Traçabilité de l’IA en entreprise, ce qu’il faut journaliser

Commençons par le mot, parce qu’il est employé pour 2 choses différentes.

Dans l’industrie et l’alimentaire, la traçabilité sert à retrouver un lot. D’où vient ce produit, dans quelle préparation est-il entré, à qui a-t-il été livré. C’est une discipline ancienne et bien rodée.

Dans l’IA, elle sert à retrouver une décision. Qui a demandé quoi, qu’est-ce que la machine a répondu, et qui a tranché à la fin.

Le règlement européen sur l’IA prévoit, pour les systèmes classés à haut risque, un enregistrement automatique des événements pendant leur fonctionnement. Le tri de candidatures en fait partie, la notation d’élèves aussi, l’accès au crédit également.

⚠ Attention à la date, et beaucoup se trompent dessus. Ce bloc a été repoussé au 2 décembre 2027, journalisation comprise. Ce qui suit n’est donc pas encore une obligation, c’est ce qui va le devenir, et ce qu’un juge ou un assureur vous demandera bien avant cette date.

⚠ 2 réserves sur la liste. Le scoring anti-fraude financière en est explicitement exclu. Et un outil qui se contente de préparer ou de mettre en forme sort du haut risque, sauf s’il profile des personnes, auquel cas il y reste toujours.

Ce qui s’applique aujourd’hui, en revanche, c’est le RGPD. Il ne vous demande pas un journal, il vous demande de prouver que vous respectez vos obligations, c’est son article 5.2. Sans trace, cette preuve n’existe pas. Et si la décision est entièrement automatisée, l’article 22 vous impose en plus de pouvoir l’expliquer.

L’image la plus juste est celle de la boîte noire d’un avion. Elle n’empêche aucun accident. Elle permet de reconstituer.

CE QU'UNE BOITE NOIRE DOIT ENREGISTRER

  QUI     la personne qui a lance l'action, et
          celle qui a valide le resultat

  QUOI    les donnees d'entree et les donnees de
          sortie, pour voir ce que le systeme a
          reellement traite

  QUAND   l'horodatage, pour situer l'action dans
          le temps et la relier au reste

  ⚠ Les 3 ensemble, ou rien. Un journal qui dit
    QUOI sans dire QUI ne prouve rien. Un journal
    qui dit QUI sans dire QUAND ne se defend pas.

Retenez la phrase qui résume tout, et nous l’assumons en notre nom. Les journaux sont votre protection juridique. Pas un coût administratif, pas une case à cocher. Le jour où vous en avez besoin, c’est la seule chose que vous ayez.

Prenons le cas le plus courant et le plus encadré, un logiciel qui trie des candidatures.

Beaucoup d’entreprises croient qu’il faut tout enregistrer. C’est faux, et c’est même contre-productif, parce qu’un journal qui contient tout devient un risque à lui tout seul. Il faut enregistrer 3 choses précises.

LE TRI DE CV, LES 3 TRACES QUI COMPTENT

  1. L'ENTREE
     Le CV du candidat, ou sa reference. C'est ce
     que le systeme avait sous les yeux.

  2. LA SORTIE
     Le score attribue par la machine. C'est sa
     proposition, et rien de plus.

  3. LA DECISION
     La validation humaine finale. Qui a garde ou
     ecarte ce dossier, et quand.

  ⚠ C'est la 3e qui manque presque toujours. Sans
    elle, rien ne distingue une decision prise par
    un humain d'une decision prise par la machine.
    Or c'est exactement la question qu'on vous
    posera.

Cette 3e ligne est la plus importante et c’est celle qu’on oublie. ⚠ Aucun texte ne vous dicte ligne à ligne ce que doit contenir votre journal pour un tri de CV, contrairement à ce qu’on lit souvent. Mais le jour où on vous demandera si un humain a tranché, c’est la seule ligne qui répondra. Et si la décision est entièrement automatisée, c’est l’article 22 du RGPD qui vous attend. Si votre journal enregistre le score mais pas l’arbitrage humain, vous avez documenté une automatisation, pas une supervision.

