Business Digital

Préparer ISO/IEC 42001 Lead Implementer PECB : gouvernance IA

12 min de lecture

La certification PECB Certified ISO/IEC 42001 Lead Implementer est l’une des premières certifications internationales centrées sur la gouvernance de l’intelligence artificielle. Elle prépare à la mise en place d’un système de management de l’IA (AIMS, AI Management System) conforme à la norme ISO/IEC 42001:2023, publiée en décembre 2023. Ce tutoriel propose un plan d’étude méthodique de cinq semaines, calibré sur le cours officiel PECB de quatre jours et sur les attendus de l’examen scenario-based.

Pour le panorama complet PECB et le positionnement de cette certification face aux profils DPO et RSSI, voir le panorama des certifications PECB 2026.

Prérequis avant de démarrer

L’ISO/IEC 42001 est une norme jeune, ce qui implique deux conséquences pratiques. Premièrement, les ressources d’appoint sont rares — peu de retours d’examen, peu de blogs détaillés, pas encore de bibliothèque d’exercices commune comme on en trouve pour ISO 27001. Le manuel candidat PECB est de fait votre source principale, complétée par la norme elle-même et par les guides régulateurs européens. Deuxièmement, la transition vers la mise en œuvre opérationnelle se fait sous pression réglementaire : l’AI Act européen, adopté en 2024 et entré en vigueur le 1er août 2024, introduit des obligations progressives : depuis le 2 février 2025 (pratiques IA interdites et exigences d’AI literacy), le 2 août 2025 (modèles d’IA d’usage général) et le 2 août 2026 (systèmes IA à haut risque), ce qui rend la certification d’autant plus valorisable que l’organisation se trouve en chantier de conformité IA.

Le profil idéal a déjà une exposition à un système de management ISO (typiquement ISO 27001) et à au moins un projet IA en entreprise. Les concepts AIMS empruntent largement à la grammaire ISO classique (politique, périmètre, parties intéressées, appréciation de risque, mesures, surveillance), donc un Lead Implementer 27001 préalable est un excellent accélérateur. Côté IA, savoir distinguer un modèle entraîné d’un modèle de fondation, comprendre ce qu’est un dataset d’entraînement et un dataset de validation, et avoir vu une fois la chaîne ML complète sont des prérequis informels.

Le matériel à se procurer comprend le manuel candidat PECB ISO/IEC 42001 Lead Implementer, un exemplaire de la norme ISO/IEC 42001:2023 (achat séparé), idéalement les normes connexes ISO/IEC 23894:2023 (lignes directrices pour la gestion du risque IA) et ISO/IEC 23053:2022 (cadre pour l’IA et le machine learning), et une lecture du texte de l’AI Act européen au moins sur les articles relatifs aux systèmes à haut risque.

Vue d’ensemble du plan en cinq semaines

  • Semaine 1 — Fondamentaux IA, vocabulaire AIMS, articulation 42001 / 23894 / AI Act
  • Semaine 2 — Contexte, parties intéressées, périmètre AIMS
  • Semaine 3 — Évaluation d’impact des systèmes IA et appréciation des risques
  • Semaine 4 — Contrôles de l’Annexe A 42001 et déclaration d’applicabilité
  • Semaine 5 — Surveillance, amélioration, examens blancs

Étape 1 — Semaine 1 : fondamentaux IA et vocabulaire AIMS

La norme ISO/IEC 42001 emprunte sa structure générique à la Harmonized Structure (anciennement Annex SL) commune à toutes les normes de système de management ISO récentes. Cette structure facilite la cohabitation de plusieurs systèmes (27001, 22301, 42001) dans une même organisation. Mais elle se double d’un vocabulaire spécifique à l’IA qu’il faut maîtriser dès la première semaine.

Les définitions à fixer sont : système IA (système d’ingénierie pouvant pour un ensemble donné d’objectifs définis par l’humain générer des sorties telles que des prédictions, recommandations ou décisions influençant des environnements réels ou virtuels), cycle de vie d’un système IA (conception, développement, validation, déploiement, exploitation, retrait), partie prenante (toute entité affectée par ou affectant le système IA, incluant fournisseur, déployeur, utilisateur final, personne concernée), impact (effet d’un système IA sur ses parties prenantes), et évaluation d’impact d’un système IA (analyse documentée des impacts potentiels sur les parties prenantes).

L’articulation avec l’AI Act européen est centrale et testable. L’AI Act classe les systèmes IA en quatre catégories de risque : inacceptable (interdit), élevé (obligations strictes), limité (obligations de transparence) et minimal (pas d’obligation spécifique). ISO/IEC 42001 n’est pas un règlement mais un cadre volontaire — adopter 42001 ne garantit pas la conformité AI Act, mais facilite très significativement la démonstration de cette conformité. À l’examen PECB, vous pouvez référencer l’AI Act dans vos justifications mais la source d’autorité reste le manuel et la norme 42001.

