Comment les équipes RH peuvent déployer des applications créées avec l’IA sans exposer les données des salariés

La société de cybersécurité RedAccess a recherché des applications créées avec des outils de développement assisté par IA et publiées sur l’hébergement de ces outils. Elle en a trouvé plus de 5 000 sans presque aucune sécurité ni authentification. Parmi les captures d’écran transmises à Wired figuraient ce qui semblait être les affectations professionnelles d’un hôpital, accompagnées des informations personnelles des médecins.

Les outils de développement assisté par IA ont simplifié la création. Dans les applications créées avec l’IA pour les équipes RH, l’exposition vient ensuite, lorsqu’un suivi des congés ou une grille d’entretien est mis en ligne comme pendant la démonstration : un lien public, un seul accès administrateur et toute la table des salariés derrière.

En bref

• Un outil contribuant aux décisions de recrutement, de promotion ou d’évaluation peut être considéré comme à haut risque au titre du règlement européen sur l’IA. Il doit passer par l’informatique et le service juridique ou le DPO avant d’attribuer une note à qui que ce soit.
• Les dossiers des salariés ne doivent jamais rester sur l’hébergement de l’outil de développement assisté par IA. Par défaut, utilisez un serveur contrôlé par l’équipe, accessible uniquement sur un réseau privé, avec l’authentification de l’entreprise en amont lorsque les responsables ou tous les salariés doivent y accéder.
• Les corrections passent par l’outil d’IA qui a créé l’application : limiter les champs lus, donner des vues différentes aux administrateurs RH, aux responsables et aux salariés, sortir les identifiants du code, réduire les données envoyées à l’extérieur, journaliser les accès aux dossiers et traiter les demandes de suppression selon les obligations de conservation. Vous devez vérifier vous-même chaque correction ; le rapport de l’IA ne suffit pas.
• L’accès à l’outil doit cesser le jour où l’emploi prend fin. Une personne désignée doit en être responsable, et choisir l’emplacement d’un serveur ne rend pas le système conforme.

Les erreurs de déploiement qui exposent les données des salariés

Un outil RH créé avec l’IA expose les données des salariés à toute personne qui trouve son lien, possède un identifiant collé dans une conversation ou dans le code, ouvre les dossiers d’un collègue, reçoit les données via un service externe ou a quitté l’entreprise. Sans journal, personne ne sait qui a consulté quoi. Lire toute la table des salariés élargit chacune de ces voies d’exposition.

La première ligne correspond au problème que RedAccess a observé à grande échelle. Dans le reportage de Wired sur les conclusions de RedAccess, trois des quatre entreprises de développement assisté par IA ont contesté les affirmations des chercheurs (la quatrième n’a pas répondu), sans nier que les applications créées par vibe coding trouvées par RedAccess étaient exposées. J’y vois un problème de configuration et une étape de vérification oubliée.

Vérifiez si l’outil contribue aux décisions de recrutement, de promotion ou d’évaluation

Le fait d’être créé avec un outil de développement assisté par IA ne rend pas, à lui seul, un outil RH à haut risque au titre du règlement européen sur l’IA. C’est sa fonction qui le détermine. L’annexe III du règlement européen sur l’IA recense les systèmes d’IA utilisés pour recruter ou sélectionner des personnes, décider des promotions et des licenciements, attribuer des tâches ou surveiller et évaluer les performances.

Avant de décider où héberger l’outil, posez cette question : prend-il ou influence-t-il une décision concernant le recrutement, la promotion, le licenciement, l’attribution de tâches ou l’évaluation des performances ?

Un suivi des congés, une liste d’intégration ou un annuaire interne stocke les dossiers et les restitue : il se situe donc du côté « non ». Une grille d’entretien classant les candidats ou un outil notant les performances, surtout si un modèle d’IA attribue les notes, peut être du côté « oui ». Si je ne sais pas trancher, je retiens « oui » et laisse l’informatique et le juridique me dire le contraire.

