· Security musings

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
~10 minutes

Un RSSI qui ouvre en même temps l’EU AI Act, l’ISO 42001, le NIST AI RMF et un Top 10 OWASP se retrouve avec quatre vocabulaires différents pour parler du même risque. La Cloud Security Alliance vient de publier la version 1.1 de son AI Controls Matrix (AICM) : 247 objectifs de contrôle répartis sur 18 domaines, avec un mappage explicite vers chacun de ces référentiels. Un panda n’a qu’une seule liane à surveiller pour ne pas tomber ; un RSSI IA en a une bonne dizaine, et elles ne sont pas toutes tendues à la même hauteur.


La prolifération des référentiels IA est devenue, en 2026, un problème en soi. J’ai déjà couvert sur ce blog MAESTRO pour le threat modeling agentique, AISVS pour la vérification technique, MITRE ATLAS pour la cartographie des techniques adverses, et plus récemment le crosswalk AIUC-1 ↔ OWASP Top 10 Agentic. Chacun de ces référentiels répond à une question différente, mais aucun ne répond à celle que pose un DPO ou un auditeur externe : “montrez-moi vos contrôles, domaine par domaine, et dites-moi comment ils s’alignent avec la loi et les normes.”

L’AICM v1.1 est la tentative de la CSA de répondre précisément à cette question, sans pousser sa propre techno, en s’appuyant sur un existant qu’elle maîtrise déjà : le Cloud Controls Matrix (CCM), utilisé depuis des années par l’écosystème CSA STAR pour la certification cloud. L’AICM part de l’existant : c’est un sur-ensemble du CCM v4.1, étendu aux spécificités de l’IA.

Note du PandaRedacteur: Un référentiel de contrôles qui ne sait pas où il se situe par rapport aux autres n’est qu’une liste de cases à cocher de plus. L’intérêt de l’AICM v1.1 est justement de savoir se situer.


MAJ de la v1.0 à la v1.1…

On note quatre évolutions et non pas une refonte complète. Rien de spectaculaire. La CSA a choisi la continuité plutôt que la rupture, ce qui compte pour les organisations qui avaient déjà commencé à s’outiller sur la v1.0.

Note du PandaRedacteur: j’apprécie ce genre de mise à jour ; on ne change pas la forêt de bambous d’un coup, on ajoute juste une pousse là où il en manquait une.

  • Extension du périmètre : le nombre d’objectifs de contrôle passe de 243 à 247, répartis sur 18 domaines couvrant tout le cycle de vie IA, de la préparation initiale jusqu’au retrait du modèle. Ça compte : la sécurité IA ne s’arrête pas au déploiement, elle continue jusqu’à la décommission.
  • Le nouveau domaine Model Security (MDS) : 13 contrôles entièrement dédiés à la protection du modèle lui-même : empoisonnement de modèle, injections de prompt, accès non autorisé, sécurité de l’inférence. La v1.0 traitait ces sujets de façon diffuse à travers d’autres domaines ; la v1.1 leur donne un domaine à part entière. La CSA a visiblement classé ce trou en priorité haute.
  • AI-CAIQ v1.1, le questionnaire qui grossit : l’outil d’auto-évaluation associé passe à 320 questions. Utile pour structurer un audit interne, mais à ne pas sous-estimer : un questionnaire de cette taille demande une vraie mobilisation transverse entre sécurité, data science et juridique. J’ai déjà vu un questionnaire de ce format traîner six semaines parce que personne n’avait mandaté le juridique dès le départ.
  • Synchronisation avec CCM v4.1 : l’AICM reste un sur-ensemble du CCM classique, ce qui veut dire qu’une organisation déjà certifiée CSA STAR sur le CCM hérite d’une bonne partie du travail déjà fait.

Comment l’AICM se positionne par rapport a d’autres référentiels

C’est la partie la plus intéressante à comprendre : au lieu de prétendre remplacer les référentiels existants, l’AICM v1.1 publie un tableau d’alignement qui dit explicitement où il se superpose, et où il ne le fait pas (un peu comme vous l’avez dans l’ASVS de l’OWASP).

