Quand une IA oublie un détail d'un projet, elle devrait demander avant de se souvenir

Pourquoi un souvenir plausible reste une supposition

Un projet créatif repose sur de petites décisions : quel titre a été présélectionné, si le brouillon utilise la première ou la deuxième personne, ou quelle palette de couleurs l'utilisateur a choisie. Si l'assistant ne parvient pas à retrouver l'un de ces détails, une réponse fluide peut donner l'impression d'un souvenir fiable tout en introduisant discrètement un nouveau choix.

Le NIST définit la confabulation de l'IA générative comme incluant des contenus faux présentés avec assurance, ainsi que des résultats qui divergent de l'entrée ou la contredisent. Un détail de projet inventé correspond tout à fait à ce risque pratique : il peut être confondu avec une décision déjà prise. Le profil pour l'IA générative (Generative AI Profile) du NIST décrit ce mécanisme en termes généraux ; les conséquences sur le travail de projet présentées ici relèvent d'une déduction de conception et non d'une observation propre à un produit particulier.

Des recherches menées par OpenAI soutiennent également que les incitations d'évaluation courantes peuvent récompenser la supposition plutôt que la reconnaissance de l'incertitude. L'exemple cité concerne les réponses à des questions générales, mais la leçon de conception s'applique tout autant : un assistant ne devrait pas considérer une complétion qui semble sûre d'elle comme la preuve qu'un échange passé est disponible. Why language models hallucinate

Établir d'abord ce que l'assistant peut réellement voir

L'assistant devrait distinguer trois états : un détail visible dans la conversation actuelle, un détail récupérable à partir d'une source de projet accessible, et un détail qu'il ne peut pas vérifier. Ces états exigent des formulations différentes. Si le détail apparaît plus haut dans le fil actuel, l'assistant peut le citer ou le résumer et renvoyer à ce contexte. S'il a trouvé une note ou un document, il peut nommer cette source. Si aucune de ces options n'est disponible, il devrait le dire clairement.

Une déclaration d'incertitude utile est précise et délimitée : « D'après les informations du projet auxquelles j'ai accès, je ne peux pas vérifier quel titre vous avez choisi. » Cela ne sous-entend pas que l'utilisateur n'a jamais choisi de titre, que l'assistant a fouillé toutes les archives possibles, ou que le détail manquant n'existe pas. Ces nuances sont importantes, car l'incapacité à récupérer un document ne prouve pas que ce document n'a jamais été créé.

Le People + AI Guidebook de Google recommande d'expliquer les capacités et les limites pertinentes, et de concentrer les explications sur ce qui influe sur la compréhension et les décisions de l'utilisateur. Appliqué ici, ce principe oriente vers une brève déclaration sur le contexte disponible du projet, plutôt que vers une explication technique des mécanismes internes du modèle. Explainability + Trust

Demander la source utile la plus concise possible

Après avoir exposé le manque, posez une seule question ciblée. Par exemple : « Pourriez-vous coller la note ou me rappeler le titre que vous avez retenu ? » Si l'utilisateur dispose de plusieurs sources possibles, proposez une liste restreinte : « Était-ce dans le dernier brouillon, dans vos notes de projet ou dans une conversation précédente ? » L'objectif est de faciliter la récupération sans transformer une tâche créative de routine en interrogatoire.

Un schéma de réponse pratique est : « D'après les éléments auxquels j'ai accès, je ne peux pas confirmer la palette. Si vous partagez la note ou me rappelez les couleurs, je les utiliserai pour le prochain brouillon. » Cela identifie l'élément manquant, sollicite une preuve ou une confirmation, et explique ce qui se passera ensuite. Cela permet aussi de maintenir la dynamique : l'assistant peut continuer à travailler sur les parties non affectées de la tâche tout en laissant le choix incertain en suspens.

La clarification est utile lorsque l'information manquante modifie la réponse. Dans une étude sur le dialogue collaboratif, Testoni et Fernández ont constaté qu'une stratégie de clarification guidée par l'incertitude du modèle améliorait la réussite de la tâche dans leur exercice spécifique de dessin ; ils indiquent également que poser des questions a un coût. Cela plaide pour une approche mesurée : poser une question lorsque le détail absent du projet a son importance, et garder une question ciblée. Asking the Right Question at the Right Time

Ne mettre à jour qu'après confirmation de l'utilisateur

Une fois que l'utilisateur fournit une source ou confirme un détail, répétez l'élément confirmé sous une forme concise : « C'est noté : d'après la note que vous avez collée, le titre actuel est “Notes d'un petit jardin”. » Si la source indique quelque chose de légèrement différent, signalez l'incohérence au lieu de choisir arbitrairement. Par exemple : « Votre note indique “Notes de jardin” ; vous venez de dire “Notes d'un petit jardin”. Lequel dois-je utiliser ? »

