« On a choisi l’outil, maintenant ça va aller vite. » C’est une phrase que j’entends souvent au démarrage d’un projet SIRH (Système d’Information des Ressources Humaines), et c’est presque toujours un mauvais signal : le choix de l’éditeur n’est qu’une étape parmi d’autres, et rarement la plus risquée. Voici comment je découpe un projet SIRH avec mes clients, du cadrage jusqu’à la stabilisation après la mise en production — et à quel moment chaque étape a le plus de chances de dérailler.
Cadrage : la question qu’on saute trop souvent
Avant de regarder le moindre outil, je fais poser une question simple à mes clients : quel problème précis cherche-t-on à résoudre ? Remplacer un outil vieillissant n’est pas le même projet que digitaliser un processus resté sur Excel, ou que préparer une fusion de deux périmètres RH. Le cadrage, c’est la liste des processus concernés (paie, temps, recrutement, formation, entretiens), les effectifs et sites impactés, et surtout les irritants actuels — ce qui ne marche pas aujourd’hui et qu’on ne veut surtout pas reproduire dans le nouvel outil.
C’est aussi le moment de décider si vous avez besoin d’une AMOA (assistance à maîtrise d’ouvrage — un consultant qui représente vos intérêts côté client face à l’éditeur et à l’intégrateur). J’ai détaillé ailleurs à quoi sert l’AMOA et quand s’en passer ; sur un projet qui touche plusieurs silos RH à la fois, c’est rarement du luxe.
Le cadrage, c’est enfin le moment de nommer un binôme de pilotage clair : un chef de projet côté RH, qui porte la connaissance métier et tranche sur les règles RH ambiguës, et un interlocuteur côté DSI (direction des systèmes d’information), qui porte la contrainte technique (interfaces avec les autres systèmes, sécurité, hébergement des données). Sur les projets qui s’enlisent, je constate presque toujours la même cause : personne n’a l’autorité claire pour trancher vite quand RH et DSI ne sont pas d’accord, et chaque arbitrage remonte trop haut pour être traité au rythme du projet.
Rédiger le cahier des charges : le socle de tout le reste
Le cahier des charges traduit le cadrage en exigences écrites, opposables : ce que le futur outil doit faire, pour qui, avec quelles contraintes (réglementaires, techniques, budgétaires). J’ai écrit une méthode complète pour structurer un cahier des charges SIRH en six blocs ; je ne la répète pas ici, mais je rappelle le point le plus souvent raté : un cahier des charges flou ou trop générique rend impossible de comparer sérieusement deux éditeurs sur leurs réponses, et c’est au moment de la recette, des mois plus tard, qu’on découvre que personne n’avait vraiment défini le besoin.
Choisir l’éditeur : au-delà de la démo
Une démonstration commerciale est faite pour être convaincante, pas pour être représentative de votre usage réel. Sur mes projets, je pousse toujours pour un scénario de démo construit avec vos propres cas (vos conventions collectives, vos circuits de validation, vos effectifs multi-sites), pas le scénario standard de l’éditeur. Je fais aussi vérifier systématiquement trois points qui ne se voient pas en démo : la solidité du core RH (le socle qui porte les données salarié dont dépendent tous les autres modules), la qualité réelle du support après la vente (pas seulement pendant le cycle commercial), et la feuille de route produit de l’éditeur sur les deux à trois prochaines années — un SIRH se choisit pour durer, pas pour l’année du déploiement.
Paramétrage et recette : où se jouent les vrais risques
C’est l’étape la moins visible pour la direction, et celle où je vois le plus d’écarts entre le planning initial et la réalité. Paramétrer un SIRH, c’est transposer vos règles RH concrètes (grilles de primes, circuits de validation des congés, règles de temps de travail) dans la logique de l’outil — et cette traduction n’est jamais parfaite au premier essai. La recette (les tests qui vérifient que le paramétrage produit le résultat attendu) doit couvrir non seulement le cas standard, mais aussi les situations rares : temps partiel, contrat suspendu, changement de statut en cours de mois. C’est précisément là que les choses se jouent, pas sur le cas le plus fréquent.
Le retour terrain de Pierre
Sur un projet dans une ETI (entreprise de taille intermédiaire) du retail, le planning de recette avait été comprimé pour tenir une date de go-live fixée en amont par la direction, sans lien avec la réalité du chantier. Résultat : le jeu de tests n’a couvert que les cas standards, validés en trois jours. Les premiers signalements sont arrivés dès la première paie en production — sur des cas de rupture de contrat en cours de mois, jamais testés. Depuis, je défends systématiquement un principe simple auprès de mes clients : la date de go-live se fixe une fois la recette terminée, jamais l’inverse.
Conduite du changement : le chantier qu’on sous-budgète
Un SIRH bien paramétré que personne n’utilise correctement reste un échec de projet. La conduite du changement commence bien avant le go-live : communiquer tôt sur ce qui change concrètement pour chaque population d’utilisateurs (managers, salariés, équipe RH), former sur des cas réels plutôt que sur une présentation générique, et désigner des relais locaux capables de répondre aux premières questions sans systématiquement remonter au support de l’éditeur. Sur la plupart de mes projets, c’est le budget le plus facile à réduire quand le planning glisse — et c’est presque toujours une erreur, parce que l’adoption se joue dans les toutes premières semaines d’usage.
Go-live et stabilisation : le projet ne s’arrête pas à la mise en production
La bascule en production n’est pas la ligne d’arrivée. Je recommande toujours de prévoir une période de stabilisation d’au moins un cycle complet (un mois de paie, une campagne d’entretiens annuels selon le périmètre) où une cellule resserrée reste disponible pour traiter rapidement les écarts, avant de dissoudre l’équipe projet. C’est aussi le moment de documenter ce qui a été réellement paramétré — pas ce qui était prévu au cahier des charges — pour que l’outil reste pilotable une fois l’intégrateur reparti.
Questions fréquentes
Combien de temps dure un projet SIRH, du cadrage au go-live ?
Ça dépend trop du périmètre (un seul module ou plusieurs, un ou plusieurs sites, une convention collective ou dix) pour donner un chiffre unique sans se tromper. Ce qui compte davantage que la durée totale, c’est de ne pas comprimer la recette pour tenir une date fixée trop tôt.
Faut-il faire appel à une AMOA sur tous les projets SIRH ?
Non, ça dépend de la complexité et des ressources internes déjà disponibles. Sur un périmètre simple avec une équipe RH qui maîtrise déjà l’exercice, elle n’est pas indispensable. Sur un projet multi-sites ou multi-conventions, elle sécurise surtout la phase de cadrage et de recette.
Quelle étape est la plus souvent sous-estimée ?
La conduite du changement, sans hésiter. C’est celle qu’on réduit en premier quand le planning dérape, alors que c’est elle qui détermine si l’outil sera réellement utilisé une fois en production.
En résumé
Un projet SIRH réussi tient moins au choix de l’éditeur qu’à la rigueur des étapes qui l’entourent : un cadrage honnête sur le problème à résoudre, un cahier des charges opposable, une recette qui couvre les cas rares, et une conduite du changement qui ne se sacrifie pas en premier quand le planning glisse. Vous démarrez ou vous relancez un projet SIRH ? Écrivez-moi, on regarde ensemble où se situent vos vrais risques.