AI Act : pourquoi les DSI ne doivent plus parier sur un report

Le report des obligations de l’AI Act n’est pas acquis. Les sanctions sont prévues, même si le dispositif français de contrôle reste encore en construction. Pour les DSI, l’urgence n’est donc pas d’attendre Bruxelles, mais de reprendre la main : retrouver les usages d’IA déjà présents dans le SI, qualifier les risques, documenter les contrôles et organiser la preuve.

Il y a des étés où les DSI aimeraient que Bruxelles regarde ailleurs. Celui qui arrive ne s’annonce pas vraiment comme une parenthèse. À peine les équipes ont-elles commencé à digérer la réforme de la facture électronique, avec ses impacts sur les ERP, les flux achats, la comptabilité, les plateformes partenaires et les référentiels fournisseurs, qu’un autre chantier vient frapper à la porte : l’AI Act.

Ce n’est d’ailleurs pas le premier texte à venir se glisser dans l’agenda des directions numériques. IT for Business l’a déjà documenté : la conformité du SI devient un empilement continu – RGPD, NIS2, DORA, CRA, CSRD, facture électronique, AI Act – au point que la question n’est plus seulement de respecter les textes, mais de construire une organisation capable d’absorber leur rythme. À ce titre, l’AI Act arrive dans une pile réglementaire déjà haute, où chaque nouvelle obligation demande à la DSI de traduire le droit en architecture, en processus et en preuves.

La tentation était grande, ces derniers mois, de compter sur un répit. Le Digital Omnibus, paquet européen de simplification numérique, devait alléger et repousser certaines obligations liées aux systèmes d’IA à haut risque. Mais le 28 avril dernier, les négociations entre le Conseil et le Parlement européen ont échoué. Le report n’est pas mort. Il n’est simplement pas voté. Et pour une DSI, cette nuance change tout.

Car un calendrier politique n’est pas un plan projet. Tant qu’un report n’est pas adopté, le 2 août 2026 reste la date à piloter. Autrement dit : les entreprises qui attendaient un délai doivent désormais considérer qu’elles n’en ont plus.

L’AI Act n’est pas un dossier juridique de plus

Le piège serait de ranger l’AI Act à côté des textes que l’entreprise confie au juridique, au DPO ou à la conformité. Ce serait rassurant. Ce serait aussi faux.

Le RGPD avait appris aux organisations à se demander où étaient les données personnelles, qui les traitait, pourquoi, pendant combien de temps et sur quelle base légale. L’AI Act impose une question plus dérangeante : où l’IA agit-elle déjà dans l’entreprise ?

Pas seulement où elle est déclarée. Pas seulement où elle a été présentée au Comex avec une jolie feuille de route “IA générative”. Mais où elle trie, résume, recommande, classe, priorise, évalue, détecte, automatise ou influence une décision.

C’est là que le texte devient un sujet de DSI. Parce que l’IA n’est pas seulement dans les laboratoires data. Elle est dans les suites bureautiques, les SIRH, les CRM, les outils de relation client, les plateformes de cybersécurité, les solutions de support, les logiciels de scoring, les outils de BI, les agents conversationnels, les moteurs de recommandation, les copilotes métiers et parfois dans des produits industriels déjà certifiés.

Dès février 2025, IT for Business rappelait déjà que l’AI Act repose d’abord sur les usages et qu’il doit être intégré dans les projets de la DSI plutôt que traité comme une conformité tardive. C’est précisément ce que l’échec du report vient confirmer : il ne s’agit pas d’ajouter un vernis juridique à des projets déjà déployés, mais de faire entrer la conformité dans le cycle de vie même des systèmes d’IA.

Première scène : le SIRH qui trie les candidats

Prenons un cas simple. Une direction RH utilise un outil de recrutement qui aide à présélectionner des candidatures. Le fournisseur explique qu’il ne “décide” pas. Il “assiste”. Il classe des CV, repère des compétences, rapproche des profils d’une fiche de poste, suggère une short-list.