Le même raisonnement vaut partout. Une IA qui rédige la synthèse d’un entretien social, une IA qui prépare un diagnostic, une IA qui note un dossier de prestation. Dans chaque cas, ce sont les mêmes 3 lignes. Et c’est la même logique que le périmètre écrit d’un agent, dont nous parlons dans ce que les laboratoires automatisent en premier.

Voilà le point technique qui change tout, et il est rarement expliqué.

Tracer un système d’IA n’est pas garder un journal fourre-tout après coup. C’est séparer 2 matières qui n’ont ni la même valeur ni la même durée de vie.

Les métadonnées décrivent l’échange. Qui, quand, quel agent, quel outil. Elles ne sont pas sensibles, elles se conservent longtemps, et ce sont elles qui portent la preuve.

Le contenu échangé est la matière sensible. Le texte du CV, le dossier du patient, le contrat. ⚠ En santé, la règle est plus stricte encore, cf ce que la certification HDS ne couvre pas. Il se pseudonymise et se garde peu de temps.

{
  "horodatage": "2026-08-16T09:41:12Z",
  "agent": "tri-candidatures",
  "outil": "scoring-v3",
  "demandeur": "u-0147",
  "entree_ref": "cv-2026-0831",
  "sortie": { "score": 62, "seuil": 70 },
  "decision": {
    "par": "u-0032",
    "valeur": "ecarte",
    "le": "2026-08-16T14:05:00Z"
  },
  "contenu_ref": "coffre://cv/2026-0831",
  "contenu_duree_jours": 730,
  "archivage_restreint_jours": 1825
}

Regardez ce que cette ligne ne contient pas. Ni le nom du candidat, ni le texte de son CV. Elle contient une référence vers un coffre séparé, avec sa propre durée de conservation. Le journal, lui, peut vivre des années sans devenir un problème.

⚠ Les durées de l’exemple ne sont pas prises au hasard, et se tromper là-dessus coûte cher. Sur une candidature, la CNIL recommande 2 ans en base active puis 5 ans d’archive à accès restreint, à des fins de preuve. C’est exactement la durée pendant laquelle une discrimination à l’embauche peut être contestée. Détruire le dossier au bout de 3 mois, c’est jeter la pièce qui vous défendrait.

⚠ La conséquence pratique est celle-ci. Les écrans de supervision ne montrent que les métadonnées. Quand vous regardez en temps réel ce que font vos agents, vous voyez des noms d’agents et d’outils, jamais des données client. Un tableau de bord qui affiche le contenu des échanges est une fuite qui attend son heure.

Une trace qu’on peut modifier ne prouve rien. C’est évident dit comme ça, et pourtant la plupart des journaux d’entreprise sont dans une base où n’importe quel administrateur peut corriger une ligne.

Le principe s’appelle l’ajout seul. On ajoute des enregistrements, on ne les réécrit jamais. Une correction n’efface pas la ligne fautive, elle en ajoute une nouvelle qui la corrige.

-- Journal en ajout seul, PostgreSQL
-- IDENTITY plutot que bigserial : la sequence est
-- liee en interne, aucun privilege separe a poser.
CREATE TABLE journal_ia (
  id          bigint GENERATED ALWAYS AS IDENTITY
              PRIMARY KEY,
  horodatage  timestamptz NOT NULL DEFAULT now(),
  agent       text NOT NULL,
  charge      jsonb NOT NULL
);

GRANT INSERT, SELECT ON journal_ia TO app_ia;

-- Un declencheur, pas une RULE. Il CRIE au lieu
-- d'avaler en silence, et il couvre l'effacement
-- en masse, ce qu'une RULE ne sait pas faire.
CREATE FUNCTION journal_immuable() RETURNS trigger
AS $$
BEGIN
  RAISE EXCEPTION 'journal_ia est en ajout seul';
