Suggestion IA corrigée : exploiter le retour utilisateur sans confondre correction et vérité

Le gestionnaire remplace 40 € par 42 € dans la proposition du copilote. Le produit conserve la phrase corrigée, puis l’équipe la récupère comme réponse « validée » pour améliorer le système. Pourtant ce geste peut corriger une source ancienne, appliquer une exception au seul dossier ou simplement préparer une négociation. La perte de contexte transforme un ajustement utile à l’utilisateur en référence qui pourrait être fausse ailleurs.

En pratique, la correction d’un document et la qualification d’un retour pour réutilisation doivent conserver des contrats distincts. Le service relie proposition, version, source, portée et décision de revue avant d’en faire une attente d’évaluation. Une application IA intégrée aux décisions métier doit rendre ces effets compréhensibles sans obliger l’utilisateur à devenir annotateur après chaque modification de sa saisie.

Nous construisons un prix et des événements entièrement fictifs. Dix parcours ont été exécutés dans SQLite en mémoire, avec des contrôles de provenance, de répétition et d’admissibilité. Aucun apprentissage, modèle ou ERP n’est sollicité. Dans une IA sur mesure intégrée à une fiche métier, le passage de 40 à 42 € doit garder sa source et sa portée. La personne habilitée à qualifier ce retour ne déduit pas sa validité du seul clic de sauvegarde.

Pour qui séparer le travail corrigé de la référence

Décrire les usages possibles du même geste

Le sujet concerne une équipe produit qui intègre un copilote dans une fiche, un responsable métier qui revoit les propositions et une équipe IA qui souhaite récupérer des erreurs pour sa recette. Sauvegarder le travail, signaler une erreur et proposer une référence future ne servent pas la même décision. Une édition peut rester dans le document sans devenir une donnée de calibration ou d’évaluation.

Commencez par demander pourquoi l’utilisateur a corrigé et ce que le produit souhaite en faire. Un retour peut aider à améliorer une explication, identifier une source périmée ou documenter un cas critique. Il ne doit pas nécessairement modifier le modèle. Le bénéfice peut venir d’une règle, d’un raccordement de source ou d’un meilleur écran, avec une nouvelle recette avant ouverture.

Préserver la possibilité de terminer son travail

Le gestionnaire doit pouvoir corriger sa note et poursuivre son dossier même s’il ne souhaite pas fournir un motif détaillé au produit. Une demande de qualification systématique peut déplacer vers lui la charge d’analyse que l’assistance était censée réduire. Le parcours choisit les retours utiles et le moment où les demander, puis indique ce qui est requis pour enregistrer le document et ce qui relève d’un retour volontaire.

La guideline 15 du Microsoft HAX Toolkit encourage un feedback précis sur les sorties et comportements. Nous en retenons une orientation de conception : demander un motif relié au résultat concerné. Cela ne prouve pas qu’un formulaire donné sera accepté par vos utilisateurs ; il faut vérifier la compréhension et la charge dans leur travail réel.

Distinguer style, fait et exception locale

Qualifier ce qui a réellement changé

Remplacer « Bonjour » par « Bonjour Julie » exprime un choix de formulation. Remplacer un prix erroné par celui d’une source autorisée propose une correction factuelle. Accorder ponctuellement une condition différente relève d’une exception au dossier. Les trois gestes peuvent être légitimes, mais leur réutilisation diffère. Le service garde leur type et leur portée au lieu d’inscrire indistinctement le contenu final dans une liste de réponses exactes.

Dans le banc, les retours de style restent style_only et les exceptions local_override. Ils sont enregistrés mais non admissibles à la référence factuelle. Cette décision n’empêche pas d’étudier ultérieurement les préférences de formulation dans un protocole distinct. Elle évite de leur donner immédiatement le statut d’une valeur métier que le système devrait produire pour toutes les demandes comparables.

Refuser la généralisation d’un accord local