Référentiel Niveau d'alignement Ce que ça signifie concrètement
ISO 42001 eleve ~59% couverture L'AICM opérationnalise une bonne partie des exigences de management ISO, sans s'y substituer
EU AI Act modere ~20% couverture L'AICM comble le gap de sécurité infrastructurelle que le texte réglementaire ne détaille pas
NIST AI RMF severe ~7% couverture Écart intentionnel : NIST est un cadre de gestion des risques, pas une liste de contrôles techniques

Ne confondez pas un faible taux de couverture avec un mauvais référentiel : NIST AI RMF et l’AICM ne répondent pas à la même question, ils sont conçus pour se compléter, pas pour se recouvrir.


Où situer l’AICM face à MAESTRO, AISVS et MITRE ATLAS

  • MAESTRO et MITRE ATLAS / ATT&CK couvrent le volet menace : le premier cartographie quelles couches de l’architecture agentique sont exposées et à quoi (threat modeling), le second liste les techniques qu’un attaquant va réellement utiliser contre le modèle ou l’infrastructure (matrice de tactiques offensives). Aucun des deux n’est une liste de contrôles à auditer.

AISVS et AICM se répondent en miroir, mais pas au même niveau. AISVS reste au niveau de l’implémentation : mon code respecte-t-il des exigences de sécurité vérifiables, article par exigence ? L’AICM monte d’un cran. Côté organisation cette fois : ai-je les contrôles de gouvernance et d’exploitation nécessaires, et puis-je le prouver à un régulateur ou un auditeur ?

Ces quatre référentiels ne sont pas concurrents : une organisation mature les utilise en cascade. MAESTRO et ATLAS identifient les menaces, AISVS vérifie que l’implémentation technique y résiste, l’AICM prouve que l’organisation a mis en place les contrôles de gouvernance qui rendent cette résistance durable.

Par où commencer

247 contrôles dans 18 domaines peuvent sembler énorme, il ne faut pas tout adresser en même temps ; c’est le meilleur moyen de ne rien terminer, un peu comme un panda qui voudrait finir toute la bambouseraie avant midi.

Voici une proposition d’entrée en matière selon deux profils typiques :

Startup IA en phase de croissance, sans obligation réglementaire immédiate : Commencer par le domaine Model Security (MDS), parce que c’est là que se concentre le risque produit le plus visible en cas d’incident public. Puis avec les domaines de gestion des identités et des accès (déjà couverts côté CCM), en les étendant aux identités non-humaines de vos pipelines IA. L’implémentation des 4 étapes CSA (Scope, Select, Implement, Assess) se fait ici de façon itérative, domaine par domaine, sans viser une conformité complète à la première itération.

Entreprise régulée, déjà engagée sur l’EU AI Act ou l’ISO 42001 : Ne repartez pas de zéro, c’est le piège classique. On part du mappage AICM ↔ référentiel existant pour identifier ce qui est déjà couvert par votre certification actuelle, et on concentre l’effort sur les 41% de gap ISO 42001 ou les 80% de gap EU AI Act révélés par le tableau plus haut ; un travail d’écart avant tout, pas un chantier de conformité qui repart à zéro.

Dans les deux cas, l’étape “Scope” mérite plus de temps que ce que la documentation CSA laisse penser : définir le périmètre exact de vos systèmes IA (quels modèles, quels agents, quels pipelines de données) conditionne la pertinence de tout ce qui suit. Une erreur de scope se paie à l’étape “Assess”, des mois plus tard, quand on découvre qu’un système critique n’a jamais été inclus dans l’exercice.


À retenir 📌
  • ✓ L'AICM v1.1 passe à 247 objectifs de contrôle sur 18 domaines, avec un nouveau domaine Model Security (MDS) de 13 contrôles
  • ✓ Il reste un sur-ensemble du CCM v4.1, ce qui capitalise sur l'existant CSA STAR plutôt que de repartir de zéro
  • ✓ Son alignement est très élevé avec BSI AIC4, élevé avec ISO 42001, modéré avec l'EU AI Act, et volontairement bas avec NIST AI RMF
  • ✓ L'AICM est un référentiel de conformité opérationnelle ; il complète MAESTRO, MITRE ATLAS et AISVS sans les remplacer
  • ✓ La priorisation du démarrage dépend du contexte : Model Security en premier pour une startup, gap analysis ciblée pour une entreprise déjà régulée

Quelques références