Politiques et rôles

Pourquoi la gouvernance ne se décrète pas

Une politique 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 affichée sur un intranet et jamais révisée n'a aucune valeur probante lors d'un audit. ISO/IEC 42001 ne demande pas un texte bien écrit : elle demande une chaîne de décision traçable, où chaque exigence de la politique a un porteur identifiable et où ce porteur peut démontrer qu'il a exercé son rôle. C'est la différence entre une politique et une intention.

Ce chapitre traite de la clause 5 de la norme (Leadership) et de son prolongement opérationnel : comment la direction générale engage l'organisation, comment ce engagement se décline en rôles concrets, et comment on documente cette chaîne pour qu'elle résiste à un audit de certification.

Un système de management IA sans accountability nommée n'est pas un système de management, c'est une déclaration d'intention. L'auditeur ne cherche pas la politique la mieux écrite : il cherche la personne qui peut répondre, sans hésiter, à la question « qui a validé la mise en production de ce modèle, et sur quelle base ? ».

Le contenu attendu d'une politique IA

Une politique IA conforme n'est pas un manifeste éthique générique. Elle doit être suffisamment précise pour orienter des décisions réelles, tout en restant assez stable pour ne pas être réécrite à chaque nouveau projet. Les éléments attendus :

• Le périmètre — quels systèmes sont couverts (modèles internes, IA générative tierce, automatisations de décision, systèmes embarqués dans des produits) et quels usages sont explicitement exclus ou soumis à un régime différent.
• Les principes directeurs — équité, transparence, sécurité, respect des droits des personnes concernées, traçabilité des décisions automatisées. Ces principes doivent être reliés à des mécanismes concrets, pas listés comme des valeurs abstraites.
• Les niveaux de risque et leurs conséquences — un classement (par exemple faible / modéré / élevé) qui détermine le niveau de validation requis avant déploiement.
• Les rôles et autorités — qui peut approuver quoi, à quel niveau de risque, avec quel droit de veto.
• Les modalités de revue — fréquence de mise à jour, déclencheurs de révision anticipée (incident, nouvelle réglementation, changement de fournisseur).
• L'articulation avec les autres politiques — sécurité de l'information, protection des 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, conformité réglementaire sectorielle. La politique IA ne doit pas être un silo.

Une politique IA copiée d'un modèle générique, sans adaptation aux systèmes réellement utilisés dans l'organisation, se retourne contre elle lors de l'audit. Si la politique mentionne des contrôles que personne n'applique, ou omet des usages réels (un copilote de code, un chatbot support client, un système de scoring RH), l'écart est immédiatement visible et compte comme non-conformité.

Cartographier les rôles : qui porte quoi

La gouvernance IA repose sur un petit nombre de rôles récurrents, que l'organisation soit une PME ou un grand groupe. Leur nom peut varier, mais leurs responsabilités doivent être couvertes sans trou ni chevauchement flou.

La tentation la plus fréquente est de confier tous ces rôles à une seule personne, souvent le responsable informatique ou le DPO, parce que « c'est la personne la plus compétente sur le sujet ». Cette concentration crée un point de défaillance unique et, plus grave pour l'audit, une confusion entre celui qui exécute et celui qui rend compte du résultat — exactement la distinction que la norme veut voir séparée.

Ne cherchez pas à créer des postes dédiés si l'organisation est petite. Un même individu peut cumuler plusieurs rôles RACI, à condition que la matrice le documente explicitement et que les rôles d'Accountable et de Responsible restent distincts sur les décisions à enjeu (déploiement, arrêt d'un système, gestion d'incident).

Ces rôles ne fonctionnent pas en silo : leur valeur tient à la façon dont ils interagissent au quotidien. L'owner du système IA doit pouvoir solliciter le data steward à chaque évolution significative du jeu de données d'entraînement, et le risk owner doit être associé suffisamment tôt dans le cycle de vie pour que son avis pèse réellement sur la conception, pas seulement sur la validation finale. Un risk owner consulté après que le budget est engagé et le calendrier verrouillé ne peut plus exercer d'influence utile — il devient un simple validateur de façade. La cartographie des rôles doit donc préciser non seulement qui fait quoi, mais à quel moment du cycle de vie chaque rôle intervient, faute de quoi les bonnes intentions de la politique IA restent lettre morte dans l'exécution réelle des projets.

La matrice RACI appliquée à l'IA

