Parce que la réponse change tout. Si le problème vient de l’outil, il faut envisager une évolution ou un remplacement. Si le problème vient de l’usage, un nouveau système reproduira exactement les mêmes difficultés, avec en prime les coûts d’une migration et d’un déploiement.
Or dans beaucoup d’organisations, les deux se mélangent. L’outil a des limites réelles, mais l’usage est aussi en cause. Distinguer les deux, c’est la condition pour prendre la bonne décision et éviter de traiter le mauvais problème.
Pourquoi la distinction est si difficile à faire
Quand un SIRH est perçu comme insuffisant, la tentation est grande d’en attribuer la responsabilité à l’outil. C’est plus simple, et c’est souvent ce que remontent les équipes sur le terrain.
Mais plusieurs signaux doivent alerter :
- Les mêmes plaintes existaient avec l’ancien système, avant la dernière migration.
- Les fonctionnalités incriminées existent dans l’outil, mais personne ne les utilise.
- Les difficultés varient fortement d’une équipe à l’autre avec le même outil.
- Les managers contournent le système, mais sans se plaindre de ses limites fonctionnelles.
Dans ces cas, l’outil n’est probablement pas le seul coupable. Et parfois, il n’est pas coupable du tout.
Les signaux d’un problème d’outil
Un outil est objectivement en cause quand ses limites sont structurelles, c’est-à-dire quand elles ne peuvent pas être résolues par une meilleure configuration, une formation ou un changement de processus.
Les signaux les plus nets :
- Des fonctionnalités clés sont absentes et ne peuvent pas être développées dans le système actuel.
- L’architecture technique ne permet pas les intégrations nécessaires avec les autres outils de l’entreprise.
- La solution n’évolue plus : pas de nouvelles versions, support en fin de vie, éditeur peu réactif.
- Les temps de traitement ou les interfaces sont tellement dégradés qu’ils rendent l’usage impossible, même avec de la bonne volonté.
- Le coût de maintenance et de personnalisation dépasse celui d’un remplacement.
Quand plusieurs de ces signaux sont présents simultanément, la question du remplacement est légitime. Mais même dans ce cas, il vaut mieux comprendre les causes profondes des problèmes d’usage actuels avant de choisir la solution suivante, pour ne pas reproduire les mêmes erreurs.
Les signaux d’un problème d’usage
Un problème d’usage est plus subtil à identifier, parce qu’il se manifeste exactement de la même manière qu’un problème d’outil : insatisfaction, contournements, données peu fiables, reportings difficiles.
Mais les causes sont différentes :
L’adoption est inégale
Certains managers utilisent bien l’outil, d’autres pas du tout. Les fonctionnalités sont les mêmes pour tout le monde, mais les résultats varient fortement selon les équipes. Ce n’est pas un problème d’outil. C’est un problème d’accompagnement, de formation ou de processus.
Les processus ne sont pas cadrés
Le système propose des workflows, mais chaque équipe a développé sa propre manière de faire. Certains valident dans l’outil, d’autres envoient un email, d’autres encore maintiennent un fichier Excel en parallèle. Résultat : la donnée dans le SIRH n’est jamais vraiment fiable, pas parce que l’outil dysfonctionne, mais parce que personne ne l’alimente correctement.
La donnée n’a jamais été nettoyée
Le système a absorbé des années de saisies hétérogènes, de référentiels incohérents, de doublons non traités. Il produit des résultats peu exploitables non pas parce qu’il est mauvais, mais parce qu’on lui demande de faire quelque chose de correct avec une matière première défaillante.
Les utilisateurs n’ont pas été formés aux bons usages
Le déploiement a eu lieu, la formation de base a été faite, mais les utilisateurs n’ont pas compris pourquoi ils devaient utiliser le système d’une certaine manière, ni quel bénéfice concret ils en tiraient. Sans ce « pourquoi », l’adoption reste superficielle et les contournements s’installent.
Comment objectiver le diagnostic
La bonne méthode pour distinguer les deux n’est pas de demander aux utilisateurs si l’outil leur convient. Ils diront non, quelle que soit la cause réelle du problème.
Elle consiste à analyser les usages réels, pas les perceptions.
Questions pour diagnostiquer un problème d’outil | Questions pour diagnostiquer un problème d’usage |
La fonctionnalité manquante peut-elle exister dans une autre solution du marché ? | Les fonctionnalités incriminées existent-elles déjà dans l’outil ? |
Le problème est-il le même dans toutes les équipes ? | Certaines équipes s’en sortent mieux avec le même outil ? |
L’éditeur peut-il faire évoluer le système dans un délai raisonnable ? | Les processus associés sont-ils clairement définis et documentés ? |
Le coût de personnalisation est-il justifiable par rapport à une migration ? | La donnée dans le système est-elle fiable et à jour ? |
Dans la pratique, le diagnostic révèle presque toujours une combinaison des deux. L’enjeu est alors de pondérer : est-ce que les limites de l’outil sont rédhibitoires, ou est-ce que l’essentiel des gains passe d’abord par une remise à plat des usages ?
Ce que cette distinction change dans la décision
Quand le problème est principalement un problème d’usage, il est souvent possible de regagner beaucoup de valeur sans changer d’outil. Standardiser les processus, former les managers, fiabiliser la donnée, simplifier les workflows existants : ces actions sont moins visibles qu’un projet de migration, mais elles produisent des résultats rapides et durables.
Quand le problème est principalement un problème d’outil, le changement est justifié. Mais il doit être préparé différemment : en comprenant précisément ce qui a dysfonctionné dans l’usage de l’ancien système, pour ne pas reproduire les mêmes erreurs avec le nouveau.
Dans tous les cas, la décision la plus coûteuse n’est pas de changer d’outil. C’est de changer d’outil sans avoir compris pourquoi l’ancien ne fonctionnait pas. |
Par où commencer
Avant toute décision, consacrez quelques semaines à un audit des usages réels. Pas un questionnaire de satisfaction, mais une analyse concrète :
- Quelles fonctionnalités sont effectivement utilisées, par qui, et à quelle fréquence ?
- Quels contournements ont été mis en place, et pourquoi ?
- Quelle est la qualité réelle de la donnée dans le système ?
- Quels processus sont bien exécutés, et lesquels dérivent ?
Ces quatre questions donnent une image bien plus précise de la situation que n’importe quelle démonstration de solution concurrente.
Pour aller plus loin
Si cet article vous a aidé à clarifier votre situation, cette ressource peut compléter votre réflexion :
Vous souhaitez aller plus loin avec un regard extérieur sur votre situation ? Nos équipes sont disponibles pour un premier échange, sans engagement.