END; $$ LANGUAGE plpgsql;

CREATE TRIGGER journal_ajout_seul
  BEFORE UPDATE OR DELETE OR TRUNCATE ON journal_ia
  FOR EACH STATEMENT
  EXECUTE FUNCTION journal_immuable();

⚠ Ne vous racontez pas d’histoire sur ce que ça protège. Ce déclencheur arrête les erreurs et les gestes ordinaires. Il n’arrête pas le propriétaire de la base, qui peut le retirer en une ligne, ni un administrateur tout-puissant. Beaucoup d’articles s’arrêtent là et parlent de journal opposable. C’est faux.

L’opposabilité réelle demande 3 choses de plus, et aucune n’est dans le SQL.

LES 3 ETAGES QUE LE SQL NE DONNE PAS

  1. LE COMPTE APPLICATIF N'EST PAS PROPRIETAIRE
     Celui qui ecrit dans le journal ne doit pas
     pouvoir modifier la table qui le contient.

  2. UNE COPIE PART HORS DE LA MACHINE
     Archivage continu vers un stockage en
     ecriture unique. Sinon tout tient sur un
     seul serveur, et sur celui qui l'administre.

  3. LA DATE VIENT D'UN TIERS
     Un horodatage ecrit par votre serveur vaut
     ce que vaut votre parole. C'est vous qui
     tenez l'horloge.

  ⚠ Sans le 3, vous fabriquez une preuve pour
    vous-meme. C'est l'etage decisif, pas un
    raffinement optionnel.

Ce 3e étage est tout le sujet de l’horodatage RFC 3161, et c’est lui seul qui tient devant un tiers.

⚠ Dernier point, et il tombe toujours au pire moment. Vérifiez que vos sauvegardes sont encore lisibles. Conserver 3 ans de journaux dans une archive corrompue revient exactement à ne rien avoir conservé, avec en prime la certitude d’avoir bien fait.

Passons à la question qui décide de tout le reste, et que presque personne ne se pose.

Où vivent vos traces ?

Si vos équipes utilisent la version grand public d’un assistant, la réponse est simple. Elles vivent chez l’éditeur, et l’historique des échanges peut être supprimé. Par l’utilisateur, d’un clic. Ou par l’éditeur, selon ses propres règles de conservation.

Une trace qu’un tiers peut effacer n’est pas une preuve sur laquelle on peut compter. En cas de contestation, il faudrait espérer retrouver quelque chose sur des serveurs qui ne sont pas les vôtres.

⚠ Et le problème est plus large qu’un simple effacement. La durée ne vous appartient dans aucun des 2 sens. Un changement de politique peut effacer vos échanges plus tôt que prévu. Et une décision de justice à l’étranger peut au contraire les faire conserver bien au-delà de ce que vous aviez demandé, c’est arrivé aux utilisateurs d’un grand assistant pendant 16 mois. Vous ne décidez ni dans un sens ni dans l’autre.

LA MEME ACTION, DEUX SITUATIONS

  ASSISTANT GRAND PUBLIC
    La trace est chez l'editeur. Vous pouvez
    l'exporter, ca oui. Mais la duree ne vous
    appartient pas. Elle depend d'une politique
    qui change, et parfois d'un juge etranger.
    -> Vous ne decidez de rien.

  SYSTEME QUE VOUS HEBERGEZ
    La trace est chez vous, en ajout seul.
    Vous decidez de la duree. Vous exportez
    quand vous voulez. Personne d'autre ne
    peut effacer.
    -> Vous pouvez repondre.

  ⚠ La difference n'est pas la qualite du modele.
    C'est l'endroit ou la preuve se depose.

C’est la vraie raison, très concrète, pour laquelle l’État français a déployé son propre assistant, Albert, plutôt que d’ouvrir des comptes chez un éditeur. Le modèle en dessous est souvent le même. Ce qui change, c’est que la journalisation est réelle et que l’effacement n’est pas au menu.

