par | Juil 21, 2025

Conformité AI Act : transformer le workflow Data Science pour les systèmes à haut risque

Dans cet article nous allons voir comment adapter notre workflow Data Science pour être conforme à l’AI Act.

Nous suivrons chaque étape du cycle de développement d’un système d’IA, de la phase de cadrage initial jusqu’à l’industrialisation et au monitoring, en passant par la phase de preprocessing des données et d’entraînement des modèles.

Pour cela, nous nous mettrons dans la peau d’un provider travaillant sur un système d’IA classé à haut risque. En effet, en tant que Data Scientists, nous endossons souvent ce rôle dès lors que nous concevons, entraînons ou déployons des systèmes d’IA destinés à un usage interne ou à une commercialisation (voir Partie III de l’article précédent).

Il est important de garder à l’esprit que les obligations réglementaires et donc les méthodes de travail et les best practices qui en découlent varient selon la catégorie de risque du système. Si le système que vous développez est à risque faible ou modéré, le niveau d’exigence sera différent.

Enfin, pour garder une lecture claire, nous nous concentrerons ici sur le cas général. Pour autant, il existe de nombreuses situations particulières, par exemple l’utilisation d’un modèle pré-entraîné que l’on fine-tune. Dans un tel cas, il faudra à la fois vérifier la conformité du modèle initial pré-entraîné, puis appliquer toutes les exigences du provider sur le nouveau modèle fine-tuné.

I. Cadrage du projet

 

Comme pour tout projet d’IA, la première étape est celle du cadrage. Il s’agit de bien définir les besoins et contraintes métiers, les contraintes techniques, budgétaires, de cybersécurité, ainsi que les modalités d’usage du système par les utilisateurs finaux. Avec l’entrée en vigueur de l’AI Act, cette phase prend une dimension supplémentaire : l’évaluation du risque réglementaire et la détermination de notre rôle dans la chaîne de conformité.

1. Identification du niveau de risque du système

L’AI Act classe les systèmes d’IA selon leur niveau de risque. Comme ce niveau dépend du cas d’usage et non de la technologie employée, il peut (et doit) être défini dès la phase de cadrage. De plus, cette identification est cruciale pour connaître les obligations réglementaires à respecter dans la suite du développement du système.

2. Détermination de notre rôle vis-à-vis de l’AI Act

Pour rappel, l’AI Act définit plusieurs rôles réglementaires (provider, deployer, importer, distributeur). Il est fondamental d’identifier le rôle que l’on a, car ce rôle détermine l’ensemble des obligations à respecter. La plupart du temps, un Data Scientist développe un système d’IA et l’entreprise responsable du projet est donc un provider.

Mais certaines situations sont plus nuancées. Prenons le cas d’une ESN qui développe un système d’IA pour le compte d’un client. Le système d’IA étant utilisé ou commercialisé sous la marque du client, c’est ce dernier qui est provider. Le rôle joué par l’ESN peut donc porter à confusion, mais concrètement :

  • Tant que le projet est en cours de développement, l’ESN agit comme provider et doit se conformer aux exigences associées.

  • Une fois le projet livré, le client devient le provider officiel, responsable des obligations liées à l’industrialisation, à la maintenance ou aux mises à jour et garant des obligations des phases précédentes.

Bien sûr, ce cas est un cas général et il faudra s’assurer de clairement identifier ce transfert de responsabilité, car il a un impact direct sur la manière dont on structure la documentation, les livrables, et les processus de conformité.

3. Mise en place d’un Risk Management System – RMS

 

 

L’une des principales obligations des systèmes d’IA à risque élevé est la mise en place d’un système de gestion des risques. En effet, comme nous savons que notre système d’IA représente un fort risque, il faut tout mettre en œuvre pour identifier, évaluer et mitiger ce risque afin qu’il soit maîtrisé. Les risques concernés sont toujours ceux liés à la santé, à la sécurité ou aux droits fondamentaux.

À ce jour, l’AI Act ne fournit pas de framework précis sur la manière dont ce RMS doit être mis en œuvre, mais l’article 9 du texte de loi liste un ensemble de guidelines à suivre. Les différentes instances de gouvernance de la loi viendront préciser ces guidelines officielles avant l’entrée en application complète du texte en août 2027.