Le règlement ne concerne pas uniquement les entreprises européennes : l’article 2 couvre les fournisseurs et les déployeurs établis hors de l’UE lorsque les résultats de leur système d’IA sont utilisés dans l’UE. Selon l’article 113 modifié, les obligations applicables aux systèmes à haut risque de l’annexe III prennent effet le 2 décembre 2027. Elles comprennent un système de gestion des risques, la gouvernance des données, la documentation technique, la tenue de registres, la transparence envers les déployeurs et le contrôle humain (articles 9 à 14). Leur évaluation relève de l’informatique et du juridique.

Si la réponse est oui, arrêtez-vous avant que l’outil ne note un seul candidat ou salarié réel. Présentez-le à l’informatique et au responsable juridique ou de la protection des données, le DPO lorsqu’il existe. Cette vérification ne décide pas si un outil précis relève du règlement ; elle indique qui doit le déterminer. Certains États américains réglementent aussi les décisions automatisées de recrutement ; leurs règles figurent dans le tableau plus bas.

Vous pouvez préparer cette analyse. Je demanderais à l’outil d’IA de remettre en cause sa notation plutôt que de la défendre :

Cette application note ou classe des candidats ou des salariés. Liste chaque champ et chaque étape de calcul contribuant à la note ou au classement. Pour chacun, indique s’il pourrait refléter directement ou indirectement une caractéristique protégée : âge, race, sexe, nationalité, origine ethnique, handicap, grossesse, religion ou orientation sexuelle. Si tu n’es pas sûr, dis-le au lieu de deviner. Signale ensuite tout problème d’équité dans cette notation que je devrais examiner mais que je n’ai pas mentionné.

Vérification : considérez la réponse comme une liste initiale destinée aux personnes qui examinent l’outil, pas comme un verdict. Transmettez-la avec l’outil. Exécuter cette consigne ne constitue pas un audit des biais et ne satisfait à aucune obligation juridique.

Où héberger un outil RH

Gardez les dossiers des salariés hors de l’hébergement de l’outil d’IA. Pour un usage limité aux RH, le choix par défaut est un serveur contrôlé par l’équipe, accessible uniquement sur un réseau privé, avec l’authentification de l’entreprise en amont dès que les responsables ou salariés doivent l’utiliser. Un outil ayant échoué à la vérification des décisions de recrutement, ou dont personne ne peut gérer le serveur, doit être confié à l’informatique.

Publier sur l’hébergement de l’outil de développement assisté par IA place l’application à une adresse du domaine du fournisseur. Si sa visibilité n’est pas privée, toute personne trouvant cette adresse peut y accéder. RedAccess a identifié des milliers de ces applications avec de simples recherches Google et Bing sur ces domaines. Un réseau privé fonctionne à l’inverse : l’outil ne répond qu’aux appareils qui l’ont rejoint. L’authentification de l’entreprise, ou connexion unique, permet aux collègues d’utiliser leur compte habituel, vérifié par un fournisseur d’identité, le service qui gère ces comptes.

Tant que l’outil ne fonctionne pas sur le serveur de l’équipe, créez-le et testez-le avec des données synthétiques : des noms, salaires et dates de congés fictifs ayant la forme des données réelles. Un tunnel gratuit entre un ordinateur portable et une adresse publique est public au même titre que l’hébergement du fournisseur ; il appartient donc aussi à la phase de démonstration.

Pourquoi un réseau privé plutôt que la page de connexion existante ? Sur un réseau privé, l’outil ne répond pas du tout aux personnes extérieures : elles ne peuvent ni le charger, ni le sonder, ni essayer des mots de passe. Une page de connexion écrite par l’IA ne suffit pas à elle seule. Tout le monde peut y accéder, et sa résistance dépend du code généré. Le rapport 2025 de Veracode sur la sécurité du code GenAI a constaté que 45 % des échantillons de code testés, issus de plus de 100 modèles, échouaient aux tests de sécurité avec une vulnérabilité de l’OWASP Top 10, une liste reconnue des principaux risques des applications web. C’est pourquoi je préfère placer un verrou devant l’application plutôt que me fier à celui écrit par l’IA.

