Gouvernance des données, IA responsable et règlement européen sur l’IA

L’IA responsable, une préoccupation architecturale

La notion d’IA responsable rassemble les principes que partagent la plupart des cadres : équité, transparence, responsabilité, protection de la vie privée, sûreté, sécurité et robustesse. Énoncés comme des principes, ils sont difficiles à contester et faciles à ignorer. Ils ne deviennent réels que lorsqu’ils sont traduits en propriétés du système : où vont les données et combien de temps elles restent, ce qui est journalisé et qui peut le lire, où une personne peut intervenir, ce qui est documenté et tenu à jour, et ce qui est mesuré, pour quels groupes. Ce sont des décisions d’architecture, souvent coûteuses à ajouter après coup ; c’est pourquoi l’IA responsable a sa place dans les revues de conception et les registres de décisions, et pas seulement dans un document de politique.

Cette section s’appuie sur les principes de protection de la vie privée de la section 8.7 et sur la réflexion éthique de la section 11.8, et les applique à des systèmes dotés de composants appris et probabilistes. Elle aborde ensuite les principaux cadres réglementaires et normatifs qu’un architecte rencontrera : le règlement européen sur l’IA, le NIST AI Risk Management Framework et ISO/IEC 42001.

Gouvernance des données : provenance, licences et données à caractère personnel

La provenance des données est l’origine et l’historique documentés des données : d’où elles viennent, sous quelle licence ou avec quel consentement, et comment elles ont été transformées. Les systèmes d’IA consomment des données de plus de façons que les logiciels ordinaires : les données d’entraînement et de fine-tuning façonnent les poids du modèle, les corpus de récupération façonnent ses réponses, les jeux d’évaluation définissent ce que bon veut dire, et des boucles de rétroaction peuvent réinjecter des sorties comme entrées. Chacune de ces données exige une source connue et une base licite, couverte par une licence, pour son utilisation. Les poids des modèles sont eux aussi soumis à des licences : les modèles à poids ouverts sont publiés sous des licences qui vont de licences open source permissives à des licences sur mesure assorties de restrictions d’usage acceptable ou de conditions pour les très grands utilisateurs, et ces conditions sont des contraintes pour l’architecture au même titre que la licence d’une base de données.

Les données à caractère personnel méritent une attention particulière, car les fonctionnalités d’IA les répandent dans de nouveaux endroits. Chaque prompt envoyé à un modèle hébergé est une communication à un sous-traitant, ce qui, au titre du RGPD, exige un contrat, une localisation appropriée ou un mécanisme de transfert, et de la clarté sur la conservation par le fournisseur et sur la possibilité qu’il utilise les données pour l’entraînement. La minimisation des données s’applique aux prompts : envoyez le numéro de commande et l’article manquant, pas le profil complet du client. Pseudonymisez ou caviardez lorsque la tâche le permet. Le tableau montre les endroits moins évidents où les données à caractère personnel s’accumulent. Le plus difficile concerne les poids des modèles : les données utilisées pour le fine-tuning peuvent être mémorisées et ne peuvent pas être retirées sélectivement ; les données personnelles ou qui changent vite ont donc leur place dans un magasin de récupération (section 12.3), où elles peuvent être filtrées, corrigées et supprimées, et non dans les poids.

Biais et équité

Le biais algorithmique désigne des résultats systématiquement moins bons pour certains groupes de personnes. Il s’introduit par des données historiques qui encodent des discriminations passées, par des groupes sous-représentés dans les données, par des variables indirectes (un code postal qui tient lieu d’origine ethnique), par des choix de mesure (utiliser les arrestations comme indicateur de la criminalité) et par un déploiement dans des contextes pour lesquels le modèle n’a pas été conçu. Les modèles de langage ajoutent leurs propres formes : des associations stéréotypées apprises dans les textes du web et une qualité nettement inégale selon les langues et les dialectes, si bien qu’un assistant de support peut être excellent en anglais et médiocre en polonais ou en gallois.

L’équité peut se définir de plusieurs façons mesurables, par exemple des taux égaux de décisions positives entre les groupes (parité démographique), des taux d’erreur égaux entre les groupes (égalité des chances, ou equalised odds) ou des scores qui correspondent à la même probabilité dans chaque groupe (calibration). Kleinberg, Mullainathan et Raghavan (2016) et Chouldechova (2017) ont montré que, lorsque les groupes ont des taux de base différents, un classifieur ne peut généralement pas satisfaire en même temps la calibration et l’égalité des taux d’erreur. Choisir un critère d’équité est donc un jugement de valeur qui revient aux personnes concernées et à l’organisation, et non un réglage technique par défaut. Le rôle de l’architecte est de rendre ce choix explicite, de ventiler les résultats d’évaluation par groupe et par langue comme dans la section 12.5, et de décider comment les données nécessaires à cette mesure sont collectées et protégées. Mesurer les biais exige souvent des attributs sensibles que le système ne devrait pas détenir par ailleurs ; l’article 10, paragraphe 5, du règlement sur l’IA autorise leur traitement pour détecter les biais dans les systèmes à haut risque, sous réserve de garanties strictes, et les modifications de 2026 ont ajouté une autorisation similaire, assortie de conditions strictes, pour les autres systèmes et modèles d’IA.

