Gouvernance IA : Guide Complet d'Audit et de Conformité pour les ETI Françaises

Résumé exécutif. L'entrée en vigueur progressive de l'AI Act européen (2024-2028), combinée au renforcement des cadres sectoriels français (ACPR, ANSSI, CNIL, HAS, RGS), crée un environnement réglementaire sans précédent pour les entreprises déployant l'intelligence artificielle. Ce guide propose une analyse approfondie des obligations en vigueur et à venir, une méthodologie d'audit structurée, et des templates opérationnels prêts à l'emploi pour les DPO, RSSI, comités de direction et équipes techniques. La gouvernance IA ne se substitue pas aux dispositifs de conformité existants : elle s'y intègre, en agrégeant les exigences du RGPD, de l'AI Act, des référentiels sectoriels et des standards internationaux comme l'ISO/IEC 42001.

Chapitre 1. Le Cadre Réglementaire Européen : AI Act

1.1 Genèse et structure du règlement

Le règlement européen sur l'intelligence artificielle, dit AI Act, est entré en vigueur le 1er août 2024 . Il constitue le premier cadre réglementaire au monde visant à protéger les citoyens des risques liés à l'IA tout en favorisant un marché unique européen de l'IA de confiance . Sa logique fondamentale repose sur une classification des systèmes d'IA selon leur niveau de risque potentiel pour la sécurité, la santé et les droits fondamentaux des personnes . Cette approche proportionnée implique que les obligations réglementaires varient en intensité selon la dangerosité perçue du système : les pratiques à risque inacceptable sont purement et simplement interdites, tandis que les systèmes à haut risque font l'objet d'un encadrement strict portant sur la documentation, la traçabilité et la supervision humaine .

La structure du texte s'articule autour de quatre catégories de risque, inacceptable, élevé, limité et minimal, auxquelles s'ajoutent des obligations spécifiques pour les modèles d'IA à usage général (GPAI) tels que les grands modèles de langage (LLM). Cette architecture hiérarchisée permet de cibler les exigences là où elles sont le plus nécessaires, sans imposer un fardeau disproportionné aux usages à faible impact. Pour les entreprises françaises, et particulièrement les ETI qui constituent le tissu économique principal du pays, la compréhension fine de cette classification est l'étape indispensable avant tout déploiement en production .

1.2 Classification des systèmes par niveau de risque

La classification du AI Act est le cœur du dispositif. Chaque entreprise doit être en mesure de placer ses systèmes d'IA dans l'une des quatre catégories suivantes, car c'est cette classification qui détermine l'ensemble des obligations applicables.

Le risque élevé constitue la catégorie la plus dense en obligations et celle qui concerne directement les ETI des secteurs régulés. L'Annexe III du règlement énumère les domaines concernés : biométrie, infrastructures critiques, éducation, emploi, accès à des services essentiels, law enforcement, migration et administration de la justice . Pour le secteur financier spécifiquement, deux catégories de systèmes sont explicitement classées à haut risque par l'article 6 §2 : les systèmes d'IA destinés à évaluer la solvabilité des personnes physiques ou à établir leur note de crédit, et ceux utilisés pour évaluer les risques et la tarification en assurance-vie et assurance-maladie .

1.3 Calendrier d'application actualisé (Digital Omnibus)

L'application du AI Act est progressive, mais le rythme s'est considérablement accéléré depuis fin 2024. Le Digital Omnibus, accord politique trouvé le 7 mai 2026 entre le Parlement européen, le Conseil de l'UE et la Commission européenne, a modifié plusieurs échéances clés . Ces ajustements visent à laisser le temps aux normes techniques harmonisées d'être finalisées avant l'application des obligations les plus lourdes.