Pour une PME, la conclusion est la même à une échelle plus modeste, et c’est le point de départ d’une IA souveraine quand on commence. La question n’est pas de savoir quel modèle est le meilleur ce mois-ci. Elle est de savoir où atterrit la trace.

Avant même de parler de conformité, il y a un préalable que tout le reste suppose. Vous ne pouvez pas tracer ce que vous ne savez pas qui existe.

Dans une entreprise qui n’a rien organisé, chacun a choisi son assistant. Quelques comptes sur l’un, quelques-uns sur un autre, des licences intégrées à la bureautique, et DeepSeek installé par curiosité. Personne n’a rien décidé, et un système d’information parallèle est né sans que personne l’administre.

C’est le sujet entier de l’IA de l’ombre, quand vos équipes utilisent des outils que vous n’avez pas choisis, et nous y détaillons comment en faire l’inventaire. Ici, retenez seulement les 5 risques, parce qu’ils décident de ce que votre journal pourra dire.

LES 5 RISQUES DE L'IA DE L'OMBRE

  1. DES OUTILS SANS POLITIQUE COMMUNE
     Chacun le sien, aucune regle partagee.

  2. DES DONNEES QUI SORTENT
     Contrats, devis, fichiers clients, code
     source. On sait qu'on ne devrait pas, on
     le fait quand meme pour gagner 2 heures.

  3. UNE DEPENDANCE QUI S'INSTALLE
     A un fournisseur qu'on n'a jamais choisi
     collectivement.

  4. DES COUTS EPARPILLES
     Des abonnements partout, aucun pilotage.

  5. LA CONNAISSANCE QUI S'EVAPORE
     Les instructions qui marchent vraiment
     restent dans le compte personnel de celui
     qui les a trouvees. Elles quittent
     l'entreprise avec lui.

  ⚠ Le 5e est le plus sous-estime. Ce n'est pas
    un risque de conformite, c'est une perte
    seche de savoir-faire.

Le lien avec la traçabilité est direct, et c’est le point de cette section. Chacun de ces outils tient son propre historique, chez son propre éditeur, avec ses propres règles d’effacement. Tant qu’ils sont là, votre journal ne couvre qu’une partie de ce qui se passe réellement, et vous ne savez même pas laquelle.

Terminons par la partie qui se négocie une seule fois, et qu’on regrette longtemps si on l’a ratée.

Vous n’avez pas à demander l’accès à vos journaux au cas par cas. Vous devez y avoir accès quand vous en avez besoin, sans passer par un ticket et sans dépendre de la bonne volonté de quelqu’un.

Ces 3 engagements sont à obtenir par écrit.

LES 3 CLAUSES QUI CHANGENT TOUT

  1. ACCES
     Vous accedez a vos journaux quand vous en
     avez besoin, sans demande prealable.

  2. EXPORT
     Vous les exportez dans un format que vous
     pouvez relire sans le fournisseur. Un JSON
     ou un CSV, pas une capture d'ecran.

  3. NON-EFFACEMENT
     Le fournisseur ne peut pas purger vos
     traces avant la duree que vous avez fixee,
     ni au titre de sa politique interne, ni au
     titre d'un changement d'offre.

  ⚠ Un fournisseur qui ne s'engage pas sur les 3
    vous laisse une preuve qui depend de lui. Ce
    n'est pas une preuve, c'est un espoir.

Et pour finir, une question à se poser une fois par an, celle qui résume tout ce qui précède. Si un auditeur demandait aujourd’hui qui a analysé ce risque, qui l’a approuvé, et qui a accepté ce qui restait, le silence ne serait pas une réponse.

La bonne nouvelle, c’est que rien de tout cela n’est cher. Un journal en ajout seul, la séparation des métadonnées et du contenu, un inventaire des outils réellement utilisés, et 3 clauses dans un contrat. C’est du travail de quelques jours, et ça reste utile quel que soit ce que la réglementation deviendra ensuite.