Une condition accordée pour ce client, cette date ou cette commande ne devient pas la politique de l’entreprise. Le responsable métier peut avoir le droit de décider cette exception sans avoir celui de modifier le référentiel commun. La correction doit donc rester reliée au dossier et à l’autorité de cette décision. Le fait qu’un agent ait préparé la phrase ne change pas la portée de l’accord humain.

Paradoxalement, le contenu final le plus utile pour terminer un dossier peut être le moins adapté comme réponse générale d’entraînement ou de test. La décision locale fait précisément partie de ce qui le rend utile. Effacer ses conditions transforme une exception en règle. Une référence réutilisable exige une qualification supplémentaire, avec le propriétaire des faits et le périmètre dans lequel cette réponse serait attendue.

Attacher le retour à une proposition et à sa portée

Conserver les pièces qui expliquent la modification

Le retour pointe vers une proposition précise, sa révision, le champ concerné, le type de modification et la portée demandée. Une correction factuelle garde sa source et la révision de preuve. L’identité de l’auteur vient du contexte applicatif autorisé ; elle ne doit pas être prise depuis un champ libre fourni par la suggestion. Le service distingue aussi auteur du retour et responsable de qualification.

{
  "event_id": "FB-E1",
  "proposal_id": "PROP24",
  "proposal_revision": 3,
  "kind": "fact",
  "scope": "reference",
  "source_id": "PRICE24",
  "source_revision": 3,
  "corrected_value": "42 EUR"
}

Ce JSON est le contrat d’entrée du petit banc exécuté, pas un schéma fournisseur. Le champ factuel de prix, Alice et sa société A sont fixés dans le contrôleur ; aucune authentification complète n’est testée. Le registre sépare événement reçu et décisions ajoutées ensuite. Une source hors société ou une proposition périmée est refusée avant l’insertion du retour, afin de ne pas transformer ce contenu en candidat de revue.

Retrouver la transformation et sa responsabilité

La provenance relie la suggestion, la correction et l’activité de qualification. Le modèle W3C PROV-DM distingue notamment entités, activités et responsabilité des agents. Cette distinction aide à penser les pièces à conserver ; notre registre JSON/SQLite n’est pas une implémentation complète de PROV. Un lien de provenance explique une dérivation, mais ne certifie pas que le fait corrigé est vrai.

Dans une application réelle, le dossier de retour garde les références nécessaires à son examen sans recopier systématiquement tout l’historique du client. Les permissions, la finalité et la rétention de ces pièces sont décidées pour cet usage. Une équipe peut avoir le droit de consulter un dossier en production sans que toutes ses données puissent être réutilisées dans un autre environnement d’évaluation. Ces usages restent qualifiés séparément.

Reconnaître répétition et conflit d’événement

Ne pas compter deux fois le même retour

Le navigateur peut répéter un envoi ou l’utilisateur relancer une action dont il n’a pas vu l’accusé de réception. L’événement conserve alors une identité stable. Le contrôleur calcule l’empreinte du payload canonique et rapproche une nouvelle réception du même identifiant. Dans FB06, la répétition exacte répond duplicate_ignored ; le registre garde un retour et une décision initiale, sans créer un deuxième signal favorable.

Cette idempotence locale concerne l’enregistrement dans le banc séquentiel. Elle ne prouve ni concurrence entre services ni livraison exactement une fois sur un réseau distribué. Dans le produit, le contrat doit définir la portée de l’identifiant et la durée pendant laquelle il peut être rapproché. Une simple déduplication par contenu peut fusionner deux corrections distinctes qui se trouvent utiliser la même valeur.

Détecter une identité réutilisée avec un autre contenu

Second cas concret : FB07 conserve FB-E1 mais remplace 42 EUR par 45 EUR lors du nouvel envoi. Le contrôleur refuse event_identity_conflict et vérifie que la valeur initiale reste 42 EUR. Une réception conflictuelle ne devient pas une mise à jour silencieuse. La correction suivante doit recevoir l’identité ou la révision prévue par le contrat pour exprimer un nouveau geste.

