Hugo, peux-tu nous parler du projet SIRH que tu as mené récemment ? Quels étaient les principaux défis ?
Bien sûr. Nous avons mené un projet d’envergure pour déployer SAP SuccessFactors en un an. C’était un Big Bang, ce qui signifie que tout a été lancé simultanément sur neuf régions, trente pays et environ deux mille collaborateurs. Rien que l’ échelle du projet en faisait un défi impressionnant.
À cela s’ajoutaient des contraintes spécifiques : nous devions reprendre deux années de données historiques, mettre en place six à sept interfaces comme la paie, Active Directory ou Concur, et tout cela avec trois équivalents temps plein (ETP) dédiés au projet principalement côté IT.
Ces parties prenantes ont été clés dans la mise en place de ce projet.
J’étais personnellement très impliqué sur l’ensemble des aspects du projet : Design, reprise des données et conduite du changement incluant la communication.
Mais en toute honnêteté, il a fallu redoubler d’efforts et une collaboration constante entre les équipes centrales et locales afin de mener à bien ce projet de transformation.
Finalement, c'est un projet qui s’est très bien déroulé. Ce qui est rare dans des projets de cette envergure.
Comment as-tu réussi à embarquer autant de régions dans un projet aussi complexe ?
La clé, c’était l’intégration et la transparence dès le départ. De même, le soutien et l’implication des partenaires IT interne a été précieux car sans eux cela n’aurait pas été possible.
Toutes les semaines, on organisait des points avec les RH et les IT de chaque région.
On ne s’est jamais contentés de leur dire : “Voici ce que vous devez faire.” On leur montrait pourquoi ce projet était important pour eux, pas seulement pour le Central.
Lors de l’appel d’offres, par exemple, les DRH et les directeurs IT des régions étaient invités à participer aux soutenances des solutions. On leur demandait : “Qu’avez-vous aimé ? Qu’avez-vous trouvé difficile ?” Ces feedbacks ont pesé dans le choix final. Ils savaient qu’ils avaient leur mot à dire en tant que partie prenante active.
Je me souviens d’une anecdote amusante : lors d’une présentation du modèle global de données, une RH s’est étonnée en voyant le nombre de champs à remplir. On a donc réduit le modèle de données au strict nécessaire, en expliquant que tout devait servir à un besoin concret, souvent drivé par la conformité légale.
La qualité des données a dû être un gros défi. Comment as-tu géré cette partie ?
C’était un vrai casse-tête. Certaines régions n’avaient pas de système source fiable, et il fallait tout construire à partir de données brutes. Ainsi, nous leur avons demandé de se concentrer uniquement sur les données avec un niveau de fiabilité élevé. On leur disait : “Mettez les noms des sites tels qu’ils apparaissent chez vous, et nous nous chargerons de transformer ces données pour qu’elles s’intègrent dans le système.”
On a aussi utilisé des outils comme des macros VBA pour vérifier automatiquement la cohérence des fichiers. Malgré cela, des erreurs se glissent toujours.
Pour surmonter ces problèmes, on a mis l’accent sur la responsabilisation. Je leur disais : “Si les données sont fausses, ce n’est pas moi au Central qui en subirait les conséquences. Ce sont vos équipes locales qui seront malheureusement impactées”. Cela a eu un effet immédiat sur leur implication.
Tu as collaboré avec des intégrateurs comme Deloitte et Arago. Comment ça s’est passé ?
Très bien. Deloitte a été excellent pour la conduite du changement et l’AMOA. Leur expertise a vraiment fait la différence, surtout pour accompagner les équipes dans cette transition.
Avec Arago, cela s’est aussi très bien passé. Ce que j’ai particulièrement apprécié chez eux, c’est leur indépendance par rapport à SAP. Ils étaient capables de challenger les solutions, ce qui nous a permis de trouver des compromis pertinents.
Les interfaces avec d’autres systèmes comme la paie ou Active Directory sont souvent critiques. Comment les avez-vous gérées ?
C’était effectivement un des points les plus complexes. Nous avions six à sept interfaces en parallèle, dont deux liées à la paie. deux personnes ont été lead sur cette partie, et cela a été crucial.
De mon côté, mon bagage en IT m’a aidé à dialoguer avec les équipes techniques. Par exemple, quand un problème semblait insoluble, j’avais cette philosophie : “S’il n’y a pas de solution, ce n’est pas un problème.” Le raisonnement peut sembler simpliste, mais cela aide à ne pas s’attarder sur ce qui est impossible et à se concentrer sur ce qui est réalisable.
Comment as-tu géré les différences culturelles entre les régions ?
Chaque région avait son propre style. Certaines zones, par exemple, préféraient aller vite et corriger les erreurs après, tandis que d’autres voulaient tout perfectionner avant de valider.
Pour garder tout le monde aligné, on a fixé des règles claires dès le départ.
Le Big Bang signifiait que tout le monde devait être prêt au même moment, mais on leur laissait la liberté de choisir comment atteindre cet objectif, tant qu’ils respectaient le cadre global.
Avec le recul, quelles sont les principales leçons que tu retiens de ce projet ?
Ce projet m’a appris plusieurs choses :
Impliquer les équipes locales dès le début. Si les régions ne se sentent pas concernées, le projet risque de tomber à l’eau. Nous avons pris le temps de les écouter, de répondre à leurs questions et de valoriser leurs contributions.
Responsabiliser tout le monde. Pour la qualité des données, par exemple, faire comprendre que les erreurs impacteraient directement les équipes locales a été déterminant pour améliorer leur implication.
Rester pragmatique. Chercher la perfection est inutile. On a fixé des objectifs réalistes, comme atteindre 80 % de données fiables au go-live, et on a corrigé le reste progressivement.
Communiquer sans relâche. Les points hebdomadaires, les mises à jour régulières et même une dose d’humour ont créé un climat de confiance qui a permis d’avancer sereinement.
S’appuyer sur des experts compétents. Les intégrateurs et consultants externes comme Deloitte ou Arago ont été des partenaires essentiels pour surmonter les défis techniques et organisationnels.
Un dernier conseil pour ceux qui souhaitent lancer un projet SIRH ?
Rester transparent et humble. Dire ce que tu sais, mais aussi ce que tu ne sais pas. Reconnaître que tout ne sera pas parfait au départ, et montrer que tu es prêt à avancer ensemble.
Et surtout, se rappeler qu’un projet SIRH, même s’il est stratégique, ne sauve pas des vies. On peut travailler sérieusement tout en restant dans une ambiance positive et collaborative. Cela change tout.