Un système d’information des ressources humaines (SIRH) se change en moyenne tous les dix ans. Dix ans, c’est plus long que la présence moyenne d’un directeur des ressources humaines à son poste, plus long que la plupart des plans stratégiques, plus long que la durée de vie de bien des organisations telles qu’elles se pensent aujourd’hui.
Pourtant, la décision se prend souvent comme un projet informatique de plus : un cahier des charges fonctionnel, une grille de comparaison, une démonstration, une signature. Ce que l’on signe réellement, c’est autre chose. C’est une dépendance de dix ans.
Ce que vous engagez vraiment
Le choix d’un SIRH engage trois choses qui ne figurent presque jamais dans la grille de comparaison. Un cadre contractuel, avec sa durée, ses conditions de renouvellement et ses conditions de sortie. Un modèle de données, qui décidera de ce que vous saurez mesurer et de ce que vous ne saurez pas. Et une capacité, ou une incapacité, à changer plus tard.
Ce dernier point est le moins regardé et le plus structurant. À la signature, personne ne se projette dans la sortie. C’est précisément pour cela qu’elle coûte si cher le jour où elle devient nécessaire.
Quatre dépendances à nommer
La première est la dépendance à l’éditeur. Sa feuille de route devient la vôtre : les fonctions qu’il priorise sont celles dont vous disposerez, celles qu’il abandonne disparaîtront de votre paysage. Sa politique tarifaire s’applique à un socle que vous ne pouvez plus quitter facilement. Et sa décision d’arrêter un produit ou de le retirer d’un marché s’impose à vous, comme l’ont récemment découvert des entreprises dont la solution de paie a été retirée du marché français.
La deuxième est la dépendance aux données. La paie et les données sociales figurent parmi les données les plus sensibles de l’entreprise. Leur localisation, le droit auquel elles sont soumises et la possibilité de les récupérer dans un format exploitable ne sont pas des sujets techniques. Ce sont des sujets de direction, particulièrement lorsque l’hébergement relève d’une entité soumise à un droit extraterritorial.
La troisième est la dépendance à l’intégrateur. Quand un projet est déployé sans que les compétences soient internalisées, la connaissance de l’outil part avec les consultants. L’organisation se retrouve alors dépendante d’un tiers pour la moindre évolution, et souvent incapable de répondre à ses propres utilisateurs. C’est un cas que je rencontre régulièrement, et il précède presque toujours le retour des tableurs.
La quatrième est la dépendance de réversibilité. Pouvez-vous sortir, dans quel délai, à quel coût, et avec quoi ? Sur ce point, une réalité juridique mérite d’être connue des directions : aucune loi française n’impose de clause de réversibilité dans un contrat de logiciel en service en droit privé. Le dispositif est entièrement contractuel. Ce que vous n’avez pas négocié, vous ne l’aurez pas.
Changer de posture : décider des dépendances plutôt que de l’outil
La conséquence pratique est simple. Cessez de chercher la meilleure solution dans l’absolu. Commencez par décider quelles dépendances créent de la valeur, et lesquelles réduisent votre liberté d’action.
Certaines dépendances sont saines et assumées. Confier la conformité réglementaire de la paie à un éditeur qui en fait son métier vous décharge d’une veille lourde et d’un risque réel. C’est un échange raisonnable.
D’autres réduisent votre marge de manœuvre sans contrepartie. Un modèle de données fermé qui vous empêche de produire vos propres indicateurs. Un format d’export propriétaire, lisible seulement par l’éditeur. Une clause de sortie vague, renvoyée à des délais raisonnables, qui ne veut rien dire le jour du contentieux. Celles-là se limitent, par le contrat, par l’architecture, ou par une clause de réversibilité écrite.
Ce qui se joue à la signature
Trois points méritent d’être traités avant de signer, parce qu’ils coûtent alors dix fois moins cher qu’après.
Le premier est le plan de réversibilité, annexé au contrat et non résumé en une phrase. Il précise le périmètre restitué (données brutes, mais aussi paramétrages et documentation technique), le format, dans des standards ouverts et documentés, un délai ferme, le niveau d’assistance et son coût. Une bonne pratique consiste à tester ce plan six mois après la mise en service, quand tout va bien, plutôt que de le découvrir en pleine rupture.
Le deuxième est la propriété et la portabilité des données. Vous restez propriétaire de vos données, mais cette propriété ne vaut que si vous pouvez les extraire à tout moment, et pas seulement en fin de contrat.
Le troisième est la clause de sortie elle-même. Les engagements de trois ans minimum sont courants, souvent assortis de pénalités anticipées représentant une part substantielle du solde dû. Ces conditions se négocient à l’entrée. Jamais après.
La dépendance qui se paie après la mise en production
Il reste une dépendance dont on parle peu, et qui est pourtant la plus fréquente : celle qui naît quand l’outil est en place mais que personne ne se l’approprie. Les fonctions existent, elles sont payées, et les équipes travaillent à côté. L’organisation dépend alors d’un système qu’elle n’utilise pas vraiment, et de fichiers personnels qu’elle ne contrôle pas.
Cette dépendance-là ne se règle ni par le contrat ni par l’architecture. Elle se traite par la conduite du changement après la mise en production, précisément la phase que les projets abandonnent une fois le déploiement prononcé.
Choisir un SIRH, c’est donc arbitrer entre des dépendances, pas comparer des fonctionnalités. Les organisations qui gardent la main sur dix ans sont celles qui ont posé cette question à la signature, quand elles avaient encore le choix.
Pour aller plus loin : Transformation digitale & SIRH · Livre blanc : Souveraineté des données RH et IA