Écrire la fiche d’un système d’IA

La fiche d’un système d’IA est un document d’une page, rédigé par l’équipe qui l’a construit, qui décrit sa finalité, ses données, la décision qu’il sert, sa supervision et sa date de revue. Elle sert de point d’entrée à un dossier, sans couvrir à elle seule toutes les exigences d’un contrôle.

La raison n’est pas la charge de travail : c’est que personne n’est désigné pour l’écrire.

La documentation exigible est souvent perçue comme un dossier volumineux à produire par un service spécialisé. Cette perception paralyse : le dossier ne commence jamais, et rien n’existe.

Une page rédigée par l’équipe qui a construit le système vaut infiniment mieux que rien, et constitue le socle de tout dossier plus complet ensuite. Je propose une première séance de rédaction, puis la vérification des points qui restent sans preuve. Elle sert aussi de première pièce lorsqu’une autre équipe doit reprendre le système, situation décrite dans reprendre un système d’IA construit par quelqu’un d’autre.

Les cinq rubriques d’une fiche de système d’IA sont la finalité, les données, la décision servie, la supervision et la date de revue, chacune formulée de façon vérifiable par un tiers. Le tableau suivant distingue une rédaction creuse d’une rédaction utile.

La colonne de droite se vérifie ; celle du milieu ne se vérifie pas. C’est toute la différence entre une fiche et une déclaration d’intention.

La finalité d’un système d’IA doit préciser la décision servie, les personnes concernées et les conséquences attendues, afin de distinguer l’usage métier de la seule fonction technique. C’est la rubrique qui révèle le plus de choses.

« Répondre aux questions sur les procédures » n’est pas une finalité : c’est une fonction. « Permettre à un gestionnaire de vérifier l’applicabilité d’une procédure avant de traiter un dossier » en est une, parce qu’elle nomme qui décide quoi.

Cette formulation révèle régulièrement qu’un système poursuit deux finalités : informer les collaborateurs et, accessoirement, orienter des décisions engageantes. Ces deux usages n’ont pas le même régime, et les mélanger est précisément ce qui rend une évaluation de risque impossible.

Quand deux finalités apparaissent, il faut soit les séparer en deux systèmes, soit retenir la plus exigeante.

Au-delà de la finalité, il faut documenter les données et leurs droits, la décision réellement servie, les mécanismes de supervision et la date de revue avec un responsable nommé.

• Les données : lesquelles, d’où elles viennent, quels droits d’accès sont appliqués et à quel moment de la chaîne.
• La décision servie : qui décide, sur la base de quoi, et ce qui se passe si le système se trompe.
• La supervision : qui vérifie, quand, avec quel moyen concret de dire non. Voir supervision humaine : la concevoir, pas la promettre.
• La date de revue : quand cette fiche sera relue, et par qui. Sans date, elle se périme en silence.

La rubrique « données » d’une fiche de système d’IA doit préciser à quel moment de la chaîne les droits d’accès sont appliqués, et pas seulement la source des données. C’est le détail qui distingue une protection d’une apparence de protection.

Deux architectures coexistent dans les systèmes que je reprends. Dans la première, les droits filtrent les documents avant la recherche : le système ne peut pas lire ce que l’utilisateur n’a pas le droit de voir. Dans la seconde, la recherche porte sur tout et le résultat est filtré ensuite.

Un filtrage après la recherche peut encore protéger la génération s’il intervient avant tout envoi d’extraits au modèle. Un filtrage après génération est trop tardif : masquer les sources ne retire pas les informations déjà transmises ou utilisées. La fiche doit nommer précisément cette frontière.

Cette précision tient en une ligne dans la fiche et elle a plus de valeur qu’un paragraphe sur la sécurité en général.

Écrire « supervision humaine assurée » ne documente rien : la fiche doit nommer qui supervise, à quel moment, et avec quel moyen concret de refuser la proposition du système. C’est la rubrique la plus souvent creuse.

