Défis

La législation européenne sur l'IA est en vigueur. Pouvez-vous répondre à ces cinq questions ?

Par Marc Molas·31 mai 2026·8 min de lecture

Le règlement européen sur l'IA est en vigueur depuis août 2024. Les pratiques interdites ont expiré en août 2025. Les obligations relatives à l'IA à haut risque entrent en vigueur en août 2026. Si vous déployez des systèmes d'IA en Europe — ou si vous traitez des données appartenant à des Européens — le compte à rebours a déjà commencé.

La plupart des organisations traitent encore le règlement IA comme un document de conformité à lire et valider. Elles l'ont confié à la direction juridique, marqué comme "en cours d'examen" et sont passées à autre chose. C'est la mauvaise approche.

Le règlement IA n'est pas principalement un texte juridique. C'est un ensemble d'obligations opérationnelles. Et la façon la plus rapide de savoir si vous êtes réellement conforme — pas sur le papier, mais opérationnellement — est de répondre à cinq questions concrètes sur chaque système d'IA que vous exploitez.

Si vous ne pouvez pas répondre aux cinq, vous avez du travail à faire avant août.

Pourquoi ces cinq questions

Le règlement comprend plus de 180 articles. Mais enfoui dans les dispositions de gestion des risques, les obligations de transparence, les exigences de supervision humaine et le cadre de responsabilité se trouve une structure sous-jacente cohérente : les systèmes d'IA doivent être gouvernables. Pas seulement sûrs dans l'abstrait — activement gouvernables par des personnes identifiables, avec des processus définis, un comportement auditable et une chaîne de responsabilité claire.

Cette structure se résume à cinq questions. Elles ne sont pas de moi — ce sont celles que tout régulateur, auditeur ou avocat posera en premier quand quelque chose se passera mal. Vous devriez pouvoir y répondre avant que quelque chose se passe mal.

Question 1 : À quelles données accède-t-il et quelles données peut-il modifier ?

Cela semble évident. Ça l'est rarement.

En pratique, la plupart des équipes déployant des systèmes d'IA ont une réponse raisonnable pour "quelles données lit-il ?" (données d'entraînement, données d'entrée, peut-être un corpus de récupération), mais une réponse bien plus floue pour "quelles données peut-il écrire, modifier ou déclencher des changements ?"

Les systèmes agentiques aggravent cela. Un agent qui envoie des e-mails, met à jour des enregistrements CRM, appelle des API ou modifie des configurations a un accès en écriture à de vrais systèmes. Les dispositions de gouvernance des données du règlement IA (articles 10 et 13) exigent de documenter la traçabilité des données d'entraînement, la portée des données d'entrée et — surtout — quel état du système peut être modifié par les sorties du système d'IA.

Ce que la conformité implique : une cartographie des données maintenue par déploiement d'IA. Sources d'entrée (avec contrôles d'accès documentés), destinations de sortie (avec autorisations d'écriture documentées), et une distinction claire entre les chemins de lecture et d'écriture.

Le manque le plus courant : on a documenté ce qui entre mais pas ce qui se passe en aval des sorties de l'IA. Si votre IA recommande quelque chose et qu'un humain clique sur "approuver", le clic de l'humain compte-t-il comme l'écriture ? Légalement : parfois oui, parfois non. Vous devez savoir lequel.

Question 2 : Qui le supervise ?

Le règlement IA exige une supervision humaine pour les systèmes d'IA à haut risque (article 14). Pas "les humains peuvent examiner les résultats s'ils le souhaitent." Une supervision humaine définie — un rôle nommé avec la responsabilité de surveiller le comportement du système, d'examiner les décisions signalées, et l'autorité pour ignorer ou arrêter.

Cette question a deux niveaux :

Supervision opérationnelle : qui surveille le système au quotidien ? Qui reçoit l'alerte quand le taux d'erreur augmente ? Dans la plupart des organisations, c'est une fonction d'astreinte d'ingénierie. C'est bien, mais ça doit être explicite. "L'équipe le surveille" n'est pas suffisant — l'équipe n'est pas une entité juridique et n'a pas d'autorité.

