Un client reçoit une réponse bizarre. Il rappelle deux mois plus tard, mécontent. Quelqu'un cherche à comprendre : le message a été préparé par un assistant, relu par une personne qui ne s'en souvient plus, avec un prompt qui a été modifié trois fois depuis. Il n'y a rien à regarder. C'est cette situation que la traçabilité évite — et elle sert bien au-delà.
Ce qu'il faut conserver
Cinq éléments. Pas plus, mais les cinq.
- L'entrée. Ce qui a été soumis au système : le texte, le document, les champs de données. C'est la partie qu'on oublie le plus souvent, et sans elle rien n'est reproductible.
- La version du prompt. Pas le prompt « du système », mais celui qui tournait ce jour-là. Un prompt vit : on le corrige, on ajoute une règle, on retire un exemple. Deux sorties différentes viennent souvent de deux versions de prompt, pas du modèle.
- Le modèle et ses paramètres. Nom exact, version, température, éventuellement les outils auxquels il avait accès. Les modèles sont mis à jour par leurs fournisseurs, parfois silencieusement pour les alias génériques.
- La sortie brute. Ce que le système a produit, avant toute retouche.
- L'action humaine. Qui a relu, qu'est-ce qui a été validé, modifié, rejeté — et le texte final s'il diffère. C'est le champ le plus précieux et le plus négligé.
Ajoute un horodatage et un identifiant de dossier pour raccrocher la trace à l'objet métier concerné. Ça tient dans une ligne de table.
Pourquoi c'est utile bien avant la conformité
La conformité est la raison la moins motivante, et la moins fréquente en pratique. Trois autres usages justifient l'effort à eux seuls.
Le débogage. Sans les entrées et la version du prompt, une régression est impossible à analyser. Tu constates que « ça marchait mieux avant » et tu n'as aucun moyen de savoir ce qui a bougé. Avec les traces, tu retrouves en dix minutes l'exemple précis où le comportement a changé.
L'amélioration. C'est l'usage que je trouve le plus rentable. Le champ « action humaine » te donne, gratuitement, un jeu de corrections réelles : voilà ce que le système a proposé, voilà ce que l'humain a écrit à la place. Trente cas relus produisent une liste de règles à ajouter au prompt bien plus juste que n'importe quelle séance de réflexion en salle.
C'est aussi la seule mesure honnête du taux de reprise : quelle proportion des sorties part telle quelle, quelle proportion est modifiée à la marge, quelle proportion est jetée. Trois chiffres qui disent si le cas d'usage tient debout, sans avoir à croire personne sur parole.
La défense en cas de litige. Pouvoir montrer qu'une personne a relu, ce qu'elle a vu, et ce qu'elle a décidé. C'est aussi ce qui matérialise la supervision humaine quand elle est exigée. Je précise que je ne suis pas juriste et que ce n'est pas un avis juridique : sur ce que ton secteur impose réellement, fais valider par quelqu'un dont c'est le métier.
Comment le faire simplement
C'est là que beaucoup de projets se noient. On imagine une plateforme d'observabilité, on repousse, et on ne trace rien pendant un an.
Le niveau zéro suffit pour démarrer
Une table, une ligne par appel, dix colonnes. Dans la base que tu as déjà. Si le cas d'usage tourne dans un outil no-code, un onglet de tableur alimenté automatiquement fait le travail les premiers mois — je l'ai fait comme ça sur mes propres produits, et c'est ce qui m'a permis de corriger les vrais problèmes plutôt que ceux que j'imaginais.
Versionner le prompt comme du code
Le prompt ne vit pas dans l'interface d'un outil, où il est modifié par n'importe qui sans trace. Il vit dans un fichier, avec un numéro de version, et c'est ce numéro qu'on écrit dans la trace. Une ligne à changer, un problème en moins.
Stocker un identifiant, pas toujours le contenu
Si l'entrée contient des données sensibles, tu n'es pas obligé de la dupliquer dans la table de traces. Stocke la référence du document ou de l'enregistrement source. Tu retrouves le contenu quand tu en as besoin, sans le recopier partout.
Fixer une durée de conservation
Les traces sont des données comme les autres : elles ont une finalité, une durée, et parfois des données personnelles dedans. Écris la durée dès le premier jour — six mois, douze mois selon ton contexte — et fais purger automatiquement. Une table de traces qui grossit sans limite finit par devenir un problème à elle seule.
Regarder les traces à intervalle fixe
Une traçabilité que personne ne consulte est un coût sans contrepartie. Bloque trente minutes par mois pour lire vingt cas au hasard et les dix cas rejetés. C'est court, et c'est là que se trouvent les vraies améliorations.
Ce que ça ne remplace pas
La traçabilité ne rend pas un système explicable. Elle dit ce qui est entré et ce qui est sorti, pas pourquoi le modèle a produit cette sortie-là. C'est une nuance importante à tenir quand on présente le sujet à un comité : on documente une chaîne de décision, on n'ouvre pas la boîte noire.
Elle ne remplace pas non plus la supervision humaine. Enregistrer qu'une personne a cliqué sur « valider » ne prouve pas qu'elle a lu. Le champ utile n'est pas la validation, c'est la modification : ce qui a été changé prouve qu'on a regardé.
À câbler dès le premier cas d'usage
Quand tu montes un cas d'usage en production, ajoute la table de traces avant de brancher le premier utilisateur. Cinq colonnes, une purge automatique, une revue mensuelle au calendrier. Rétrofitter la traçabilité six mois plus tard coûte dix fois plus cher, et tu auras perdu les six mois de données qui t'auraient le plus appris.