IA Act : ce que cette réglementation change concrètement pour les projets IA

Pendant deux ans, l'IA Act a été un sujet abstrait pour la plupart des équipes data. On en parlait en COMEX, on l'évoquait dans les slides de séminaire, mais sur le terrain, les projets continuaient à se lancer comme avant : un cas d'usage, un POC, un modèle entraîné sur les données disponibles, une mise en production quand ça fonctionne. Cette époque est révolue.

Le règlement européen est entré en vigueur en août 2024, et les premières obligations s'appliquent depuis février 2025. À partir d'août 2026, les systèmes d'IA classés à haut risque doivent être documentés, supervisés, tracés et auditables. Ce n'est pas une nouvelle norme à appliquer en plus, c'est une nouvelle manière de cadrer un projet IA dès la phase de conception.

Les conséquences sont concrètes. Un cas d'usage qui se lançait en quelques semaines sur un coin de table demande désormais une qualification de risque formalisée, une documentation technique opposable, un dispositif de supervision humaine, et un responsable nommé pour piloter la conformité. Cet article reprend la question de zéro : qu'est-ce qui change vraiment pour un projet IA, à quel moment intervient ce changement, et qui doit s'en occuper.

Pourquoi l'IA Act change la manière de cadrer un projet IA ?

L'IA Act n'introduit pas seulement des règles supplémentaires. Il change la nature même du contrat implicite entre l'organisation qui déploie une IA et les personnes qui en subissent les décisions. Avant, on demandait que ça fonctionne. Maintenant, on demande qu'on puisse l'expliquer.

Le passage d'une logique de bonnes pratiques à une obligation documentée

Jusqu'à présent, la gouvernance d'un projet d'intelligence artificielle reposait sur des bonnes pratiques internes : on documentait quand on avait le temps, on validait les biais quand le sujet remontait, on testait les performances quand le métier le demandait. C'était une logique d'effort raisonnable, plus ou moins formalisée selon la maturité de l'organisation.

L'IA Act bascule cette logique. Ce qui n'est pas documenté n'existe pas du point de vue du régulateur. Il ne suffit plus d'affirmer qu'un modèle a été testé : il faut produire le rapport de test, les jeux de données utilisés, les métriques calculées, les seuils retenus, les arbitrages effectués. Et tout cela doit être conservé et accessible pendant toute la durée d'exploitation du système.

Cette exigence change aussi la chaîne de responsabilité. Un Data Scientist qui produit un modèle ne peut plus se contenter de livrer un notebook fonctionnel. Il doit produire, ou voir produire, une documentation technique normée. Un sponsor métier qui valide une mise en production ne valide plus seulement la performance : il valide aussi la qualification de risque et la robustesse du dispositif de supervision. L'effort de documentation devient une condition de mise en production, pas une option post-livraison.

Ce que cela implique dès la phase de cadrage

Concrètement, trois choses changent dans la manière de cadrer un projet IA, dès les premières discussions avec le métier.

• La qualification de risque devient un livrable de cadrage : avant de lancer un POC, il faut être capable de positionner le cas d'usage dans la nomenclature de l'IA Act (risque inacceptable, haut risque, risque limité, risque minimal). Ce positionnement détermine le niveau d'exigences applicable et donc l'effort à anticiper. C'est une décision qui se prend avec le juridique, pas uniquement avec la data.
• Les données d'entraînement entrent dans le périmètre du projet : la provenance, la qualité, la représentativité et la conformité (notamment RGPD) des données utilisées pour entraîner le modèle deviennent des éléments documentés et auditables. On ne peut plus entraîner un modèle sur « un export du CRM » sans préciser quel export, à quelle date, avec quelles règles d'exclusion.
• Le dispositif de supervision humaine se conçoit en amont : la supervision humaine n'est pas un mode dégradé activé en cas de problème. C'est une composante structurelle du système, qui se conçoit en même temps que l'architecture technique, qui implique des rôles dédiés et qui se documente au même titre que le modèle lui-même.

