Les cinq erreurs qui font échouer un projet d'IA

Le projet démarre par « nous voulons faire de l'IA », ou pire, par « nous voulons utiliser tel modèle ». C'est un objectif de moyen.

Ce qui se passe ensuite est prévisible : on construit quelque chose qui fonctionne, on le montre en comité, tout le monde trouve ça impressionnant, et personne ne l'utilise trois mois plus tard. Le système n'était pas mauvais — il ne répondait à rien.

Le signal d'alerte : personne ne sait dire, en une phrase, quel problème est résolu.

Un programme qui vise à transformer cinq processus simultanément échoue presque toujours. Trop de dépendances, trop d'interlocuteurs, trop de fronts ouverts en même temps. Quand une brique prend du retard, tout attend.

Un périmètre restreint permet de mesurer, de corriger et de décider. Un périmètre large permet seulement de constater l'échec à la fin.

Le signal d'alerte : le mot « transformation » apparaît plus souvent que le nom d'une tâche concrète.

C'est l'erreur la plus fréquente et la plus coûteuse.

Un agent s'entraîne sur ce qui existe. Si les procédures ne sont écrites nulle part, si le catalogue n'est pas à jour, si les indicateurs n'ont pas de définition commune, il n'y a rien à indexer. Aucune technique ne compense l'absence de matière.

Le projet démarre quand même, la phase de cadrage s'allonge, on découvre que le travail réel est d'écrire ce que l'entreprise sait — et ce travail n'était ni prévu ni budgété.

Le signal d'alerte : à la question « où sont vos procédures ? », la réponse est « dans la tête de untel ».

Un agent produit une alerte, un chiffre, une réponse. Si personne n'est désigné pour en faire quelque chose, le système produit du bruit.

Nous avons vu des systèmes d'alerte parfaitement fonctionnels dont les notifications arrivaient sur un téléphone que personne ne regardait la nuit. Le système marchait. Le projet avait échoué.

Le signal d'alerte : à la question « qui reçoit l'alerte et que fait-il ? », la réponse est un service, pas une personne ou un rôle avec une procédure.

Sans critère défini avant de commencer, la discussion de fin de projet devient une affaire d'impression. Le prestataire trouve que ça marche, le client trouve que ce n'est pas ça, et personne ne peut trancher.

Un critère écrit protège les deux parties. Il protège le client contre un système qui ne tient pas ses promesses, et le prestataire contre un déplacement permanent de la cible.

Le signal d'alerte : personne ne peut dire, avant le démarrage, à quoi on reconnaîtra que le projet a réussi.

Par honnêteté, parce que c'est celle qui revient.

Sous-estimer le temps de calibrage. Un système livré avec des paramètres corrects en laboratoire produit des faux positifs sur site, jusqu'à ce que plus personne ne regarde les alertes. Le réglage sur conditions réelles n'est pas une finition : c'est la moitié du travail.

C'est la raison pour laquelle nous annonçons 4 à 8 semaines et non deux. Le temps « gagné » sur le calibrage se paie ensuite au décuple, en crédibilité perdue.

Il tient en cinq phrases écrites avant de commencer :

• Le problème, en une phrase
• La matière disponible, vérifiée et non supposée
• Le destinataire du résultat, nommé
• Le critère de réussite, chiffré
• Le périmètre du pilote, volontairement étroit

Si ces cinq phrases ne peuvent pas être écrites, il est trop tôt. Ce n'est pas un échec — c'est une information qui vous économise un budget.

Aucune des cinq erreurs n'est technique. Toutes se détectent avant le démarrage, en une conversation d'une demi-heure. C'est précisément ce que fait le diagnostic — et c'est pour cela qu'il conclut parfois à « pas maintenant ».