Pour le métier, c’est un gain de temps. Pour la DSI, c’est un premier signal d’alerte. Qui a configuré l’outil ? Quelles données sont utilisées ? Le modèle a-t-il été entraîné sur des historiques de recrutement susceptibles de reproduire des biais ? L’humain garde-t-il réellement la main ? Les critères de classement sont-ils compréhensibles ? Les logs existent-ils ? Le fournisseur documente-t-il ses contrôles ? Le contrat dit-il quelque chose des obligations AI Act ?

L’AI Act devient alors très concret. Il ne s’agit pas de savoir si l’entreprise “fait de l’IA”. Elle en fait déjà, parce qu’un outil métier en contient. Et si l’usage touche l’emploi, l’évaluation ou la gestion des personnes, la zone devient sensible.

Deuxième scène : le copilote qui résume les réunions

Autre exemple, plus banal encore. Une entreprise déploie un copilote bureautique pour résumer des réunions, produire des comptes rendus, extraire des actions, classer des documents ou répondre à partir d’un corpus interne.

Le risque n’est pas forcément “haut risque” au sens de l’AI Act. Mais il pose déjà des questions structurantes : quelles données le copilote peut-il lire ? Les droits d’accès sont-ils propres ? Les documents confidentiels sont-ils exposés à des personnes qui n’y avaient pas accès auparavant ? Les résumés peuvent-ils devenir des éléments de décision ? Les utilisateurs savent-ils quand ils interagissent avec un système d’IA ? Les traces sont-elles conservées ? Les erreurs sont-elles détectables ?

Le DSI découvre alors que la conformité AI Act croise la gouvernance documentaire, l’IAM, la sécurité, la classification des données, le RGPD, la politique d’archivage et la formation des utilisateurs. Ce n’est plus seulement un sujet IA. C’est un sujet SI.

Troisième scène : la cybersécurité qui recommande une action

Un RSSI utilise déjà des outils capables de corréler des alertes, prioriser des incidents, recommander des réponses, voire automatiser certaines actions. Dans un contexte cyber, l’IA peut être précieuse : elle aide à réduire le bruit, accélérer l’analyse, orienter les équipes.

Mais là encore, la question n’est pas seulement technique. Si un système recommande d’isoler une machine, de bloquer un compte, de qualifier un comportement comme suspect ou de déclencher une réponse automatisée, l’entreprise doit comprendre le niveau de supervision humaine, le périmètre d’action, la robustesse du système et la traçabilité des décisions.

IT for Business l’a déjà souligné : pour les systèmes à haut risque, l’AI Act introduit des exigences continues d’exactitude, de robustesse et de cybersécurité, plus proches d’une démarche DevSecOps que d’une certification ponctuelle. La preuve ne sera donc pas seulement juridique. Elle sera aussi technique, opérationnelle et maintenue dans le temps.

Pourquoi le report a capoté

Le report n’a pas échoué parce que personne ne voulait donner du temps aux entreprises. Le sujet est plus subtil.

Le point dur porte sur les systèmes d’IA intégrés dans des produits déjà soumis à des réglementations sectorielles : machines industrielles, dispositifs médicaux, équipements radioélectriques, produits de sécurité, infrastructures critiques. Les industriels craignent une double conformité : une première au titre des règles sectorielles existantes, une seconde au titre de l’AI Act. Le Parlement européen, lui, redoute qu’en ouvrant trop largement cette porte, on vide une partie du règlement de sa portée.

En clair, deux visions s’affrontent. D’un côté, celle des industriels qui disent : “Nos produits sont déjà contrôlés.” De l’autre, celle des régulateurs qui répondent : “Quand l’IA change le comportement du produit ou influence la décision, le risque change aussi.”

Pour les DSI, cette querelle institutionnelle a une conséquence immédiate : elle maintient l’incertitude. Et l’incertitude n’est pas un plan d’action.

Qui sanctionnera ? La question reste inconfortable

Autre différence avec le RGPD : la France ne s’oriente pas vers un modèle aussi lisible qu’un régulateur unique. Le RGPD avait son visage : la CNIL. L’AI Act aura plutôt une cartographie.

