L’IA se trompe sans le savoir. Voici comment on s’en protège.

Voici le problème, en une phrase : un modèle qui se trompe a exactement le même ton qu’un modèle qui a raison. Il n’y a aucun signal dans la réponse. C’est ce qui rend l’erreur dangereuse sur un document technique — et c’est ce que trois travaux mesurent.

Un : les modèles généralistes se trompent beaucoup sur du contenu réglementé

La mesure de référence vient d’une équipe de Stanford, publiée en 2024 dans le Journal of Legal Analysis. Sur des tâches juridiques — un domaine proche du nôtre par sa nature : texte normatif, référence à des sources, conséquence en cas d’erreur — les auteurs établissent que les modèles « hallucinate at least 58% of the time », avec une fourchette allant de 58 % pour ChatGPT 4 à 88 % pour Llama 2.

Le chiffre frappe, mais le plus important est la suite de la phrase : ces modèles « struggle to predict their own hallucinations ». Un système qui se trompe et qui le sait est gérable. Un système qui se trompe avec la même assurance que lorsqu’il a raison ne l’est pas.

Deux : les systèmes spécialisés réduisent l’erreur, sans l’annuler

La même équipe a évalué, en préenregistrant son protocole, les outils de recherche juridique assistée par intelligence artificielle de LexisNexis et Thomson Reuters — c’est-à-dire des systèmes professionnels, adossés à des bases documentaires, exactement l’architecture que nous défendons.

Le résultat est à deux faces, et il faut tenir les deux. D’un côté : « hallucinations are reduced relative to general-purpose chatbots ». La spécialisation marche, c’est mesuré. De l’autre : ces outils « hallucinate between 17% and 33% of the time », alors que leur communication promettait l’absence d’hallucination. Les auteurs écrivent que « the providers’ claims are overstated ».

Nous en tirons une règle interne simple : nous ne promettrons jamais un système sans erreur. Ce serait une promesse déjà réfutée par la littérature, et un architecte qui le vérifie aurait raison de ne plus nous croire sur le reste.

Un modèle qui se trompe a exactement le même ton qu’un modèle qui a raison. C’est ce qui rend l’erreur dangereuse sur un document qui part en consultation.

Trois : une réponse fluide n’est pas une réponse étayée

Reste le mécanisme qui rend ces erreurs dangereuses en production : elles ne se voient pas. Une étude présentée aux Findings de l’EMNLP 2023 a audité des moteurs de recherche génératifs, source par source. Le rappel de citation y est de 51,5 % — la moitié des phrases produites ne sont pas entièrement étayées par les sources affichées — et la précision de citation de 74,5 %, soit un quart de citations qui ne soutiennent pas l’affirmation à laquelle elles sont rattachées. Les réponses, elles, sont décrites comme « fluent and appear informative ».

C’est le découplage qu’il faut avoir en tête quand un CCTP généré « a l’air bien ».

Et dans notre métier précisément ?

Un travail d’évaluation dédié au secteur de la construction, AECBench, teste neuf modèles sur vingt-trois tâches issues de la pratique, rédigées et relues par des ingénieurs. Deux résultats nous concernent directement. Sur l’interprétation des tableaux des codes de construction, l’exactitude moyenne se situe autour de 40 à 45 % — or c’est exactement la matière d’un CCTP. Et sur la génération de documents spécialisés du bâtiment, les auteurs constatent que « all models failed to surpass the 60-point threshold » : aucun des neuf modèles évalués ne franchit la barre.

Là encore, la nuance s’impose : c’est une prépublication, l’évaluation repose en partie sur un jugement automatique, et le panel de modèles testés n’est pas exhaustif. Le signal n’en est pas moins clair et convergent avec le reste.

Comment nous avons réglé ce problème dans les infrastructures que nous livrons

Si le taux d’erreur ne tombe pas à zéro, et s’il ne se voit pas à la lecture, alors la protection ne peut pas être « faire attention ». Elle doit être structurelle. Nous en tirons trois règles, appliquées dans toutes nos installations.

Chaque élément dit d’où il vient. Une hauteur relevée en coupe sort avec le numéro de la coupe. Un ouvrage identifié sort avec la planche dont il est tiré. Un prix sort avec la ligne de DPGF ou le devis d’origine. La relecture porte alors sur les points incertains au lieu de tout revérifier — c’est-à-dire qu’elle a lieu vraiment.

Ce qui n’est pas prouvé est signalé, pas deviné. Une démolition ferme repose sur une pièce du dossier ; un ouvrage neuf projeté ne prouve pas qu’un existant est à démolir. Un diagnostic amiante ou plomb n’est jamais déduit. Sans preuve, l’infrastructure écrit « à confirmer » — et c’est une réponse acceptable, contrairement à une affirmation fausse énoncée avec aplomb.

Le producteur n’est jamais le relecteur. Chaque exécution passe par un agent de contrôle distinct, avec ses propres critères et une condition d’arrêt écrite. C’est la conséquence directe du résultat le plus utile de tout cet article : un modèle ne sait pas prédire ses propres erreurs, donc il ne peut pas être son propre correcteur.

Aucune de ces trois règles ne fait tomber le taux d’erreur à zéro. Ensemble, elles font qu’une erreur est visible — ce qui est la seule chose qui compte quand un document part en consultation.

Ce que cet article ne dit pas : il n’existe aucune mesure publiée du taux d’erreur d’un système d’intelligence artificielle sur des pièces écrites françaises. Ni pour nous, ni pour personne. Tout ce qui précède raisonne par analogie avec des domaines voisins.