Que demande un commissaire aux comptes sur un système d'IA ?

Les quatre questions récurrentes

Le commissaire aux comptes n’arrive pas avec une grille « IA » exotique. Il arrive avec les réflexes de l’audit financier et du contrôle interne, appliqués à un nouveau type de traitement. Les formulations varient. Le fond, très peu.

Sur quelles données le système s’est-il appuyé. Périmètre, origine, version, exclusions. Si le commentaire de gestion cite un agrégat, d’où vient l’agrégat. Si un scoring repose sur un référentiel, quelle millésime. L’auditeur veut pouvoir relier un chiffre du livrable à une donnée d’entrée, comme il relie un poste du bilan à une pièce.

Quel traitement a été appliqué. Pas le nom commercial du modèle. Le traitement : règles, paramètres, éventuelles reprises, ordre des étapes. Il veut distinguer ce qui est déterministe de ce qui est probabiliste, et savoir si un humain a modifié le résultat après coup. Un traitement non déclaré est, pour lui, un traitement non contrôlé.

Qui a validé, et à quelle date. L’identité, le rôle, l’horodatage. La validation doit porter sur le livrable effectivement utilisé, pas sur une version antérieure. Une liste de diffusion en copie n’est pas une validation. Un « vu » sur messagerie, détaché du fichier, non plus.

L’exécution peut-elle être reproduite. C’est la question qui départage les dossiers. Si l’on peut relancer le run et obtenir le même objet, ou un écart expliqué, l’auditeur a un fait. S’il faut « refaire à la main » en espérant s’en rapprocher, il a un récit. Les normes d’audit préfèrent les faits.

Ces quatre questions suffisent à structurer une revue. Elles suffisent aussi à structurer la conception d’un rituel. Tout ce qui, dans la plateforme, ne contribue pas à y répondre est, du point de vue de l’audit, du confort. Le confort n’est pas interdit. Il ne remplace pas le dossier.

Un point de méthode, souvent omis dans les préparations : l’auditeur échantillonne. Il ne relit pas tous les runs de l’année. Il en choisit quelques-uns, parfois les plus sensibles, parfois au hasard. Si l’échantillon tombe sur un run sans pack, l’exception devient le constat. La documentation « en moyenne » n’existe pas en audit. La documentation de l’unité choisie existe, ou n’existe pas. Concevoir le dossier au niveau du run, et non au niveau du projet, est donc la seule maille qui résiste à l’échantillonnage.

Ce qui pose problème dans les déploiements courants

Les déploiements qui passent mal l’épreuve ont des traits communs, indépendants du secteur.

Le livrable et les sources vivent dans des outils différents. Le rapport est dans un Drive. Les données sont dans un entrepôt. Le prompt est dans un carnet. La validation est dans un outil RH de workflow. L’auditeur n’a pas à reconstituer l’architecture de l’entreprise. Si l’organisation ne lui présente pas un pack, il notera une limitation de piste d’audit.

Les versions ne sont pas figées. Le modèle a changé entre le run et la revue. Le fichier source a été écrasé. Le paramètre de seuil a été « ajusté » sans historique. La piste s’interrompt. L’interruption n’est pas un détail technique. C’est une rupture de contrôle.

Les rôles de validation sont nominaux. Tout le monde peut approuver. Personne n’est désigné. Ou, à l’inverse, une seule personne approuve tout, y compris ce qu’elle n’a pas le temps de lire. Dans les deux cas, le contrôle interne est faible, même si un statut « approved » existe dans l’interface.

Enfin, le rejeu n’a pas été prévu. On peut relancer « un » traitement. On ne peut pas relancer ce traitement. La distinction est celle que l’auditeur fait entre une démonstration et une preuve. Les démonstrations l’intéressent peu le jour de la revue. Les preuves, si.