La DGCCRF doit jouer un rôle de coordination des autorités de surveillance du marché et de point de contact unique. La DGE représente la France dans la gouvernance européenne. La CNIL aura un rôle majeur, notamment sur les usages touchant les données personnelles, les droits fondamentaux, l’emploi, la biométrie ou certains usages sensibles. D’autres autorités sectorielles interviendront selon les domaines : ACPR (L’Autorité de contrôle prudentiel et de résolution) pour certains usages financiers, ANSM (L’Agence nationale de sécurité du médicament et des produits de santé) pour les dispositifs médicaux, ANFR (L’Agence nationale des fréquences) pour certains équipements, Arcom pour d’autres périmètres, sans oublier les autorités propres aux secteurs critiques.

La formule “personne ne sanctionne aujourd’hui” dit quelque chose du trouble actuel. Mais la version exacte serait plutôt : les sanctions sont écrites, le gendarme français est encore en cours d’assemblage.

Ce flou ne protège pas les entreprises. Il complique leur préparation. Car le jour venu, il ne suffira pas de savoir que l’AI Act s’applique. Il faudra savoir quelle autorité regarde quel usage.

---

Étape 1 : faire l’inventaire, mais le vrai

La première action d’une DSI n’est pas de lancer un grand programme théorique. C’est de dresser un inventaire.

Mais pas un inventaire limité aux projets IA déclarés. Il faut ouvrir les armoires : SaaS, SIRH, CRM, outils marketing, relation client, support, finance, achats, cybersécurité, data science, copilotes, agents, automatisations internes, solutions métiers, outils développés localement.

La bonne question à poser aux métiers n’est pas : “Utilisez-vous de l’intelligence artificielle ?” Beaucoup répondront non, sincèrement. La bonne question est : “Votre outil classe-t-il, recommande-t-il, résume-t-il, évalue-t-il, prédit-il, priorise-t-il ou automatise-t-il quelque chose ?”

C’est là que les réponses commencent.

Cette logique rejoint les travaux déjà relayés par IT for Business autour de la gouvernance de l’IA. Le Cigref y insiste : la gouvernance ne doit pas être un modèle plaqué sur l’organisation, mais un outil de conformité intégré aux instances existantes, avec un circuit décisionnel clair, des responsabilités tracées et une vision du cycle de vie des systèmes d’IA. Autrement dit, l’inventaire n’est pas une photographie. C’est le début d’une gouvernance vivante.

Dans cette phase, les outils de conformité peuvent aider. Des acteurs comme Adequacy, venus du monde RGPD, poussent désormais une logique de registre des systèmes d’IA : recenser les cas d’usage, qualifier les modèles, évaluer les risques, constituer des dossiers de conformité. L’intérêt n’est pas seulement logiciel. Il est méthodologique : passer d’un tableur dispersé à une mémoire organisée des systèmes d’IA.

Étape 2 : qualifier les usages sensibles

Une fois l’inventaire établi, il faut trier. Tous les usages ne méritent pas la même énergie.

Un chatbot interne qui aide à retrouver une procédure n’a pas le même niveau d’exposition qu’un outil qui classe des candidats, attribue un score de risque à un client, aide à décider d’un crédit, oriente un diagnostic médical, pilote une infrastructure critique ou recommande une action dans un environnement industriel.

Les DSI doivent donc prioriser les zones sensibles : RH, formation, finance, assurance, santé, services essentiels, infrastructures critiques, cybersécurité, biométrie, relation usager, produits régulés.

La conformité AI Act commence par une hiérarchie. Il ne s’agit pas de tout traiter avec la même intensité. Il s’agit de savoir où l’entreprise peut faire mal, discriminer, exposer, décider à tort ou ne plus pouvoir expliquer.

Étape 3 : comprendre le rôle de l’entreprise

C’est l’une des difficultés les plus sous-estimées. Une entreprise peut croire qu’elle n’est qu’utilisatrice d’un système. Mais si elle le modifie, l’intègre dans un produit, le réentraîne avec ses propres données, le commercialise sous son nom ou l’utilise dans un contexte très différent de celui prévu par le fournisseur, son rôle peut changer.

