Ressources humaines : quelles données ne devraient jamais alimenter un système d’IA interne ?
Par StratoSentry - 9 février 2026
Les organisations investissent massivement dans l’intelligence artificielle pour optimiser le recrutement, la gestion des talents ou la planification de la main‑d’œuvre. Pourtant, toutes les informations détenues par les services RH ne sont pas compatibles avec ces usages. Entre exigences du RGPD, risques de discrimination et vecteurs d’attaques : quelles catégories de données doivent être exclues catégoriquement des jeux d’entraînement ou d’inférence ? Cet article décrypte le cadre juridique, identifie les données à proscrire, analyse les menaces techniques et propose une gouvernance opérationnelle permettant aux DSI, RSSI, DPO et dirigeants de tirer profit de l’IA sans compromettre la conformité ni la confiance des salariés.
Introduction
Imaginez que le service IA d’une multinationale décide d’alimenter son modèle de recommandation interne avec les dossiers médicaux complets de ses 12 000 employés. En quelques semaines, le système identifie des corrélations entre maladies chroniques et performances, générant des suggestions de mobilité qui, bien qu’apparemment pertinentes, exposent chaque salarié à un risque de discrimination illégale. Le scandale éclate, les autorités de protection des données ouvrent une enquête, et l’entreprise voit son image ternie ainsi que son budget juridique exploser.
Ce scénario n’est pas hypothétique : plusieurs incidents récents (ex. : fuite de données de santé via un modèle de langage en 2022, biais sexistes détectés dans un outil d’évaluation de compétences) montrent que la tentation d’utiliser « tout » le patrimoine RH comme matière première pour l’IA peut rapidement devenir une bévue coûteuse.
L’enjeu est double : respecter les obligations légales (RGPD, Code du travail, directives européennes sur l’IA) et préserver la sécurité et l’équité des modèles. Pour y parvenir, il faut d’abord identifier quelles données doivent être exclues a priori de tout système d’IA interne, puis mettre en place les garde‑fous nécessaires.
1️⃣ Cadre juridique et réglementaire applicable aux données RH
| Texte | Principaux articles / exigences | Portée pour l’IA |
|---|---|---|
| RGPD (UE) 2016/679 – art. 9 | Interdiction de traiter les catégories particulières de données à moins d’une base légale explicite (consentement, obligations légales…) | Toute donnée sensible (santé, origine raciale, opinions politiques…) doit être justifiée et souvent exclue des modèles génériques |
| Code du travail français – L.1221‑6 & L.1121‑1 | Protection de la vie privée du salarié ; limitation du traitement aux seules finalités professionnelles légitimes | Utilisation d’informations privées (ex. : état de santé) doit être proportionnée et documentée |
| Décret n°2021‑1260 (IA Act – projet français) | Obligation d’évaluer les risques discriminants des systèmes automatisés à haut risque, dont les IA RH | Nécessité d’une analyse d’impact avant l’alimentation du modèle |
| CNIL – Guide « Bonnes pratiques IA et données personnelles » (2023) | Recommandations sur la minimisation, l’anonymisation et le contrôle d’accès | Indique explicitement quelles catégories de données RH sont à proscrire ou à pseudonymiser |
| ISO/IEC 27701 (Privacy Information Management) | Cadre de gouvernance de la confidentialité des informations personnelles | Fournit les exigences de documentation et de contrôle d’accès pour les projets IA |
En résumé : le traitement de toute donnée relevant de l’article 9 du RGPD ou de catégories protégées par le droit du travail doit être justifié, limité dans le temps et faire l’objet d’une gouvernance renforcée. L’absence de base légale constitue un motif suffisant pour exclure ces données des systèmes IA internes.
2️⃣ Typologie des données RH à proscrire systématiquement
| Catégorie | Exemple concret | Pourquoi la bannir ? |
|---|---|---|
| Données de santé (diagnostics, traitements, dossiers médicaux) | Certificat d’arrêt maladie, résultats de bilan de prévention | Art. 9 RGPD ; risque de discrimination et de stigmatisation ; modèle inversion peut révéler le statut de santé d’un individu |
| Informations biométriques (empreintes digitales, reconnaissance faciale, données vocales) | Photo d’identité pour badge d’accès, empreinte digitale du pointage | Art. 9 RGPD ; forte identifiabilité, ciblage par attaques de type “spoofing” |
| Données génétiques | Analyse ADN réalisée dans le cadre d’un programme santé volontaire | Art. 9 ; sensibilité extrême, risque de re‑identification même après agrégation |
| Opinions politiques / syndicales | Déclaration d’affiliation à un parti, participation à une grève | Art. 9 ; protection renforcée, risque de représailles professionnelles |
| Croyances religieuses ou philosophiques | Pratique du jeûne pendant le Ramadan, demande d’aménagements liés à la foi | Art. 9 ; discrimination potentielle dans les décisions de promotion ou de mobilité |
| Orientation sexuelle & identité de genre | Déclaration de transition, informations sur la vie affective | Art. 9 ; stigmatisation et biais de genre dans les recommandations d’emploi |
| Informations relatives à la situation familiale (état civil, nombre d’enfants) lorsqu’elles sont utilisées pour des décisions automatisées | Utilisation du nombre d’enfants pour ajuster le salaire ou les horaires | Peut entraîner discrimination indirecte (ex. : charge familiale) |
| Données de sanction disciplinaire (avertissements, mises à pied, procédures judiciaires internes) | Historique complet des sanctions disciplinaires d’un salarié | Risque de biais négatif dans l’évaluation de performance et violation du principe de proportionnalité |
| Informations de géolocalisation fine (traçage GPS en temps réel) | Données de localisation provenant d’applications mobiles de suivi du temps de travail | Intrusion dans la vie privée, exigence de consentement explicite rarement justifiable |
À retenir : toute donnée classée comme « catégorie particulière » au sens du RGPD ou susceptible de créer un déséquilibre de pouvoir doit être exclue a priori des jeux d’entraînement et d’inférence.
3️⃣ Risques techniques liés à l’alimentation d’IA avec ces données
3.1 Fuites et re‑identification
Même lorsqu’une donnée est agrégée, les modèles de génération (LLM, diffusion) peuvent être exploités via des attacks d’inférence d’appartenance ou de reconstruction de données : un adversaire interroge le modèle avec des prompts ciblés et récupère des informations sensibles qui n’étaient pas explicitement stockées.
3.2 Biais discriminants
Les variables comme l’âge, le genre ou l’origine ethnique sont souvent corrélées à d’autres attributs (par exemple : niveau de salaire). Si ces champs sont conservés dans le jeu d’entraînement, le modèle peut apprendre des associations biaisées et reproduire ou amplifier les discriminations existantes.
3.3 Attaques par inversion de modèle
Un attaquant disposant d’un accès limité à l’API du système IA peut reconstruire partiellement les entrées originales (ex. : dossiers médicaux) en analysant les gradients ou les réponses probabilistes, compromettant ainsi la confidentialité des salariés.
3.4 Non‑conformité réglementaire et sanctions
Le non‑respect de l’obligation de minimisation (RGPD art. 5(1)(c)) expose l’entreprise à des amendes pouvant atteindre 4 % du chiffre d’affaires annuel mondial ou 20 M€, sans compter les coûts liés aux actions correctives et à la perte de confiance.
4️⃣ Scénarios d’usage légitimes : où le champ est‑il réellement ouvert ?
| Cas d’usage | Données généralement acceptées | Restrictions |
|---|---|---|
| Recrutement automatisé (tri de CV) | Parcours professionnel, compétences déclarées, diplômes | Exclure les données santé, opinions politiques, informations familiales. Anonymiser le nom et l’adresse dès la phase de présélection. |
| Gestion des talents & planification | Historique de projets, évaluations de performance (objectives), disponibilités | Masquer les raisons exactes d’éventuels écarts de performance (ex. : problème de santé) ; agrégations anonymisées pour l’analyse de tendances. |
| Optimisation du planning | Horaires de travail, préférences de shift, contraintes légales (temps de repos) | Ne pas exploiter les données de suivi GPS fine ou d’activités hors heures contractuelles. |
| Analyse de climat organisationnel | Enquêtes anonymes, scores de satisfaction | Garantir le cryptage et la non‑traçabilité des réponses individuelles ; éviter toute corrélation avec l’identité du répondant. |
Principe clé : chaque cas d’usage doit être précédé d’une analyse d’impact sur la vie privée (PIA) afin de valider que les données employées sont proportionnées, nécessaires et correctement sécurisées.
5️⃣ Architecture sécurisée pour le traitement des données RH
- Ingestion contrôlée : les pipelines ETL intègrent un step de filtrage qui supprime automatiquement toute colonne correspondant aux catégories prohibées (ex. : health_status, political_affiliation).
- Anonymisation / pseudonymisation : avant le stockage, les identifiants directs sont remplacés par des UUID et les attributs sensibles sont agrégés ou floutés selon la technique de differential privacy (ε‑budget contrôlé).
- Chiffrement au repos : toutes les tables du data vault utilisent AES‑256 avec rotation de clés gérée par un HSM (Hardware Security Module).
- Sandbox d’entraînement : l’environnement d’apprentissage est isolé, sans accès réseau externe, afin de limiter le risque d’exfiltration via des canaux cachés.
- Contrôle d’accès basé sur les rôles (RBAC) : seuls les data scientists autorisés et le DPO peuvent visualiser les métadonnées du jeu de données.
Cette architecture répond aux exigences de confidentialité, intégrité et traçabilité tout en conservant la flexibilité requise pour l’expérimentation IA.
6️⃣ Gouvernance des jeux de données RH
| Élément | Action concrète | Responsable |
|---|---|---|
| Inventaire des sources | Catalogue automatisé (CMDB) répertoriant chaque table, champ et propriétaire | DSI / Responsable Data |
| Classification | Tagging selon le niveau de sensibilité (public, interne, sensible, très sensible) | DPO |
| Validation avant ingestion | Workflow d’approbation incluant DPO + RH pour chaque nouveau jeu de données | Comité IA |
| Audit continu | Scans trimestriels à l’aide d’outils de data‑loss‑prevention (DLP) pour détecter les fuites de champs prohibés | RSSI |
| Documentation des bases légales | Registre décrivant le fondement juridique (consentement, obligation contractuelle…) | Juriste conformité |
| Retrait et archivage | Processus automatisé de suppression après X mois d’inactivité ou fin de projet | Responsable IA |
Un processus de gouvernance robuste permet de prouver la conformité lors d’un audit CNIL et de limiter les risques opérationnels.
7️⃣ Points de vigilance spécifiques aux modèles IA
7.1 Model Inversion & Membership Inference
- Symptôme : le modèle renvoie des réponses trop précises lorsqu’on lui fournit un prompt contenant peu d’informations.
- Mitigation : appliquer le differential privacy pendant l’entraînement, limiter la granularité des sorties (ex. : fournir des scores agrégés plutôt que des probabilités individuelles).
7.2 Biais de données déséquilibrées
- Symptôme : performance du modèle fortement variable selon le genre ou l’âge du candidat.
- Mitigation : ré‑échantillonnage, re‑pondération des classes, audits de fairness (ex. : métriques Equal Opportunity, Demographic Parity).
7.3 Dépendance à des données périmées
- Symptôme : le modèle recommande des formations qui ne correspondent plus aux compétences actuelles du marché.
- Mitigation : mise en place d’un pipeline de ré‑entraînement périodique avec validation de la fraîcheur des sources (TTL).
7.4 Risques de rétro‑ingénierie via API
- Symptôme : un utilisateur malveillant récupère les poids du modèle à travers de multiples appels d’API.
- Mitigation : limitation du taux d’appels, authentification forte, monitoring des patterns d’accès anormaux.
8️⃣ Recommandations opérationnelles pour les décideurs
| Priorité | Action | Impact attendu |
|---|---|---|
| 1. Définir une politique de « data‑exclusion » | Interdire formellement le traitement des catégories listées à la section 2 dans tout projet IA RH. | Conformité juridique & réduction du risque de discrimination. |
| 2. Instaurer un pipeline d’anonymisation automatisé | Utiliser des outils certifiés (ex. : Aircloak, ARX) pour pseudonymiser avant le stockage. | Minimisation des données et protection contre les attaques d’inférence. |
| 3. Mettre en place une PIA systématique | Chaque nouveau modèle IA doit passer par une analyse d’impact sur la vie privée validée par le DPO. | Documentation de la justification légale et visibilité du risque résiduel. |
| 4. Appliquer le differential privacy lors de l’entraînement | Choisir un budget ε adapté (ex. : 0,5–1) pour garantir une protection théorique forte. | Limite la capacité d’un attaquant à reconstruire les données d’origine. |
| 5. Auditer régulièrement les jeux de données | Scans trimestriels avec DLP + revue des logs d’accès. | Détection précoce de fuites ou de mauvaises pratiques. |
| 6. Former les équipes IA et RH | Programme de sensibilisation aux risques éthiques et réglementaires. | Adoption d’une culture « privacy‑by‑design ». |
| 7. Documenter le cycle de vie du modèle | Versioning des jeux de données, hyperparamètres, métriques de fairness. | Traçabilité pour les audits internes et externes. |
Conclusion opérationnelle
L’introduction de l’intelligence artificielle dans la fonction ressources humaines offre un potentiel d’efficacité indéniable : réduction du temps de recrutement, meilleure visibilité sur les