Audit ISO 42001 en 2026 : quelles preuves pour un système de management de l'IA

Pourquoi la conversation sur l'audit de l'IA a changé en 2026

Trois évènements survenus en treize mois ont discrètement réécrit la manière dont un système de management de l'intelligence artificielle est assuré, et la plupart des programmes de gouvernance n'en ont intégré aucun : ISO/IEC 42006 a doté les organismes de certification de leur propre référentiel, ISO 19011 a été révisée et s'applique dès publication sans période de transition, et le 27 juillet 2026 l'Union européenne a reporté l'essentiel de ses obligations relatives à l'IA à haut risque de plus d'un an.

Ensemble, ces trois changements déplacent le centre de gravité, puisque l'échéance réglementaire vers laquelle tout le monde travaillait a bougé tandis que la voie volontaire de la certification est devenue à la fois plus rigoureuse et, pour la première fois, réellement comparable d'un certificat à l'autre. Si votre plan 2026 a donc été écrit autour d'une falaise réglementaire fixée en août 2026, il vise désormais quelque chose qui n'est plus là.

Ce guide s'adresse à celles et ceux qui doivent répondre à la question dans un dossier de conseil d'administration ou une revue de sécurité client : qu'exige réellement un audit ISO/IEC 42001, quelles preuves le satisfont, et que vaut un certificat au regard du règlement IA maintenant que le calendrier a changé. Il est délibérément précis sur les preuves, car c'est là que les programmes de préparation échouent. Les organisations arrivent à l'étape 2 avec un corpus de politiques et aucune trace des décisions que ces politiques étaient censées encadrer.

On me pose toujours une variante de « sommes-nous prêts », et c'est la mauvaise question, car la préparation n'est pas un état que l'on atteint, c'est une propriété de vos enregistrements. Si vos preuves n'existent que parce que quelqu'un les a rassemblées pour l'audit, vous n'étiez pas prêts mais apprêtés, et ce sont deux choses différentes que l'édition 2026 d'ISO 19011 est justement conçue pour distinguer.

Les trois niveaux d'assurance que l'on confond systématiquement

Presque toutes les conversations confuses sur l'assurance de l'IA fusionnent trois choses distinctes. Elles ne sont pas équivalentes, elles ne sont pas délivrées par les mêmes organismes, et l'une d'elles n'existe aujourd'hui sous aucune forme exploitable. Les séparer est la chose la plus utile qu'une fonction conformité puisse faire ce trimestre.

Le premier niveau est la certification du système de management : un organisme accrédité audite votre système de management de l'IA au regard d'ISO/IEC 42001 et délivre un certificat couvrant un périmètre défini. Le deuxième est l'évaluation réglementaire de la conformité : pour un système d'IA à haut risque relevant du règlement IA, le fournisseur conduit une procédure d'évaluation de la conformité au titre de l'article 43, soit par contrôle interne (annexe VI), soit via un organisme notifié évaluant le système de management de la qualité et la documentation technique (annexe VII). Le troisième est la présomption de conformité au titre de l'article 40, accordée uniquement lorsqu'une norme harmonisée a été citée au Journal officiel.

C'est ce troisième niveau qui fait trébucher. En août 2026, aucune norme harmonisée du règlement IA n'a été citée au Journal officiel. Le pipeline du CEN-CENELEC JTC 21 commence à livrer : EN 18286:2026 sur les systèmes de management de la qualité a été approuvée le 12 juillet 2026 et constitue la première norme du règlement IA réellement publiée. Mais publication ne vaut pas citation, et seule la citation déclenche l'effet juridique. La conséquence pratique est nette : un certificat ISO/IEC 42001 ne confère aujourd'hui aucune présomption légale de conformité au règlement IA, et quiconque prétend le contraire vous vend quelque chose.

Ce que l'omnibus numérique sur l'IA a réellement changé

Le règlement (UE) 2026/1744 modifie le règlement IA plutôt qu'il ne le remplace. Le point saillant est le report : les obligations complètes pour les systèmes à haut risque de l'annexe III passent du 2 août 2026 au 2 décembre 2027, et les systèmes intégrés à haut risque de l'annexe I du 2 août 2027 au 2 août 2028. Le texte est disponible sur EUR-Lex, et le règlement (UE) 2024/1689 sous-jacent reste l'instrument de base.

