Atelier : AIMS pragmatique

Pourquoi un atelier plutôt qu'une lecture de norme

La norme ISO/IEC 42001 décrit ce qu'un système de management de l'IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire (AIMS) doit contenir : contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire, leadership, planification, support, fonctionnement, évaluation des performances, amélioration. Elle ne dit pas dans quel ordre agir, ni combien de temps consacrer à chaque brique quand on part de zéro. Ce chapitre comble ce vide avec une feuille de route concrète, calibrée pour une organisation moyenne — disons entre 150 et 1 500 salariés, avec un ou plusieurs cas d'usage d'IA en production ou en projet, et une fonction qualité ou conformité déjà existante mais pas nécessairement de département IA dédié.

L'objectif à 90 jours n'est pas la certification. C'est un AIMS fonctionnel : périmètre défini, risques identifiés et traités, contrôles de l'annexe A sélectionnés et justifiés, premiers indicateurs suivis, et une revue de direction tenue au moins une fois. La certification, si elle est visée, vient ensuite — après plusieurs cycles PDCA et un audit interne plus complet.

Un AIMS construit en 90 jours n'est pas mature à 90 jours. Il est amorcé. La maturité vient des cycles suivants — c'est le principe même de l'amélioration continue de l'ISO/IEC 42001. Présenter un AIMS de 90 jours comme achevé à un auditeur ou à un client est le meilleur moyen de perdre en crédibilité.

Semaine 0 — cadrage et engagement de la direction

Avant le jour 1, trois décisions doivent être prises par la direction, pas déléguées à l'équipe projet :

• Le périmètre — quels systèmes d'IA, quelles entités, quels sites sont couverts. Un périmètre flou à ce stade se paie cher au jour 40, quand il faut arbitrer si un outil RH basé sur un modèle tiers entre ou non dans l'AIMS.
• Le sponsor — une personne identifiée, avec autorité budgétaire et capacité à trancher entre directions métier. Sans sponsor, l'atelier devient une initiative de la qualité que personne d'autre ne prend au sérieux.
• Le budget de temps — un AIMS demande du temps humain avant tout : ateliers, entretiens, rédaction. Compter a minima 0,3 à 0,5 ETP pendant les 90 jours pour le pilote du projet, plus des contributions ponctuelles des métiers concernés.

Le piège le plus fréquent en semaine 0 est un périmètre trop large par précaution — « autant tout couvrir tout de suite ». Résultat : l'appréciation des risques explose en volume, les métiers se désengagent faute de voir un livrable avant le jour 60, et le projet s'essouffle. Un périmètre restreint mais réellement piloté vaut mieux qu'un périmètre exhaustif mais nominal.

La semaine 0 se conclut par une réunion de lancement courte, une heure suffit, avec un ordre du jour fixe : validation du périmètre, présentation du sponsor aux propriétaires de systèmes concernés, calendrier des trois phases, et rappelrappelIAProportion des cas positifs réels effectivement détectés par un modèle. Sur un jeu déséquilibré, c'est un indicateur bien plus parlant que l'exactitude globale.Voir dans le glossaire que l'objectif du jour 90 est un AIMS amorcé, pas un système achevé.

Jours 1 à 30 — fondations : contexte, parties intéressées, politique

Le premier mois construit les clauses 4 à 6 de la norme : compréhension de l'organisation et de son contexte, besoins et attentes des parties intéressées, détermination du périmètre documenté, politique IA, et planification initiale.

Concrètement, trois livrables :