Le motif aide le support à distinguer une répétition réseau d’un défaut de client ou d’une modification réellement demandée. Répondre « déjà enregistré » dans les deux cas cacherait le conflit. La supervision peut retrouver les références d’événement et les états sans présenter toute la donnée corrigée dans un log technique. Le contenu original et ses décisions gardent ainsi une histoire explicable.

Vérifier le fait et la source avant la revue

Comparer la correction à la source applicable

Cas concret : PRICE24 révision 3, société A, indique le prix fictif de 42 EUR. Le retour de même source, même révision et même valeur devient pending_review. Une correction à 45 EUR reçoit insufficient_evidence et ne crée aucun retour dans le registre. Le service vérifie ces propriétés avant de demander au réviseur d’examiner un candidat ; il ne déduit pas la valeur attendue du seul geste de l’utilisateur.

Cette égalité est facile à contrôler sur le champ structuré du banc. Une correction de formulation libre demande une analyse de sens et d’applicabilité, pas seulement une référence de document. La présence d’une citation peut aider à retrouver la preuve, mais elle ne suffit pas à montrer que le passage soutient la nouvelle affirmation. Le protocole de revue doit préciser ce que le responsable examine avant de qualifier la correction.

Écarter source étrangère et contexte périmé

FB04 propose une source de la société B à Alice, rattachée à A. Le banc la refuse avant l’enregistrement ; il ne garde aucun payload étranger dans sa table de retours. FB05 vise PROP24 révision 2 alors que la révision actuelle fixée est 3 ; il est également refusé. Ces contrôles empêchent d’attribuer une correction au mauvais contexte avant même de discuter sa qualité.

Une ancienne source peut rester utile à l’analyse d’une erreur passée sans être applicable à une réponse future. Le registre conserve cette distinction dans les environnements qui l’autorisent. Notre simulation teste le refus de la proposition ancienne, pas une politique complète d’archives. Le propriétaire décide quand un retour historique devient un cas de diagnostic et quelles attentes seraient valides pour une recette actuelle.

Qualifier une correction sans élargir son sens

Séparer réception et décision de référence

Le statut pending_review signifie que le retour satisfait les contrôles d’admission du banc, pas qu’il constitue déjà une vérité commune. La qualification ajoute une décision avec son acteur. Dans la démonstration, seul l’identifiant de test expert24 peut approuver un retour en attente. Sa décision est fournie manuellement ; il ne s’agit ni d’un expert client réel ni d’une annotation générée par un modèle.

Le contrat de revue décrit responsabilité, preuve et portée de sortie. L’examinateur doit pouvoir confirmer, demander des pièces, restreindre le périmètre ou refuser. Notre petit contrôleur exécute seulement la branche de qualification manuscrite et ses refus d’état ou d’acteur. Une procédure opérationnelle ajoute les désaccords, motifs et arbitrages nécessaires plutôt que présenter ce booléen comme une revue complète du contenu.

Distinguer autorité du réviseur et préférence de l’auteur

Dans FB10, Alice tente elle-même la qualification réservée à expert24. Le contrôleur répond reviewer_denied et conserve le retour en attente. Ce choix appartient à la simulation ; il ne prescrit pas un nombre universel de validateurs. Le métier doit définir qui peut qualifier quelle propriété, notamment lorsqu’une correction touche une politique commune ou une condition commerciale plutôt qu’une simple saisie.

Un retour très fréquent peut rester incorrect, tout comme un retour rare peut révéler un défaut grave. Le volume des préférences ne remplace pas la preuve factuelle. Les désaccords doivent garder leur source, leur portée et l’autorité de l’arbitrage. Copier automatiquement la dernière version humaine comme réponse attendue peut déplacer l’erreur de la suggestion vers le jeu qui servira ensuite à évaluer le système.

Dix parcours SQLite réellement exécutés

Observer le registre après chaque parcours

Les dix situations partent chacune d’une base SQLite en mémoire vide, avec auteur, proposition et source fictifs fixés. Les assertions examinent verdicts, nombres de retours et de décisions, état final et admissibilité. Elles ne se contentent pas du message de réception. Le seuil retenu est zéro candidat de référence sans qualification applicable et zéro nouvelle ligne de retour sur les trois refus avant admission.

