"On va mettre de l'IA dans les RH." J'entends cette phrase de plus en plus souvent en mission. Elle est rarement suivie d'un cas d'usage concret. Ma réponse tient en une ligne : je ne cherche pas à mettre de l'IA partout, je cherche à absorber la charge répétitive qui empêche l'expertise RH de se déployer. Et pour le faire correctement, j'ai décidé d'apprendre à construire moi-même les outils plutôt que de rester simple prescriptrice.
Le constat qui m'a mise en mouvement
Près de 30 ans à intervenir sur des paies, des SIRH, des GTA, ça laisse des traces. Un catalogue assez précis des irritants qui reviennent, mission après mission, chez des entreprises qui n'ont pourtant rien en commun.
Des interfaces paie/SIRH mal paramétrées qu'on découvre au moment où l'écart de charges tombe. Des GTA mal calibrées qui génèrent des anomalies que personne ne prend le temps de fiabiliser en amont. Des process qui reposent sur trois personnes indispensables, et qui s'effondrent dès que l'une d'elles est absente.
Ce qui m'a vraiment fait tiquer, ce n'est pas la complexité de ces sujets, c'est leur caractère répétitif. Vérifier une interface, croiser deux fichiers, relire une liste d'anomalies : ce sont des tâches chronophages, normées, sans valeur ajoutée en elles-mêmes. La valeur ajoutée arrive après : quand on sait interpréter l'écart, statuer sur un cas limite, décider si l'anomalie est un vrai problème ou un non-événement. Or ce temps d'analyse, on ne l'a jamais, parce qu'il est mangé par le contrôle mécanique en amont.
En parallèle, je me suis mise à tester des outils d'IA par curiosité, pour voir ce qu'ils permettaient en matière d'efficacité et de personnalisation. Et j'ai vu une opportunité assez nette : ce qui coince dans les services RH aujourd'hui n'est pas un problème d'expertise, c'est un problème de bande passante. L'IA ne remplace pas le jugement métier, elle peut redonner du temps pour l'exercer.
Pourquoi j'apprends à construire, et pas seulement à commander
J'aurais pu m'arrêter là : identifier les cas d'usage, briefer un prestataire, superviser la livraison. Je ne l'ai pas choisi, et pas par goût de la technique pour la technique.
D'abord, traduire un irritant RH en cas d'usage précis demande de connaître le métier de très près, jusque dans ses détails les plus ingrats. Un prestataire technique, aussi compétent soit-il, ne sait pas spontanément qu'une interface de paie mal paramétrée se repère souvent à un motif d'écart récurrent sur les mêmes rubriques. Si je reste en position de commanditaire, une bonne partie de cette connaissance se perd dans la traduction. Si je construis moi-même, elle reste dans l'outil.
Ensuite, il y a une question d'autonomie. Je ne veux pas dépendre d'un prestataire pour faire évoluer un agent chaque fois qu'un client a une règle de paie un peu particulière, ce qui, en paie, arrive à peu près tout le temps.
Pourquoi commencer par le contrôle de paie
Sur les pistes que j'explore, le contrôle de paie s'est imposé comme premier chantier, pour trois raisons.
La fiabilité y est non négociable. Une erreur de paie n'est jamais un détail : elle abîme la confiance des salariés, elle expose l'entreprise, elle mobilise des heures de correction en aval bien plus coûteuses que le contrôle lui-même.
La tâche elle-même est répétitive et normée. Contrôler une interface paie/SIRH avant validation, c'est comparer des données structurées à des règles connues - un terrain beaucoup plus favorable à un agent fiable qu'une tâche floue.
Et la valeur ajoutée pour le service paie est claire dès le premier usage : moins de temps passé à vérifier ligne par ligne, plus de temps disponible pour traiter les vrais cas complexes.
L'autre piste, un agent capable de répondre aux questions RH de premier niveau (congés, primes, procédures), reste sur ma feuille de route, une fois le premier chantier bien avancé.
Où j'en suis vraiment
Je vais être directe, parce que c'est aussi ma façon de travailler avec mes clients : je ne vends pas encore un produit. Je suis en train d'apprendre à construire un agent de contrôle de paie, avec de l'accompagnement sur les briques techniques que je ne maîtrise pas nativement. C'est un chantier en cours, pas une solution clé en main.
Ce que j'ai en revanche, c'est un point de départ que peu de personnes construisant des outils d'IA aujourd'hui possèdent : trente ans à savoir précisément où les paies dérapent, ce qu'un contrôleur expérimenté regarde en premier, et pourquoi tel écart mérite d'être creusé quand tel autre ne mérite qu'un haussement d'épaules.
Je préfère annoncer un chantier honnêtement que promettre un produit qui n'existe pas.
Ce que ça change pour vous, si vous pilotez un service paie ou une DRH de PME/ETI
Ce n'est pas encore le moment d'attendre une offre de ma part. C'est peut-être le moment de vous poser une question toute simple : dans votre service paie, quelle est la tâche que tout le monde fait sans y penser, qui prend du temps, et qui n'apporte de valeur à personne tant qu'elle n'est pas terminée ?
C'est en général la meilleure porte d'entrée pour réfléchir à l'IA. Pas la plus spectaculaire, la plus utile.
Je continue ce chantier avec la même méthode que le reste de mon activité : le terrain d'abord, la technologie ensuite. Si le sujet vous parle, ou si vous avez identifié un irritant du même genre dans votre service RH, je suis toujours preneuse d'en discuter.