---
name: trace-des-productions-ia
description: Aide l’assistant à organiser la trace d’une production faite avec un outil d’IA (outil et version, instructions, sources, date, relecteur, modifications humaines) pour pouvoir expliquer plus tard comment un résultat a été obtenu. À utiliser dès qu’un livrable, un texte ou une analyse produit avec une IA sort de la structure ou sert à une décision.
---

# Garder la trace de ce qui a été produit avec un outil d’IA

## Quand s’en servir

Mettre en place une fiche de trace pour les livrables produits avec une IA. Décider ce qu’on garde et ce qu’on ne garde pas. Compléter la trace d’un travail déjà rendu tant que les éléments sont encore disponibles. Préparer ce qui servira, le jour venu, à la Skill dossier-de-preuve-en-cas-de-contestation.

## Ce que l’assistant doit savoir

Une trace utile répond à une seule question : comment ce résultat a-t-il été obtenu, et qui l’a validé ? Elle tient en quelques champs : l’outil et sa version ou son abonnement, la date, les instructions données, les sources fournies ou citées, ce que l’humain a modifié, le nom de la personne qui a relu et validé. Garder tout, tout le temps, n’est pas une bonne trace : le RGPD impose la minimisation des données (art. 5 §1 c), et une instruction contenant des données personnelles se conserve comme une donnée personnelle. Pour les systèmes à haut risque, le règlement européen sur l’IA impose en plus au déployeur de conserver les journaux du système au moins six mois (art. 26 §6), à partir du 2 décembre 2027 ; c’est distinct de la trace éditoriale décrite ici. La trace alimente le registre tenu avec la Skill registre-usages-ia.

## Marche à suivre

1. Demander quels livrables sont concernés, où ils sont stockés, et qui les relit aujourd’hui. Partir de l’existant plutôt que d’un outil nouveau.
2. Proposer une fiche de trace courte, adaptée au type de production (texte, code, image, analyse chiffrée), avec les seuls champs qui répondent à la question « comment ce résultat a-t-il été obtenu ».
3. Repérer les champs qui contiendraient des données personnelles ou confidentielles, et proposer de les remplacer par une référence au dossier source plutôt que par une copie.
4. Faire fixer par l’humain la durée de conservation et l’endroit où la trace est rangée ; noter qui en est responsable.
5. Remplir la fiche avec l’utilisateur pour un premier livrable réel, et signaler les champs qu’il n’a pas pu renseigner.
6. Rappeler ce qui reste à la personne : la relecture, la validation, la signature du livrable.

## Lignes rouges

- Ne jamais reconstituer après coup une instruction, une source ou une date qu’on ne retrouve pas : écrire « non conservé ».
- Ne jamais copier dans la trace des données personnelles ou couvertes par un secret quand une référence suffit.
- Ne jamais indiquer qu’un livrable a été relu sans le nom de la personne qui l’a fait.
- Ne jamais présenter la trace comme une preuve de conformité : elle montre comment on a travaillé, pas que c’était licite.

## Ce que la Skill ne fait pas

Elle ne choisit pas l’outil d’archivage, ne fixe pas la durée de conservation à la place de la structure et ne remplace ni le registre des usages ni les journaux techniques d’un système.

## Modèle de sortie

~~~
LIVRABLE : ...
OUTIL ET VERSION : ...          DATE : ...
INSTRUCTIONS (ou référence) : ...
SOURCES FOURNIES / CITÉES : ...
MODIFICATIONS HUMAINES : ...
RELU ET VALIDÉ PAR : ...        LE : ...
NON CONSERVÉ : ...
CONSERVATION : durée ... / lieu ... / responsable ...
~~~