Supervision de gouvernance : qui a l'autorité de modifier les paramètres du système, de réentraîner le modèle ou de l'arrêter ? Pour les industries réglementées, cela correspond aux structures de gouvernance existantes. Pour les startups, ça ne correspond souvent à personne, ce qui est un problème.

Ce que la conformité implique : pour chaque système d'IA, un individu nommé ou un rôle avec des responsabilités de supervision documentées et l'autorité réelle (accès, outils, processus) pour les exercer. Pas un RACI qui pointe vers "Ingénierie" — une personne, ou un rôle clairement défini, avec une responsabilité réelle.

Le Bureau de l'IA et les autorités nationales de surveillance du marché — la CNIL en France — sont la couche de supervision au-dessus de votre gouvernance interne. Elles ne sont pas abstraites. Elles construisent activement des capacités d'application.

Question 3 : Où stocke-t-il les informations ?

Le RGPD et le règlement IA se recoupent de manière significative ici. Les obligations de transparence et les exigences de gouvernance des données du règlement IA présupposent que vous pouvez répondre à la question de l'endroit où les entrées du modèle, les sorties et les états intermédiaires sont persistés.

Cela se complique rapidement pour les systèmes utilisant des fournisseurs de modèles tiers, la génération augmentée par récupération avec des bases de données vectorielles externes, des modèles affinés hébergés par des fournisseurs cloud, ou des architectures multi-agents où un agent transmet le contexte à un autre.

Ce que la conformité implique : résidence des données documentée pour chaque stockage persistant que touche le système d'IA. Cela inclut : données d'entrée, données de sortie, historique des conversations ou état de session si conservé, embeddings dans une base de données vectorielle, données d'entraînement de fine-tuning, journaux d'audit.

Pour l'IA à haut risque, les données doivent être conservées d'une manière permettant un audit post-hoc. Vous devez pouvoir reconstruire ce que le système a fait avec quelles données, pour une décision spécifique, à une date spécifique.

La question du fournisseur cloud : si vous utilisez un fournisseur LLM basé aux États-Unis sans résidence des données dans l'UE, la question de l'endroit où vont les données en transit est ouverte. La plupart des équipes d'ingénierie n'ont jamais lu les avenants de traitement des données de leurs contrats.

Question 4 : Qui est responsable en cas d'erreur ?

Le cadre de responsabilité du règlement IA, combiné avec la directive sur la responsabilité de l'IA en attente, est conçu pour répondre à cela au niveau macro. Mais la question pratique est interne : avant que le régulateur demande, votre organisation le sait-elle ?

Il y a trois rôles de responsabilité dans la structure du règlement IA :

Fournisseur : l'organisation qui développe ou met sur le marché un système d'IA. Si vous affinez un modèle, construisez un produit sur un modèle ou développez un outil d'IA pour que d'autres l'utilisent, vous êtes probablement fournisseur.

Déployeur : l'organisation qui met un système d'IA en service dans un contexte spécifique. Si vous utilisez le produit d'un fournisseur d'IA dans vos opérations commerciales, vous êtes déployeur.

La plupart des organisations sont à la fois fournisseurs (de leurs propres outils d'IA) et déployeurs (d'IA tierce). La répartition des obligations entre eux est importante : les fournisseurs sont responsables de la sécurité de conception fondamentale du système ; les déployeurs sont responsables du contexte de déploiement approprié et de la supervision.

Ce que la conformité implique : allocation documentée des obligations entre votre organisation et vos fournisseurs d'IA. Vos contrats enterprise devraient spécifier qui est le fournisseur de référence pour chaque système.

Le vrai manque : la plupart des organisations n'ont pas encore eu la conversation sur la responsabilité avec leurs fournisseurs d'IA. Le contrat a été signé, la clé API est en production, et personne n'a formellement alloué qui répond au régulateur.

Question 5 : Comment l'arrêter s'il commence à mal fonctionner ?

