En bref : sur le GID Assistant, la recherche documentaire se terminait à 26,21 secondes alors que l'interface coupait à 25,00. Résultat : l'assistant répondait de mémoire, avec une réponse plausible, un statut de succès et aucun signal visuel indiquant qu'aucun document n'avait été lu. La preuve du défaut est une confusion entre IfcPipeFitting et IfcPipeSegment selon la phase. La règle retenue pour tout l'écosystème est simple : le budget de temps côté client doit être strictement supérieur au plafond côté serveur, jamais égal.
Le cas exact, avec ses chiffres
Un utilisateur pose une question sur les propriétés attendues par une fiche GID à une phase donnée. La chaîne de recherche documentaire part, interroge la base, remonte les extraits pertinents et rend la main à 26,21 secondes. Sauf que l'interface, elle, avait cessé d'attendre à 25,00 secondes exactement, et avait déjà basculé sur un mode de repli qui laisse le modèle répondre sans document.
L'écart tient en 1,21 seconde. Sur deux appels consécutifs mesurés dans les journaux, la réponse documentaire arrivait bien, complète et correcte, mais après que l'écran ait renoncé à l'attendre. L'utilisateur ne voyait rien de tout cela. Il voyait une réponse, formulée avec le même aplomb qu'à l'ordinaire, dans le même format, avec le même temps de réaction apparent.
Ce n'est pas un bug spectaculaire. C'est un bug de bordure, du genre qui ne se déclenche que quand la base est un peu chargée, et qui reste invisible tant que personne ne recoupe la réponse avec la source. C'est précisément ce qui le rend intéressant.
Pourquoi le repli est-il plus dangereux qu'une erreur franche ?
Une erreur franche se voit. Un message d'échec, un écran vide, une exception affichée : l'utilisateur sait qu'il n'a pas obtenu ce qu'il demandait, et il recommence ou il cherche ailleurs. Le coût est de quelques minutes.
Le repli silencieux ne se voit pas. La requête est comptée comme un succès dans les journaux, la réponse est plausible parce qu'un modèle généraliste connaît suffisamment le vocabulaire IFC et la logique ISO 19650 pour produire quelque chose de crédible, et aucun élément visuel ne distingue cette réponse d'une réponse sourcée. L'utilisateur repart avec une information qu'il croit adossée aux fiches GID officielles du CRTI-B, alors qu'elle vient d'une mémoire statistique.
Dans un métier normatif, l'écart de conséquence entre les deux situations est énorme. Une réponse manquante fait perdre du temps. Une réponse plausible et non sourcée entre dans un BEP, puis dans une exigence contractuelle, puis dans un contrôle de conformité, et elle n'est démentie qu'au moment où un tiers vérifie la source. C'est-à-dire trop tard.
La preuve la plus nette : IfcPipeFitting contre IfcPipeSegment
Le défaut aurait pu rester théorique. Il ne l'est pas, parce qu'il a produit une réponse vérifiablement fausse sur un point que les fiches GID tranchent explicitement.
En mode sourcé, sur une question de phase PDE, la réponse citait IfcPipeFitting, l'entité qui porte les accessoires de réseau. En mode de repli, sur la même famille de question mais en phase APD, la réponse partait sur IfcPipeSegment, l'entité qui porte les tronçons droits. Les deux entités existent, les deux sont légitimes en IFC, et une réponse qui cite la mauvaise reste parfaitement crédible pour quelqu'un qui n'a pas la fiche sous les yeux. C'est le type d'erreur qu'un coordinateur MEP repère au troisième contrôle de maquette, quand les propriétés attendues ne se trouvent pas sur les objets qu'on lui avait annoncés.
Cette confusion est le marqueur qui a permis d'identifier le problème comme systémique plutôt qu'anecdotique. Une IA qui lit vraiment la fiche ne se trompe pas d'entité, parce que la fiche nomme l'entité. Une IA qui reconstruit à partir de son entraînement se trompe exactement là, sur des distinctions fines qui varient selon le référentiel et la phase.
Comment détecter ce défaut dans votre propre outil ?
Si vous utilisez ou si vous déployez un assistant documentaire, en interne ou chez un éditeur, cinq points suffisent à savoir s'il peut vous mentir sans le dire. Gardez cette liste, elle se déroule en une demi-heure.
- Marqueur de source visible. L'interface indique-t-elle, sur chaque réponse, quels documents ont été effectivement consultés ? Pas une mention générique du corpus, une liste des extraits qui ont servi à cette réponse-là. Si la réponse ne porte aucune trace de sa source, vous ne pouvez pas distinguer les deux modes.
- Comportement en cas de dépassement de délai. Que fait l'outil quand la recherche documentaire n'a pas répondu à temps ? Refuser et le dire est un comportement sain. Répondre quand même en est un autre, et c'est celui qu'il faut identifier avant de faire confiance à l'outil. Posez la question à l'éditeur, la réponse est rarement dans la documentation.
- Écart entre le plafond client et le plafond serveur. C'est la cause racine du cas décrit ici. Si l'interface cesse d'attendre avant que la chaîne documentaire ait fini son travail, le mode dégradé se déclenche sur des requêtes qui auraient parfaitement abouti.
- Distinction visuelle du mode dégradé. Quand l'outil répond sans document, le dit-il autrement que par une ligne discrète en pied de réponse ? Une réponse non sourcée doit être visuellement différente, pas simplement annotée.
- Journalisation des refus. Les cas où l'outil n'a pas pu répondre sont-ils tracés et consultables ? Un outil qui n'enregistre que ses succès ne vous laissera jamais découvrir la fréquence réelle de son mode dégradé.
Ces cinq points ne testent pas la qualité du modèle, ils testent l'honnêteté du système autour du modèle. C'est la partie que les démonstrations commerciales ne montrent jamais, parce qu'elle ne se voit que quand quelque chose se passe mal.
La règle retenue pour tout l'écosystème
Le correctif tient en une phrase, et il vaut au-delà de ce cas particulier : le budget de temps accordé côté client doit être strictement supérieur au plafond appliqué côté serveur, jamais égal.
Deux valeurs égales semblent cohérentes sur le papier, et c'est exactement le piège. La latence du réseau, la sérialisation de la réponse et le rendu à l'écran s'ajoutent toujours au temps de traitement, donc une égalité stricte garantit statistiquement des replis sur les requêtes les plus lentes, c'est-à-dire les plus complexes, c'est-à-dire celles où la source documentaire compte le plus. Le défaut frappe précisément les questions les plus difficiles, ce qui est le pire profil possible pour un outil normatif.
La règle est appliquée sur les trois applications qui interrogent la base documentaire, et le comportement de repli a été supprimé sur les questions normatives : quand la chaîne documentaire n'a pas répondu, l'assistant le dit et refuse, il ne comble pas.
Les trois autres corrections invisibles
Le même passage a traité trois défauts qui ne se voient pas davantage à l'usage, mais qui portaient tous sur la même question de confiance.
Le quota est passé côté serveur. Le décompte des messages était tenu par le navigateur, donc modifiable depuis la console par n'importe qui sachant ouvrir les outils de développement. Il est désormais écrit par un compte de service, en deux compteurs, 20 messages par jour et 250 par mois en gratuit, 500 et 5 000 sous licence organisation. Le refus indique laquelle des deux périodes a bloqué, et la valeur retenue est le maximum entre le registre serveur et le miroir client, ce qui rend la manipulation locale inopérante.
Le filtre d'injection parle français. Les motifs de détection des tentatives de détournement d'instruction sont passés de 7 à 12, dont 5 spécifiquement francophones. Un filtre entraîné uniquement sur des formulations anglaises laisse passer les mêmes attaques rédigées en français, et l'audience de ces outils est très majoritairement francophone.
La liste blanche d'outils est réellement appliquée. Elle existait, elle était déclarée, et elle n'était pas vérifiée à l'exécution. Une déclaration de sécurité non appliquée est pire qu'une absence de déclaration, parce qu'elle crée une fausse assurance dans les revues.
Un point que je tiens à écrire clairement : la base documentaire elle-même n'a pas été touchée. Les données sont identiques, il n'y a eu ni ré-indexation, ni reclassement des résultats, ni changement de méthode de recherche. Tout ce qui précède porte sur les garde-fous autour de la recherche, pas sur sa qualité. Annoncer une amélioration du moteur documentaire serait faux, et ce serait particulièrement malvenu dans un article qui traite d'honnêteté des réponses.
Questions fréquentes sur les réponses d'IA non sourcées
Comment savoir si une réponse d'IA vient d'un document ?
Cherchez la trace des extraits effectivement consultés pour cette réponse précise, pas une mention générale du corpus. En l'absence de ce marqueur, aucune inspection visuelle ne permet de distinguer une réponse sourcée d'une réponse produite de mémoire : les deux ont le même ton, le même format et le même niveau de détail apparent.
Que fait le GID Assistant quand la base documentaire ne répond pas ?
Il le signale et refuse de répondre sur la question normative. Le comportement de repli, qui laissait le modèle répondre sans document, a été supprimé sur ce type de question.
Le quota IA est-il contournable ?
Non. Il était tenu par le navigateur, donc modifiable depuis la console. Il est désormais écrit côté serveur par un compte de service, en deux compteurs journalier et mensuel, et la valeur appliquée est le maximum entre le registre serveur et le miroir client.
Les données GID sont-elles officielles ?
Elles proviennent des fiches GID publiées par le CRTI-B pour le marché luxembourgeois. L'assistant les rend interrogeables en langage naturel, il ne les réinterprète pas et ne se substitue pas au référentiel publié.
Dans un métier normatif, un refus vaut mieux qu'une réponse non sourcée
Le réflexe de conception dominant, sur les assistants documentaires, est de toujours rendre une réponse. Un écran vide est perçu comme un échec produit, une réponse est perçue comme un service rendu. Sur des sujets généralistes, l'arbitrage se défend. Sur une question de conformité normative qui finira dans un BEP ou dans un contrôle de livraison, il est mauvais.
Ma position n'a pas bougé depuis ce cas : sur ces sujets, un outil qui refuse est plus utile qu'un outil qui comble. Le refus coûte trente secondes à l'utilisateur, qui va vérifier ailleurs. La réponse plausible et non sourcée coûte plusieurs semaines à tout le monde, et elle coûte surtout la confiance dans l'outil le jour où elle est démasquée. Si vous voulez éprouver le comportement décrit ici, posez au GID Assistant une question à laquelle les fiches GID ne répondent pas et regardez ce qu'il fait. C'est le test le plus court pour juger un assistant normatif, celui du sien comme celui d'un autre.
À propos de l'auteur.
Renaud Climent est BIM Coordinator MEP, plus de 10 ans de terrain au Luxembourg et en Belgique. Cursus complet CRTI-B (Bases, Référent, Modeleur, Coordinateur), formé Solibri, BIMcollab et Revit MEP, certifié en IA. Fondateur de BIMsmarter.eu, il code ses propres outils pour automatiser les tâches BIM chronophages. Contact : contact@bimsmarter.eu