On cite volontiers des statistiques spectaculaires sur la proportion de projets d'IA qui n'atteignent jamais la production. Les chiffres varient selon les études et les définitions retenues ; le phénomène, lui, est incontestable et parfaitement observable sur le terrain. Ce qui frappe, c'est la répétitivité des causes.
1. Le pilote n'avait pas de propriétaire
Un sponsor au comité de direction n'est pas un propriétaire. Le propriétaire est la personne dont le quotidien change si le projet réussit, et qui a l'autorité pour modifier une procédure. Sans elle, le projet reste une initiative de la DSI ou de l'innovation, et il meurt à la première réorganisation.
Contre-mesure : désigner nommément un responsable métier, lui allouer du temps officiel — au moins une demi-journée par semaine — et faire du projet un objectif inscrit dans son évaluation.
2. Le succès n'a jamais été défini
Interrogez trois participants d'un pilote sur ce qui constituerait une réussite : vous obtiendrez trois réponses différentes. Sans critère écrit, le projet ne peut ni être validé ni être arrêté. Il s'étire, puis s'éteint.
Contre-mesure : une phrase, écrite avant le démarrage, contenant un chiffre et une date. « À la fin du mois de novembre, au moins douze des vingt utilisateurs pilotes utilisent l'outil trois fois par semaine et le temps moyen de production d'un devis est passé sous quarante minutes. » Cette phrase se relit en comité et se vérifie.
3. La donnée n'était pas prête
C'est la cause la plus fréquente des dérapages de délai. Un assistant documentaire suppose des documents à jour, correctement nommés, sans quinze versions concurrentes du même contrat. Beaucoup de projets découvrent l'état réel du fonds documentaire en semaine six.
Contre-mesure : auditer un échantillon de données avant l'engagement. Prendre cinquante documents au hasard, les faire évaluer par un expert métier : sont-ils à jour, complets, cohérents ? La réponse conditionne le calendrier et parfois la décision elle-même.
4. La conformité est arrivée trop tard
Le scénario est classique : un pilote convaincant, une décision de généralisation, puis une revue juridique ou sécurité qui bloque tout parce que les données transitent par un service non validé, ou que l'analyse d'impact n'a pas été menée. Six mois de travail sont suspendus.
Contre-mesure : associer le délégué à la protection des données et le responsable sécurité dès le cadrage, pas à la fin. Dans notre expérience, ils sont beaucoup plus constructifs quand ils sont consultés en amont que lorsqu'ils découvrent un projet abouti qu'on leur demande de valider en trois jours.
5. L'outil n'a pas remplacé le geste
Tant que l'ancien mode opératoire reste possible et officiel, l'outil est une option. Or une option, en période de charge, n'est pas retenue : les gens font ce qu'ils savent faire vite. L'usage s'effondre dès la première période tendue.
Contre-mesure : réécrire la procédure. Le nouveau geste doit devenir le geste normal, décrit dans le mode opératoire, présenté aux nouveaux arrivants, et intégré aux points d'équipe. Ce travail est peu spectaculaire et déterminant.
6. Personne n'a assumé d'arrêter
Paradoxalement, l'incapacité à arrêter tue plus de projets qu'elle n'en sauve. Un pilote qui ne donne rien mais qu'on maintient consomme le budget, l'attention et la crédibilité nécessaires au cas d'usage suivant — qui, lui, aurait peut-être fonctionné.
Contre-mesure : écrire le critère d'arrêt en même temps que le critère de succès, et le faire appliquer par le comité, pas par l'équipe projet — qui, elle, ne peut pas être juge et partie.
La liste de contrôle avant de lancer
Sept questions. Si vous ne pouvez pas répondre à l'une d'entre elles, il est trop tôt.
- Qui est le propriétaire métier, nommément, et combien de temps y consacre-t-il ?
- Quelle phrase, avec un chiffre et une date, définit la réussite ?
- Quelle phrase définit l'arrêt ?
- Un échantillon de données a-t-il été audité par un expert métier ?
- Le délégué à la protection des données et la sécurité ont-ils validé le principe ?
- Quelle procédure existante sera réécrite ?
- Qui exploite l'outil et répond aux questions après la mise en service ?
Aucune de ces questions ne porte sur le modèle, l'architecture ou le fournisseur. C'est précisément le point.