Référence publique

La Cartographie Annexe IV

L’Annexe IV est l’exigence de documentation technique du règlement IA — ce que le régulateur attend de voir lorsqu’un système d’IA à haut risque est mis sur le marché. Nous traduisons chaque exigence en source d’ingénierie où la preuve existe déjà dans une plateforme ML disciplinée, plus l’écart que nous observons le plus souvent et une sévérité par défaut. Le Diagnostic survole ces lignes ; le Sprint les analyse par système ; le Programme rend le dossier technique opérationnel pour qu’il reste à jour à mesure que vos modèles évoluent.

Annexe IV §1 — description du système

Le premier paragraphe de l’Annexe IV demande une description générale du système : ce qu’il est, sous quelle forme il est livré, avec quoi il dialogue. La plupart des lignes ont une sévérité faible par défaut parce que les artefacts existent déjà quelque part dans votre wiki d’ingénierie ou votre processus de release — l’écart est de forme, pas de fond.

  • Annexe IV §1(a)

    Finalité prévue ; personnes développant le système ; date et version

    Où la preuve réside dans votre stack
    Entrée de registre de modèles ; tag Git ; métadonnées de release-gate
    Écart fréquent
    Souvent complet dans MLflow ou W&B ; l’énoncé de finalité prévue manque parfois en prose
    Faible

  • Annexe IV §1(b)

    Coordonnées du fournisseur (nom, adresse, etc.)

    Où la preuve réside dans votre stack
    Données d’immatriculation de l’entreprise
    Écart fréquent
    Mention standard ; presque jamais un écart
    Faible

  • Annexe IV §1(c)

    Comment le système interagit avec le matériel et les logiciels qui ne font pas partie du système d’IA

    Où la preuve réside dans votre stack
    Diagrammes d’architecture des services ; contrats d’interface ; documentation SDK
    Écart fréquent
    Existe généralement dans le wiki d’ingénierie, jamais en forme Annexe IV
    Moyenne

  • Annexe IV §1(d)

    Versions des logiciels / firmwares pertinents

    Où la preuve réside dans votre stack
    Manifestes de conteneurs ; lock files ; artefacts CI
    Écart fréquent
    Existe généralement ; parfois uniquement dans les logs CI et pas dans un artefact écrit
    Faible

  • Annexe IV §1(e)

    Formes sous lesquelles le système est mis sur le marché — produit en boîte, API en ligne, SDK embarqué, etc.

    Où la preuve réside dans votre stack
    Documentation produit / release
    Écart fréquent
    Généralement clair côté produit ; nécessite un énoncé écrit en une ligne
    Faible

  • Annexe IV §1(f)

    Description du matériel sur lequel le système s’exécute

    Où la preuve réside dans votre stack
    Infra-as-code (Terraform, Pulumi, etc.) ; manifestes de déploiement
    Écart fréquent
    Souvent complet en IaC ; nécessite un résumé en prose
    Faible

  • Annexe IV §1(g)

    Journaux de validation et de tests, signés et datés

    Où la preuve réside dans votre stack
    Historique des runs MLflow / W&B ; logs CI
    Écart fréquent
    Existe presque toujours ; la discipline de signature et de datation manque
    Moyenne

  • Annexe IV §1(h)

    Description de l’interface utilisateur (le cas échéant)

    Où la preuve réside dans votre stack
    Documentation UX ; captures d’écran utilisateur
    Écart fréquent
    Existe généralement pour le B2C ; plus mince pour les produits API uniquement
    Faible

  • Annexe IV §1(i)

    Instructions d’utilisation pour les déployeurs (le cas échéant)

    Où la preuve réside dans votre stack
    Documentation API ; guides SDK ; manuels destinés aux déployeurs
    Écart fréquent
    Existe souvent ; pas au format régulateur
    Faible

Annexe IV §2 — description technique détaillée

