ROI d'un SIRH : une méthode mesurable avant l'achat

Verdict : mesurer un processus, pas acheter un pourcentage

Un dossier de ROI devient fragile dès qu'il commence par « un SIRH fait gagner X heures par mois ». Ce chiffre dépend du processus, du nombre d'acteurs, des règles de validation, de la qualité des données et de l'adoption. Il ne peut pas être transféré d'une entreprise à une autre sans mesure.

La méthode robuste commence par une question plus étroite : sur quel processus observable le projet doit-il changer une décision ou supprimer une charge ? Par exemple : gérer une demande d'absence, préparer l'onboarding, produire un export de variables de paie ou retrouver un document salarié.

Pour chaque processus, il faut une base avant projet, un coût complet, une cible, une mesure après projet et une règle d'arrêt. Le ROI agrège ensuite ces éléments ; il ne les remplace pas.

1. Définir le périmètre avant de chiffrer

Un projet « SIRH » peut couvrir des fonctions très différentes. Additionner des gains théoriques sur les congés, le recrutement, la formation et les entretiens alors que seule la gestion administrative sera déployée gonfle artificiellement le résultat.

Construisez d'abord le registre suivant :

Ne retenez dans le ROI initial que les processus réellement inclus au contrat et au déploiement. Les modules « prévus plus tard » appartiennent à un scénario futur séparé.

2. Établir la base de référence

Mesurez au moins plusieurs cycles complets. Une seule semaine peut être atypique ; un seul mois peut masquer les entrées, départs ou clôtures annuelles. Pour chaque opération, notez :

• le temps actif de chaque rôle, et non le simple délai calendaire ;
• le nombre de passages de relais et de relances ;
• les erreurs ou reprises effectivement observées ;
• les outils utilisés et les doubles saisies ;
• la preuve finale produite ;
• les cas qui sortent du processus standard.

La mesure doit être assez légère pour être répétée. Un échantillon daté et documenté vaut mieux qu'une estimation précise à la minute mais impossible à reproduire.

3. Distinguer temps libéré et économie

Une heure gagnée ne produit pas automatiquement une heure de salaire économisée. Si l'équipe termine plus tôt mais que sa capacité n'est ni réallouée ni transformée en dépense évitée, il s'agit d'un gain de capacité, pas encore d'un gain financier.

Classez chaque bénéfice dans une catégorie :

Cette séparation empêche de compter deux fois la même amélioration : une heure supprimée ne peut pas être valorisée simultanément comme salaire économisé et comme capacité réallouée.

4. Calculer le coût complet

Le coût d'acquisition affiché ne suffit pas. Utilisez la même période pour les coûts et les gains, en distinguant les dépenses de mise en place des coûts récurrents.

Coûts de mise en place

• cadrage et paramétrage ;
• reprise, nettoyage et contrôle des données ;
• intégrations et interfaces ;
• temps des RH, managers, IT, paie et référents ;
• formation et communication ;
• fonctionnement parallèle et correction des écarts.

Coûts récurrents

• licence, options, stockage et connecteurs ;
• support ou accompagnement ;
• administration fonctionnelle et gestion des droits ;
• contrôles de données et revue des paramétrages ;
• maintenance des interfaces ;
• réversibilité annualisée : exports, assistance et future migration.

Ajoutez une réserve identifiée plutôt qu'un pourcentage opaque : reprise d'un historique incomplet, connecteur non inclus ou population supplémentaire. Chaque réserve doit avoir une cause et une condition de consommation.

5. Formules qui restent lisibles

Sur une période donnée :

Gain net = gains financiers vérifiés − coût complet.

ROI = gain net ÷ coût complet × 100.

Délai de retour = moment où les gains cumulés dépassent les coûts cumulés.

Le pourcentage ne doit jamais être présenté seul. Un ROI de 100 % sur un petit montant et un ROI de 20 % sur un projet structurant ne racontent pas la même décision. Montrez les flux par mois ou par trimestre afin de rendre visible le décaissement initial et la montée progressive de l'adoption.

6. Construire trois scénarios sans inventer de gains

