Penser sécurité IA en grand sac fourre-tout, c'est rater 80% des contrôles concrets. La bonne décomposition c'est par phase du cycle de vie ML, parce que chaque phase a des risques propres et des contrôles propres. Voilà la grille que j'utilise en mission cadrage.
Les 6 phases du cycle de vie ML
- Collecte des données
- Préparation et labellisation
- Entraînement / fine-tuning
- Évaluation et validation
- Déploiement
- Monitoring et retrait
Une donnée peut traverser les 6 phases sur plusieurs mois, voire années. Chaque transition est une zone de risque. Voici ce que je vérifie.
Phase 1 — Collecte des données
Risques majeurs : data poisoning à la source, PII non consentées, licence incompatible, supply chain dataset.
Contrôles :
- Provenance documentée par dataset (source, contrat, date, hash).
- Évaluation fournisseur pour les datasets externes (réputation, contrat, droit d'audit).
- Pas de scraping web non encadré (risque RGPD + droits d'auteur).
- Scan PII automatique à l'arrivée (Presidio, scrubadub, regex métier).
- Politique de consentement vérifiée pour données personnelles.
Vérification : audit annuel des datasets actifs avec traçabilité par dataset.
Phase 2 — Préparation et labellisation
Risques majeurs : empoisonnement label, biais introduits par labelers, fuite PII vers labelers externes.
Contrôles :
- Workflow de labellisation tracé (qui a labellisé quoi, quand).
- Double labellisation sur les labels critiques + résolution de conflit.
- Labelers externes : NDA, accès données restreint, pseudonymisation.
- Outils de labellisation auto-hébergés pour les contextes sensibles (santé, défense, secret professionnel).
- Échantillonnage qualité labels par revue humaine périodique.
Vérification : taux d'agreement entre labelers + sample audit mensuel.
Phase 3 — Entraînement / fine-tuning
Risques majeurs : compromission infrastructure entraînement, fuite secrets, modèle compromis (backdoor), mauvaise séparation train/test (data leakage).
Contrôles :
- Environnement d'entraînement isolé (service account dédié, réseau restreint).
- Pas de credentials en clair dans les notebooks/scripts.
- Code review des scripts d'entraînement.
- Logs d'entraînement structurés et stockés.
- Reproductibilité documentée (seeds, versions, hyperparams).
- Vérification stricte de la séparation train/val/test.
Vérification : test de reproductibilité périodique + audit notebooks.
Phase 4 — Évaluation et validation
Risques majeurs : modèle qui passe l'évaluation qualité mais a une backdoor, modèle biaisé non détecté, fuites memorization non testées.
Contrôles :
- Suite de tests qualité classique (métriques métier).
- Suite de tests sécurité adversariale (PyRIT, DeepTeam, voir stack outils sécurité IA).
- Tests memorization (essai de récupération de données training).
- Tests de fairness sur sous-populations.
- Tests de robustesse adversariale (inputs perturbés).
- Approbation formelle par owner sécu avant promotion.
Vérification : rapport d'évaluation avant chaque promotion modèle.
Phase 5 — Déploiement
Risques majeurs : modèle non signé déployé, mauvais modèle promu, surface API trop large, secrets exposés.
Contrôles :
- Signature des artefacts modèle (Sigstore, Cosign sur l'image).
- Vérification signature au déploiement.
- Endpoint d'inférence rate-limité, authentifié.
- Configuration runtime (model name, version) versionnée et change-controlled.
- Capacité de rollback rapide.
- Plan de communication si retrait d'urgence.
Vérification : checklist déploiement signée à chaque release.
Phase 6 — Monitoring et retrait
Risques majeurs : dégradation silencieuse, attaque d'extraction non détectée, modèle obsolète qui reste en prod, données qui doivent être supprimées (RGPD).
Contrôles :
- Monitoring drift en continu (distribution inputs, distribution outputs).
- Détection d'attaques (extraction, adversarial, voir data poisoning et model leakage).
- Logs d'inférence structurés (sans PII en clair).
- Plan de retrait : conditions, qui décide, comment on supprime.
- Droit à l'effacement (RGPD article 17) opérable.
- Politique de rétention des modèles obsolètes (archive ? destruction ?).
Vérification : tableau de bord par modèle avec status, métriques, prochaine revue.
Le mapping aux référentiels
Cette grille s'aligne directement sur :
- NIST AI RMF : chaque phase alimente les fonctions MAP / MEASURE / MANAGE.
- ISO 42001 : clauses 8 (planification opérationnelle) et 9 (évaluation des performances).
- MITRE ATLAS : chaque phase a des techniques d'attaque associées.
- AI Act : exigences sur la gestion des risques (art. 9), gouvernance des données (art. 10), traçabilité (art. 12).
Avoir cette grille phase × référentiel rend le programme défendable face à un auditeur. Voir articulation des 4 cadres.
Les pièges que je vois revenir
Sécuriser une seule phase
Une équipe met en place du red teaming en évaluation (phase 4) mais ne contrôle ni la provenance dataset (1) ni le déploiement signé (5). Le maillon le plus faible définit la sécurité globale.
Croire que le MLOps couvre
Le MLOps gère le déploiement et le monitoring. Il ne gère pas la provenance dataset, la labellisation, le secret management côté training. Les contrôles sécurité doivent être greffés à chaque phase.
Pas d'owner sécu sur le cycle de vie
Si personne n'est responsable de la sécurité du modèle bout en bout, ça tombe entre les chaises. Désigner un owner par modèle, avec mandat explicite.
Ne pas re-passer après mise à jour modèle
Un modèle qui était à jour il y a 1 an doit re-passer évaluation sécu si l'environnement a changé (nouvelles attaques connues, nouveau cas d'usage métier).
Mon avis en 1 ligne
Le cycle de vie ML a 6 phases, chacune avec ses contrôles. Le programme sécurité IA doit couvrir les 6, pas une ou deux. Compter 6-12 mois pour atteindre un niveau défendable sur les 6 phases dans une organisation qui démarre, avec roadmap priorisée. C'est ce que NIST AI RMF + ATLAS valident, mais sans la grille par phase, ça reste théorique.