Pour le transfert, l’outil fonctionne sur un VPS, un serveur loué entièrement contrôlé par l’équipe, avec un outil de déploiement comme Coolify ou Dokku qui exécute l’application à partir de son code. Coolify permet aussi de revenir à une version précédente depuis son tableau de bord après une mauvaise mise à jour. Le choix entre Coolify et Dokku dépend surtout du nombre d’applications à héberger et de la préférence de l’aide informatique pour un tableau de bord. Le réseau privé utilise Tailscale ou WireGuard. Tailscale est plus rapide à mettre en place, mais son service de coordination est exploité par Tailscale, tandis que WireGuard est entièrement auto-hébergé. L’authentification de l’entreprise passe par un fournisseur d’identité comme Authentik ou Keycloak. Un proxy inverse comme Caddy ou Nginx Proxy Manager ajoute HTTPS lorsque l’authentification est exposée au web. Confiez cette partie à l’aide informatique, avec la liste de vérification finale.

Les corrections, sous forme de consignes pour votre outil d’IA

La plupart des corrections permettant de déployer une application RH créée avec l’IA en sécurité passent par l’outil qui l’a construite, mais seulement si vous les demandez. Comme l’a expliqué le chercheur en sécurité Joel Margolis à Wired, ces outils « font ce que vous leur demandez. Et si vous ne leur demandez pas de le faire de façon sécurisée, ils ne vont pas prendre cette initiative ».

Considérez chaque consigne ci-dessous comme un point de départ et adaptez les noms des champs et les rôles à votre outil. Je considère l’IA comme l’ingénieur et moi-même comme le vérificateur : son annonce de correction est donc un brouillon. La vérification qui suit chaque consigne fournit la preuve, sans vous demander de lire du code. Si elle échoue, renvoyez la correction à l’IA et ajoutez la leçon dans un fichier de règles pour votre outil d’IA, afin que la prochaine session en tienne compte. Chaque consigne demande aussi à l’outil de signaler ses incertitudes ; reconnaître une lacune vaut mieux qu’afficher une assurance trompeuse. Exécutez-les sur le code et de faux dossiers, sans jamais coller des données réelles ou des mots de passe dans la conversation.

Repérez les champs des salariés utilisés par l’outil, puis interdisez l’accès aux autres

Vous ne pouvez pas bloquer un champ dont vous ignorez la présence. La première consigne est donc un audit :

Examine la base de données, le code, les écrans et les exports de cette application. Liste tous les champs susceptibles de contenir des données personnelles d’un salarié ou candidat : noms, identifiants de salariés, SSN ou identifiants nationaux, identifiants fiscaux, dates de naissance, adresses personnelles, informations de santé, handicap, dossiers d’aménagement, documents d’immigration ou d’autorisation de travail, salaire, primes, participation au capital, notes de performance et notes disciplinaires. Pour chacun, indique quel écran ou quelle fonction l’utilise et s’il est nécessaire à l’objectif principal de l’application. Si tu ne peux pas le déterminer, marque-le comme incertain au lieu de deviner.

Vérification : ouvrez les écrans principaux et les exports et assurez-vous que chaque champ de données personnelles visible figure dans la liste. Si un champ visible manque, l’audit est incomplet : redemandez-le.

La deuxième consigne retire les données inutiles. Elle repose sur le compte utilisé par l’application pour accéder à sa base de données, dont les droits peuvent être limités à certains champs.

Modifie cette application pour qu’elle ne lise que ces champs : [liste des champs nécessaires]. Supprime tous les autres champs de données personnelles de sa copie des données, du code, des écrans et des exports. Crée ensuite un compte de base de données distinct pour l’application, qui ne puisse lire que ces champs et ne modifier que les données écrites par l’outil lui-même, comme les demandes de congés. Fais utiliser ce compte par l’application. Décris exactement chaque modification, fichier par fichier, et signale ce que tu n’as pas pu faire.

