Documentation technique d’un système d’IA : ce qu’elle est, ce qu’elle doit contenir et comment la préparer avant qu’elle ne devienne obligatoire

L’AI Act exige que tout système d’IA à haut risque dispose d’une documentation technique complète. Nous vous présentons les 16 sections qu’elle doit comporter, son articulation avec la FRIA et l’AIPD, ainsi qu’une stratégie pratique pour commencer dès aujourd’hui à documenter vos systèmes

Lorsqu’on parle de l’AI Act, la discussion se concentre généralement sur la classification des risques ou sur les sanctions. Mais il existe une obligation moins visible qui va exiger un effort opérationnel considérable de la part des entreprises : la documentation technique.

La documentation technique est le dossier complet d’un système d’IA. Ce n’est ni une synthèse pour la direction ni une fiche produit. C’est un dossier exhaustif qui décrit ce que fait le système, comment il fonctionne, quelles données il utilise, comment il est évalué, qui le supervise, comment il est sécurisé et ce qui se passe lorsqu’il tombe en panne. Pour les systèmes à haut risque, tenir cette documentation à jour n’est pas une bonne pratique : c’est une obligation légale.

Le problème, c’est que la plupart des entreprises ne documentent pas leurs systèmes d’IA avec ce niveau de détail. Elles ont du code dans des dépôts, des modèles en production, des configurations éparpillées et des connaissances réparties dans la tête de leurs ingénieurs. Transformer tout cela en une documentation technique structurée demande du temps, un processus et un modèle clair.

Dans cet article, nous vous expliquons ce qu’est la documentation technique, pourquoi l’AI Act l’exige, quelles sections elle doit comporter et comment commencer à la constituer même si vos systèmes sont déjà en production.

Qu’est-ce que la documentation technique et pourquoi en avez-vous besoin ?

La documentation technique est le document central du dossier de conformité d’un système d’IA. L’AI Act l’exige pour tous les systèmes à haut risque (tant pour les fournisseurs que pour les déployeurs) et elle doit être mise à la disposition des autorités de surveillance si elles en font la demande.

Son objectif est triple :

• Traçabilité : Elle permet de reconstituer le fonctionnement du système, les données avec lesquelles il a été entraîné ou configuré, les métriques utilisées pour l’évaluer et les personnes qui prennent les décisions relatives à son déploiement.
• Responsabilité : Elle consigne les décisions techniques et organisationnelles : pourquoi ce modèle a été choisi, pourquoi ces seuils ont été fixés, qui a approuvé la mise en production.
• Continuité opérationnelle : Si le responsable du système change de poste ou d’entreprise, la documentation permet à toute personne ayant le profil adéquat de comprendre, de maintenir et d’auditer le système.

La documentation technique n’est pas une simple formalité. C’est la mémoire institutionnelle de votre système d’IA.

Les 16 sections de la documentation technique

Sur la base des exigences de l’AI Act et des bonnes pratiques de gouvernance de l’IA, une documentation technique complète comprend les sections suivantes :

Bloc 1 : identification et contexte (sections 0-2)

1. Page de garde et métadonnées. Nom du système, version, date, product owner, responsable du déploiement, fournisseur, DPO, RSSI. État du système (conception, pilote, production, retiré). Réglementation applicable : RGPD, AI Act, DSA, DMA, NIS2.
2. Finalité et limites. Objet du système, processus pris en charge, populations et canaux inclus et exclus, cas d’abstention. Utilisation prévue selon les instructions du fournisseur. Modifications substantielles nécessitant une réévaluation.
3. Classification et rôle au titre de l’AI Act. Rôle de l’organisation (fournisseur, déployeur, importateur, distributeur). Classification du système (interdit, haut risque annexe III, haut risque intégré annexe I, limité, minimal). Évaluations requises : AIPD oui/non, FRIA oui/non.

Bloc 2 : architecture et données (sections 3-5)

1. Architecture et environnements. Schéma de bout en bout du système. Description des composants, des dépendances externes et des points de contrôle. Endpoints par environnement (développement, staging, production). Mode dégradé et continuité : RTO, RPO, preuves de tests.
2. Données et gouvernance. Inventaire des jeux de données : origine, présence de données personnelles ou sensibles, base légale du traitement, représentativité, conservation, transferts, data owner. Liens vers l’AIPD et les accords de traitement des données (DPA).
3. Méthode et configuration du système. Technique utilisée (modèle supervisé, RAG, agent, etc.), fournisseur, ID/version du modèle, paramètres clés, guardrails et politiques. Pour les systèmes RAG : top-k, reranking, fenêtres de contexte, modèles de prompt.

Bloc 3 : évaluation et supervision (sections 6-8)

