MLOps conforme ISO 27001 et NIS 2 — pipeline IA sécurisé

La conformite des pipelines MLOps aux referentiels ISO 27001 et NIS 2 est devenue une preoccupation majeure pour les DSI et RSSI en 2026. L'acceleration du deploiement des modeles ML en production -- LLM, modeles de detection d'anomalies, systemes de recommendation, outils de scoring -- a cree une proliferation de pipelines IA qui operent souvent en dehors du cadre de securite et de gouvernance IT habituel. Les modeles ML ont des caracteristiques de risque specifiques qui les distinguent des logiciels classiques : ils peuvent deriver de leur comportement attendu suite a un changement de distribution des donnees, ils sont vulnerables a des attaques specifiques (empoisonnement, evasion adversariale), leurs decisions peuvent impacter significativement des personnes (decisions de credit, scoring RH, diagnostics medicaux) et elles sont soumises a des obligations de traçabilite, et la supply chain des modeles (datasets, modeles pre-entraines, librairies ML) presente des risques specifiques. Ce guide detaille comment implementer un pipeline MLOps conforme ISO 27001 et NIS 2, en couvrant la gouvernance des modeles, la securite du CI/CD ML, la gestion des secrets, et l'audit trail requis.

Gouvernance des modeles ML -- versioning, validation et approbation

La gouvernance des modeles ML est le premier pilier d'un MLOps conforme. Sans gouvernance formalisee, les modeles ML sont deployes en production sans validation adequate, sans documentation de leurs limites, et sans processus de retrait en cas de probleme. Les elements cles :

Le Model Registry (registre des modeles) est l'equivalent du catalogue CMDB pour les modeles ML : il centralise tous les artefacts ML (modeles, versions, metadonnees, metriques de performance, historique d'approbation). Des outils comme MLflow Model Registry, Weights & Biases Model Registry, ou le registre integre de Vertex AI permettent de gerer le cycle de vie complet des modeles. Chaque modele dans le registre doit inclure : la version du code d'entrainement (lien Git commit), les donnees d'entrainement utilisees (nom du dataset, version, hash), les hyperparametres d'entrainement, les metriques de performance sur le jeu de validation (accuracy, F1, AUC, etc.), les metriques de biais et d'equite si applicable, et le responsable de la validation (approbateur designe).

Le processus d'approbation des modeles avant production doit etre formalisé et trace : revue technique par l'equipe ML (validation des metriques, tests de robustesse), revue securite par le RSSI (analyse des risques specifiques au modele), revue fonctionnelle par le metier (validation de la pertinence des outputs), et validation juridique si le modele prend des decisions impactant des personnes. Ce processus doit etre documente dans le Model Registry avec les signatures electroniques des approbateurs.

Data lineage -- traçabilite des donnees d'entrainement

Le data lineage (lignée des données) trace l'origine et les transformations de chaque dataset utilise pour entrainer ou evaluer un modele ML. Il est critique pour :

• Conformite RGPD : identifier quelles donnees personnelles ont ete utilisees pour entrainer quels modeles, et pouvoir supprimer un modele ou le re-entrainer sans ces donnees si une personne exerce son droit a l'effacement
• Detection d'empoisonnement : tracer l'origine de chaque enregistrement du dataset d'entrainement pour identifier et isoler des donnees potentiellement empoisonnees si un biais ou comportement anormal est detecte apres deploiement
• Audit trail reglementaire : prouver aux auditeurs ISO 27001 et aux autorites de controle (CNIL, AMF, autorites sectorielles) que les modeles ML ont ete entraines sur des donnees conformes et validees
• Reproductibilite : etre capable de re-entrainer exactement le meme modele avec les memes donnees et le meme code pour des raisons de debugging ou de validation post-incident

CI/CD securise pour les modeles ML -- DevSecML