Modifier seulement les écrans ne suffit pas. Si le compte de base de données ne peut pas lire la colonne des salaires, un bug ailleurs dans le code généré ne pourra pas non plus l’afficher. Le chiffrement des données au repos relève de l’informatique : il dépend de la configuration du serveur et des disques, qu’un assistant examinant le code ne peut pas vérifier de façon fiable.

Vérification : connectez-vous comme utilisateur ordinaire et ouvrez tous les écrans et exports : aucun champ supprimé ne doit apparaître. Demandez ensuite à l’aide informatique gérant le serveur, ou à l’outil d’IA en exigeant d’en voir le résultat, de demander un champ supprimé avec le compte de base de données de l’application. Une erreur de permission ou indiquant que le champ n’existe pas valide le test. Une erreur de connexion, de syntaxe ou sans rapport ne le valide pas. Une colonne vide ou une valeur constitue un échec. Gardez la liste d’audit, car l’outil de suppression l’utilise.

Donnez des vues différentes aux administrateurs RH, aux responsables et aux salariés

C’est ici que les données fuient en interne, lorsqu’un collègue consulte le salaire d’un pair ou la note d’aménagement d’un membre de l’équipe. Le contrôle d’accès par rôles corrige ce risque ; la consigne précise où la vérification doit avoir lieu :

Ajoute un contrôle d’accès avec trois rôles, vérifiés côté serveur à chaque requête, et pas simplement en masquant les boutons ou liens dans la page.

- Administrateur RH : peut lire et modifier tous les dossiers des salariés.

- Responsable d’équipe : peut lire uniquement les dossiers de ses collaborateurs directs et ne voit jamais les champs de salaire, de santé, d’aménagement, de discipline ou d’immigration.

- Salarié : peut lire uniquement son propre dossier.

Refuse toute autre demande avec une réponse « accès refusé » (403). Prends le rôle de chaque utilisateur dans son compte authentifié, jamais dans une valeur qu’il peut saisir ou modifier dans la page ou la barre d’adresse. Liste tous les endroits où tu as ajouté une vérification et signale les pages ou exports dont la couverture reste incertaine.

Certaines entreprises autorisent les responsables à voir les rémunérations lors des révisions salariales. Si c’est votre cas, adaptez la ligne du rôle responsable.

Vérification : créez un responsable et un salarié de test. Connecté comme responsable, ouvrez le dossier d’un collaborateur direct, copiez son adresse, remplacez le numéro par celui d’une personne hors de l’équipe et chargez la page : vous devez obtenir « accès refusé ». Répétez comme salarié avec le numéro d’un collègue. Vérifiez ensuite que la vue du responsable n’affiche jamais les champs de salaire, d’aménagement ou d’immigration.

Sortez les identifiants du code et de la conversation

Un mot de passe de base de données ou un jeton d’API du SIRH ou de la paie, la longue clé permettant à un système de se connecter à un autre, peut disparaître du code actuel tout en restant dans les versions précédentes. La consigne examine donc aussi l’historique. Une variable d’environnement corrige la partie code : le serveur fournit sa valeur au démarrage, et le code la désigne par son nom sans contenir cette valeur.

Trouve chaque mot de passe, clé d’API, jeton d’accès et chaîne de connexion à une base de données dans ce projet, y compris ceux du SIRH, de la paie et des systèmes de messagerie. Remplace chaque valeur dans le code par une variable d’environnement et donne-moi la liste des noms. Assure-toi que les fichiers contenant les valeurs réelles, comme .env, sont exclus du dépôt. Liste ensuite tous les endroits où une ancienne valeur apparaît encore dans l’historique du projet, afin que je sache quels identifiants remplacer.

La consigne ne peut pas réaliser l’étape essentielle. Dans la console d’administration du SIRH ou de la base de données, créez un nouvel identifiant pour chaque valeur ayant figuré dans une conversation ou dans le dépôt, puis désactivez l’ancienne.