Le raisonnement exposé par la Commission mérite une lecture attentive, car il s'agit d'un aveu aux conséquences opérationnelles. Le report a été proposé en réponse aux difficultés de mise en œuvre : retards dans la désignation des autorités nationales compétentes et des organismes d'évaluation de la conformité, et absence de normes harmonisées, d'orientations et d'outils de conformité pour l'IA à haut risque. Autrement dit, la machinerie d'évaluation n'était pas prête, l'obligation d'être évalué a donc été décalée.

Deux choses n'ont pas bougé. Les obligations de transparence s'appliquent depuis le 2 août 2026 comme prévu, avec des obligations de marquage des contenus générés par IA sur les systèmes déjà mis sur le marché applicables à compter du 2 décembre 2026, et les pratiques interdites, applicables depuis février 2025, ne sont pas concernées hormis quelques ajouts. Un report du régime haut risque n'est pas une amnistie générale.

Pour un ou une responsable conformité, la lecture est simple : vous avez gagné environ seize mois sur le chantier le plus lourd et rien du tout sur la transparence, les pratiques interdites ou les attentes commerciales de vos clients, puisque les directions achats n'ont rien reporté. Si tant est que cela change quelque chose, l'absence de plancher réglementaire rend un système de management audité indépendamment plus différenciant plutôt que moins.

ISO/IEC 42006:2025 : pourquoi les certificats ne se valent plus

ISO/IEC 42006:2025 a été publiée le 7 juillet 2025 et fixe les exigences applicables aux organismes fournissant l'audit et la certification des systèmes de management de l'IA, en s'appuyant sur ISO/IEC 17021-1. Avant son existence, un organisme certifiant un AIMS travaillait à partir d'une accréditation générique en systèmes de management et de sa propre lecture de ce que signifiait la compétence en IA, ce qui n'est plus acceptable.

L'effet pratique est triple : les organismes de certification doivent désormais démontrer une compétence spécifique en IA dans leurs équipes d'audit plutôt qu'une compétence générique assortie d'une bibliographie sur l'IA, la durée d'audit est calculée selon des critères définis au lieu d'être négociée à la baisse, et les organismes d'accréditation appliquent un programme de transition, ce qui signifie que la population des organismes légitimement habilités à délivrer un certificat ISO/IEC 42001 est activement filtrée.

Cela compte lorsque vous achetez de l'assurance et lorsque vous en recevez. Si vous sélectionnez un organisme de certification, demandez directement s'il est accrédité selon ISO/IEC 42006 et ce que couvre le périmètre d'accréditation. Si vous évaluez un fournisseur qui présente un certificat ISO/IEC 42001, vérifiez la marque d'accréditation et l'énoncé du périmètre sur le certificat lui-même. Un certificat délivré avant la transition ISO/IEC 42006, par un organisme sans accréditation spécifique à l'IA, n'a pas le même poids qu'un certificat délivré après.

ISO 19011:2026 : ce qui change dans la conduite de l'audit

ISO 19011:2026, quatrième édition des lignes directrices pour l'audit des systèmes de management, a été publiée le 27 mai 2026 et annule et remplace l'édition 2018. C'est une norme de recommandations : elle ne comporte donc ni date d'entrée en vigueur distincte ni période de transition, elle s'applique dès publication. Si votre programme d'audit interne est encore rédigé selon l'édition 2018, il est obsolète aujourd'hui, pas l'année prochaine.

La révision est technique plutôt que structurelle. Lue avec les commentaires publiés depuis mai par les organismes de certification et d'audit, trois évolutions ressortent pour un AIMS. La première est un déplacement de l'accent, qui ne porte plus sur la confirmation qu'un processus existe formellement mais sur l'évaluation de sa capacité à atteindre les résultats escomptés, ce qui constitue un resserrement significatif pour la gouvernance de l'IA. Une procédure d'évaluation d'impact IA qui existe, est validée et n'a jamais été appliquée à un modèle en production se lira différemment sous les recommandations 2026 que sous celles de 2018.