1. Évaluation, métriques et seuils. Métriques avec formule, jeu de données d’évaluation, objectif, seuil et déclencheur opérationnel (révision ou rollback). Fréquence d’évaluation et responsable. C’est le cœur technique de la documentation.
2. Contrôle humain. Points de contrôle où un humain intervient. Pour chaque point : condition de déclenchement, action humaine, niveau d’autorité, preuve générée, SLA.
3. Journalisation et traçabilité. Ce qui est enregistré à chaque interaction : entrée, contexte, passages cités (en cas de RAG), sortie, scores, décision, utilisateur/agent. Durées de conservation, accès et emplacement des logs.

Bloc 4 : sécurité et transparence (sections 9-10)

1. Sécurité et continuité (NIS2/DR-BCP). Contrôles de sécurité avec preuves, périodicité, responsable et statut. RTO, RPO, résultats des tests de reprise, mode dégradé.
2. Transparence et information de l’utilisateur. Textes d’avertissement relatifs à l’IA, détectabilité des contenus synthétiques, pages explicatives. Captures et versions des avertissements.

Bloc 5 : risques et modifications (sections 11-14)

1. Risques et garanties (synthèse FRIA/AIPD). Synthèse des risques identifiés dans la FRIA et l’AIPD : risque, droit concerné, gravité × probabilité, mesures, risque résiduel, preuve.
2. Gestion des modifications. Changelog recensant chaque modification significative : ID, date, objet de la modification, impact attendu, preuves de test, décision.
3. Rôles et responsabilités (RACI). Matrice RACI pour les activités critiques : AIPD/FRIA, métriques, journalisation, sécurité, transparence, changelog, déploiement.
4. Incidents et surveillance après commercialisation. Registre des incidents avec date, description, gravité, action corrective, clôture. Lien vers les post-mortems.

Bloc 6 : clôture (sections 15-16)

1. Annexes et liens. Inventaire des documents associés : métriques, checklists, preuves RAG, changelog, runbook d’incidents, DPA, AIPD, FRIA.
2. Approbations. Signatures du product owner, du data owner/ML, du service juridique/DPO, de la sécurité/RSSI et de la direction. Date d’approbation et déclencheur de révision.

À retenir : La documentation doit être finalisée avant la Porte 2 (Gate 2, pré-déploiement) du dispositif de gouvernance de l’IA. Et elle doit être mise à jour en cas de modification substantielle ou à l’issue de la période de stabilisation après le go-live.

Exemple : ce que contiendrait la documentation d’un chatbot RAG de service client

Pour rendre les choses concrètes, voyons comment la documentation s’appliquerait à un chatbot RAG de service client sur un site e-commerce. Ce système utilise l’IA générative pour répondre aux questions des clients sur les commandes, les retours et les produits, à partir d’une base de connaissances interne.

• Classification : Risque limité (il ne figure pas à l’annexe III, mais il interagit directement avec des consommateurs). Il impose une obligation de transparence : l’utilisateur doit savoir qu’il échange avec une IA.
• Architecture : Base de connaissances indexée (documents de politiques, FAQ, catalogue produits) → recherche vectorielle (top-k=5) → reranking → LLM avec un prompt système intégrant des instructions de grounding → réponse à l’utilisateur.
• Métriques clés : Faithfulness (fidélité au contexte) ≥ 90 %, taux d’hallucinations < 5 %, satisfaction utilisateur (CSAT) ≥ 4,0/5, taux d’escalade vers un agent humain < 15 %.
• Contrôle humain : Escalade automatique lorsque le chatbot détecte une intention de réclamation formelle, une demande de remboursement supérieure à 200 € ou trois questions consécutives sans réponse satisfaisante.
• Transparence : Bannière visible : « Cet assistant utilise l’intelligence artificielle. Pour parler à un conseiller, écrivez AGENT ». Détectabilité des contenus synthétiques si des images ou des résumés sont générés.
• Sécurité : Tests réguliers de prompt injection, guardrails contre la génération d’informations sur des sujets sans rapport avec l’activité, filtrage des données personnelles dans les logs.

Même si ce système n’est pas à haut risque, le documenter selon ce modèle de documentation technique est une bonne pratique qui facilite la maintenance, l’audit interne et la démonstration de votre diligence en cas de problème.

Les erreurs que nous voyons le plus souvent dans la documentation des systèmes d’IA

• Documentation rétrospective : Le système est en production depuis des mois et personne n’a rien documenté. Reconstituer la documentation à partir de zéro est possible, mais coûteux en temps et en efforts.
• Documentation figée : La documentation est rédigée une fois et n’est jamais mise à jour. Une documentation obsolète est pire que pas de documentation du tout, car elle crée un faux sentiment de conformité.
• Se concentrer uniquement sur le modèle : La documentation ne se limite pas à la fiche du modèle d’IA. Elle couvre les données, la sécurité, le contrôle humain, la transparence, les incidents et la gouvernance organisationnelle.
• Ni métriques ni seuils : Une documentation sans métriques mesurables est un document descriptif, pas un instrument de contrôle. Vous devez savoir quand le système fonctionne bien et quand ce n’est pas le cas.
• Déconnectée de la FRIA : La documentation technique et la FRIA doivent être liées. Les risques identifiés dans la FRIA doivent apparaître dans la section 11 de la documentation, avec leurs garanties.