C'est la question que la plupart des équipes trouvent la plus difficile à répondre, non pas parce que le mécanisme n'existe pas, mais parce qu'il n'a jamais été explicitement conçu.

L'article 9 (gestion des risques) et l'article 14 (supervision humaine) ensemble exigent que les systèmes d'IA à haut risque disposent de procédures définies pour arrêter l'opération lorsque les seuils de sécurité ou de précision sont dépassés. Ce n'est pas "vous pouvez éteindre le serveur." Cela signifie :

Détection : comment savez-vous qu'il se comporte mal ? Quelle métrique, alerte ou processus de révision fait remonter le problème ?
Classification : qu'est-ce qui constitue "mal fonctionner" pour ce système spécifique ? Dérive du modèle ? Disparité démographique dans les sorties ? Taux d'erreur dépassant le seuil ?
Autorisation : qui a l'autorité de décider d'arrêter ?
Exécution : qu'est-ce qu'arrêter signifie ? Couper l'API ? Revenir à une version précédente ? Passer à un processus manuel de secours ?
Communication : qui est notifié quand un arrêt se produit ? Pour les systèmes à haut risque dans certaines catégories, la notification d'incidents au Bureau de l'IA est obligatoire.

Ce que la conformité implique : un runbook — pas un interrupteur d'arrêt théorique, mais une procédure documentée testée au moins une fois, avec des propriétaires nommés à chaque étape.

Pourquoi la plupart des équipes échouent ici : le système a été déployé de manière incrémentale. Il n'y a jamais eu de session de conception sur "quel est le plan d'arrêt ?". L'interrupteur existe en principe (éteindre le serveur) mais les couches de détection et d'autorisation n'existent pas.

Le schéma derrière les cinq questions

Lisez-les ensemble : accès/modification des données, supervision, stockage, responsabilité, arrêt. Ce ne sont pas cinq exigences indépendantes. Ce sont cinq facettes d'une seule question : ce système d'IA est-il gouvernable ?

La gouvernance exige que quelqu'un puisse observer le système (questions 1, 3), que quelqu'un ait autorité sur lui (questions 2, 4) et que cette autorité puisse être exercée en pratique (question 5). Si l'une des cinq est manquante, la boucle de gouvernance est brisée.

Le règlement IA européen opérationnalise cela dans la loi parce que l'approche volontaire n'a pas fonctionné. Des principes sans application ne changent pas les comportements. Le règlement, c'est l'application.

Ce que je ferais ce trimestre

Si vous déployez des systèmes d'IA en Europe, ou quoi que ce soit touchant des données européennes, la séquence pratique :

Inventoriez vos déploiements d'IA. Pas seulement les produits d'IA que vous vendez — toute l'IA que vous utilisez en interne. Outils de sélection RH, bots de service client, détection de fraude, moteurs de recommandation.
Pour chaque système, répondez aux cinq questions. Écrivez-les. "Nous n'avons pas encore décidé" est une réponse — cela signifie que vous avez un manque.
Pour tout ce qui se trouve dans les catégories à haut risque (Annexe III du règlement) — priorisez. Août 2026 est l'échéance ferme.
Mettez vos contrats fournisseurs en ordre. Qui est le fournisseur de référence ? Quelles capacités d'audit le fournisseur fournit-il ?
Construisez le runbook pour la question 5. Des cinq, c'est la plus opérationnelle et la moins susceptible d'exister. Construisez-la avant d'en avoir besoin.

Le règlement IA n'est pas une réglementation parfaite. Mais les cinq questions sont une ingénierie responsable indépendamment de la réglementation — c'est ce que le déploiement responsable de systèmes à conséquences a toujours requis. Le règlement le rend simplement obligatoire.

Vous déployez des systèmes d'IA en production en Europe et vous avez besoin d'une capacité d'ingénierie qui opère déjà avec ces contrôles de gouvernance intégrés ? Parlons-en — nos équipes nearshore construisent des systèmes d'IA avec journaux d'audit, hooks de supervision humaine et runbooks de conformité comme pratique standard.