L'analyse d'écart (gap analysis)

Ce qu'est une analyse d'écart

L'analyse d'écart, ou gap analysis, est une revue systématique de l'état actuel de votre gestion de l'IA, comparée aux exigences de l'ISO/IEC 42001. Elle repère les endroits où vos pratiques ne satisfont pas encore les critères de la norme, ces écarts qui séparent votre dispositif de la conformité.^[2] Le mot écart est à prendre au sens propre : on mesure une distance, point par point, entre ce qui existe chez vous et ce que la norme demande.

Le but n'est pas de prononcer un verdict, mais de produire une feuille de route. À l'issue de l'exercice, vous savez où vous en êtes, ce qui manque, et dans quel ordre traiter les manques.^[2] C'est un point de départ pour juger de la maturité de votre gouvernance de l'IA, avant tout engagement plus lourd.^[3]

Cette opération suppose un repère stable : on ne mesure un écart que par rapport à une référence. Cette référence, c'est le texte de la norme et son Annexe A, deux corps d'exigences distincts qu'il faut bien comprendre avant de se lancer.

Le référentiel : clauses et Annexe A

L'analyse d'écart compare vos pratiques à un double référentiel. D'un côté, les exigences des clauses 4 à 10 de la norme, celles qui décrivent le système de management lui-même : contexte, leadership, planification, support, fonctionnement, évaluation des performances, amélioration.^[3] De l'autre, les contrôles de référence regroupés dans l'Annexe A.

L'Annexe A est un jeu de contrôles que l'organisation utilise comme repère pour atteindre ses objectifs et traiter les risques liés à la conception et à l'exploitation des systèmes d'IA. La norme précise que tous ces contrôles ne sont pas obligatoires : l'organisation peut concevoir et adopter ses propres contrôles, en cohérence avec son traitement des risques.^[1] L'Annexe A n'est donc pas une liste de cases à cocher, mais un point de comparaison à partir duquel justifier ses choix.

Cette annexe couvre un large périmètre de sujets. Comprendre ce qu'elle recouvre aide à savoir où chercher des écarts.

Les familles de contrôles de l'Annexe A, repères de l'analyse d'écart

A.2	Politiques liées à l'IA
A.3	Organisation interne (rôles, signalement des préoccupations)
A.4	Ressources des systèmes d'IA (données, outils, calcul, humaines)
A.5	Évaluation des impacts des systèmes d'IA
A.6	Cycle de vie du système d'IA
A.7	Données pour les systèmes d'IA
A.8	Information des parties intéressées
A.9	Usage des systèmes d'IA
A.10	Relations avec les tiers et les clients

Pour chaque famille, l'analyse d'écart pose la même question : disposez-vous déjà d'une pratique qui répond à l'objectif du contrôle, et si oui, est-elle documentée ? La réponse révèle l'écart, des plus profonds, là où rien n'existe, aux plus faibles, là où la pratique existe mais reste informelle.^[4]

Sa place dans le parcours : tout en amont

L'analyse d'écart intervient au tout début, avant même la décision de se certifier. Elle sert à mesurer la distance à parcourir, donc à juger si l'objectif de certification est réaliste à court ou à moyen terme, et à quel coût d'effort.^[3] Repousser ce diagnostic ne fait pas disparaître les écarts, il les laisse seulement se découvrir plus tard, au pire moment.^[3]

Elle éclaire une décision, plutôt qu'elle ne la suppose déjà prise. Une organisation peut très bien mener une analyse d'écart, constater que sa gouvernance de l'IA est encore jeune, et choisir de renforcer ses pratiques pendant un an avant de viser le certificat. Le diagnostic garde sa valeur même sans certification au bout, car il structure une démarche de progrès.

Une fois la décision prise, l'analyse d'écart se prolonge naturellement dans la préparation : elle alimente le plan de traitement des risques, la rédaction de la documentation, puis la préparation à l'audit. Elle est la première marche des étapes de la certification, pas une étape à part.

Comment la mener, étape par étape

La norme ne fournit pas de méthode imposée pour l'analyse d'écart, qui reste un exercice volontaire et préparatoire. Les organismes qui la pratiquent convergent toutefois vers une marche à suivre cohérente, fondée sur le risque, qui traite d'abord les usages d'IA les plus sensibles et les écarts les plus graves.^[3]

Une analyse d'écart enchaîne ces cinq temps. Chacun prépare le suivant, du cadrage initial jusqu'au plan qui guidera la mise en conformité.

