Un projet d'IA arrêté laisse trois choses : du code, des données, et une méfiance.
Les deux premières se diagnostiquent en quelques jours. La troisième est le vrai sujet, et c'est celle qui décide si la reprise réussira.
Nous intervenons sur ce type de reprise. Voici la méthode que nous appliquons, et ce qu'elle révèle le plus souvent.
Commencer par la cause réelle de l'arrêt
La première erreur consiste à ouvrir le code. Avant cela, il faut comprendre pourquoi le projet s'est arrêté, et cette réponse ne se trouve pas dans un dépôt.
L'explication officielle est presque toujours technique : le modèle n'était pas assez bon, les réponses n'étaient pas fiables, la technologie n'était pas mûre. Ces explications sont rarement fausses, mais elles sont rarement la cause.
Les causes réelles, par ordre de fréquence constatée :
Personne ne tranchait. Le projet avançait jusqu'au premier arbitrage sur le corpus ou le périmètre, puis les questions remontaient sans redescendre. Le calendrier glissait sans qu'on sache dire pourquoi.
Le périmètre s'est étendu. Chaque ajout paraissait raisonnable. À la fin, rien n'était terminé, et le budget était consommé.
Aucun critère de succès n'avait été écrit. Le système fonctionnait, et personne ne savait dire s'il avait réussi. Chacun jugeait selon des attentes implicites qui divergeaient.
Les utilisateurs n'ont jamais eu le temps. Le dispositif était livré, les référents métier avaient déjà un travail à plein temps, et l'appropriation n'a pas eu lieu.
Le corpus était inexploitable. Documents scannés, versions contradictoires, tableaux illisibles. Le système répondait avec assurance à partir d'informations fausses.
Pour identifier la bonne, il faut parler séparément à trois personnes : le commanditaire, un utilisateur qui a essayé, et la personne technique qui a construit. Leurs trois récits ne coïncident jamais, et c'est précisément l'écart entre eux qui indique où le projet a cassé.
Le diagnostic technique, en quatre points
Une fois la cause organisationnelle comprise, l'examen technique se concentre sur ce qui décide de la valeur.
Le corpus. Combien de documents, dans quel état, et surtout : que produit réellement leur extraction ? Prendre trente documents représentatifs et regarder le texte obtenu tranche plus de questions qu'une semaine d'analyse d'architecture. Un corpus dégradé explique à lui seul la plupart des déceptions sur la qualité des réponses.
Le cloisonnement. Qui a accès à quoi, et cette séparation est-elle appliquée par une architecture ou par une condition dans une requête ? Un filtre logique qu'un défaut de code peut contourner n'est pas une isolation. C'est un point à vérifier tôt, parce qu'il conditionne ce qu'on peut proposer à un secteur réglementé.
Ce qui est réellement branché. Sur les projets repris, nous trouvons régulièrement des composants complets mais inaccessibles : une interface de programmation dont les routes ne sont chargées nulle part, des tests qui vérifient du code mort, un générateur de métadonnées jamais appelé contenant des informations obsolètes. Ce code donne l'illusion d'un système plus avancé qu'il ne l'est.
Ce qui est mesuré. Y a-t-il des tests, une mesure de couverture, une surveillance en production ? L'absence n'est pas rédhibitoire, mais elle indique le volume de travail avant toute modification sûre. Sur notre propre plateforme, la campagne de couverture a révélé que quatorze modules n'avaient aucun test, dont les traitements asynchrones à 21 % et les contrôleurs de sécurité à 40 %. Le code le moins testé était systématiquement celui dont l'échec était le plus silencieux.
Ce qui mérite d'être conservé
La tentation de tout reprendre à zéro est forte, et rarement justifiée.
Le corpus sélectionné mérite presque toujours d'être gardé. Le travail de choix des documents, quand il a été fait, représente l'essentiel de la valeur accumulée. Il a demandé des arbitrages métier qui ne se refont pas gratuitement.
Les intégrations qui fonctionnent. Un connecteur vers un système interne, une fois qu'il marche, encapsule une connaissance des particularités de ce système qui a coûté cher à acquérir.
Les cas d'usage documentés. Si quelqu'un a écrit les questions que les utilisateurs posent réellement, cette liste est un jeu d'évaluation prêt à l'emploi. C'est rare, et précieux.
Ce qui mérite d'être jeté : le code mort, les composants à moitié branchés, et les tests qui vérifient des chemins inaccessibles. Ils coûtent du temps de compréhension à chaque intervention et masquent l'état réel du système.
Le point difficile : la confiance des utilisateurs
Voici ce qui distingue une reprise d'un démarrage.
Des personnes ont essayé un outil, l'ont trouvé décevant, et ont conclu que « l'IA, chez nous, ça ne marche pas ». Cette conclusion est ancrée, elle circule, et elle est partiellement justifiée : leur expérience était réellement mauvaise.
Trois principes, appris à nos dépens.
Ne pas promettre que cette fois sera différente. L'argument a déjà été utilisé. Il ne produit plus d'effet, et il agace.
Montrer sur leur matériau. Une démonstration construite sur les documents réels du service, répondant à trois questions qu'ils posent effectivement, vaut mieux que n'importe quel discours. La différence se constate ou ne se constate pas.
Nommer ce qui avait échoué. Dire explicitement « les réponses étaient fausses parce que le corpus contenait trois versions du même document, et voici comment nous traitons ce point » restaure plus de crédibilité qu'une présentation qui ferait comme si rien ne s'était passé.
Cette dernière posture demande que le diagnostic ait été fait honnêtement. C'est la raison pour laquelle il vient avant tout le reste.
Redémarrer petit, y compris quand le système existe
Le réflexe naturel est de reprendre là où le projet s'est arrêté. C'est généralement une erreur.
Un projet interrompu s'est arrêté à un moment où son périmètre était trop large. Reprendre à ce point revient à hériter du problème qui l'a fait échouer.
La méthode qui fonctionne consiste à choisir un périmètre volontairement étroit : un métier, un corpus restreint, trois cas d'usage précis, et un critère de succès écrit avant de commencer. Le reste du système existant peut rester en place sans être utilisé.
Ce redémarrage réduit produit un résultat vérifiable en quelques semaines. C'est ce résultat, et non un plan, qui rétablit la confiance et débloque la suite.
Les sept conditions, à revérifier
Une reprise sans vérifier les prérequis reproduit l'échec initial. Ces conditions sont les mêmes que pour un démarrage : un propriétaire métier nommé, un périmètre délimité, des données exploitables, un critère de succès écrit, une décision d'accès prise avant l'indexation, du temps utilisateur réellement alloué, et une politique d'usage face à l'erreur.
Sur une reprise, la question à poser est plus précise : laquelle de ces conditions manquait la première fois, et qu'est-ce qui a changé depuis ?
Si la réponse est « rien n'a changé », la reprise échouera pour la même raison. Il vaut mieux le dire avant de s'engager que de le constater après.
Ce qu'il faut retenir
Reprendre un projet d'IA arrêté commence par un diagnostic organisationnel, pas technique. La cause de l'arrêt est presque toujours l'absence d'un décideur, un périmètre qui s'est étendu, un critère de succès jamais écrit, ou un corpus inexploitable.
L'examen technique se concentre sur quatre points : l'état réel du corpus, la nature du cloisonnement, ce qui est effectivement branché, et ce qui est mesuré.
Le code mérite souvent d'être largement conservé. Le périmètre, lui, doit être réduit : reprendre au point d'arrêt revient à hériter du problème.
Et le travail le plus important ne se voit dans aucun dépôt : rétablir la confiance de gens qui ont déjà été déçus une fois. Cela passe par une démonstration sur leur propre matériau, et par le courage de nommer ce qui avait échoué.