La confirmation de ces reports par le Digital Omnibus offre un répit apparent aux entreprises, mais ne doit pas masquer l'urgence opérationnelle. Les systèmes à haut risque nécessitent une préparation de 12 à 18 mois pour atteindre la conformité complète . Les entreprises qui attendront le dernier moment risqueront de ne pas disposer des ressources techniques et organisationnelles nécessaires pour respecter les délais. Par ailleurs, certaines obligations antérieures restent inchangées : les pratiques interdites sont effectivement illégales depuis février 2025, et les sanctions financières sont applicables depuis août 2025 .

1.4 Obligations détaillées par niveau de risque

1.4.1 Systèmes à risque inacceptable (interdits)

Depuis le 2 février 2025, les pratiques suivantes sont strictement prohibées sur le territoire de l'Union européenne :

• La notation sociale des individus par les pouvoirs publics ou des systèmes de profilage évaluant les individus à partir de leurs comportements en ligne
• La manipulation cognitive ou comportementale subliminale, comme la production artificielle de contenus destinés à influencer ou tromper les individus à leur insu
• L'exploitation des vulnérabilités des personnes (âge, handicap, situation sociale ou économique) pour modifier leur comportement de manière préjudiciable
• Les systèmes de surveillance biométrique en temps réel dans les espaces publics, sauf exceptions très strictement encadrées (recherche de victimes d'enlèvement, prévention d'actes terroristes)
• La reconnaissance des émotions dans des contextes professionnels ou éducatifs

Le non-respect de ces interdictions expose à des sanctions maximales de 35 millions d'euros ou 7% du chiffre d'affaires mondial annuel .

1.4.2 Systèmes à risque élevé (encadrement strict)

Les systèmes à haut risque, qui constituent le périmètre le plus dense du AI Act, doivent respecter un ensemble d'exigences structurées autour de neuf piliers avant leur mise sur le marché ou leur mise en service .

Pour les entreprises qui déploient ces systèmes ("déployeurs" dans la terminologie du règlement), des obligations supplémentaires s'appliquent : mise en place de la supervision humaine sur place, surveillance du fonctionnement du système, conservation des logs, et notification des incidents sérieux .

1.4.3 Systèmes à risque limité (transparence)

Les systèmes à risque limité, qui incluent les chatbots et les outils de génération de contenu, sont soumis à une obligation principale : informer clairement l'utilisateur qu'il interagit avec une IA ou que le contenu qu'il consulte a été généré par une IA . Cette obligation de transparence, prévue à l'article 50 du règlement, est applicable à partir du 2 août 2026. Le Digital Omnibus a reporté au 2 décembre 2026 les obligations spécifiques de marquage numérique (watermarking) des contenus générés par IA .

Le Digital Omnibus a également introduit une nouvelle prohibition : l'interdiction des systèmes d'IA générant des images intimes non consensuelles et du matériel d'abus sexuels sur enfants, applicable à partir de décembre 2026 .

1.5 Sanctions et pénales

Le régime de sanctions du AI Act est gradué selon la gravité des manquements et le niveau de risque des systèmes concernés. Il vise à garantir une application cohérente du cadre réglementaire et à dissuader les comportements non conformes .

Au-delà des sanctions pécuniaires, les autorités nationales de surveillance peuvent ordonner le retrait du marché d'un système d'IA non conforme et imposer des injonctions, y compris à titre provisoire, en cas de danger grave et immédiat . L'AI Act prévoit également des sanctions allégées pour les PME et start-ups afin de ne pas freiner l'innovation, tout en maintenant une exigence minimale de conformité .

Chapitre 2. Le Cadre Sectoriel Français : Superviseurs et Référentiels

Pour les entreprises françaises, l'AI Act ne constitue qu'une couche du cadre réglementaire. Les secteurs régulés, banque, assurance, santé, secteur public, doivent articuler ces nouvelles exigences avec des référentiels préexistants déjà exigeants : ACPR, ANSSI, CNIL, HAS, HDS, RGS, NIS2, DORA. Cette superposition de cadres crée une complexité de conformité qui nécessite une approche intégrée.

