Six business units, deux éditeurs partenaires, une équipe projet de vingt-sept personnes et un écosystème SIRH où tout se tient. Ce retour d'expérience raconte comment nous avons construit un pilotage consolidé, capable de donner à chacun la même photographie du projet, du daily jusqu'au COMEX.
01Un outil en fin de vie, une plateforme unique en ligne de mire
Le groupe, acteur majeur du retail, devait remplacer sa brique de gestion des temps, devenue obsolète. Il a saisi l'occasion pour viser plus loin : mieux couvrir les besoins métier et rendre la planification des équipes plus efficiente. La cible, une plateforme unique de GTA (gestion des temps et activités) avec planification intégrée, pour 36 000 collaborateurs répartis dans six BU en France.
Pour y parvenir, l'entreprise s'est appuyée sur deux éditeurs travaillant en partenariat, chacun avec sa propre roadmap et ses propres contraintes. Nous avons été sollicités pour mettre en place les outils de pilotage du projet, au sein d'une équipe de 27 personnes aux profils très variés. Notre périmètre courait du cadrage et de la priorisation des fonctionnalités jusqu'au déploiement des premiers magasins pilotes.
02Pourquoi une bascule GTA demande autant de précautions
Sur le papier, on remplace un outil par un autre. Dans la réalité, la GTA vit au milieu d'un écosystème SIRH dense, structuré autour de trois briques majeures et de huit briques mineures, toutes interconnectées et portées par différentes BU.
Heures travaillées, absences, compteurs, plannings des équipes.
Elle transforme les variables reçues en bulletins.
Elle porte les dispositions contractuelles de chaque collaborateur.
La GTA finit toujours sur le bulletin
Heures travaillées, majorations, absences, compteurs de congés : tout ce que la GTA saisit ou calcule dépend des dispositions contractuelles du collaborateur, portées par la gestion administrative, puis se transforme en variables de paie. Une règle mal paramétrée se propage donc jusqu'au bulletin, avec des conséquences humaines et sociales immédiates.
Le temps de travail, un sujet réglementaire
Depuis 2019, l'employeur doit disposer d'un système objectif, fiable et accessible pour mesurer le temps de travail journalier. Une GTA indisponible, ou qui calcule faux pendant quelques semaines, expose l'entreprise sur le plan social et réglementaire. Et comme chaque BU obéit à ses propres accords d'entreprise, le nombre de règles à vérifier grimpe très vite.
Un écart de calcul découvert après la paie se corrige dans la douleur : régularisations, questions des salariés, dialogue social tendu. Mieux vaut le débusquer pendant la recette et les pilotes, quand il ne coûte encore qu'un ticket.
Des dépendances dans tous les sens
Chaque BU vit au rythme de ses échéances sociales : négociations annuelles, clôtures, pics d'activité commerciale pendant lesquels personne ne veut entendre parler d'un nouvel outil en magasin. Ajoutez plusieurs éditeurs et services interconnectés, et un glissement de trois semaines sur une release éditeur d'une autre brique se répercute aussitôt sur tous les plannings.
Face à ces risques, nous avons proposé un pilotage consolidé autour de cinq objectifs.
03Maîtriser la trajectoire budgétaire et temporelle
Premier chantier : établir les restes à faire au regard des fonctionnalités attendues à chaque jalon. Chaque stream a été passé en revue. Qu'est-ce qui était livré ? Que restait-il à faire ? De quels tiers dépendait-on, lot par lot, sur les périmètres arbitrés ?
Pour que ces restes à faire s'additionnent sans fausser le total, il a fallu standardiser les conventions de chiffrage. Une analyse capacitaire a ensuite mis à plat les forces réellement disponibles et fait ressortir les goulots d'étranglement sur les profils critiques.
Tout l'intérêt tient dans ce lien direct entre plan de charge et budget. Quand une release éditeur glisse, on lit immédiatement ce que cela représente en charge interne et en budget. En comité, les arbitrages se transforment alors en choix entre scénarios chiffrés.
Un arbitrage sans chiffres reste une opinion. Avec un plan de charge partagé, il devient une décision.
04Une gouvernance à plusieurs étages, chacun avec son périmètre
Vingt-sept personnes, six BU cibles, cinq streams, deux éditeurs au cœur du dispositif et d'autres encore en dépendance : sans règles claires, chaque sujet finit par remonter partout. La gouvernance a donc été posée en plusieurs niveaux, chacun avec un périmètre de décision explicite.
Le principe qui fait tenir l'ensemble est simple : chaque sujet se tranche au niveau le plus bas capable de le faire. Les comités supérieurs gardent ainsi leur temps pour les vrais arbitrages, et les équipes avancent sans attendre une réunion mensuelle pour débloquer un détail.
05Méthodes hybrides : le bon cadre pour chaque chantier
Le projet a combiné trois approches, choisies au cas par cas selon le degré de dépendance de chaque chantier.
Sans dépendance externe, l'équipe interne maîtrisait son backlog, livrait par incréments courts et gardait la main sur sa roadmap.
Un cadre contractuel, des jalons et des recettes formelles, avec des équipes aux dépendances et aux méthodes multiples.
Pour structurer le run et faire évoluer la solution en continu, une fois les premiers magasins stabilisés.
Reste la question délicate des coutures entre ces mondes. Une user story agile qui dépend d'une livraison éditeur en cycle en V hérite de son calendrier, qu'on le veuille ou non.
La story liée démarre au sprint qui suit la release éditeur. Les stories autonomes avancent à leur rythme, sans rien attendre de personne.La release glisse de trois semaines et la story liée recule d'un sprint, alors que les stories autonomes restent à leur place. C'est ce point de couture qu'il faut rendre visible dans le plan de charge.
Ces points de couture doivent apparaître noir sur blanc dans le plan de charge et dans la matrice de risques. C'est ce qui permet de décider vite, et en connaissance de cause, sur les jalons du chemin critique.
06Piloter par des indicateurs partagés
Sur un projet complexe, chacun regarde les jalons à travers ses propres objectifs et ses propres contraintes. Pour clarifier la décision, une part importante de la mission a consisté à installer des tableaux de bord et des indicateurs communs, afin que tout le monde voie la même photographie au même moment.
Des objectifs clairs, déclinés en résultats clés mesurables, pour s'accorder sur le périmètre de chaque échéance.
- Périmètre des magasins pilotes
- Planification des releases
- Engagements de run
- Planification des vagues
- Couverture et efficacité magasin
Ils alimentent les OKR et nourrissent les comités de suivi, semaine après semaine.
- Jalons tenus ou glissés
- Consommation du reste à faire
- Avancement par stream
Un outillage remis au carré
Les mesures d'avancement s'appuyaient sur plusieurs sources :
Une partie de la mission a consisté à structurer les pratiques des équipes dans Jira : conventions de tickets, statuts communs, rattachement aux streams et priorisation des principales échéances. Les cahiers et plans de tests ont été en partie intégrés dans Xray, l'application de gestion des tests de Jira qui relie tests, plans de test et exécutions.
Cette traçabilité prend toute sa valeur au moment des arbitrages, et surtout lors des go / no go sur les grandes échéances. La décision repose alors sur trois questions factuelles.
Chaque exigence reliée à ses tests et à leurs exécutions.
Les anomalies ouvertes, avec leur gravité et leur porteur.
Les BU, magasins et règles concernés par chaque écart.
07Trois magasins pilotes pour éprouver la bascule
Pour fiabiliser la bascule grâce aux retours du terrain, des magasins pilotes volontaires ont été identifiés puis animés en plusieurs phases successives. Le choix s'est porté sur trois magasins basculés en décalé, soit 600 personnes concernées.
Ce périmètre restreint permet d'éprouver les règles de calcul en conditions réelles, de mesurer l'effort d'accompagnement des managers et d'ajuster le tir avant d'élargir. Encore faut-il que les pilotes reflètent la diversité des situations : formats de magasin, organisations du travail, accords applicables. C'est cette représentativité qui prépare les vagues de déploiement suivantes.
Un hypercare qui trie chaque retour
Pendant plusieurs semaines, les magasins pilotes ont bénéficié d'un accompagnement renforcé, appuyé sur un suivi structuré de leurs retours. Chaque remontée était qualifiée, puis orientée vers le bon interlocuteur.
- Remontées des managers
- Anomalies de calcul
- Questions d'usage
Ce tri systématique a fiabilisé les solutions avant les vagues suivantes. Le passage en run s'est fait progressivement, à mesure que les pilotes se stabilisaient.
08Ce que cette bascule nous enseigne
- Relier plan de charge et budget
Chaque glissement se traduit aussitôt en charge et en euros. Les comités arbitrent entre des scénarios chiffrés, et les débats gagnent en sérénité.
- Donner à chaque instance son périmètre de décision
Une gouvernance à plusieurs étages fonctionne quand chacun sait précisément ce qu'il tranche, et ce qu'il fait remonter.
- Choisir la méthode chantier par chantier
Scrum, cycle en V et mode produit cohabitent très bien, à condition de rendre visibles les points de couture entre eux.
- Partager une seule photographie du projet
Les OKR pour le cap, les KPI pour le quotidien, la traçabilité dans Jira et Xray pour les go / no go.
- Faire des pilotes un vrai laboratoire
Représentatifs, basculés en décalé et suivis en hypercare, ils préparent le déploiement à grande échelle.
Ntico Services
Comment Ntico accompagne vos projets de transformation SIRH
Cette mission illustre notre façon d'intervenir sur les projets de transformation : un pilotage outillé, une gouvernance claire et une méthode choisie selon la réalité du terrain.
Au sein de Ntico Services, nos PMO et nos directeurs de projet prennent en charge le pilotage et la réalisation de projets multi-acteurs, de l'audit de charge jusqu'au passage en run.
Vous préparez une bascule SIRH ou un déploiement multi-BU ? Nos équipes seront ravies d'échanger avec vous sur votre contexte.