Aucune de ces trois exigences n'est insurmontable. Toutes demandent en revanche d'être anticipées au cadrage, pas découvertes en fin de projet. C'est précisément ce qui change la manière de travailler.

Comment qualifier un projet IA selon le niveau de risque défini par l'IA Act ?

L'IA Act repose sur une logique de pyramide à quatre étages, du risque inacceptable au risque minimal. Cette qualification n'est pas indicative : c'est elle qui détermine le régime juridique applicable et donc les obligations qui pèsent sur le projet. Plus le risque est élevé, plus les exigences sont contraignantes.

Au sommet de la pyramide, les usages interdits couvrent les systèmes considérés comme incompatibles avec les droits fondamentaux : notation sociale généralisée, manipulation comportementale exploitant des vulnérabilités, identification biométrique en temps réel dans l'espace public (sauf exceptions strictes). Ces usages sont purement et simplement prohibés, quelle que soit la qualité du dispositif technique mis en place.

Le deuxième niveau, le haut risque, est celui qui mobilise le plus les organisations. Il couvre les systèmes d'IA utilisés dans des contextes sensibles : recrutement, accès au crédit, accès à des services publics essentiels, infrastructures critiques, justice, application de la loi. La liste précise est définie dans l'annexe III du règlement et fait l'objet de mises à jour régulières. Un système classé à haut risque doit respecter l'ensemble du référentiel d'obligations détaillé dans la suite de cet article.

Le troisième niveau, le risque limité, vise les systèmes qui interagissent directement avec des humains (chatbots, contenus générés par IA, deepfakes). Les obligations sont alors essentiellement des obligations de transparence : la personne doit savoir qu'elle interagit avec une IA, ou qu'un contenu a été généré ou modifié par IA. C'est moins contraignant, mais ce n'est pas rien : une mention manquante sur un chatbot client peut suffire à créer un défaut de conformité.

Le dernier niveau, le risque minimal, couvre la majorité des usages courants (filtres anti-spam, recommandations produit, optimisation logistique). Aucune obligation spécifique n'est imposée par l'IA Act, même si les bonnes pratiques internes restent recommandées.

La difficulté pratique est rarement de classer un usage clairement minimal ou clairement interdit. Elle est de trancher pour les cas frontières : un outil d'aide à la décision RH est-il un système de recrutement à haut risque, ou un simple outil d'analyse ? Un assistant médical embarqué dans un workflow clinique est-il un dispositif à haut risque, ou un outil d'aide à la consultation ? Ces arbitrages se prennent au cas par cas, en croisant le métier, le juridique et la data, et doivent être tracés.

Quelles obligations concrètes l'IA Act impose à un projet IA à haut risque ?

Pour les systèmes à haut risque, l'IA Act définit un référentiel d'obligations qui couvre tout le cycle de vie du projet, de la conception à l'exploitation. Trois familles d'obligations structurent l'essentiel de ce travail : la documentation, la supervision humaine et la traçabilité.

Documenter le système et ses données d'entraînement

La documentation est la première brique. Elle prend la forme d'une documentation technique normée, conservée et mise à jour pendant toute la durée d'exploitation du système. Elle doit permettre à un tiers (un auditeur, un régulateur, un utilisateur impacté) de comprendre ce que fait le système et comment il a été conçu.

Cinq éléments la composent au minimum :

• La description fonctionnelle : ce que le système fait, dans quel processus métier il s'inscrit, quelles décisions il influence ou automatise, et quelles populations sont concernées. C'est le document qui explique au régulateur à quoi sert exactement le système.
• L'architecture technique : les choix algorithmiques (type de modèle, hyperparamètres principaux), les briques techniques utilisées (cloud, frameworks, librairies, modèles tiers), et les interfaces avec les autres systèmes.
• Les données d'entraînement, de validation et de test : leur provenance, leur volumétrie, leur nature (sensibles ou non), les règles d'inclusion et d'exclusion, les traitements de préparation appliqués, et les évaluations de représentativité et de qualité. Cette partie suppose une démarche structurée en amont, dans la lignée de ce qu'on attend d'un audit qualité des données rigoureux.
• Les évaluations de performance et de biais : les métriques calculées (précision, rappel, taux de faux positifs, écarts de performance par sous-population), les seuils retenus, et les arbitrages effectués entre performance globale et équité entre groupes.
• Les procédures de mise à jour et de réentraînement : comment et quand le modèle est mis à jour, quels critères déclenchent un réentraînement, et quels contrôles s'appliquent avant chaque nouvelle mise en production.