2.1 Secteur financier : ACPR, DORA et AMF

2.1.1 L'ACPR, autorité de surveillance du marché pour le AI Act

L'Autorité de Contrôle Prudentiel et de Résolution (ACPR) devrait être désignée autorité de surveillance du marché pour les secteurs de la banque et de l'assurance en application du AI Act . Cette mission, qui devrait être effective depuis le 2 août 2025 (date limite de désignation des autorités nationales compétentes), confère à l'ACPR le pouvoir de contrôler la bonne application du règlement européen sur l'IA dans le secteur financier français .

L'ACPR a mis sur pied une task force interne réunissant l'ensemble de ses métiers, travaillant sur cinq axes principaux :

L'ACPR entend exercer ces missions dans l'esprit de conciliation entre innovation et sécurité qui est celui du règlement, en adoptant une approche par les risques proportionnée et en utilisant toutes les synergies possibles avec ses contrôles habituels . Le 2 avril 2025, l'ACPR a organisé une réunion de travail avec une vingtaine d'établissements (banques, assurances, fintechs) pour évaluer leur niveau de préparation et co-construire ses réflexions sur l'audit de l'IA .

2.1.2 DORA : résilience opérationnelle numérique

Le Digital Operational Resilience Act (DORA), entré en vigueur le 17 janvier 2025, constitue un cadre complémentaire particulièrement pertinent pour les systèmes d'IA déployés dans le secteur financier . DORA impose aux institutions financières de nouvelles obligations en matière de gestion des risques liés aux technologies de l'information et de la communication (TIC). Ses quatre piliers s'appliquent directement aux infrastructures IA :

DORA renforce la surveillance des risques liés aux prestataires cloud et aux fournisseurs de services IA, exigeant des institutions financières qu'elles évaluent leur résilience. Le cloud souverain de l'UE, soutenu par le cadre EUCS, vise à garantir la sécurité et la confidentialité des données européennes, s'alignant sur les objectifs de DORA .

2.1.3 Systèmes à haut risque dans le secteur financier

Dans le secteur financier, deux catégories de systèmes d'IA sont explicitement classées à haut risque par l'article 6 §2 de l'AI Act :

• Systèmes d'évaluation de solvabilité : outils d'évaluation du crédit des personnes physiques, à l'exclusion des systèmes de détection de fraude financière
• Systèmes d'évaluation des risques et tarification assurance : outils utilisés pour évaluer les risques et fixer les primes en assurance-vie et assurance-maladie

Ces systèmes devront respecter l'ensemble des exigences des systèmes à haut risque (documentation technique, supervision humaine, traçabilité, marquage CE) dès le 2 décembre 2027 . L'ACPR sera l'autorité compétente pour vérifier leur conformité .

2.2 Secteur santé : HAS, HDS et ANSM

2.2.1 La HAS et l'intelligence artificielle médicale

La Haute Autorité de Santé (HAS) a intégré l'intelligence artificielle dans son référentiel de certification des établissements de santé. La version 2025 du référentiel introduit trois critères spécifiques liés à l'IA :

Ces critères imposent aux établissements de santé une gouvernance active des outils d'IA, qu'ils aient une finalité médicale (diagnostic, aide à la décision clinique) ou organisationnelle (planification, gestion des ressources). La certification HAS v2, applicable depuis 2025, renforce également les critères sur la cybersécurité et la digitalisation .

2.2.2 HDS : hébergement des données de santé

La certification HDS (Hébergeur de Données de Santé) est un référentiel obligatoire pour tout acteur hébergeant ou traitant des données de santé à caractère personnel en France . Établie à l'article L.1111-8 du Code de la santé publique, elle garantit que les informations médicales sont stockées et traitées dans des conditions de sécurité, de confidentialité et de disponibilité strictes. Le référentiel HDS v2, publié en 2025, introduit plusieurs évolutions notables .