Les copies de ces mots de passe destinées à l’équipe doivent être conservées dans un gestionnaire de mots de passe, comme un serveur Vaultwarden auto-hébergé (quelle option convient à une équipe est une question distincte). Il stocke les identifiants des personnes et n’alimente pas l’application en cours d’exécution, qui reçoit ses valeurs de l’outil de déploiement. Pour les secrets lus par l’application elle-même, HashiCorp Vault est une solution plus lourde, avec des politiques et une rotation centralisées pour les équipes qui en ont besoin.

Vérification : demandez à l’IA de rechercher les anciennes valeurs dans les fichiers actuels et lisez les résultats affichés, pas leur résumé. Ces fichiers ne doivent contenir aucune correspondance. Les correspondances dans l’historique sont normales et n’ont pas besoin d’être effacées : elles indiquent quels identifiants remplacer. La preuve de leur invalidation se trouve dans la console du SIRH ou de la base : chaque ancien identifiant est révoqué, ou l’informatique confirme que le système le refuse.

Vérifiez quelles données des salariés quittent l’outil

Lorsqu’un appel a envoyé les notes d’entretien d’un candidat à un service externe, supprimer le dossier dans votre outil ne supprime pas la copie éventuellement conservée par ce service. La correction consiste donc d’abord à envoyer moins de données.

Audite chaque appel externe de cette application : OpenAI, Anthropic ou toute autre API d’IA, systèmes RH comme le SIRH ou l’ATS, outils d’analyse ou de suivi des erreurs et webhooks. Pour chaque appel, liste exactement les champs des salariés ou candidats envoyés. Signale les services susceptibles de stocker ou journaliser ces données et les appels qui pourraient fonctionner avec moins de données. Indique tes incertitudes.

Vérification : créez un salarié ou candidat fictif avec un nom inventé distinctif, puis utilisez chaque fonction faisant un appel externe : produire le résumé d’entretien, déclencher le webhook ou ouvrir la page chargeant le script d’analyse. Dans le tableau de bord de chaque service, l’outil d’analyse, le suivi des erreurs, le journal des webhooks reçus de l’ATS ou le journal d’utilisation du fournisseur d’IA lorsqu’il montre les requêtes, recherchez ce nom. Il ne doit apparaître que là où l’appel en a besoin. Sinon, renvoyez cet appel à l’IA pour réduire les données, puis retestez. Certains tableaux de bord ne montrent pas les données reçues. Pour ceux-ci, et pour tout service devant continuer à recevoir des données de salariés, soumettez ses conditions de conservation à la personne qui signe les contrats fournisseurs.

Journalisez qui ouvre chaque dossier de salarié

Un salarié demande qui a exporté la feuille des salaires au trimestre précédent. Sans journal d’audit, un historique de qui a fait quoi sur quel dossier, personne ne peut répondre.

Ajoute un journal d’audit. Chaque consultation, modification, export ou suppression d’un dossier doit ajouter une ligne avec l’identifiant de l’utilisateur, celui du dossier, l’action, les champs modifiés et l’heure. Configure la base pour que le compte de l’application puisse ajouter des lignes, sans les modifier ni les supprimer. Seuls les administrateurs RH peuvent lire ce journal dans l’application. Indique où et comment l’interdiction de modification et de suppression est appliquée.

L’ajout seul doit être imposé par les permissions du compte de base de données, pas par une promesse de l’application. Le journal constitue lui-même des données personnelles puisqu’il montre qui a consulté quel dossier : seuls les administrateurs RH doivent donc le lire.

Vérification : comme administrateur RH, ouvrez un dossier puis vérifiez la présence de l’entrée dans le journal. Faites essayer à l’informatique ou à l’IA, en exigeant d’en voir le résultat, de supprimer une ligne avec le compte de base de l’application. Vous devez voir l’erreur de permission elle-même.

Traitez les demandes de suppression sans enfreindre les obligations de conservation