La mise à jour doit être circonscrite au projet et aux éléments fournis. Une ligne collée peut justifier l'utilisation de cette ligne dans la tâche en cours ; elle n'établit pas automatiquement que ce détail est définitif, qu'il s'applique à toutes les versions ou qu'il doit être conservé au-delà de la conversation actuelle. Si le produit dispose d'un historique de projet visible, affichez la mise à jour proposée et offrez à l'utilisateur un moyen de la corriger. S'il n'en a pas, n'affirmez pas que la mémoire a été modifiée de façon permanente.

Cette étape de confirmation est une recommandation de conception issue de la traçabilité et du contrôle par l'utilisateur : celui-ci peut voir quel fait a été retenu et le corriger avant qu'il n'influence la suite du travail. Elle est particulièrement utile lorsque les choix créatifs évoluent. Un brouillon antérieur peut contenir un ancien titre, tandis qu'un message récent en établit un nouveau ; l'assistant doit préserver cette chronologie plutôt que d'aplatir les brouillons en un seul souvenir prétendument intemporel.

Éviter les questions qui glissent discrètement une supposition

Une question peut tout de même induire en erreur si elle intègre une réponse inventée. « Vous aviez choisi le sarcelle, n'est-ce pas ? » oriente la conversation vers un détail que l'assistant n'a pas vérifié. Privilégiez une formulation neutre : « Quelle couleur aviez-vous choisie ? » S'il existe une véritable source mentionnant le sarcelle, nommez-la : « Les notes de brouillon mentionnent le sarcelle. Est-ce toujours la palette que vous souhaitez ? » Cette formulation distingue la preuve issue d'une source de la confirmation actuelle.

Ne présentez pas des alternatives générées comme des faits mémorisés. Si l'utilisateur ne parvient pas à retrouver l'ancienne décision, l'assistant peut proposer son aide pour choisir à nouveau, mais il doit présenter cela comme un nouveau choix : « Je ne parviens pas à retrouver la palette précédente. Souhaitez-vous en sélectionner une maintenant ? » Cette distinction permet la collaboration créative sans réécrire l'histoire du projet.

Une étude de 2024 portant sur les réponses des modèles de langage à des questions incomplètes a révélé qu'un comportement de clarification adapté au contexte n'apparaissait pas automatiquement, mais émergeait sous certaines conditions précises de taille de modèle et de guidage par invites (prompting). Ce résultat rappelle aux équipes produit qu'il convient de concevoir et d'évaluer ce comportement de manière explicite, et non de supposer qu'un modèle posera par défaut et de manière fiable la bonne question. Clarifying Completions

Évaluer le comportement à l'aide de tâches de projet ordinaires

Les équipes produit peuvent tester cette interaction à l'aide de requêtes courantes de projets créatifs : demander un titre manquant, un format sélectionné ou une préférence de brouillon lorsque le détail pertinent est absent du contexte accessible à l'assistant. Une réponse de qualité doit nommer l'élément manquant, éviter d'inventer un échange antérieur, demander une source pertinente ou une confirmation, puis exploiter l'information confirmée de manière cohérente.

Incluez des cas voisins où le détail est présent dans le fil actuel ou dans une note fournie. L'assistant doit alors exploiter les preuves disponibles, tout en indiquant précisément d'où elles proviennent. Testez également les versions contradictoires et les corrections apportées par l'utilisateur. Une évaluation pertinente distingue un rappel non étayé d'une récupération fondée sur des sources, et vérifie si l'assistant poursuit les tâches non impactées au lieu de bloquer l'ensemble du travail.

Il s'agit d'une méthode d'évaluation proposée, et non d'un résultat établi par les études citées. Sa valeur ajoutée réside dans la séquence de décision : déterminer l'accès, énoncer la limite, demander la source utile la plus concise, confirmer le détail retenu et garder un périmètre de mise à jour bien défini. Cette séquence transforme un « je ne sais pas » en une étape productive du travail.

Faire de l'incertitude un élément de la continuité du projet

Pour un assistant de projet créatif, reconnaître l'absence d'un détail n'est pas une impasse. C'est un moyen de préserver la continuité : le système peut continuer à apporter son aide tout en laissant vide un historique non vérifié. Une incertitude clairement énoncée, une demande ciblée et une confirmation visible permettent à l'utilisateur de décider de ce qui a sa place dans les archives du projet — et offrent à l'assistant une base solide pour le prochain brouillon.

Continuer sur ce thème