Livrable de la semaine : produire un glossaire personnel de quinze termes minimum avec définition officielle, exemple sectoriel et mapping vers l’AI Act quand applicable.

Étape 2 — Semaine 2 : contexte, parties intéressées, périmètre

L’établissement du contexte AIMS suit la même mécanique qu’un SMSI 27001 mais avec une particularité importante : les parties intéressées incluent les personnes concernées par les décisions du système IA (candidats évalués par un système de tri de CV, patients diagnostiqués par un système d’aide médicale, justiciables évalués par un système de scoring de récidive). Cette catégorie n’a pas d’équivalent direct dans 27001 et son omission est une non-conformité fréquente.

Le périmètre AIMS peut être délicat à définir. Une organisation déploie souvent plusieurs systèmes IA hétérogènes — un chatbot de support client (risque limité AI Act), un système RH de tri de candidatures (à haut risque), un assistant de rédaction interne (risque minimal). Faut-il couvrir tous les systèmes par un même AIMS, ou se limiter aux systèmes à haut risque ? La réponse normative est que le périmètre doit refléter la stratégie IA et les exigences réglementaires applicables. En pratique, démarrer par un périmètre restreint (les systèmes à haut risque uniquement) puis l’étendre est une approche défendable et fréquente.

La politique IA (clause 5.2) est un document signé par la direction qui formalise la posture de l’organisation sur l’IA : objectifs éthiques, principes directeurs (transparence, équité, contrôle humain, robustesse, vie privée, sécurité), périmètre, gouvernance. C’est l’équivalent de la politique de sécurité dans un SMSI 27001.

Livrable de la semaine : produire un document de contexte pour une organisation imaginaire qui déploie deux systèmes IA (un système RH à haut risque et un chatbot client), une cartographie des parties intéressées incluant les personnes concernées, et une politique IA d’une page.

Étape 3 — Semaine 3 : évaluation d’impact et appréciation des risques

ISO/IEC 42001 introduit deux concepts qui n’existent pas dans 27001. Le premier est l’évaluation d’impact d’un système IA (AI System Impact Assessment, AIS-IA), formalisée par l’Annexe B du manuel et précisée par la norme connexe ISO/IEC 42005:2025 (lignes directrices pour l’évaluation d’impact). Cette évaluation s’inspire de l’analyse d’impact relative à la protection des données (AIPD) du RGPD mais l’étend à l’ensemble des effets sociétaux, éthiques et techniques.

Le second est l’appréciation des risques IA, qui suit la structure ISO 31000 / 23894 mais avec des sources de risque spécifiques : biais dans les données d’entraînement, dérive du modèle en production, robustesse face aux attaques adversariales, opacité du modèle (boîte noire), perte de contrôle humain, atteinte aux droits fondamentaux des personnes concernées. La norme ISO/IEC 23894:2023 fournit le cadre détaillé de cette appréciation et le manuel PECB y renvoie abondamment.

L’examen testera votre capacité à mener une AIS-IA et une appréciation de risque IA cohérentes. Le piège classique est de confondre les deux : l’AIS-IA porte sur les impacts du système (que se passe-t-il si le système est utilisé comme prévu), tandis que l’appréciation de risque porte sur les scénarios de défaillance du système (que se passe-t-il s’il dysfonctionne). Une organisation a besoin des deux livrables, qui s’alimentent mutuellement.

Livrable de la semaine : produire une AIS-IA et une appréciation de risque sur le système RH imaginaire de tri de candidatures. L’AIS-IA doit couvrir les impacts sur les candidats, sur les recruteurs, sur l’organisation, sur la conformité réglementaire. L’appréciation de risque doit lister au minimum cinq scénarios de défaillance avec vraisemblance et impact.

# Trame AIS-IA — sections minimales
1. Description du système IA et de son cycle de vie
2. Cartographie des parties prenantes (incluant personnes concernées)
3. Impacts positifs attendus (par partie prenante)
4. Impacts négatifs potentiels (par partie prenante)
5. Mesures d'atténuation prévues
6. Décision : déploiement, déploiement conditionnel, abandon

Étape 4 — Semaine 4 : Annexe A et déclaration d’applicabilité

ISO/IEC 42001:2023 inclut deux annexes informatives importantes. L’Annexe A liste les contrôles AIMS de référence, regroupés en neuf objectifs : politiques relatives à l’IA, structures et rôles internes, ressources pour les systèmes IA, évaluation d’impact, cycle de vie du système IA, données pour les systèmes IA, information aux parties intéressées, usage des systèmes IA, relations avec les tiers. L’Annexe B fournit des lignes directrices pour la mise en œuvre de ces contrôles.

