Six concepts d’IA qui vous indiquent ce à vérifier avant de faire confiance à une réponse

Vous remettez un rapport à un assistant IA et vous recevez un résumé soigné qui inclut un graphique que l’on ne trouve nulle part dans le document. Lorsque vous demandez des explications, l’assistant s’excuse et propose un autre graphique. Fallait-il de l’information manquante, la récupération a-t-elle échoué, ou ce chiffre a-t-il simplement été inventé ? Six concepts fondamentaux, compris en fonction des décisions qu’ils influencent, vous permettent de remplacer la question « Pourquoi ment-il ? » par une question diagnostique précise ; ils vous aident également à contrôler les coûts et à évaluer les affirmations des fournisseurs.

Pourquoi le scepticisme est une attitude raisonnable par défaut

La méfiance envers les résultats générés par l’IA est courante, même chez ceux qui l’utilisent tous les jours. Selon l’enquête Stack Overflow Developer Survey de 2025, 46 % des répondants à la question concernant l’exactitude ont déclaré ne pas faire confiance aux résultats de l’IA, contre 33 % qui y croyaient, sur un total de 33 244 réponses (résultats de l’enquête). Lisez bien ceci : elle recueille les opinions des développeurs, et non une mesure de l’exactitude du modèle, et elle ne constitue pas un échantillon représentatif de la population. Elle reflète cependant une tension réelle : les gens adoptent ces outils sans pour autant croire en tout ce qu’ils disent.

Tout d’abord, appliquez la même rigueur aux titres

Le contenu sur l’IA promet souvent qu’apprendre quelques termes suffit pour se placer « devant 90 % des gens ». On dirait un résultat de recherche, mais en l’absence d’étude à l’appui, il s’agit de marketing déguisé en statistique. Posez-vous les questions évidentes : devant qui ? Comment est-ce mesuré ? Avec quels participants ? Où sont publiés les résultats ? Aucune évaluation, aucun échantillon, aucune donnée signifie que ce pourcentage n’est pas fondé. Cela ne rend pas fausses toutes les explications qui l’accompagnent, et cela n’indique rien sur les intentions de quiconque ; cela signifie simplement que ce chiffre n’a aucune valeur.

Connaître les définitions est un point de départ. Les appliquer, reconnaître les exceptions et vérifier les résultats réels sont des compétences distinctes, et aucune d’entre elles n’est mesurée par un pourcentage flatteur.

La même discipline s’applique aux promesses selon lesquelles une seule requête peut remplacer toute une équipe, ou que certains outils multiplient par dix la vitesse de travail de chacun. Demandez la tâche spécifique, les critères de référence, la manière dont elle a été mesurée et quels en ont été les limites. Une démonstration impressionnante ne suffit pas à établir un résultat général. Un titre accrocheur est acceptable ; les problèmes commencent lorsque l’affirmation est plus précise que les preuves qui la soutiennent. Appliquez ce guide selon les mêmes critères.

1. Tokens : la véritable taille d’une tâche

Un token est l’unité de texte que le modèle linguistique traite réellement. Selon le tokeniseur, un token peut être un mot entier, un fragment de mot, un signe de ponctuation ou tout autre élément de texte, et le tokeniseur associe chaque élément à un ID numérique.

Il n’existe pas de règle fixe du type « un mot équivaut à un token ». La présentation générale des outils de tokenisation d’Hugging Face décrit plusieurs approches, notamment l’encodage par paires de bytes, WordPiece et des méthodes liées à SentencePiece ; la même phrase peut donc être divisée de manières très différentes selon les outils utilisés. Les langues autres que l’anglais, le code ainsi que les formats inhabituels utilisent souvent davantage de tokens par mot.

L’importance de ce facteur devient évidente avec une question comme celle-ci :

Quelles sont les trois plaintes des clients qui se sont produites le plus souvent ?

La question elle-même est très courte. Mais si y répondre signifie lire des milliers de messages d’assistance, cette question représente une erreur d’arrondi dans la quantité totale de données à traiter. À titre d’illustration approximative : 400 messages, chacun comptant environ 150 tokens, donnent déjà un total de 60 000 tokens avant même d’inclure des instructions ou tout autre contexte.

La question importante n’est donc pas la longueur de votre demande, mais la quantité de matériel que la tâche oblige le système à traiter. Comme les prix, les délais de réponse et les limites de contexte sont généralement exprimés en tokens, c’est également ce qui détermine le coût. Avant de traiter un document volumineux, supprimez les signatures d’e-mail répétées, les annexes irrelevantes et les enregistrements dupliqués qui ne fournissent aucune preuve, tout en conservant tout ce dont la réponse dépend réellement.

2. Fenêtre de contexte : ce que le modèle peut voir dans une seule demande