FB02 est le seul cas encore admissible à la fin de son parcours. FB08 a été qualifié puis retiré ; FB06 et FB07 restent en attente parce que leur premier retour n’a jamais reçu de qualification. Ces états ne mesurent pas la satisfaction utilisateur ni la qualité d’un modèle. Ils prouvent les règles exécutées dans ce registre avec les valeurs et décisions fournies.

Conserver les limites de la démonstration

Les écritures utilisent SQLite et ses transactions, mais les bases sont en mémoire. Aucun test de durabilité après arrêt, de concurrence, d’annuaire ou de permissions distribuées n’est réalisé. Les contrôles de source reposent sur un objet fixe ; ils ne prouveraient pas l’applicabilité d’un prix dans un ERP. Le système de production doit raccorder les véritables autorités et vérifier ses propres garanties avant réutilisation.

La démonstration n’entraîne pas de modèle, ne change pas de prompt et ne publie aucun document dans un RAG. Elle ne réalise pas non plus de test utilisateur. Le contrat est une base pour éprouver la boucle de qualification, avec des refus inspectables. Les usages supplémentaires exigent leur décision et leur recette, plutôt que d’être attribués à l’existence d’une table nommée feedback.

Admettre puis retirer une référence d’évaluation

Exporter une attente avec ses conditions

Une correction qualifiée peut devenir candidate à un jeu de test avec demande, contexte autorisé, propriétés attendues, interdictions et provenance. Elle ne rejoint pas automatiquement la recette finale : le responsable doit aussi vérifier le groupe de dossier et éviter qu’un cas utilisé pour régler le prompt se retrouve dans une mesure censée être indépendante. La qualification du fait et le placement dans le jeu sont deux décisions.

La construction des cas d’évaluation IA donne ce cadre de sélection et d’annotation. Une nouvelle référence peut attendre un arbitrage de portée ou un contrôle de données avant d’être incluse. La sortie conserve alors un statut de candidat, sans promettre que l’assistant répondra mieux immédiatement à la prochaine demande de l’utilisateur.

Fermer une qualification devenue contestée

FB08 ajoute une décision withdrawn après pending_review et qualified. L’admissibilité devient fausse et une nouvelle tentative de revue est refusée parce que le retour n’est plus en attente. Les trois décisions restent visibles dans le registre synthétique. Ce retrait ferme la référence courante ; il ne supprime pas les pièces de la base et n’est pas présenté comme une procédure juridique de suppression.

Si le retour a déjà été exporté dans une autre référence, la fermeture locale ne retire pas magiquement cette copie. Le service doit retrouver les destinations et requalifier les versions concernées selon leur contrat. La comparaison versionnée des évaluations IA évite qu’un changement d’attente conserve les preuves précédentes comme si le juge ou le dataset étaient restés identiques.

Dire à l’utilisateur ce que son retour change

Nommer réception, revue et effet réel

L’interface peut indiquer « modification enregistrée dans votre note » puis, pour un retour explicite, « signalement reçu pour examen ». Elle ne doit pas annoncer « l’IA a appris » après une simple édition. Le chapitre Feedback + Control du Google PAIR Guidebook insiste sur les attentes liées au retour et à ses effets. Le vocabulaire doit correspondre au mécanisme réellement livré.

Le contrat d’entrée distingue geste de travail et envoi au circuit de qualification. La responsabilité de la revue et le repli en cas de preuve manquante sont visibles ; la sortie décrit l’état actuel. Un retour incomplet peut être reçu comme signal produit sans devenir une référence factuelle. Il faut expliquer cette limite au lieu de demander des pièces toujours plus détaillées pour obtenir artificiellement un taux de qualification élevé.

Mesurer la charge déplacée vers la revue