L’objectif de la semaine est de naviguer rapidement dans l’Annexe A pendant l’examen. Comme pour 27001, l’apprentissage par cœur n’est ni réaliste ni nécessaire — mais le repérage doit être rapide. Préparez un index personnel des objectifs et de leurs contrôles, avec des onglets dans votre exemplaire papier de la norme.

Les contrôles les plus testés sont ceux liés à la gouvernance des données (qualité, représentativité, gestion des biais, étiquetage), au cycle de vie (validation, test, déploiement, surveillance, retrait), et aux relations avec les fournisseurs (audit des fournisseurs de modèles de fondation, transfert de responsabilité, transparence sur les données d’entraînement utilisées par le fournisseur).

La déclaration d’applicabilité AIMS suit la même mécanique que la SoA de 27001 — pour chaque contrôle de l’Annexe A, sa pertinence, sa justification, son état d’implémentation. Le livrable réel d’un projet AIMS pèse une vingtaine de pages.

Livrable de la semaine : produire une SoA partielle (dix contrôles bien choisis) pour le système RH de tri de candidatures.

Étape 5 — Semaine 5 : surveillance, amélioration, examens blancs

La surveillance d’un système IA en production est techniquement plus complexe que la surveillance d’un SMSI classique, parce qu’elle implique la détection de dérives statistiques (le modèle reçoit en production des données différentes de celles d’entraînement, et ses performances chutent). Cette surveillance se fait via des indicateurs spécifiques : data drift (dérive des distributions de variables d’entrée), concept drift (dérive de la relation entre entrées et sortie), fairness metrics (mesures d’équité comme la parité démographique ou l’égalité des chances).

Cette surveillance technique est complétée par une surveillance non-technique : retours des utilisateurs, réclamations des personnes concernées, signalements internes éthiques, audits réguliers. L’examen testera la complémentarité des deux dimensions.

L’amélioration continue d’un AIMS inclut le réentraînement périodique des modèles, la mise à jour des datasets, la révision de l’AIS-IA quand le périmètre ou l’usage du système évolue. Une organisation qui aurait certifié un AIMS en 2024 sans le mettre à jour en 2026 se retrouverait avec un système formellement conforme mais déconnecté de la réalité opérationnelle.

La fin de semaine est consacrée aux examens blancs. Le format scenario-based MCQ comporte typiquement douze scénarios en 3 heures, livre ouvert. Comme la norme est jeune, les questions tendent à porter davantage sur la cohérence méthodologique (« quel est le bon ordre des étapes ») et sur la compréhension conceptuelle (« quelle est la différence entre AIS-IA et appréciation de risque ») que sur des cas opérationnels très détaillés.

Erreurs fréquentes en préparation

Erreur Cause Solution
Confondre AIS-IA et appréciation de risque Vocabulaire jeune Semaine 3 dédiée, deux livrables distincts
Oublier les personnes concernées Reprise mécanique de 27001 Étendre la cartographie aux destinataires des décisions IA
Confondre 42001 et AI Act Pression réglementaire 42001 = cadre volontaire ; AI Act = règlement contraignant
Surveillance limitée à la sécurité IT Approche cybersécurité Inclure data drift, concept drift, fairness, réclamations
Périmètre trop large dès le départ Sur-ambition Démarrer sur les systèmes à haut risque, étendre ensuite

Après l’examen et marché de la certification

Le marché de la gouvernance IA est en très forte croissance depuis 2024, tirée par l’AI Act européen et par les politiques internes des grands groupes qui anticipent les obligations. Les profils certifiés ISO/IEC 42001 sont rares au moment de la première vague — typiquement RSSI ou DPO qui ajoutent ce titre à leur portefeuille, consultants conformité, juristes IT qui veulent monter en compétence technique.

Pour un DPO, ISO/IEC 42001 Lead Implementer est complémentaire de la certification DPO (CNIL en France, EUDPB au niveau européen). Le mapping entre AIS-IA et AIPD est direct mais incomplet — l’AIS-IA couvre des dimensions (équité, robustesse) que l’AIPD ne couvre pas. Pour un RSSI, le titre permet de prendre en charge la gouvernance IA sans recruter un nouveau profil.

La certification est valable trois ans, avec cotisation PECB annuelle et 31 crédits CPD à valoriser sur le cycle. Étant donné la jeunesse de la norme, les conférences spécialisées (notamment l’ICAIS et les événements ENISA sur l’IA) sont aujourd’hui les meilleures sources de CPD éligibles.

Ressources et références officielles

Articles connexes

Service ITSkillsCenter

Site ou application web sur mesure

Conception Pro + Nom de domaine 1 an + Hébergement 1 an + Formation + Support 6 mois. Accès et code livrés. À partir de 350 000 FCFA.

Demander un devis
Publicité