1Cadrer le périmètre et le rôle (quels systèmes d'IA, fournisseur, déployeur, utilisateur)

2Recenser tous les usages d'IA, y compris ceux intégrés à des outils

3Documenter l'existant par entretiens, enquêtes et revue des politiques

4Comparer aux clauses et aux contrôles de l'Annexe A via une liste de contrôle

5Prioriser les écarts par le risque, puis bâtir le plan d'action

Marche à suivre reformulée à partir de pratiques d'organismes de conseil. Schéma indicatif.

Le premier temps consiste à cadrer le périmètre, c'est-à-dire les systèmes d'IA, les processus et les départements qui entrent dans l'évaluation, et à déterminer le rôle de l'organisation, fournisseur, déployeur ou utilisateur. Ce rôle commande quels contrôles s'appliquent réellement et comment structurer le dispositif.^[3] Ce cadrage rejoint la logique de la clause 4 de la norme, qui demande de déterminer son rôle et son périmètre avant toute chose.

Vient ensuite le recensement de tous les usages d'IA, y compris ceux qui sont intégrés à des outils du quotidien sans qu'on en ait toujours conscience.^[3] On documente alors les pratiques en place par des entretiens, des enquêtes internes et une revue des politiques existantes, en évaluant la maturité sur plusieurs domaines, de la stratégie aux données, de la gouvernance à l'ingénierie et au modèle opérationnel.^[3]

Le cœur de l'exercice est la comparaison : on confronte chaque pratique aux exigences des clauses et aux contrôles de l'Annexe A, à l'aide d'une grille ou d'une liste de contrôle structurée et alignée sur la norme.^[4] Cette comparaison gagne à mobiliser une équipe transverse, qui réunit l'informatique, la conformité, la science des données, la gestion des risques et le juridique, avec l'appui de la direction pour les questions de politique et des métiers pour les contrôles de cycle de vie.^[3]

Le dernier temps transforme le constat en feuille de route. On classe les écarts par le risque et l'impact, à l'aide d'une matrice qui croise probabilité et conséquence, pour traiter en premier ce qui pèse le plus lourd.^[3] Chaque écart reçoit un responsable, une échéance et des jalons, ce qui donne un plan d'action exploitable plutôt qu'une simple liste de manques.^[2]

Ce qu'elle produit : les livrables

Une analyse d'écart bien menée laisse une trace écrite, utile bien au-delà du diagnostic lui-même. Le premier livrable est un état des lieux : la liste des usages d'IA, le rôle de l'organisation et le périmètre retenu.^[3] Ce document sert ensuite à cadrer le système de management tout entier.

Le deuxième livrable est la cartographie des écarts elle-même : pour chaque exigence de clause et chaque contrôle de l'Annexe A, l'état constaté et la distance qui reste à parcourir.^[3] Le troisième est la priorisation, qui hiérarchise ces écarts selon le risque qu'ils font porter.^[4]

Le livrable final est le plan d'action, ou feuille de route, avec ses responsables, ses jalons et ses décisions d'allocation de ressources.^[2][3] Ce plan devient le fil conducteur de la mise en conformité. Il nourrit le plan de traitement des risques, la production de la documentation, puis la préparation à l'audit, sans s'y substituer.^[4]

Ne pas la confondre avec l'audit interne ni l'audit de certification

L'analyse d'écart est souvent prise pour un audit, ce qu'elle n'est pas. La norme prévoit trois examens de nature différente, qu'il faut tenir distincts pour bien situer chacun.

L'analyse d'écart est un diagnostic préparatoire, généralement informel, mené avant que le système ne soit en place. Elle n'est pas exigée par la norme : c'est un outil de préparation, libre dans sa forme.

L'audit interne de la clause 9.2 est tout autre chose. C'est un mécanisme exigé par la norme, mené à intervalles planifiés une fois le système opérationnel, pour vérifier qu'il est conforme aux exigences propres de l'organisation et à celles de la norme, et qu'il est effectivement déployé et maintenu.^[5] Il suppose un programme d'audit défini, des objectifs, des critères et un périmètre pour chaque audit, des auditeurs choisis pour garantir l'objectivité et l'impartialité du processus, et des résultats rapportés aux responsables concernés.^[5] Là où l'analyse d'écart prépare, l'audit interne contrôle un système déjà vivant.

L'audit de certification, enfin, est conduit par un organisme tiers accrédité, pas par l'organisation elle-même. L'analyse d'écart se place en amont de cet audit, justement pour réduire le risque de non-conformités majeures lors de l'examen formel.^[3][4] Une lecture simple aide à retenir la distinction : l'analyse d'écart mesure la distance, l'audit interne surveille le système une fois construit, l'audit de certification valide cette construction de l'extérieur.

Interne ou externe

L'analyse d'écart peut être menée par l'organisation elle-même ou confiée à un tiers. En interne, une équipe transverse s'auto-évalue à l'aide de listes de contrôle alignées sur la norme.^[4] Cette option a l'avantage du coût et de la connaissance fine du terrain, au prix d'un angle mort possible : on voit mal ses propres lacunes.

Un regard externe, celui d'un consultant ou d'un organisme spécialisé, apporte l'habitude des contrôles et une lecture détachée des routines internes.^[3] Beaucoup d'organisations combinent les deux : une auto-évaluation pour défricher, puis un avis tiers pour valider et challenger les conclusions avant d'engager un organisme de certification.^[4]

Une chose ne change pas selon le mode retenu : quelle que soit la qualité de l'analyse d'écart, elle ne vaut pas certification. Seul un organisme tiers accrédité délivre le certificat ISO 42001. L'analyse d'écart prépare ce moment, elle ne le remplace pas.

Un cas concret : une PME romande

Prenons, à titre d'illustration, une entreprise de services de quarante personnes basée dans l'arc lémanique, qui utilise plusieurs outils d'IA : un assistant de rédaction, un moteur de recommandation sur son site, un classifieur de documents. Elle envisage la certification, sans savoir si elle est mûre pour s'y engager. Elle commence par une analyse d'écart.

Le cadrage révèle d'abord un usage d'IA oublié, intégré à un logiciel métier, que personne n'avait recensé comme tel.^[3] La comparaison aux contrôles de l'Annexe A met en lumière des écarts nets : aucune politique d'IA écrite (A.2), des rôles non formalisés (A.3), aucune trace documentée de la provenance des données utilisées (A.7).^[1] À l'inverse, l'entreprise dispose déjà de bonnes pratiques de sécurité héritées d'une démarche antérieure, qui réduisent l'écart sur plusieurs points.

La priorisation par le risque place la politique d'IA et la traçabilité des données en tête, devant des sujets moins pressants.^[4] L'entreprise sort de l'exercice avec une feuille de route claire, un ordre de marche, et une décision éclairée : viser le certificat dans l'année, en commençant par les écarts les plus lourds. Sans ce diagnostic, elle aurait découvert ces manques bien plus tard, au contact d'un auditeur.

Questions fréquentes

À lire ensuite