Pour les systèmes d'IA déployés dans le secteur de la santé, la conformité HDS est un prérequis indispensable. Les données utilisées pour entraîner ou alimenter un modèle d'IA (via RAG par exemple) doivent être hébergées dans une infrastructure certifiée HDS dès lors qu'elles contiennent des données de santé à caractère personnel. Cette contrainte s'applique également aux sous-traitants et aux prestataires de services cloud utilisés par les éditeurs de solutions IA médicales.

2.3 Secteur public : RGS et NIS2

2.3.1 Le Référentiel Général de Sécurité (RGS)

Le RGS est un ensemble de règles fixées par l'ANSSI s'imposant aux systèmes d'information des autorités administratives françaises . Il définit les exigences de sécurité pour les téléservices, la messagerie et l'authentification dans les échanges dématérialisés. Le RGS s'applique de manière obligatoire aux administrations de l'État, aux collectivités territoriales, aux établissements publics et à leurs prestataires numériques .

Toute administration procédant à des échanges électroniques doit obtenir une homologation de sécurité selon une démarche en trois étapes : identification des menaces, analyse des risques selon la criticité des données, et mise en œuvre d'un plan d'action conforme aux exigences du RGS . Pour les systèmes d'IA déployés dans le secteur public, cette homologation doit intégrer les risques spécifiques liés à l'IA (biais algorithmiques, hallucinations, fuites de données via les modèles).

2.3.2 NIS2 : cybersécurité et IA

La directive NIS2, qui doit être transposée en droit français, renforce la cybersécurité des entreprises dans l'UE en élargissant son champ d'application et en imposant des obligations plus strictes . En France, entre 15 000 et 18 000 entreprises seront concernées, classifiées en entités essentielles (EE) ou importantes (EI). Les entreprises concernées auront trois ans pour se conformer à partir de la publication des décrets .

L'ANSSI a défini 20 objectifs stratégiques pour encadrer cette transposition. L'interaction entre NIS2 et les systèmes d'IA est particulièrement importante : les attaques ciblant spécifiquement l'IA (empoisonnement, évasion, extraction) doivent être intégrées dans les analyses de risques cyber des entités concernées .

2.4 Cybersécurité : les 35 recommandations de l'ANSSI

L'Agence nationale de la sécurité des systèmes d'information (ANSSI) a publié en avril 2024 un guide de 35 recommandations de sécurité pour un système d'intelligence artificielle générative . Actualisé en 2025, ce document constitue la référence française en matière de sécurisation des architectures IA. Il traite de la sécurisation d'une architecture de système d'IA générative depuis la phase de conception jusqu'au déploiement .

Les recommandations s'articulent autour de trois grandes catégories d'attaques identifiées :

Parmi les 35 recommandations, plusieurs sont directement applicables à la gouvernance des systèmes RAG et chatbots en entreprise :

L'ANSSI a également publié en février 2025 un rapport international, en partenariat avec 16 organismes, sur le développement de la confiance dans l'IA par une approche par les risques cyber . Ce document souligne que la sécurité des systèmes d'IA n'est jamais garantie et que leur utilisation peut accroître la vulnérabilité de leurs utilisateurs face aux cyberattaques . L'agence est par ailleurs partie prenante de l'Institut national de l'évaluation de la sécurité de l'intelligence artificielle (INESIA), lancé en 2025, qui développe des schémas de certification pour les produits et systèmes intégrant de l'IA .

Chapitre 3. RGPD et Intelligence Artificielle : les Recommandations de la CNIL

L'application du RGPD aux systèmes d'intelligence artificielle constitue un enjeu majeur de la gouvernance IA. La CNIL a publié une série de fiches pratiques détaillant les conditions de conformité des systèmes d'IA au règlement européen sur la protection des données . Ces recommandations s'inscrivent dans le plan d'action sur l'IA lancé par la CNIL en 2023 et complètent les règles existantes en matière de conformité .

3.1 Les piliers de la conformité RGPD pour l'IA