La fenêtre de contexte limite la quantité de matériel avec laquelle un modèle peut travailler dans une seule demande. Les instructions du système, l’historique de la conversation, les extraits récupérés et tous les autres éléments d’entrée consomment cette capacité ; la manière dont les tokens de sortie y sont comptabilisés dépend du modèle et de l’API. La documentation de Google sur les grands contextes montre comment des fenêtres plus larges permettent de travailler avec de grandes collections de texte et d’autres médias.

Accepter un document n’est cependant pas la même chose que faire usage de manière fiable de chaque détail pertinent qu’il contient. L’étude de 2023 intitulée « Lost in the Middle » a testé la réponse à des questions sur plusieurs documents ainsi que la récupération de données de type clé-valeur et a constaté que, pour les modèles examinés, la précision diminuait souvent lorsque les informations pertinentes se trouvaient au milieu d’une entrée longue plutôt qu’au début ou à la fin. Considérez cela comme une preuve historique de ces expériences spécifiques, et non comme un indicateur pour les modèles d’aujourd’hui, mais la leçon concernant la vérification reste valable.

Les produits de chat se comportent également rarement comme l’indique leur interface. Lorsqu’une conversation dépasse la taille de la fenêtre, une application n’est pas obligée d’effacer simplement les messages les plus anciens ; elle peut plutôt en résumer le contenu, sélectionner ou récupérer des éléments antérieurs. Ce que vous voyez dans l’historique de la conversation n’est pas une représentation fiable de ce qui parvient au modèle à chaque appel.

En pratique :

• Pour les tâches longues, conservez un résumé court et explicite des exigences et décisions actuelles, et le reformulez lorsque c’est nécessaire.
• Lorsqu’une conclusion dépend d’un passage précis, demandez à l’assistant de citer ou de localiser ce passage avant de tirer une conclusion.

Une fenêtre plus grande donne au système de la marge pour travailler ; cela ne prouve pas pour autant que le système a utilisé les bonnes preuves.

3. Température : contrôle de la variété, non de la vérité

À chaque étape de génération, le modèle évalue tous les tokens possibles suivants. La température modifie la distribution de probabilité utilisée pour sélectionner parmi ces évaluations : des valeurs basses concentrent les probabilités sur les candidats les plus probables, tandis que des valeurs élevées les répartissent sur davantage d’options. Hugging Face décrit la température en même temps que d’autres paramètres de génération tels que l’échantillonnage top-p et le décodage gourmand.

Le raccourci tentant est que « une température basse signifie des réponses factuelles ». Ce n’est pas le cas. Si la réponse la plus probable du modèle est fausse, rendre les réponses moins variées ne pourra pas fournir le fait manquant ; cela ne fera qu’accentuer de manière plus constante la même erreur. De même, augmenter la température ne garantit pas de meilleures idées, seulement des idées plus variées.

Deux tâches contrastées montrent la différence. Générer cinq noms pour un café fictif bénéficie de la variété. Extraire des numéros de facture bénéficie d’un formatage cohérent, mais ces numéros doivent encore correspondre aux factures réelles, et la température n’a aucun impact sur ce point.

Considérez la température comme un paramètre à expérimenter, en l’évaluant par rapport aux besoins réels de la tâche. Pour l’extraction, comptez les champs erronés ou manquants ; pour la génération d’idées, vérifiez si celles-ci sont à la fois utilisables et véritablement différentes les unes des autres. La prévisibilité et la correction nécessitent des vérifications distinctes.

4. Hallucination : résultats dépassant les preuves fournies

Ici, une hallucination désigne du contenu généré qui est fabriqué de toutes pièces, factuellement incorrect ou non étayé par le matériel qu’il prétend décrire. Un ton assuré rend plus difficile son identification, mais l’assurance n’est pas une partie de la définition ; une phrase prudente peut tout aussi bien être dénuée de fondement.

Un article de recherche inventé en est un exemple évident. Un cas plus subtil et courant concerne un article réel cité pour un résultat qu’il n’a jamais rapporté, et qui passe inaperçu à première vue précisément parce que la citation existe.

Le benchmark TruthfulQA a introduit 817 questions réparties en 38 catégories, basées sur des idées fausses courantes. Lors de l’évaluation initiale, le meilleur modèle testé a donné des réponses exactes pour 58 % des questions, contre 94 % chez les humains. Il s’agit de résultats historiques issus de recherches menées en 2021 et 2022, qui ne mesurent pas les performances des chatbots actuels ni un taux universel d’hallucinations. Ce travail montre cependant que les modèles peuvent reproduire fidèlement des croyances fausses présentes dans des textes écrits par des humains.

Lorsqu’un résumé contient un chiffre surprenant, demandez explicitement son origine :

Indiquez le passage source, sa date ainsi que la population qu’il concerne. Si le passage ne soutient pas ce chiffre, marquez-le comme non étayé.

Vérifiez ensuite la référence de vos propres yeux. Toute citation produite par un modèle n’est qu’une affirmation tant que vous n’avez pas confirmé à la fois l’existence de la page et le fait qu’elle contienne réellement la phrase en question.