Ces problèmes ne sont pas des maladresses d’équipes. Ils sont le résultat d’une mise en production guidée par la sortie (le texte, le score, le graphe) plutôt que par l’opposabilité de la sortie. Tant que le critère de succès du projet est « ça marche en démo », le dossier d’audit reste hors périmètre. Il revient dans le périmètre le jour où le commissaire pose la question. Ce jour-là, le calendrier n’est plus celui du projet.

Il faut ajouter le cas, fréquent dans l’assurance et la banque, des commentaires intégrés à un rapport réglementaire. Le commentaire paraît accessoire à côté des tableaux. Pour l’auditeur, il est un traitement de l’information financière ou prudentielle. S’il a été produit avec un modèle, il entre dans le champ des quatre questions au même titre qu’un calcul. Le minimiser en « aide à la rédaction » ne change pas la nature du contrôle. Cela change seulement le moment où la surprise arrive.

Préparer le dossier avant la demande

Préparer, ce n’est pas rédiger un mémoire sur l’IA à l’attention des commissaires. C’est faire en sorte que chaque exécution soit déjà un dossier.

Le pack exportable contient, a minima : l’identifiant du run, les références de sources, la version du traitement, les paramètres, les identités HITL, l’horodatage des états, le livrable lui-même. Il est généré par le système, pas assemblé par un chef de projet la veille de la revue. S’il faut l’assembler, on est déjà dans la reconstitution.

La préparation inclut un exercice que trop d’équipes reportent : faire relire un pack par quelqu’un qui n’a pas conçu le rituel. Un contrôleur interne, un DAF adjoint, un auditeur interne. S’il ne comprend pas le lineage, l’auditeur externe ne le comprendra pas davantage. Le critère n’est pas la sophistication. C’est la lisibilité pour un professionnel du contrôle.

La préparation inclut aussi le périmètre. Tous les usages d’IA de l’entreprise n’ont pas le même enjeu. Un assistant de rédaction interne n’appelle pas le même dossier qu’un commentaire intégré à un rapport réglementaire. Le commissaire s’intéressera d’abord aux traitements qui alimentent l’information financière, prudentielle ou de gestion publiée. C’est là qu’il faut que le pack existe, pas dans une politique générale qui promet la traçabilité sans l’attacher aux runs concernés.

Préparer, enfin, c’est décider qui parle le jour de la revue. Si seuls les data scientists peuvent expliquer le run, le contrôle interne est dépendant d’une équipe projet. Un pack lisible par un DAF adjoint réduit cette dépendance. C’est un critère de conception, pas un critère de pédagogie a posteriori.

Le rejeu d’exécution

Le rejeu n’est pas une fonction « pour les data scientists ». C’est la réponse à la quatrième question. Il suppose que l’on a figé ce qui doit l’être : données d’entrée ou leur empreinte, code ou image d’algorithme, paramètres, graine si elle influe, version de modèle.

Un rejeu utile produit une comparaison. Identique, ou écart. L’écart a une cause déclarable : donnée mise à jour, dépendance externe, intervention humaine postérieure. Un rejeu qui « ressemble » n’est pas un rejeu. C’est une nouvelle exécution. L’auditeur fait la différence.

Dans les rituels de reporting, le rejeu a une valeur supplémentaire : il permet de montrer qu’un commentaire sourcé l’année précédente l’est encore, ou d’expliquer pourquoi il a changé. La continuité de piste n’est pas la répétition du même texte. C’est la capacité à relier chaque version à son run.

Les organisations qui savent rejouer n’ont pas un avantage rhétorique. Elles ont un dossier. Celles qui ne savent pas rejouer ont un narratif, et le narratif, en audit financier, a une durée de vie courte. Le commissaire n’est pas hostile à l’IA. Il est hostile, par métier, à ce qui ne se retrace pas. Sur ce point, un système d’IA n’est pas traité plus sévèrement qu’un tableur occulte. Il est traité de la même manière. Le tableur occulte, chacun sait ce qu’il en coûte le jour de la revue.