Commencer par une seule tâche observable
Une fiche de correction devient utile lorsqu’elle porte sur une tâche assez précise pour qu’une personne puisse reconnaître une bonne réponse. Évitez de commencer par « améliorer notre assistant ». Choisissez plutôt une action, par exemple classer une demande de réparation, extraire le numéro d’un appareil ou proposer la prochaine étape à un agent de service. Définissez ensuite ce que le système doit produire et ce qu’il ne doit jamais décider seul. Prenons l’exemple fictif d’un atelier d’électroménagers. Son assistant lit un court message et doit choisir entre quatre catégories : rendez-vous, pièce, garantie ou information générale. Il peut aussi signaler « incertain », mais il ne peut ni confirmer une garantie ni promettre une date. Cette portée tient sur une page et permet de juger chaque sortie avec les mêmes règles. Avant de créer la fiche, réunissez la personne qui utilise le résultat et celle qui peut corriger le processus. Ensemble, écrivez trois exemples acceptables et trois erreurs typiques. Cette petite base évite que chacun évalue l’assistant selon une impression différente.
Conserver le cas réel et la réponse attendue
La fiche peut rester très courte. Elle doit conserver au minimum l’entrée reçue, la sortie de l’assistant, la correction attendue, la raison de la correction et la date. Ajoutez la version du modèle ou de l’instruction si elle est disponible. Il faut pouvoir rejouer le cas plus tard; une capture d’écran isolée ou une note comme « ça ne marche pas » ne suffit pas. Dans notre atelier, un client écrit : « La sécheuse a moins de deux ans et ne chauffe plus. Est-ce couvert? » L’assistant classe la demande comme information générale et répond que la réparation sera probablement gratuite. La fiche indique plutôt la catégorie attendue « garantie », puis précise que l’agent doit vérifier la preuve d’achat avant toute promesse. La raison n’est pas simplement que la catégorie était fausse : la réponse a aussi affirmé une couverture sans preuve. Pour protéger les renseignements personnels, remplacez les noms, adresses, numéros de série et autres identifiants par des valeurs fictives avant de conserver le cas dans un jeu de test.
Nommer le type d’erreur et sa gravité
Deux erreurs peuvent sembler semblables tout en exigeant des correctifs différents. Utilisez une courte liste de types : fait inventé, champ mal extrait, information omise, ton inadéquat, instruction non respectée ou action non autorisée. Limitez cette liste à cinq ou six choix au départ. Si chaque fiche crée une nouvelle catégorie, l’équipe ne pourra pas repérer les tendances. Ajoutez aussi trois niveaux de gravité. Une erreur faible ralentit la révision sans changer la décision, comme une phrase trop longue. Une erreur moyenne envoie le dossier vers la mauvaise file ou oblige un employé à reprendre le travail. Une erreur critique peut causer un engagement financier, exposer une donnée ou déclencher une action interdite. Dans l’exemple de la sécheuse, la mauvaise catégorie est moyenne, mais la promesse de gratuité est critique. Cette distinction aide à traiter d’abord les risques importants. Elle évite aussi qu’un taux global d’exactitude masque un petit nombre de réponses dangereuses.
Transformer chaque correction en test de non-régression
Une correction n’améliore rien si elle demeure dans une boîte de réception. Une fois validée, copiez le cas anonymisé dans un jeu de retest avec l’entrée, le résultat attendu et le critère de réussite. Pour une classification, le critère peut être la bonne catégorie. Pour un résumé, il peut exiger la présence de deux faits et interdire une conclusion. Pour une action, il peut vérifier que le système demande une approbation humaine. Après avoir changé une instruction, une règle ou un modèle, rejouez tous les cas conservés. Le nouveau réglage devrait corriger le cas visé sans briser ceux qui fonctionnaient déjà. L’atelier pourrait tester vingt demandes représentatives avant de publier une nouvelle version : cinq cas de garantie, cinq de pièces, cinq de rendez-vous et cinq ambigus. Conservez le résultat de chaque passage avec la date. Ne modifiez pas la réponse attendue seulement pour faire monter le score; si l’équipe change une règle d’affaires, notez explicitement cette décision et faites-la approuver par la personne responsable du processus.
Réviser les tendances avant de toucher au modèle
Prévoyez une courte revue après dix à vingt fiches ou à une fréquence adaptée au volume. Regroupez les erreurs par type, gravité et étape du travail. Trois corrections identiques peuvent révéler une instruction ambiguë. Plusieurs champs manquants peuvent signaler un formulaire incomplet. Une erreur concentrée sur des photos floues peut nécessiter une meilleure consigne de saisie plutôt qu’un autre modèle. La bonne intervention peut être une règle, un exemple ajouté au message système, une validation dans l’interface ou un transfert vers une personne. Évitez d’envoyer automatiquement toutes les corrections dans un entraînement. Une correction peut elle-même être erronée, contenir des données sensibles ou refléter une exception locale. Faites-la valider, anonymisez-la et vérifiez qu’elle représente encore la règle actuelle. Suivez ensuite trois mesures simples : nombre de cas corrigés au premier essai, erreurs critiques et temps humain consacré à la révision. Si les erreurs critiques diminuent sans déplacer le travail vers une longue vérification manuelle, la boucle apporte une valeur réelle. La fiche de correction ne rend pas l’assistant parfait; elle rend son amélioration traçable, testable et liée au travail quotidien.
