AI Act européen. Ce qui change pour les DSI françaises.
L'AI Act est entré en application progressive. Pour les DSI françaises, il introduit des obligations concrètes qui dépassent la simple conformité documentaire. Cet article fait le point sur ce qui change opérationnellement, dans nos échanges avec les directions informatiques de grandes entreprises basées en France.
Les catégories de risque et ce qu'elles déclenchent.
La logique de l'AI Act repose sur une classification par niveau de risque, et cette classification est l'exercice de cadrage qui structure tout le reste. Dans nos discussions avec les DSI françaises, c'est aussi l'étape qui révèle le plus rapidement la maturité réelle d'une organisation sur le sujet. Une DSI qui hésite sur le périmètre d'un système IA, sur sa finalité ou sur ses utilisateurs aura beaucoup de mal à le classer correctement, et donc à dimensionner ses obligations.
Quatre niveaux structurent le texte. Les pratiques inacceptables, qui sont tout simplement interdites, couvrent par exemple la notation sociale, la manipulation cognitive ou certaines formes d'identification biométrique en temps réel dans l'espace public. Les systèmes à haut risque, qui concentrent la majeure partie des obligations, recouvrent l'éducation, l'emploi, l'accès aux services essentiels, l'application de la loi, la gestion de la migration et le contrôle des frontières, ainsi que certains usages dans les secteurs régulés. Les systèmes à risque limité sont soumis à des obligations de transparence, notamment lorsqu'ils interagissent directement avec des personnes. Les systèmes à risque minimal restent largement libres, sous réserve de bonnes pratiques.
L'exercice de classification se complique dès qu'un même système IA cumule plusieurs usages, dont certains relèvent du haut risque et d'autres non. Les directions informatiques que nous accompagnons sur ce sujet adoptent généralement une approche de classification par cas d'usage plutôt que par système, ce qui donne une lecture plus fine et plus défendable face à un régulateur.
Documentation, gouvernance et évaluation continue.
Pour les systèmes à haut risque, le texte impose un triptyque qui structure le travail de la DSI sur le moyen terme. Une documentation technique complète, une gouvernance opérationnelle avec des rôles clairs, et une évaluation continue tout au long du cycle de vie. Chacun de ces volets demande une discipline qui n'existe pas spontanément dans la plupart des organisations.
La documentation comme dette à rembourser.
La documentation technique requise couvre la description du système, les jeux de données d'entraînement, les choix de conception, les performances attendues, les limites connues et les mesures de surveillance humaine. Dans nos échanges avec des DSI qui ont commencé à industrialiser leurs systèmes IA il y a deux ou trois ans, le constat est sans appel : la documentation accumulée n'est jamais à la hauteur des exigences du texte. C'est une dette technique à rembourser avant l'échéance, et il est plus économique de commencer maintenant que de tout rattraper sous pression.
Une gouvernance qui sort du périmètre de la DSI.
La gouvernance des systèmes IA ne peut pas reposer uniquement sur la DSI. Elle implique le métier qui exploite le système, la fonction conformité, le délégué à la protection des données, et de plus en plus une fonction dédiée IA dans les organisations matures. Le piège que nous voyons souvent dans les conseils de direction informatique est de créer un comité supplémentaire sans clarifier les droits de décision. La gouvernance qui fonctionne, dans notre expérience, est celle qui rattache chaque système IA à un propriétaire fonctionnel nommé, avec un escalade clair vers une instance de niveau direction générale pour les arbitrages structurants.
L'évaluation comme habitude, pas comme événement.
L'évaluation continue est l'exigence qui change le plus le travail quotidien des équipes IA. Le texte demande une surveillance après mise sur le marché, c'est-à-dire la capacité à détecter une dérive de performance, à analyser un incident et à corriger le système dans des délais raisonnables. Cela suppose une instrumentation, des indicateurs, des seuils d'alerte et une équipe qui regarde réellement les tableaux de bord. Les DSI qui industrialisent leur observabilité IA dès le pilote sont prêtes pour cette exigence. Celles qui traitent l'observabilité comme un sujet de production lointain devront rebrousser chemin.
Ce que les DSI doivent mettre en place dès maintenant.
Trois chantiers reviennent systématiquement dans nos discussions avec les directions informatiques que nous accompagnons. Ils peuvent être lancés en parallèle, sans attendre la finalisation de tous les actes délégués ou la jurisprudence des premières années d'application.
Un registre interne des systèmes IA.
Le registre est l'outil de base. Il recense tous les systèmes IA en production ou en phase pilote, avec leur classification de risque provisoire, leur finalité, le fournisseur du modèle, les données d'entraînement, le propriétaire fonctionnel et l'instance de gouvernance qui en répond. Dans les organisations que nous accompagnons, ce simple exercice fait apparaître un nombre de systèmes très supérieur à ce que la DSI pensait gérer, parce que les métiers ont déployé des outils SaaS embarquant des modèles sans toujours passer par la gouvernance centrale.
Une gouvernance avec droits de décision clairs.
Le comité IA n'est utile que s'il décide. Cela veut dire un président clairement identifié, une fréquence de réunion connue, des dossiers présentés avec une décision attendue, et un mécanisme d'escalade vers la direction générale pour les arbitrages structurants. Les comités qui se contentent de partager de l'information ne tiendront pas la pression réglementaire qui arrive.
Une discipline d'évaluation et de risque.
Pour chaque système classé à haut risque, une analyse d'impact doit être conduite avant déploiement et actualisée régulièrement. Cette analyse couvre les risques pour les droits fondamentaux, les mesures d'atténuation, les modalités de surveillance humaine et les indicateurs de performance. La méthodologie peut s'inspirer des analyses d'impact RGPD, mais elle doit être adaptée aux spécificités de l'IA, notamment sur la qualité des données et le risque de biais.
L'articulation AI Act, RGPD et NIS2.
L'AI Act ne remplace aucun texte existant. Il s'ajoute. Le RGPD continue de s'appliquer dès qu'un système IA traite des données personnelles, et l'AI Act renvoie d'ailleurs explicitement au RGPD sur de nombreux aspects. NIS2 reste applicable pour les entités essentielles et importantes sur leurs obligations de cybersécurité, qui couvrent par extension les systèmes IA qu'elles exploitent. Pour les secteurs régulés, banque, assurance, santé, énergie, les textes sectoriels gardent leur primauté sur leurs périmètres propres.
Cette superposition est un casse-tête pour les équipes conformité, mais elle est aussi une opportunité pour les DSI qui ont déjà construit des dispositifs solides sur le RGPD. La structure de gouvernance, les analyses d'impact, le registre des traitements, les mécanismes d'escalade sont en grande partie réutilisables. L'effort consiste à étendre ces dispositifs au périmètre IA, pas à les recréer de zéro. Les DSI qui partent d'une conformité RGPD avancée ont, selon notre expérience, environ douze à dix-huit mois d'avance sur celles qui partent d'une page blanche.
La conformité IA ne se construit pas dans un coin de l'organisation. Elle se construit en faisant évoluer les dispositifs existants, en clarifiant les rôles, et en industrialisant ce qui ne peut plus rester artisanal.
La conformité comme avantage opératoire.
Dans nos exchanges avec les directions informatiques de grandes entreprises françaises, une lecture revient souvent : la conformité IA bien menée raccourcit le temps entre un cas d'usage validé et sa mise en production. Les organisations qui ont industrialisé leurs contrôles, leur documentation, leur évaluation, ne perdent plus des semaines à chaque mise en service. La discipline réglementaire devient alors un avantage opératoire, parce qu'elle permet d'aller plus vite avec moins de risques.
Les DSI qui retardent ce travail prennent un pari coûteux. À mesure que les actes délégués se précisent, que les autorités de contrôle se mettent en place et que les premières sanctions tombent, le coût de la mise en conformité tardive grimpe vite. Si vos équipes hésitent encore sur la classification de vos systèmes IA, sur le périmètre de votre registre interne ou sur la gouvernance qui décide réellement, c'est probablement le bon moment pour ouvrir la conversation. Nos partenaires Consulting à Paris, Dubaï, Singapour et Bali sont disponibles via le formulaire de brief ci-dessous, et nous répondons sous un jour ouvré, avec le partner qui suivra le dossier plutôt qu'un commercial.
Questions fréquentes.
Quel est le calendrier d'application de l'AI Act ?
L'AI Act suit une application progressive. Les interdictions sur les pratiques inacceptables s'appliquent en premier, suivies des obligations sur les modèles d'IA à usage général, puis des règles complètes pour les systèmes à haut risque. Les DSI doivent travailler par paliers et anticiper plutôt que de tout traiter en bloc.
Quelles sanctions sont prévues ?
Les sanctions vont jusqu'à 35 millions d'euros ou 7% du chiffre d'affaires mondial pour les pratiques interdites, et jusqu'à 15 millions d'euros ou 3% pour les manquements aux obligations applicables aux systèmes à haut risque. L'échelle est calibrée pour qu'aucune direction générale ne traite le sujet comme un détail.
Comment l'AI Act s'articule-t-il avec les régulations sectorielles ?
L'AI Act se superpose aux textes sectoriels existants. Pour la banque, le DSP2 et le règlement DORA restent en vigueur. Pour la santé, le RGPD et la réglementation des dispositifs médicaux restent prioritaires sur leurs propres périmètres. L'AI Act ajoute une couche horizontale qui ne remplace rien et qui s'additionne.
L'IA générative est-elle couverte ?
Oui. Les modèles d'IA à usage général ont leurs propres obligations, notamment sur la transparence, la documentation technique et le respect du droit d'auteur. Les modèles à risque systémique ont des obligations renforcées sur l'évaluation et la maîtrise des risques.
Les modèles open source sont-ils concernés ?
Le texte prévoit des allègements pour les modèles libres, mais ces allègements ne tiennent pas dès que le modèle est mis sur le marché à titre commercial, monétisé ou intégré dans un système à haut risque. En pratique, beaucoup de déploiements en entreprise restent dans le périmètre complet.
Quel est le périmètre du registre des systèmes IA ?
Le registre interne doit couvrir tous les systèmes IA utilisés ou déployés par l'entreprise, avec leur classification de risque, leur finalité, leur fournisseur, leurs données d'entraînement et leur propriétaire fonctionnel. C'est l'outil de base pour démontrer la conformité à un régulateur ou à un auditeur.
Pour aller plus loin avec nous
Comment nous prolongerions ce sujet avec vous.
Pilier Consulting
AI-Augmented Enterprise
Du diagnostic de maturité à la priorisation des cas d'usage jusqu'à l'adoption durable dans l'organisation.
Pilier Tech Factory
Data, Cloud & DevOps
Plateformes data, arbitrages cloud souverain, discipline devops pour des systèmes qui doivent passer à l'échelle.
Pilier Consulting
Strategy & Innovation Governance
Cadrer la direction, séquencer les portefeuilles, gouverner les décisions qui composent dans la durée.
L'écriture est une chose. Livrer en est une autre. Sélection de travaux par les partners qui écrivent ici.
See the work
