Biais IA : les données sensibles restent une exception

Le 27 juillet 2026, le Digital Omnibus on AI est entré en vigueur. Une modification mérite l’attention des PME qui utilisent l’IA pour recruter, évaluer, orienter des clients ou prioriser des dossiers : le nouvel article 4a de l’AI Act ouvre une voie pour détecter certains biais avec des données sensibles.

Ce n’est pas une autorisation générale. C’est une exception étroite, entourée de six conditions cumulatives. Elle commence par une question que le fournisseur ne peut pas éluder : pourquoi le test serait-il impossible avec des données ordinaires, synthétiques ou anonymisées ?

Si cette démonstration manque, la collecte ne doit pas commencer.

Règlement (UE) 2026/1744 et Commission européenne, vérifiés le 29 juillet 2026.

Le problème réel : mesurer sans créer un second risque

Un système peut sembler précis dans l’ensemble et échouer davantage pour certains groupes. Un outil de présélection peut écarter plus souvent un profil. Un modèle de fraude peut multiplier les faux positifs. Un assistant de triage peut produire des recommandations moins fiables selon l’âge ou l’état de santé.

Pour observer ces écarts, il faut parfois comparer les résultats entre groupes. Or les variables utiles à cette comparaison peuvent relever des catégories particulières du RGPD : origine raciale ou ethnique, opinions politiques, convictions religieuses, appartenance syndicale, données génétiques, données biométriques d’identification, santé, vie sexuelle ou orientation sexuelle.

Le paradoxe est connu : ignorer ces caractéristiques peut cacher une discrimination, mais les collecter crée un risque supplémentaire pour les personnes. L’article 4a ne supprime pas ce conflit. Il organise une voie exceptionnelle pour le traiter.

L’Autorité de protection des données belge rappelle que le traitement de ces catégories est interdit par principe, sauf exceptions déterminées. Les données relatives aux condamnations et infractions suivent, elles, un régime distinct. Un fichier ne devient donc pas « données de test » par simple changement d’étiquette.

Les six conditions à mettre dans le dossier

Le nouveau texte ne demande pas une promesse générale de prudence. Il énumère six protections concrètes.

Condition	Preuve minimale à demander
Les autres données ne suffisent pas	Note expliquant pourquoi les données ordinaires, synthétiques ou anonymisées rendent le test inefficace
La réutilisation est techniquement limitée	Environnement isolé, finalité verrouillée et pseudonymisation
L’accès est strictement protégé	Liste nominative des accès, journalisation et engagement de confidentialité
Aucune autre partie n’accède aux données	Schéma des flux montrant l’absence de transmission ou d’accès tiers
La suppression intervient au plus tôt	Règle automatique liée à la correction du biais ou à la fin de conservation
La nécessité est inscrite au registre	Motif du traitement et justification de l’impossibilité d’utiliser d’autres données

Article 4a du règlement (UE) 2024/1689, inséré par le règlement (UE) 2026/1744, vérifié le 29 juillet 2026.

Ces conditions sont cumulatives. Une pseudonymisation ne compense pas un transfert au fournisseur. Une durée courte ne compense pas l’absence de nécessité. Un accord de confidentialité ne transforme pas une base de données entière en échantillon proportionné.

Le texte distingue aussi les situations. Le fournisseur d’un système à haut risque peut exceptionnellement traiter ces données lorsque c’est strictement nécessaire pour satisfaire les exigences de qualité des données. Pour les autres systèmes et modèles, ainsi que pour les déployeurs de systèmes à haut risque, le biais recherché doit en plus être susceptible d’affecter la santé, la sécurité, les droits fondamentaux ou de conduire à une discrimination interdite.

Autrement dit, un léger écart de confort ou de style ne suffit pas à ouvrir cette porte.

Le cloud rend la question contractuelle immédiate

Dans une PME, le test est rarement réalisé seul. Le fournisseur du logiciel, un intégrateur ou un consultant propose souvent d’analyser les résultats. C’est précisément là que la quatrième condition devient décisive : les catégories particulières utilisées sous cette exception ne peuvent pas être transmises, transférées ou rendues accessibles à d’autres parties.