Dès la phase de cadrage, nous pouvons réaliser une première itération du RMS en nous concentrant sur les points suivants :

  • Identifier les risques liés à l’utilisation normale du système, mais aussi ceux liés à des usages détournés ou incorrects.
    Par exemple, pour un système dont l’output doit être évalué par un humain avant d’être utilisé, il faut penser à évaluer le risque qui survient si cette supervision humaine n’est plus assurée. Toutes les possibilités doivent être envisagées et il faut donc se poser les questions suivantes :

    • Quelles sont les conditions normales d’utilisation du système et quelles sont les possibles utilisations incorrectes que l’on peut raisonnablement envisager ?

    • Pour chacune d’elles, quels risques peuvent survenir (santé, sécurité et droits fondamentaux des citoyens) ?

    • Pour chaque risque identifié, quelle est la probabilité qu’il survienne et quelle est la gravité de la survenue de ce risque ?

    • Existe-t-il des indicateurs permettant de surveiller ou d’anticiper ces risques ?

  • Commencer à réfléchir aux mesures de mitigation : à quel niveau (données, modèle, interface, supervision humaine…) et avec quelles solutions ? Parfois, il faudra attendre la phase de développement pour avoir une meilleure vision de l’aspect technique du système et pour pouvoir y intégrer les meilleurs moyens de mitigation.

Il est essentiel de concevoir le RMS comme un processus vivant et continu, mis à jour à chaque étape du développement et du cycle de vie du système. Nous reviendrons donc sur ce point dans les phases suivantes du workflow Data Science.

II. Ingestion et preprocessing des données

 

Maintenant que notre projet est bien cadré et que l’on sait où l’on va, nous pouvons passer à l’étape suivante : la sélection, l’ingestion, le prétraitement et l’analyse des données qui serviront à alimenter notre système d’IA.
Cette phase est critique car de la qualité des données dépendra directement la performance et la robustesse du modèle entraîné et donc la qualité de notre système d’IA dans son entièreté.

1. Gouvernance des données et rigueur dans la sélection

Avant toute chose, les données doivent naturellement respecter les exigences du RGPD et s’inscrire dans une gouvernance maîtrisée : traçabilité, documentation, accessibilité, droits d’usage.

Dans les grandes structures où plusieurs versions d’un même jeu de données peuvent coexister et où l’on fait face à de très grandes quantités de data, il n’est pas rare de retrouver :

  • Des variables similaires représentant des réalités différentes,

  • Des granularités hétérogènes,

  • Ou des logiques métiers divergentes.

Il est donc essentiel d’opérer un travail de sélection rigoureux avant ingestion, en collaboration étroite avec les experts métier et les responsables des différents périmètres data.

2. Qualité des données : exigences de l’AI Act

L’AI Act porte une attention particulière à la qualité des données utilisées pour l’entraînement des systèmes à haut risque. Plusieurs axes clés doivent être traités à cette étape :

    • Biais

Il faudra s’assurer que les biais dans nos data peuvent être monitorés afin de pouvoir les détecter. On veillera à :

  • Identifier les biais potentiels dans chaque variable (ex : biais liés au genre, à l’âge, à la localisation…).

  • Se demander : s’agit-il d’un biais représentatif de la réalité (ex : disparité naturelle liée au métier) ou d’un biais induit et indésirable (ex : discrimination historique) ?

  • Monitorer ces biais dans le temps et prévoir des indicateurs pour les suivre.

  • Appliquer des stratégies de mitigation adaptées : techniques de rééchantillonnage, de repondération, ou de débiaisement algorithmique. On choisira la méthode la mieux adaptée à notre cas d’usage.

• Représentativité

Il faudra s’assurer que les data utilisées sont bien représentatives de la réalité métier et que les méthodes de mesures et d’échantillonnage n’aient pas biaisé ces données. Pour cela, il faudra donc s’intéresser à la manière dont les données ont été récoltées.

• Complétude

L’absence de données peut fausser l’analyse. On identifiera les champs manquants, et évaluera l’impact de ces absences. On pourra alors choisir la meilleure stratégie de traitement (imputation, exclusion, collecte complémentaire…).

• Précision et erreurs

Il faudra là aussi, autant que possible, disposer d’un dataset sans erreurs. La compréhension du processus de récolte des données nous permettra d’estimer le taux d’erreur du dataset et des mesures possibles pour les détecter et les éliminer.

• Drift

