Organisation
Partie VI. Compliance : la preuve par la télémétrie
Pour : architectes · finance, risque et conformitéPrérequis : Avoir lu la partie I ; notions de journalisation et de rétention des données.
22. Matrice de preuve réglementaire
Section intitulée « 22. Matrice de preuve réglementaire »Principe : une bonne instrumentation produit, comme sous-produit, les preuves exigées par la réglementation. La matrice ci-dessous relie une obligation à son thème, à celui qui la porte et au signal de télémétrie qui en constitue la preuve. Le mapping précis article par article doit être validé avec le service juridique et le DPO. C’est une matrice de travail, pas un avis juridique.
L’AI Act distingue les obligations selon le rôle (le fournisseur met le système sur le marché, le déployeur l’utilise) et selon le niveau de risque. La plupart de ses lignes ci-dessous ne visent que les systèmes à haut risque ; l’article 50, lui, vise tout système qui dialogue avec des personnes ou génère du contenu, quel que soit son niveau de risque.
| Thème d’obligation | Texte et article | Qui, pour quels systèmes | Signal de télémétrie qui produit la preuve |
|---|---|---|---|
| Journalisation et traçabilité : le système enregistre automatiquement les événements pendant toute sa durée de vie | AI Act, art. 12 | fournisseur, haut risque | Traces de bout en bout horodatées avec trace_id, journal d’invocation d’outils, versions de modèle et de pipeline dans les spans |
| Documentation technique : description du système, des données, des méthodes d’évaluation et de surveillance | AI Act, art. 11 | fournisseur, haut risque | Historique des évaluations, configuration versionnée |
| Transparence et information des déployeurs : notice d’utilisation (performances attendues, limites, moyens de collecter et d’interpréter les journaux) | AI Act, art. 13 | fournisseur, haut risque | Attribution du modèle, capture de contenu contrôlée, versionnage du prompt, tableaux de bord et seuils documentés |
| Contrôle humain | AI Act, art. 14 | fournisseur, haut risque | Taux de passage à l’humain, points de validation, garde-fous tracés |
| Exactitude, robustesse et cybersécurité | AI Act, art. 15 | fournisseur, haut risque | SLO de qualité, évals continues, détection de dérive |
| Surveillance après commercialisation : collecter et analyser les données de performance tout au long de la vie du système | AI Act, art. 72 | fournisseur, haut risque | Scores qualité, dérive, coût, alertes |
| Surveillance du fonctionnement : surveiller le système selon la notice, signaler les risques | AI Act, art. 26, paragraphe 5 | déployeur, haut risque | Alertes, procédures d’escalade vers le fournisseur |
| Conservation des journaux générés automatiquement : au moins six mois, sauf autre disposition du droit de l’Union ou national | AI Act, art. 19 (fournisseurs) et art. 26, paragraphe 6 (déployeurs) | fournisseur et déployeur, haut risque | Politique de rétention documentée, rétention horodatée des traces et des journaux réglée en conséquence |
| Transparence envers les personnes : informer la personne qu’elle échange avec une IA, marquer les contenus générés | AI Act, art. 50 | fournisseur et déployeur, tout système qui interagit avec des personnes ou génère du contenu | L’obligation relève du produit, pas de l’observabilité ; la télémétrie peut seulement tracer l’affichage de l’information « vous parlez à une IA » et le marquage des contenus |
| Gestion des incidents | NIS2, art. 21, paragraphe 2, point b) | entités essentielles et importantes | Alerting sécurité, remontée SOC, MTTD et MTTR mesurés |
| Notification d’incident : alerte précoce sous 24 h, notification sous 72 h, rapport final dans un délai d’un mois | NIS2, art. 23 | entités essentielles et importantes | Horodatage de la détection, chronologie reconstituée à partir des traces |
| Sécurité de la chaîne d’approvisionnement | NIS2, art. 21, paragraphe 2, point d) | entités essentielles et importantes | Tool pinning, détection de mutation, échecs d’authentification |
| Minimisation des données | RGPD, art. 5, paragraphe 1, point c) | responsable du traitement | Contenu opt-in, masquage au collecteur |
| Protection des données dès la conception et par défaut | RGPD, art. 25 | responsable du traitement | Aucune capture de contenu par défaut, rétention séparée, traçabilité des données personnelles |
Textes : AI Act, règlement (UE) 2024/1689 ; NIS2, directive (UE) 2022/2555 ; RGPD, règlement (UE) 2016/679. Articles vérifiés le 2 octobre 2026 ; les lignes des articles 11 et 72 et celle de l’article 26, paragraphe 5 viennent du tableau fournisseur et déployeur de la formation, module 5, fusionné ici le 4 octobre 2026. Les obligations NIS2 s’appliquent à travers la loi nationale de transposition.
Une pile OpenTelemetry bien posée fournit la matière technique de ces obligations : journaux, mesures de performance, historique. Reste à qualifier votre système et votre rôle, à documenter et à tenir le dispositif dans la durée.
23. Séparation contenu et métadonnées
Section intitulée « 23. Séparation contenu et métadonnées »Règle structurante de conformité : séparer le contenu (sensible, rétention courte, accès restreint, expurgé) des métadonnées de télémétrie (faible cardinalité, rétention longue, exploitables librement). C’est le pattern de contenu externe d’OpenTelemetry généralisé à toute la pile. Souveraineté : auto-héberger les backends (par exemple VictoriaMetrics ou Prometheus, VictoriaLogs ou Loki, Grafana, Langfuse ou Phoenix) permet de choisir où résident les données.
Révisé le 2 octobre 2026 : ajout des articles de chaque texte et du calendrier issu du règlement (UE) 2026/1744 qui modifie l’AI Act.
Révisé le 4 octobre 2026 : fusion du tableau AI Act fournisseur et déployeur de la formation (module 5) dans la matrice, qui gagne une colonne « qui », les articles 11 et 72 et l’article 26, paragraphe 5 ; le calendrier n’est donné qu’une fois, dans l’encadré.