Que se passe-t-il lorsqu’un salarié demande l’effacement de ses données alors que certains dossiers de paie doivent être conservés ? La consigne évidente, « supprimer toutes les données personnelles de ce salarié dans toutes les tables », les supprime quand même et pose deux problèmes. Les employeurs doivent souvent conserver certains dossiers, notamment de paie, fiscaux et d’autorisation de travail. De plus, le droit à l’effacement du RGPD ne s’applique pas dans la mesure où le traitement est nécessaire au respect d’une obligation légale ou à des actions en justice (article 17, paragraphe 3, points b et e). Un bouton supprimant tout est aussi dangereux. La version plus sûre distingue les données à « supprimer sur demande » de celles soumises à une obligation de conservation, qui doivent être gardées malgré la demande, et affiche son plan avant toute suppression :

Crée un outil de demande de suppression accessible uniquement aux administrateurs RH. Pour un identifiant de salarié, il affiche d’abord toutes les tables et tous les champs contenant ses données, regroupés selon les catégories de l’audit. Chaque catégorie a un réglage défini par un administrateur RH : « supprimer sur demande » ou « conserver : obligation de conservation ». Après confirmation d’un administrateur RH, l’outil supprime uniquement les catégories réglées sur « supprimer sur demande ». Il journalise seulement l’identifiant du salarié, l’heure, la personne ayant confirmé et les catégories supprimées ou conservées, sans autre information sur la personne. Les autres utilisateurs obtiennent « accès refusé ».

Les réglages de conservation doivent venir du responsable conformité ou du DPO, pas de l’IA ni d’une estimation du créateur. Précisez que le journal garde l’identifiant du salarié après suppression, afin qu’ils décident combien de temps le conserver. Les sauvegardes et les copies détenues par des services externes nécessitent leur propre procédure de conservation ou de suppression.

Vérification : créez un salarié de test avec des dossiers dans deux catégories, l’une réglée sur « supprimer sur demande », l’autre soumise à conservation obligatoire. Exécutez l’outil comme administrateur RH et vérifiez que seule la première catégorie disparaît. Ouvrez ensuite l’outil avec un compte responsable : vous devez obtenir « accès refusé ».

Les règles relatives à l’emploi à examiner avec votre DPO ou responsable conformité

Les règles applicables à un outil RH dépendent de sa fonction et des personnes dont il détient les données, pas de sa méthode de création. Cette liste sert à discuter avec votre DPO ou responsable conformité ; elle ne constitue pas un avis juridique et ne détermine pas quelles règles vous concernent.

Un suivi des congés conservant des notes d’aménagement pour des salariés en Allemagne et en Californie relève de règles différentes d’un planificateur d’effectifs ne contenant que des intitulés de postes. La question du règlement européen sur l’IA relève de la vérification des décisions de recrutement.

L’emplacement du serveur détermine où les dossiers sont physiquement stockés ; il ne satisfait pas, à lui seul, aux règles ci-dessus. Pour les salariés ailleurs, commencez par le régulateur national, régional ou local compétent en matière de protection des données ou d’emploi, ou par votre responsable juridique ou conformité.

L’accès cesse lorsque l’emploi prend fin

Lorsque le compte d’entreprise d’une personne est désactivé le jour de son départ, sa messagerie, son calendrier et ses fichiers deviennent inaccessibles en une seule opération. L’outil RH doit suivre cette même opération. L’authentification de l’entreprise le permet si le processus de départ révoque aussi les sessions actives. Tout outil sans cette authentification doit avoir sa propre ligne dans la liste de départ, pour qu’une personne supprime manuellement le compte.

Le créateur finira lui aussi par partir. Lorsqu’il quitte l’entreprise ou change de rôle, la responsabilité passe à un successeur nommé, capable de se connecter comme administrateur et sachant où se trouve le serveur. L’accès administrateur personnel du créateur est fermé. Je nommerais ce successeur avant la mise en service : le préavis est un mauvais moment pour en chercher un.

