L'ISO/IEC 42001:2023 établit les exigences pour créer, maintenir et améliorer un système de management de l'intelligence artificielle. Elle s'adresse aussi bien aux organisations qui développent l'IA qu'à celles qui la fournissent ou l'utilisent. Une PME n'a pas besoin de reproduire la bureaucratie d'une multinationale : elle a besoin d'un périmètre clair, d'un inventaire fiable, de décisions fondées sur le risque, de responsables identifiés et de preuves proportionnées.
Qu'est-ce qu'un système de management de l'IA
Un SMIA — Système de Management de l'Intelligence Artificielle (AIMS en anglais) — relie politique, objectifs, processus, personnes, données, technologie, fournisseurs, évaluation et amélioration au sein d'un système de management de l'IA conforme à l'ISO/IEC 42001. Il ne certifie pas que chaque résultat est correct et ne remplace pas la loi : il démontre que l'organisation gouverne l'IA au moyen d'un système auditable.
L'ISO/IEC 42001 suit la structure de haut niveau des autres normes de management, ce qui facilite son intégration avec l'ISO 9001, l'ISO/IEC 27001 ou l'ISO 14001.
Pour qui cela a du sens
La démarche peut apporter de la valeur lorsque la PME :
- développe des produits ou des composants d'IA ;
- intègre des modèles tiers dans ses services ;
- utilise l'IA dans des processus critiques ;
- doit répondre aux exigences de clients ou d'appels d'offres ;
- doit coordonner l'AI Act, le RGPD, la sécurité et la qualité ;
- souhaite une certification indépendante.
Il ne faut pas rechercher la certification pour le seul marketing. Il doit d'abord exister un cas d'usage solide et la capacité à faire vivre le système.
Étape 1. Définir le périmètre
Le périmètre identifie les entités, sites, produits, processus et rôles concernés. « Toute l'IA de l'entreprise » peut être ingérable ; « développement et exploitation de l'assistant documentaire client en Espagne » est vérifiable.
Il faut éviter d'exclure des dépendances critiques : données, plateforme, fournisseurs, sécurité ou support. Les interfaces avec des domaines hors périmètre sont documentées.
Questions clés pour délimiter le périmètre :
- Développons-nous, fournissons-nous ou utilisons-nous de l'IA ?
- Quels systèmes génèrent le plus fort impact ?
- Quels clients et quelles personnes sont concernés ?
- Quelles obligations contractuelles et légales existent ?
- Quelle équipe peut faire vivre le système ?
Étape 2. Contexte et parties prenantes
On analyse les enjeux internes et externes : stratégie, réglementation, maturité, dépendance aux fournisseurs, compétences, disponibilité des données, cybersécurité et attentes sociétales.
Les parties prenantes peuvent inclure les clients, les utilisateurs, le personnel, les personnes concernées, les régulateurs, les fournisseurs, les actionnaires et la société. Les exigences pertinentes sont consignées, ainsi que leurs modalités de revue.
Toute attente ne devient pas une obligation, mais la sélection doit être justifiée.
Étape 3. Inventaire des systèmes d'IA
L'inventaire est la colonne vertébrale du système. Chaque fiche contient :
- nom, propriétaire et version ;
- finalité et décisions concernées ;
- rôle de l'organisation ;
- utilisateurs et personnes concernées ;
- modèles, données et outils ;
- fournisseur et sous-traitants ;
- environnement et sites ;
- autonomie et supervision ;
- classification juridique et de risque ;
- indicateurs, incidents et statut.
L'IA « de l'ombre » est également recensée : comptes personnels, fonctions intégrées et automatisations non approuvées.
Étape 4. Politique et gouvernance
La politique doit être précise : principes, usages interdits, critères d'approbation, responsabilités et engagement d'amélioration. Déclarer une « IA éthique » ne suffit pas.
Une structure RACI indicative :
| Décision | Approuve | Exécute | Conseille |
|---|---|---|---|
| Intégrer un système | Direction/comité | Propriétaire | Juridique, sécurité et confidentialité |
| Accepter un risque | Niveau défini | Propriétaire | Équipe SMIA |
| Changer un modèle | Propriétaire autorisé | Équipe technique | Risque et sécurité |
| Gérer un incident | Responsable désigné | Exploitation | DPO/juridique/communication |
| Retirer un système | Direction/propriétaire | Exploitation | Parties concernées |
La PME peut s'appuyer sur un petit comité, mais doit éviter les décisions sans responsable identifié.
Étape 5. Risques et opportunités
La méthode couvre les préjudices et les opportunités pour l'organisation, les personnes et la société. Elle doit envisager :
- résultats incorrects ;
- discrimination et accessibilité ;
- manque de transparence ;
- confidentialité et propriété intellectuelle ;
- sécurité et usage malveillant ;
- dépendance et continuité d'activité ;
- impact social et humain ;
- coûts et consommation de ressources ;
- bénéfice attendu et non réalisé.
Chaque risque a une cause, un événement, un impact, une probabilité, un contrôle, un responsable et un risque résiduel. Les seuils d'acceptation sont approuvés avant l'évaluation.
Étape 6. Évaluation d'impact
L'évaluation d'impact analyse les effets du système et ses usages prévisibles sur les individus, les groupes et la société. Elle se coordonne avec l'AIPD du RGPD, l'analyse d'impact sur les droits fondamentaux de l'AI Act, la sécurité ou la durabilité pour éviter les doublons.
Elle doit inclure les personnes indirectement concernées, les usages non prévus mais raisonnablement prévisibles, les défaillances, les bénéfices, la répartition des impacts et les canaux de réclamation.
L'ISO/IEC 42005 apporte des lignes directrices spécifiques et peut s'intégrer au SMIA.
Étape 7. Cycle de vie
Le système doit encadrer :
- conception et exigences ;
- acquisition ou conception technique ;
- données et développement ;
- validation ;
- déploiement ;
- surveillance ;
- changements ;
- retrait.
Chaque jalon a ses critères. Par exemple, ne pas passer en production sans tests, sans propriétaire désigné, sans documentation, sans supervision, sans procédure d'incident et sans plan de retour arrière.
Données et qualité
La gouvernance des données couvre la provenance, la licéité, la qualité, la représentativité, l'étiquetage, l'accès, la conservation et les limites. Pour un système RAG, cela inclut les documents et les index ; pour les modèles tiers, les entrées, les sorties et la télémétrie.
La PME doit documenter ce qu'elle ignore. L'absence d'information de la part d'un fournisseur constitue en soi un risque pouvant justifier des restrictions.
Fournisseurs
La diligence raisonnable examine :
- documentation et finalité prévue ;
- sécurité, confidentialité et sites ;
- usage des données pour l'entraînement ;
- sous-traitants ;
- indicateurs et limites ;
- changements de version ;
- incidents ;
- export et réversibilité.
Le contrat doit répartir les responsabilités et les obligations de notification. La responsabilité ne peut pas être externalisée.
Objectifs et indicateurs
Les objectifs doivent mesurer des résultats, pas seulement des activités. Exemples :
- 100 % des systèmes inventoriés et dotés d'un propriétaire ;
- zéro action critique menée sans autorisation ;
- réduction des réponses sans source ;
- délai maximal de révocation des accès ;
- pourcentage de changements ayant provoqué une régression ;
- incidents clôturés dans les délais du SLA.
Chaque indicateur nécessite une définition, une source, une fréquence, un seuil et une action associée.
Compétence et culture de l'IA
La formation varie selon le rôle. La direction a besoin de comprendre le risque et la responsabilité ; le développement, l'évaluation et la sécurité ; les utilisateurs, les limites et la vérification ; les achats, la diligence raisonnable ; le DPO et le juridique, l'impact et les droits.
La preuve doit démontrer la compétence, pas seulement la participation : exercices, tests, observation ou revue de décisions.
Documentation minimale viable
Une PME peut tenir à jour :
- périmètre et contexte ;
- politique et objectifs ;
- inventaire ;
- méthodologie de risque et d'impact ;
- procédures d'approbation, de changement et d'incident ;
- évaluation des fournisseurs ;
- indicateurs et enregistrements ;
- audit interne ;
- revue de direction ;
- actions correctives.
Aucun document n'est dupliqué lorsque des contrôles existent déjà dans l'ISO 9001 ou l'ISO 27001 : ils sont référencés et intégrés.
Audit interne
L'audit doit vérifier des preuves réelles :
- Existe-t-il des systèmes hors inventaire ?
- La classification correspond-elle à l'usage réel ?
- Les contrôles réduisent-ils le risque ?
- Les changements sont-ils testés ?
- La supervision peut-elle réellement arrêter le système ?
- Les incidents génèrent-ils des enseignements ?
- La direction prend-elle des décisions fondées sur les résultats ?
L'auditeur doit être objectif et ne pas auditer son propre travail.
Revue de direction
La direction passe en revue le contexte, les objectifs, les audits, les incidents, la performance, les changements, les ressources et les opportunités. Les conclusions doivent contenir des décisions : priorités, acceptation du risque, ressources et changements.
Certification
La certification comprend généralement une étape 1 — préparation documentaire et du périmètre — et une étape 2 — mise en œuvre et efficacité —, suivies d'une surveillance. L'organisme certificateur doit être compétent et opérer dans le cadre du schéma d'accréditation applicable.
La certification n'est annoncée qu'une fois obtenue, et jamais étendue à des produits hors périmètre.
Plan à 120 jours
Jours 1 à 30
Périmètre, contexte et inventaire. Politique, rôles et méthodologie. Analyse des écarts par rapport aux exigences.
Jours 31 à 60
Risques et impacts prioritaires. Fournisseurs et cycle de vie. Contrôles et indicateurs.
Jours 61 à 90
Mise en œuvre, formation et enregistrements. Tests et incidents. Suivi des objectifs.
Jours 91 à 120
Audit interne. Actions correctives. Revue de direction. Préparation à la certification.
Le délai dépend du périmètre et de la maturité de l'organisation ; ce n'est pas une garantie.
Erreurs fréquentes
- Certifier un périmètre qui ne représente pas l'activité réelle.
- N'inventorier que les modèles propriétaires.
- Copier une politique générique.
- Séparer la conformité et l'équipe technique.
- Mesurer des activités plutôt que des résultats.
- Ne pas contrôler les changements des fournisseurs.
- Dupliquer l'ISO 27001 et l'ISO 9001.
- Réaliser l'évaluation d'impact en toute fin de projet.
- Auditer sans preuves suffisantes.
- Considérer le certificat comme la fin du processus.
Liste de contrôle
- Périmètre vérifiable.
- Inventaire complet avec propriétaires.
- Politique, rôles et escalade.
- Risque et impact par système.
- Cycle de vie et jalons de contrôle.
- Données et fournisseurs gouvernés.
- Indicateurs avec seuils.
- Compétence par rôle.
- Incidents, changements et retrait testés.
- Audit interne et revue de direction.
Questions fréquentes
L'ISO 42001 est-elle obligatoire ?
C'est une norme volontaire, sauf exigence contractuelle ou sectorielle. Elle ne remplace pas les obligations légales.
Ne concerne-t-elle que les développeurs ?
Non. La norme précise qu'elle s'applique aux organisations qui développent, fournissent ou utilisent l'IA.
Certifie-t-elle un produit ?
Elle certifie le système de management dans un périmètre défini, pas le fait que tous les résultats du produit soient corrects.
Peut-elle s'intégrer à l'ISO 27001 ?
Oui. Elles partagent une structure et des contrôles de gouvernance, de risque, d'audit et d'amélioration, même si leur objet diffère.
Summum Calidad peut accompagner la définition du périmètre, la mise en œuvre, l'audit interne et la préparation à la certification ISO/IEC 42001, coordonnée si nécessaire avec l'évaluation d'impact de l'IA (ISO/IEC 42005), sans jamais se substituer à l'organisme certificateur.