Un export brut vers un portail fournisseur ne peut donc pas être justifié par une simple ligne « test de biais » dans le contrat. Il faut revoir l’architecture avant la collecte.

Trois options plus sobres existent :

1. calculer localement des indicateurs agrégés et ne partager que les résultats non personnels ;
2. faire exécuter le test dans un environnement contrôlé par la PME, sans accès du fournisseur aux données sensibles ;
3. produire un jeu synthétique ou anonymisé et documenter pourquoi il permet — ou non — de mesurer le biais recherché.

Si aucune option ne fonctionne, le dossier doit expliquer la stricte nécessité, les rôles RGPD, les accès, la sécurité, la conservation et la suppression. Une analyse d’impact peut également être requise lorsque le traitement est susceptible d’engendrer un risque élevé. L’article 4a ne remplace ni cette analyse ni le reste du RGPD.

Le Comité européen de la protection des données et le Contrôleur européen avaient soutenu une exception circonscrite aux biais susceptibles de produire des effets suffisamment graves. Le texte adopté retient cette logique pour les fournisseurs et déployeurs des autres systèmes : santé, sécurité, droits fondamentaux ou discrimination interdite.

Avis conjoint EDPB-EDPS sur le Digital Omnibus on AI et RGPD, vérifiés le 29 juillet 2026.

Un test utile commence avant les données

La première réunion ne doit pas porter sur les colonnes disponibles. Elle doit définir la décision examinée.

Prenons un outil de présélection de candidatures. « Vérifier les biais » est trop vague. Il faut préciser le résultat : passage à l’étape suivante, score, recommandation ou rejet. Il faut ensuite choisir l’écart étudié, la période, les personnes concernées et le seuil qui déclenche une correction.

Cette définition évite deux erreurs.

La première est de collecter des caractéristiques sensibles sans savoir comment elles seront utilisées. La seconde est de produire un tableau d’écarts sans relier ceux-ci à une décision réelle. Un écart statistique ne dit pas, à lui seul, pourquoi le système se comporte ainsi ni quelle correction est appropriée.

Le test doit aussi séparer trois niveaux :

• les données d’entrée, qui peuvent déjà refléter des inégalités historiques ;
• le comportement du modèle, qui peut amplifier ou atténuer ces écarts ;
• la décision humaine ou métier, qui peut corriger, ignorer ou renforcer la sortie.

Tester seulement le modèle laisse les deux autres niveaux hors champ. Pour une PME, le livrable utile reste donc un petit dossier de décision : risque étudié, méthode, données minimales, résultat, correction et contrôle après correction.

La checklist avant toute collecte

• Nommer la décision ou la sortie dont le biais est recherché.
• Décrire l'effet possible sur la santé, la sécurité, les droits ou la discrimination.
• Tester d'abord des données ordinaires, synthétiques ou anonymisées.
• Documenter pourquoi ces alternatives échouent si des données sensibles restent nécessaires.
• Limiter l'échantillon, la durée et les personnes autorisées.
• Vérifier qu'aucune autre partie ne reçoit ou ne consulte les données.
• Inscrire la nécessité et les accès dans le registre des traitements.
• Déclencher la suppression dès la correction du biais.
• Décider si une analyse d'impact et l'avis du DPO sont nécessaires.

Autorité de protection des données, données sensibles, vérifié le 29 juillet 2026.

La décision de lundi matin

Si un fournisseur demande des données sensibles pour « auditer l’équité », ne commencez pas par l’export. Demandez une note d’une page qui répond à cinq questions : quel biais, quel dommage possible, quelles alternatives ont échoué, qui verra les données et quand seront-elles supprimées ?

Sans réponses précises, l’article 4a ne sécurise pas le projet. Avec elles, la PME peut décider si le test est nécessaire, si son architecture est compatible avec les garde-fous et si le risque justifie réellement l’exception.

Le nouvel Omnibus facilite un test qui était juridiquement difficile. Il ne rend pas les données sensibles ordinaires. La bonne mesure du biais commence par une mesure de la collecte elle-même.