Le coût caché de la boucle vient du tri, du rapprochement de source et des arbitrages, pas seulement du stockage des retours. Un formulaire facile à envoyer peut créer une file que personne ne qualifie. Le produit suit les retours en attente, les motifs de rejet et les délais réellement observés, puis décide où demander moins, mieux ou autrement. Aucun délai cible universel n’est fourni par les dix essais synthétiques.

Le taux de correction d’une suggestion ne mesure pas seul son utilité. Un utilisateur peut reformuler une bonne proposition pour son client, corriger un défaut grave ou abandonner sans signaler. Les interprétations demandent un contexte et, si nécessaire, une recherche auprès des utilisateurs. Un compteur d’éditions ne doit pas devenir une estimation de précision du modèle ni un indicateur automatique d’adoption réussie.

Erreurs fréquentes dans la collecte des corrections

Traiter la version humaine comme une vérité universelle

La première erreur copie la note finale dans une liste de réponses correctes. La deuxième mélange préférences de style et faits dans une même note de qualité. La troisième interprète l’absence de correction comme une validation. Ces raccourcis perdent le motif du geste et sa portée. Le contenu final peut être utile au dossier sans constituer une attente que le système devrait reproduire ailleurs.

Un signal faible est un événement « accepté » sans révision de proposition. Un autre est une correction chiffrée sans référence à la source que le métier a consultée. Le circuit ne sait alors plus quelle erreur était visée. La priorité est de rendre la provenance examinable, puis de définir ce qui pourrait être réutilisé, plutôt que d’augmenter seulement le nombre de retours collectés.

Réutiliser le retour avant que sa décision soit applicable

Une réception dupliquée ne représente pas deux utilisateurs satisfaits. Un réviseur non habilité ne donne pas au retour une portée commune. Un retrait n’est pas appliqué si l’export continue de considérer uniquement l’existence d’une ancienne ligne qualified. Le service doit consulter la décision actuelle et le contrat de référence, avec les restrictions pertinentes, avant de sélectionner un candidat pour la recette.

Le champ corrigé peut contenir des informations étrangères au besoin d’évaluation ou une instruction injectée. Sa collecte ne lui donne pas d’autorité sur le pipeline. Le retour reste une donnée à examiner, pas un ordre de modifier le prompt ou de publier un corpus. La sécurité des usages futurs s’ajoute aux contrôles de réception ; le petit registre ne revendique pas une protection complète contre tous ces contenus.

Plan d’action pour une boucle de retour exploitable

Choisir un champ et une décision de réutilisation

Commencez par une correction dont le métier peut expliquer le motif et retrouver la source. Le responsable produit décrit le geste de l’utilisateur, l’équipe métier définit la portée d’une qualification et l’équipe technique identifie proposition, révision et événement. La première boucle doit permettre de décider si un retour sert seulement au travail courant, au diagnostic produit ou à une référence d’évaluation, sans imposer tous ces usages à chaque édition.

1. Documenter les trois effets possibles du geste : sauvegarde opérationnelle, signalement explicite et candidature à une référence. Donner à chacun son libellé et sa condition d’entrée ; vérifier que le gestionnaire peut terminer le dossier sans une annotation superflue.
2. Associer retour, proposition, révisions, auteur et preuve disponible. Définir source et périmètre faisant autorité pour le fait ; garder l’exception locale séparée de la règle qu’elle pourrait sembler modifier.
3. Rapprocher les réceptions par identité d’événement. Provoquer répétition exacte et contenu conflictuel, puis vérifier les écritures réellement conservées ; un message d’erreur ne suffit pas si la première valeur a été écrasée.
4. Soumettre les faits admissibles à une qualification explicitement attribuée. Tester acteurs refusés, preuve insuffisante et proposition périmée ; préciser comment l’état change lorsque la référence est contestée ou retirée.
5. Décider de la destination d’un retour qualifié avec le propriétaire du jeu d’évaluation. Conserver groupe, attente et provenance, puis versionner la référence et contrôler les copies concernées avant toute mesure de changement.