Ce volume documentaire peut paraître intimidant, surtout pour les équipes habituées à livrer des notebooks. Il est cependant la condition de mise en production. Sans documentation conforme, le système ne peut pas être déployé légalement.

Garantir une supervision humaine effective

La supervision humaine est le deuxième pilier. L'IA Act exige que les systèmes à haut risque soient conçus de manière à permettre une supervision humaine effective. Ce mot, « effective », est central : il ne suffit pas d'afficher un humain dans la boucle. Il faut démontrer qu'il a réellement les moyens d'intervenir.

Cela passe par trois composantes :

• La capacité de compréhension : l'humain superviseur doit pouvoir comprendre, au moins dans les grandes lignes, comment le système produit ses sorties. Cela suppose une formation, des interfaces lisibles, et une documentation accessible. Un superviseur qui valide à l'aveugle ce que produit un modèle ne supervise rien.
• La capacité d'intervention : le système doit permettre à l'humain de remettre en cause une décision, de la modifier, ou de désactiver le système si nécessaire. Cette capacité doit être conçue dans l'outil dès le départ, pas ajoutée à la marge. Un système qui ne peut pas être désactivé n'est pas un système supervisé.
• L'organisation de la supervision : qui supervise, à quelle fréquence, avec quels critères, en relation avec qui dans l'organisation. C'est typiquement le sujet qui passe à la trappe dans les projets pressés : on conçoit l'IA, on oublie d'organiser la supervision, et au moment de la mise en production, personne ne sait qui doit regarder quoi.

Le principe du « human in the loop » est facile à énoncer, difficile à mettre en œuvre. Il demande des compétences (formation), du temps (la supervision occupe des personnes), et une discipline de revue qui s'inscrit dans les rituels de l'équipe métier concernée.

Tracer les décisions et les incidents

Le troisième pilier est la traçabilité. L'IA Act impose la journalisation automatique des événements significatifs : prédictions produites, décisions automatisées, interventions humaines, incidents techniques, dérives détectées. Cette traçabilité doit être conservée pendant une durée définie (typiquement six mois minimum, davantage selon les secteurs) et doit être exploitable en cas d'audit ou de réclamation.

Concrètement, cela implique de mettre en place un dispositif de logs structurés, qui capture pour chaque inférence du modèle : l'identifiant de l'inférence, les entrées du modèle (de manière à pouvoir reproduire la décision), la sortie produite, le score de confiance, l'horodatage, et l'identifiant de l'utilisateur ou du système qui a déclenché l'appel. Cette infrastructure technique de traçabilité doit être prévue dès l'architecture, pas branchée après coup.

C'est typiquement un sujet qui rejoint les pratiques d'industrialisation et de pilotage des modèles en production, même si l'IA Act élargit le périmètre habituel du MLOps en y intégrant des exigences réglementaires explicites. Les organisations qui ont déjà investi dans ces pratiques partent avec une longueur d'avance.

Ce que l'IA Act change pour les projets IA déjà en production

Le règlement ne s'applique pas qu'aux projets futurs. Les systèmes d'IA déjà en exploitation au moment où les obligations entrent en vigueur sont aussi concernés. Pour les organisations qui ont déjà mis en production plusieurs cas d'usage IA ces dernières années, le travail de mise en conformité est substantiel et doit être planifié.

Requalifier les systèmes existants

La première étape consiste à inventorier les systèmes d'IA en production. Cet inventaire n'est pas aussi simple qu'il en a l'air : dans la plupart des organisations, des modèles ont été déployés au fil de l'eau, parfois sans qualification claire de leur statut « IA » au sens de l'IA Act. Un modèle de scoring intégré dans un CRM, un assistant de tri de candidatures dans un ATS, un module de détection de fraude dans un système financier : tout cela entre dans le périmètre.