Le pipeline CI/CD ML securise (que l'on peut appeler DevSecML, par analogie avec DevSecOps) integre des controles de securite specifiques au cycle de vie des modeles ML :

• Scanning des dependances ML : les librairies ML (TensorFlow, PyTorch, Transformers, scikit-learn) ont des vulnerabilites comme tout logiciel. Integrer un SCA (Software Composition Analysis) dans le pipeline CI pour detecter les CVE dans les dependances ML avant le deploiement.
• Validation des modeles pre-entraines : les modeles telecharges depuis HuggingFace Hub ou d'autres registres doivent etre verifies par leur hash SHA256 avant d'etre utilises. Un modele pre-entraine compromis peut contenir un backdoor qui se manifeste sur des inputs specifiques.
• Tests adversariaux automatises : integrer dans la pipeline CI/CD des tests adversariaux qui verifient la robustesse du modele face aux attaques connues. Pour les LLM, des tests de jailbreak automatises (utilisant des datasets de prompts adversariaux comme HarmBench) peuvent valider que les guardrails fonctionnent correctement apres chaque mise a jour du modele.
• Analyse de biais automatisee : pour les modeles prenant des decisions impactant des personnes, des tests d'equite automatises (disparate impact analysis, calibration par groupe) doivent s'executer a chaque mise en production.

# Exemple pipeline GitLab CI/CD MLOps securise
stages:
  - validate-data
  - train
  - evaluate
  - security-scan
  - approve
  - deploy

security-scan:
  stage: security-scan
  script:
    - pip install safety pip-audit
    - pip-audit --requirement requirements.txt
    - python scripts/verify_model_hash.py --model $MODEL_PATH --hash $EXPECTED_HASH
    - python scripts/adversarial_tests.py --model $MODEL_PATH --threshold 0.95
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request"

approve:
  stage: approve
  when: manual
  allow_failure: false
  script:
    - python scripts/register_model.py --model $MODEL_PATH --approver $GITLAB_USER_LOGIN

Gestion des secrets dans les pipelines ML -- GPU credentials et API keys

La gestion des secrets dans les pipelines MLOps est particulierement complexe en raison de la multiplicite des credentials impliques :

• Cles API LLM (OpenAI, Anthropic, Mistral) : ne jamais hardcoder dans le code ou les fichiers de configuration. Utiliser un gestionnaire de secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) avec rotation automatique.
• Credentials des registres de modeles (HuggingFace token, MLflow credentials) : gerer via les secrets CI/CD (GitLab CI Variables, GitHub Secrets) avec des tokens a duree de vie limitee.
• Credentials cloud GPU (AWS EC2 IAM role, GCP Service Account pour les instances GPU) : utiliser des identites managees (IAM role pour EC2, Workload Identity pour GKE) plutot que des cles statiques pour les workloads cloud.
• Cles de chiffrement des modeles : les modeles fine-tunes sur des donnees sensibles doivent etre chiffres au repos. Les cles de chiffrement doivent etre dans le gestionnaire de secrets, pas dans le code ni dans les artefacts ML.

Une erreur classique dans les projets MLOps : les developpeurs incluent leurs tokens HuggingFace ou leurs cles API LLM dans les notebooks Jupyter qui sont ensuite commites dans git. Le scan pre-commit avec des outils comme detect-secrets ou GitGuardian permet de prevenir ces fuites. La securite des secrets ML s'inscrit dans le cadre de securite general decrit dans notre guide PSSI et notre guide Zero Trust.

Audit trail et logging pour la conformite ISO 27001

L'audit trail des systemes ML est une exigence ISO 27001 (controle 8.15 -- Logging) et NIS 2 (Article 21 sur la gestion des risques et la traçabilite). Les elements de l'audit trail ML :

• Logging des predictions : enregistrer chaque inference du modele avec : timestamp, identifiant de requete, version du modele, version des features d'entree (hash), classe/score predite. Les inputs eux-memes ne doivent pas etre logges si ils contiennent des donnees personnelles (sauf consentement et base legale).
• Logging des evaluations et derives : enregistrer les metriques de performance du modele calculees periodiquement sur des donnees de production (performance monitoring). Alerter quand les metriques sortent des seuils acceptables definis lors de la validation.
• Audit trail des modifications : tout changement de version de modele en production (deploiement, rollback) doit etre trace avec : qui a initie le changement, qui l'a approuve, quand, et quelle version precedente a ete remplacee.
• Retention des logs : ISO 27001 requiert generalement une retention des logs d'au moins 1 an. Pour les systemes soumis a des regulations sectorielles (finance, sante), la retention peut etre de 3 a 10 ans.

ISO/IEC 42001 -- le nouveau referentiel IA management

