Beaucoup d'entreprises démarrent leur transformation IA à l'envers : elles choisissent un outil, lancent un POC, et se demandent ensuite ce qu'elles vont bien pouvoir en faire. Le résultat, c'est une pile de démonstrateurs qui ne passent jamais en production. L'étape qui manque n'est pas technique, elle est stratégique.
Ce que "AI Readiness" veut dire concrètement
L'expression est souvent galvaudée. On la retrouve dans des rapports de cabinets conseil, associée à des radars de maturité à cinq niveaux et des recommandations qui ne débouchent sur rien de concret. Ce n'est pas de ça qu'on parle ici.
Un plan d'action IA opérationnel répond à quatre questions précises, dans un ordre précis, avant qu'une seule ligne de code soit écrite :
- Quels cas d'usage valent réellement le coup ?
- Les données sont-elles prêtes à soutenir ces cas d'usage ?
- Quelle est l'exposition réglementaire de chacun ?
- Dans quel ordre livrer pour maximiser la valeur et minimiser les risques ?
La différence avec un audit traditionnel : à l'issue de ce travail, vous avez un backlog priorisé, pas un rapport. Chaque item est associé à une estimation d'effort, une évaluation de risque et un ROI défendable en comité.
Question 1 : Quels cas d'usage valent vraiment le coup ?
C'est la question la plus sous-estimée. Quand on commence à collecter les idées en interne, les cas d'usage arrivent vite. Trop vite. Une direction finance voit une opportunité d'automatiser la réconciliation comptable. La direction juridique veut un assistant de revue de contrats. Le département RH parle de screening de CV automatisé. En quelques ateliers, on dépasse facilement la cinquantaine d'idées.
Le problème, c'est que toutes ne méritent pas d'être construites. La cartographie qu'on a réalisée pour un grand compte financier l'illustre bien : plus de 90 cas d'usage identifiés sur cinq domaines (Finance, Conformité, Crédit, Légal, Risque), scorés selon trois axes.
Les trois axes de scoring
| Axe | Ce qu'on évalue | Exemple concret |
|---|---|---|
| Valeur | Gain de temps, réduction d'erreurs, revenus générés | 3 ETP libérés sur la réconciliation mensuelle |
| Faisabilité | Maturité des données, complexité technique, dépendances | Données structurées existantes vs. PDF non indexés |
| Risque | Impact en cas d'erreur, exposition réputationnelle | Décision crédit automatisée vs. résumé de rapport |
Un cas d'usage qui score haut sur la valeur mais bas sur la faisabilité (parce que les données sont un désordre) ne passe pas en priorité 1. Un cas d'usage à valeur modérée mais totalement faisable en huit semaines peut, lui, financer politiquement les chantiers suivants.
Ce scoring n'est pas un exercice académique. C'est ce qui permet de présenter un premier chantier avec un argumentaire solide : voici ce qu'on construit, voici pourquoi maintenant, voici ce que ça rapporte.
Question 2 : Les données sont-elles prêtes ?
C'est ici que la plupart des projets IA meurent, silencieusement, après six mois de travail. L'évaluation de la maturité des données couvre quatre dimensions :
Sources et accessibilité. Où sont les données ? Dans un ERP vieillissant, dans des tableurs partagés sur SharePoint, dans des bases de données sans documentation ? L'accès est-il programmatique (API, connecteur) ou manuel (exports CSV hebdomadaires) ? Cette question seule peut doubler ou tripler l'estimation d'effort d'un projet.
Qualité et complétude. Une donnée accessible n'est pas forcément utilisable. Des champs vides à 40 %, des formats incohérents entre business units, des libellés qui ont changé trois fois en cinq ans : tout ça doit être évalué avant de choisir une approche technique. Il est parfois plus rapide de nettoyer un jeu de données que de construire un modèle robuste à la donnée sale.
Volumétrie et fraîcheur. Certains cas d'usage nécessitent de l'historique (détection d'anomalie, prévision), d'autres fonctionnent bien avec des données récentes mais peu nombreuses (classification, extraction). La volumétrie conditionne aussi les choix d'architecture.
Hébergement et souveraineté. En 2025, envoyer des données clients ou des données métier sensibles vers un LLM hébergé hors UE sans encadrement contractuel, c'est une prise de risque RGPD réelle. L'évaluation de la maturité IA doit inclure une cartographie des flux de données par cas d'usage et valider que l'hébergement est compatible avec les exigences réglementaires de l'entreprise.
Question 3 : Quelle conformité pour chacun ?
Le cadre réglementaire autour de l'IA évolue vite. Deux textes structurent aujourd'hui l'espace de jeu pour les entreprises françaises et européennes : le RGPD, que la plupart connaissent déjà, et l'EU AI Act, dont les obligations commencent à s'appliquer de manière progressive depuis 2024.
Ce que l'EU AI Act change concrètement
L'AI Act introduit une classification par niveau de risque. Pour la plupart des cas d'usage en entreprise (automatisation de back-office, assistance à la rédaction, résumé de documents), le niveau de risque est limité. Mais certains domaines sont directement concernés par des obligations renforcées :
- Décisions RH automatisées : recrutement, évaluation de performance
- Scoring crédit sans supervision humaine suffisante
- Systèmes d'identification biométrique
- Décisions dans des secteurs critiques : santé, justice, infrastructures
Pour chaque cas d'usage identifié dans un plan d'action IA, il faut donc documenter : quel niveau de risque AI Act, quelle base légale RGPD, quel degré de supervision humaine requis, et quelles obligations de traçabilité. Ce n'est pas un travail de juriste pur, c'est un travail conjoint entre l'équipe technique, le DPO et les métiers concernés.
Ignorer cette étape ne fait pas gagner du temps. Ça déplace le problème vers la production, où le coût de mise en conformité est cinq à dix fois plus élevé.
Question 4 : Par où commencer et dans quel ordre ?
C'est la question opérationnelle finale, et c'est celle qui transforme un exercice de cartographie en feuille de route réelle.
La priorisation doit équilibrer plusieurs contraintes simultanément :
La valeur perçue par le métier. Un premier chantier doit être visible et utile rapidement. Si personne dans l'organisation ne voit de résultat tangible dans les six premiers mois, le programme perd son momentum politique.
La faisabilité technique à court terme. Les projets dont les données sont propres, les accès disponibles et les dépendances limitées passent devant, même si leur valeur n'est pas la plus élevée sur le papier. Livrer quelque chose en production, c'est structurer un transfert qui tient dans la durée : documentation, observabilité, runbooks.
Le risque réglementaire. Les cas d'usage à haut risque AI Act ne doivent pas être les premiers livrés, sauf si l'organisation a déjà une infrastructure de gouvernance solide. Mieux vaut commencer sur un terrain balisé et accumuler de l'expérience avant de s'attaquer aux cas complexes.
Les effets de séquence. Certains cas d'usage créent de la valeur pour les suivants. Un système d'extraction et de structuration de documents, par exemple, peut servir de socle à cinq ou six cas d'usage en aval. Construire cet enabler en premier multiplie la vitesse de déploiement des chantiers suivants.
Ce que ça donne en pratique
Pour le grand compte financier mentionné plus haut, le résultat de la cartographie n'était pas un classement des 90 cas d'usage par score décroissant. C'était une feuille de route sur 18 mois avec trois horizons :
- Horizon 1 (0-6 mois) : 4 cas d'usage en production, faisabilité immédiate, données prêtes, risque faible
- Horizon 2 (6-12 mois) : 8 cas d'usage conditionnés à des travaux de data quality ou d'infrastructure
- Horizon 3 (12-18 mois) : Cas d'usage à fort potentiel mais nécessitant une infrastructure de gouvernance IA plus mature
Chaque horizon avait un ROI estimé, une liste de prérequis et un responsable métier identifié. C'est ce niveau de détail qui rend un plan d'action IA défendable en CODIR.
Pourquoi la plupart des entreprises sautent cette étape
Parce qu'elle n'est pas sexy. Un workshop d'idéation avec des post-its sur l'IA générative, ça mobilise les équipes. Une analyse rigoureuse des sources de données et des gaps de qualité, moins.
Il y a aussi une pression du résultat rapide : les directions veulent voir une démo, quelque chose qui tourne. Le POC répond à cette demande. Il rassure à court terme tout en créant un problème structurel : comment passe-t-on d'un POC à un système en production, maintenu, monitoré, conforme ? Cette question, sur laquelle notre méthode Build & Run répond ligne par ligne, ne se pose plus si on n'a jamais défini ce qu'on cherchait à construire en premier lieu.
Enfin, il y a une confusion entre vitesse et précipitation. Faire ce travail de cadrage prend du temps, certes, mais il en fait gagner beaucoup plus en évitant les faux départs. Un projet lancé sans plan d'action IA solide a statistiquement plus de chances d'être arrêté, refondu ou abandonné après six mois de développement.
Ce que ce travail produit réellement
À l'issue d'un plan d'action IA bien conduit, vous disposez de :
- Un inventaire priorisé des cas d'usage avec score valeur/faisabilité/risque
- Un état des lieux des données par domaine métier
- Une cartographie réglementaire cas par cas (RGPD, AI Act)
- Une feuille de route sur 12 à 18 mois avec jalons, prérequis et ROI estimé
- Un premier chantier clairement défini, prêt à être lancé sans ambiguïté
Ce n'est pas un rapport de plus. C'est le document de référence qui aligne la direction, les métiers et les équipes techniques sur quoi construire, pourquoi maintenant, et avec quelles ressources.
Si vous ne savez pas encore où en est votre organisation sur ces quatre questions, c'est probablement le bon moment pour le vérifier, avant de signer le prochain bon de commande d'un éditeur IA.