Le deuxième est l'élargissement des recommandations sur les méthodes d'audit à distance et les sites virtuels, s'appuyant sur ISO/IEC TS 17012. Cela convient bien aux systèmes d'IA, où les preuves significatives résident dans des dépôts, des registres de modèles, des systèmes de tickets et des tableaux de bord de surveillance plutôt que dans un classeur sur un site physique. Attendez-vous à ce que les équipes d'audit demandent un accès en lecture, des partages d'écran de systèmes en production et la traçabilité entre une version de modèle et l'approbation qui l'a autorisée.

Le troisième est l'amélioration des recommandations sur la documentation des constats, la restitution des résultats et l'enregistrement des non-conformités afin qu'elles soutiennent l'action corrective. En pratique, les constats vagues survivront moins. « Documentation insuffisante des performances du modèle » devient un constat qui nomme le modèle, la mesure, la preuve attendue et l'écart.

Pour les organisations qui exploitent un programme d'audit interne au regard d'ISO/IEC 42001, l'enchaînement est simple. Mettez à jour le programme d'audit selon les recommandations 2026, réévaluez les compétences d'audit au regard à la fois de ces recommandations et des connaissances spécifiques à l'IA, puis conduisez l'audit interne avant l'arrivée de l'organisme de certification plutôt qu'en formalité après avoir déclaré la préparation achevée.

Le dossier de preuves : ce qu'un audit ISO/IEC 42001 demande réellement

ISO/IEC 42001:2023 associe des clauses obligatoires à l'annexe A, qui porte 38 mesures réparties sur neuf objectifs de mesure (A.2 à A.10). Les mesures sont appliquées de façon sélective et justifiées dans une déclaration d'applicabilité. Ce qui suit est organisé par les preuves qu'une équipe d'audit demandera effectivement, domaine par domaine, en partant de ce qui manque habituellement plutôt que de ce qui est habituellement rédigé.

Inventaire des systèmes d'IA et périmètre

L'inventaire est le premier document demandé et le plus fréquemment insuffisant. Une équipe d'audit recherche un registre tenu à jour qui identifie chaque système d'IA dans le périmètre, sa finalité, son stade de cycle de vie, son propriétaire, sa classification de risque, s'il est développé en interne ou acquis, et où résident le modèle et les données. Le mode de défaillance type est un tableur exact le jour où le périmètre a été rédigé.

Preuves qui satisfont : un registre avec historique des modifications, un processus documenté d'ajout de systèmes et un lien démontrable avec les achats et la gestion du changement, de sorte qu'une nouvelle capacité d'IA ne puisse entrer dans le parc sans être enregistrée. Preuves qui ne satisfont pas : une liste statique sans colonne propriétaire ni date de dernière revue.

Évaluation d'impact IA

L'évaluation d'impact est l'endroit où le caractère spécifiquement IA de la norme mord le plus fort, et où les équipes dotées d'un programme ISO/IEC 27001 mature supposent le plus souvent, à tort, être couvertes. Une appréciation des risques de sécurité de l'information traite confidentialité, intégrité et disponibilité. Une évaluation d'impact IA doit aussi traiter les effets sur les personnes et les groupes, y compris les mésusages prévisibles, et être réexaminée lorsque le système change substantiellement.

Preuves qui satisfont : des évaluations complètes pour chaque système du périmètre, avec participants nommés, une méthode appliquée de façon cohérente, des impacts identifiés sur les personnes concernées et un déclencheur documenté de réévaluation lié au réentraînement du modèle ou au changement de finalité. Preuves qui ne satisfont pas : une évaluation unique au niveau de l'organisation couvrant « notre usage de l'IA ».

Gouvernance et provenance des données

Les équipes d'audit remontent la piste des données. Pour les données d'entraînement, de validation et de test, elles demanderont d'où elles proviennent, quels droits vous détenez pour les utiliser, comment leur pertinence et leur représentativité ont été appréciées et comment les problèmes de qualité ont été traités. Pour les systèmes utilisant des modèles de fondation tiers, les mêmes questions valent pour les données d'affinage et pour ce que le fournisseur accepte de divulguer sur le modèle de base.