Le deuxième paragraphe est là où se concentre le travail : choix de conception, fiches de données, validation, modifications prédéfinies, cybersécurité. La plupart des lignes sont de sévérité moyenne à élevée parce que les artefacts existent souvent de manière informelle (cartes de modèles, discussions de conception sur Slack, notebooks d’évaluation) mais pas dans une forme lisible par le régulateur.

  • Annexe IV §2(a)

    Logique générale / méthodologie utilisée pour développer le système

    Où la preuve réside dans votre stack
    Carte de modèle ; document de conception ; notes de type ADR
    Écart fréquent
    Écart le plus fréquent — les cartes de modèles sont rarement écrites avec la discipline qu’exige l’Annexe IV
    Élevée

  • Annexe IV §2(b)

    Choix de conception, hypothèses clés, justification

    Où la preuve réside dans votre stack
    Idem §2(a), plus historique de commits et discussions de conception
    Écart fréquent
    Même schéma que §2(a) — les hypothèses vivent dans la mémoire collective, pas par écrit
    Élevée

  • Annexe IV §2(c)

    Description de l’architecture du système

    Où la preuve réside dans votre stack
    Diagrammes d’architecture ; documentation des services
    Écart fréquent
    Existe généralement ; nécessite un document à la forme Annexe IV
    Moyenne

  • Annexe IV §2(d)

    Fiches de données — sources, données d’entraînement / validation / test, lignée, biais

    Où la preuve réside dans votre stack
    Documentation des données ; configurations ETL ; outils de lignée de données
    Écart fréquent
    Écart fréquent — la plupart des équipes ont la lignée mais pas les fiches de données
    Élevée

  • Annexe IV §2(e)

    Description du contrôle humain (alignement Article 14)

    Où la preuve réside dans votre stack
    UX produit montrant les affordances de relecture humaine ; supports de formation des relecteurs
    Écart fréquent
    Souvent informel ; nécessite un design écrit du contrôle humain
    Moyenne

  • Annexe IV §2(f)

    Modifications prédéfinies / comportement d’apprentissage continu

    Où la preuve réside dans votre stack
    Journal de gestion des modifications ; configuration de feature flags ; document de cadence de réentraînement
    Écart fréquent
    Existe souvent dans le processus ; pas par écrit
    Moyenne

  • Annexe IV §2(g)

    Procédures de validation et de test, métriques incluses

    Où la preuve réside dans votre stack
    Rapports W&B ; code d’évaluation ; pipelines de test
    Écart fréquent
    Existe généralement ; pas signé et daté
    Moyenne

  • Annexe IV §2(h)

    Mesures de cybersécurité

    Où la preuve réside dans votre stack
    Documentation SOC 2 / ISO 27001 ; modèle de menaces ; runbook de réponse aux incidents
    Écart fréquent
    Existe souvent pour les équipes matures SOC 2 ; nécessite un mappage à la forme Annexe IV
    Moyenne

  • Annexe IV §2(i)

    Algorithmes utilisés (lorsque divulguables)

    Où la preuve réside dans votre stack
    Cartes de modèles ; architecture publiée
    Écart fréquent
    Généralement divulguable sous forme synthétique
    Faible

Annexe IV §3–§9 — couches opérationnelles et de gouvernance

Les paragraphes restants couvrent la supervision, les métriques de performance, le système de gestion des risques, les modifications de cycle de vie, les normes harmonisées, la déclaration de conformité et la surveillance après commercialisation. L’écart le plus important sur la plupart des missions est le §9 — le plan de surveillance après commercialisation existe rarement par écrit à notre arrivée.

  • Annexe IV §3

    Informations détaillées sur la supervision, le fonctionnement et le contrôle du système

    Où la preuve réside dans votre stack
    Tableaux de bord de supervision ; documents SLO ; runbook on-call
    Écart fréquent
    Existe souvent dans les docs SRE ; nécessite la forme Annexe IV
    Moyenne

  • Annexe IV §4

    Métriques de performance, y compris par sous-groupe démographique (lien vers Article 15)

    Où la preuve réside dans votre stack
    Métriques par sous-groupe dans le pipeline d’entraînement (fairlearn, Aequitas)
    Écart fréquent
    Écart fréquent — calculé à l’entraînement mais pas exporté par système livré
    Élevée

  • Annexe IV §5

    Description du système de gestion des risques au sens de l’Article 9

    Où la preuve réside dans votre stack
    Document SGR écrit
    Écart fréquent
    Existe rarement par écrit ; parfois informel dans les processus de revue d’incidents
    Élevée

  • Annexe IV §6

    Description des modifications pertinentes au cours du cycle de vie du système

    Où la preuve réside dans votre stack
    Journal de gestion des modifications ; CHANGELOG.md
    Écart fréquent
    Souvent complet dans Git ; nécessite un résumé en prose
    Faible

  • Annexe IV §7

    Normes harmonisées appliquées (le cas échéant)

    Où la preuve réside dans votre stack
    Mappage ISO 42001 / normes harmonisées
    Écart fréquent
    Rarement applicable en 2026 ; à signaler le cas échéant
    Faible

  • Annexe IV §8

    Copie de la déclaration UE de conformité (Article 47)

    Où la preuve réside dans votre stack
    Modèle de déclaration, signé
    Écart fréquent
    Rédigée dans le cadre du palier Programme
    Moyenne

  • Annexe IV §9

    Plan de surveillance après commercialisation (lien vers Article 72)

    Où la preuve réside dans votre stack
    Document de plan SAC
    Écart fréquent
    Plus grand écart unique — le plan SAC existe rarement par écrit à l’entrée en mission
    Critique