La CNIL met en avant la nécessité d'intégrer la protection des données dès la conception (privacy by design) et par défaut (privacy by default) des systèmes d'IA . Le responsable du traitement doit être en mesure de démontrer à tout moment sa conformité aux principes du RGPD, ce qui implique une documentation rigoureuse et la mobilisation du Data Protection Officer (DPO) .

La CNIL rappelle que ces principes s'appliquent à toutes les phases du cycle de vie d'un système d'IA : constitution des jeux de données, entraînement du modèle, déploiement en production, et utilisation par les utilisateurs finaux .

3.2 Données d'entraînement : constitution et gestion

Les fiches pratiques de la CNIL insistent sur la documentation de la constitution des jeux de données d'entraînement. Pour chaque jeu de données, le responsable de traitement doit être en mesure de justifier plusieurs éléments clés :

• La provenance des données (collecte directe, bases ouvertes, web scraping, achat)
• La base légale applicable à chaque source
• Les catégories de données incluses et exclues
• Les mesures de minimisation appliquées (suppression de champs identifiants, pseudonymisation)
• La durée de conservation des données d'entraînement après l'achèvement du modèle

La question de la conservation des données d'entraînement fait l'objet d'une attention particulière. La CNIL considère qu'une conservation "au cas où", sans finalité précise, contrevient au principe de limitation de la conservation . Si les données sont nécessaires pour ré-entraîner ou améliorer le modèle, leur conservation peut être justifiée, mais cette justification doit être documentée .

3.3 Anonymisation, pseudonymisation et données synthétiques

La CNIL considère que l'anonymisation et la pseudonymisation constituent des garanties fortes qui ne s'opposent pas à l'utilisation des données personnelles pour l'entraînement d'IA, dès lors que ces mesures sont nécessaires au traitement . Dans sa synthèse des contributions sur les fiches IA, la CNIL apporte plusieurs clarifications importantes :

La CNIL a développé une arborescence décisionnelle pour guider les acteurs dans la détermination du statut d'un modèle d'IA au regard du RGPD . Cette méthodologie passe par l'évaluation de la vraisemblance de réidentification des personnes à partir du modèle, en conduisant des tests d'attaque sur le système. Si l'analyse conclut à une vraisemblance insignifiante de réidentification, l'utilisation du système peut être présumée sortie du champ d'application du RGPD .

3.4 Droit à l'oubli et vector stores : l'enjeu technique majeur

Le droit à l'effacement, souvent appelé "droit à l'oubli", est consacré par l'article 17 du RGPD. Il permet aux individus de demander la suppression de leurs données personnelles détenues par un organisme . En 2025, ce droit a été choisi comme thème de l'action coordonnée du Comité européen de la protection des données (CEPD), avec la participation de 32 autorités européennes . Pour la seule CNIL en 2024, le droit à l'effacement représentait 37% des plaintes reçues .

L'application du droit à l'oubli aux systèmes d'IA soulève des défis techniques majeurs, particulièrement pour les architectures RAG (Retrieval-Augmented Generation) qui reposent sur des vector stores (bases de données vectorielles) .

La CNIL a lancé le projet partenarial PANAME (Privacy AuditiNg of Ai ModEls) avec l'ANSSI, le programme iPoP et le PEReN, visant à développer une bibliothèque logicielle pour évaluer si un modèle traite ou non des données personnelles . Cet outil, attendu pour les prochains mois, permettra d'offrir des solutions techniques concrètes aux développeurs et utilisateurs de modèles d'IA.

3.5 Responsabilités des acteurs de la chaîne de valeur

La CNIL a annoncé la publication, au second semestre 2025, de nouvelles recommandations pour éclairer les acteurs de la chaîne de création d'un système d'IA sur leurs responsabilités au regard du RGPD . Ces recommandations porteront notamment sur :