Preuves qui satisfont : des décisions documentées de sourcing des données, des enregistrements de licences et de droits, une évaluation de la qualité des données rapportée à l'usage prévu, et une trace de ce qui a été exclu et pourquoi. Preuves qui ne satisfont pas : un catalogue de données sans champ de provenance.

Documentation de transparence et d'explicabilité

Les données de recherche montrent un net faisceau d'intérêt côté entreprises sur les preuves d'explicabilité qu'un audit exige réellement, et la réponse honnête est que cela dépend du public que la transparence sert. La norme attend de vous que vous ayez déterminé qui a besoin de comprendre quoi à propos du système, et que vous ayez produit une information appropriée à chaque groupe : utilisateurs, personnes concernées, fonctions de supervision internes et, le cas échéant, régulateurs.

Preuves qui satisfont : une détermination documentée des besoins d'information par public, les artefacts eux-mêmes (fiches de modèle, informations destinées aux utilisateurs, documentation technique interne) et un historique de versions liant chaque artefact à une version de modèle. Preuves qui ne satisfont pas : une fiche de modèle technique rédigée par l'équipe data science sans aucune trace que quiconque d'autre ait été pris en compte.

Équité et tests de biais

C'est le domaine de mesures où l'écart entre ce que les organisations disent et ce qu'elles peuvent montrer est le plus large. L'exigence n'est pas que votre système ressorte parfaitement équitable, ce qui n'est ni atteignable ni demandé par la norme, mais que vous ayez défini ce que l'équité signifie pour ce système dans ce contexte, testé au regard de cette définition, consigné le résultat et pris une décision documentée sur ce qui restait.

Preuves qui satisfont : un objectif d'équité énoncé par système, la métrique retenue et sa justification, des résultats de tests sur les cohortes pertinentes, le seuil d'acceptabilité et la validation de l'écart résiduel avec l'identité de qui l'a accepté. Preuves qui ne satisfont pas : une déclaration dans la politique IA affirmant que l'organisation est attachée à l'équité.

Supervision humaine

La supervision humaine est facile à affirmer et difficile à prouver. La question d'audit n'est pas de savoir si un humain est nominalement dans la boucle, mais si cette personne dispose de l'information, de l'autorité et de la capacité pratique d'intervenir, et si des interventions ont effectivement lieu.

Preuves qui satisfont : des rôles de supervision définis avec compétences documentées, l'interface ou le processus par lequel la supervision s'exerce, et des journaux montrant de véritables interventions, y compris dérogations et escalades. Preuves qui ne satisfont pas : un schéma de processus comportant une case « revue humaine » sans aucune trace qu'un humain ait jamais revu quoi que ce soit.

Traitement des incidents et surveillance après déploiement

Les incidents IA ne ressemblent pas aux incidents de sécurité. La dérive de modèle, la dégradation des performances sur un sous-groupe, un schéma de sortie inattendu ou une hallucination parvenant à un client sont tous des incidents au sens de la gouvernance de l'IA, et la plupart des organisations n'ont de voie de traitement pour aucun d'eux, parce que leur processus incident a été bâti pour les pannes et les violations de données.

Preuves qui satisfont : une définition de l'incident IA couvrant performance et comportement autant que disponibilité, une surveillance avec des seuils définis par système, des enregistrements de tri, et au moins un cas concret parcourant le processus jusqu'à une résolution documentée. Preuves qui ne satisfont pas : la procédure d'incident informatique générale avec le mot « IA » ajouté au paragraphe de périmètre.

IA des tiers et des fournisseurs

L'annexe A.10 régit les relations avec les tiers, et c'est là que le parc est généralement le plus vaste et la gouvernance la plus mince. Chaque fonctionnalité d'IA intégrée dans un produit SaaS acquis est de l'IA tierce. Il en va de même de chaque appel d'API vers un modèle de fondation, de chaque capacité d'IA activée par un éditeur lors d'une mise à jour produit, et de chaque modèle dans une chaîne de sous-traitance.