Parfois, la réalité peut évoluer et les distributions des données qui la reflètent vont donc, elles aussi, évoluer au cours du temps. Il est important de suivre ces changements de distribution car le modèle entraîné sur ces données peut ne plus être le meilleur pour identifier les tendances et relations dans les données. On détectera tout drift de data (concept drift ou data drift) et on anticipera le besoin de réentraînement du modèle pour rester aligné avec l’environnement actuel.

• Versioning

Les datasets pouvant être modifiés, il est indispensable d’avoir un système de versionning de données afin de savoir exactement quelles data ont été utilisées pour quelle analyse et d’être en capacité de reproduire les analyses menées.

3. Adapter ses pratiques aux cas d’usage

Il n’existe pas de méthode unique pour garantir la qualité des données : chaque projet, chaque domaine, chaque dataset demande une approche spécifique.
On devra donc mettre en place une stratégie sur-mesure, alignée avec les exigences de l’AI Act tout en restant cohérente avec les contraintes métier et techniques.

Et surtout : tout doit être documenté. Chaque choix méthodologique ou technique concernant les données doit être justifié, traçable et mis à disposition pour l’auditabilité et la conformité.

III. Expérimentation et entraînement de modèle

 

Une fois la qualité des données validée, nous pouvons passer à l’étape centrale du développement : la conception et l’entraînement du modèle, cœur de la majorité des systèmes d’IA.

Les configurations possibles pour un système d’IA sont quasi infinies, de l’enchaînement de modèles aux pipelines conditionnelles mêlant règles métier et modèles de ML, en passant par les systèmes utilisant des LLM fine-tuné ou non, etc.

Pour simplifier l’analyse, nous nous plaçons ici dans un cas général : un modèle unique, entraîné à 100 % sur nos propres données, à l’aide d’une librairie classique (comme scikit-learn, XGBoost, etc.).

Pour les architectures plus complexes, il conviendra d’adapter les principes présentés ici aux spécificités de votre système.

Dans ce cadre, une bonne analyse exploratoire des données permet d’orienter le choix du modèle. Différents modèles peuvent être testés avec une optimisation des hyperparamètres, et le ou les modèles les plus performants sur le dataset de test sont retenus.

Ce modèle sera intégré dans une pipeline complète, avec :

  • Un prétraitement des entrées,

  • Un post-traitement des sorties,

  • Et éventuellement, d’autres logiques métiers.

1. Risk Management System (RMS)

À ce stade, les mesures de mitigation des risques identifiés lors du cadrage doivent être intégrées dans le système.
Il est aussi possible que de nouveaux risques émergent au moment de la conception ou de l’entraînement du modèle. On appliquera alors la même procédure d’identification, d’analyse et de mitigation du risque, sans oublier de les documenter.

On devra expérimenter plusieurs méthodes de mitigation et évaluer leur efficacité en conditions réalistes : tests sur jeux de données simulant des cas d’usage typiques ou extrêmes. On pourra alors sélectionner la méthode la plus pertinente en fonction de son impact réel.
Cette démarche fait partie intégrante du RMS, qui doit être vivant, évolutif et documenté à chaque itération.

2. Transparence & Supervision Humaine

L’exigence de transparence est l’un des piliers de l’AI Act.

Cela implique que le système doit permettre une bonne interprétation des résultats : l’utilisateur (ou l’auditeur) doit pouvoir comprendre pourquoi une prédiction a été faite. Le système doit aussi permettre une supervision humaine effective : un humain doit pouvoir surveiller le comportement du système et, si besoin, annuler ou corriger ses décisions.

Le règlement laisse liberté d’implémentation technique sur ces points. À chaque équipe d’adapter les solutions en fonction de son cas d’usage.

Quelques pistes :

  • Pour l’explicabilité : on pourra utiliser des librairies comme SHAP, LIME, les visualisations de feature importance, le scoring de confiance…

  • Pour la supervision : on pourra mettre en place un workflow de validation humaine, un « bouton d’arrêt », ou des seuils déclenchant des alertes…

Tous ces choix d’implémentation devront être justifiés, tracés et documentés pour garantir la conformité.

3. Cybersécurité

Enfin, l’AI Act rappelle que les best practices en matière de cybersécurité doivent bien évidemment être appliquées à tous les systèmes à haut risque.

IV. Industrialisation du système

 

Une fois le système conçu et le modèle entraîné, on peut enfin passer à la phase de mise en production de la solution.
Peu importe les choix techniques de déploiement (cloud, edge, API, application embarquée, etc.), tout système d’IA à haut risque est soumis à un certain nombre d’obligations préalables avant sa mise en service.

