Neuf feuilles : le cahier des charges d'un système d'IA existe déjà, et il est public

Personne ne donne de manuel de qualité à qui construit un système d'IA. Il en existe pourtant un, publié, remplissable, et rempli 144 fois à la date où nous l'avons compté. Nous l'avons ouvert et nous décrivons ce qu'il demande, feuille par feuille — moins pour le droit qui l'impose quelque part que pour la liste de questions qu'il pose à n'importe quel système, partout.

Laurent SOUHY's profile

Rédigé par Laurent SOUHY

5 min de lecture
Neuf feuilles : le cahier des charges d'un système d'IA existe déjà, et il est public

Il n'existe pas de manuel de qualité pour construire un système d'intelligence artificielle. On apprend le métier en le faisant, on assemble des briques dont on n'a pas écrit le code, et personne ne remet à la fin une liste de ce qu'il aurait fallu savoir. C'est une situation étrange pour une discipline d'ingénierie.

Il se trouve qu'un tel document existe. Il est public, il est gratuit, il tient dans un classeur de neuf feuilles, et il a été rempli 144 fois à la date où nous l'avons compté.

Ce n'est pas un guide de bonnes pratiques. C'est un formulaire, avec des cases, qu'une administration doit remplir pour chaque outil algorithmique qu'elle met en service. Le droit qui l'impose ne s'applique pas chez nous, et c'est sans importance pour ce qui suit : ce qui nous intéresse n'est pas l'obligation, c'est la liste de questions. Une fois posées, elles valent pour n'importe quel système, dans n'importe quelle organisation.

Nous l'avons ouvert. Voici ce qu'il demande.

Deux niveaux, et le premier tient sur une page

Le formulaire est découpé en deux niveaux. Le premier est une feuille unique, intitulée Summary Information. Le standard écrit qu'elle vise le grand public et « should be clear and simple in language » ; l'information y est de haut niveau, destinée à « a general audience without technical knowledge ».

Une page. Un outil. Écrite pour être comprise par une personne qui n'y connaît rien.

Cette contrainte est plus dure qu'elle n'en a l'air, et c'est la première chose que le formulaire révèle. Un système qu'on ne sait pas décrire en une page compréhensible n'est pas un système qu'on ne sait pas expliquer : c'est un système dont on n'a pas arrêté le périmètre. Le défaut de rédaction est un symptôme, pas une maladresse.

Le second niveau reste accessible au public mais s'adresse à des lecteurs spécialisés, et la documentation y descend au niveau du fonctionnement réel. Le standard décrit ce qu'il attend de lui en deux temps. D'abord, il « expands on the high-level description given in Tier 1 with more granular detail about the algorithmic tool, its scope and the justification for its use ». Ensuite, là où le niveau 1 dit ce qu'est l'outil et pourquoi il est utilisé, la description détaillée du niveau 2 « aims to explain how the algorithmic tool works, including the tool's purpose, its intended users, key aspects and functions at a more granular level, as well as its scope and limitations or context where it does not apply ».

La fin de cette seconde phrase est celle qu'on lit le moins et qui coûte le plus cher : là où l'outil ne s'applique pas.

Les huit feuilles du second niveau

Elles portent ces intitulés, dans cet ordre :

Feuille
1Owner and responsibility
2Description and Rationale
3Deployment Context
4Tool Specification
5Model Specification
6Development Data Specification
7Operational Data Specification
8Risks, Mitigations and Impact Assessments

Lues à la suite, elles ne ressemblent pas à un questionnaire administratif. Elles ressemblent à une revue de conception.

Un propriétaire, et une responsabilité. La première feuille ne demande pas quelle équipe a construit l'outil : elle demande qui en répond. Ce sont deux questions différentes, et dans beaucoup d'organisations la seconde n'a jamais reçu de réponse écrite.

Une description, et une justification. Non pas seulement ce que fait l'outil, mais pourquoi il a été jugé nécessaire de le faire ainsi. Une justification qu'on n'a jamais formulée est une décision qu'on ne peut pas réexaminer.

Un contexte de déploiement. Où l'outil tourne, dans quel processus, à quel moment, pour décider de quoi.

Deux spécifications distinctes, celle de l'outil et celle du modèle. Cette séparation est peut-être la ligne la plus instructive du formulaire. Elle acte que l'outil qu'on met en service et le modèle qui l'anime sont deux objets, avec deux propriétaires possibles, deux cycles de vie et deux jeux de garanties. C'est une distinction que beaucoup d'organisations découvrent le jour où le modèle change sous l'outil, et c'est aussi la frontière sur laquelle le règlement européen sur l'IA fait porter deux régimes différents, à des dates différentes, sur des personnes différentes.

Deux spécifications de données, celles du développement et celles de l'exploitation. Ce qui a servi à construire, et ce qui circule une fois en service. Là encore, deux questions que l'usage courant confond, et deux régimes de risque qui n'ont rien à voir.

Les risques, les mesures qui les réduisent, et les évaluations d'impact. La feuille finale, celle qui ne peut pas être remplie honnêtement si les huit précédentes ne le sont pas.