Trois conditions rendent une supervision réelle. La personne voit ce qui va se passer, avant que cela se passe. Elle dispose du contexte pour juger, ce qui suppose que la source soit affichée. Et elle a le temps de le faire, ce qui suppose que le volume soit compatible avec une attention réelle.

Une supervision qui échoue sur l’une des trois est une formalité : elle ne démontre ni protection effective ni conformité juridique.

Dans un exemple fictif, une formulation vérifiable ressemble à ceci : « le gestionnaire voit la proposition et la source avant validation ; il traite en moyenne quarante dossiers par jour ; il peut renvoyer le dossier en traitement manuel d’un clic ». Trois lignes, vérifiables. C’est la même exigence de concret que dans ce qu’on ne délègue jamais à un modèle.

Une fiche explique les conséquences d’une erreur lorsqu’un lecteur extérieur peut retrouver la décision concernée, son responsable, les personnes exposées et la procédure de reprise ou d’arrêt.

La donner à quelqu’un qui ne connaît pas le système et lui demander ce qui se passe si le système se trompe. Si la réponse n’est pas dans la page, la fiche n’est pas finie.

La première version d’une fiche peut être rédigée en séance avec l’équipe qui connaît le système, puis complétée par les preuves et les vérifications restées ouvertes. La séquence suivante évite les pages blanches.

1. Désigner un rédacteur dans l’équipe qui a construit le système, pas dans un service extérieur.
2. Écrire la finalité en premier, sous la forme « permettre à [qui] de [décider quoi] ». Si deux décisions apparaissent, le signaler.
3. Décrire les données : sources, droits d’accès, et moment où ces droits sont appliqués.
4. Nommer la décision servie et la conséquence d’une erreur du système.
5. Décrire la supervision en trois lignes vérifiables : qui, quand, comment refuser.
6. Fixer une date de revue et un responsable nommé.
7. Faire relire par un tiers qui ne connaît pas le système, avec la question du callout ci-dessus.

Les journaux du système aident à remplir les rubriques données et supervision avec des faits plutôt que des intentions, ce que permet l’observabilité des systèmes d’IA.

Comparer la fiche à l’usage actuel aide à repérer une dérive de finalité, à condition de vérifier les parcours réels et les changements depuis la dernière revue. C’est un effet secondaire qui justifie l’exercice à lui seul.

Un système construit pour aider à retrouver une information finit souvent par orienter des décisions, sans qu’aucune décision explicite n’ait été prise. La dérive est progressive : les utilisateurs font confiance, puis s’appuient, puis cessent de vérifier.

Rédiger la fiche oblige à constater cette dérive, parce qu’il faut nommer la décision servie. Si celle qu’on nomme aujourd’hui n’est pas celle du départ, le régime du système a changé et son encadrement doit suivre.

C’est aussi ce qui rend la date de revue indispensable : une fiche exacte à la mise en service peut devenir inexacte après un changement ; relisez-la lors des modifications et des revues. C’est le principe posé dans l’AI Act en vigueur : ce que l’ingénieur doit livrer. Un audit IA commence d’ailleurs souvent par la rédaction de ces fiches, système par système.

La fiche peut servir de support à une formation IA : un collaborateur explique le refus et le repli à partir du document, puis on vérifie que ces moyens existent. Pour un jumeau numérique, elle précise notamment le domaine de simulation, les données réelles utilisées et la décision que le résultat peut éclairer.

Une fiche de système d’IA devient inutile quand elle décrit des intentions au lieu de faits vérifiables, ou quand elle n’a ni responsable ni date de revue. Les erreurs les plus fréquentes sont faciles à repérer.

• Confondre fonction et finalité, ce qui masque la décision réellement servie.
• Décrire la sécurité en général au lieu de préciser le moment où les droits d’accès s’appliquent.
• Promettre une supervision sans dire qui, quand, ni comment refuser.
• Confier la rédaction à un service extérieur au système, qui ne connaît ni ses données ni ses usages.
• Oublier la date de revue, ce qui laisse la fiche se périmer en silence.
• Viser l’exhaustivité d’emblée, ce qui repousse indéfiniment la première version.