Transparence, explicabilité et model cards

La transparence consiste à dire aux personnes à quoi elles ont affaire : qu’elles parlent à une IA, qu’une image est synthétique, à quoi sert un système et dans quels cas il n’est pas fiable. L’explicabilité consiste à pouvoir dire pourquoi une sortie donnée a été produite. Pour les modèles d’apprentissage automatique classiques, des techniques comme l’attribution de caractéristiques (feature attributions) peuvent indiquer quelles entrées ont influencé un score, avec des limites connues. Pour les modèles de langage, les explications sont plus difficiles : le récit qu’un modèle fait de son propre raisonnement est un texte généré qui ne reflète pas nécessairement le calcul qui a réellement produit la réponse. Dans les systèmes à base de LLM, l’explicabilité pratique vient donc de l’architecture plutôt que de l’introspection : montrez les sources récupérées sur lesquelles une réponse s’est appuyée, confiez les décisions lourdes de conséquences à des règles déterministes qui produisent des codes de motif, et journalisez les entrées, les sources et les versions du prompt et du modèle pour que toute décision puisse être reconstituée et contestée par la suite. Lorsque des décisions produisant des effets juridiques ou des effets significatifs similaires sont prises exclusivement par des moyens automatisés, le RGPD ajoute le droit d’obtenir une intervention humaine et le droit à des informations utiles concernant la logique sous-jacente.

Les model cards (fiches de modèle), proposées par Mitchell et ses collègues en 2019, sont de courts documents qui accompagnent un modèle entraîné : ses usages prévus et ses usages hors périmètre, les facteurs (comme les groupes démographiques) selon lesquels il a été évalué, ses métriques et leurs résultats par groupe, ses données d’entraînement et d’évaluation, les considérations éthiques et les mises en garde. Les Datasheets for Datasets (Gebru et al.) font de même pour les données, et de nombreux fournisseurs publient désormais des system cards couvrant tout un système déployé. Pour les architectes, ce sont à la fois des entrées (lisez la fiche de chaque modèle que vous adoptez, y compris ses limites et sa licence) et des sorties (publiez-en une pour votre propre système, conservée dans le dépôt et mise à jour à chaque version, à côté de la documentation d’architecture du chapitre 4).

Contrôle humain

Le contrôle humain prend trois formes courantes : une personne approuve chaque décision avant qu’elle prenne effet (humain dans la boucle, human in the loop), une personne surveille le système et peut intervenir (humain sur la boucle, human on the loop), ou des personnes décident quand et comment le système est utilisé, et même s’il l’est (humain aux commandes, human in command). Un contrôle ne vaut que ce que vaut sa conception. Le biais d’automatisation, c’est-à-dire la tendance à accepter la recommandation d’un système sans réel examen, transforme des relecteurs qui approuvent des centaines de suggestions de l’IA par heure en simple tampon, qui ajoute de la responsabilité juridique mais aucune sûreté.

Un contrôle efficace se conçoit dès le départ : montrez les éléments de preuve et les sources derrière chaque recommandation, pas seulement la réponse ; rendez le désaccord facile et consignez-le ; dimensionnez de manière réaliste la charge de relecture ; insérez périodiquement des cas connus comme erronés pour vérifier que les relecteurs les repèrent ; mesurez les taux d’infirmation (override rates : un taux proche de zéro est un signal d’alerte, pas un succès) ; et donnez aux opérateurs un moyen testé de suspendre ou d’arrêter le système. La section 12.2 traite des conceptions avec humain dans la boucle et de leur planification de capacité. L’article 14 du règlement sur l’IA exige que les systèmes à haut risque soient conçus de sorte que les personnes chargées du contrôle puissent comprendre les capacités et les limites du système, rester conscientes du biais d’automatisation, interpréter les sorties, décider de ne pas les utiliser ou de passer outre, et interrompre le système.

Le règlement européen sur l’IA

