Ce qu'un auditeur demande vraiment quand vous lui dites « IA »
Les équipes préparent des réponses sur le modèle, le fournisseur et la protection des données. L'auditeur, lui, pose trois questions beaucoup plus simples : quelle décision a été prise sur ce dossier, sur quelles données, et qui en répond. Aucune des trois ne porte sur l'intelligence artificielle. Toutes les trois portent sur la traçabilité.
Ce qu'il faut retenir
- Un auditeur ne contrôle pas un modèle : il contrôle une décision, sa date, ses entrées et la personne qui en répond.
- Un journal de conversation avec un modèle n'est pas une piste d'audit : il ne permet pas de reproduire la décision.
- La question qui met en échec la plupart des déploiements est « rejouez-moi cette exécution du mois dernier ».
- Ce qui rend une exécution auditable est écrit avant l'exécution — le plan et les contrats — pas reconstitué après.
Pourquoi les réponses préparées tombent à côté#
Une équipe qui prépare un audit sur un système à base d'IA arrive avec une documentation du modèle, une attestation du fournisseur et une politique de traitement des données. C'est un bon dossier. Il ne répond simplement pas à ce qui va être demandé.
L'auditeur ne cherche pas à évaluer une technologie. Il cherche à vérifier qu'une opération enregistrée dans vos comptes correspond à une décision qu'une personne identifiable assume.
Les trois questions qui reviennent#
« Montrez-moi la décision prise sur ce dossier-là. » Pas la catégorie de décisions, pas le processus en général : celle-ci, sur ce client, ce jour-là.
« Sur quelles données a-t-elle été prise ? » L'état exact des entrées au moment de l'exécution, pas l'état actuel de la base — qui a changé depuis.
« Qui en répond ? » Un nom. Et si la réponse est « le système », la question suivante est « sur quelle délégation écrite ».
Pourquoi un historique de conversation ne suffit pas#
C'est le point de rupture le plus fréquent. Une équipe conserve consciencieusement les échanges avec le modèle : la requête, la réponse, l'horodatage. C'est une trace, mais pas une piste d'audit, pour une raison mécanique : elle ne permet pas de reproduire la décision.
Reproduire suppose de retrouver la version du plan, la version des contrats, l'état des entrées et la réponse du modèle telle qu'elle a été reçue — pas telle qu'un modèle mis à jour la produirait aujourd'hui. Un historique conserve le résultat ; il ne conserve pas les conditions.
Ce que « rejouable » veut dire précisément#
Une exécution rejouable est une exécution dont le journal contient assez d'informations pour la reconstituer à l'identique, six mois plus tard, sur une machine différente, réponses du modèle comprises — parce qu'elles ont été enregistrées, pas parce qu'on espère que le modèle répondra pareil.
Cette propriété ne s'ajoute pas après coup. Elle découle de la façon dont le système est écrit : un plan versionné, un contrat par étape, un journal qui fait autorité. Le détail des mécanismes est sur la page comment le déterminisme est obtenu.
Un exemple que nous pouvons montrer#
Le bot de réunion que nous exploitons en production depuis le 14 août 2026 produit, pour chaque réunion, un compte rendu soumis à validation. Ce que le journal conserve n'est pas seulement ce compte rendu : c'est la transcription telle qu'elle a été reçue, la proposition produite, la personne qui l'a validée, l'horodatage, et ce qu'elle y a modifié.
Un auditeur qui demande « qui a écrit cette phrase » obtient une réponse. Ce n'est pas une propriété du modèle : c'est une propriété de ce qui a été journalisé.
Ce que ça change dans la conception#
Trois conséquences pratiques, et aucune n'est théorique :
- Le plan est un fichier de votre dépôt, avec un identifiant de version écrit dans chaque exécution. Une modification du plan ne réécrit jamais le passé.
- Les réponses du modèle sont journalisées telles quelles, avant tout traitement. C'est la seule façon de rejouer sans dépendre d'un fournisseur.
- Les points d'arrêt humains produisent une identité, pas un simple booléen : qui, quand, et ce qui a été modifié à cette occasion.
Ce que ça ne résout pas#
Un système auditable n'est pas un système correct. Il vous permet de démontrer ce qui s'est passé, pas de garantir que c'était la bonne décision. Cette garantie-là reste humaine, et c'est précisément pourquoi les points d'arrêt existent. La question de savoir où les placer relève de la mise en œuvre, pas de l'architecture.