Dossier technique de l’AI Act : que peut-on générer ?
Votre système d’IA a changé depuis sa dernière version. Son dossier technique de l’AI Act le décrit-il encore ?
EN 30 SECONDES
La documentation technique de l’AI Act est le dossier qui décrit un système d’IA à haut risque et doit montrer comment il respecte le règlement. Elle doit rester à jour : un build peut générer les faits de chaque version, les jugements relèvent de personnes nommées.
À RETENIR · 3
- L’Article 11 demande une documentation technique tenue à jour, pas écrite une fois.
- Générez les faits de chaque version quand c’est utile, et contrôlez ce que l’outil extrait.
- Justification de conception, argumentaire des métriques et système de gestion des risques relèvent de personnes nommées.
Sur cette page
Pourquoi un dossier technique écrit à la main peut se périmer
EN BREF Un dossier technique écrit à la main a l’air terminé même quand le système change : cette dérive peut passer inaperçue, sauf si quelqu’un l’entretient.
Prenons une équipe fictive. Elle décrit bien son système d’IA : le modèle, les prompts (les instructions données au modèle), la recherche de documents, les scores de tests. Le texte colle à la version 1.4.
Puis le système bouge : un nouveau modèle, un index de recherche refait, un prompt retouché. Si le document échappe aux contrôles de livraison, il peut continuer à décrire la 1.4. Personne ne le relit.
Écrit à la main
Produit à chaque version
ATTENTION
Ceci n’est pas un conseil juridique. C’est de l’ingénierie documentaire, écrite par un ingénieur IA et smart-contract, à jour au 6 août 2026. Rien ici ne vous dit si votre système est à haut risque, et rien ici n’interprète le règlement.
Chaque Article, Annexe et date cités ici viennent du texte consolidé de l’AI Act sur EUR-Lex : le Règlement (UE) 2024/1689, modifié par le Règlement (UE) 2026/1744. Vérifiez sur EUR-Lex avant de vous y fier.
J’ai vérifié les passages modifiés sur ce règlement modificatif au Journal officiel. Le service d’assistance AI Act de la Commission disait ne pas être à jour. Évitez les sites de suivi non officiels : l’un des plus cités avait un texte périmé quand j’ai vérifié.
Dans la section suivante : Alors, qu’est-ce que ce dossier, et qui doit l’écrire ?
Ce qu’est le dossier technique, et qui l’établit
EN BREF Le dossier technique est l’affaire du fournisseur, et il doit suivre le système qu’il décrit.
L’Article 11(1) de l’AI Act vise chaque Système d’IA à haut risque Un système d’IA que le règlement classe à haut risque, par exemple au titre de l’Annexe III. Savoir si le vôtre l’est est une question juridique. Voir le glossaire. Son Fournisseur La personne ou l’organisation qui développe un système d’IA, ou le fait développer, et le met sur le marché ou en service sous son propre nom ou sa propre marque. Voir le glossaire établit un dossier avant la mise sur le marché ou la mise en service, puis le tient à jour. Le règlement l’appelle la Documentation technique Le dossier que l’Article 11 demande au fournisseur d’établir avant la mise sur le marché ou la mise en service, puis de tenir à jour. Voir le glossaire.
LES MOTS À CONNAÎTRE
- Fournisseur
- La personne ou l’organisation qui développe un système d’IA, ou le fait développer, et le met sur le marché ou en service sous son propre nom ou sa propre marque.
- Système d’IA à haut risque
- Un système d’IA que le règlement classe à haut risque, par exemple au titre de l’Annexe III. Savoir si le vôtre l’est est une question juridique.
- Documentation technique
- Le dossier que l’Article 11 demande au fournisseur d’établir avant la mise sur le marché ou la mise en service, puis de tenir à jour.
- Tag de version
- Une étiquette dans le gestionnaire de versions, comme 1.4.0, qui identifie le code et les réglages versionnés d’une livraison.
Le dossier doit montrer que le système respecte les règles du Chapitre III, Section 2. Il doit être clair et complet pour les autorités nationales compétentes et les organismes notifiés. L’Annexe IV en fixe le contenu minimal.
ADAM explique : Pensez à une étiquette imprimée à partir de la recette de chaque lot, pas recopiée. La limite : l’Annexe IV demande bien plus, plusieurs parties sont des jugements qu’aucune imprimante ne produit, et ici une personne les reconfirme à intervalles fixes.
Dans la section suivante : Quelles parties de ce dossier un build peut-il produire pour vous ?
La moitié du dossier qu’un build peut générer
EN BREF Traitez le dossier comme une sortie de build en deux moitiés : les faits lus dans la version, et les jugements d’une personne nommée.
Tout part du Tag de version Une étiquette dans le gestionnaire de versions, comme 1.4.0, qui identifie le code et les réglages versionnés d’une livraison. Voir le glossaire : le dossier décrit une version d’un système.
Sans tag de version, un dossier technique décrit un système en général, c’est-à-dire aucun en particulier.
Générez les faits tirés de sources versionnées fiables : modèles, prompts, réglages d’index, dépendances, scores d’évals. Contrôlez ce que l’outil extrait. Tout n’est pas forcément dans Git, qui garde votre historique de versions.
ÉTAPE PAR ÉTAPE
Étape 1. Poser le tag de version. Le tag fixe le sujet : le code et les réglages exacts que le dossier va décrire.
- Poser le tag de version Le tag fixe le sujet : le code et les réglages exacts que le dossier va décrire.
- Demander d’où vient chaque réponse Un manifeste, petit fichier de configuration, indique, pour chaque point de l’Annexe IV, si la réponse est un fait consigné ou un jugement.
- Les faits : les générer Versions, dépendances, architecture, dernière exécution des évals et changements depuis le dernier tag sont lus dans la version.
- Les jugements : reprendre le texte du responsable Chaque bloc de jugement vient de son responsable. Le build vérifie la date de revue et n’écrit jamais le texte.
- Produire un dossier daté Les deux moitiés sont réunies dans un même document, avec sa version et sa date. La date seule ne prouve pas qu’il est à jour : des personnes le relisent.
EN CLAIR
Un générateur peut assembler des raisons déjà validées. Il ne doit pas inventer de décision, ni prendre la place des personnes qui en répondent.
En production, je fais de la recherche de documents, de l’abstention (refuser de deviner), des évals (tests automatiques) et du red-teaming (attaques volontaires). Ce build est ma proposition pour documenter ce type de système. Je ne prétends pas qu’un client a utilisé cette mise en œuvre exacte de l’Annexe IV.
OBJET OBTENU
Les faits se génèrent, pas les jugements
NIVEAU TERMINÉ
Ce que vous savez maintenant
- Le dossier doit suivre le système quand il change : une copie écrite une fois peut se périmer.
- Un build peut remplir ce qu’une version consigne ; la raison d’être du système demande toujours une personne.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Cas fictif : votre générateur rédige un joli paragraphe sur le choix de votre modèle. Cela fait-il partie de la moitié générée ?
Non. La raison d’un choix est un jugement. Une personne l’écrit et l’approuve ; le build ne fait que reprendre ce texte approuvé.
Ingénieur web3 x IA, ancien CTO d’Integra. Auteur nommé (1 sur 5) d’ERC-3643, premier auteur d’ERC-6960, co-auteur d’ERC-7410 et co-auteur d’ERC-8203, encore à l’état de brouillon.
Un projet à livrer ou un poste à pourvoir ?
Parlons de votre besoinSuivre les notes techniques
Recevez les nouveaux articles sur l’IA en production et les smart contracts par email.