La matrice RACI (Responsible, Accountable, Consulted, Informed) est l'outil le plus efficace pour transformerTransformerIAArchitecture introduite en 2017, fondée sur le mécanisme d'attention, qui traite une séquence entière en parallèle. Elle sert de base à tous les grands modèles de langage actuels.Voir dans le glossaire une liste de rôles en engagements vérifiables. Chaque activité du cycle de vie IA reçoit une ligne, chaque rôle une colonne, et l'intersection précise le type d'implication.

La règle la plus souvent violée en pratique : un seul Accountable par activité. Multiplier les Accountable revient à n'en avoir aucun, car en cas de problème chacun renvoie vers l'autre. À l'inverse, plusieurs personnes peuvent être Responsible sur la même ligne (par exemple, l'owner du système et le data steward exécutent conjointement une revue de données), tant que l'Accountable reste unique.

Exemple concret. Une entreprise de services financiers déploie un modèle de scoring pour l'octroi de crédit. La matrice RACI attribue : Accountable à l'owner métier du produit crédit (pas au data scientist qui l'a construit), Responsible au data scientist et au data steward pour la qualité du modèle et des données, Consulted au risk owner pour l'évaluation d'impact réglementaire, Informed au comité de direction via un reporting trimestriel. Lors d'un contrôle défavorable détecté sur une sous-population, c'est l'owner métier qui doit justifier la décision de suspendre ou non le modèle — pas le data scientist, qui n'a pas autorité pour arbitrer un compromis entre performance commerciale et risque de discrimination.

Le comité de gouvernance IA

Au-delà d'un certain nombre de systèmes IA en production, la gestion cas par cas par la direction générale devient intenable. Le comité de gouvernance IA sert d'organe intermédiaire : il instruit les dossiers, applique les critères de la politique IA de façon cohérente, et ne remonte à la direction que les décisions qui dépassent son mandat (risque élevéhaut risqueConformitéCatégorie de l'AI Act regroupant les usages soumis à conditions strictes : recrutement, crédit, éducation, infrastructures critiques. Elle impose documentation, examen des biais et contrôle humain effectif.Voir dans le glossaire, budget significatif, exposition réglementaire nouvelle).

Sa composition doit croiser des compétences que peu d'individus réunissent seuls :

• une compétence technique (data science, ingénierie, sécurité des systèmes IA) ;
• une compétence risque et conformité (protection des données, réglementation sectorielle, 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 le cas échéant) ;
• une compétence métier (celui qui subit les conséquences d'une erreur du système) ;
• un mandat de décision suffisant pour que ses avis ne soient pas systématiquement recontestés en dehors du comité.

La fréquence de réunion doit être adaptée au rythme réel de déploiement — mensuelle dans une organisation qui met en production plusieurs cas d'usage par trimestre, trimestrielle sinon, avec une capacité de convocation exceptionnelle en cas d'incident.

Un comité efficace fonctionne sur un ordre du jour structuré et récurrent : revue des nouveaux cas d'usage soumis depuis la dernière séance, suivi des actions correctives décidées précédemment, examen des incidents survenus sur les systèmes déjà en production, et veille sur les évolutions réglementaires susceptibles de modifier les niveaux de risque retenus. Chaque décision doit être actée par écrit, avec la justification qui l'accompagne, même lorsque la décision est un refus ou un report — un dossier ajourné sans motif documenté est aussi problématique en audit qu'une absence totale de dossier. Le comité gagne aussi à formaliser des critères de décision explicites (seuils de risque, exigences minimales de documentation) plutôt que de statuer au cas par cas selon l'intuition de ses membres, ce qui garantit une cohérence des arbitrages dans le temps, y compris lorsque la composition du comité change.

Le comité de gouvernance IA n'est pas un comité d'éthique consultatif sans pouvoir. S'il ne peut ni bloquer un déploiement ni exiger des mesures correctives, il ne remplit pas la fonction que la norme attend d'une structure de gouvernance : il devient une chambre d'enregistrement, ce qui sera relevé comme une faiblesse lors de l'audit.

Escalade et gestion des désaccords

Même avec une matrice RACI bien construite, des désaccords surviennent : un data steward peut juger un jeu de données insuffisamment documenté pour un usage donné, tandis que l'owner du système, sous pression de calendrier, souhaite avancer quand même. La gouvernance IA doit prévoir un mécanisme d'escalade explicite pour ces situations, plutôt que de laisser le rapport de force interne trancher au cas par cas.

Un mécanisme d'escalade efficace précise trois éléments : le déclencheur (à partir de quel type de désaccord l'escalade devient obligatoire), l'instance de recours (le comité de gouvernance IA en premier niveau, la direction générale si le comité lui-même est divisé), et le délai de traitement, pour éviter qu'un dossier bloqué au niveau opérationnel ne reste en suspens pendant des mois faute d'arbitrage.

Ce mécanisme protège autant l'organisation que les individus qui portent les rôles à risque. Un data steward ou un risk owner qui n'a d'autre option que de céder face à la pression d'un calendrier de mise en production, faute de voie de recours formelle, voit son rôle vidé de son sens : il devient Consulted de nom mais sans influence réelle sur la décision finale. Documenter les cas d'escalade effectivement traités constitue par ailleurs une preuve tangible, lors de l'audit, que les contre-pouvoirs prévus par la gouvernance fonctionnent en pratique et pas seulement sur le papier.

Accountability du top management

La clause 5.1 d'ISO/IEC 42001 impose à la direction de démontrer un leadership actif, pas seulement une signature en bas de la politique. Concrètement, cela se traduit par des éléments observables :

• la politique IA est revue et re-signée à échéance définie, pas laissée à sa version initiale pendant des années ;
• des ressources (budget, temps, compétences) sont allouées de façon traçable aux activités de gouvernance ;
• la direction reçoit et discute un reporting régulier sur les risques IA, avec des traces de cette discussion (comptes rendus, décisions actées) ;
• en cas d'incident significatif, la direction est informée dans un délai défini et peut démontrer qu'elle a exercé un contrôle, même si elle délègue l'exécution.

Cette exigence ne vise pas à alourdir l'agenda des dirigeants : elle vise à empêcher que la gouvernance IA devienne une responsabilité orpheline, portée uniquement par une équipe technique sans autorité réelle sur les arbitrages business.

Documentation et preuves d'audit

Un rôle non documenté n'existe pas pour l'auditeur. Les preuves attendues typiquement :

• une fiche de rôle par fonction clé, décrivant le mandat, le périmètre et les limites de décision ;
• la matrice RACI elle-même, versionnée et datée ;
• les comptes rendus du comité de gouvernance IA, avec les décisions et leurs justifications ;
• une trace des révisions de la politique IA (qui a proposé le changement, qui l'a validé, pourquoi) ;
• un registre des cas d'usage IA avec, pour chacun, l'identité de l'Accountable désigné.

Préparez ce registre avant l'audit, pas pendant. L'exercice de recensement révèle presque toujours des systèmes IA « informels » — un tableur avec des règles de scoring, un assistant conversationnel déployé par une équipe sans validation centrale — qui échappent à la politique en vigueur. Les détecter en amont évite une non-conformité majeure découverte en direct par l'auditeur.

La qualité de ces preuves se mesure moins à leur volume qu'à leur cohérence dans le temps. Un auditeur qui compare la version actuelle de la matrice RACI aux comptes rendus du comité des douze derniers mois doit pouvoir reconstituer une trajectoire cohérente : les rôles attribués correspondent aux décisions effectivement prises, les révisions de la politique suivent les incidents ou évolutions réglementaires qui les ont motivées, et aucun système significatif ne réapparaît dans le registre sans historique de validation antérieur. Un ensemble de preuves figé, mis à jour uniquement à l'approche de l'audit, se repère facilement à l'absence de traces intermédiaires — c'est souvent ce décalage, plus que l'absence pure et simple d'un document, qui déclenche une non-conformité mineure lors de la revue documentaire.

Checklist de mise en œuvre

1. La politique IA existe, est datée, versionnée et couvre les usages réels de l'organisation.
2. Chaque rôle clé (direction, comité, owner système, data steward, risk owner) est nommément attribué, pas seulement décrit en théorie.
3. Une matrice RACI existe pour les activités majeures : validation de politique, approbation de cas d'usage, gestion d'incident, retrait d'un système.
4. Chaque ligne de la matrice a un seul Accountable.
5. Le comité de gouvernance IA dispose d'un mandat de décision réel, pas seulement consultatif.
6. La direction générale peut produire des preuves concrètes de son engagement (reporting, décisions, allocation de ressources).
7. Un registre des systèmes IA en production existe et est tenu à jour.
8. Un mécanisme d'escalade formel existe pour les désaccords entre rôles, avec instance de recours et délai de traitement définis.
9. Les preuves de gouvernance (RACI, comptes rendus, registre) sont mises à jour en continu, pas seulement reconstituées avant l'audit.

Cette structure de gouvernance sert de socle aux chapitres suivants : elle détermine qui instruit l'évaluation d'impact, qui valide les mesures de traitement du risque, et qui porte la responsabilité si un contrôle échoue en production.