Un scénario n'est pas une opinion « pessimiste, moyenne, optimiste ». C'est un ensemble d'hypothèses explicitement modifiées.

Le scénario haut reste conditionnel. Il ne peut pas devenir le cas central au motif qu'il rend le projet rentable.

7. Intégrer les données personnelles comme une condition de valeur

Un SIRH concentre des données de salariés. Une recherche plus rapide n'est pas un gain si les droits sont trop larges, si les données sont conservées sans durée définie ou si les actions sensibles ne sont pas traçables.

Le référentiel CNIL publié en 2026 aide à déterminer des durées adaptées aux traitements RH. Il ne remplace pas l'analyse des finalités et obligations propres à l'entreprise. Avant d'attribuer un gain au futur système, vérifiez donc :

• que les données utiles peuvent être séparées des données arrivées à échéance ;
• que les rôles limitent l'accès au besoin réel ;
• que les opérations sensibles sont journalisées de manière exploitable ;
• que l'export permet de répondre à une demande ou à un contrôle ;
• que la suppression et l'archivage sont testables ;
• que le sous-traitant et les éventuels transferts sont documentés.

Une fonction qui accélère un processus mais crée un travail manuel permanent de contrôle ou de purge doit voir ce coût ajouté au modèle.

8. Protocole de preuve avant décision

Étape 1 — choisir deux processus prioritaires

Retenez un processus fréquent et un processus à risque ou à nombreux passages de relais. Décrivez leur point de départ, leur fin et leur preuve.

Étape 2 — observer la situation actuelle

Mesurez plusieurs cycles, conservez les volumes et documentez les écarts. Faites valider la base par les personnes qui exécutent réellement le travail.

Étape 3 — tester sur des cas anonymisés

Demandez à chaque solution de rejouer les mêmes cas, y compris une exception. Chronométrez les actions des utilisateurs et comptez les reprises hors outil.

Étape 4 — vérifier les coûts cachés

Obtenez un chiffrage écrit des connecteurs, de la migration, du support, du stockage, des options, des environnements et de la sortie. Toute ligne absente reste une hypothèse, pas zéro euro.

Étape 5 — tester l'administration

Créez, modifiez et retirez un droit. Exportez un journal. Appliquez une durée de conservation à un jeu de données de test. Un bénéfice dépendant de l'administrateur doit inclure son temps.

Étape 6 — fixer le seuil de décision

Écrivez avant le choix le gain net minimal, le délai maximal de retour et les deux indicateurs opérationnels attendus. Définissez l'action si le seuil n'est pas atteint : correction, réduction du périmètre ou arrêt.

Étape 7 — mesurer après 30, 90 et 180 jours

Rejouez le même échantillon. Comparez temps actif, reprises, délais, satisfaction des acteurs et coûts réels. Ne créditez le ROI que des gains observés et réalloués.

Contre-cas : quand ne pas acheter de SIRH

Le projet n'est pas justifié si le processus est rare, stable et déjà fiable, si le principal problème est une règle de gestion non décidée, ou si les données sources sont trop incohérentes pour être automatisées. Dans ces cas, clarifier le processus ou corriger les données peut produire plus de valeur qu'un nouvel outil.

Il faut aussi différer la décision si aucun propriétaire ne peut administrer les droits et paramétrages, si la migration n'a pas de responsable ou si l'éditeur ne fournit pas les preuves nécessaires à la réversibilité. Le coût du statu quo doit être mesuré, mais le coût d'un déploiement mal préparé aussi.

Limites et règle de révision

Cette méthode ne promet aucun nombre d'heures, délai de retour ou baisse de turnover. Elle transforme ces affirmations en hypothèses vérifiables. Les prix et capacités d'un produit doivent être confirmés par un contrat, un essai et des exports datés.

Révisez le modèle dès que le périmètre, les populations, le coût contractuel ou les règles de conservation changent. Un écart supérieur à 20 % entre une hypothèse importante et la mesure post-déploiement déclenche un recalcul complet plutôt qu'une simple justification a posteriori.