Preuves qui satisfont : l'IA des fournisseurs identifiée dans l'inventaire, des clauses contractuelles couvrant les obligations spécifiques à l'IA, une diligence raisonnable proportionnée au risque, et un processus de détection des capacités d'IA introduites par les éditeurs après la signature. Preuves qui ne satisfont pas : un registre fournisseurs avec une colonne Oui ou Non intitulée « utilise de l'IA ».

La traçabilité d'origine devient la preuve

Le déplacement le plus intéressant dans l'assurance de l'IA se joue aujourd'hui dans la traçabilité d'origine plutôt que dans les clauses du système de management. Régulateurs, organismes de normalisation et laboratoires de pointe sont arrivés à la même idée depuis trois directions différentes : si une machine a produit cet artefact, ce fait doit voyager avec l'artefact. Pour un programme d'audit, cela transforme un débat philosophique sur l'attribution en une mesure dont la sortie est testable.

Le moteur réglementaire est l'article 50 du règlement IA, que l'omnibus n'a pas reporté. Les obligations de transparence s'appliquent depuis le 2 août 2026. L'article 50 scinde l'exigence en deux couches que l'on confond régulièrement : une information visible pour l'humain, et un marquage lisible par machine intégré au contenu lui-même, afin qu'un système, et non une personne, puisse détecter que la sortie a été générée artificiellement. Les systèmes génératifs déjà sur le marché avant le 2 août 2026 disposent jusqu'au 2 décembre 2026 pour satisfaire l'exigence de marquage lisible par machine. Les sanctions de ce niveau atteignent 15 millions d'euros ou 3 pour cent du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu, avec une nuance utile : pour les PME et les jeunes entreprises, le plafond est le plus faible des deux montants et non le plus élevé.

La réponse de fait à la moitié lisible par machine est le Content Credential C2PA, soutenu par plusieurs milliers de membres, dont Adobe, Microsoft, Google, Intel, la BBC et AP. Soyez précis sur son statut, car la spécification fait seulement l'objet d'une procédure accélérée vers une norme ISO, ISO 22144 sur les content credentials, encore au stade de projet en août 2026. Traitez C2PA comme la convention du marché plutôt que comme une norme internationale établie, et méfiez-vous des fournisseurs qui la présentent comme déjà publiée. Un Content Credential lie l'horodatage de création, le modèle et sa version, ainsi que les modifications humaines ultérieures, dans une signature cryptographique portée à l'intérieur du fichier, ce qui le rend auditable : une équipe d'audit peut ouvrir une sortie et vérifier si le justificatif est présent, intact et cohérent avec ce que votre inventaire déclare l'avoir produite.

Observez ce que cela fait au domaine de la transparence. La preuve de transparence était jusqu'ici documentaire, c'est-à-dire fiches de modèle, informations et politiques, alors que le marquage d'origine en rend une partie forensique, si bien que vous pouvez prélever un échantillon de sorties et le vérifier réellement, ce qui correspond au type de preuve vers lequel ISO 19011:2026 pousse les équipes d'audit puisqu'il démontre l'efficacité plutôt que l'existence.

Le cas que personne n'a cadré : le code écrit par l'IA

La traçabilité des contenus attire l'attention parce que le règlement la nomme, mais l'exposition non cadrée la plus importante dans la plupart des organisations reste le code. Des assistants de programmation écrivent aujourd'hui du logiciel de production dans des entreprises dont l'inventaire IA recense trois modèles orientés client et rien d'autre. Demandez à une fonction gouvernance si le code généré par IA entre dans le périmètre de l'AIMS : vous obtiendrez généralement un silence, puis un non, puis un silence beaucoup plus long.

L'outillage a discrètement résolu la partie difficile. Claude Code, d'Anthropic, inscrit une mention Co-Authored-By portant l'identifiant du modèle dans chaque commit auquel il participe, si bien qu'une seule requête git log retourne tous les commits assistés par IA de l'historique. Des conventions plus larges émergent et ajoutent de la gradation, avec une mention Assisted-by pour une suggestion légère, Co-authored-by pour une contribution substantielle et Generated-by pour du code majoritairement écrit par la machine, chacune associée à un Signed-off-by qui maintient une personne nommée responsable. Rien de tout cela n'exige l'achat d'une plateforme, puisqu'il s'agit de métadonnées que votre gestionnaire de versions transporte déjà.

Pour une organisation d'ingénierie régulée, c'est la mesure de gouvernance de l'IA la moins coûteuse qui existe, et la plus souvent désactivée. Les équipes coupent la mention pour des raisons cosmétiques, parce qu'elle encombre le journal ou parce qu'un responsable en déteste l'apparence, et cette décision supprime discrètement la piste d'audit. Lorsqu'une revue d'incident, un questionnaire de sécurité client ou un régulateur demandera un jour quelles parties d'un système ont été écrites par une machine et qui les a acceptées, mieux vaut que la réponse soit une requête plutôt qu'un chantier d'archéologie. À noter aussi que la mention peut être désactivée, une recherche git log constitue donc un signal positif et non une preuve d'absence.

Étape 1, étape 2 et surveillance : le cycle en pratique

La certification suit le modèle classique en deux étapes hérité d'ISO/IEC 17021-1, affiné pour l'IA par ISO/IEC 42006. L'étape 1 est une revue de préparation et de documentation, incluant généralement l'énoncé du périmètre, la déclaration d'applicabilité, la méthode d'appréciation des risques et d'impact, le rapport d'audit interne et la revue de direction. Elle sert à déterminer si l'étape 2 est viable, et une étape 1 se concluant par un report est une issue normale et souvent correcte.

L'étape 2 teste la mise en œuvre et l'efficacité. Sous ISO 19011:2026, l'accent sur l'efficacité est plus marqué : l'équipe échantillonne des cas réels et demande si le système a atteint ce pour quoi il a été conçu. Les constats sont gradués, les non-conformités majeures bloquant la certification jusqu'à correction et les mineures exigeant un plan d'action corrective.

Après certification, le cycle enchaîne des audits de surveillance, normalement annuels, avec une recertification complète la troisième année. La surveillance n'est pas une version allégée du même audit mais un examen de ce qui a changé depuis la visite précédente, et dans un parc d'IA le changement est permanent : nouveaux modèles, modèles réentraînés, nouveaux fournisseurs, nouveaux cas d'usage. Les organisations qui la traitent comme une formalité accumulent des constats précisément parce que leur maîtrise du changement n'a jamais maintenu l'AIMS à jour.

Ce que cela coûte en effort, honnêtement

L'effort est dominé par la reconstitution des preuves, pas par la documentation. Les organisations qui exploitent déjà un système de management ISO/IEC 27001 certifié trouvent généralement la structure des clauses familière et le contenu de l'annexe A étranger : le squelette de gouvernance se transpose, les mesures spécifiques à l'IA non. Le gros du travail porte sur la complétude de l'inventaire, les évaluations d'impact par système et la construction de la chaîne de traçabilité de la version de modèle jusqu'à l'approbation.

Deux postes de coût sont systématiquement sous-estimés. Les audits de surveillance reviennent chaque année et augmentent avec la taille et la volatilité du parc d'IA, qui croît dans la plupart des organisations. Et la compétence d'audit interne comporte désormais une dimension IA qu'une expérience générique en systèmes de management ne fournit pas automatiquement, ce qui impose soit de former votre équipe existante, soit d'acquérir la capacité.

Ce qu'ISO/IEC 42001 ne résout pas

La certification est une assurance portant sur le système de management, et trois choses que l'on attend d'elle ne se produiront pas. Elle n'évalue pas si un système d'IA précis est sûr ou exact, car c'est une question de niveau produit qui relève de la documentation technique et non du certificat. Une organisation certifiée peut déployer un mauvais modèle, et l'audit ne le détectera que si le processus de gouvernance censé le détecter a lui aussi échoué.

Elle ne se substitue pas à l'évaluation de la conformité au règlement IA. Si vous êtes fournisseur d'un système d'IA à haut risque, l'article 43 s'applique à vous selon le calendrier reporté, et un certificat de système de management n'est pas une évaluation de la conformité. C'est un travail préparatoire réellement utile, en particulier pour les exigences de système de management de la qualité de l'article 17, mais ce sont deux objets juridiques distincts.