1. Supervision humaine

Il est impératif de s’assurer que la solution de supervision humaine envisagée est compatible avec le mode de déploiement et puisse être maintenue au cours du cycle de vie du système.

Quelques questions à adresser :

  • Les référents responsables de la supervision ont-ils été désignés ?

  • Existe-t-il un processus clair de désignation ou de remplacement en cas d’absence (vacances, changement de poste, etc.) ?

  • Le mécanisme de supervision est-il maintenu tout au long du cycle de vie du système, y compris en phase de scaling ou de réentraînement ?

Tout cela doit être défini et validé en amont du lancement pour garantir une supervision continue et efficace.

2. Notice d’utilisation

Une notice d’utilisation claire et accessible doit être mise à disposition des utilisateurs finaux ou des potentiels deployer.

Elle doit contenir :

  • Les instructions d’utilisation du système (ce qu’il fait et ce qu’il ne doit pas faire),

  • Une description synthétique de son fonctionnement dans un souci de transparence,

  • Les modalités d’interprétation des sorties du système,

  • Les risques identifiés ainsi que les mesures de mitigation mises en place.

Cette notice est essentielle pour garantir une utilisation responsable du système d’IA.

3. Documentation technique et réglementaire

Une documentation complète retraçant l’ensemble des analyses, des décisions de conception et des choix techniques doit être élaborée.

Ses deux objectifs :

  • Démontrer la conformité au regard de l’AI Act, en prouvant que toutes les mesures raisonnables ont été prises pour prévenir et atténuer les risques identifiés.

  • Assurer la maintenabilité du système.

Cette documentation doit être complétée avant le déploiement de la solution et accessible aux différents acteurs concernés.

4. Enregistrement du système

Selon l’article 49 de l’AI Act, tout système à haut risque ainsi que l’entité provider doivent être enregistrés dans une base de données européenne dédiée avant leur mise en service.

Les modalités précises de cette base sont décrites à l’article 71.
À ce jour, la plateforme n’est pas encore opérationnelle, mais sa création est prévue par l’AI Office dans les mois précédant l’entrée en vigueur des obligations des systèmes à haut risque.

Il est donc conseillé de préparer l’ensemble des informations nécessaires à cet enregistrement dès maintenant.

5. Marquage CE

 

Avant toute mise en service ou commercialisation, le système doit également obtenir un marquage CE, preuve de sa conformité réglementaire.

Cela implique :

  • La réalisation d’une évaluation de conformité complète,

  • La rédaction d’une déclaration de conformité à l’AI Act, à conserver à disposition des autorités nationales,

  • L’obtention du marquage CE auprès d’un organisme notifié habilité.

À ce jour, le processus officiel d’attribution et les organismes notifiés chargé de délivrer le marquage CE n’ont pas encore été désignés. Une fois qu’ils le seront, on pourra se référer à la liste des organismes notifiés pour la législation (2024/1689).

Une fois toutes ces obligations remplies, le système peut alors être mis en production et rendu disponible aux utilisateurs finaux.

V. Monitoring après déploiement

 

Le déploiement du système ne marque pas la fin du travail. Bien au contraire, l’AI Act impose un suivi rigoureux en phase d’exploitation, afin de garantir que le système reste conforme, fiable et sûr tout au long de son cycle de vie.

Modèle Drift

Il est important de détecter toute évolution dans la distribution des données d’entrée ou de sortie au cours du temps. En effet, cela pourrait indiquer un changement dans l’environnement réel ou une dégradation progressive de la performance du modèle. En cas de dérive avérée, un réentraînement, une mise à jour du modèle ou une adaptation du design pourra être envisagé.

Conservation des logs de fonctionnement

Autre exigence essentielle : la conservation des logs de fonctionnement. Ces logs, enregistrés automatiquement, doivent permettre d’analyser le comportement du système, notamment en cas d’audit ou de survenue d’un risque. Ils jouent un rôle central dans la traçabilité et l’analyse des incidents.

Risk Management System

Notre RMS intervient maintenant après le déploiement de notre système. Il s’agit de rester attentif à l’émergence de nouveaux risques non identifiés lors du développement initial. L’analyse des retours terrain et des logs de fonctionnement permet de détecter ces nouveaux risques. Toute nouvelle menace doit être analysée, évaluée et documentée, et il faudra intégrer de nouvelles mesures de mitigation dans une mise à jour corrective du système.