Le règlement européen sur l’IA (AI Act), règlement (UE) 2024/1689, est la première loi horizontale complète sur l’IA. Il est entré en vigueur le 1er août 2024 et s’applique par étapes. Il réglemente selon le risque, attribue des obligations principalement aux fournisseurs (qui développent un système ou un modèle et le mettent sur le marché sous leur nom) et aux déployeurs (qui l’utilisent dans un cadre professionnel), et sa portée dépasse l’UE : il s’applique aux fournisseurs qui mettent des systèmes sur le marché de l’UE ainsi qu’aux fournisseurs et déployeurs établis ailleurs dont les sorties des systèmes sont utilisées dans l’UE. Les sanctions pour les pratiques interdites peuvent atteindre 35 millions d’EUR ou 7 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu, avec des plafonds plus bas pour les autres infractions.

Le règlement classe les systèmes en quatre niveaux, plus une filière distincte pour les modèles. Les pratiques interdites (article 5) comprennent la notation sociale, les techniques manipulatrices ou trompeuses et l’exploitation des vulnérabilités qui causent un préjudice important, le moissonnage non ciblé d’images faciales, la reconnaissance des émotions sur le lieu de travail et dans les établissements d’enseignement (sauf exceptions étroites), la catégorisation biométrique visant à déduire des caractéristiques sensibles, la prédiction d’infractions pénales sur la seule base du profilage, et l’identification biométrique à distance en temps réel dans des espaces accessibles au public à des fins répressives, sauf dans des cas restreints. Les systèmes à haut risque (article 6) sont les composants de sécurité de produits couverts par la législation de l’UE sur la sécurité des produits énumérée à l’annexe I, ainsi que les systèmes utilisés dans les domaines énumérés à l’annexe III : biométrie, infrastructures critiques, éducation, emploi et gestion de la main-d’œuvre, accès aux services privés et publics essentiels (comme l’évaluation de la solvabilité et la tarification de l’assurance vie et maladie), répression, migration et contrôle aux frontières, justice et processus démocratiques. Un système relevant de l’annexe III peut échapper à la catégorie à haut risque en vertu de l’article 6, paragraphe 3, s’il n’exécute qu’une tâche étroite ou préparatoire et ne présente pas de risque important, mais jamais s’il effectue un profilage de personnes. Les obligations de transparence (article 50) imposent d’informer les personnes lorsqu’elles interagissent avec un système d’IA, sauf si c’est évident, de marquer dans un format lisible par machine les contenus générés ou manipulés, et de signaler les hypertrucages (deepfakes). Les systèmes à risque minimal, qui sont la grande majorité, ne sont soumis à aucune nouvelle obligation spécifique, même si la disposition de l’article 4 sur la maîtrise de l’IA s’applique de manière générale aux fournisseurs et aux déployeurs.

Les modèles d’IA à usage général (GPAI), comme les grands modèles de langage qui sous-tendent la plupart des assistants, sont réglementés au niveau du modèle. En vertu de l’article 53, leurs fournisseurs doivent tenir une documentation technique, fournir aux fournisseurs en aval les informations dont ils ont besoin, mettre en place une politique visant à respecter le droit de l’UE en matière de droit d’auteur et publier un résumé du contenu utilisé pour l’entraînement. Les modèles présentant un risque systémique, présumé lorsque la puissance de calcul utilisée pour l’entraînement dépasse 10²⁵ opérations en virgule flottante, sont soumis à des obligations supplémentaires en vertu de l’article 55 : évaluation, y compris des essais contradictoires, atténuation des risques, signalement des incidents graves et cybersécurité. Un code de bonnes pratiques pour l’IA à usage général, publié en juillet 2025, offre aux fournisseurs un moyen volontaire de démontrer leur conformité. Une entreprise qui construit une application sur le modèle d’un autre est normalement fournisseur ou déployeur d’un système d’IA, et non du modèle, mais elle peut devenir fournisseur du modèle si elle le modifie substantiellement.

Le calendrier et les modifications de 2026