• La précision des conséquences de l'application du RGPD aux modèles qui ne seraient pas anonymes
• L'étude du cas de l'open source, pratique essentielle pour le développement des technologies d'IA
• Les outils techniques pour faciliter la mise en œuvre concrète des recommandations

Chapitre 4. Sécurité des Systèmes RAG et Chatbots en Entreprise

Le déploiement de chatbots et de systèmes RAG (Retrieval-Augmented Generation) en entrepose un risque spécifique : le contournement des règles d'accès existantes. Un chatbot mal cadré peut exposer à un opérateur de production des salaires de l'équipe direction. Un RAG mal configuré peut révéler à un commercial des notes confidentielles du comité juridique. La sécurité de l'accès aux documents ne peut pas être une couche ajoutée après coup : elle doit faire partie intégrante de l'architecture.

4.1 Le principe : héritage des autorisations existantes

Les chatbots et RAG d'entreprise doivent s'appuyer sur les systèmes d'autorisation déjà en place : Active Directory, IAM (Identity and Access Management), ou modèle RBAC métier. L'opérateur de production qui interroge un agent ne doit récupérer que les documents qu'il pourrait déjà consulter dans les applications existantes. Aucun canal IA ne doit contourner les règles d'accès établies .

Cette approche s'appuie sur plusieurs mécanismes complémentaires :

4.2 Row-level security et metadata filtering

La row-level security (RLS) représente l'état de l'art pour sécuriser les systèmes RAG d'entreprise. Cette technique consiste à appliquer des filtres de permissions avant la recherche vectorielle, garantissant que seuls les documents autorisés sont pris en compte dans le calcul de similarité .

Le processus se déroule en trois phases critiques :

Phase 1 : Ingestion et tagging ACL. Lors de l'ingestion des documents dans le vector store, chaque chunk est enrichi de métadonnées de sécurité : owner_id, tenant_id, department, access_level, classification (publique, interne, confidentielle, secrète). Ces métadonnées proviennent directement du système de gestion documentaire source (SharePoint, Google Drive, Confluence) où les ACL sont déjà définies .

Phase 2 : Filtrage à la requête. Quand un utilisateur soumet une requête, le système récupère d'abord ses permissions depuis l'Identity Provider (Active Directory, Okta, etc.), puis construit un filtre dynamique qui est appliqué à la recherche vectorielle. Par exemple : WHERE department IN ('Finance') AND access_level <= user_access_level .

Phase 3 : Validation post-requête. Avant d'envoyer les chunks récupérés au LLM, le système effectue une dernière validation pour s'assurer qu'aucun document hors périmètre n'a été inclus. Cette étape de "fail close" garantit que si le contexte utilisateur est manquant ou corrompu, la requête est rejetée .

4.3 Modèles d'autorisation pour RAG

Plusieurs modèles d'autorisation peuvent être implémentés dans un système RAG, selon la complexité des besoins de l'organisation :

Le modèle ReBAC est particulièrement bien adapté aux applications RAG car il se concentre sur les relations entre les utilisateurs et les ressources plutôt que sur la gestion des endpoints. Cela le rend idéal pour le post-query filtering, où le système doit déterminer quels documents un utilisateur peut accéder en fonction de ses relations avec les catégories de documents .

4.4 Isolation multi-locataire et sécurité du vector store

Dans les architectures SaaS ou multi-départements, l'isolation des données entre locataires est fondamentale. Trois patterns d'isolation sont couramment utilisés :

Les bases de données vectorielles modernes (Pinecone, Weaviate, Qdrant, pgvector) supportent toutes le metadata filtering, qui permet d'implémenter efficacement l'isolation par filtre de locataire . La recommandation de sécurité est d'appliquer les filtres de locataire avant la recherche de similarité, pas après, pour éviter que les embeddings d'autres locataires ne soient chargés en mémoire et ne fuient via des manipulations de prompt .

4.5 Défenses contre les attaques sur les systèmes RAG

