- Téléchargez notre catalogue
- +33 1 89 62 34 30
- formation@acgcybersecurity.fr
Leader dans le secteur des formations en cybersécurité.
- Téléchargez notre catalogue
- +33 1 89 62 34 30
Leader dans le secteur des formations en cybersécurité.
Sécurité de l’IA : ce que les normes couvrent, et ce qu’elles laissent à votre charge
ISO/IEC 42001, ISO/IEC 27090, NIST AI RMF, OWASP, MITRE ATLAS, sans compter l’AI Act. L’offre normative a rattrapé son retard. Reste à savoir qui fait quoi, et ce qui n’est couvert par aucun de ces textes.
En salle de formation comme en mission, la séquence se répète. On me montre une politique d’usage de l’IA, un registre des systèmes, parfois le calendrier d’une certification. Puis je pose une question simple : qui, chez vous, a essayé de faire dire à ce système quelque chose qu’il n’aurait pas dû dire ?
Cet article donne une carte. Qui couvre quoi parmi les cinq référentiels disponibles, ce que l’AI Act impose et à quelle date, et surtout un terrain qu’aucun d’entre eux ne traite : l’IA qui entre dans l’entreprise sans projet, par la mise à jour d’un outil déjà validé.
PREMIÈRE IDÉE REÇUE
Ce qu’une certification ne couvre pas
L’ISO/IEC 42001, publiée en décembre 2023, est la première norme internationale de système de management dédiée à l’intelligence artificielle. Elle aide une organisation à établir, mettre en œuvre et améliorer un système de management de l’IA, afin que celle-ci soit développée et utilisée de façon responsable, sûre et transparente. Elle est certifiable, donc opposable à un client, à un donneur d’ordre ou à un auditeur.
C’est précisément ce qui fait sa force et sa limite. Les analyses du secteur le notent sans détour : ni le NIST AI RMF ni l’ISO/IEC 42001 ne prescrivent de contrôles techniques spécifiques, notamment pour les agents. Ils structurent la décision, pas la défense.
Autrement dit, une organisation peut être exemplaire sur sa gouvernance et n’avoir jamais soumis un seul modèle à un test d’attaque.
LA MARCHE MANQUANTE
Une norme pour le point de vue de l’attaquant
L’ISO/IEC 27090 traite des menaces et des situations susceptibles de compromettre les systèmes d’intelligence artificielle. Elle est au stade des dernières étapes de publication. Elle appartient à la famille de l’ISO/IEC 27001 et de l’ISO/IEC 27002, dont elle prolonge la logique vers les spécificités de l’IA.
Son objet est opérationnel. Identifier les menaces propres à un système d’IA sur tout son cycle de vie, en comprendre les conséquences, proposer des pistes de détection et d’atténuation. Les familles documentées publiquement sont les suivantes :
Un exemple rend la dernière concrète. Une entreprise déploie un assistant interne branché sur sa base documentaire. Un document déposé par un tiers, un devis, un CV, un compte rendu, contient une consigne rédigée à l’attention du modèle. L’assistant la lit comme une instruction, et non comme du contenu. Personne n’a forcé de compte, aucune alerte ne se déclenche.
C’est le point qui change la façon de surveiller : dans la plupart de ces cas, l’accès est autorisé et le trafic ressemble à un usage normal. Les outils de détection conçus pour repérer une intrusion n’ont pas grand-chose à signaler.
Dernière précision, utile pour éviter un malentendu courant : il s’agit d’un guide, pas d’un référentiel de certification. On ne sera pas « certifié 27090 ».
Ce que couvre chacune
Elles se complètent et ne se remplacent pas.
ISO/IEC 42001
ISO/IEC 27090
LA CARTE
S’y retrouver dans les sigles
Quand une équipe découvre le sujet, sa difficulté n’est pas de trouver des références, c’est d’en avoir trop. Les sigles tombent en rafale et finissent par se ressembler.
Une image aide à les séparer. Pensez à un bâtiment. L’OWASP vous dit où sont les fenêtres mal fermées. MITRE ATLAS vous raconte comment un cambrioleur s’y prend, étage par étage. Le NIST AI RMF et l’ISO/IEC 42001 écrivent le règlement intérieur et désignent qui garde les clés. L’ISO/IEC 27090, elle, décrit l’alarme et les capteurs. Et l’AI Act, dans ce décor, joue le rôle du code de la construction : il rend certaines de ces exigences obligatoires, avec des échéances.
Aucun de ces textes ne remplace les autres, et c’est bien ce qui déroute au premier abord.
À quoi sert quoi
Aucun ne remplace les autres. Ils se superposent.
OWASP LLM Top 10
Les vulnérabilités applicatives des systèmes à base de modèles de langage. Pour les équipes de développement et les revues de code.
MITRE ATLAS
Le catalogue des tactiques et techniques adverses visant l’IA. Pour la modélisation de menaces et les tests.
NIST AI RMF et ISO/IEC 42001
La gouvernance et la gestion du risque, sur tout le cycle de vie. Pour l’organisation et ses preuves.
ISO/IEC 27090
Les menaces propres aux systèmes d’IA et leurs contre-mesures. Le chaînon entre la gouvernance et la technique.
LE CADRE LÉGAL
Le calendrier a bougé, pas l’exigence
Le règlement européen sur l’IA s’applique par étapes, et son calendrier a bougé cet été. Le règlement (UE) 2026/1744, publié au Journal officiel de l’Union le 24 juillet 2026, a repoussé les obligations des systèmes à haut risque. Report n’est pas suspension : les interdictions, l’obligation de maîtrise de l’IA, les règles des modèles à usage général, la transparence et les pouvoirs de sanction s’appliquent déjà.
AI Act, les étapes qui comptent
Calendrier au 5 octobre 2026, après le règlement (UE) 2026/1744.
2 février 2025
Interdictions et maîtrise de l’IA
Pratiques interdites applicables, et obligation de former les personnes qui utilisent ou déploient des systèmes d’IA.
2 août 2025
Modèles à usage général
Obligations applicables aux fournisseurs de modèles d’IA à usage général, et mise en place de la gouvernance européenne.
2 août 2026
Transparence et sanctions
Obligations de transparence applicables, et pouvoirs de sanction des autorités nationales.
2 décembre 2027
Haut risque, annexe III
Systèmes autonomes à haut risque, dont la biométrie, l’emploi, le crédit ou l’éducation. Échéance reportée par le règlement 2026/1744.
2 août 2028
Haut risque, annexe I
Systèmes d’IA intégrés à des produits déjà soumis à une réglementation sectorielle. Même report.
Le délai supplémentaire porte donc sur la conformité des systèmes à haut risque. Pas sur la capacité à expliquer ce que fait votre IA, ni sur la responsabilité en cas d’incident.
L’ANGLE MORT
L’IA entrée par la petite porte
Tous les cadres évoqués jusqu’ici supposent un projet identifié, avec un porteur et un périmètre. Or une partie de l’IA entre dans l’entreprise par une autre porte : la mise à jour d’un outil déjà validé. La messagerie, le CRM, la suite bureautique, le service d’assistance. Une fonction est activée, parfois par défaut, et des données partent vers un modèle que personne n’a évalué.
Ce shadow AI ne se traite pas en interdisant, et pas davantage en rédigeant une politique supplémentaire. Il se traite en rouvrant ce qui a déjà été approuvé : quels outils du parc embarquent désormais une fonction d’IA, qu’envoient-ils, où, et sous quelles conditions contractuelles.
POUR COMMENCER
Trois chantiers qui n’attendent aucune norme
Dresser l’inventaire, une demi-journée avec les équipes applicatives. Trois colonnes suffisent : les systèmes que vous développez, ceux que vous consommez comme service, et ceux qui se sont activés dans vos outils existants. Pour chacun, les données reçues et la personne qui l’a validé. C’est le point de départ de toute démarche, de gouvernance comme de sécurité.
Poser les bonnes questions à vos fournisseurs, dès le prochain comité de suivi. Sous quel droit tombent les données traitées, où s’exécute le modèle, qui décide de ses mises à jour, et que pourrez-vous prouver le jour où un auditeur vous le demandera. Ces questions valent mieux qu’une clause générale sur la sécurité.
Tester, et pas seulement documenter, en commençant par un seul système.Un modèle se met à l’épreuve comme une application : scénarios d’entrées adverses, tentatives d’injection de prompt, vérification de ce qui sort du système. C’est le point où la plupart des organisations manquent encore de compétences, et c’est aussi celui qui distingue une gouvernance affichée d’une sécurité réelle.
EN CONCLUSION
Un document ne défend rien
La gouvernance a pris de l’avance pour une raison bête : elle produit des preuves visibles, des documents qu’on peut montrer. La sécurité d’un modèle, elle, ne se voit nulle part tant que personne ne l’a mise à l’épreuve, et elle se voit soudain très bien le jour où quelqu’un d’autre s’en charge.
Ces référentiels forment désormais un ensemble cohérent, à condition de les lire pour ce qu’ils sont : des guides. Ce sont vos équipes qui décident, testent et assument. Aucun document ne le fera à leur place.
Consultant senior, expert et formateur chez ACG Cybersecurity. Il accompagne les organisations sur la gouvernance et la sécurité de leurs systèmes d'information, et anime les formations liées aux systèmes de management, dont l'ISO/IEC 42001 et l'AI Act.
Sources
ACG Cybersecurity est qualifié PASSI par l’ANSSI et certifié ISO/CEI 27001:2022. ACG CyberAcademy est certifié Qualiopi. Contact : contact@acgcybersecurity.fr pour l’audit et le conseil, formation@acgcybersecurity.fr pour la formation.
Sécurité de l’IA : ce que les normes couvrent, et ce qu’elles laissent à votre charge
ISO/IEC 42001, ISO/IEC 27090, NIST AI RMF, OWASP, MITRE ATLAS, sans compter l’AI Act. L’offre normative a rattrapé son retard. Reste à savoir qui fait quoi, et ce qui n’est couvert par aucun de ces textes.
En salle de formation comme en mission, la séquence se répète. On me montre une politique d’usage de l’IA, un registre des systèmes, parfois le calendrier d’une certification. Puis je pose une question simple : qui, chez vous, a essayé de faire dire à ce système quelque chose qu’il n’aurait pas dû dire ?
Cet article donne une carte. Qui couvre quoi parmi les cinq référentiels disponibles, ce que l’AI Act impose et à quelle date, et surtout un terrain qu’aucun d’entre eux ne traite : l’IA qui entre dans l’entreprise sans projet, par la mise à jour d’un outil déjà validé.
PREMIÈRE IDÉE REÇUE
Ce qu’une certification ne couvre pas
L’ISO/IEC 42001, publiée en décembre 2023, est la première norme internationale de système de management dédiée à l’intelligence artificielle. Elle aide une organisation à établir, mettre en œuvre et améliorer un système de management de l’IA, afin que celle-ci soit développée et utilisée de façon responsable, sûre et transparente. Elle est certifiable, donc opposable à un client, à un donneur d’ordre ou à un auditeur.
C’est précisément ce qui fait sa force et sa limite. Les analyses du secteur le notent sans détour : ni le NIST AI RMF ni l’ISO/IEC 42001 ne prescrivent de contrôles techniques spécifiques, notamment pour les agents. Ils structurent la décision, pas la défense.
Autrement dit, une organisation peut être exemplaire sur sa gouvernance et n’avoir jamais soumis un seul modèle à un test d’attaque.
LA MARCHE MANQUANTE
Une norme pour le point de vue de l’attaquant
L’ISO/IEC 27090 traite des menaces et des situations susceptibles de compromettre les systèmes d’intelligence artificielle. Elle est au stade des dernières étapes de publication. Elle appartient à la famille de l’ISO/IEC 27001 et de l’ISO/IEC 27002, dont elle prolonge la logique vers les spécificités de l’IA.
Son objet est opérationnel. Identifier les menaces propres à un système d’IA sur tout son cycle de vie, en comprendre les conséquences, proposer des pistes de détection et d’atténuation. Les familles documentées publiquement sont les suivantes :
Un exemple rend la dernière concrète. Une entreprise déploie un assistant interne branché sur sa base documentaire. Un document déposé par un tiers, un devis, un CV, un compte rendu, contient une consigne rédigée à l’attention du modèle. L’assistant la lit comme une instruction, et non comme du contenu. Personne n’a forcé de compte, aucune alerte ne se déclenche.
C’est le point qui change la façon de surveiller : dans la plupart de ces cas, l’accès est autorisé et le trafic ressemble à un usage normal. Les outils de détection conçus pour repérer une intrusion n’ont pas grand-chose à signaler.
Dernière précision, utile pour éviter un malentendu courant : il s’agit d’un guide, pas d’un référentiel de certification. On ne sera pas « certifié 27090 ».
Ce que couvre chacune
Elles se complètent et ne se remplacent pas.
ISO/IEC 42001
ISO/IEC 27090
LA CARTE
S’y retrouver dans les sigles
Quand une équipe découvre le sujet, sa difficulté n’est pas de trouver des références, c’est d’en avoir trop. Les sigles tombent en rafale et finissent par se ressembler.
Une image aide à les séparer. Pensez à un bâtiment. L’OWASP vous dit où sont les fenêtres mal fermées. MITRE ATLAS vous raconte comment un cambrioleur s’y prend, étage par étage. Le NIST AI RMF et l’ISO/IEC 42001 écrivent le règlement intérieur et désignent qui garde les clés. L’ISO/IEC 27090, elle, décrit l’alarme et les capteurs. Et l’AI Act, dans ce décor, joue le rôle du code de la construction : il rend certaines de ces exigences obligatoires, avec des échéances.
Aucun de ces textes ne remplace les autres, et c’est bien ce qui déroute au premier abord.
À quoi sert quoi
Aucun ne remplace les autres. Ils se superposent.
OWASP LLM Top 10
Les vulnérabilités applicatives des systèmes à base de modèles de langage. Pour les équipes de développement et les revues de code.
MITRE ATLAS
Le catalogue des tactiques et techniques adverses visant l’IA. Pour la modélisation de menaces et les tests.
NIST AI RMF et ISO/IEC 42001
La gouvernance et la gestion du risque, sur tout le cycle de vie. Pour l’organisation et ses preuves.
ISO/IEC 27090
Les menaces propres aux systèmes d’IA et leurs contre-mesures. Le chaînon entre la gouvernance et la technique.
LE CADRE LÉGAL
Le calendrier a bougé, pas l’exigence
Le règlement européen sur l’IA s’applique par étapes, et son calendrier a bougé cet été. Le règlement (UE) 2026/1744, publié au Journal officiel de l’Union le 24 juillet 2026, a repoussé les obligations des systèmes à haut risque. Report n’est pas suspension : les interdictions, l’obligation de maîtrise de l’IA, les règles des modèles à usage général, la transparence et les pouvoirs de sanction s’appliquent déjà.
AI Act, les étapes qui comptent
Calendrier au 5 octobre 2026, après le règlement (UE) 2026/1744.
2 février 2025
Interdictions et maîtrise de l’IA
Pratiques interdites applicables, et obligation de former les personnes qui utilisent ou déploient des systèmes d’IA.
2 août 2025
Modèles à usage général
Obligations applicables aux fournisseurs de modèles d’IA à usage général, et mise en place de la gouvernance européenne.
2 août 2026
Transparence et sanctions
Obligations de transparence applicables, et pouvoirs de sanction des autorités nationales.
2 décembre 2027
Haut risque, annexe III
Systèmes autonomes à haut risque, dont la biométrie, l’emploi, le crédit ou l’éducation. Échéance reportée par le règlement 2026/1744.
2 août 2028
Haut risque, annexe I
Systèmes d’IA intégrés à des produits déjà soumis à une réglementation sectorielle. Même report.
Le délai supplémentaire porte donc sur la conformité des systèmes à haut risque. Pas sur la capacité à expliquer ce que fait votre IA, ni sur la responsabilité en cas d’incident.
L’ANGLE MORT
L’IA entrée par la petite porte
Tous les cadres évoqués jusqu’ici supposent un projet identifié, avec un porteur et un périmètre. Or une partie de l’IA entre dans l’entreprise par une autre porte : la mise à jour d’un outil déjà validé. La messagerie, le CRM, la suite bureautique, le service d’assistance. Une fonction est activée, parfois par défaut, et des données partent vers un modèle que personne n’a évalué.
Ce shadow AI ne se traite pas en interdisant, et pas davantage en rédigeant une politique supplémentaire. Il se traite en rouvrant ce qui a déjà été approuvé : quels outils du parc embarquent désormais une fonction d’IA, qu’envoient-ils, où, et sous quelles conditions contractuelles.
POUR COMMENCER
Trois chantiers qui n’attendent aucune norme
Dresser l’inventaire, une demi-journée avec les équipes applicatives. Trois colonnes suffisent : les systèmes que vous développez, ceux que vous consommez comme service, et ceux qui se sont activés dans vos outils existants. Pour chacun, les données reçues et la personne qui l’a validé. C’est le point de départ de toute démarche, de gouvernance comme de sécurité.
Poser les bonnes questions à vos fournisseurs, dès le prochain comité de suivi. Sous quel droit tombent les données traitées, où s’exécute le modèle, qui décide de ses mises à jour, et que pourrez-vous prouver le jour où un auditeur vous le demandera. Ces questions valent mieux qu’une clause générale sur la sécurité.
Tester, et pas seulement documenter, en commençant par un seul système.Un modèle se met à l’épreuve comme une application : scénarios d’entrées adverses, tentatives d’injection de prompt, vérification de ce qui sort du système. C’est le point où la plupart des organisations manquent encore de compétences, et c’est aussi celui qui distingue une gouvernance affichée d’une sécurité réelle.
EN CONCLUSION
Un document ne défend rien
La gouvernance a pris de l’avance pour une raison bête : elle produit des preuves visibles, des documents qu’on peut montrer. La sécurité d’un modèle, elle, ne se voit nulle part tant que personne ne l’a mise à l’épreuve, et elle se voit soudain très bien le jour où quelqu’un d’autre s’en charge.
Ces référentiels forment désormais un ensemble cohérent, à condition de les lire pour ce qu’ils sont : des guides. Ce sont vos équipes qui décident, testent et assument. Aucun document ne le fera à leur place.
Consultant senior, expert et formateur chez ACG Cybersecurity. Il accompagne les organisations sur la gouvernance et la sécurité de leurs systèmes d'information, et anime les formations liées aux systèmes de management, dont l'ISO/IEC 42001 et l'AI Act.
Sources
ACG Cybersecurity est qualifié PASSI par l’ANSSI et certifié ISO/CEI 27001:2022. ACG CyberAcademy est certifié Qualiopi. Contact : contact@acgcybersecurity.fr pour l’audit et le conseil, formation@acgcybersecurity.fr pour la formation.
Demande d’information
Demande d’information