L'avertissement dit de vérifier les résultats. Aucun produit ne vous donne les outils pour le faire.
Un article très partagé soutient que tous les grands outils d'IA reconnaissent faire des erreurs, puis ne proposent aucune interface pour les repérer. Les correctifs qu'il propose relèvent pour l'essentiel de l'interface utilisateur.
Trois avertissements, une fonctionnalité manquante
Gemini affiche « AI can make mistakes, so double-check responses ». Claude affiche « Claude is AI and can make mistakes. Please double-check responses. » ChatGPT affiche « ChatGPT can make mistakes. Check important info. » Tous trois en petits caractères gris, en bas de la zone de saisie.
Dans un article publié le 27 septembre 2026, le développeur qui signe Glyph prend ces phrases au pied de la lettre et pose la question qui s'impose : si la vérification des résultats est une étape obligatoire du flux de travail, où est l'interface qui permet de la faire ? Sa réponse est qu'il n'y en a pas, et que ces avertissements servent à transférer la responsabilité juridique plutôt qu'à concevoir un produit. Sa conclusion est tranchante : un outil qui vous demande de vérifier son travail sans vous offrir le moindre moyen de suivre cette vérification s'apparente, selon lui, davantage à une escroquerie qu'à un produit. Il étend la même critique à Ollama, l'outil d'exécution de modèles en local, qui aurait selon lui davantage besoin de ces fonctionnalités que les grands laboratoires, puisque les modèles qu'il fait tourner sont moins performants.
À quoi ressemble concrètement l'interface proposée
Les détails comptent plus que la polémique, car la plupart des propositions concernent l'interface utilisateur et non les modèles.
Pour le chat, il propose une feuille de travail à deux colonnes : la réponse du modèle à gauche, un champ de notes humaines à droite consignant le travail effectué pour vérifier chaque affirmation, et une case à cocher que l'on ne coche qu'une fois la vérification jugée faite. Pour les assistants de code, il soutient que l'absence d'un tel dispositif reporte la vérification sur la revue de code, ce qui permet à l'auteur nominal de soumettre une pull request qu'il n'a jamais lue.
Pour la recherche, l'inversion est plus radicale. Aujourd'hui, les citations apparaissent sous forme de minuscules annotations dans le texte, avec un nom de domaine et une icône de moins de 16 pixels. Il veut que la citation devienne l'objet principal : date de publication, nom de l'auteur lorsqu'il est disponible et citation littérale non modifiée, extraite par un programme ordinaire et non par le modèle, affichée plus grand que tout ce que l'IA a écrit. Le résumé généré est relégué dans le petit texte gris qu'occupe actuellement l'avertissement.
Il vaut la peine d'éclaircir le jargon. Le RAG, ou génération augmentée par la récupération (retrieval-augmented generation), est la technique standard dans laquelle un système cherche d'abord dans des documents, puis fournit les résultats au modèle comme contexte. Le grounding (ancrage) est le terme employé par les éditeurs pour désigner le fait de relier la sortie à ces sources récupérées. Glyph concède que ces petits liens de citation renvoient bien à de véritables structures du pipeline, et non à des jetons inventés. Son argument est qu'un modèle peut tout de même déformer un texte récupéré, comme il déforme n'importe quoi d'autre, et que la présentation ne doit donc jamais paraître faire autorité.
Notion voisine : la provenance. Lorsqu'un chatbot affiche un tableau de données, une partie provient mécaniquement d'une API ou d'un appel d'outil, et une partie est produite par le modèle. Les deux sont présentées de manière identique. Il veut qu'elles soient visuellement séparées, avec en plus une passe où les nombres sont traités comme dans un tableur et vérifiés par de l'arithmétique ordinaire, calculs à l'appui.
Ce qui est vraiment nouveau et ce qui est déjà connu
Peu de ces idées exigent une percée dans les modèles, et c'est la force de l'argument. Cartes de citation, cases à cocher, mise en forme de la provenance et vérification arithmétique relèvent du travail sur le « harness », c'est-à-dire le logiciel qui enveloppe le modèle, et pourraient être livrées dès aujourd'hui avec les modèles actuels, sans les modifier.
Deux propositions exigent en revanche la coopération des laboratoires. Interdire la première personne et les excuses dans les sorties est une modification du comportement du modèle ; il soutient que les propres affirmations des laboratoires sur leurs benchmarks prouvent qu'ils savent contrôler très finement les sorties. Quant à l'exposition de la température, le curseur d'aléatoire qui détermine la variété des réponses d'une exécution à l'autre, il la soulève mais la nuance aussitôt, en notant que la fixer à zéro ne produit pas simplement des résultats fiables. La section sur la reproductibilité est la partie la moins développée de l'article.
La critique de MCP va à contre-courant de la direction actuelle de l'industrie. Le Model Context Protocol permet aux chatbots d'appeler des outils externes et d'entreprendre des actions. L'objection de Glyph : si la saisie en langage naturel est assez imprécise pour exiger des clarifications constantes, accorder à ce même système des pouvoirs destructeurs est une erreur de logique. Il préférerait des boutons dédiés à des tâches précises, par exemple une commande spécifique pour analyser une base de code à la recherche des vulnérabilités du OWASP Top 10, reposant sur des modèles plus petits entraînés pour cet usage.
Questions à vous poser
- Si nos équipes sont tenues de vérifier les résultats de l'IA, où cette vérification est-elle consignée dans nos outils, et pouvons-nous produire cette trace si une affirmation que nous avons diffusée se révèle fausse ?
- Demandez directement à votre fournisseur : quel pourcentage des citations affichées dans votre interface renvoie à un texte que l'utilisateur peut lire sans modification, plutôt qu'à une paraphrase rédigée par le modèle ?
- Combien de nos pull requests fusionnées ont été rédigées par un assistant puis relues par quelqu'un qui supposait que l'auteur avait déjà vérifié ?
- Lorsqu'un tableau apparaît dans une réponse de chat, quelqu'un dans l'équipe peut-il dire quelles cellules proviennent d'un appel d'API et lesquelles viennent du modèle ?
- Achetons-nous l'accès agentique à des outils parce qu'il résout un problème que nous avons, ou parce que c'est ce que les éditeurs vendent en ce moment ?
À surveiller ensuite
Le signal à guetter est l'emplacement de l'avertissement. Si un grand éditeur fait passer la vérification d'un jargon juridique en gris à un élément d'interface fonctionnel, qu'il s'agisse d'une case à cocher, d'une carte de citation ou d'un marqueur de provenance, cela signifiera qu'il assume la responsabilité de conception du taux d'erreur au lieu de la déléguer à l'utilisateur. Tout le reste de ce débat découle de ce seul choix.
- 1Tenez un journal de vérification distinct : collez chaque affirmation de l'IA avec le lien vers sa source et un indicateur vérifié/non vérifié, car aucun chatbot ne suit cela pour vous.
- 2Demandez au modèle de lister toutes les affirmations factuelles qu'il a faites sous forme de liste de contrôle numérotée, puis cochez-les une à une en les confrontant à des sources primaires.
- 3Considérez toute sortie d'IA dont vous n'avez pas vous-même vérifié la source comme une hypothèse de travail, et ne la transmettez jamais à des collègues ou à des clients sans l'avoir signalée comme telle.
Ready to implement AI in your business?
Our team builds the AI systems you just read about. Start with a free 30-minute discovery meeting.