1. Cartographie du contexte — facteurs internes (structure, gouvernance existante, dette technique) et externes (réglementation applicable, dont l'AI ActAI ActConformitéRèglement européen sur l'intelligence artificielle, adopté en 2024. Il classe les systèmes en quatre niveaux de risque selon leur usage — jamais selon leur technologie.Voir dans le glossaire si l'organisation opère en UE, attentes clients, position concurrentielle). Un tableau à deux colonnes suffit, pas besoin d'un document de quarante pages.
2. Registre des parties intéressées — clients, utilisateurs finaux, régulateurs, employés, fournisseurs de modèles, partenaires. Pour chacune, ses attentes vis-à-vis de l'IA et ce qu'elle peut exiger formellement.
3. Politique IA signée par la direction — un document court, deux à trois pages, qui engage l'organisation sur des principes (traçabilité, supervision humaine, gestion des risques, conformité réglementaire) sans entrer dans le détail opérationnel, qui viendra plus tard.

Si l'organisation est déjà certifiée ISO 27001 ou ISO 9001, ne repartez pas de zéro. L'ISO/IEC 42001 partage la structure de haut niveau (Annexe SL) avec les autres normes de système de management. Le registre des parties intéressées, la revue de direction, la gestion documentaire et le programme d'audit interne existants peuvent souvent être étendus plutôt que dupliqués — cela fait gagner deux à trois semaines sur la feuille de route.

À la fin du mois 1, l'inventaire des systèmes d'IA dans le périmètre doit être stabilisé : nom du système, finalité, donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire traitées, niveau d'autonomie, criticité métier, statut (production, pilote, projet). Cet inventaire est le pivot de tout ce qui suit — sans lui, l'appréciation des risques du mois 2 n'a rien à évaluer.

Jours 31 à 60 — appréciation des risques et déclaration d'applicabilité

Le deuxième mois est le plus dense. Il couvre la clause 6.1, l'appréciation et le traitement des risques liés à l'IA, et produit la déclaration d'applicabilité (Statement of Applicability, SOA) qui justifie, pour chacun des contrôles de l'Annexe A, s'il est retenu ou exclu, et pourquoi.

La SOA n'est pas une liste de contrôles cochés. C'est un document de justification. Pour chaque contrôle exclu, l'auditeur attend une raison de fond — absence du risque correspondant dans le périmètre, contrôle couvert autrement, ou non-applicabilité technique — pas une case laissée vide.

La méthode la plus praticable pour une organisation moyenne repose sur un atelier par système d'IA critique, réunissant le propriétaire métier, un représentant technique et la fonction risques ou conformité. Pour chaque système, on caractérise :

• les risques liés aux données (biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire d'entraînement, qualité, dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire dans le temps),
• les risques liés au modèle (hallucinationhallucinationIAProduction par un modèle d'un énoncé faux formulé avec la même assurance qu'un fait établi. Le phénomène est structurel : le modèle optimise la vraisemblance, pas la vérité.Voir dans le glossaire, sur-confiance, opacité des décisions),
• les risques liés à l'usage (dépendance excessive, contournement des contrôles humains),
• les risques liés à l'écosystème (dépendance à un fournisseur, changement de version d'un modèle tiers non maîtrisé par l'organisation).

Chaque risque est coté en gravité et probabilité, puis traité par un ou plusieurs contrôles de l'Annexe A. C'est cette matrice risques-contrôles qui alimente directement la SOA.

Une PME d'édition logicielle qui utilise un modèle tiers pour générer des résumés de tickets support identifie comme risque principal la fuite de donnéesfuite de donnéesIAErreur consistant à laisser entrer dans l'entraînement une information qui n'existera pas au moment réel de la prédiction. Le modèle affiche des scores excellents puis s'effondre en production.Voir dans le glossaire client dans les invites envoyées au fournisseur. Le traitement retenu combine trois contrôles : anonymisation des champs sensibles avant envoi, clause contractuelle interdisant l'entraînement du fournisseur sur les données transmises, et journalisation des requêtes pour audit a posteriori. Ces trois contrôles, une fois documentés, alimentent directement les lignes correspondantes de la SOA.

Tableau récapitulatif des jalons de ce mois, utile pour le suivi de projet :

Jours 61 à 90 — opérationnaliser et préparer la revue de direction

Le troisième mois transforme les décisions en pratique courante. Il ne s'agit plus de produire des documents, mais de vérifier que les contrôles sélectionnés fonctionnent réellement.

Trois chantiers en parallèle :

• Procédures opérationnelles — pour chaque contrôle retenu dans la SOA, une procédure courte décrivant qui fait quoi, avec quelle fréquence, et quelle preuve est conservée. Une procédure sans preuve associée ne survit pas à un audit.
• Indicateurs de performance — un tableau de bord minimal : nombre d'incidents IA déclarés, taux de revue humaine sur les décisions à fort impact, délai de traitement des signalements. Cinq à huit indicateurs suffisent à ce stade ; en ajouter davantage dilue l'attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire plutôt que de l'enrichir.
• Audit interne à blanc — un exercice court, sur un échantillon de deux ou trois contrôles, mené par une personne qui n'a pas participé à leur mise en œuvre. L'objectif n'est pas de sanctionner mais de repérer les écarts entre ce que dit la procédure et ce qui se passe réellement.

Le jour 90 se conclut par la première revue de direction formelle : présentation du périmètre, des risques traités, de la SOA, des indicateurs, des écarts identifiés en audit interne, et des décisions à prendre pour le cycle suivant (ressources supplémentaires, extension du périmètre, arbitrages sur des risques résiduels). Cette réunion doit produire un compte-rendu daté et des actions assignées — c'est la preuve la plus directement recherchée par un auditeur externe que le système fonctionne en boucle fermée.

Une revue de direction qui se limite à une présentation descendante sans décision actée n'a pas de valeur au regard de la norme. La clause 9.3 attend des éléments de sortie explicites : décisions, actions, ressources allouées. Un compte-rendu qui ne contient que des constats est un signal d'alerte classique en audit.

Qui porte quoi : répartition des rôles

La réussite de l'atelier dépend moins de la méthode que de la clarté des rôles. Une répartition qui fonctionne bien dans une organisation moyenne :

• Sponsor (direction) — arbitre les périmètres et les risques résiduels acceptés, débloque les ressources, préside la revue de direction.
• Pilote AIMS — anime l'atelier au quotidien, rédige les livrables, coordonne les contributeurs métier. Profil qualité, conformité ou gouvernance des données selon l'organisation.
• Propriétaires de systèmes d'IA — un par système dans le périmètre, responsables de la description technique, de la participation aux ateliers de risques et de la mise en œuvre des contrôles qui les concernent.
• Fonction risques ou juridique — valide la cohérence entre l'appréciation des risques IA et les cadres de risque existants de l'organisation, notamment si un dispositif de gestion des risques d'entreprise est déjà en place.
• Auditeur interne — personne indépendante des équipes opérationnelles, mobilisée en fin de parcours pour l'audit à blanc.

Pièges fréquents à 90 jours

• Documenter avant de pratiquer — rédiger une procédure détaillée pour un contrôle qui n'a jamais été testé en conditions réelles produit un document qui ne correspond à rien.
• Confondre inventaire des systèmes d'IA et inventaire des projets IT — un système d'IA au sens de la norme est défini par sa fonction (apprentissage, inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire, génération), pas par son étiquetteétiquetageIATravail consistant à associer à chaque exemple la réponse attendue. C'est presque toujours le poste le plus coûteux d'un projet d'apprentissage supervisé.Voir dans le glossaire marketing. Un simple moteur de règles ne relève pas de l'AIMS ; un modèle de scoring, même simple, en relève.
• Sous-traiter la gouvernance au prestataire technique — la responsabilité de l'AIMS reste organisationnelle. Un intégrateur peut aider à documenter, il ne peut pas porter les arbitrages de risque à la place de la direction.
• Vouloir tout couvrir en 90 jours — un AIMS qui commence par les systèmes critiques et laisse volontairement des systèmes secondaires hors périmètre initial, documenté comme tel, est plus défendable qu'un périmètre exhaustif traité superficiellement.

Après le jour 90

Le jour 90 n'est pas une ligne d'arrivée. Le cycle PDCA continue : un deuxième trimestre affine les procédures testées en audit interne, élargit progressivement le périmètre, et prépare, si l'organisation le souhaite, un audit de certification par un organisme accrédité — généralement six à douze mois après le lancement de l'atelier, le temps d'accumuler suffisamment de preuves de fonctionnement réel du système.