L'ISO/IEC 42001, publie en decembre 2023, est le premier referentiel international specifique aux systemes de management de l'intelligence artificielle. Il complemente ISO 27001 (securite de l'information) en ajoutant des exigences specifiques a la gouvernance IA :

La norme ISO 42001 requiert l'etablissement d'un AI Management System (AIMS) couvrant le cycle de vie complet des systemes IA : identification et classification des systemes IA par niveau de risque, evaluation de l'impact des systemes IA sur les personnes et l'organisation, politiques d'usage responsable de l'IA, processus de surveillance et d'evaluation continue, et gestion des incidents specifiques a l'IA. Pour les organisations deja certifiees ISO 27001, l'integration ISO 42001 est facilitee par la structure harmonisee des normes ISO (HLS) : les clauses de contexte, leadership, planification, support, operations, evaluation de performance et amelioration sont identiques, et les controles IA s'ajoutent aux controles de securite existants.

L'AI Act europeen (Reglement UE 2024/1689) cree une convergence reglementaire avec ISO 42001 pour les systemes IA a haut risque. Les organisations qui obtiennent la certification ISO 42001 disposent d'un avantage significatif pour demonstrer la conformite AI Act : les processus de gestion des risques IA, de documentation technique et de surveillance post-marche requis par l'AI Act recoupent largement les exigences ISO 42001. Pour les equipes MLOps, ISO 42001 fournit un cadre concret pour documenter les processus de validation des modeles, la gestion des incidents IA, et les politiques d'utilisation responsable. Notre guide ISO 27001 presente le cadre complementaire de securite de l'information applicable aux systemes IA.

Model drift detection -- surveillance continue en production

La detection de la derive des modeles (model drift) est une specificite MLOps critique pour maintenir la conformite et la qualite des systemes ML en production. Deux types de derive :

La data drift (derive des donnees) : la distribution des donnees d'entree change par rapport a la distribution du dataset d'entrainement. Pour un modele de detection de fraude entraine sur des transactions de 2024, l'apparition de nouveaux patterns de paiement en 2026 (nouvelles methodes de paiement, nouvelles geographies) peut degrader ses performances sans que les metriques le signalent immediatement si les labels ne sont pas disponibles rapidement. Les outils de detection de data drift (Evidently AI, WhyLogs, Great Expectations) comparent statistiquement les distributions des features entre la periode d'entrainement et la production.

Le concept drift : la relation entre les features et la cible change. Pour un modele de prevision de la demande, un changement economique majeur (crise, nouvelle technologie) peut invalider les correlations historiques sur lesquelles le modele a appris. La detection du concept drift necessite des labels de production (connaitre les vraies valeurs cibles en production) qui peuvent arriver avec delai. Pour les organisations soumises a NIS 2, la detection de la derive des modeles utilises dans des processus critiques doit etre integree dans le programme de surveillance continue. Notre guide NIS 2 et notre guide ISO 27001 detaillent les obligations de surveillance applicable aux systemes IA.

FAQ -- MLOps conforme ISO 27001 et NIS 2

Quelles clauses ISO 27001 s'appliquent specifiquement aux systemes ML et IA ?

ISO 27001:2022 ne contient pas de clauses specifiques a l'IA, mais plusieurs controles s'appliquent directement. Controle 8.8 (Gestion des vulnerabilites techniques) : les modeles ML sont des composants logiciels susceptibles de vulnerabilites (adversarial attacks, model poisoning) qui doivent etre geres comme les autres vulnerabilites logicielles. Controle 8.9 (Gestion de la configuration) : les hyperparametres, architectures et versions de modeles sont des configurations a gerer et auditer. Controle 8.15 (Logging) : les predictions et evaluations des systemes ML doivent etre loggees. Controle 8.20 (Securite des reseaux) et 8.21 (Securite des services reseau) : les endpoints d'inference ML sont des services reseau necessitant une protection adequate. Controle 5.9 (Inventaire des actifs) : les modeles ML sont des actifs informationnels a inventorier et classifier. Le guide ISO 27001 specifique aux systemes IA de l'ISO/IEC 42001 (IA Management System), publie fin 2023, fournit un complement specifique IA tres utile. Notre guide ISO 27001 couvre l'application pratique de ces controles.

Comment documenter les risques specifiques aux modeles ML dans le registre des risques ISO 27001 ?

La documentation des risques ML dans le registre des risques ISO 27001 doit couvrir plusieurs categories de risques specifiques. Le risque de derive du modele : la probabilite et l'impact d'une degradation des performances du modele en production, avec les controles (monitoring, alertes, procedures de re-entrainement) et le risque residuel accepte. Le risque d'attaque adversariale : la probabilite qu'un attaquant exploite des vulnerabilites specifiques au modele (injection de prompt pour les LLM, evasion adversariale pour les modeles de detection), l'impact potentiel, et les mesures de mitigation (tests adversariaux reguliers, monitoring des outputs). Le risque de biais et de discrimination : la probabilite que le modele produise des outputs discriminatoires, l'impact juridique et reputationnel, et les controles (tests d'equite, revue periodique). Le risque supply chain ML : la probabilite que des modeles ou datasets de sources tierces soient compromis, et les controles (verification des hashes, sources de confiance, isolation des modeles tiers). Chaque risque doit inclure le proprietaire du risque, l'evaluation probabilite x impact, les controles mis en place, et le risque residuel.

Quelles sont les obligations specifiques NIS 2 pour les systemes ML critiques ?

NIS 2 (Directive 2022/2555) impose aux operateurs essentiels et importants des obligations qui s'appliquent a leurs systemes ML critiques. L'Article 21 NIS 2 sur les mesures de gestion des risques requiert une analyse de risque specifique pour les systemes ML utilises dans des processus critiques (detection de fraude, controle industriel, gestion des incidents). Cela inclut l'identification des vulnerabilites specifiques au ML (derive, attaques adversariales), les mesures de mitigation et leur periodicite de revue. L'Article 23 NIS 2 sur la notification des incidents s'applique aux incidents impliquant des defaillances de systemes ML critiques qui ont un impact significatif sur les services : une defaillance d'un modele ML de detection d'anomalies dans une infrastructure critique qui aurait permis une intrusion non detectee doit potentiellement etre notifiee. La gestion des fournisseurs tiers (Article 21.2.d) s'applique aux editeurs de modeles pre-entraines et aux fournisseurs d'infrastructure ML cloud. Notre guide NIS 2 complet detaille l'ensemble des obligations.

Comment integrer la conformite RGPD dans un pipeline MLOps qui traite des donnees personnelles ?

L'integration RGPD dans un pipeline MLOps traitant des donnees personnelles necessite plusieurs mesures specifiques. La base legale du traitement : identifier et documenter la base legale pour chaque traitement de donnees personnelles dans le pipeline (consentement, interet legitime, obligation legale). Pour l'entrainement de modeles, la base legale doit couvrir explicitement le traitement dans ce but. L'analyse d'impact (AIPD) : les pipelines ML a haut risque (scoring, profiling, decisions automatisees) necessite une AIPD avant deploiement, documentant les risques pour les personnes et les mesures de mitigation. La minimisation des donnees : entrainer les modeles sur le minimum de donnees personnelles necessaires, et pseudonymiser ou anonymiser autant que possible avant l'entrainement. Le droit a l'oubli : implementer un mecanisme pour retirer les donnees d'un individu specifique du dataset d'entrainement et evaluer si un re-entrainement est necessaire (machine unlearning). La minimisation de la retention : supprimer les donnees d'entrainement des systemes de stockage apres utilisation selon la politique de retention documentee. Notre guide ISO 27001 integre les interactions entre ISO 27001 et RGPD.

Quels outils MLOps open source sont les plus adaptes pour la conformite ISO 27001 ?

Plusieurs outils MLOps open source facilitent la conformite ISO 27001. MLflow est le plus adopte pour le tracking d'experiments, le model registry, et le deploiement : il fournit nativement la traçabilite des modeles, des datasets et des metriques. DVC (Data Version Control) est l'outil de reference pour la gestion des versions de datasets et la traçabilite des donnees d'entrainement via des commits Git. Evidently AI est specialise dans la surveillance en production et la detection de derive des modeles, avec des rapports detailles sur la distribution des features et les metriques de performance. Great Expectations permet de valider la qualite et la conformite des donnees en entree des pipelines d'entrainement, avec une documentation automatique des contraintes. Pour le CI/CD, GitLab CI ou GitHub Actions avec des workflows dediés ML permettent d'automatiser la validation, les tests adversariaux, et le processus d'approbation. La combinaison MLflow + DVC + Evidently + GitLab CI couvre la grande majorite des exigences de traçabilite et de surveillance requises par ISO 27001 pour les systemes ML, avec un cout open source. Pour les aspects de securite de l'infrastructure, notre guide Zero Trust s'applique a l'infrastructure MLOps.

Conclusion

Un pipeline MLOps conforme ISO 27001 et NIS 2 n'est pas un luxe mais une necessite pour les organisations qui deploient des modeles ML dans des processus critiques ou reglementés. Les investissements dans la gouvernance des modeles, la traçabilite, la securite de la supply chain ML et la detection de derive sont des investissements dans la durabilite et la fiabilite de vos systemes IA. Commencez par l'inventaire de vos modeles ML en production et leur classification par niveau de criticite, puis construisez progressivement les processus de gouvernance, de validation et de surveillance adaptes. Consultez notre guide ISO 27001 pour le cadre de conformite global, notre guide NIS 2 pour les obligations specifiques, et notre article sur la souverainete IA pour la strategie de deploiement on-premise conforme.