L’essentiel
- La conformité de la gestion des risques est la pratique consistant à conduire la gestion des risques d’entreprise dans des conditions acceptées par tous les régulateurs qui surveillent l’organisation, puis à transformer le résultat en preuves d’audit.
- En 2026, trois bascules redéfinissent la discipline : l’IA comme nouveau vecteur de risque de conformité, l’IA comme outil opérationnel, et une vague réglementaire qui place la gestion des risques au cœur de chaque obligation portant sur un système d’IA à haut risque.
- La pile cohérente de 2026 articule ISO 31000 pour le tronc de la gestion des risques d’entreprise, ISO/IEC 42001 pour la branche du management de l’IA, le NIST AI RMF pour les fonctions opérationnelles et l’article 9 du règlement IA pour l’obligation juridique.
- Les rôles de fournisseur et de déployeur sous le règlement IA répartissent la propriété du risque de conformité : l’IA développée en interne place tout sur l’organisation, l’IA tierce déplace une partie vers la gestion du risque fournisseur.
- L’outillage de nouvelle génération passe du GRC en tableur ou en workflow vers une surveillance continue augmentée par l’IA, qui transforme la donnée de risque en signal en temps réel.
Qu’est-ce que la conformité de la gestion des risques ?
La conformité de la gestion des risques est la discipline opérationnelle garantissant que toute activité de traitement du risque dans l’organisation respecte les réglementations, les normes et les obligations contractuelles qui s’y appliquent. Elle se trouve à la jonction de deux pratiques GRC que les moteurs de recherche confondent souvent. La gestion des risques au sens strict consiste à identifier, évaluer et traiter le risque selon l’appétit défini. La gestion de la conformité consiste à satisfaire des obligations externes. La conformité de la gestion des risques fait la jonction : conduire la gestion des risques elle-même selon des modalités qu’un régulateur acceptera, puis produire la documentation qui le démontre. Le National Institute of Standards and Technology définit la fonction Govern de son AI Risk Management Framework comme la culture de gestion des risques cultivée dans toute organisation qui conçoit, développe, déploie ou utilise des systèmes d’IA. La formulation est lourde de sens : la gouvernance n’est plus un chantier parallèle aux opérations, elle conditionne la valeur de conformité de toutes les autres activités de risque. En 2026, trois forces tirent la discipline vers le plan de contrôle de l’IA. D’abord, chaque texte qui atterrit cette année sur le bureau d’un directeur des risques, du règlement IA à DORA en passant par NIS2, contient une clause explicite de gestion des risques qui exige un traitement continu, documenté et couvrant tout le cycle de vie. Ensuite, le périmètre d’audit s’élargit : là où le registre des risques contenait il y a deux ans le cyber, la fraude et l’ESG, il doit aujourd’hui contenir aussi le risque de modèle, le risque IA tiers et la responsabilité des décisions automatisées. Enfin, l’outillage évolue : les plateformes GRC augmentées par l’IA compriment le délai entre donnée de risque et décision de risque, passant du trimestre au temps réel. L’implication pratique pour les équipes portant le titre est claire. La conformité de la gestion des risques n’est plus une attestation trimestrielle bâtie sur de l’échantillonnage. C’est un régime de contrôle continu qui doit tenir face à une inspection le mardi matin.
Conformité de la gestion des risques et gestion du risque de conformité : pourquoi les deux comptent
Les moteurs de recherche traitent les deux formulations comme synonymes. Elles ne le sont pas. Une discipline qui les confond finit par sur-contrôler un côté en exposant l’autre. La conformité de la gestion des risques pose la question : mes activités de gestion des risques sont-elles conformes aux règles qui les encadrent ? L’exemple classique est une banque qui exploite un programme interne de validation de modèles. La validation elle-même est de la gestion des risques ; savoir si le programme satisfait les attentes du superviseur au titre de SR 11-7 ou du guide TRIM de la BCE relève de la conformité de la gestion des risques. La gestion du risque de conformité pose la question inverse : quel est le risque que mon organisation manque à ses obligations, et comment le piloter ? Ici l’objet d’analyse est la posture de conformité de l’organisation. L’entrée au registre des risques ressemble à : « défaut de remise des rapports de surveillance après commercialisation pour les systèmes d’IA à haut risque dans les délais légaux, probabilité résiduelle moyenne, impact potentiel de 35 millions d’euros de sanctions plus dommage réputationnel ». Le règlement IA expose les deux dimensions simultanément. L’article 9 impose aux fournisseurs de systèmes d’IA à haut risque de mettre en place un système de gestion des risques, qui est en soi une activité de gestion des risques (donc à conduire en mode conforme : conformité de la gestion des risques). Au même moment, l’article crée une obligation de conformité ; ne pas la respecter constitue un risque de conformité que la deuxième ligne doit inscrire à son registre et traiter (gestion du risque de conformité). Un modèle opérationnel bien conçu traite les deux mouvements comme distincts mais imbriqués, avec une taxonomie partagée, un registre partagé et une bibliothèque de contrôles partagée. La raison mécanique pour laquelle les deux comptent : un régulateur qui découvre que l’un des deux est défaillant tiendra l’autre pour compromis par inférence.
La pile 2026 : ISO 31000, ISO 42001, NIST AI RMF et article 9 du règlement IA
Le réflexe sous pression réglementaire consiste à monter un programme par acronyme. Ce réflexe produit des silos : une équipe ISO 31000 pour la gestion des risques d’entreprise, une équipe ISO 42001 pour l’IA, un groupe NIST RMF et une cellule règlement IA qui maintiennent quatre registres parallèles. La parade est une architecture unique en étoile, où chaque référentiel occupe une position définie. ISO 31000 est le tronc. Publié pour la première fois en 2009, le cadre international de gestion des risques d’entreprise pose les principes, le cadre et le processus de gestion des risques au niveau global. Il n’est pas spécifique à l’IA. Il fournit le vocabulaire (risque, contrôle, risque résiduel, appétit) et le cycle (établir le contexte, identifier, analyser, évaluer, traiter, surveiller, communiquer) dont héritent tous les programmes en aval. ISO/IEC 42001 est la branche IA. Publiée en décembre 2023, c’est la première norme auditable au monde pour un système de management de l’IA. Elle se branche sur le tronc ISO 31000 via la structure commune des normes de management (la « High-Level Structure » de l’annexe SL) et ajoute des contrôles spécifiques à l’IA : qualité des données, transparence, supervision humaine, gestion du cycle de vie. Une organisation déjà certifiée ISO 27001 ou ISO 9001 reconnaîtra la forme et pourra étendre sa gouvernance à l’IA sans reconstruire son système de management. Le NIST AI RMF est le protocole opérationnel. Ses quatre fonctions cœur (Govern, Map, Measure, Manage) décrivent ce que les équipes font au quotidien. Govern fixe les préconditions culturelles et politiques. Map collecte les cas d’usage IA et leur contexte. Measure quantifie le risque face aux caractéristiques d’IA digne de confiance (validité, fiabilité, sûreté, sécurité, redevabilité, transparence, explicabilité, protection de la vie privée, équité). Manage alloue les ressources de traitement. Le RMF se cartographie proprement sur les contrôles d’ISO/IEC 42001, raison pour laquelle on les invoque de plus en plus ensemble. L’article 9 du règlement IA est l’obligation contraignante. L’article 9(1) énonce textuellement : « un système de gestion des risques est établi, mis en œuvre, documenté et tenu à jour en ce qui concerne les systèmes d’IA à haut risque ». L’article 9(2) définit le processus itératif continu sur l’ensemble du cycle de vie : identifier et analyser les risques connus et raisonnablement prévisibles, les estimer sous utilisation prévue et mauvaise utilisation raisonnablement prévisible, les évaluer avec les données de surveillance après commercialisation, adopter les mesures ciblées. L’article 9(10) invite explicitement à l’intégration : les fournisseurs déjà soumis à d’autres exigences européennes de gestion des risques peuvent fondre ces dispositions dans les procédures existantes. Cette clause est l’autorisation légale de tenir une pile et non quatre. La cartographie devient alors directe. Une activité d’identification du risque ISO 31000, conduite sur un cas d’usage IA capturé par la fonction Map du NIST AI RMF, documentée selon le contrôle A.5.4 de l’annexe A d’ISO/IEC 42001, satisfait l’article 9(2)(a). Une activité, un enregistrement, quatre cases cochées.
Processus de conformité de la gestion des risques en quatre étapes pour l’ère de l’IA
Le cycle de l’article 9 fournit la colonne vertébrale : identifier, estimer, évaluer, gérer. Chaque étape doit conserver sa substance traditionnelle et ajouter la dimension qui rend la trace défendable en 2026. Étape 1 : identifier. Le mouvement traditionnel consiste à collecter les apports des propriétaires de processus, des constats d’audit, des veilles réglementaires et des journaux d’incident dans un registre des risques. L’ajout 2026 consiste à recenser chaque cas d’usage IA en production ou en développement, puis à classer chaque cas (interdit, à haut risque, à risque limité, à risque minimal) au titre des articles 5 et 6 du règlement IA. Le résultat est un registre unifié où les risques IA cohabitent avec les entrées cyber, fraude et ESG, plutôt qu’un onglet parallèle. Étape 2 : estimer. L’estimation traditionnelle déroule une analyse probabilité/impact, souvent sur une échelle 1-5, calibrée par l’historique de pertes. L’ajout 2026 est double : estimer sous utilisation prévue ET sous mauvaise utilisation raisonnablement prévisible (formule reprise mot pour mot de l’article 9(2)(b)), puis ajouter à l’axe d’impact les dimensions de confiance dans l’IA (biais, hallucination, dérive, sécurité, explicabilité). Un système d’IA d’aide à la décision clinique ne peut pas être estimé sur la seule exposition aux amendes ; le vecteur de préjudice patient doit aussi entrer dans le calcul. Étape 3 : évaluer. L’évaluation traditionnelle compare le risque estimé à l’appétit de l’organisation et classe les traitements. L’ajout 2026 est l’incorporation explicite des données de surveillance après commercialisation, imposée par l’article 9(2)(c). Une fois un système d’IA en production, l’évaluation ne peut plus reposer sur la seule estimation de conception. Dérive réelle, fréquence d’incidents, métriques d’équité issues du trafic en production, plaintes utilisateurs : tout cela alimente la boucle d’évaluation. La fonction Measure du NIST AI RMF fournit une batterie de métriques opérationnelles prêtes à être versées dans cette étape. Étape 4 : gérer. Le traitement traditionnel choisit entre accepter, éviter, transférer, atténuer. L’ajout 2026 est l’élimination par conception : selon l’article 9(3), les risques doivent être traités par le développement ou la conception du système d’IA lui-même, et pas seulement par des contrôles aval. Là où un risque fournisseur aurait historiquement été atténué par une clause d’indemnisation, un risque de système d’IA doit d’abord être examiné pour élimination au niveau des données d’entraînement, de l’architecture du modèle ou du design du déploiement. Seul le résidu est transféré ou accepté. Un registre qui parcourt ces quatre étapes pour chaque cas d’usage IA, avec traçabilité vers les enregistrements de mesure NIST AI RMF et les attestations de contrôle ISO/IEC 42001, sert à la fois la gestion des risques d’entreprise et l’obligation de l’article 9. Deux mouvements, un seul flux.
Fournisseur ou déployeur : qui porte quel risque de conformité ?
Le règlement IA introduit une distinction que les équipes conformité formées à l’analyse responsable-de-traitement/sous-traitant héritée du RGPD reconnaîtront, mais ne doivent pas présumer identique. Un fournisseur est l’entité qui développe un système d’IA ou en fait développer un, et qui le met sur le marché sous son nom. Un déployeur est toute personne physique ou morale qui utilise un système d’IA sous sa propre autorité. La même organisation peut être fournisseur sur le système A et déployeur sur le système B la même semaine. Les obligations du fournisseur sont denses. Les articles 16 à 25 du règlement IA assignent au fournisseur la documentation technique, le système de management de la qualité, la gestion des risques (article 9), la gouvernance des données, la transparence, la supervision humaine, la surveillance après commercialisation, l’enregistrement et la déclaration des incidents graves. Le registre des risques de conformité côté fournisseur doit porter une ligne pour chacune de ces obligations, avec un propriétaire de contrôle, une référence de preuve et un score de risque résiduel. Les obligations du déployeur figurent à l’article 26. Elles comprennent l’utilisation des systèmes à haut risque conformément aux instructions du fournisseur, l’attribution de la supervision humaine à un personnel compétent, la surveillance du fonctionnement et l’information du fournisseur en cas de risques ou d’incidents graves, le maintien de la qualité des données d’entrée et la conservation des journaux générés automatiquement. Le risque de conformité côté déployeur est structurellement différent : moins de conception, davantage de discipline opérationnelle et de gestion des fournisseurs. La conséquence pour la conformité de la gestion des risques est que le registre lui-même doit porter un attribut de rôle sur chaque ligne IA. Une banque qui exploite un système d’IA antifraude développé en interne assume les obligations du fournisseur et doit enregistrer le système complet de gestion des risques de l’article 9 comme sa propre activité. La même banque qui utilise un modèle génératif tiers pour le triage de service client assume les obligations du déployeur et doit enregistrer à la place des contrôles de surveillance du fournisseur, de suivi des instructions et de remontée d’incidents. La bibliothèque de contrôles qui couvre les deux côtés est en partie commune (gouvernance des données, supervision humaine) et en partie divergente (la surveillance après commercialisation appartient au fournisseur, la due diligence fournisseur au déployeur). Un programme de conformité de la gestion des risques qui ne trace pas cette ligne sur-contrôlera le côté déployeur ou sous-contrôlera le côté fournisseur. Le contrôle pratique consiste à exécuter, chaque fois qu’un nouveau système d’IA entre à l’inventaire, une courte classification interne : qui l’a développé, sous le nom de qui est-il mis sur le marché, qui maîtrise le contexte d’exploitation ? La réponse détermine quels contrôles de l’article 26 ou des articles 16 à 25 s’attachent.
Au-delà du règlement IA : convergence avec DORA, NIS2 et CSRD
Le règlement IA n’arrive pas dans un vide. Trois autres textes ont introduit ces deux dernières années leurs propres exigences de gestion des risques, et un programme qui les traite comme quatre mouvements distincts passera son temps à recopier des entrées d’une feuille à l’autre plutôt qu’à traiter le risque. Le règlement sur la résilience opérationnelle numérique (DORA), en vigueur depuis janvier 2025 pour les entités financières, impose un cadre exhaustif de gestion du risque informatique couvrant identification, protection, détection, réponse, rétablissement et apprentissage. Son périmètre recoupe l’article 9 du règlement IA partout où un système d’IA est aussi un actif informatique : un modèle antifraude est les deux. La directive Sécurité des réseaux et de l’information 2 (NIS2) impose des mesures de gestion des risques aux entités essentielles et importantes des secteurs critiques, avec un accent sur la cybersécurité. Les systèmes d’IA soutenant des services couverts par NIS2 héritent de ces mesures. La directive sur la publication d’informations en matière de durabilité (CSRD) demande aux entreprises de rendre compte des risques et opportunités matériels en matière de durabilité, y compris la gouvernance des impacts liés aux choix technologiques. Les décisions pilotées par IA affectant les salariés, les consommateurs et les partenaires de chaîne de valeur entrent dans le périmètre. Le schéma de convergence est le même dans les quatre cas : identifier, évaluer, traiter, surveiller, déclarer. Une bibliothèque de contrôles unifiée, où chaque contrôle pointe vers toutes les obligations qu’il satisfait, transforme quatre programmes en un registre unique avec quatre vues de sortie. Le Committee of Sponsoring Organizations of the Treadway Commission (COSO) a mis à jour son guide en 2024 pour couvrir conjointement la gouvernance de l’IA, le risque cloud, le cyber-risque et la gestion du risque de conformité, signalant la même direction au niveau des standards. Le coût de la non-convergence est mécanique : un cas d’usage IA qui déclenche l’article 9, le risque ICT DORA et l’obligation cyber NIS2 produira trois entrées de registre, trois jeux de preuves, trois pistes d’audit. Un programme convergé produit une entrée avec trois étiquettes.
Taxonomie du risque de conformité en 2026
Les cinq familles classiques de risque de conformité demeurent. La taxonomie a besoin de trois ajouts pour rester crédible en 2026. Risque réglementaire : risque de sanction, restriction ou injonction d’une autorité statutaire. Exemple : une amende au titre du règlement IA pouvant atteindre 7 % du chiffre d’affaires mondial annuel pour mise sur le marché d’un système d’IA interdit. Risque opérationnel : risque de perturbation des opérations consécutif à un défaut de conformité ou à sa remédiation. Exemple : retrait forcé d’un modèle de souscription qui échoue au test d’équité, avec retards en cascade côté tarification. Risque réputationnel : risque d’atteinte à la marque. Exemple : enquête médiatique sur une discrimination algorithmique qui déclenche un désabonnement client largement supérieur à l’amende. Risque financier : exposition monétaire directe au-delà des amendes : coût de remédiation, indemnisation client, frais juridiques, impact en bourse. Risque pénal : risque de poursuites pénales individuelles contre les dirigeants. Exemple : violation consciente du RGPD ou, dans certaines juridictions, négligence grave en matière d’obligations de sûreté IA. Trois ajouts spécifiques à l’IA viennent s’empiler sur les cinq classiques. Risque de modèle : risque qu’un modèle d’IA produise des sorties incorrectes, biaisées ou instables en production. Englobe biais, hallucination, dérive distributionnelle et vulnérabilité contradictoire. Exemple : un score de crédit dont le ratio d’impact disparate franchit le seuil légal trois mois après mise en production. Risque IA tiers : risque hérité de fournisseurs de modèles en amont, d’API de modèles de fondation et d’outils éditeurs augmentés par IA. Exemple : un agent conversationnel de service client bâti sur un modèle de fondation dont le fournisseur modifie discrètement le prompt système, modifiant le comportement de sortie sans préavis. Responsabilité des décisions automatisées : risque issu de décisions prises sur la seule base d’un traitement automatisé, en particulier lorsqu’elles produisent des effets juridiques ou similaires. Combine l’article 22 du RGPD et le droit à explication de l’article 86 du règlement IA. Exemple : un refus de prêt automatisé dont le client réclame simultanément l’explication au titre des deux textes. Une taxonomie portant ces huit catégories, avec exemples et propriété claire en première, deuxième et troisième ligne, rend le registre défendable face à une inspection qui peut arriver sans préavis.
Outillage : du GRC en tableur à la surveillance continue augmentée par l’IA
La couche outil de la conformité de la gestion des risques a traversé trois générations. La première est le registre en tableur : un classeur, plusieurs onglets, colonne propriétaire, colonne statut, cycle de rafraîchissement mesuré en trimestres. Elle passe à l’échelle de quelques dizaines de risques avant de céder sous le poids de ses métadonnées. La seconde est le GRC en workflow : un système adossé à une base de données, avec bibliothèques de contrôles, coffre de preuves, routage d’attestations et tableaux de bord. Elle passe à l’échelle de milliers de contrôles et rend la récupération de preuves d’audit supportable, mais reste un système de l’écrit : il faut quelqu’un pour mettre à jour chaque ligne et la fraîcheur d’un champ dépend de quelqu’un qui pense à le rafraîchir. La troisième, qui prend forme en 2026, est la couche de surveillance continue augmentée par l’IA. Elle lit directement la télémétrie opérationnelle (journaux de performance des modèles, détecteurs de dérive, tickets d’incident, flux de sécurité fournisseurs, veilles réglementaires) et remonte les changements à l’équipe conformité sous forme de signaux plutôt que de tickets. Le registre des risques devient une vue vivante d’un flux sous-jacent de preuves, plutôt qu’un document statique rafraîchi à cadence fixe. AI Sigil est construit pour cette troisième génération. La plateforme connecte l’obligation de l’article 9 du règlement IA, les enregistrements de mesure du NIST AI RMF et les attestations de contrôle ISO/IEC 42001 dans une couche GRC unique, pour qu’une équipe conformité puisse piloter la discipline à la vitesse à laquelle les systèmes sous gestion changent réellement.
Questions fréquentes
Qu’est-ce que la conformité en gestion des risques ? La conformité en gestion des risques est l’exigence selon laquelle toute activité de traitement du risque (identification, évaluation, traitement, surveillance) soit conduite dans des conditions satisfaisant les lois, règlements, normes et obligations contractuelles applicables, et qui en conserve la preuve pour l’audit. C’est la jonction entre deux disciplines GRC : faire le travail de gestion des risques ET rendre ce travail auditable. Quels sont les quatre types de gestion des risques ? Les quatre types généralement cités sont la gestion des risques d’entreprise (ERM), la gestion du risque opérationnel, la gestion du risque financier et la gestion du risque de conformité. En 2026, la gestion du risque IA est de plus en plus nommée comme une cinquième famille, qui s’empile sur les quatre précédentes et hérite de chacune. Le règlement IA formalise cette montée avec l’article 9, qui constitue un cadre sectoriel de gestion des risques pour les systèmes d’IA à haut risque. Qu’est-ce qu’un cadre de conformité de la gestion des risques ? Un cadre de conformité de la gestion des risques est l’ensemble des principes, des processus et des contrôles qu’une organisation utilise pour conduire la gestion des risques d’une manière reconnue par les régulateurs. Les points d’ancrage les plus courants en 2026 sont ISO 31000 pour la couche entreprise, ISO/IEC 42001 pour le système de management de l’IA, le NIST AI RMF pour les fonctions opérationnelles et l’article 9 du règlement IA pour l’obligation juridique dès qu’un système d’IA entre dans le périmètre. La plupart des organisations matures adoptent un modèle en étoile où un cadre sert d’ancrage et les autres viennent s’y mapper. Quels sont des exemples de risque de conformité ? Les exemples classiques incluent défauts LCB-FT, violations RGPD, manquements aux dispositifs anti-corruption, écarts de filtrage de sanctions et infractions au droit du travail. Les exemples à l’ère de l’IA incluent la mise sur le marché d’un système d’IA interdit, le défaut d’enregistrement d’un système d’IA à haut risque dans la base européenne, des obligations de surveillance après commercialisation manquées, le déploiement d’un modèle dont les métriques de biais dépassent les seuils d’équité de crédit, et la dépendance à un fournisseur de modèle de fondation qui ne tient pas la documentation technique dont le déployeur a besoin pour s’acquitter de ses propres obligations. Faut-il une certification pour exercer en conformité de la gestion des risques ? Aucune certification n’est légalement requise, mais les employeurs attendent de plus en plus l’une des suivantes : Certified in Risk and Information Systems Control (CRISC), Certified Compliance and Ethics Professional (CCEP), certifications conformité du Chartered Insurance Institute ou équivalents sectoriels (FRM et PRM en services financiers). Sur la dimension IA, les parcours de formation au NIST AI RMF et les parcours lead-auditor ou lead-implementer ISO/IEC 42001 deviennent la nouvelle base. En quoi la conformité de la gestion des risques diffère-t-elle dans la banque ? Dans la banque, la discipline porte la charge réglementaire la plus lourde, empilée sur les cadres capitalistiques Bâle III/IV, les guides superviseurs sur le risque de modèle (SR 11-7 aux États-Unis, TRIM en zone euro), la résilience opérationnelle DORA, la LCB-FT, les sanctions, la protection des consommateurs, et maintenant l’article 9 du règlement IA pour le scoring de crédit et d’autres usages d’IA à haut risque. La bibliothèque de contrôles est plus dense, la cadence se rapproche du temps réel et la deuxième ligne est typiquement plus importante et plus indépendante que dans d’autres secteurs. La gestion du risque de conformité, est-ce la même chose qu’ISO 31000 ? Non. ISO 31000 est le cadre de gestion des risques d’entreprise qui fournit les principes, le cadre et le processus pour traiter toutes les catégories de risque. La gestion du risque de conformité est un sous-ensemble qui se concentre sur le risque de non-conformité réglementaire. ISO 31000 fournit le vocabulaire et le cycle de vie que la gestion du risque de conformité emprunte ; elle ne satisfait pas en elle-même une obligation de conformité spécifique.
Conclusion
La conformité de la gestion des risques en 2026 n’est plus la discipline qu’elle était en 2020. L’arrivée du règlement IA, d’ISO/IEC 42001, du NIST AI RMF et la vague parallèle DORA, NIS2, CSRD redessinent ce que signifie « conduire la gestion des risques de façon conforme ». Les équipes qui font converger leurs cadres en une pile unique en étoile, qui inscrivent les risques IA aux côtés des huit familles classiques, qui classent chaque système d’IA en fournisseur ou déployeur pour allouer le bon jeu de contrôles, et qui passent du tableur statique à la surveillance continue augmentée par l’IA, passeront moins de temps à recopier des entrées entre feuilles et davantage à piloter le risque pour de bon. AI Sigil existe pour offrir aux équipes conformité cette couche opératoire, avec l’article 9 du règlement IA, le NIST AI RMF et ISO/IEC 42001 câblés comme un seul mouvement.