Articles opérationnels associés à la Cartographie

Cinq articles dont les pistes de preuve sont fréquemment incluses dans le dossier technique, même s’ils sont en dehors de l’Annexe IV proprement dite. Article 12 (enregistrement), Article 13 (transparence vis-à-vis des déployeurs), Article 14 (contrôle humain), Article 15 (exactitude, robustesse et cybersécurité) et Article 73 (signalement d’incidents avec horloges 15 / 10 / 2 jours).

  • Article 12

    Enregistrement automatique des événements pertinents pour la traçabilité

    Où la preuve réside dans votre stack
    Logs structurés au niveau de la couche d’inférence ; trace IDs
    Écart fréquent
    Existe généralement ; nécessite une preuve de traçabilité et une politique de rétention
    Moyenne

  • Article 13

    Transparence / instructions destinées aux déployeurs

    Où la preuve réside dans votre stack
    Documentation destinée aux déployeurs
    Écart fréquent
    Existe généralement pour le SaaS ; mince pour l’embarqué
    Moyenne

  • Article 14

    Conception du contrôle humain

    Où la preuve réside dans votre stack
    Patterns UX plus runbook on-call
    Écart fréquent
    Identique au §2(e) ; fusionnés en pratique
    Moyenne

  • Article 15

    Évaluation de l’exactitude, de la robustesse et de la cybersécurité

    Où la preuve réside dans votre stack
    Rapports d’évaluation plus rapports de tests adversariaux
    Écart fréquent
    Les tests de robustesse et de cybersécurité manquent souvent
    Élevée

  • Article 73

    Workflow de signalement d’incidents graves (horloges 15 / 10 / 2 jours)

    Où la preuve réside dans votre stack
    Rota on-call plus processus d’incident ; SLA de classification
    Écart fréquent
    La détection existe ; le SLA de signalement presque jamais
    Élevée

Comment la Cartographie est appliquée par mission

Les valeurs par défaut sont typiques d’une équipe ML de série B/C. À chaque mission, la sévérité est ajustée en fonction de l’importance pour les Achats, de l’effort d’ingénierie pour la combler et de l’exposition aux sanctions — les liens vers Article 5 et Article 9 font passer les lignes à Critique.

  • Diagnostic

    Survol qualitatif des 30 lignes pour jusqu’à 3 systèmes. Écarts matériels signalés.

    → Synthèse d’écarts en une page.

  • Readiness Sprint

    Analyse complète des 30 lignes par système. Chaque ligne reçoit un statut, une sévérité et une note de preuve.

    → Document d’analyse d’écarts Annexe IV.

  • Programme

    La Cartographie devient opérationnelle. Les nouveaux déploiements alimentent automatiquement les bonnes lignes.

    → Dossier technique Annexe IV v1.0 maintenu, plus le workflow qui le tient à jour.

Voir la Cartographie appliquée à votre stack

Le Diagnostic produit une synthèse d’écarts en une page en 3 à 5 jours. — nous confirmons la classification et les écarts à plus fort impact à l’appel, gratuitement.

Prendre contact

Dites-nous où vous en êtes. Réponse sous un jour ouvrable, sans pitch commercial : une lecture rapide de votre exposition au règlement et le bon point de départ.