« On va faire un petit cahier des charges et on lance la consultation. » J’entends cette phrase sur presque tous les projets qui partent mal. Le cahier des charges (CDC) n’est pas une formalité administrative à expédier en deux pages avant de passer aux choses sérieuses : c’est le document qui décide, en amont, si votre SIRH (Système d’Information de gestion des Ressources Humaines) répondra à vos besoins ou si vous découvrirez ses manques une fois signé. Voici la trame que j’utilise sur mes projets, bloc par bloc.
À quoi sert vraiment un cahier des charges SIRH ?
Un cahier des charges a deux fonctions bien distinctes, et confondre les deux est la première source de déception. D’un côté, c’est un outil de clarification interne : l’exercice de le rédiger oblige la DRH (Direction des Ressources Humaines) et la DSI (Direction des Systèmes d’Information) à se mettre d’accord sur ce qu’elles veulent vraiment, avant même de parler à un éditeur. De l’autre, c’est un outil de comparaison externe : il permet de mettre plusieurs éditeurs sur la même ligne de départ et de juger leurs réponses sur des critères identiques. Un CDC flou rate les deux objectifs à la fois : en interne, personne ne sait vraiment ce qu’on attend ; en externe, chaque éditeur répond à sa manière, et vous comparez des réponses qui ne parlent pas du même besoin.
Qui écrit le cahier des charges ?
Sur le papier, c’est la MOA (Maîtrise d’Ouvrage) — vous, l’entreprise — qui porte le document, puisque c’est votre besoin. Dans les faits, sa rédaction est rarement solitaire. J’en parlais dans mon article sur l’AMOA (Assistance à Maîtrise d’Ouvrage) : c’est justement l’un des chantiers où ce renfort a le plus de valeur, parce qu’écrire un CDC exige une méthode et un peu de recul sur le marché que les équipes RH n’ont pas forcément à mobiliser en interne, en plus de leur activité courante. Que vous soyez accompagné ou non, le principe reste le même : le document doit être piloté par un petit noyau de deux ou trois personnes qui centralisent les arbitrages, pas rédigé à plusieurs mains sans coordination.
La trame en six blocs
Voici l’ossature que je reprends, avec des variantes, sur la quasi-totalité de mes projets.
1. Le contexte et les objectifs
Avant toute liste de fonctionnalités, posez le décor : combien de salariés, combien d’établissements, quelles conventions collectives, quel SIRH existant (le cas échéant) et pourquoi vous en changez. Un éditeur qui comprend votre contexte répond mieux qu’un éditeur qui répond à une liste de cases à cocher hors sol.
2. Le périmètre fonctionnel
Listez les briques concernées : cœur RH (dossier salarié, organigramme), paie, GTA (Gestion des Temps et Activités), recrutement, formation, entretiens. Précisez ce qui est dans le périmètre du projet et ce qui reste volontairement hors périmètre — c’est souvent cette deuxième liste qui manque, et son absence ouvre la porte à des débats sans fin pendant la phase de sélection.
3. Le besoin terrain, recueilli en ateliers
C’est le bloc le plus consommateur de temps et le plus souvent bâclé. Organisez des ateliers avec les utilisateurs réels — gestionnaires paie, managers, salariés — pas seulement avec la direction RH. Un besoin exprimé uniquement par l’encadrement rate systématiquement les irritants du quotidien, ceux qui feront ou déferont l’adoption de l’outil une fois déployé.
4. Les exigences techniques et RGPD
Ce bloc est devenu incontournable et il est régulièrement sous-traité aux « détails à voir plus tard » — grave erreur. Précisez le mode d’hébergement souhaité, les interfaces attendues avec vos autres systèmes (paie externalisée, badgeuse, annuaire), et vos exigences de sécurité. Sur le volet RGPD (Règlement Général sur la Protection des Données), exigez explicitement de l’éditeur qu’il puisse signer un contrat de sous-traitance conforme à l’article 28 du RGPD, ce qu’on appelle couramment un DPA (Data Processing Agreement) : ce contrat doit couvrir a minima l’objet, la durée, la nature et la finalité du traitement, ainsi que le sort des données de vos salariés en fin de contrat. La CNIL (Commission Nationale de l’Informatique et des Libertés) propose d’ailleurs des clauses contractuelles types que vous pouvez utiliser comme grille de lecture pour challenger la proposition de l’éditeur. Un éditeur qui n’a pas de réponse claire sur ce point est un signal d’alerte, pas un détail à régler après la signature.
5. Le budget et le planning
Donnez une fourchette budgétaire, même approximative, et un calendrier avec les jalons qui comptent pour vous (une clôture de paie à ne pas manquer, un changement de convention collective). Un CDC muet sur le budget produit des réponses hétérogènes, allant du strict minimum au sur-mesure hors de prix, et rend la comparaison illisible.
6. Les critères de choix et le mode de sélection
Annoncez dès le CDC comment vous allez trancher : grille de notation pondérée, démonstrations cadrées sur vos propres cas d’usage, références clients à contacter. Un éditeur qui sait sur quels critères il sera jugé prépare une réponse plus pertinente qu’un éditeur qui répond à l’aveugle.
Les pièges les plus fréquents
Le premier piège est le copier-coller d’un CDC trouvé ailleurs, à peine adapté : il produit un document qui ressemble à tout le monde et à personne, et les éditeurs le reconnaissent immédiatement. Le deuxième est la liste de fonctionnalités sans priorisation : tout est marqué « indispensable », ce qui ne permet plus d’arbitrer entre deux solutions qui couvrent le besoin différemment. Le troisième est l’absence de validation transverse : le document part côté RH sans que la DSI, le juridique ou les représentants du personnel l’aient relu, et les objections surgissent trop tard, une fois la solution déjà choisie.
Le retour terrain de Pierre
Sur un projet de digitalisation RH dans une ETI (entreprise de taille intermédiaire) du secteur industriel, le cahier des charges listait bien l’exigence RGPD, mais en une ligne générique reprise d’un modèle trouvé en ligne. Personne n’avait demandé le DPA de l’éditeur retenu avant la signature. Il a fallu trois mois de négociation post-contrat pour obtenir un document conforme, pendant que le déploiement était déjà lancé — un rapport de force nettement moins favorable qu’avant signature. La leçon : exigez le DPA au stade de l’appel d’offres, pas après.
Jusqu’où aller dans le détail ?
Un cahier des charges trop vague laisse chaque éditeur interpréter le besoin à sa façon ; un cahier des charges trop rigide, calqué sur le fonctionnement exact de l’outil actuel, empêche de profiter des apports d’une nouvelle solution et complique inutilement la réponse des éditeurs. Le bon niveau de détail décrit le résultat attendu (« le salarié doit pouvoir poser un congé et être notifié de la décision sous 48 heures ») plutôt que le mode opératoire technique (« un bouton doit apparaître à tel endroit de l’écran »). Cette formulation par le résultat laisse aux éditeurs la liberté de proposer leur meilleure réponse tout en vous permettant de vérifier, au moment de la recette, que l’engagement est tenu.
Questions fréquentes
Combien de temps prend la rédaction d’un cahier des charges SIRH ?
Cela dépend entièrement du périmètre et de la disponibilité des équipes pour les ateliers de recueil du besoin, qui est l’étape la plus longue. Le bon réflexe est de caler ce délai avec les personnes qui doivent participer aux ateliers avant de figer un calendrier de consultation, plutôt que l’inverse.
Faut-il faire appel à un consultant pour l’écrire ?
Ce n’est pas obligatoire si vous avez déjà mené ce type de projet en interne et que le périmètre reste simple. Sur un projet plus large ou une première expérience, un accompagnement ponctuel, même limité à la seule phase de cadrage, sécurise nettement la suite.
Le cahier des charges est-il contractuel ?
Il ne l’est pas par défaut, mais rien ne vous empêche de l’annexer au contrat final avec la réponse de l’éditeur : cela transforme les engagements pris en phase commerciale en base vérifiable au moment de la recette. C’est une pratique que je recommande systématiquement.
En résumé
Un bon cahier des charges SIRH n’est ni un document générique téléchargé en ligne, ni une liste exhaustive de fonctionnalités sans hiérarchie : c’est le résultat d’un travail de clarification interne, mené avec les utilisateurs réels, qui couvre le contexte, le périmètre, le besoin terrain, les exigences techniques et RGPD, le budget et les critères de choix. Vous préparez une consultation et voulez un regard extérieur sur votre trame ? Écrivez-moi, je vous dirai ce qui manque avant que vous ne l’envoyiez aux éditeurs.