L’AI Act est entré dans sa phase opérationnelle. Pour les entreprises, le sujet n’est plus seulement de comprendre le règlement, mais de transformer ses exigences en chantiers pilotables, avec des responsables identifiés, des preuves conservées et des décisions documentées.
La conformité AI Act concerne la DSI, les métiers, la Direction Achats, la DRH, le juridique, la conformité, la cybersécurité et la protection des données. Elle suppose de connaître les systèmes utilisés, de qualifier leur niveau de risque, de vérifier le rôle juridique de l’organisation et d’encadrer les fournisseurs.
Voici les dix chantiers prioritaires à lancer pour structurer une feuille de route réaliste en 2026.
Par où commencer pour se mettre en conformité avec l’AI Act ?
Pour se mettre en conformité avec l’AI Act, une entreprise doit d’abord recenser ses usages d’intelligence artificielle, identifier les responsables, qualifier les risques et repérer les pratiques interdites ou soumises à transparence. Elle peut ensuite constituer un AI Registry, traiter les systèmes prioritaires et organiser la supervision, la documentation, la formation et le suivi des fournisseurs.
Ce qui change pour les entreprises en 2026
Le calendrier de l’AI Act a été ajusté par le règlement (UE) 2026/1744, dit Digital Omnibus sur l’IA. Le texte est consultable dans sa version officielle sur EUR-Lex. Les échéances varient selon la catégorie du système et le rôle de l’organisation.
Pour les systèmes à haut risque relevant de l’annexe III, les obligations principales sont prévues à partir du 2 décembre 2027. Les systèmes à haut risque intégrés dans des produits réglementés relevant de l’annexe I sont concernés à partir du 2 août 2028, sous réserve des dispositions transitoires applicables. La version consolidée du règlement, mise à jour au 27 juillet 2026, doit rester la référence pour vérifier le calendrier applicable à chaque système. Elle est disponible sur EUR-Lex.
Depuis le 2 août 2026, les obligations de transparence prévues par l’article 50 s’appliquent aux systèmes concernés. Les personnes doivent notamment être informées lorsqu’elles interagissent directement avec certains systèmes d’IA. Des règles spécifiques concernent aussi le marquage de certains contenus générés ou manipulés par IA.
La Commission européenne a publié des lignes directrices sur les obligations de transparence de l’article 50, ainsi qu’une FAQ consacrée à leur mise en œuvre. Un délai spécifique jusqu’au 2 décembre 2026 concerne certains systèmes déjà mis sur le marché avant le 2 août 2026, pour les obligations de marquage et de détection des contenus générés ou manipulés par IA.
Cette actualité ne signifie pas que toutes les entreprises doivent traiter tous leurs systèmes au même rythme. Elle impose surtout de connaître son périmètre, de qualifier les échéances applicables et de conserver les arbitrages qui expliquent les priorités retenues.
Ce que coûte l’inaction
L’article 99 de l’AI Act prévoit des amendes administratives pouvant atteindre 35 millions d’euros ou 7 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu, en cas de non-respect des pratiques interdites. Pour d’autres manquements liés aux obligations des opérateurs ou des organismes notifiés, le plafond peut atteindre 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial. La fourniture d’informations incorrectes, incomplètes ou trompeuses peut relever d’un plafond de 7,5 millions d’euros ou 1 % du chiffre d’affaires mondial.
Ces montants sont des plafonds réglementaires, et non une estimation automatique de la sanction applicable à chaque situation. Le montant doit rester effectif, proportionné et dissuasif. D’autres cadres peuvent également s’appliquer selon les faits, notamment le RGPD lorsque des données personnelles sont traitées.
Pour un grand groupe, cette exposition justifie un sponsor exécutif, un budget identifié et une gouvernance qui ne repose pas uniquement sur une initiative de la DSI.
Les 10 chantiers à lancer
Une feuille de route efficace ne consiste pas à traiter les obligations dans l’ordre des articles du règlement. Elle commence par les chantiers qui donnent de la visibilité, puis concentre les moyens sur les systèmes les plus sensibles.
Chantier 1 : installer une gouvernance IA transverse
Le premier chantier consiste à décider qui pilote la conformité AI Act et comment les arbitrages sont pris. Dans un grand groupe, les systèmes IA sont répartis entre les applications métiers, les outils RH, les solutions achats, les projets data, les logiciels SaaS et les produits développés en interne. Une gouvernance limitée à la DSI ne couvre pas l’ensemble des usages.
Le dispositif doit préciser les responsabilités du sponsor exécutif, de la DSI, des métiers, de la Direction Achats, de la DRH, du juridique, du DPO, de la conformité et de la cybersécurité. Il doit aussi définir les cas qui nécessitent une validation avant expérimentation ou mise en production.
Pour éviter de créer un dispositif parallèle, la gouvernance IA peut s’appuyer sur les référentiels déjà utilisés par l’entreprise. ISO/IEC 42001:2023 fournit un cadre de système de management de l’intelligence artificielle. Le NIST AI RMF propose une approche structurée autour de quatre fonctions : Govern, Map, Measure et Manage. Ces référentiels peuvent éclairer l’organisation, sans remplacer les obligations juridiques de l’AI Act.
Livrable : une charte de gouvernance IA, une matrice RACI, un calendrier de comité et une procédure de validation des nouveaux usages.
Responsable : DSI ou Chief Data Officer, avec un sponsor de direction générale.
Anti-pattern : créer un comité IA sans pouvoir d’arbitrage, sans budget et sans rattachement clair aux comités risques, sécurité ou conformité.
Chantier 2 : cartographier tous les systèmes et usages IA
Une entreprise ne peut pas qualifier un risque qu’elle n’a pas identifié. Le premier inventaire se limite souvent aux projets IA officiellement déclarés. La seconde passe doit couvrir les fonctions déjà activées dans le CRM, l’outil de ticketing, la suite bureautique, l’ATS, les outils de relation client et les solutions de gestion des fournisseurs.
L’écart vient souvent du périmètre. Certaines fonctions IA ont été activées par un fournisseur, sans projet central, sans validation de la DSI et sans propriétaire clairement désigné. Le recensement doit donc associer les équipes IT, les métiers, les achats et les responsables applicatifs.
Pour chaque système, il faut documenter la finalité, le propriétaire métier, le fournisseur, les données utilisées, les utilisateurs concernés, la localisation des traitements, les interfaces avec d’autres applications et la décision éventuellement influencée par l’IA. Il faut aussi identifier les modèles d’IA à usage général intégrés dans des applications tierces.
Livrable : un inventaire qualifié des systèmes et usages IA, avec un propriétaire identifié pour chaque ligne.
Responsable : DSI, avec la contribution des directions utilisatrices et des Achats.
Anti-pattern : confier l’inventaire à la DSI seule. Cette méthode rate les fonctions IA activées par défaut dans les logiciels déjà utilisés par les équipes.
Chantier 3 : qualifier les risques et le rôle juridique de l’organisation
La classification par niveau de risque est le point de passage entre l’inventaire et le plan d’action. Chaque système doit être analysé selon sa finalité réelle, son domaine d’utilisation, les personnes concernées et son impact potentiel sur leurs droits ou leur sécurité.
Il faut répondre à deux questions : quel est le niveau de risque du système et quel est le rôle juridique de l’organisation ? L’article 3 distingue le fournisseur, qui développe ou fait développer un système et le met sur le marché ou en service sous son propre nom ou sa propre marque, du déployeur, qui utilise un système sous sa propre autorité.
Le piège de la requalification fournisseur
Un groupe qui appose son nom ou sa marque sur un système à haut risque, qui le modifie substantiellement ou qui change sa finalité de manière à le faire entrer dans le haut risque peut devenir fournisseur au sens de l’article 25. Il n’assume alors plus seulement les obligations du déployeur. Il peut devoir prendre en charge des obligations de documentation, de gestion des risques et d’évaluation de conformité.
Ce risque concerne notamment les assistants internes réentraînés sur des données du groupe, les copilotes développés sous une marque maison et les systèmes dont la finalité est modifiée par rapport à la documentation de l’éditeur.
Les outils de recrutement, de tri de candidatures, d’évaluation des salariés ou d’accès à certaines opportunités professionnelles doivent faire l’objet d’un examen attentif. La Commission européenne cite les outils utilisés pour l’emploi, la gestion des travailleurs et l’accès au travail indépendant parmi les cas d’usage à analyser. La présentation officielle de la législation sur l’IA fournit un rappel des catégories de risque et des usages concernés.
Livrable : une grille de qualification à deux entrées, un registre des décisions de classement et un plan de remédiation pour les usages sensibles.
Responsable : conformité ou juridique, avec la DSI et les métiers.
Anti-pattern : classer un outil uniquement à partir de son nom commercial. Le risque dépend de la finalité et du contexte d’utilisation, pas de l’étiquette « assistant », « scoring » ou « copilote ».
Chantier 4 : créer un AI Registry exploitable
L’AI Registry interne n’est pas un simple tableau de suivi. Il doit devenir le point d’accès aux informations qui permettent de comprendre, contrôler et auditer les systèmes IA de l’organisation.
Pour chaque système, le registre doit pointer vers la documentation fournisseur, le contrat, l’analyse d’impact, la qualification de risque, les décisions de validation, les personnes responsables, les résultats de tests, les incidents et les actions correctives. Il doit être relié aux processus existants de gestion des actifs, des fournisseurs, des risques et des changements.
Il faut distinguer ce registre interne de la base de données européenne prévue par l’AI Act. Les obligations d’enregistrement varient selon le type de système, le rôle de l’organisation et le secteur concerné. Le registre interne répond à une question de pilotage : quels systèmes IA utilisons-nous, pour quelle finalité, avec quelles données et sous quelle responsabilité ?
Pour compléter les définitions et les catégories de risque, consultez aussi notre guide général sur l’AI Act.
Livrable : un registre interne des systèmes IA, relié aux documents de conformité et aux preuves de contrôle.
Responsable : DSI ou responsable de la gouvernance IA.
Anti-pattern : maintenir un registre séparé du référentiel d’actifs, des achats et des changements. Il devient obsolète dès que les outils, fournisseurs ou propriétaires évoluent.
Chantier 5 : construire les dossiers de conformité des systèmes à haut risque
Les systèmes à haut risque doivent être traités comme des chantiers de conformité à part entière. Le dossier doit réunir les éléments qui permettent de comprendre la finalité du système, ses limites, ses conditions d’utilisation et les contrôles associés.
Il doit notamment préciser l’usage prévu par le fournisseur, les données mobilisées, les modalités de supervision, les journaux disponibles, les règles d’intervention humaine, les procédures d’incident et les informations nécessaires à l’utilisateur professionnel.
Exemple métier : un outil de scoring de candidatures
Une DRH utilise un outil qui classe les CV selon des critères paramétrés par l’éditeur. Le fournisseur ne suffit pas à lui seul à sécuriser le dispositif. L’entreprise doit identifier le propriétaire du système, documenter la place du score dans la décision, vérifier qu’un recruteur peut contester ou corriger le résultat, organiser la traçabilité et conserver les informations utiles sur le fonctionnement de l’outil.
La supervision humaine doit être concrète. La personne désignée doit comprendre le système, connaître ses limites, disposer des informations nécessaires et avoir le pouvoir de demander une vérification, de corriger un résultat ou de suspendre l’utilisation de l’outil.
Livrable : un dossier de conformité par système à haut risque, accompagné d’une liste des éléments manquants et d’un plan de remédiation.
Responsable : propriétaire du système, sous pilotage DSI ou conformité.
Anti-pattern : considérer que le dossier fournisseur suffit. Le déployeur doit aussi documenter son propre usage, ses équipes, ses contrôles et ses décisions.
Chantier 6 : distinguer AIPD et analyse d’impact sur les droits fondamentaux
L’AI Act ne remplace pas le RGPD. Les deux cadres doivent être examinés ensemble lorsqu’un système IA traite des données personnelles, mais ils ne créent pas les mêmes livrables.
L’AIPD, ou analyse d’impact relative à la protection des données, relève de l’article 35 du RGPD. Elle s’applique lorsqu’un traitement est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes concernées. La CNIL présente les conditions et la méthode de l’AIPD et rappelle son rôle dans la construction d’un traitement conforme au RGPD.
L’analyse d’impact sur les droits fondamentaux, prévue par l’article 27 de l’AI Act, ne concerne pas tous les déployeurs privés. Son périmètre dépend notamment du statut de l’organisme, du service fourni et du système concerné. Une AIPD peut donc être nécessaire alors qu’une analyse d’impact au titre de l’article 27 ne l’est pas automatiquement.
Les deux analyses peuvent être coordonnées lorsque leurs périmètres se recoupent, mais elles doivent rester identifiées séparément. La CNIL détaille aussi les situations dans lesquelles une analyse d’impact doit être envisagée pour un système d’IA.
Livrable : une AIPD lorsque le RGPD l’exige, une analyse d’impact sur les droits fondamentaux lorsque l’article 27 s’applique, une matrice des risques liés aux droits fondamentaux et un plan de contrôle des biais.
Responsable : DPO pour l’AIPD, conformité ou juridique pour le cadrage AI Act, avec les équipes métiers et data.
Anti-pattern : produire une analyse générique appelée « analyse d’impact IA » sans préciser le texte applicable, le redevable, les personnes concernées et les mesures de réduction des risques.
Chantier 7 : organiser la supervision humaine, la traçabilité et les incidents
La supervision humaine ne peut pas se limiter à la présence théorique d’un utilisateur dans le processus. La personne chargée de la supervision doit comprendre le système, connaître ses limites et disposer de l’autorité nécessaire pour corriger, suspendre ou arrêter son utilisation.
Prenons le cas d’une IA de détection de fraude. Si le système bloque automatiquement une transaction, l’organisation doit déterminer qui peut examiner le signal, dans quel délai, avec quelles informations et selon quelle procédure de recours. Elle doit aussi surveiller les faux positifs, les biais par population et les évolutions de performance.
Le dispositif doit préciser les événements à surveiller, les seuils d’alerte, les règles d’escalade et les conditions de conservation des logs. Les journaux doivent être accessibles aux personnes qui contrôlent le système, dans le respect des règles de sécurité, de confidentialité et de minimisation des données.
Livrable : une procédure de supervision humaine, un journal des incidents, des règles de conservation des logs et un tableau de suivi des alertes.
Responsable : DSI ou responsable du système, avec le métier concerné.
Anti-pattern : désigner un superviseur sans temps alloué, sans accès aux données du système et sans pouvoir réel de suspension.
Chantier 8 : mettre en conformité la transparence et l’information des utilisateurs
Les obligations de transparence nécessitent une revue des interfaces, des parcours utilisateurs et des contenus générés. Un chatbot de service client constitue un bon exemple : l’utilisateur doit savoir qu’il échange avec une IA lorsque l’obligation s’applique, et savoir comment obtenir l’intervention d’un interlocuteur humain lorsque cela est nécessaire.
Le chantier doit examiner les chatbots, assistants conversationnels, outils de génération de texte, fonctions de synthèse, contenus visuels et interfaces de recommandation. La mention à afficher, son emplacement et le moment où elle apparaît doivent être documentés.
La transparence ne se résume pas à une phrase générale dans les conditions d’utilisation. Elle doit être vérifiée dans le parcours concret de la personne : écran de connexion, fenêtre de conversation, résultat généré, publication externe ou décision influencée par le système.
Les lignes directrices de la Commission européenne précisent le périmètre de l’article 50. La FAQ officielle sur les obligations de transparence apporte des précisions sur les interactions directes, les contenus générés et les obligations respectives des fournisseurs et des déployeurs.
Livrable : une matrice des obligations de transparence, des mentions validées, des règles de signalement des contenus et une procédure de mise à jour.
Responsable : produit, DSI ou direction juridique selon le système.
Anti-pattern : ajouter une mention générale dans les conditions d’utilisation, sans vérifier le parcours concret dans lequel l’utilisateur interagit avec le système.
Chantier 9 : déployer une AI literacy et un réseau d’AI Champions
La formation doit être adaptée au rôle de chacun. Un utilisateur métier n’a pas besoin du même niveau d’information qu’un développeur, un acheteur logiciel, un responsable RH ou une personne chargée de superviser un système à haut risque.
Le parcours doit expliquer les usages autorisés, les données qui ne doivent pas être transmises à un outil, les règles de validation, les modalités de signalement d’un incident et les limites des résultats générés. Pour les populations exposées, la formation doit aussi couvrir les biais, la supervision humaine, la traçabilité et les droits des personnes concernées.
Les AI Champions peuvent servir de relais dans les directions et les pays. Ils font remonter les usages, orientent les équipes vers le processus de validation, diffusent les règles et identifient les situations nécessitant l’intervention de la DSI, du juridique, du DPO ou des Achats. Ils ne remplacent pas ces fonctions.
Livrable : un parcours de formation par population, une matrice des compétences et un réseau d’AI Champions.
Responsable : DRH ou direction de la transformation.
Anti-pattern : créer un réseau d’AI Champions sans temps alloué, sans mandat managérial et sans canal de remontée des usages.
Chantier 10 : sécuriser les fournisseurs, les Achats et les contrats IA
Les équipes Achats doivent intégrer l’AI Act dans le référencement, l’appel d’offres, la négociation, le renouvellement et la sortie des fournisseurs. Le contrat doit permettre de savoir qui fournit la documentation, qui signale les incidents, qui contrôle les changements de modèle et qui assume chaque obligation réglementaire.
Prenons le cas d’un outil de sourcing augmenté par IA. La Direction Achats doit vérifier ce que recouvre exactement le score produit par l’outil, les données mobilisées, les conditions d’accès aux explications, la possibilité de contester une recommandation et les modalités de contrôle du fournisseur.
Le questionnaire fournisseur doit porter sur la classification du système, sa finalité, les données utilisées, les sous-traitants, la localisation des traitements, les mesures de sécurité, les logs, la supervision humaine et la procédure de notification des incidents.
Pour prolonger ce chantier, consultez l’article Achats augmentés : comment l’IA réinvente le cycle Source-to-Pay ?, qui présente les enjeux de l’IA dans les achats de prestations intellectuelles.
Livrable : un questionnaire fournisseur IA, des clauses contractuelles, une grille de due diligence et une procédure de revue avant référencement ou renouvellement.
Responsable : Direction Achats, avec le juridique, la DSI, la sécurité et le métier utilisateur.
Anti-pattern : demander une attestation générale de conformité sans obtenir la documentation du système, la répartition des responsabilités et les conditions de notification des incidents.
Comment prioriser les actions sur 30, 60 et 90 jours ?
Le calendrier 30/60/90 jours ne remplace pas les échéances réglementaires. Il sert à donner un ordre de marche, à rendre les arbitrages visibles et à éviter que les systèmes les plus sensibles restent sans propriétaire ni dossier de conformité.
| Période | Actions prioritaires | Livrables attendus | Fonctions impliquées |
|---|---|---|---|
Jours 1 à 30 | Désigner un sponsor, installer la gouvernance, réaliser un inventaire initial, repérer les pratiques interdites et auditer les interfaces concernées par la transparence | Charte de gouvernance, première cartographie, liste des usages prioritaires et décisions initiales | DSI, métiers, juridique, conformité, Achats, DRH, DPO |
Jours 31 à 60 | Formaliser la classification, construire l’AI Registry, interroger les fournisseurs et lancer les analyses d’impact prioritaires | Registre qualifié, questionnaires fournisseurs, première liste de remédiations et responsables associés | DSI, conformité, juridique, DPO, Achats, data |
Jours 61 à 90 | Préparer les dossiers haut risque, formaliser la supervision humaine, définir la conservation des logs, structurer les incidents et former les équipes exposées | Dossiers de conformité, procédures de contrôle, tableau de pilotage et parcours de formation | DSI, métiers, DRH, conformité, sécurité, Achats |
Une DSI peut commencer par les systèmes qui influencent une décision concernant une personne, ceux qui interagissent directement avec le public et ceux qui reposent sur des fournisseurs dont la documentation est incomplète. Cette priorisation permet de traiter d’abord les situations où les conséquences opérationnelles, sociales ou réglementaires sont les plus fortes.
Les trois repères à ne pas confondre
L’AI Office européen
L’AI Office est une structure de la Commission européenne. Il intervient notamment sur les modèles d’IA à usage général et certains systèmes associés. Les autorités nationales compétentes contrôlent les autres systèmes selon leur périmètre.
Une entreprise n’a donc pas à créer un service interne appelé AI Office pour être conforme. Elle doit en revanche organiser une veille réglementaire, suivre les lignes directrices et conserver les décisions qui expliquent comment elle applique le règlement.
L’AI Registry interne
L’AI Registry est le registre de pilotage de l’organisation. Il rassemble les systèmes, leurs responsables, leur niveau de risque, les contrôles réalisés et les pièces disponibles. Il répond à une question simple : quels systèmes IA utilisons-nous, pour quelle finalité, avec quelles données et sous quelle responsabilité ?
Les AI Champions
Les AI Champions sont des relais internes. Ils rendent la gouvernance accessible aux équipes qui utilisent réellement l’IA et facilitent la remontée des usages non déclarés. Ils ne se substituent ni au DPO, ni au responsable conformité, ni au propriétaire du système.
Passer du plan à l’exécution
Les dix chantiers mobilisent des compétences qui ne sont pas toujours disponibles simultanément en interne : gouvernance IA, conformité réglementaire, data, cybersécurité, achats et transformation.
Si votre entreprise doit cadrer ou exécuter une feuille de route AI Act, vous pouvez échanger avec LittleBig Connection sur vos besoins en expertises. L’objectif est d’identifier les compétences nécessaires au regard des systèmes, des pays, des fournisseurs et des fonctions concernées.
Ce qu’il faut retenir
Devenir conforme à l’AI Act ne consiste pas à rédiger une politique générale puis à la déposer dans un espace documentaire. La démarche doit produire des preuves, attribuer des responsabilités et créer des contrôles utilisables par les équipes.
Les dix chantiers prioritaires sont la gouvernance, la cartographie, la classification des risques, l’AI Registry, les dossiers haut risque, les analyses d’impact, la supervision, la transparence, la formation et l’encadrement des fournisseurs. Leur mise en œuvre peut commencer immédiatement, même lorsque l’échéance applicable à certains systèmes est fixée à 2027 ou 2028.
Les règles applicables peuvent varier selon le rôle de l’organisation, le type de système, le secteur et l’usage réalisé. Il est préférable de vérifier chaque situation avec les équipes juridiques, conformité, DSI, RH, Achats ou protection des données concernées.


