Sur les missions de transformation RH et de pilotage social, quatre chantiers métier amont reviennent régulièrement. Aucun ne touche à l’IA directement. Tous conditionnent pourtant ce qu’il sera possible d’en faire ensuite.

1. Fiabiliser le référentiel agents et l’historique

C’est le chantier le moins glamour et le plus systématiquement sous-estimé. Avant de parler d’assistant RH conversationnel, d’analyse prédictive ou de moteur de recommandation, il faut être capable de répondre à une question simple : qui est dans l’eKectif, à quelle date, à quel statut, sur quel périmètre, et avec quelle continuité historique ?

En mission, le constat est récurrent. Les référentiels agents présentent des écarts entre paie, gestion administrative et reporting social. Les statuts (CDI, CDD, alternance, prestataire interne, mis à disposition, expatrié) ne sont pas codifiés de la même manière selon les sources. Les historiques sont tronqués lors des changements d’outil, ou figés à la dernière reprise de données. Les doublons existent, par exemple lorsqu’un même collaborateur est saisi deux fois sous deux matricules après une mobilité interne.

Tant que ces écarts existent, deux choses deviennent impossibles. La première : alimenter un modèle d’IA de manière fiable, parce qu’il apprendra sur une réalité fausse. La seconde : expliquer les résultats produits, parce qu’on ne saura plus reconstituer le périmètre exact des données d’entrée.

Ce chantier n’est pas un préalable optionnel. C’est la condition de base. Et il ne se traite pas en trois semaines avant le lancement d’un projet IA : il demande une vraie démarche de qualité des données, avec des règles claires sur qui produit, qui valide, qui corrige.

2. Documenter les règles de gestion implicites

Le deuxième chantier est plus politique qu’il n’y paraît. Dans la plupart des ETI accompagnées, une part importante des règles de gestion RH n’est écrite nulle part. Elles vivent dans la tête de deux ou trois personnes du service paie ou RH, dans des fichiers Excel transmis d’une génération à l’autre, ou dans des paramétrages SIRH dont plus personne ne sait pourquoi ils ont été faits ainsi.

Tant que ces règles restent implicites, l’organisation s’arrange. Il y a toujours quelqu’un pour rattraper un cas particulier, faire une exception, arbitrer une situation limite. Le jour où l’on cherche à automatiser ou à confier un arbitrage à un outil, ces règles deviennent un problème. Soit on les documente honnêtement, et l’on découvre qu’elles sont parfois contradictoires, voire qu’elles ne tiennent pas juridiquement. Soit on les laisse implicites, et l’outil les reproduit telles quelles, en les amplifiant.

L’exercice de documentation est exigeant. Il oblige à faire émerger ce que l’on appliquait sans le dire. Il oblige à arbitrer : cette règle, on la conserve, on la modifie, on la supprime. C’est un moment de vérité organisationnel, qui dépasse largement la fonction RH.

3. Arbitrer les pratiques divergentes entre entités

Le troisième chantier concerne particulièrement les ETI structurées en plusieurs sites, filiales, ou business units. Chaque entité a construit ses pratiques RH au fil du temps : les processus d’entretien annuel ne suivent pas la même trame, les critères de promotion ne sont pas formalisés de la même façon, les règles d’attribution de primes varient, les nomenclatures de postes ne se recouvrent pas.

Là encore, tant que chaque entité fonctionnait dans son couloir, ces divergences étaient gérables. Au moment où l’on cherche à mettre en place un SIRH unifié, et à plus forte raison à le doter d’usages IA transversaux (analyse de cohortes, recommandations de mobilité, lecture du climat social) ces divergences deviennent bloquantes.

L’arbitrage à conduire n’est pas technique. Il est politique. Qu’est-ce que l’on standardise au nom de l’eKicacité, et qu’est-ce que l’on accepte de conserver en local au nom de la spécificité métier ? Qui décide ? À quel niveau ? Avec quel calendrier ? Ce sont des décisions que la direction générale doit assumer avant le lancement du projet, pas pendant le déploiement. Sinon, le projet SIRH devient le lieu où l’on tranche, par défaut, des sujets de gouvernance qui n’avaient jamais été tranchés.

4. Cadrer la gouvernance des usages IA avant les usages

Le quatrième chantier est le plus récent, et le plus mal traité. Beaucoup d’ETI démarrent leur réflexion IA par l’outil : quel module activer, quel éditeur retenir, quel cas d’usage prioriser. La question préalable, qui est celle de la gouvernance, est traitée en retard ou pas du tout.

Or, avant d’autoriser un usage IA en RH, il faut être capable de répondre à plusieurs questions concrètes. Qui décide qu’un usage est lancé ? Sur quels critères ? Qui en mesure les effets ? Qui peut l’arrêter, et selon quelle procédure ? Le DPO a-t-il été associé en amont ? L’usage relève-t-il d’un système d’IA à haut risque au sens du règlement européen sur l’IA, l’AI Act ? Une analyse d’impact relative à la protection des données, ou DPIA, a-t-elle été conduite ? L’usage est-il inscrit au registre des traitements ? Les représentants du personnel ont-ils été informés et consultés quand le sujet relève du dialogue social ?

À côté de cette gouvernance officielle, il y a la gouvernance officieuse, et c’est probablement la plus urgente à traiter. L’IA générative est massivement utilisée dans les services RH sans que la direction ne le sache toujours : rédaction de comptes rendus d’entretien, génération de fiches de poste, reformulation de courriers difficiles, préparation d’analyses pour les comités de direction. Ces usages, parfois utiles, échappent au cadre. C’est ce qu’on appelle souvent l’IA fantôme, ou « shadow IA ». Tant que l’entreprise ne propose pas un cadre clair, des outils validés et une formation, les collaborateurs utilisent ce qu’ils trouvent. Avec parfois des données RH sensibles envoyées vers des outils dont personne ne maîtrise ni l’hébergement ni les conditions d’usage.

Cadrer la gouvernance avant les usages, ce n’est pas freiner. C’est éviter d’avoir à arrêter brutalement, plus tard, des pratiques installées dont on découvrira qu’elles posaient un problème juridique ou éthique.

B. Au-delà des chantiers métier : la souveraineté comme nouveau critère de choix

Une fois ces chantiers identifiés et engagés, reste une dernière question, qui n’existait quasiment pas il y a cinq ans dans les comités de sélection SIRH : où vivent les données ? Qui peut y accéder ? Que peut faire l’éditeur de la donnée RH qu’il héberge ?

Pendant longtemps, choisir un SIRH revenait à comparer des couvertures fonctionnelles, des expériences utilisateurs et des coûts de licence. C’est encore vrai, mais ce n’est plus suffisant. Quand l’éditeur entraîne ou enrichit des modèles d’IA avec les données de ses clients, ou quand il sous-traite l’hébergement à un fournisseur soumis à des législations extra-territoriales, la question des données devient un critère de choix à part entière.