Les systèmes RAG sont exposés à des attaques spécifiques qui peuvent contourner les contrôles d'accès ou extraire des informations sensibles :

Le concept de RAG 2.0 émerge pour adresser ces défis en introduisant un flux de contrôle centré sur la sécurité : session-based policy evaluation, metadata filtering avant injection dans le prompt, permission branching mid-flow, et provenance tracking explicable .

Chapitre 5. Gouvernance Organisationnelle de l'IA

5.1 Comité de pilotage IA : instance décisionnelle transversale

Le premier réflexe des entreprises est souvent de confier la gouvernance IA à la DSI ou au Chief Data Officer. C'est une erreur. Le comité de pilotage IA doit être une instance transversale et décisionnelle, co-présidée par un membre du COMEX et le responsable data/IA . Sa composition type inclut : DG ou DGA, DSI, directeur métier principal, DRH (pour l'impact emploi), RSSI (pour la sécurité des données), et un référent éthique .

L'efficacité d'un comité de gouvernance IA repose sur la diversité des expertises représentées. Une vision exclusivement technique ou juridique serait insuffisante pour appréhender la nature multidimensionnelle des enjeux de l'IA .

La fréquence des réunions dépend du nombre de systèmes IA déployés : trimestrielle pour deux ou trois systèmes, mensuelle au-delà de cinq . Le rôle du comité est de valider les nouveaux déploiements, d'arbitrer les évolutions, et d'examiner les incidents. Dès lors qu'au moins deux systèmes IA sont déployés en production, un comité de pilotage dédié devient indispensable .

5.2 Architecture organisationnelle à trois niveaux

Une gouvernance IA efficace s'organise en trois niveaux d'intervention, du stratégique à l'opérationnel :

Niveau stratégique, Comité de gouvernance IA. Présidé par un membre du comité exécutif (CEO ou COO), cette instance définit la vision, la stratégie et les priorités d'investissement IA de l'organisation. Elle assure l'alignement entre initiatives IA et objectifs business, arbitre les conflits de priorités et valide les investissements majeurs . Ses missions incluent : définition de la stratégie IA corporate, validation des investissements au-delà d'un seuil défini, approbation des politiques de gouvernance, et supervision des risques IA majeurs .

Niveau opérationnel, Comité de pilotage IA. Animé par le Chief Data Officer ou Chief AI Officer, ce comité traduit la stratégie en plans d'action concrets et pilote l'exécution des initiatives. Il assure la coordination entre projets, l'allocation des ressources et le suivi des performances . Ses responsabilités couvrent : la priorisation des projets selon les critères stratégiques, l'allocation des ressources techniques et budgétaires, le suivi des performances et du ROI, et l'escalade des problèmes vers le comité stratégique .

Niveau technique, Centre d'excellence IA (AI Center of Excellence). Cette structure centralise l'expertise technique et méthodologique, développe les standards et bonnes pratiques, et accompagne les métiers dans leurs projets . Il comprend typiquement : une équipe data science et ML engineering, des experts en éthique et explicabilité IA, des spécialistes en gouvernance des données, et des consultants internes pour l'accompagnement métier .

5.3 Les cinq piliers d'une gouvernance IA en ETI

L'expérience auprès de dizaines d'ETI permet de formaliser les fondamentaux d'une gouvernance IA qui fonctionne :

5.4 ISO/IEC 42001 : le standard international de gouvernance IA

L'ISO/IEC 42001:2023 est la première norme internationale certifiable dédiée aux systèmes de management de l'intelligence artificielle (SMIA) . Publiée en décembre 2023, elle s'impose rapidement comme le standard de référence pour gouverner l'IA de manière responsable. En décembre 2025, plus de 2 400 organisations étaient certifiées dans le monde, avec une croissance de +350% par rapport à 2024 .

L'un des atouts majeurs de l'ISO 42001 réside dans sa forte convergence avec les exigences de l'AI Act. La norme couvre déjà 80 à 85% des obligations du règlement européen, ce qui en fait un socle opérationnel particulièrement efficace pour atteindre la conformité .