Le DSI doit donc poser une question simple, mais décisive : sommes-nous déployeur, fournisseur, intégrateur, importateur, distributeur ou simple utilisateur ?

La réponse conditionne les obligations. Elle conditionne aussi les clauses contractuelles à négocier avec les éditeurs.

Étape 4 : documenter ce qui était implicite

La conformité AI Act ne se résumera pas à une déclaration. Elle exigera de la preuve.

Qui a validé l’usage ? Sur quelle base ? Quels tests ont été réalisés ? Quelles données ont été utilisées ? Quels biais ont été recherchés ? Quel humain supervise ? Que se passe-t-il en cas d’erreur ? Quels logs sont disponibles ? Comment le système est-il mis à jour ? Quelles garanties fournit l’éditeur ? Que dit le contrat ? Qui peut arrêter le système ?

Beaucoup d’entreprises ont déjà une partie de ces réponses. Mais elles sont dispersées. Dans un ticket Jira, une annexe contractuelle, une note du DPO, un document sécurité, un fichier Excel, un canal Teams, une présentation PowerPoint.

Le chantier consiste à relier ces traces pour produire une preuve lisible.

Étape 5 : reprendre les contrats SaaS

C’est probablement le point le plus concret pour les prochains mois.

Les DSI doivent demander aux fournisseurs une description claire des fonctions IA intégrées à leurs solutions. Quelles données sont utilisées ? Les données client servent-elles à améliorer le modèle ? Quels logs sont accessibles ? Quelles garanties de sécurité sont données ? Quels mécanismes de supervision humaine existent ? Quel niveau de documentation est disponible ? Que se passe-t-il en cas de mise à jour fonctionnelle ? L’éditeur s’engage-t-il à notifier l’introduction d’une nouvelle fonction IA ?

Dans le monde SaaS, l’IA arrive souvent par mise à jour. C’est pratique pour l’innovation. C’est dangereux pour la conformité. Une fonctionnalité activée par défaut peut transformer un usage ordinaire en usage sensible.

Étape 6 : former les métiers sans les assommer

La conformité AI Act ne réussira pas par circulaire interne.

Les métiers ne rempliront pas correctement un registre s’ils ne comprennent pas ce qu’on leur demande. Il faut leur parler dans leur langue. Aux RH, on parlera recrutement, évaluation, mobilité, formation. À la finance, scoring, fraude, solvabilité, prévision. À la relation client, priorisation, recommandation, personnalisation. À la cybersécurité, détection, réponse, automatisation. Aux achats, clauses fournisseurs et dépendance SaaS.

La pédagogie doit être simple : l’AI Act ne bloque pas l’IA. Il oblige à savoir ce qu’elle fait.

Ce point rejoint une autre bascule déjà observée : avec l’IA, la gouvernance de la donnée cesse d’être un sujet de support. L’IA n’est pas une manière de contourner la gouvernance, mais une raison supplémentaire de l’outiller, sous contrôle humain et dans un cadre sécurisé.

Étape 7 : installer une gouvernance qui décide vraiment

Le comité IA ne doit pas devenir une chambre d’enregistrement. Il doit pouvoir dire oui, non, pas encore, ou oui sous conditions.

Cela suppose une gouvernance courte, avec des rôles clairs : DSI, RSSI, DPO, juridique, achats, métiers, conformité, risk management. Dans les secteurs régulés, il faudra ajouter les directions métier concernées par l’ACPR, l’ANSM ou d’autres autorités.

Ce glissement explique aussi pourquoi le DPO revient dans le jeu, sans pouvoir porter seul le sujet. Avec l’AI Act et le Digital Omnibus, le DPO devient un pivot stratégique, mais il doit travailler au contact du CTO, de la DSI, des métiers et de la conformité. La gouvernance AI Act ne peut donc pas être une délégation au juridique. Elle doit devenir un dispositif collectif.

Le bon comité n’est pas celui qui produit une charte. C’est celui qui sait prioriser les risques, documenter ses arbitrages et suivre l’évolution des systèmes dans le temps.

Les partenaires à regarder

Le marché de l’accompagnement se structure rapidement. Il ne faut pas en faire une liste promotionnelle, mais montrer que les DSI ne sont pas seules.