Le livrable comprend événements, états, motifs, responsabilités et parcours de refus. Il explique quelles propriétés sont contrôlées automatiquement et lesquelles exigent une revue de sens. Un premier champ structuré peut rendre cette séparation inspectable avant d’élargir aux notes libres. Le choix ne doit pas convertir les décisions particulières du métier en exemples génériques par simple commodité d’export.

Vérifier la boucle dans le travail réel

La recette technique vérifie réception et sélection ; une vérification auprès des utilisateurs examine compréhension, effort et possibilité de correction. Les responsables observent quels motifs restent indéterminés et quels retours produisent des références utiles. Si la qualification devient une file durable, ils révisent le périmètre ou l’interface. L’automatisation doit aider au tri sans fabriquer la décision de vérité qui manque.

Le suivi garde les états retirés et les versions de référence concernées selon les règles applicables au produit. Il distingue retour reçu, fait qualifié, cas intégré et modification du système réellement évaluée. Cette chaîne permet d’expliquer ce qui a changé sans attribuer automatiquement à une correction utilisateur un apprentissage, une nouvelle précision ou une fonction produit qui n’a jamais été exécutée.

Guides complémentaires entre écran et évaluation

Préserver le geste de correction dans l’écran

Le copilote dans un écran métier sépare suggestion, source, insertion, enregistrement et annulation. L’utilisateur doit garder sa saisie et comprendre ce que la proposition pourrait remplacer. Cette conception donne un contexte exploitable au retour ; elle ne fait pas de l’enregistrement de la note une qualification automatique pour un autre usage.

Le parcours d’attente et d’annulation complète les révisions quand une réponse arrive tard ou que le dossier change. Un retour lié à la mauvaise proposition peut être techniquement enregistré tout en décrivant une erreur qui n’existe plus dans la version affichée. La correspondance entre gestes et révisions doit donc traverser toute la boucle.

Transformer une correction qualifiée en cas de test

Le jeu d’évaluation couvrant erreurs et non-réponses définit groupes, critères et propriétés interdites. Une correction peut l’enrichir lorsqu’elle possède une attente arbitrée et un périmètre autorisé. Le nombre de retours disponibles ne garantit pas cette couverture ; il peut refléter seulement les utilisateurs qui corrigent et acceptent de signaler leurs modifications.

Les évaluations de régression entre versions utilisent ensuite une référence constante et une lecture des différences. Si une qualification change, cette référence doit être réexaminée avant comparaison. La boucle conserve ainsi la différence entre comprendre une erreur, décider d’une attente et démontrer qu’une modification réelle du système l’a corrigée.

Conclusion : réutiliser une preuve qualifiée, pas un geste ambigu

Une correction humaine exprime un besoin dans son contexte. Elle peut porter sur le style, un fait ou une exception que le dossier autorise. Sa réutilisation comme référence exige type, portée, proposition, source et décision de qualification. La version finale du document ne fournit pas à elle seule cette preuve et ne doit pas devenir automatiquement la réponse attendue du système.

Les dix parcours SQLite fictifs vérifient réception, contrôle de source, identité d’événement, revue et retrait. Seul FB02 reste admissible ; FB08 ferme cette admissibilité après qualification, et les répétitions n’ajoutent pas de retour. Les essais concernent un registre en mémoire et des décisions fournies manuellement. Ils ne démontrent ni apprentissage d’un modèle, ni durabilité, ni compréhension utilisateur ou vérité commerciale d’un prix réel.

La conception d’une application IA avec une boucle de correction maîtrisée relie le travail de l’utilisateur à un examen utile pour le produit. Elle montre ce qui est enregistré, ce qui attend une revue et ce qui pourra rejoindre une recette. Une correction devient alors une pièce expliquée, avec ses limites et ses destinations.

Dawap accompagne la conception des retours de votre copilote IA sur mesure à partir d’une correction dont l’origine peut être retrouvée. Avec le responsable métier et l’équipe produit, nous précisons ce qui reste une édition personnelle, ce qui demande une revue et ce qui peut rejoindre la recette. Le pilote teste aussi le retrait et la répétition du retour, afin qu’un export de références conserve les décisions encore valables et leur provenance.