Seules quelques zones restent spécifiques à l'AI Act et ne sont pas couvertes par l'ISO 42001 : l'enregistrement dans la base de données européenne, les évaluations par organismes notifiés pour certains produits, le marquage CE, et la déclaration de conformité UE . Ces éléments représentent entre 15 et 20% des exigences de l'AI Act et doivent être traités en complément de la certification ISO 42001.

Chapitre 6. Méthodologie d'Audit IA et Livrables de Conformité

6.1 Phases de l'audit de gouvernance IA

Un audit de gouvernance IA structuré se déroule en cinq phases successives, d'une durée totale de deux à trois semaines pour un système existant :

Le coût d'un audit initial pour un système IA en production sans documentation de conformité varie de 12 000 à 25 000 euros selon la complexité . La mise en conformité elle-même varie de 15 000 euros pour une remise en ordre documentaire simple à 80 000 euros si une refonte de l'architecture d'accès est nécessaire . Sur le marché français en 2026, les TJM des consultants spécialisés se situent entre 600 et 3 000 euros par jour selon le niveau d'expertise .

6.2 Grille d'évaluation de la maturité gouvernance IA

La grille suivante permet d'évaluer la maturité de la gouvernance IA d'une organisation sur une échelle de 1 (initial) à 5 (optimisé) :

6.3 Les huit livrables de mise en production

Chaque mise en production d'un système IA doit produire huit documents constitutifs du dossier de conformité :

6.4 Checklist de conformité AI Act par niveau de risque

Checklist, Systèmes à risque limité (chatbots, génération de contenu)

Checklist, Systèmes à risque élevé (recrutement, scoring, diagnostic)

Chapitre 7. Intégration Réglementaire : Articuler AI Act, RGPD et Cadres Sectoriels

7.1 Matrice d'articulation des référentiels

Les entreprises des secteurs régulés doivent naviguer dans un écosystème complexe de référentiels en partie superposés. La matrice suivante synthetise les articulations principales :

7.2 Approche intégrée de la conformité

L'approche recommandée pour les ETI consiste à ne pas traiter chaque référentiel de manière isolée, mais à construire un dispositif de gouvernance IA qui agrège les exigences communes et identifie les spécificités sectorielles. La gouvernance IA s'appuie sur la gouvernance data existante : le data catalog référence les datasets utilisés par les systèmes IA, les politiques de classification déterminent quels documents un système IA peut ingérer, et les processus existants de validation des accès s'étendent aux nouveaux canaux IA .

7.3 Cartographie des acteurs de supervision en France

Chapitre 8. Templates Opérationnels

8.1 Template, Registre des systèmes IA (conforme AI Act)

8.2 Template, Fiche technique système IA à risque élevé

8.3 Template, Plan de réponse aux incidents IA

Conclusion, Les 10 commandements de la gouvernance IA pour les ETI

Face à la complexité du paysage réglementaire et technique, voici les dix principes directeurs que nous recommandons à toute ETI déployant ou envisageant de déployer des systèmes d'intelligence artificielle :

La conformité n'est pas une destination mais un processus continu. Les entreprises qui investissent dès maintenant dans une gouvernance IA structurée, avec des comités opérationnels, des registres tenus à jour, des contrôles d'accès robustes et une documentation complète, transformeront cette contrainte réglementaire en avantage concurrentiel. La certification ISO 42001, la maîtrise démontrée des risques et la capacité à répondre efficacement aux audits deviendront des différenciateurs sur un marché où la confiance dans l'IA ne cesse de s'éroder .

Document rédigé en mai 2026. Les dates réglementaires citées intègrent les modifications apportées par le Digital Omnibus (accord politique du 7 mai 2026). Ce guide ne constitue pas un avis juridique et doit être complété par une analyse au cas par cas de la situation de chaque organisation.