Une fois l'inventaire posé, chaque système doit être requalifié selon la pyramide de risques. C'est un travail de croisement entre la finalité métier (qui détermine le niveau de risque) et les caractéristiques techniques (qui déterminent la portée des obligations). Cette requalification se prend en équipe métier + data + juridique, et donne lieu à une décision tracée pour chaque système.

L'enjeu pratique de cette requalification est de séparer les systèmes qui peuvent rester en production en l'état (risque minimal ou limité avec mentions de transparence à ajouter) de ceux qui demandent un effort de mise en conformité significatif (haut risque). Cette séparation conditionne directement le budget et le calendrier de mise en conformité.

Combler les écarts de documentation

Pour les systèmes classés à haut risque qui sont déjà en production, le travail principal est documentaire. Dans la plupart des cas, la documentation existante est insuffisante : des morceaux d'analyse fonctionnelle, des slides de comité, des notebooks d'exploration, mais rarement une documentation technique normée au sens où l'IA Act l'exige.

Combler ces écarts demande de reconstituer ce qui n'a pas été produit en temps réel. Concrètement :

• Retracer l'origine des données d'entraînement : ce qui suppose souvent de remonter à des exports anciens, de retrouver les règles d'extraction utilisées, et parfois d'admettre que cette traçabilité a été perdue. Quand c'est le cas, il faut documenter ce que l'on sait et tracer explicitement ce qui n'est plus reconstituable.
• Reproduire les évaluations de performance et de biais : dans des conditions documentées, avec des jeux de données conservés, sur les axes attendus par l'IA Act (performance globale, écarts entre sous-populations, robustesse face aux dérives).
• Documenter le dispositif de supervision actuel : souvent informel ou implicite, qu'il faut formaliser ou renforcer. Si la supervision actuelle n'est pas suffisante, c'est aussi l'occasion de redimensionner les rôles et les rituels.

Ce travail de documentation rétroactive est l'effort le plus lourd de la mise en conformité. Il demande de mobiliser à la fois les équipes data (qui ont conçu les systèmes) et les équipes métier (qui les utilisent au quotidien). Le risque réel est de découvrir que certains systèmes ne peuvent pas être documentés rétroactivement et doivent être refondus, voire arrêtés.

Mettre à jour les contrats avec les fournisseurs de modèles

Le troisième chantier concerne les modèles fournis par des tiers : modèles fondation (LLM), modèles vendus en SaaS, modèles embarqués dans des solutions commerciales. L'IA Act répartit les responsabilités entre les fournisseurs et les déployeurs, mais cette répartition doit être traduite contractuellement, ce qui demande une mise à jour des accords existants.

Trois points doivent figurer explicitement dans les contrats :

• L'engagement de conformité du fournisseur : le fournisseur s'engage à fournir la documentation technique requise par l'IA Act, à la mettre à jour, et à informer le déployeur des modifications significatives apportées au modèle.
• La répartition des obligations : qui documente quoi, qui supervise quoi, qui répond en cas de contrôle. Cette répartition est rarement triviale, surtout sur les modèles fondation où le déployeur ajoute une couche d'application sans contrôle sur le modèle de base.
• Le droit d'audit et de portabilité : la possibilité, pour le déployeur, de vérifier la conformité du fournisseur et de pouvoir migrer vers un autre fournisseur en cas de défaillance, sans rupture de service.

