Pourquoi une majorité de projets IA n'arrivent jamais en comité ?

Ce que le prototype démontre

Un prototype d’IA a un métier précis : montrer qu’une sortie est possible. Sur un échantillon, dans un délai court, avec une équipe resserrée, on obtient un texte, un score, une extraction, un matching. Les métiers voient quelque chose qu’ils n’avaient pas. L’effet est réel. Il explique pourquoi tant de projets démarrent, et pourquoi tant de comités de direction applaudissent une démonstration.

Ce que le prototype démontre aussi, en négatif, est plus discret. Il démontre que l’on peut produire sans journal d’audit, sans chaîne de validation, sans politique d’accès fine, sans coût par exécution, sans rejeu. Ces absences ne sont pas des oublis dans le cadre d’un prototype. Elles sont la condition de sa vitesse. On a retiré tout ce qui n’était pas nécessaire pour convaincre.

Le prototype répond donc à une question : « un modèle peut-il extraire, classer, rédiger, scorer dans notre domaine ». Il ne répond pas à : « un comité peut-il s’appuyer sur ce résultat pour décider, six mois plus tard, face à un auditeur ». Ce sont deux questions. Les organisations les fusionnent. Elles prennent la réponse à la première pour une réponse à la seconde. Le projet avance. Il avance vers un mur qui n’était pas dans la démo.

Il faut rendre justice aux prototypes. Ils sont utiles pour écarter une impasse technique, pour préciser un rituel, pour former un jugement sur la qualité brute. Ils deviennent un piège lorsqu’ils sont traités comme une version zéro de la production. Une version zéro de la production aurait déjà, même rudimentaires, les fondations. Un prototype n’est pas une version zéro. C’est un objet d’un autre type.

La démonstration a aussi un effet politique. Une fois montrée, elle crée une créance : « nous avons vu que c’était possible ». Les fondations, elles, n’ont pas été vues. Lorsque le délai d’industrialisation s’allonge, la créance se retourne contre le projet. Le comité se souvient de la démo, pas de la liste des absences. Entrer par le rituel, c’est éviter de créer cette créance avant d’avoir de quoi la honorer.

Ce que la production exige

Entrer en comité, c’est exposer un résultat à des personnes qui n’ont pas construit le système, qui en porteront la responsabilité, et qui devront le défendre. Les exigences qui s’ensuivent ne sont pas du confort.

Traçabilité. Le livrable pointe vers ses sources. Le run a un identifiant. Les paramètres sont figés. Sans cela, le comité discute d’un objet dont l’origine est une conversation.

Validation formalisée. Quelqu’un approuve, en rôle, en date, sur un dossier visible. Le comité n’est pas un lieu où l’on « prend acte » d’un texte généré. C’est un lieu où l’on décide. La décision a besoin d’un signataire.

Gestion des accès. Les données du rituel ne sont pas un export ouvert à l’équipe projet. En production, le périmètre, les habilitations, le cloisonnement, l’identité du lanceur de run font partie du système. Un prototype tourne souvent avec un compte partagé. Un compte partagé n’entre pas en comité.

Pilotage du coût. Un prototype n’a pas de volume. La production en a un. Sans coût par run, sans observabilité, le rituel est un chèque en blanc. Les directions financières le savent. Elles bloquent, ou elles laissent filer jusqu’à la première facture, puis elles bloquent plus tard, plus durement.

Journal d’audit. Ce n’est pas un fichier de logs bruts. C’est la possibilité de raconter une exécution avec des artefacts. Le comité qui sait qu’il ne pourra pas répondre à une question ultérieure préfère, rationnellement, ne pas s’appuyer sur le résultat. Mieux vaut un processus manuel connu qu’un processus automatique indéfendable.

Ces exigences sont celles de n’importe quel système qui touche une décision d’entreprise. L’IA n’y ajoute pas une magie. Elle y ajoute une difficulté : la sortie est fluide, donc elle paraît prête plus tôt que les fondations.

L’écart de fondations

L’écart n’est pas un écart de features à « ajouter au sprint suivant ». C’est un écart d’architecture. La traçabilité qui n’a pas été conçue dans le flux d’exécution se greffe mal. La validation qui n’est pas un état du livrable devient un circuit parallèle que personne n’emprunte. Les accès qui n’ont pas été modelés dès les données d’entrée se corrigent par des exceptions. Le journal d’audit qui n’est pas émis au run se reconstitue par enquête.

C’est pourquoi tant de projets restent au stade « industrialisation en cours ». L’industrialisation, ici, n’est pas un déploiement Kubernetes. C’est la construction tardive de fondations sous un édifice déjà habité. On peut y parvenir. C’est long, cher, et politiquement fragile, parce que les métiers ont vu la démo et ne comprennent pas le délai.

Les chiffres de cimetière des projets IA : les pourcentages souvent cités de prototypes qui ne passent pas : mesurent surtout cet écart. Ils ne mesurent pas l’incapacité des modèles à extraire une exigence ou à classer un produit. Ils mesurent l’incapacité des organisations à offrir à un comité un objet signable. Le modèle a fait sa part. Le rituel n’a pas la sienne.

L’écart se voit aussi dans les critères d’acceptation. Le prototype est accepté sur une impression de qualité. La production est acceptée sur une capacité à durer : reprise sur incident, changement de modèle, départ d’un expert, demande d’un auditeur. Un système qui ne survit pas à ces quatre événements n’est pas en production. Il est en démonstration prolongée.

Entrer par le rituel plutôt que par le prototype

La séquence qui réduit l’écart inversé le point d’entrée. On ne part pas d’un modèle à « trouver un cas ». On part d’un rituel qui existe déjà : une revue d’exigences, un comité de pricing, un reporting périodique, une classification catalogue. Ce rituel a déjà des rôles, un calendrier, un livrable, une honte interne quand le livrable est indéfendable.

On demande alors : de quoi ce rituel a-t-il besoin pour que le livrable soit sourcé, validé, rejouable, et d’un coût lisible. Le modèle vient après cette question, comme un moteur parmi d’autres, remplaçable. Les fondations viennent avec le premier run utile, pas après le vingtième.

Cette séquence paraît plus lente au début. Elle évite la phase où l’on possède une démo admirable et un comité qui refuse de s’en servir. Le critère de succès n’est plus « le métier a été surpris ». C’est « le métier a signé, et le dossier existe ». La surprise n’est pas une unité de production. La signature l’est.

Les projets qui arrivent en comité ne sont pas ceux dont le modèle est le plus habile en démonstration. Ce sont ceux dont le rituel a été pris au sérieux : mêmes personnes, mêmes enjeux, mêmes questions d’audit, avec un système qui émet la preuve au moment où le résultat est produit. Le prototype a sa place, en amont, pour tester une extraction ou un matching. Il n’a pas sa place comme substitut aux fondations. Confondre les deux, c’est expliquer, année après année, pourquoi « ça n’arrive jamais en comité ». L’explication, une fois posée, est opérationnelle. Elle se corrige par l’ordre des travaux, pas par un modèle plus récent.

Un test simple permet de savoir où l’on se situe. Demander, sur le dernier livrable produit par le prototype : qui a signé, sur quelles sources, avec quel identifiant de run, et en combien de temps on exporte le dossier. Si trois réponses sur quatre manquent, le projet n’est pas en retard d’industrialisation. Il n’a pas commencé l’industrialisation. Il a réussi une démonstration. Les deux n’ont pas le même comité pour destination.