Éliminer les goulots d'étranglement : fluidifier un flux de livraison en 3 sprints

Sur une mission EDF (remplacement d’une GED utilisée par 6 unités, équipe MOE de 18 personnes), l’équipe livrait, mais le flux bouchonnait. Tout s’accumulait en review et en test, les livraisons arrivaient en bloc en fin de sprint, et personne ne savait vraiment quand un ticket sortirait.

Voici, factuellement, comment je l’ai diagnostiqué et résorbé en 3 sprints.

Le symptôme, mesuré

À mon arrivée, aucune métrique n’était suivie. J’ai mis en place le suivi du débit, de la vélocité, du temps de cycle et du WIP, et j’ai orienté les rétrospectives sur l’analyse de ces données plutôt que sur les impressions.

Premier indicateur parlant : le nombre moyen de tickets accumulés en review à chaque sprint.

En parallèle, le temps de cycle a suivi la même trajectoire : d’environ 13-14 jours au sprint 6 à 7,5 puis 4,75 jours au sprint 8. Le flux est passé d’un engorgement marqué (livraisons en batch closing en fin de sprint) à un flux continu, fluide et sans accumulation.

L’analyse de cause racine

Les métriques pointaient un point de blocage précis : la review. Des tickets y stagnaient, en attente d’une livraison vers l’environnement de dev.

Plutôt que de traiter le symptôme, j’ai animé une analyse de cause racine (diagramme d’Ishikawa) avec l’équipe. Deux causes principales sont ressorties :

• Des pipelines de livraison très longs : chaque déploiement vers l’environnement de dev prenait un temps disproportionné.
• Des tickets non mis à jour : sur des cycles longs, les devs « perdaient le fil » et le tableau ne reflétait plus la réalité.

Le sujet technique (pipelines) a été pris en main par les leads tech lors de leur point hebdomadaire dédié. Résultat : pipelines accélérés, tests plus rapides.

Les actions concrètes

J’ai appliqué les pratiques Kanban, mais outillées par la donnée, pas en les récitant :

• Visualisation du workflow : atelier pour aligner l’équipe sur les étapes réelles et les conditions de passage de l’une à l’autre (quel environnement fait quoi).
• Limitation du WIP : des limites posées sur les colonnes Review et Test, précisément là où ça bouchonnait, pour forcer à terminer avant d’entamer.
• Gestion active de l’en-cours : ajout de l’âge des tickets (aging) pour repérer ceux qui stagnent et agir avant qu’ils ne pourrissent.
• Inspection & adaptation : simplification du workflow (regroupement de colonnes) et mise en place des estimations, pour une vue réaliste de la capacité et des sprints qui ne sont plus surchargés.

Ce que ça change

Au-delà du chiffre, l’équipe est passée d’un mode « on pousse et on espère » à un flux prévisible : on sait ce qui est en cours, ce qui bloque, et quand ça sortira. Pour un responsable, c’est la différence entre piloter à l’instinct et décider sur des faits.

C’est exactement ce que j’apporte sur une mission de delivery : je rends le flux visible, j’attaque les vraies causes, et je redonne de la prévisibilité.