Ces clauses ne sont pas standard dans les contrats SaaS classiques. Les renégocier prend du temps et peut révéler des oppositions commerciales (le fournisseur n'a parfois pas les moyens de tenir ces engagements). Identifier les contrats à risque tôt permet d'éviter de découvrir le problème en pleine échéance d'audit.

👉 À lire aussi : Gouverner l'IA en entreprise : ce qu'il faut vraiment faire

Qui doit piloter la conformité à l'IA Act dans un projet IA ?

La conformité à l'IA Act n'est pas un sujet purement juridique, ni purement technique. Elle se situe à l'intersection de plusieurs fonctions, qui doivent coopérer dans un dispositif clair. Sans portage explicite, les obligations restent flottantes et la conformité se construit au coup par coup, généralement trop tard.

Quatre rôles structurent le pilotage de la conformité au niveau d'un projet IA :

• Le sponsor métier : porteur du cas d'usage, il est responsable de la finalité, de l'arbitrage sur le niveau de risque accepté et de la mobilisation des ressources nécessaires à la supervision. Sans sponsor engagé, la conformité passe systématiquement après la performance, ce qui crée la dette de conformité dont on parlait plus haut.
• Le Data Owner du domaine : responsable des données d'entraînement et de production utilisées par le système. Il garantit la conformité de ces données (qualité, RGPD, droits d'usage) et leur traçabilité documentaire.
• Le Data Scientist ou ML Engineer : responsable de la production technique de la documentation (architecture, choix algorithmiques, évaluations de performance et de biais) et de l'implémentation des dispositifs de traçabilité.
• Le juridique ou la fonction conformité : responsable de la qualification de risque, de la veille réglementaire, de la mise à jour des contrats fournisseurs et de la préparation aux audits.

Ces quatre rôles ne suffisent pas isolément. C'est leur coordination qui fait la conformité. Cette coordination peut prendre plusieurs formes selon la taille de l'organisation :

• Dans une petite organisation : une revue projet trimestrielle qui croise les quatre rôles, avec un livrable de conformité simple (état de la documentation, niveau de risque, supervision en place) pour chaque cas d'usage actif.
• Dans une organisation de taille moyenne : un comité IA dédié, qui se réunit mensuellement et qui couvre l'ensemble des cas d'usage en production ou en cadrage. Ce comité peut être animé par le Data Governance Manager ou par un AI Officer dédié si l'organisation a créé ce rôle.
• Dans une grande organisation : un dispositif à deux étages, avec des comités locaux par domaine (animés par les Data Owners) et un comité central piloté par le CDO ou un AI Officer, qui consolide les risques, arbitre les priorités et porte le sujet au COMEX.

L'erreur la plus fréquente est de confier la conformité IA Act au seul juridique. Le juridique est indispensable pour interpréter le texte et qualifier les risques, mais il ne peut pas produire la documentation technique, ni superviser les modèles, ni dialoguer avec les fournisseurs sur les aspects MLOps. Une conformité confiée au seul juridique est une conformité de papier, pas une conformité opérationnelle. Cette logique de coopération renvoie d'ailleurs à des principes plus larges de répartition des rôles et responsabilités en gouvernance des données : la conformité IA Act prolonge ce cadre, elle ne le remplace pas.

À l'inverse, confier la conformité aux seules équipes data crée le problème symétrique : on produit de la documentation technique, mais on ne s'assure pas qu'elle répond aux exigences juridiques. Le seul dispositif robuste est croisé.

👉 À lire aussi : L'IA générative et ses impacts sur la gouvernance des données

En synthèse

L'IA Act ne sanctuarise pas l'innovation ; il en redéfinit les conditions. Quatre réflexes structurent les organisations qui s'adaptent sans douleur :

• Elles intègrent la qualification de risque dès la phase de cadrage, comme un livrable de cadrage à part entière, pas comme un contrôle a posteriori.
• Elles adossent la conformité au MLOps existant, plutôt que de créer un dispositif parallèle qui ne tiendra pas.
• Elles confient le pilotage à un binôme métier + juridique + data, jamais à un seul de ces rôles.
• Elles traitent leur stock de systèmes en production en priorité, parce que c'est là que se concentrent les écarts les plus coûteux à combler.

À l'inverse, les organisations qui attendent un contrôle pour s'y mettre découvrent généralement que la mise en conformité d'un système déjà déployé coûte trois à cinq fois plus cher que celle d'un système conçu directement aux normes. Anticiper n'est pas du zèle réglementaire, c'est une question d'économie de projet.