top of page
Send

Pourquoi un cahier des charges SIRH doit commencer par trois problèmes, pas par une liste de fonctionnalités

Photo du rédacteur: Jennyfer MONTANTIN
Jennyfer MONTANTIN
il y a 11 minutes
7 min de lecture

Un cahier des charges SIRH peut devenir très complet et pourtant ne rien dire de la décision à prendre. Les modules, interfaces et fonctionnalités occupent plusieurs pages, mais l’entreprise n’a pas formulé ce que le projet doit améliorer. Les éditeurs répondent alors à une liste sans comprendre les priorités.

Le document doit commencer par trois problèmes. Ce choix n’est pas une norme officielle : c’est une discipline de décision. Il oblige le RRH à distinguer ce qui bloque réellement la fonction RH de ce qui serait simplement utile ou agréable.

Le premier SIRH doit produire un changement visible dans le travail. Réduire les tâches administratives, piloter la rémunération ou suivre le développement des compétences ne demandent pas le même périmètre, les mêmes données ni les mêmes utilisateurs. Le cahier des charges doit rendre cette différence explicite.


Pourquoi un cahier des charges SIRH doit commencer par trois problèmes, pas par une liste de fonctionnalités

Un besoin n’est pas une fonctionnalité

« Gestion des entretiens », « coffre-fort numérique » ou « reporting RH » désignent des briques de solution. Elles ne montrent ni le problème, ni le processus, ni le niveau de service attendu. Deux entreprises demandant le même module peuvent avoir des usages totalement différents.

Le besoin doit décrire une situation actuelle, sa conséquence et le résultat recherché. Combien de manipulations sont nécessaires ? Où la donnée se perd-elle ? Qui attend l’information ? Quelle décision n’est pas prise faute de visibilité ? Cette formulation permet de mesurer si le futur outil améliore réellement le fonctionnement.

Elle permet aussi de reconnaître qu’un problème ne relève pas toujours du logiciel. Un processus mal défini, une responsabilité floue ou une donnée de mauvaise qualité ne seront pas automatiquement corrigés par le SIRH. L’outil peut rendre le dysfonctionnement plus rapide sans le résoudre.

Ce travail oblige également à reconnaître ce que le SIRH ne résoudra pas. Une règle de validation incohérente restera incohérente une fois automatisée. Un indicateur dont personne ne se sert restera inutile une fois disponible. En séparant les problèmes d’outil, de processus et de responsabilité, le RRH évite de charger le logiciel d’une transformation qu’il ne peut pas porter seul. Le cahier des charges gagne en honnêteté et l’estimation du projet devient plus réaliste.

Les trois problèmes ne sont pas trois thèmes généraux. Ils doivent décrire des écarts entre la situation actuelle et le fonctionnement recherché. “Digitaliser les RH” reste trop large. “Réduire les ressaisies entre le suivi des absences et la paie”, “fiabiliser les décisions de rémunération” ou “rendre le suivi du développement des compétences exploitable” donnent une direction. Cette formulation permet ensuite de vérifier si chaque exigence du cahier des charges contribue réellement à l’un des objectifs.


Hiérarchiser avant de rédiger

Placer tous les besoins au même niveau produit un cahier des charges irréaliste. Chaque partie prenante ajoute ses demandes, personne ne veut renoncer et la solution idéale devient celle qui promet tout. Le coût et la complexité augmentent tandis que les priorités disparaissent.

La distinction entre indispensable, confort et usage futur crée une base de négociation. Une exigence indispensable doit être démontrée et contractualisée. Un élément de confort peut départager deux offres proches. Un usage futur doit être anticipé sans imposer immédiatement son paramétrage ou son achat.

Cette hiérarchie doit rester reliée aux trois problèmes initiaux. Si une fonctionnalité ne contribue à aucun d’eux, elle doit justifier sa présence autrement ou sortir du premier périmètre. Cette règle protège le projet contre l’enthousiasme produit par les démonstrations.

La pondération doit être décidée avant la réception des offres. Après coup, il devient trop facile d’augmenter le poids du critère sur lequel la solution préférée excelle. Une grille transparente protège la qualité de l’arbitrage, notamment lorsque le RRH, le DAF et le dirigeant ne regardent pas le projet avec les mêmes préoccupations. Elle ne supprime pas le jugement ; elle rend les changements de jugement visibles et discutables.