Ce que ce formulaire demande de savoir

Reprenons la liste en oubliant complètement qu'elle vient d'une administration. Pour remplir ces neuf feuilles sur un système, il faut être capable de dire :

  • quel est cet outil, en une page qu'un profane comprend ;
  • qui en répond, nommément ;
  • pourquoi il a été construit comme ça plutôt qu'autrement ;
  • dans quel processus réel il intervient, et sur quoi il pèse ;
  • ce qu'est l'outil, et séparément ce qu'est le modèle qui l'anime ;
  • avec quelles données il a été construit ;
  • quelles données le traversent en service ;
  • où il ne s'applique pas ;
  • ce qui peut mal se passer, et ce qui a été mis en face.

Aucune de ces neuf questions n'est une question juridique. Ce sont des questions d'ingénierie, posées dans l'ordre où un concepteur devrait pouvoir y répondre. Nous avions proposé un jeu plus court dans le même esprit, quatre questions à poser avant de brancher un outil d'IA : celles-là valent pour un outil qu'on achète, les neuf feuilles pour un système qu'on met en service. Le mérite du document n'est pas de les avoir inventées : c'est de les avoir arrêtées, publiées, et rendues remplissables. Une exigence qui tient dans un classeur cesse d'être une intention.

C'est la raison pour laquelle ce formulaire nous intéresse bien au-delà du régime qui l'impose. La plupart des organisations n'ont pas de mauvaise volonté sur la documentation de leurs systèmes ; elles n'ont pas de format. Elles savent qu'il faudrait écrire quelque chose, sans savoir quoi, ni quand s'arrêter. Neuf feuilles nommées répondent aux trois questions à la fois.

L'exercice qui coûte une heure

Prenez un système d'IA qui tourne aujourd'hui chez vous — un assistant, un classifieur, un outil de tri, n'importe lequel. Ouvrez une page blanche et écrivez la feuille 1 : ce que c'est, en langage clair, pour quelqu'un qui n'y connaît rien.

Deux issues, et les deux sont utiles. Soit la page vient, et vous savez désormais que vous tenez ce système. Soit elle ne vient pas, et l'endroit précis où vous butez est l'information qui manquait — le propriétaire, le périmètre, les données, la limite. Dans les deux cas, l'exercice a rendu quelque chose qu'aucune réunion ne rend : un état des lieux daté.

Ce que ce billet ne dit pas

Il ne dit pas que ce formulaire s'impose à vous. Il relève d'un régime national qui vise des organismes publics, et rien de ce qui précède ne le transpose à une entreprise française ou européenne.

Il ne dit pas que le remplir suffirait à satisfaire une obligation quelconque, ici ou ailleurs.

Il ne dit pas non plus que 144 fiches mesurent une couverture. C'est un nombre de documents publiés, compté par nous sur le registre public le 6 septembre 2026 ; ce n'est ni une proportion, ni un taux de conformité, et le registre lui-même n'en publie aucun.

Enfin, il ne détaille pas les champs situés à l'intérieur de chaque feuille : ce niveau de détail vit dans le classeur téléchargeable, que nous n'avons pas déplié ici. Nous décrivons les neuf feuilles, telles qu'elles sont nommées, et rien au-delà.

Poursuivre la lecture

Trois articles qui prolongent celui-ci.

La limite que le fournisseur a écrite avant qu'on la lui trouve

La limite que le fournisseur a écrite avant qu'on la lui trouve

Un fournisseur d'IA a publié le 1er septembre 2026 une phrase que le secteur contourne : détecter les usages abusifs oblige à conserver les données assez longtemps pour les corréler. Deux principes du même article du RGPD tirent alors en sens opposés. Nous citons le texte du fournisseur, nous citons celui du règlement, et nous décrivons ce que la réponse apportée déplace — sans prétendre qu'elle tranche.
6 min de lecture
L'AI Act a allégé une obligation, et le texte explique pourquoi elle reste nécessaire sans elle

L'AI Act a allégé une obligation, et le texte explique pourquoi elle reste nécessaire sans elle

Le train de mesures omnibus du 8 juillet 2026 a été lu pour ses reports de dates. Il a aussi remplacé l'article 4 du règlement sur l'IA, celui qui porte la compétence des équipes. Nous avons mis les deux libellés côte à côte : le verbe change, et le considérant qui justifie le changement écrit que la maîtrise de l'IA doit rester une priorité stratégique indépendamment des obligations réglementaires et des sanctions potentielles.
5 min de lecture
Le signal s'efface au moment précis où le travail devient réel

Le signal s'efface au moment précis où le travail devient réel

Le filigrane textuel mesure la conservation d'un choix de mots — or relire sérieusement consiste précisément à ne pas le conserver. Le texte le plus travaillé porte donc le moins de trace de son travail. Ce que cela dit d'une preuve héritée d'un fournisseur, et les cinq usages, dont quatre non réglementaires, d'un état antérieur daté.
7 min de lecture

Partager: