ISO/IEC 42001 : le référentiel qui structure votre gouvernance IA
L'AI Act dit ce qui est interdit. ISO/IEC 42001 dit comment s'organiser pour le prouver. Ce sont deux choses différentes — et la seconde est celle qui tient dans le temps.
Depuis l'entrée en vigueur de l'AI Act, les organisations cherchent une réponse à une question simple : que doit-on mettre en place. La réponse réglementaire existe, mais elle est partielle : le règlement définit des obligations, pas une méthode d'organisation.
C'est là qu'intervient l'ISO/IEC 42001, publiée fin 2023. Ce n'est pas un texte qui dit ce qui est légal ou interdit. C'est un référentiel de système de management : il décrit comment une organisation peut structurer, documenter et améliorer sa gouvernance de l'intelligence artificielle.
La différence avec l'AI Act
- L'AI Act est un règlement. Il fixe des obligations opposables, avec des sanctions. Il dit ce que vous devez faire, pas comment vous organiser.
- ISO/IEC 42001 est un standard volontaire. Il décrit un système de management : politiques, rôles, processus, évaluation des risques, amélioration continue.
Les deux se complètent. Le règlement crée l'obligation ; le standard fournit la preuve organisationnelle. Une entreprise peut se conformer à l'AI Act sans ISO 42001, mais elle devra construire sa propre méthode — et la défendre devant un régulateur.
Pas un document de plus : une boucle de décision. Qui décide qu'un système IA peut être mis en service, sur quelle analyse de risque, avec quels contrôles, et comment cette décision est revue. C'est cette boucle que l'auditeur cherche.
Les cinq briques d'un système de management IA
1. Une politique
Un document court qui dit ce que l'organisation accepte et refuse en matière d'IA. Sans politique, chaque projet négocie ses propres règles.
2. Des rôles
Qui est responsable de l'inventaire des systèmes, de l'évaluation des risques, de la validation, de la surveillance en production. Un rôle non nommé est un rôle non tenu.
3. Un inventaire
La liste des systèmes IA en service, en projet et abandonnés, avec leur finalité et leur niveau de risque. C'est la base de tout le reste.
4. Une évaluation des risques
Une méthode reproductible : quels risques, pour qui, avec quelle gravité, quelles mesures de réduction. Pas une analyse ad hoc par projet.
5. Une surveillance
Ce qui est mesuré après la mise en service : dérives, incidents, plaintes, corrections. Un système validé une fois n'est pas un système validé pour toujours.
Pourquoi les organisations échouent
Le premier échec est de traiter le standard comme un exercice documentaire. On produit une politique, un inventaire, des procédures — et rien ne change dans les décisions réelles. L'auditeur le voit immédiatement : les documents ne sont reliés à aucune décision.
Le second échec est de vouloir tout couvrir d'un coup. Un système de management se construit par périmètre : commencer par les systèmes les plus risqués, prouver la boucle, puis étendre.
« Une gouvernance IA qui n'a jamais refusé un projet n'est pas une gouvernance. C'est une formalité. »
Ce qu'il faut retenir
ISO/IEC 42001 ne rend pas une organisation conforme à l'AI Act. Il rend sa conformité démontrable, et surtout maintenable. La différence entre les deux se voit le jour où un système change, où un incident survient, où un régulateur demande des comptes.
La bonne question n'est pas « faut-il se certifier », mais « sommes-nous capables de prouver, projet par projet, pourquoi nous avons décidé ce que nous avons décidé ».
Retour aux articles