« Quel outil d’IA devrions-nous acheter ? » C’est souvent la première question que nous pose un dirigeant. C’est rarement la bonne. Elle place la technologie au centre, alors que le succès d’un projet d’IA se joue presque toujours ailleurs : dans la clarté du problème, dans l’état des données, et dans la manière dont l’organisation décidera et assumera ce que le système produit.
Avant tout projet, nous posons donc trois questions. Toujours dans le même ordre.
1. Quel problème, mesuré comment ?
Un bon projet d’IA commence par un irritant métier que l’on sait chiffrer : des heures passées à consolider des tableaux, un taux d’erreur, un délai de réponse client, un coût. « Faire de l’IA » n’est pas un problème. « Diviser par deux le temps de production du rapport hebdomadaire » en est un.
Cette mesure de départ sert trois fois : pour choisir entre plusieurs cas d’usage, pour décider si le projet vaut l’investissement, et pour savoir, à la fin, s’il a réussi.
- Qui souffre du problème aujourd’hui, et combien de fois par semaine ?
- Que coûte-t-il, en temps, en erreurs ou en argent ?
- À quoi ressemblerait un succès dans six mois, en un seul chiffre ?
2. Quelles données, et à qui sont-elles ?
Un système d’IA ne vaut que par les données qu’il reçoit. Trois vérifications suffisent à éviter la plupart des mauvaises surprises.
- Existence : les données nécessaires sont-elles réellement collectées, ou seulement supposées l’être ?
- Qualité : sont-elles complètes, à jour et cohérentes d’une source à l’autre ?
- Accès : qui en est responsable, et peut-on y accéder légalement et techniquement ?
Il arrive que la réponse honnête soit « pas encore ». Dans ce cas, le premier chantier n’est pas l’IA, mais la donnée. C’est une conclusion précieuse, et beaucoup moins coûteuse quand elle arrive avant le projet qu’au milieu.
3. Quelle gouvernance ?
Un système d’IA finit toujours par se tromper. La question n’est pas de l’éviter, mais de savoir ce qui se passe à ce moment-là.
- Qui décide de déployer le système, et qui peut l’arrêter ?
- Qui répond de ses résultats devant la direction, les clients ou le régulateur ?
- Comment une erreur est-elle repérée, corrigée, puis évitée la fois suivante ?
Ces réponses ne relèvent pas de l’informatique. Elles relèvent de la direction. C’est pourquoi la gouvernance se pose avant le premier prototype, et non après le premier incident.
Si l’une des trois réponses manque, ce n’est pas encore un projet d’IA. Et c’est une très bonne nouvelle de le savoir tôt.
Un exemple : le reporting d’un grand groupe industriel
Pour un grand groupe industriel, les trois réponses étaient claires dès le départ. Le problème : des rapports opérationnels consolidés à la main, chaque semaine, au prix de nombreuses heures et d’erreurs de recopie. Les données : déjà produites par les outils des équipes, mais dispersées. La gouvernance : une équipe métier identifiée, propriétaire du rapport et de sa validation.
Le système de reporting automatisé a donc pu être cadré, construit et documenté sans détour. Résultat : plus de 70 % de temps gagné sur la production des rapports, et moins d’erreurs.
Pourquoi cet ordre
Commencer par les données, c’est risquer de construire une solution à la recherche d’un problème. Commencer par la gouvernance, c’est encadrer un projet dont on ne connaît pas encore la valeur. Le problème vient en premier parce qu’il donne leur sens aux deux autres questions.
En vidéo
Ces trois questions, présentées dans un entretien avec Malt sur les raisons pour lesquelles tant de projets d’IA en entreprise n’aboutissent pas.
À retenir
- Un problème métier chiffré, avant tout choix d’outil.
- Des données qui existent, fiables et accessibles.
- Une gouvernance claire : qui décide, qui répond, que faire en cas d’erreur.
Testons ces trois questions sur votre projet, en 30 minutes.
Réserver un appelAutres notes