Les obligations du règlement devaient s’appliquer par étapes entre février 2025 et août 2027. En novembre 2025, la Commission européenne a proposé un omnibus numérique sur l’IA pour simplifier la mise en œuvre, principalement parce que les normes harmonisées et les lignes directrices nécessaires aux règles sur le haut risque étaient en retard. Après un accord entre le Parlement européen et le Conseil, il a été adopté sous la forme du règlement (UE) 2026/1744 du 8 juillet 2026, publié au Journal officiel le 24 juillet 2026 et en vigueur depuis le 27 juillet 2026. Il reporte les obligations relatives au haut risque à des dates fixes (le 2 décembre 2027 pour les systèmes de l’annexe III et le 2 août 2028 pour ceux de l’annexe I) ; ajoute l’interdiction des systèmes d’IA qui génèrent ou manipulent du matériel relatif à des abus sexuels sur enfants ou des images intimes de personnes identifiables sans leur consentement ; accorde aux fournisseurs de systèmes génératifs déjà sur le marché une période transitoire de quatre mois pour le marquage lisible par machine ; transforme l’obligation de maîtrise de l’IA, qui passe de garantir un niveau suffisant de maîtrise à prendre des mesures pour la favoriser ; ajoute une base juridique, sous des conditions strictes, pour traiter des catégories particulières de données à caractère personnel afin de détecter et de corriger les biais au-delà des systèmes à haut risque ; étend aux petites entreprises à moyenne capitalisation les simplifications prévues pour les PME ; déplace le règlement sur les machines de la section A vers la section B de l’annexe I, de sorte que les exigences applicables à l’IA dans les machines soient appliquées par ce règlement plutôt que directement en vertu du règlement sur l’IA ; et renforce le rôle du Bureau de l’IA dans la surveillance des systèmes d’IA construits sur des modèles à usage général. Les interdictions et les obligations relatives aux modèles d’IA à usage général déjà en vigueur n’ont pas été reportées, et les obligations de transparence de l’article 50 s’appliquent à partir du 2 août 2026 comme prévu.

Une proposition distincte d’omnibus numérique de novembre 2025, qui modifierait le RGPD, les règles ePrivacy et le règlement sur les données (Data Act), suit sa propre procédure législative ; vérifiez si elle a été adoptée, et concevez en fonction du droit en vigueur, pas des propositions. Vérifiez le texte consolidé actuel du règlement sur l’IA avant de vous fier à une quelconque date du tableau ci-dessous.

Qu’est-ce que cela signifie pour la plateforme de livraison de repas ? L’assistant de support client ne relève pas d’un domaine de l’annexe III : il n’est donc pas à haut risque, mais il doit indiquer aux clients qu’ils parlent à une IA, et le RGPD s’applique pleinement à ses prompts et à ses journaux. Les systèmes de la même entreprise consacrés aux livreurs sont une autre affaire : une IA qui attribue du travail aux livreurs sur la base de leur comportement ou de leurs caractéristiques, surveille et évalue leurs performances ou décide de leur désactivation relève du domaine de l’emploi et de la gestion de la main-d’œuvre de l’annexe III, et donc du régime du haut risque à partir de décembre 2027, ainsi que de la directive européenne sur le travail via une plateforme (directive (UE) 2024/2831) en matière de gestion algorithmique, que les États membres doivent transposer d’ici décembre 2026. La classification suit la finalité, pas la technologie : un même modèle peut servir un usage à risque minimal et un usage à haut risque dans la même entreprise.

Cadres et normes : NIST AI RMF et ISO/IEC 42001

Le NIST AI Risk Management Framework (AI RMF 1.0, NIST AI 100-1, janvier 2023) est un cadre américain volontaire, largement utilisé à l’international. Il organise la gestion des risques liés à l’IA en quatre fonctions : Govern (gouverner : culture, politiques, rôles et responsabilité), Map (cartographier : contexte, usage prévu et impacts potentiels), Measure (mesurer : analyse, test et suivi des risques) et Manage (gérer : hiérarchisation et traitement des risques, et réponse aux incidents). Il décrit une IA digne de confiance comme valide et fiable, sûre, sécurisée et résiliente, responsable et transparente, explicable et interprétable, respectueuse de la vie privée, et équitable, avec une gestion des biais préjudiciables. Son profil pour l’IA générative (Generative AI Profile, NIST AI 600-1, juillet 2024) ajoute des risques et des actions propres aux modèles génératifs. Consultez le site du NIST pour connaître la version actuelle et ses profils associés avant de le citer.

ISO/IEC 42001:2023 spécifie les exigences d’un système de management de l’IA : les politiques, les rôles, les appréciations des risques et des impacts, les mesures de maîtrise, la surveillance et l’amélioration continue par lesquels une organisation encadre ses activités d’IA, dans le même style Plan-Do-Check-Act que l’ISO/IEC 27001 pour la sécurité de l’information. Contrairement au cadre du NIST, elle est certifiable, et les organisations demandent de plus en plus souvent la certification à leurs fournisseurs. ISO/IEC 23894:2023 donne des lignes directrices sur la gestion des risques liés à l’IA. Les trois s’articulent : le règlement sur l’IA énonce des obligations légales, des normes européennes harmonisées (en cours d’élaboration par le CEN et le CENELEC) décriront comment les respecter, et le cadre du NIST et ISO/IEC 42001 fournissent les pratiques de management dans lesquelles les preuves sont produites.