Comment l'AI Act va changer concrètement le développement de vos modèles

Le premier article posait le cadre : niveaux de risque, obligations générales, calendrier. Cette suite s'adresse aux équipes qui construisent ou intègrent des modèles et qui se demandent ce qui change, concrètement, dans leur façon de travailler.

Ce que le règlement touche dans le cycle de développement

L'AI Act ne régule pas seulement ce qu'un système fait, mais comment il a été conçu, testé, documenté et maintenu. Pour les équipes de développement, cela signifie que la conformité ne peut pas être déléguée à une équipe juridique en fin de projet. Elle s'intègre dans le cycle lui-même.

Voici les quatre étapes les plus directement impactées.

1. La définition du cas d'usage, avant la première ligne de code

La question du niveau de risque doit être posée au moment de la conception, pas après. Un modèle de scoring de crédit, un outil d'aide à la décision RH ou un système de détection d'anomalies utilisé dans un contexte réglementé ne se conçoivent pas de la même façon qu'un moteur de recommandation interne.

En pratique, cela implique d'introduire une étape de qualification en amont de chaque nouveau projet d'IA : à qui s'adresse le système, dans quel contexte, avec quelles conséquences pour les personnes concernées ? Cette qualification oriente ensuite les choix d'architecture, de documentation et de gouvernance.

Ce qui change concrètement : ajouter une fiche de qualification systémique au kickoff de tout projet impliquant de l'IA. Elle n'a pas besoin d'être complexe. Elle doit permettre de répondre à la question : sommes-nous dans le champ du règlement, et si oui, à quel niveau ?

2. La qualité des données et leur traçabilité

Pour les systèmes à haut risque, l'AI Act impose des exigences explicites sur les données d'entraînement : pertinence, représentativité, absence de biais, documentation des sources. Ce n'est pas un audit ponctuel, c'est une obligation de conception.

Pour les équipes data engineering et ML, cela se traduit par plusieurs pratiques à mettre en place ou à renforcer : traçabilité des jeux de données (d'où viennent-ils, quand ont-ils été collectés, comment ont-ils été traités), versionnement des datasets, documentation des choix de filtrage ou d'exclusion, et tests de biais sur les populations représentées.

Ce qui change concrètement : les data cards et model cards, deviennent une exigence de fond pour les systèmes à haut risque. Des outils comme MLflow, DVC ou les fonctionnalités de lineage des plateformes cloud peuvent supporter cette traçabilité.

3. Les tests de robustesse et la gestion des risques

L'AI Act exige que les systèmes à haut risque fassent l'objet d'une gestion des risques formalisée et continue, pas seulement d'une validation à la mise en production. Cela inclut des tests de robustesse, la prise en compte des scénarios de défaillance et des mécanismes permettant à un humain d'intervenir ou de corriger.

Pour les équipes qui pratiquent déjà du MLOps structuré, une partie de ce travail est déjà en place. Là où ça change, c'est sur la formalisation : il ne suffit pas de faire des tests, il faut les documenter, les versionner et être en mesure de les produire en cas de contrôle.

Ce qui change concrètement : documenter systématiquement les tests de performance et de robustesse dans le cadre du pipeline CI/CD. Prévoir des scénarios de test sur des distributions atypiques ou des cas limites. Définir et documenter les seuils de déclenchement d'une revue humaine.

4. La supervision humaine, intégrée par design

C'est probablement le point le plus structurant pour les équipes produit. L'AI Act ne se contente pas d'encourager la supervision humaine : pour les systèmes à haut risque, il l'exige et impose qu'elle soit rendue possible par la conception même du système.

Cela signifie qu'un système qui prend des décisions automatiques sur des sujets sensibles doit avoir été conçu pour permettre une intervention humaine effective : comprendre ce que le modèle a produit, identifier les cas problématiques, corriger ou annuler une décision. L'explicabilité n'est plus un bonus, elle devient une contrainte d'architecture.

Ce qui change concrètement : revoir les interfaces et les workflows autour des décisions automatisées. Prévoir des logs compréhensibles, des indicateurs de confiance exposés aux opérateurs, et des points de validation humaine explicitement intégrés dans le processus métier.

Ce que ça implique pour les équipes agiles

Ces exigences semblent, à première lecture, en tension avec les pratiques agiles : itérer vite, livrer souvent, ajuster en continu. En réalité, elles ne s'y opposent pas, mais elles obligent à traiter certaines dimensions comme des constraints non négociables plutôt que comme du backlog.

La documentation de conformité peut être incrémentale. Les tests de robustesse peuvent s'intégrer dans la définition of done. La qualification du niveau de risque peut être un rituel de sprint planning. Ce qui ne peut pas être agilisé, c'est l'absence de ces éléments au moment du déploiement.

Un changement de posture autant que de process

Au fond, ce que l'AI Act demande aux équipes tech, c'est de considérer que développer un système d'IA dans un contexte sensible engage une responsabilité qui ne s'arrête pas à la qualité du code. La robustesse du modèle, la représentativité des données, la capacité d'un humain à comprendre et contester une décision : ce sont des critères de qualité au même titre que la performance ou la scalabilité.

Cette évolution est inconfortable pour ceux qui la voient comme une contrainte externe. Elle est utile pour ceux qui la lisent comme un cadre pour construire des systèmes réellement dignes de confiance.

Sources :