Le Cigref et Numeum ont déjà publié des guides utiles pour comprendre l’AI Act côté grandes entreprises. France Digitale, Wavestone et Gide ont produit un guide plus orienté start-up et acteurs innovants. Les cabinets d’avocats (August Debouzy, DLA Piper, Racine, Bird & Bird, Gide) interviennent sur les responsabilités, les contrats, la propriété intellectuelle, les clauses fournisseurs.

Les grands cabinets (Wavestone, Capgemini, KPMG, Deloitte, Grant Thornton) se positionnent sur la cartographie, la gouvernance, le contrôle interne et l’articulation avec les autres réglementations. Les spécialistes RGPD et conformité outillée, comme Adequacy, DPO Consulting ou ComplEthics4IA, proposent une approche plus proche du registre, du dossier de preuve et de la gouvernance opérationnelle. Des acteurs plus techniques, enfin, travaillent sur l’audit, la traçabilité, la cybersécurité, les logs ou la conservation de la preuve.

Mais le choix du partenaire doit dépendre du problème. Une entreprise qui ne sait pas où est son IA a besoin d’un inventaire. Une entreprise qui connaît ses usages sensibles a besoin de qualification juridique. Une entreprise très SaaS doit revoir ses contrats. Une entreprise industrielle doit articuler AI Act et réglementation produit. Une banque ou un assureur doit croiser le sujet avec l’ACPR, DORA et ses modèles de risque.

Le plan d’action en trois mois

Premier mois : retrouver l’IA. Inventaire des outils, des projets, des fonctions SaaS, des copilotes, des agents, des modèles internes et des automatisations.

Deuxième mois : qualifier les risques. Classement des usages, identification des zones sensibles, analyse des rôles, premières priorités sur RH, finance, santé, assurance, infrastructures, cyber.

Troisième mois : documenter et sécuriser. Dossiers de conformité prioritaires, clauses fournisseurs, logs, supervision humaine, preuves, arbitrages de gouvernance, formation des métiers.

Ce plan ne rendra pas l’entreprise totalement conforme. Mais il lui évitera le pire : découvrir trop tard qu’elle n’a même pas commencé par savoir de quoi elle parle.

Ce mouvement s’inscrit dans une transformation plus large du métier de DSI. Comme nous l’écrivions déjà dans notre projection 2026, le DSI n’est plus seulement le gardien du SI : il devient le chef d’orchestre de l’IA dans l’entreprise, entre choix de modèles, données, contrôle des risques, conformité et passage à l’échelle. L’AI Act ne fait qu’accélérer cette mutation.

Ne comptez plus sur un report. Et ne comptez pas davantage sur l’absence actuelle d’un gendarme unique pour différer les travaux. Les sanctions sont dans le règlement ; la France assemble encore son dispositif de contrôle. Entre les deux, les DSI ont une fenêtre étroite pour reprendre la main.

L’AI Act ne demande pas seulement de surveiller l’IA spectaculaire, celle des démonstrations et des annonces. Il demande de retrouver l’IA ordinaire, celle qui s’est glissée dans les logiciels, les processus et les décisions. La plus dangereuse n’est peut-être pas celle qui parle. C’est celle que personne n’a encore recensée.

---

Sources externes

Reuters – EU countries, lawmakers fail to reach deal on watered-down AI rules
Lire la source Reuters

Bird & Bird – Digital Omnibus on AI: Trilogue stalls ahead of the AI Act deadline
Lire l’analyse de Bird & Bird

Ministère de l’Économie – Mise en œuvre du règlement IA
Lire la page du ministère de l’Économie

DGE / DGCCRF – Projet de désignation des autorités nationales chargées de l’application du règlement IA
Lire le communiqué DGE / DGCCRF

CNIL – Développement des systèmes d’IA : les recommandations de la CNIL pour respecter le RGPD
Lire les recommandations de la CNIL

Cigref – Guide de mise en œuvre de l’AI Act
Lire le guide du Cigref

Adequacy – Registre SIA AI Act
Lire la présentation du registre SIA d’Adequacy