Stratégie pratique : comment démarrer sans vous laisser paralyser

Inutile de tout documenter d’un coup. La stratégie la plus efficace est progressive :

1. Semaines 1-2 : inventaire. Recensez tous les systèmes d’IA utilisés ou en cours de développement. Pour chacun, identifiez : nom, responsable, état (conception/pilote/production), classification préliminaire au titre de l’AI Act.
2. Semaines 3-4 : priorisation. Classez chaque système selon l’AI Act. Les systèmes à haut risque (annexe III) exigent une documentation complète ; ceux à risque limité, une documentation proportionnée.
3. Mois 2 : page de garde + classification + architecture. Complétez les sections 0-3 des systèmes prioritaires. Ce sont les plus simples, car l’information existe déjà : il suffit de la structurer.
4. Mois 3 : données + méthode + métriques. Complétez les sections 4-6. C’est la partie technique la plus dense : elle demande une coordination avec les équipes data et ingénierie.
5. Mois 4 : supervision + sécurité + transparence. Sections 7-10. C’est ici qu’interviennent les équipes opérations, sécurité et juridique.
6. Mois 5 : risques + gouvernance + approbations. Sections 11-16. Faites le lien avec la FRIA et l’AIPD, établissez la matrice RACI et obtenez les approbations.

Si vous commencez aujourd’hui à ce rythme, la documentation de vos systèmes critiques sera complète en 5 mois. Cela vous laisse de la marge avant août 2026.

La documentation technique dans le cadre de gouvernance de l’IA

La documentation technique ne vit pas de façon isolée. Dans le modèle des 5 Piliers de l’AI Transformation, c’est une pièce maîtresse du Pilier Conformité, connectée à l’ensemble de l’écosystème de gouvernance :

• Gates (portes de contrôle) : La documentation est ouverte à la Gate 1 (approbation du projet) et doit être complète pour la Gate 2 (pré-déploiement). À la Gate 3 (post-déploiement), on vérifie qu’elle est à jour.
• FRIA et AIPD : La documentation les intègre dans sa section 11 et les référence dans les annexes. Elle ne les remplace pas : elle les complète par la dimension technique.
• AI Steering Committee : Le comité IA examine la documentation dans le cadre de la décision GO/FIX/KILL. Une documentation incomplète plaide en faveur d’un FIX.
• Politique IA Lite : Les principes d’observabilité et de réversibilité de la politique sont rendus opérationnels dans les sections journalisation (8) et mode dégradé (9) de la documentation.

Qui doit participer à l’élaboration de la documentation technique ?

Une erreur fréquente consiste à considérer que la documentation technique relève exclusivement de l’équipe data ou ingénierie. En réalité, elle exige la participation coordonnée de nombreux profils :

• Product Owner / responsable métier : Définit la finalité, les limites d’utilisation et les critères de réussite du système. Responsable des sections 1 et 2.
• Data Engineer / ML Engineer : Documente l’architecture, les données, la méthode, les métriques et la journalisation. Sections 3-6 et 8.
• Juridique / DPO : Valide la classification au titre de l’AI Act, la FRIA, l’AIPD et les exigences de transparence. Sections 2, 10 et 11.
• Sécurité / RSSI : Documente les contrôles de sécurité, la continuité et les tests de reprise. Section 9.
• Opérations : Définit et documente les points de contrôle humain, le runbook d’incidents et le mode dégradé. Sections 7 et 14.

La matrice RACI (section 13) formalise ces responsabilités ; elle est essentielle pour que la documentation reste vivante après sa création initiale.

Conclusion : documentez aujourd’hui ce qui sera obligatoire demain

La documentation technique est sans doute l’obligation de l’AI Act qui demande le plus d’effort opérationnel. Un document générique ne suffit pas : chaque système a besoin de sa propre documentation, avec des données spécifiques, des métriques réelles et des décisions consignées.

La bonne nouvelle, c’est que l’essentiel de l’information existe déjà dans votre organisation. Le défi consiste à la structurer, à la centraliser et à la tenir à jour. Avec le modèle en 16 sections et un rythme progressif, vous pouvez avoir votre documentation prête avant l’entrée en vigueur de l’obligation.

Si vous avez besoin d’aide pour constituer la documentation technique de vos systèmes d’IA, définir les métriques d’évaluation ou intégrer la documentation dans votre cadre de gouvernance, chez Impulsa3 nous disposons du modèle, de la méthodologie et de l’expérience pour vous accompagner.

impulsa3.com · Transformation digitale et IA pour les PME et l’e-commerce · servicios@impulsa3.com