Hiérarchiser signifie accepter que certains besoins soient différés. Tous les sujets peuvent être légitimes sans avoir le même poids dans la décision. Une PME peut considérer l’intégration avec la paie comme non négociable, le suivi de la formation comme prioritaire et une campagne d’entretiens très sophistiquée comme souhaitable plus tard. Cette distinction évite qu’une longue liste de demandes secondaires élimine une solution solide sur l’essentiel.


Utiliser les cas d’usage pour donner de la réalité au document

Les cas d’usage racontent ce que devra faire un salarié, un manager, le RH ou l’interlocuteur paie. Ils précisent le déclencheur, les étapes, les validations, les données et le résultat. Ils révèlent les exceptions qui comptent sans transformer le cahier des charges en encyclopédie.

Présentés en annexe, ils permettent à l’éditeur de préparer une démonstration pertinente. L’entreprise ne sera pas parfaitement comprise après deux rendez-vous de quatre-vingt-dix minutes. Ces situations réduisent donc les suppositions et montrent les points sur lesquels une réponse générique serait insuffisante.

Les cas d’usage aident également les utilisateurs internes à réagir. Il est plus facile pour un manager de confirmer un parcours de validation que de commenter une spécification fonctionnelle. Leur implication devient concrète et limitée au travail qu’ils connaissent.

Un bon cas d’usage inclut le point de départ, les acteurs, les décisions, les données produites et le résultat attendu. Il peut mentionner une exception fréquente, car c’est souvent elle qui distingue un parcours réellement utilisable d’une promesse générique. En revanche, il ne doit pas enfermer l’éditeur dans la reproduction exacte du fonctionnement actuel. Le projet est aussi l’occasion de simplifier ce qui n’a plus de raison d’être.

Les cas d’usage placés en annexe sont particulièrement utiles aux éditeurs. Ils leur permettent de comprendre l’environnement sans multiplier les rendez-vous exploratoires et de montrer comment leur solution répond à une situation complète. Ils révèlent aussi les dépendances entre modules, les droits d’accès et les interfaces. Le fournisseur peut alors chiffrer plus justement ce qui relève du standard, du paramétrage ou d’un service complémentaire.


Faire du cahier des charges un outil de comparaison

Le document doit permettre de distinguer les solutions. Des exigences trop générales conduisent tous les éditeurs à répondre oui. Il faut préciser ce qui devra être montré, les données concernées, les interfaces attendues et le niveau de paramétrage nécessaire.

La réponse doit aussi faire apparaître les limites, les actions manuelles restantes et les dépendances à d’autres modules. Un oui assorti d’un développement spécifique, d’un coût supplémentaire ou d’un fonctionnement dégradé n’a pas la même valeur qu’une capacité standard.

Le cahier des charges nourrit ensuite la grille pondérée. Chaque critère reçoit un poids relié aux priorités. La PME évite ainsi de sélectionner le logiciel le plus impressionnant au lieu de celui qui répond le mieux à ses problèmes.

La sécurité, la protection des données et la gestion des habilitations ne doivent pas être réduites à une case générique. Il faut comprendre qui accède à quoi, comment les droits évoluent, quelles traces sont conservées et comment les données peuvent être récupérées. La sensibilité des informations RH exige une réponse concrète. L’objectif n’est pas de transformer le RRH en expert technique, mais de faire intervenir les compétences nécessaires au bon moment.

Pour rendre les réponses comparables, le document doit demander la même lecture du coût global : abonnement, mise en œuvre, reprise des données, interfaces, formation, support, évolutions prévisibles et conditions de sortie. Il doit aussi distinguer les fonctions disponibles immédiatement de celles annoncées sur une feuille de route. Cette précision évite de comparer un prix standard à une offre comprenant des prestations plus larges.


Savoir quand le cahier des charges est prêt

Un bon cahier des charges permet à un tiers de comprendre les objectifs avant de lire les fonctionnalités. Il montre les processus concernés, les cas prioritaires, les utilisateurs, les contraintes et les critères de réussite.

