Une IA qui hallucine en production ne se répare pas en changeant de modèle le lendemain matin. Chez les PME et les ETI, les réponses inventées sont souvent le symptôme d'une base documentaire périmée, d'une version de modèle qui a changé sans que personne ne le sache, ou d'un prompt retouché à la main sans jeu de tests. Voici, anonymisé, le cas d'un assistant documentaire chez un industriel et les garde-fous posés pour que le problème ne revienne pas.
Le cas : un assistant fiable pendant le pilote, des réponses inventées un an plus tard
L'entreprise fabrique des équipements industriels et emploie un peu plus de trois cents personnes sur deux sites. Son service après-vente répond chaque jour à des questions techniques venues des distributeurs : compatibilité d'une pièce avec une référence, procédure de remplacement, couple de serrage, conditions de garantie.
Un assistant documentaire de type RAG (génération augmentée par recherche) avait été mis en place pour que les techniciens du service après-vente obtiennent une réponse sourcée en quelques secondes au lieu de fouiller dans un répertoire de fichiers. Le pilote avait duré trois mois. Les techniciens l'avaient adopté et le prestataire avait clôturé le projet.
Quatorze mois plus tard, la directrice du service après-vente demande une réunion. Un distributeur a monté une pièce sur un modèle incompatible en suivant une réponse de l'assistant. Deux autres cas similaires remontent la même semaine. Les techniciens ont commencé à revérifier chaque réponse dans les documents d'origine, ce qui supprime le gain de temps que l'outil était censé apporter.
Le prestataire initial ne répond plus depuis plusieurs mois. Le développeur interne qui avait suivi le projet a changé de poste. Personne dans l'entreprise ne sait dire comment l'outil fonctionne ni où regarder. C'est dans cet état que nous prenons le dossier.
Ce que le dirigeant voyait, ce que les journaux montraient
Du point de vue de la direction, le constat tient en une phrase : l'IA s'est mise à inventer. C'est une lecture trompeuse, parce qu'elle laisse penser à un défaut du modèle, donc à quelque chose sur lequel l'entreprise n'a pas prise.
Les journaux d'exécution racontent autre chose. L'assistant conservait, pour chaque question, la requête envoyée, les extraits de documents récupérés, la réponse produite et l'identifiant du modèle appelé. Nous avons relu un échantillon de trois cents échanges répartis sur l'année avec un technicien expérimenté du service.
Trois familles de réponses fautives sont apparues. D'abord, des réponses exactes au regard des documents récupérés, mais fondées sur des documents qui n'étaient plus valides. Ensuite, des réponses dont le style avait changé, plus affirmatives et chargées de détails absents des extraits fournis. Enfin, des réponses où l'assistant tranchait alors que les extraits se contredisaient, sans signaler le doute.
Chacune de ces familles correspond à une cause différente. Aucune des trois ne se corrige en changeant de fournisseur de modèle.
Diagnostic un : la base documentaire n'était plus à jour
L'assistant avait été alimenté au moment du pilote avec les documents disponibles à cette date. Un script d'ingestion existait pour ajouter de nouveaux fichiers, mais il fallait le lancer à la main et personne n'en avait la charge après le départ du développeur.
En quatorze mois, le bureau d'études avait publié une vingtaine de bulletins de service, dont plusieurs modifiaient des compatibilités de pièces. Deux références avaient été retirées du catalogue. L'assistant répondait donc avec sérieux et avec des sources, mais les sources dataient de l'année précédente. Le cas du distributeur qui avait monté une pièce incompatible venait de là : la fiche technique récupérée était exacte à sa date de rédaction, et fausse au moment de la question.
Une réponse sourcée n'est pas une réponse juste si la source est périmée. Un système RAG n'a aucune notion de validité temporelle tant qu'on ne la lui donne pas. Les mécanismes en jeu, et ce qu'ils coûtent quand on les découvre tard, rejoignent les coûts cachés de la maintenance d'un RAG.
La correction a consisté à brancher l'ingestion sur le dépôt documentaire officiel avec une exécution planifiée, à ajouter une date de validité et un statut (en vigueur, remplacé, retiré) sur chaque document, et à exclure de la recherche tout document dont le statut n'est plus « en vigueur ».
Diagnostic deux : une version de modèle avait changé
La deuxième famille de réponses, celles dont le style avait changé, avait une cause que les journaux ont rendue visible en quelques minutes. L'identifiant du modèle appelé n'était pas figé dans la configuration. Le code demandait la version « la plus récente » d'une famille de modèles chez le fournisseur. Neuf mois après le pilote, le fournisseur a fait pointer cet alias vers une nouvelle génération.
Le nouveau modèle n'était pas moins bon, il était différent. Il complétait volontiers une réponse quand les extraits fournis étaient incomplets, et respectait moins les consignes de concision calibrées sur l'ancien. Le prompt qui fonctionnait avec la version précédente produisait maintenant des réponses qui ajoutaient des précisions plausibles mais non documentées. Sur des couples de serrage ou des références de pièces, une précision plausible est une erreur.
Personne n'avait été informé, parce que personne ne surveillait. Aucune alerte n'était configurée et aucun indicateur de qualité n'était suivi. Sur la question plus large de la surveillance de ces glissements, nous renvoyons à notre article sur la supervision des agents IA en entreprise.
La correction a été simple à écrire et importante à tenir dans le temps : le modèle est désormais appelé par sa version exacte, jamais par un alias. Tout changement de version passe par une exécution du jeu d'évaluation décrit plus bas, et par une validation humaine avant bascule. Les dates de fin de support annoncées par le fournisseur sont suivies pour planifier les migrations avant qu'une version ne soit retirée.
Diagnostic trois : un prompt retouché sans test
La troisième famille, celle où l'assistant tranchait face à des extraits contradictoires, nous a pris plus de temps. L'historique du prompt système montrait une modification faite sept mois plus tôt par le développeur interne. Le prompt initial demandait de signaler explicitement toute contradiction entre les sources. Des techniciens avaient trouvé ces signalements agaçants. Le développeur avait retiré la consigne et ajouté une instruction demandant de « privilégier la réponse la plus utile ».
La modification avait été faite directement dans l'environnement de production, sans jeu de tests, sans relecture, et sans note dans un journal des changements. Elle avait réglé le symptôme du moment et retiré le seul garde-fou qui empêchait l'assistant de choisir arbitrairement entre deux sources. Combinée à la base périmée du diagnostic un, cette retouche produisait exactement le cas du distributeur : une notice ancienne et un bulletin récent en désaccord, et un assistant qui choisit l'ancienne parce qu'elle est plus détaillée.
Un prompt est du code. Il a le même besoin d'historique, de revue et de tests qu'une fonction métier. Une retouche anodine change le comportement du système sur des milliers de questions que personne n'a relues.
Les garde-fous posés : citations obligatoires, seuil de confiance, refus explicite
Une fois les trois causes traitées, la question était de rendre le système robuste à la prochaine dérive, quelle qu'elle soit. Nous avons posé trois garde-fous, qui ne dépendent ni du modèle ni de la base.
Citations obligatoires. Chaque affirmation technique dans une réponse doit renvoyer à un extrait précis d'un document en vigueur, avec sa référence et sa date. Une phrase qui ne peut pas être rattachée à un extrait récupéré est supprimée de la réponse avant affichage. Ce contrôle est fait par une vérification programmée en sortie, pas par une consigne dans le prompt. Le modèle peut ignorer une consigne, il ne peut pas contourner un filtre.
Seuil de confiance. Le système calcule pour chaque question un score de pertinence des extraits récupérés. En dessous d'un seuil fixé avec les techniciens, l'assistant ne produit pas de réponse rédigée. Il affiche les documents les plus proches et invite à les consulter. Une réponse hésitante vaut mieux qu'une réponse fausse quand un distributeur va démonter une machine.
Refus explicite. Quand deux extraits en vigueur se contredisent, ou quand la question porte sur une référence absente de la base, l'assistant le dit en clair et propose de créer une demande vers le bureau d'études. Ces demandes sont comptées et servent d'indicateur des trous dans la documentation.
Ces trois mécanismes ont un coût : environ une question sur huit n'obtient plus de réponse rédigée. Les techniciens ont préféré cette version, et l'usage de l'outil est reparti à la hausse.
Le jeu d'évaluation enrichi des cas fautifs
Aucun garde-fou ne tient sans moyen de mesurer. Le pilote initial avait été validé sur une cinquantaine de questions posées par les techniciens, sans réponses de référence écrites. Cette validation était impossible à rejouer.
Nous avons construit un jeu d'évaluation à partir de trois sources. Les questions du pilote, pour lesquelles un technicien senior a rédigé la réponse attendue et les documents qui la justifient. Les trois cents échanges de l'échantillon analysé, dont chaque réponse fautive est devenue un cas de test avec la bonne réponse. Et une série de questions pièges construites exprès : références retirées du catalogue, pièces homonymes entre deux gammes, questions dont la réponse a changé entre une notice et un bulletin.
Ce jeu est exécuté automatiquement à chaque modification du prompt, à chaque changement de version du modèle, et une fois par semaine sans modification, pour détecter une dérive silencieuse côté fournisseur ou une ingestion défectueuse. Le résultat est un tableau simple : taux de réponses correctes, taux de refus justifiés, taux de refus injustifiés, et liste des cas qui ont changé de statut depuis la dernière exécution. Un cas qui passait et qui échoue déclenche une revue avant toute mise en production.
Chaque nouvelle erreur signalée par un technicien entre dans le jeu. Il grossit donc avec l'usage, et la même erreur ne peut pas revenir sans être détectée.
Ce qui a été écrit dans le contrat pour que cela ne se reproduise pas
La partie technique représentait moins de la moitié du problème. L'assistant s'était dégradé parce que personne n'en avait la responsabilité écrite. Le prestataire avait livré, le développeur interne était parti, et l'outil vivait seul. Un système qui appelle un modèle externe et lit une base documentaire vivante n'est pas une livraison, c'est un service qui demande une supervision continue.
Le contrat de maintenance signé ensuite couvre des points précis. La supervision permanente des indicateurs de qualité et des coûts d'appel au modèle, avec des alertes qui arrivent avant que les techniciens ne signalent un problème. L'exécution planifiée du jeu d'évaluation et la revue de ses résultats. Le suivi des versions du modèle et des annonces de fin de support, avec une migration testée avant toute dépréciation. La remise à niveau du RAG et des prompts à intervalle fixé, dans le cadre d'une maintenance applicative supervisée, qui inclut le nettoyage de la base, la vérification des statuts de documents et la revue du prompt système au regard des cas d'évaluation les plus récents. Un rapport d'activité régulier, lisible par la direction, qui dit ce qui a été surveillé, ce qui a changé et ce qui a été corrigé.
Deux clauses ont compté pour la direction générale. D'abord, le code, les prompts, le jeu d'évaluation et les accès restent la propriété de l'entreprise et sont hébergés chez elle, avec une documentation qui permet à un autre intervenant de reprendre l'ensemble. Ensuite, les engagements de réactivité sont écrits, définis au contrat après l'audit initial, et non laissés à l'appréciation du prestataire du moment.
Ce sont des pratiques ordinaires de maintenance logicielle, appliquées à un système dont le comportement dépend de trois choses qui bougent sans prévenir : les documents, le modèle et le prompt. Le sujet de fond, pour un dirigeant, n'est pas de savoir si son IA hallucine. C'est de savoir qui regarde, avec quels indicateurs, et ce qui se passe le jour où un chiffre change. Nous détaillons cette approche dans notre page consacrée à l'industrialisation des systèmes IA, et dans notre guide sur ce qu'il faut surveiller après la mise en production.