5. RAG : récupération de preuves avant réponse

La génération augmentée par la récupération associe une étape de recherche à une étape de génération. Le système cherche du matériel pertinent dans une collection externe, le transmet au modèle et lui demande de répondre à partir de ce matériel.

L’étude influente sur RAG publiée en 2020 a combiné un générateur préentraîné avec un outil de récupération sur un index de Wikipédia, et lors de sa publication, a obtenu les meilleurs résultats connus sur trois benchmarks de Q&A dans un domaine ouvert. Ces résultats décrivent un système de recherche spécifique, et non une garantie de qualité pour tous les produits portant l’étiquette RAG.

Imaginons qu’un employé demande combien de jours il lui faut pour déposer une demande de remboursement. Un bon système récupère la politique en vigueur et y trouve la réponse. S’il récupère plutôt la politique de l’année précédente, une rédaction soignée ne pourra pas corriger l’erreur ; la réponse sera fluide mais fausse. C’est pourquoi les pannes de RAG sont généralement plus faciles à diagnostiquer étape par étape qu’en se contentant d’examiner la réponse finale, une méthode abordée dans l’évaluation de RAG par étape d’erreur.

Deux idées reçues méritent d’être clarifiées :

• RAG ne dépend pas de la présence d’un stockage vectoriel spécialisé. L’étape de recherche peut consister en une correspondance classique par mots-clés, en une similarité d’embedding ou en un mélange des deux, et l’aperçu de RAG fourni par Microsoft examine ces options ainsi que l’importance de préparer le contenu afin qu’il puisse être recherché efficacement.

Télécharger un PDF ne prouve pas que la récupération des informations a eu lieu. Certains systèmes insèrent directement le contenu du document dans la fenêtre de contexte du modèle, comme l’explique la documentation sur les longs contextes de Google. La récupération d’informations et le traitement direct à long terme du contexte sont des choix de conception distincts, et un produit peut les combiner.

Pour évaluer tout assistant documentaire, posez deux questions séparées : a-t-il trouvé le passage approprié, et sa réponse reflète-t-elle fidèlement ce passage ?

6. Agents : systèmes qui choisissent leur prochain pas

Le terme « agent » est utilisé de manière large, il est donc utile d’établir une distinction claire. Le guide d’Anthropic pour créer des agents efficaces décrit les workflows comme des systèmes qui suivent des chemins de code prédéfinis, tandis que les agents permettent au modèle de diriger dynamiquement son propre processus et l’utilisation des outils.

Plus il y a d’étapes, plus les chances d’échec augmentent. À titre d’illustration simplifiée, si une tâche nécessite dix étapes et que chacune réussit de manière indépendante avec une probabilité de 95 %, la probabilité que toutes les dix réussissent est 0,95 à la puissance dix, soit environ 60 %. En pratique, les étapes d’un agent dépendent les unes des autres et les tentatives répétées modifient les calculs ; il s’agit donc d’une intuition sur le risque cumulé plutôt que d’un critère de référence. La conséquence pratique est de vérifier si toute la tâche a été accomplie correctement, y compris ses effets secondaires, et non si les étapes individuelles semblent plausibles. Pour une analyse plus approfondie du cycle en lui-même, consultez comprendre les agents IA : objectifs, outils, mémoire et le cycle de l’agent.

Une liste de contrôle de six questions pour les tâches réelles

Chaque concept correspond à une question que vous pouvez poser pour toute tâche réelle :

• Tokens : quelle quantité de matériel ce travail exige-t-il réellement du système pour être traité, et qu’est-ce qui peut être supprimé sans perdre des éléments de preuve ?
• Fenêtre de contexte : sur quel passage l’ réponse s’appuie-t-elle, et le système l’a-t-il vraiment utilisé ?
• Temperature : ce travail concerne-t-il la variété ou la cohérence, et la justesse ainsi que la prévisibilité ont-elles été vérifiées séparément ?
• Hallucination : où se trouve exactement la source de chaque affirmation surprenante, et indique-t-elle bien ce que l’ réponse prétend faire ?
• RAG : le document correct et à jour a-t-il été récupéré, et a-t-il été représenté avec précision ?
• Agents : que peut faire le système, et le travail dans son intégralité, y compris ses effets secondaires, a-t-il été accompli correctement ?

Conclusion

Testez ces questions sur une tâche réelle unique, comme un résumé de document, une modification de code ou une réponse au service client, en ayant le matériel source ouvert à côté de vous. Distinguez les éléments sur lesquels il s’est appuyé, les conclusions qu’il a tirées de lui-même et les actions qu’il a réellement effectuées. Faire cela de manière constante révèle davantage sur la fiabilité d’un outil que n’importe quelle démonstration ou statistique médiatique, et il transforme une méfiance vague en problèmes spécifiques et corrigeables : des entrées trop volumineuses, des passages manquants, un document incorrect, une figure non prise en charge ou un agent disposant d’une trop grande marge de manœuvre.