Il reste proportionné. La qualité ne se mesure pas au nombre de pages, mais à la capacité du document à produire des réponses comparables et à soutenir la négociation. Les sujets hors périmètre sont explicitement nommés au lieu d’être laissés dans l’ambiguïté.

Enfin, il appartient à l’entreprise. Le conseil peut structurer, questionner et révéler les angles morts, mais le RRH doit reconnaître ses choix dans le document. Le cahier des charges n’est pas une production externalisée que l’on découvre au moment de l’appel d’offres.

Avant l’envoi, une revue croisée avec la direction, la paie, les utilisateurs concernés et, si nécessaire, le référent technique permet de repérer les contradictions. Cette validation ne doit pas rouvrir tous les choix. Elle confirme que les hypothèses structurantes sont partagées. Le RRH conserve ainsi la maîtrise de la stratégie tout en sécurisant les points qui dépassent son seul périmètre.

Le cahier des charges est prêt lorsque l’entreprise peut expliquer ses priorités, ses renoncements et sa méthode de comparaison. Il ne l’est pas seulement parce qu’il compte beaucoup de pages. Un document court, précis et accompagné de cas d’usage peut produire des réponses plus utiles qu’un catalogue exhaustif. La qualité se mesure à la capacité des fournisseurs à répondre sans deviner l’intention du projet.

Pour objectiver la construction du cahier des charges, la PME doit conserver une photographie de départ. Elle peut documenter les outils utilisés, les opérations manuelles, les personnes sollicitées, les délais et les erreurs récurrentes. Cette base ne sert pas à fabriquer un retour sur investissement artificiellement précis. Elle permet de vérifier que le projet traite bien une difficulté réelle et de comparer la situation après quelques mois. Sans point de départ, une amélioration perçue reste difficile à expliquer et une déception ponctuelle peut masquer des progrès plus importants.

Un exercice utile consiste à décrire le scénario d’échec de la construction du cahier des charges. Que se passerait-il si les utilisateurs contournaient l’outil, si la reprise de données prenait du retard ou si la personne qui administre le système quittait l’entreprise ? Cette question ne vise pas à dramatiser. Elle révèle les dépendances et les mesures de prévention à intégrer au choix. Un risque devient pilotable lorsqu’il possède un responsable, un signal d’alerte et une réponse prévue. Il ne suffit pas de l’inscrire dans une colonne à la fin du projet.

Les affirmations décisives sur la construction du cahier des charges doivent être transformées en preuves. Une fonction annoncée comme simple peut être testée sur un cas d’usage ; une intégration annoncée comme standard peut être documentée ; un niveau de service peut être confirmé dans le contrat. Plus une promesse pèse dans la note finale, plus sa vérification doit être exigeante. Cette discipline protège l’éditeur autant que l’entreprise, car elle réduit les malentendus entre le langage commercial, le paramétrage réellement inclus et le fonctionnement attendu par les équipes.

Vous avez commencé à lister des modules sans parvenir à définir les priorités ? Un appel de qualification Blossom Talents permet d’examiner les problèmes, les processus et le niveau de maturité avant d’engager la rédaction ou la consultation des éditeurs.


À propos de l’autrice :

À propos de l’autrice : 
Jennyfer Montantin

Consultante RH, formatrice et fondatrice de Blossom Talents
Depuis plus de 15 ans, j’accompagne les entreprises dans leurs transformations RH et les professionnels dans leurs évolutions de carrière. 

J’interviens notamment sur la conduite du changement, les projets SIRH, la formation et les trajectoires professionnelles. Mon approche vise des décisions éclairées, réalistes et applicables.    Prendre rendez-vous

Jennyfer Montantin

Consultante RH, formatrice et fondatrice de Blossom Talents


Depuis plus de 15 ans, j’accompagne les entreprises dans leurs transformations RH et les professionnels dans leurs évolutions de carrière.

J’interviens notamment sur la conduite du changement, les projets SIRH, la formation et les trajectoires professionnelles. Mon approche vise des décisions éclairées, réalistes et applicables. Prendre rendez-vous

Commentaires


  • blossom-talents-contact-telephone-mobile
  • blossom-talents-calendrier-rendez-vous
  • blossom-talents-linkedin-officiel
  • blossom-talents-instagram-officiel
  • blossom-talents-youtube-officiel
bottom of page