Plan de mise en conformité AI Act
Une méthode opérationnelle pour passer de l'obligation réglementaire à un plan d'action daté : inventaire, gap analysis, quick wins, roadmap 12-24 mois et portage RACI.
Table des matières
Pourquoi un plan, et pas seulement une liste d'obligations
Les chapitres précédents ont détaillé les obligations de 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 : classification par niveau de risque, exigences documentaires, transparence, gouvernance des systèmes à haut risquehaut 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. Cette connaissance reste théorique tant qu'elle n'est pas transformée en actions datées, budgétées et attribuées à des responsables identifiés. C'est l'objet de ce chapitre : construire un plan de mise en conformité qui tienne la route devant un COMEX, une direction juridique et un calendrier réglementaire qui ne se négocie pas.
L'AI Act n'a pas une seule date d'entrée en vigueur. Les obligations s'échelonnent : interdictions de pratiques inacceptables depuis le 2 février 2025, obligations pour les modèles à usage général (GPAI) et gouvernance depuis le 2 août 2025, obligations complètes pour les systèmes à haut risque au 2 août 2026, et certaines dispositions sectorielles jusqu'en 2027. Un plan de conformité doit être structuré autour de ce calendrier, pas autour d'une échéance unique fictive.
Un plan de mise en conformité efficace répond à cinq questions dans l'ordre : que possédons-nous réellement en matière d'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, quel est le niveau de risque de chaque système, où sont les écarts par rapport aux obligations, que peut-on corriger rapidement, et comment structure-t-on l'effort de fond sur la durée. Ce chapitre suit cet enchaînement.
Étape 1 — L'inventaire des systèmes IA
Avant toute analyse de conformité, il faut savoir ce que l'organisation utilise réellement. Ce n'est presque jamais ce que l'on croit. L'inventaire spontané établi par la DSI omet systématiquement les usages portés par les métiers : un assistant de recrutement intégré dans un SIRH SaaS, un outil de scoring crédit acheté par la finance, un chatbot client déployé par le marketing sans validation centrale.
Un inventaire utilisable croise trois sources :
- Le référentiel applicatif — extraire tout logiciel dont la fiche produit mentionne IA, machine learningapprentissage automatiqueIABranche de l'IA où le programme dégage lui-même ses règles à partir d'exemples, au lieu de les recevoir d'un développeur. C'est ce déplacement des règles écrites vers les régularités apprises qui définit l'IA moderne.Voir dans le glossaire, scoring, recommandation ou génération automatique.
- Les achats et contrats fournisseurs — les clauses IA apparaissent rarement dans l'intitulé du contrat mais souvent dans les CGU du produit.
- Une enquête déclarative auprès des directions métier — la seule source qui révèle le "shadow AI", ces usages d'outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire IA grand public (assistants génératifs, extensions navigateur) jamais validés par un processus d'achat.
Pour chaque système recensé, l'inventaire doit consigner : la finalité métier, le fournisseur, si le système est développé en interne ou acquis, les 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, les personnes concernées par les décisions du système, et le rôle de l'organisation au sens de l'AI Act (fournisseur, déployeur, distributeur, importateur).
Le rôle réglementaire n'est pas figé. Une organisation qui personnalise substantiellement un modèle IA acheté, ou qui appose sa propre marque sur un système IA, peut basculer du statut de déployeur à celui de fournisseur — avec un jeu d'obligations nettement plus lourd. Vérifier ce point pour chaque système est un préalable, pas un détail.
Étape 2 — Classifier avant d'analyser les écarts
Une fois l'inventaire stabilisé, chaque système doit être classé selon les niveaux de risque de l'AI Act : inacceptable (interdit), haut risque, risque limité (obligations de transparence), risque minimal. Cette classification détermine entièrement la suite du plan — inutile de mener une gap analysis détaillée sur un système à risque minimal alors qu'un système RH de tri de candidatures, presque toujours à haut risque au titre de l'annexe III, mérite un traitement prioritaire.
Étape 3 — La gap analysis
Pour chaque système à haut risque ou à obligations de transparence, la gap analysis compare l'existant aux exigences du règlement : système de gestion des risques, gouvernance des données d'entraînement, documentation technique, journalisation (logging), transparence envers les personnes concernées, supervision humaine, robustesse et cybersécurité, enregistrement dans la base de données européenne le cas échéant.
Un tableau de gap analysis, même sommaire, doit exister pour chaque système prioritaire :
| Exigence AI Act | Statut actuel | Écart | Effort estimé |
|---|---|---|---|
| Documentation technique (art. 11) | Fiche produit fournisseur uniquement | Absence de documentation interne sur l'usage réel | Moyen |
| Supervision humaine (art. 14) | Validation automatique sans intervention humaine | Aucun point d'arrêt humain avant décision | Élevé |
| Journalisation (art. 12) | Logs applicatifs génériques | Pas de traçabilité des décisions individuelles | Moyen |
| Information des personnes concernées (art. 13, 26) | Aucune mention dans les communications | Absence totale | Faible |
Le piège le plus fréquent est de confondre la documentation fournisseur avec la documentation de conformité. Un fournisseur de système IA à haut risque produit une documentation technique au sens de l'annexe IV, mais le déployeur reste responsable de ses propres obligations : supervision humaine effective, information des personnes concernées, tenue de ses propres registres d'usage. Recevoir la fiche technique du fournisseur ne clôt pas la gap analysis, elle en constitue une entrée.
Étape 4 — Distinguer quick wins et chantiers structurels
Une fois les écarts identifiés, la tentation est de tout traiter en parallèle. C'est une erreur de méthode qui dilue les ressources et retarde les résultats visibles nécessaires à maintenir le soutien du COMEX. Il faut trier.
Les quick wins partagent trois caractéristiques : ils ne nécessitent pas de changement de système, ils ne dépendent pas d'un budget d'investissement significatif, et ils réduisent un risque réel. Exemples concrets :
- Ajouter une mention d'information sur l'usage d'un système IA dans un point de contact client existant (obligation de transparence de l'article 50).
- Nommer un référent AI Act et documenter le circuit de remontée d'incident.
- Geler les achats de nouveaux outils IA sans passage par une check-list de qualification préalable.
- Retirer ou suspendre tout usage relevant des pratiques interdites (notation sociale, manipulation subliminale, reconnaissance des émotions au travail hors exceptions strictes) — ce point n'est pas négociable et doit être traité en priorité absolue, indépendamment de sa complexité technique.
Les chantiers structurels demandent un budget, une refonte de processus ou un arbitrage organisationnel : mise en place d'un système de gestion des risques IA pérenne, intégration d'un point de supervision humaine dans un workflow automatisé, construction d'une base de gouvernance des données d'entraînement, déploiement d'un outil de journalisation dédié.
Livrer deux ou trois quick wins visibles dans les six premières semaines change la dynamique politique du projet. Un plan de conformité qui ne produit aucun résultat tangible avant plusieurs mois perd le soutien des sponsors, quelle que soit la qualité de l'analyse sous-jacente.
Étape 5 — Construire la roadmap 12-24 mois
La roadmap articule les chantiers structurels avec le calendrier réglementaire et les cycles budgétaires de l'organisation. Une structure en trois horizons fonctionne dans la plupart des contextes :
- 0-3 mois — quick wins, arrêt des pratiques interdites, désignation des responsables, cadrage du périmètre.
- 3-12 mois — mise en conformité des systèmes à haut risque prioritaires, construction du système de gestion des risques, formation des équipes concernées, mise en place de la documentation technique interne.
- 12-24 mois — audit interne ou externe, préparation à une éventuelle évaluation de conformité, intégration dans un système de management pérenne, amélioration continue.
Une entreprise de services financiers de taille intermédiaire recense 14 systèmes IA lors de son inventaire, dont 3 relèvent du haut risque (scoring crédit, détection de fraude avec impact individuel, outil de tri des candidatures RH). La gap analysis révèle qu'aucun des trois ne dispose d'un point de supervision humaine documenté. Le plan retenu traite en quick win la suspension temporaire de la décision automatique pure sur le scoring crédit — en réintroduisant une validation humaine minimale sous 15 jours — puis engage sur 9 mois la refonte du workflow avec le fournisseur pour industrialiser cette supervision, en parallèle de la construction du registre de risques IA porté par la fonction conformité.
Étape 6 — Le portage RACI
Un plan sans porteurs identifiés reste un document. La matrice RACI (Responsible, Accountable, Consulted, Informed) doit couvrir au minimum : l'inventaire et sa mise à jour continue, la classification des nouveaux systèmes avant achat, la documentation technique, la formation des utilisateurs de systèmes à haut risque, et le reporting au COMEX.
Dans la majorité des organisations qui n'ont pas de fonction IA dédiée, le montage suivant fonctionne : le DPO ou un référent IA nouvellement désigné porte la responsabilité opérationnelle (Responsible) de l'inventaire et de la classification, la direction juridique ou conformité est Accountable sur l'interprétation réglementaire, les directions métier sont Responsible sur la documentation d'usage et Consulted sur la classification, et la direction générale reste Informed sauf sur les décisions d'arbitrage budgétaire où elle devient Accountable.
Le référent IA n'a pas besoin d'être un poste à temps plein dès la première année. Ce qui compte est que la fonction existe formellement, avec un mandat écrit et un accès direct au COMEX en cas de risque identifié — pas qu'elle soit occupée à plein temps dès le lancement du plan.
Le pitch COMEX
Présenter ce plan à un COMEX exige un format différent de la gap analysis détaillée. Trois messages suffisent : le niveau d'exposition actuel (nombre de systèmes à haut risque, écarts critiques, échéances réglementaires proches), les actions déjà engagées avec leur coût, et la demande d'arbitrage précise — budget, ressource humaine, ou décision de suspendre un usage. Éviter d'ouvrir le sujet par l'exhaustivité du règlement : un COMEX retient trois chiffres et une décision à prendre, pas vingt-cinq articles.
Un support de trois diapositives — exposition, plan d'action, demande d'arbitrage — obtient généralement plus d'adhésion qu'un rapport de quarante pages. Le rapport détaillé reste nécessaire, mais en annexe, pour les équipes opérationnelles.
Articulation avec ISO 42001 et le RGPD
Le plan de mise en conformité AI Act ne doit pas être construit en silo. La norme ISO/IEC 42001, qui définit un système de management de l'intelligence artificielle, offre un cadre organisationnel qui recouvre une large part des exigences de gouvernance de l'AI Act — inventaire, gestion des risques, amélioration continue. Une organisation déjà engagée dans une démarche ISO 42001 peut s'appuyer sur cette structure plutôt que d'en créer une nouvelle en parallèle.
Le RGPDRGPDConformitéRèglement européen sur la protection des données personnelles. Il s'applique dès qu'un système d'IA traite de telles données, et se cumule avec l'AI Act.Voir dans le glossaire, de son côté, couvre un périmètre voisin mais distinct : la protection des données à caractère personnel. De nombreux systèmes IA à haut risque traitent des données personnelles, ce qui signifie que l'analyse d'impactAIPDConformitéAnalyse d'impact relative à la protection des données, obligatoire dès qu'un traitement est susceptible d'engendrer un risque élevé — ce qui couvre la plupart des systèmes de profilage.Voir dans le glossaire relative à la protection des données (AIPD) et l'analyse de conformité AI Act partagent des constats communs — finalité du traitement, personnes concernées, mesures de protection — sans se substituer l'une à l'autre. Mutualiser les ateliers de collecte d'information entre le référent AI Act et le DPO évite de solliciter deux fois les mêmes équipes métier pour des questions largement similaires.
L'AI Act et NIS2 sont deux règlements distincts, à ne pas fusionner dans un même plan sans discernement. NIS2 porte sur la cybersécurité des entités essentielles et importantes, l'AI Act sur les systèmes d'intelligence artificielle en tant que tels. Un système IA à haut risque déployé par une entité soumise à NIS2 peut relever des deux textes simultanément, mais leurs obligations, leurs autorités de contrôle et leurs calendriers ne se recoupent pas automatiquement.
Ce que ce plan ne remplace pas
Ce chapitre fournit une méthode opérationnelle, pas un avis juridique. La qualification exacte d'un système au regard de l'annexe III, l'interprétation d'une exemption, ou la rédaction des clauses contractuelles avec un fournisseur de système IA doivent être validées par une expertise juridique dédiée, en particulier pour les systèmes à fort impact sur les personnes. Le plan de mise en conformité structure la démarche et accélère l'exécution ; il ne dispense pas de la vérification réglementaire fine sur les cas limites.
L'essentiel à retenir
Ce chapitre transforme les obligations de l'AI Act, vues dans les chapitres précédents, en un plan de mise en conformité exécutable. Il détaille la méthode d'inventaire des systèmes IA, la conduite d'une gap analysis, la priorisation en quick wins puis en chantiers de fond sur 12 à 24 mois, ainsi que le montage d'une gouvernance RACI. Il propose également une trame de pitch COMEX et articule cette démarche avec ISO 42001 et le RGPD, sans se substituer à un audit juridique.
Questions fréquentes
Faut-il attendre que tous les systèmes soient inventoriés avant de commencer la gap analysis ?
Un système IA acheté sur étagère (SaaS) engage-t-il notre responsabilité au même titre qu'un système développé en interne ?
Combien de temps prend, en pratique, la construction d'un plan de mise en conformité complet ?
Le référent AI Act doit-il être la même personne que le DPO ?
Que faire si la gap analysis révèle qu'un système à haut risque ne peut pas être mis en conformité avant l'échéance du 2 août 2026 ?
Comment prioriser entre plusieurs systèmes à haut risque quand les ressources sont limitées ?
Le plan de mise en conformité doit-il être révisé une fois établi ?
Progression sauvegardée dans votre navigateur.
Quiz de validation
Quiz Player
Quiz de validation
Plusieurs réponses possibles — validez ensuite.
Vrai ou faux.
Quiz indisponible (données invalides).