Et elle ne confère pas, aujourd'hui, de présomption de conformité. Cela restera vrai tant qu'une norme harmonisée n'aura pas été citée au Journal officiel. Surveillez le pipeline du JTC 21, mais lisez-le précisément : EN 18286:2026 sur les systèmes de management de la qualité est désormais publiée, ce qui est un progrès réel, et elle n'a toujours pas été citée. Notez aussi que les exigences de système de management de la qualité de l'article 17 se situent hors des dispositions du chapitre III section 2 auxquelles s'attache la présomption de l'article 40 : même une citation à cet endroit ne produirait pas une présomption nette pour tout le régime haut risque. Ne bâtissez pas un argumentaire de conformité sur une citation qui n'a pas eu lieu.

Trois schémas de certification, et ce que chacun enseigne

Les recommandations sur la preuve ne deviennent utiles que lorsqu'on voit la forme qu'elles prennent dans une organisation réelle. Trois situations reviennent assez souvent pour mériter un nom. La première est publique et vérifiable. Les deux autres se déduisent de ce qui se produit quand la norme rencontre un parc d'entreprise ordinaire, traitez-les donc comme de l'arithmétique et non comme des anecdotes.

Schéma un : le laboratoire de pointe, où la gouvernance est venue d'abord

Anthropic a obtenu une certification ISO/IEC 42001 accréditée pour son système de management de l'IA, parmi les premiers laboratoires d'IA de pointe à le faire, le certificat ayant été délivré par Schellman Compliance, LLC, organisme accrédité par l'ANSI National Accreditation Board, avec prise d'effet en janvier 2025. Lisez ensuite la ligne de périmètre plutôt que le titre, car elle couvre la recherche et le développement en IA ainsi que les services d'IA plutôt que l'organisation entière, ce qui est exactement la distinction sur laquelle cet article insiste, visible ici sur l'un des certificats les plus scrutés du secteur.

Le détail instructif est l'ordre des opérations, car la certification s'est appuyée sur une gouvernance qui existait déjà et était déjà publique : un cadre de mise à l'échelle responsable publié, un travail délibéré sur le comportement et l'alignement des modèles, et une recherche continue en sécurité. Plutôt que de créer la gouvernance, l'audit a rendu une gouvernance existante lisible par un tiers, ce qui est le bon sens de lecture et celui que la plupart des programmes d'entreprise inversent. Ils commandent un corpus de politiques pour se faire certifier, puis découvrent à l'étape 2 que des politiques sans enregistrements d'exploitation ne prouvent rien.

Une seconde leçon se cache dans l'organisme de certification. Les données de recherche montrent que les gens interrogent activement si telle ou telle firme est un prestataire d'audit ISO 42001. Les acheteurs pratiquent désormais exactement la diligence qu'ISO/IEC 42006 a été écrite pour permettre : non seulement vérifier qu'un certificat existe, mais vérifier qui l'a délivré et sous quelle accréditation. Si votre questionnaire d'achat demande aux fournisseurs un certificat ISO 42001 mais ne demande ni la marque d'accréditation ni l'énoncé du périmètre, vous collectionnez un logo.

Schéma deux : le choc de l'inventaire

Prenez une organisation persuadée d'exploiter une poignée de systèmes d'IA : un assistant orienté client, un modèle de prévision, un classificateur de documents. Faites maintenant l'arithmétique que le cadrage impose. Comptez les fonctions d'IA déjà activées dans la plateforme de support, le scoring dans l'outil de recrutement, l'assistant intégré au CRM, les assistants de programmation dans toute l'ingénierie, la traduction et la rédaction dans la suite bureautique. Presque aucune n'a été construite par quiconque dans la salle, et chacune est un système d'IA au sens de la définition de la norme.

Cet écart n'est pas un défaut de documentation, c'est un défaut de cadrage à racine gouvernance, car rien dans les achats ni dans la gestion du changement n'a jamais imposé de déclarer une capacité d'IA. La correction est peu spectaculaire : ajoutez une porte de déclaration IA à l'enrôlement fournisseur et à l'acceptation des changements produit, puis passez une fois en revue les contrats existants et les consoles d'administration. C'est de le faire avant de rédiger la politique qui économise les reprises, car l'inventaire fixe le périmètre, le périmètre fixe la déclaration d'applicabilité, et la déclaration d'applicabilité fixe tout ce qu'il faudra prouver.

Schéma trois : le titulaire ISO 27001

Une organisation dotée d'un système de management de la sécurité de l'information mature et certifié aborde ISO/IEC 42001 comme un exercice de delta. En un sens elle a raison : la structure des clauses, le rythme des revues de direction, la machinerie d'audit interne et le processus d'action corrective se transposent intégralement. C'est une véritable avance et cela raccourcit généralement le calendrier de manière significative.

Là où cela dérape, c'est l'hypothèse que le travail sur les risques se transpose aussi, alors qu'il ne se transpose pas. Une appréciation des risques de sécurité raisonne en menace, vulnérabilité et impact sur l'organisation, tandis qu'une évaluation d'impact IA raisonne sur les effets envers les personnes et les groupes, y compris les mésusages prévisibles, ce qui est un objet analytique différent exigeant des participants différents. Les équipes qui confient l'évaluation d'impact IA à la seule fonction sécurité produisent des documents compétents, bien structurés, et qui manquent systématiquement la dimension des personnes affectées que la norme interroge réellement. Faire entrer le juridique, la fonction protection des données et un responsable métier dans la même évaluation est la correction unique qui résout le problème.

Que faire maintenant, par rôle

La gouvernance de l'IA échoue aux coutures entre fonctions plus souvent qu'à l'intérieur de l'une d'elles. Le report du régime haut risque a supprimé l'échéance artificielle qui forçait ces fonctions à se réunir, ce qui rend l'attribution explicite des rôles plus importante, pas moins. Le tableau ci-dessous est la répartition qui fonctionne en pratique.

Un point de coordination relie ces six rôles. Quelqu'un doit porter l'enregistrement des décisions, et ce ne doit pas être la personne qui pilote le projet de certification. L'enregistrement des décisions est une habitude d'exploitation permanente : s'il est porté par un programme temporaire, il meurt la semaine où le certificat arrive, c'est-à-dire précisément quand le premier audit de surveillance commence à accumuler ses constats.

Liste de contrôle de préparation

Utilisez ceci comme auto-test avant l'étape 1. Si vous ne pouvez pas répondre oui avec la preuve jointe, voilà votre liste d'écarts.

Que faire dans les 90 prochains jours

D'abord, recalibrez le plan sur le calendrier modifié. Si votre programme a été dimensionné pour une échéance du règlement IA en août 2026, redimensionnez-le, car les obligations haut risque de l'annexe III mordent désormais au 2 décembre 2027 et celles de l'annexe I au 2 août 2028, tandis que les obligations de transparence s'appliquent déjà. Ce que vous avez est une réaffectation de l'effort plutôt qu'une pause.

Ensuite, comblez l'écart de preuves plutôt que l'écart de politiques. Prenez trois systèmes d'IA au hasard dans l'inventaire et tentez le test de traçabilité : évaluation d'impact, décisions sur les données, résultats de tests, approbation, surveillance, en moins d'une heure chacun. Ce qui casse constitue votre programme de préparation.

Enfin, réparez la fonction d'audit avant de réparer la documentation. Mettez à jour le programme d'audit interne selon ISO 19011:2026, vérifiez que la personne qui le conduit détient une compétence spécifique à l'IA et pas seulement une compétence en systèmes de management, et conduisez un vrai audit interne. Les constats seront plus utiles que n'importe quelle analyse d'écarts produite par un cabinet, parce qu'ils proviennent de vos propres preuves.

Prochaine étape

Si votre rôle consiste à conduire ou à commanditer des audits d'AIMS, la formation certifiante ISO 42001 Lead Auditor couvre le processus d'audit de bout en bout au regard d'ISO 19011:2026 et du contexte ISO/IEC 42006. Si vous construisez le système de management plutôt que vous ne l'auditez, le programme ISO 42001 Lead Implementer est le bon point d'entrée, et les équipes centrées sur la couche de risque sous-jacente commencent généralement par Lead AI Risk Manager. Les trois figurent dans notre hub de formation sur la gouvernance de l'IA, aux côtés du playbook de mise en œuvre et du guide de conformité au règlement IA.