Étude de cas 01 · Gouvernance des releases
Reprendre en main un processus de release fragmenté
Un paysage SAP multi-équipes où les changements arrivaient sans plan, où les transports se contredisaient et où personne ne pouvait dire avec certitude ce qui partait en production le jeudi.
Anonymisé — reconstruit à partir des missions figurant dans mon CV. Aucun document, chiffre ou résultat client n’est divulgué.
ContextePlusieurs flux SAP — fonctionnel, Basis, intégration — livraient à leur propre cadence dans un paysage de transports partagé. Les demandes de changement étaient suivies dans deux outils à la fois, et la release hebdomadaire était devenue une négociation plutôt qu'un planning.
Enjeux
- Aucune source de vérité sur le contenu d'une release
- Transports en conflit découverts au moment de l'import
- Décisions Go/No-Go prises sans preuve documentée
- Équipes métier informées tardivement, donc surprises
Mes responsabilitésRelease management : responsabilité du calendrier, des règles de gouvernance et des preuves de readiness.
MéthodologieUn calendrier de release unique alimenté par chaque flux, des fenêtres gelées annoncées un mois à l'avance, une porte de validation du changement avec critères d'entrée explicites, et un dossier Go/No-Go construit sur des preuves plutôt que sur des avis.
Livrables
- Calendrier de releases (glissant, par flux)
- Cadre de gouvernance : règles CAB, RACI, escalade
- Dossier de décision Go/No-Go
- Tableau de bord KPI de readiness
Valeur métierLes releases ont cessé d'être un débat. Le calendrier a donné la même échéance à tous les flux, la porte a détecté les transports en conflit avant l'import plutôt que pendant, et le dossier Go/No-Go a transformé une réunion en décision.