Monitoring et Signalement d’Incidents

Enfin, malgré tous les efforts mis en place pour éliminer ou minimiser le risque, des incidents peuvent tout de même survenir. Nous parlons ici d’incidents en lien avec les risques à la santé, à la sécurité et aux droits fondamentaux des citoyens et non d’incidents purement techniques (bien qu’une interruption du système puisse dans certains cas représenter une nuisance pour les utilisateurs). Pour chaque incident, il faudra :

  • s’assurer qu’un lien de causalité avéré ou probable existe entre l’événement et le système d’IA,

  • le signaler aux autorités compétentes dans un délai de 15 jours suivant sa découverte,

  • mener une enquête interne pour comprendre les causes de l’incident et mettre en place les mesures correctives nécessaires.

Des précisions supplémentaires sur cette procédure sont attendues de la part des instances de gouvernance de l’AI Act.

En résumé, le monitoring post-déploiement n’est pas une simple formalité : c’est une démarche proactive, continue et documentée, indispensable pour garantir la fiabilité, la transparence et la conformité des systèmes d’IA à haut risque dans le temps.

VI. Quality Management System (QMS)

 

Comme nous venons de le voir, se conformer à l’AI Act implique de nombreuses obligations qui peuvent, à première vue, paraître complexes à orchestrer dans leur ensemble.

Pour garantir que chaque exigence réglementaire est bien prise en compte tout au long du cycle de vie d’un système d’IA, l’AI Act impose la mise en place d’un Quality Management System (QMS). Ce cadre méthodologique a pour but de structurer les pratiques internes en centralisant les procédures, politiques et instructions nécessaires au respect des exigences du règlement.

Le QMS devra notamment contenir :

  • Une stratégie globale de mise en conformité pour tous les systèmes d’IA développés ou utilisés par l’entreprise.

  • L’intégration systématique de toutes les étapes décrites dans cet article, de la phase de cadrage jusqu’au monitoring post-déploiement.

  • Le rappel des standards et bonnes pratiques à respecter dans le développement.

  • Des protocoles de test et de validation des méthodes de réduction des risques.

  • L’inclusion du Risk Management System, ainsi que les processus associés de suivi et de révision des risques.

  • Les procédures de reporting d’incidents, en lien avec les autorités compétentes.

  • L’articulation avec les outils de monitoring et d’alerte, afin de suivre le fonctionnement en temps réel.

  • La gestion de la documentation : notices d’utilisation, historiques de décisions techniques, logs de fonctionnement.

  • Un processus de gestion des mises à jour des systèmes, assurant que toute modification déclenche automatiquement les tests, vérifications, mesures de mitigation et actions de monitoring nécessaires.

  • Une gestion et un suivi de la communication avec les différents acteurs en lien avec le système d’IA ainsi que les autorités nationales compétentes et les organismes notifiés.

  • Une définition claire de la gouvernance autour des systèmes, précisant les rôles, responsabilités et processus de désignation des référents.

Ici aussi, le règlement ne fixe pas de format unique pour ce système de qualité, laissant aux entreprises une liberté d’implémentation proportionnée à leur taille et leurs ressources (comme le précise l’article 17). Il revient donc à chaque structure de définir une solution adaptée à son contexte.

 

En Conclusion

L’AI Act transforme en profondeur les pratiques Data Science, en particulier pour les systèmes à haut risque. Plus qu’une contrainte, il offre l’occasion de renforcer la rigueur et la transparence des modèles.

Adapter ses workflows, c’est professionnaliser l’IA, fluidifier la collaboration entre équipes et se préparer à un futur où la conformité sera un levier de confiance et un avantage compétitif.

La route n’est pas simple : il faudra repenser certaines étapes du cycle de vie des modèles, mettre en place de nouveaux outils de gouvernance et surtout créer un dialogue fluide entre les équipes techniques, juridiques et métiers. Mais les organisations qui réussiront cette transition auront un avantage stratégique clair : celui de pouvoir déployer des systèmes d’IA responsables et conformes dans un paysage réglementaire de plus en plus exigeant.

Dans un futur article, nous explorerons comment mettre en place un système de gouvernance de l’IA au sein d’une organisation afin d’assurer la qualité et la conformité de nos systèmes.

Tous nos articles