Carnet de bord · 2026-07-26

Autopsie d'un projet IA — six mois, zéro impact

Cas reconstitué à partir de missions réelles. Un projet d'IA générative lancé en fanfare, mort sans bruit. Six causes, aucune n'est technique.

Le patient : une ETI, 400 personnes, un comité de direction convaincu qu'il fallait « faire de l'IA ». Budget voté sans débat. Un chef de projet motivé, un partenaire techno sérieux, des équipes plutôt volontaires.

Six mois plus tard : une démo qui fonctionne, deux slides de restitution, et rien qui ait changé dans le travail de qui que ce soit.

Personne n'a échoué. C'est bien ça le problème : chaque décision, prise isolément, était défendable. C'est leur accumulation qui a produit le vide.

Les chiffres ci-dessous sont arrondis et anonymisés, reconstitués à partir de plusieurs missions. Ouvrez chaque cause pour lire la dissection.

Le cas d'usage a été choisi par la technoCause n°1

Le constat. Le projet démarre par une question : « qu'est-ce qu'on pourrait faire avec l'IA ? ». La réponse arrive d'un atelier de deux heures avec l'intégrateur : un assistant conversationnel sur la base documentaire interne.

La dissection. Personne n'a jamais mesuré combien de temps les équipes perdaient réellement à chercher un document. En entretien, le vrai irritant était ailleurs : la ressaisie manuelle entre deux outils qui ne se parlent pas — un sujet d'intégration, pas d'IA.

Le cas d'usage n'a pas été choisi parce qu'il résolvait un problème coûteux. Il a été choisi parce qu'il démontrait bien la technologie.

Verdict : un projet qui répond à une question que personne ne se posait. La bonne première question n'est jamais « que peut faire l'IA ? » mais « qu'est-ce qui nous coûte le plus cher aujourd'hui ? ».

La donnée était le vrai plafondCause n°2

Le constat. La base documentaire contenait « environ 12 000 documents ». Chiffre annoncé au lancement, jamais audité.

La dissection. Après inventaire : près d'un tiers de doublons ou de versions périmées, aucune règle de nommage, des documents contradictoires qui coexistaient sans date de validité. L'assistant répondait donc parfois avec une procédure abandonnée deux ans plus tôt — avec le même aplomb que pour une réponse juste.

C'est le piège classique : la qualité de la donnée n'est pas un détail d'implémentation, c'est le plafond de verre du projet. Aucun modèle ne compense un référentiel que personne n'a nettoyé.

Verdict : trois mois de travail de fond ont été découverts après le lancement, pas avant. Un audit de données de deux semaines en amont aurait redimensionné tout le projet.

Le POC ne pouvait pas devenir un produitCause n°3

Le constat. Le prototype tourne en huit semaines. Démo applaudie en COMEX. Puis : plus rien pendant trois mois.

La dissection. Le POC avait été construit hors du système d'information : données copiées à la main, aucune gestion des droits, aucune authentification, un environnement qui n'existait pas dans la cartographie de la DSI.

Le passer en production ne demandait pas un ajustement, mais une reconstruction — avec cette fois la sécurité, la conformité RGPD, la reprise des habilitations et l'exploitation. Personne n'avait chiffré ce trajet, parce que la démo avait donné l'illusion que le plus dur était fait.

Verdict : un POC réussi qui prouvait uniquement que la démo était possible. Un prototype qui ignore les contraintes de production ne prouve rien sur la production.

Personne n'a changé sa façon de travaillerCause n°4

Le constat. L'outil est mis à disposition. Un e-mail d'annonce, un lien dans l'intranet, une session de démonstration facultative.

La dissection. Après six semaines : 18 % des utilisateurs cibles l'avaient ouvert une fois, moins de 4 % l'utilisaient chaque semaine. Aucun processus n'avait été modifié pour l'intégrer, aucun manager ne l'avait inscrit dans une routine d'équipe, et l'ancien réflexe — demander à un collègue — restait plus rapide et plus fiable.

Un outil qui s'ajoute au travail existant sans en retirer une seule étape sera toujours perçu comme du travail en plus.

Verdict : l'adoption n'était le sujet de personne. Elle était implicitement attendue de la technologie elle-même.

Aucun avant, donc aucun aprèsCause n°5

Le constat. À la restitution, la question tombe : « bon, ça nous a rapporté quoi ? ». Silence.

La dissection. Aucune mesure de référence n'avait été prise avant le lancement : ni temps passé, ni volume de demandes, ni taux d'erreur, ni satisfaction. Impossible, six mois plus tard, de démontrer une amélioration — et tout aussi impossible de démontrer qu'il n'y en avait pas.

Le projet s'est donc défendu avec ce qui restait : des verbatims choisis et un nombre de connexions. Deux indicateurs qui ne prouvent rien.

Verdict : sans point de départ, il n'existe aucune trajectoire. Une mesure d'avant coûte quelques jours ; son absence coûte la capacité à décider de la suite.

Le coût réel n'a jamais été consolidéCause n°6

Le constat. Budget voté : la ligne « projet IA » de l'intégrateur. C'est le seul chiffre qui a circulé.

La dissection. N'y figuraient ni le temps interne (chef de projet, DSI, référents métier mobilisés en ateliers), ni les licences, ni l'infrastructure, ni surtout le coût d'opportunité : pendant ces six mois, le chantier d'intégration entre les deux outils qui ne se parlaient pas — le vrai irritant identifié en cause n°1 — n'a pas avancé.

En consolidant, le coût complet dépassait largement le double de la ligne budgétaire annoncée.

Verdict : ce n'est pas le budget IA qui a coûté cher, c'est ce qu'on n'a pas fait pendant ce temps.

Le rapport d'autopsie

Six causes. Aucune n'est technique. Le modèle fonctionnait, l'intégrateur a livré ce qui était commandé, les équipes n'ont pas saboté quoi que ce soit.

Ce qui a tué le projet tient en une phrase : il a été piloté comme un projet technologique alors que c'était un projet d'organisation.

Et c'est le point aveugle du moment. L'IA générative est arrivée avec une promesse de simplicité — un prompt, une réponse — qui a fait oublier les fondamentaux que l'on n'aurait jamais négligés sur un ERP ou un CRM : qualité des données, cas d'usage chiffré, conduite du changement, mesure d'impact.

Les quatre questions à poser avant de voter un budget IA :

  1. Quel processus précis coûte cher aujourd'hui, et combien exactement ?
  2. Nos données sur ce processus sont-elles exploitables en l'état — qui l'a vérifié ?
  3. Qui va changer sa façon de travailler, et qu'est-ce qu'on retire de son quotidien en échange ?
  4. Qu'est-ce qu'on mesure avant de commencer ?

Si les quatre réponses n'existent pas, le projet ne produira pas d'impact — quelle que soit la qualité du modèle.

Ces questions n'exigent ni data scientist ni budget. Elles exigent quelqu'un sans intérêt dans le résultat : ni l'intégrateur qui vend la techno, ni l'équipe qui a porté le projet en interne.

C'est exactement le protocole Dark Motu. Huit questions pour situer votre maturité réelle : le diagnostic. Ou directement : parlons-en.

Dans la même série : Autopsie d'un budget média — 100 000 € passés au scalpel.