À intervalles définis, vérifiez qui possède chaque rôle et si l’outil est toujours utilisé. Élargissez l’accès progressivement : RH, puis responsables, puis tous les salariés, en répétant à chaque étape le test de la barre d’adresse. Si l’outil n’est plus utilisé, retirez-le : désactivez son compte de base et ses identifiants, supprimez les données selon les réglages de conservation, arrêtez-le et retirez-le du réseau privé ou du système d’authentification.

Le successeur désigné hérite d’un serveur que quelqu’un a dû mettre en place, avec un outil de déploiement, un réseau privé et, pour un accès élargi, l’authentification de l’entreprise. Notre Linux VPS fournit un accès root, et Coolify, Tailscale et Authentik se déploient chacun comme une application en un clic, ce qui laisse à l’aide informatique du temps pour les vérifications. Les emplacements incluent Francfort et Amsterdam dans l’UE, Londres au Royaume-Uni et plusieurs villes américaines. Cela fixe le pays du serveur, un élément de la discussion avec le DPO, pas son remplacement.

La liste de vérification avant mise en service

Avant d’ajouter des dossiers de salariés, chaque point ci-dessous est soit réalisé, soit non réalisé. Transmettez cette liste à la personne qui met en place le serveur.

1. La question sur les décisions de recrutement est tranchée, et chaque « oui » a été transmis à l’informatique et au juridique.
2. L’outil fonctionne sur un serveur contrôlé par l’équipe, pas sur l’hébergement de l’outil d’IA.
3. Il est accessible uniquement sur le réseau privé ou via l’authentification de l’entreprise.
4. Le compte de base de données de l’application ne lit que les champs listés.
5. Le responsable et le salarié de test obtiennent tous deux « accès refusé » au test de la barre d’adresse.
6. Chaque identifiant ayant figuré dans une conversation ou le code a été remplacé, et l’ancien révoqué.
7. L’audit des données sortantes est terminé et les champs inutiles sont retirés.
8. Le journal d’audit consigne les consultations, et le compte de l’application ne peut ni le modifier ni le supprimer.
9. Les réglages de conservation et les règles relatives à l’emploi ont été examinés par le DPO ou le responsable conformité.
10. Un responsable et un remplaçant sont nommés.

Foire aux questions

Qu’est-ce que l’IA non autorisée dans les RH ?

L’IA non autorisée dans les RH désigne l’utilisation d’outils d’IA, ou d’applications créées avec eux, sur les données RH sans information ni accord de l’informatique. Selon l’enquête annuelle 2026 de Sapient Insights sur les systèmes RH, rapportée par Cornerstone OnDemand, plus de 80 % des professionnels RH utilisent quotidiennement des outils d’IA personnels, tandis que 3 % utilisent l’IA intégrée à leurs systèmes RH.

Puis-je utiliser de vrais dossiers de salariés pendant la création ?

Non. Gardez les dossiers réels hors de la conversation pendant que vous créez l’outil RH avec l’IA. Les coller dans un assistant constitue un risque distinct du déploiement, qui apparaît immédiatement, même si l’outil n’est jamais mis en service. Utilisez de faux dossiers jusqu’à ce que l’outil fonctionne sur un serveur contrôlé par l’équipe.

Les salariés doivent-ils consentir à l’utilisation de leurs données par un outil RH ?

Le consentement est généralement une base inadaptée. Les lignes directrices sur le consentement de l’EDPB expliquent qu’il est problématique pour les employeurs de traiter les données de salariés actuels ou futurs sur cette base, car le consentement a peu de chances d’être donné librement. La base légale applicable selon l’article 6 du RGPD doit être déterminée avec votre DPO.

HIPAA couvre-t-il les notes médicales d’un outil RH ?

Généralement non. La définition des informations de santé protégées de HIPAA exclut les informations dans les dossiers d’emploi détenus par une entité couverte en sa qualité d’employeur (45 CFR 160.103). Cela ne signifie pas que ces notes échappent à toute réglementation : demandez au responsable conformité quelles règles les couvrent.