Un cahier des charges SIRH sert à une chose : décrire noir sur blanc ce que l’entreprise attend de son futur logiciel RH, avant de regarder la moindre démo. J’y note le contexte, les objectifs, les processus concernés, les fonctionnalités attendues, les contraintes techniques, le budget et les critères de choix. Sans ce document, je compare des outils sur leur apparence. Avec lui, je les compare sur mes besoins réels. C’est toute la différence entre un projet SIRH qui tient ses délais et un logiciel que personne n’ouvre six mois plus tard.
Dans cet article, je vous explique comment je procède, qui j’implique, ce que je mets dans le document et les pièges que j’évite.
Sommaire
- Pourquoi je ne choisis jamais un logiciel RH sans cadrage écrit
- Qui mettre autour de la table
- Les étapes que je suis, dans l’ordre
- Ce que contient un document complet
- Comment je priorise les besoins
- Les erreurs qui coûtent cher
- Comparer les éditeurs avec une grille commune
- FAQ
Pourquoi je ne choisis jamais un logiciel RH sans cadrage écrit
Un SIRH touche à tout. Les congés, les absences, les temps de travail, la paie, les entretiens, la formation, les notes de frais, les documents du salarié. Chaque module concerne des utilisateurs différents. Chaque module a ses règles. Si je pars en démonstration sans avoir trié mes priorités, je me laisse séduire par l’interface la plus jolie. Et je découvre trop tard que l’outil ne gère pas ma convention collective ou mon organisation multi-sites.
Le cadrage écrit me protège de trois risques.
Le premier, c’est le mauvais choix de logiciel. Un outil très puissant mais trop lourd pour une PME de quarante salariés finit sous-utilisé. À l’inverse, un outil léger devient un frein dès que l’effectif grandit.
Le deuxième, c’est le dérapage budgétaire. Les surcoûts arrivent presque toujours après la signature : paramétrages supplémentaires, reprise de données, connecteurs avec la paie, formation des équipes. Quand ces points figurent dans le document dès le départ, les éditeurs les chiffrent dans leur offre. Je compare alors des prix complets.
Le troisième, c’est le rejet par les utilisateurs. Un logiciel choisi sans écouter les managers et les collaborateurs ne correspond pas à leur quotidien. Ils reviennent vite au tableur et aux mails.
Pour gagner du temps, je ne pars pas d’une page blanche. Je m’appuie sur une trame existante pour réaliser un cahier des charges SIRH structuré, puis je l’adapte à la taille et aux contraintes de l’entreprise. Une trame évite les oublis classiques, surtout sur la partie technique.
Qui mettre autour de la table
Les RH pilotent la rédaction. Mais je ne les laisse jamais écrire seuls. Le projet concerne toute l’entreprise, et chaque acteur détient une partie de l’information.| Acteur | Ce qu’il apporte | La question que je lui pose |
|---|---|---|
| Équipe RH | La connaissance des processus, des irritants et des données sensibles | Quelles tâches vous prennent le plus de temps chaque mois ? |
| DSI ou référent informatique | Les contraintes d’intégration, de sécurité et d’hébergement | Avec quels outils le SIRH doit-il échanger des données ? |
| Direction | Les objectifs, le budget et le calendrier | Quel résultat attendez-vous dans un an ? |
| Gestionnaire de paie | Les variables, les exports et les règles de calcul | Quelles ressaisies voulez-vous supprimer ? |
| Managers | Les circuits de validation réels | Comment validez-vous une absence aujourd’hui ? |
| Collaborateurs | L’usage quotidien, souvent sur mobile | Qu’est-ce qui vous agace dans les démarches RH actuelles ? |
Dans une structure complexe, je nomme un chef de projet SIRH. Il recueille les besoins, rédige, organise la consultation des éditeurs et suit le planning. Dans une petite entreprise, ce rôle revient souvent au responsable RH, avec un appui ponctuel de l’informatique.
Les étapes que je suis, dans l’ordre
Je respecte toujours la même progression. Je pars de l’existant et je termine par la consultation des éditeurs. Sauter une étape se paie plus tard.
Décrire l’existant
Je commence par un état des lieux. Effectif, nombre de sites, conventions collectives, types de contrats, outils déjà en place. Je décris aussi les processus tels qu’ils fonctionnent vraiment, pas tels qu’ils figurent dans la procédure. Si les congés se valident par un message au manager puis un report dans un tableur, je l’écris.
Lister les irritants
Je note ensuite ce qui coince. Les doubles saisies. Les erreurs de compteurs. Les fichiers éparpillés. L’absence de reporting. Les relances manuelles pour les entretiens annuels. Cette liste devient la matière première du document. Un besoin bien formulé part toujours d’un problème concret.
Fixer les objectifs
Je traduis ces irritants en objectifs clairs. Réduire le temps passé sur la préparation de la paie. Fiabiliser les compteurs d’absences. Donner de l’autonomie aux salariés. Sécuriser les données RH. Accompagner une croissance des effectifs. Je limite le nombre d’objectifs. Trois ou quatre suffisent, et je les classe.
Définir le périmètre fonctionnel
Je précise les modules attendus. Congés et absences, suivi des temps, dossier du personnel, entretiens, formation, notes de frais, bulletins dématérialisés, reporting. Pour chacun, je décris le besoin en situation. Je n’écris pas « gestion des congés ». J’écris « un salarié pose une demande depuis son téléphone, son manager valide en un clic, le compteur se met à jour et l’information part vers la paie ».
Poser le cadre technique
Cette partie est souvent négligée par les RH. Elle fait pourtant échouer des projets. J’y indique les intégrations nécessaires, notamment avec le logiciel de paie et l’annuaire de l’entreprise. Je précise la gestion des droits d’accès, l’hébergement des données, les exigences de sécurité, la conformité au RGPD, les formats d’import et d’export. Je mentionne aussi les données à reprendre : historiques d’absences, documents, soldes.
Écrire les critères de choix
Avant de recevoir la moindre offre, je fixe mes critères. Couverture fonctionnelle, ergonomie, coût total, qualité de l’accompagnement, support, évolutivité, délais de déploiement. Je leur attribue un poids. Ce travail en amont m’évite de réécrire les règles une fois les démos passées.
Lancer la consultation
Je transmets le document à une sélection courte d’éditeurs. Je précise le format de réponse attendu, la date limite et le déroulé des démonstrations. Plus le document est précis, plus les réponses se ressemblent dans leur forme. La comparaison devient simple.
Ce que contient un document complet
Voici la structure que j’utilise. Elle s’adapte à la taille de l’entreprise. Une PME tient sur une dizaine de pages. Un groupe multi-sites en demande davantage.| Rubrique | Contenu |
|---|---|
| Présentation de l’entreprise | Activité, effectif, sites, conventions collectives, populations concernées |
| Contexte du projet | Outils actuels, limites constatées, raisons du changement |
| Objectifs | Résultats attendus et indicateurs de réussite |
| Périmètre fonctionnel | Modules souhaités, décrits par cas d’usage |
| Processus et circuits de validation | Qui demande, qui valide, qui est informé |
| Exigences techniques | Intégrations, sécurité, droits, hébergement, reprise de données |
| Cadre du projet | Budget, calendrier, ressources internes disponibles |
| Critères d’évaluation | Liste pondérée des critères de choix |
| Modalités de réponse | Format, date limite, démonstration, interlocuteurs |
Je garde un principe en tête. Le document doit être assez précis pour guider l’éditeur, mais pas fermé au point d’interdire toute proposition. Un bon prestataire connaît son métier. Il suggère parfois une manière plus simple de traiter un besoin. Je lui laisse cette place.
Comment je priorise les besoins
Lister les besoins ne suffit pas. Si tout est prioritaire, rien ne l’est. Je classe chaque fonctionnalité dans un des trois niveaux ci-dessous.| Niveau | Définition | Exemple |
|---|---|---|
| Indispensable | Sans cette fonction, l’outil est écarté | Export des absences vers le logiciel de paie |
| Important | Apporte un gain réel, une alternative reste acceptable | Signature électronique des documents RH |
| Confort | Un plus appréciable, sans effet sur la décision | Personnalisation de la page d’accueil |
Ce classement a deux effets. Il cadre le budget, car je sais ce que je peux retirer si l’enveloppe est dépassée. Et il rend la comparaison objective. Un éditeur qui coche toutes les cases de confort mais rate un point indispensable sort de la liste, sans discussion.
Je fais valider ce classement par la direction et par les RH avant l’envoi. Les arbitrages se font à ce moment, pas pendant les démonstrations.
Les erreurs qui coûtent cher
Je retrouve souvent les mêmes travers. Les voici, avec ce que je fais à la place.
- Rédiger seul dans son coin. Je consulte la paie, l’informatique et quelques managers avant d’écrire.
- Copier la liste de fonctionnalités d’un éditeur. Je pars de mes problèmes, pas d’une plaquette commerciale.
- Rester vague. Je bannis les formules du type « outil intuitif ». Je décris un cas d’usage vérifiable.
- Oublier la technique. J’intègre les connecteurs, la sécurité et la reprise de données dès la première version.
- Ne pas parler d’argent. J’indique une fourchette de budget et je demande un coût complet, mise en œuvre et formation comprises.
- Négliger l’après. Je prévois la conduite du changement : communication interne, formation, référents par service.
Comparer les éditeurs avec une grille commune
Une fois les réponses reçues, je passe à l’évaluation. J’utilise la même grille pour tous. Chaque critère reçoit une note et un coefficient. Je remplis la grille à plusieurs, RH et informatique ensemble, pour limiter les biais.
Je demande toujours une démonstration sur des cas réels. J’envoie à l’avance deux ou trois scénarios tirés du quotidien de l’entreprise. Une demande de congé à cheval sur deux périodes. Un entretien annuel avec objectifs repris de l’année précédente. Une note de frais avec plusieurs taux de TVA. L’éditeur déroule ces scénarios devant moi. Je vois tout de suite si l’outil suit ou s’il faut contourner.
Je vérifie aussi trois points que la démo ne montre pas. La qualité du support et ses horaires. La méthode de déploiement et le temps demandé à mes équipes. Les conditions de sortie, c’est-à-dire la récupération des données si je change un jour de solution.
Enfin, je contacte un ou deux clients de taille comparable. Leur retour sur les premiers mois vaut souvent plus qu’une présentation commerciale.
FAQ
À quel moment faut-il rédiger le cahier des charges SIRH ?
Avant toute prise de contact avec un éditeur. Le document précède le choix du logiciel. Il sert ensuite de référence pendant tout le déploiement, pour vérifier que ce qui est livré correspond à ce qui était demandé.
Combien de temps prend la rédaction ?
Cela dépend de la taille de l’entreprise et du périmètre. Pour une PME avec un périmètre limité aux congés, aux temps et au dossier du personnel, quelques semaines suffisent en général. Le recueil des besoins auprès des différents acteurs représente la plus grande part du travail.
Une petite entreprise en a-t-elle vraiment besoin ?
Oui. Le document est simplement plus court. Même avec vingt salariés, écrire ses besoins et ses priorités évite de payer pour des modules inutiles ou de choisir un outil trop limité.
Qui doit valider le document final ?
La direction valide les objectifs, le budget et le calendrier. Les RH valident le périmètre fonctionnel. L’informatique valide les exigences techniques. Je demande une validation écrite des trois avant l’envoi aux éditeurs.
Quelle longueur viser ?
Je vise la clarté plutôt que le volume. Un document d’une dizaine de pages bien structuré vaut mieux qu’un dossier de cinquante pages que personne ne lit. L’important est que chaque besoin soit compréhensible sans explication orale.
Faut-il indiquer son budget aux éditeurs ?
Je le recommande. Une fourchette permet aux éditeurs de proposer une offre réaliste et évite de perdre du temps avec des solutions hors de portée. Elle n’empêche pas la négociation.
Peut-on utiliser un modèle tout prêt ?
Oui, c’est même un bon point de départ. Un modèle fournit la structure et rappelle les rubriques qu’on oublie facilement. Il faut ensuite le remplir avec les spécificités de l’entreprise : ses processus, ses contraintes et ses priorités.
Que faire si les besoins évoluent en cours de projet ?
Je mets le document à jour et je trace chaque modification. Tout changement de périmètre a un effet sur le coût et le planning. Je le fais donc valider par la direction et chiffrer par l’éditeur avant de l’accepter.
