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.
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.
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.
Elles portent ces intitulés, dans cet ordre :
| Feuille | |
|---|---|
| 1 | Owner and responsibility |
| 2 | Description and Rationale |
| 3 | Deployment Context |
| 4 | Tool Specification |
| 5 | Model Specification |
| 6 | Development Data Specification |
| 7 | Operational Data Specification |
| 8 | Risks, 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.
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 :
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.
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é.
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à.
Trois articles qui prolongent celui-ci.