Value Stream et Flow

Où en êtes-vous dans le parcours ?

Vous êtes dans la Partie 2 — Accélérer le flux, chapitre 2.1.

Prérequis : Three Ways et CALMS — Le First Way (Flow) est appliqué ici

Prochaine étape : Boucles de rétroaction (chapitre 2.2)

Imaginez une équipe de développement qui travaille sur une nouvelle fonctionnalité. Le développeur termine son code en 2 jours. Mais entre ce moment et la mise en production, il se passe 6 semaines. Où est passé le temps ? Le code attend une revue (3 jours), puis un environnement de test (1 semaine), puis une validation métier (2 semaines), puis un créneau de déploiement (2 semaines). Le travail réel représente moins de 10% du temps total. C’est exactement le problème que le Value Stream et le Flow permettent de résoudre.

Comment ce concpet article s’inscrit dans le DevOps

Le concept de Flow est le premier des Three Ways de Gene Kim, qui structurent la philosophie DevOps :

1. First Way — Flow : accélérer le flux de valeur de l’idée à la production ← c’est cet article
2. Second Way — Feedback : raccourcir les boucles de retour d’information
3. Third Way — Learning : créer une culture d’apprentissage continu

Le Value Stream Mapping (VSM) est un outil issu du Lean Manufacturing (Toyota Production System) que le DevOps a adapté au développement logiciel. Comprendre le flow est essentiel car toutes les autres pratiques DevOps (CI/CD, automatisation, monitoring) visent à l’améliorer.

Qu’est-ce que le Value Stream ?

Le Value Stream (flux de valeur en français) représente l’ensemble des étapes nécessaires pour transformer une idée en valeur livrée au client. C’est comme une chaîne de production dans une usine, mais appliquée au développement logiciel.

Analogie simple : Pensez à la préparation d’un repas au restaurant. Le flux de valeur commence quand le client passe commande et se termine quand le plat est servi. Entre les deux : prise de commande, préparation en cuisine, cuisson, dressage, service. Chaque étape prend du temps, et le client ne perçoit de la valeur qu’au moment où il reçoit son plat.

En développement logiciel, le flux de valeur inclut généralement :

Étape	Ce qui se passe	Valeur pour le client
Idéation	Une idée ou un besoin est identifié	Aucune (l’idée n’existe que dans les esprits)
Spécification	Le besoin est formalisé	Aucune (du papier)
Développement	Le code est écrit	Aucune (le code n’est pas déployé)
Tests	Le code est validé	Aucune (toujours pas en production)
Déploiement	Le code arrive en production	Enfin de la valeur !
Exploitation	Le code est utilisé	Valeur continue

Point clé

Le client ne perçoit aucune valeur tant que la fonctionnalité n’est pas en production. Tout le temps passé avant est du travail en cours (Work In Progress), pas de la valeur livrée.

Pourquoi cartographier son flux de valeur ?

Sans une vision claire de votre flux, vous ne pouvez pas savoir où vous perdez du temps. La cartographie du flux de valeur révèle :

• Le temps de travail réel : combien de temps quelqu’un travaille activement sur la tâche
• Le temps d’attente : combien de temps la tâche attend (revue, validation, environnement…)
• Les transferts : combien de fois la tâche change de mains

Dans la plupart des organisations, le temps d’attente représente 80 à 90% du temps total. C’est là que se trouve le gisement d’amélioration.

Le Flow : faire circuler la valeur

Le Flow (flux en français) mesure la vitesse à laquelle la valeur traverse votre système. Un bon flow signifie que les idées se transforment rapidement en fonctionnalités utilisables.

Analogie : Imaginez une autoroute. Le flow représente le nombre de voitures qui arrivent à destination par heure. Même si chaque voiture roule vite, si l’autoroute est embouteillée, le flow global est faible.

Les métriques du flow

Pour mesurer le flow, on utilise principalement deux métriques :

Le Cycle Time (temps de cycle) mesure la durée entre le début du travail sur une tâche et sa livraison en production. Plus il est court, plus vous livrez vite.

Cycle Time	Interprétation
< 1 jour	Excellent : livraison quasi continue
1-7 jours	Bon : livraison fréquente
1-4 semaines	Moyen : cycles de sprint classiques
> 1 mois	Problématique : délais significatifs

Le Throughput (débit) mesure le nombre de tâches livrées par unité de temps (par jour, par semaine). Il indique la capacité de production de votre équipe.

Conseil pratique

Commencez par mesurer le Cycle Time de vos 10 dernières livraisons. La moyenne vous donnera une base de référence pour mesurer vos améliorations.

Les goulots d’étranglement

Un goulot d’étranglement (bottleneck en anglais) est une étape du flux qui limite le débit global du système. C’est le point le plus lent, celui qui fait attendre tout le reste.

Analogie : Dans un sablier, le goulot est l’étroit passage entre les deux parties. Peu importe la quantité de sable au-dessus, il ne peut s’écouler que grain par grain à travers le goulot. Agrandir le haut du sablier ne sert à rien : seul l’élargissement du goulot accélère l’écoulement.

Identifier vos goulots

Les goulots courants dans le développement logiciel :

Symptôme	Goulot probable	Impact
Files d’attente longues pour les revues de code	Pas assez de reviewers disponibles	Les développeurs attendent, changent de contexte
Environnements de test indisponibles	Infrastructure partagée sous-dimensionnée	Les tests sont retardés ou bâclés
Approbations manuelles qui traînent	Processus de validation bureaucratique	Des semaines perdues en attente de signatures
Déploiements risqués et rares	Peur de casser la production	Gros lots, gros risques, gros délais
Une personne indispensable	Connaissances concentrées sur un expert	Tout s’arrête quand cette personne est absente

La théorie des contraintes

Eliyahu Goldratt, dans son livre The Goal, a formalisé une idée contre-intuitive mais fondamentale :

Optimiser une étape qui n’est pas le goulot n’améliore pas le débit global du système.

Cela signifie que si votre goulot est la revue de code, améliorer la vitesse de vos déploiements ne changera rien. Les tâches continueront de s’empiler devant la revue de code.

En pratique

Concentrez 100% de vos efforts d’amélioration sur le goulot actuel. Une fois qu’il est résorbé, un nouveau goulot apparaîtra ailleurs. C’est normal : l’amélioration continue consiste à éliminer les goulots un par un.

La taille des lots (Batch Size)

La taille des lots désigne la quantité de travail regroupée avant d’être livrée. Dans le développement logiciel, c’est le nombre de fonctionnalités ou de modifications incluses dans une release.

Analogie : Imaginez que vous fassiez les courses une fois par mois avec un énorme caddie. Si vous oubliez quelque chose ou achetez un produit périmé, vous ne le découvrez qu’au moment de l’utiliser, parfois des semaines plus tard. À l’inverse, si vous faites de petites courses tous les 2-3 jours, vous détectez rapidement les problèmes et pouvez corriger le tir.

Pourquoi les petits lots sont-ils meilleurs ?

Aspect	Gros lots (release trimestrielle)	Petits lots (release quotidienne)
Risque	Élevé : beaucoup de changements = beaucoup de bugs potentiels	Faible : peu de changements = problèmes faciles à isoler
Feedback	Lent : 3 mois avant de savoir si ça plaît aux utilisateurs	Rapide : retour utilisateur en quelques heures
Correction	Coûteuse : le développeur a oublié le contexte	Peu coûteuse : le contexte est frais
Coordination	Complexe : nombreux conflits, merges difficiles	Simple : modifications isolées
Stress	Intense : la release est un événement critique	Minimal : la release est une non-événement

Objectif à viser

Les organisations les plus performantes déploient plusieurs fois par jour. Chaque déploiement contient une ou quelques modifications seulement. Si quelque chose casse, on sait immédiatement quoi et on peut rollback en secondes.

Le paradoxe du risque

Intuitivement, on pourrait penser que faire moins de releases réduit le risque (« moins on touche, moins on casse »). C’est l’inverse qui est vrai :

• Gros lots = gros risques : des centaines de changements, des dizaines de développeurs impliqués, des semaines de travail en jeu. Si ça casse, c’est la panique.
• Petits lots = petits risques : quelques lignes modifiées, un développeur concerné, quelques heures de travail. Si ça casse, on revient en arrière et on corrige tranquillement.

Work In Progress (WIP)

Le Work In Progress (travail en cours) désigne le nombre de tâches commencées mais pas encore terminées. C’est une métrique souvent négligée mais cruciale pour le flow.

Analogie : Imaginez un jongleur. Avec 3 balles, il peut maintenir un rythme régulier. Avec 10 balles, il en fait tomber constamment et passe son temps à les ramasser au lieu de jongler. Le WIP, c’est le nombre de balles en l’air.

Les effets d’un WIP élevé

WIP élevé cause…	Parce que…
Changements de contexte	Vous passez d’une tâche à l’autre sans cesse, perdant du temps à chaque switch
Rallongement du Cycle Time	Chaque tâche attend son tour plus longtemps
Baisse de qualité	L’attention est dispersée, les erreurs se multiplient
Stress et surcharge	La liste des choses « en cours » est écrasante
Masquage des problèmes	Les goulots sont invisibles car tout est « en cours »

Limiter le WIP pour révéler les problèmes

Limiter le WIP signifie fixer un nombre maximum de tâches pouvant être en cours simultanément à chaque étape du flux.

Exemple concret : Une équipe limite le nombre de tâches « En revue de code » à 3. Si 3 tâches sont déjà en revue, les développeurs qui terminent leur code ne peuvent pas en ajouter une 4ᵉ. Ils doivent d’abord aider à vider la file de revue.

Cet effet est bénéfique :

• Force à finir avant de commencer : plus d’accumulation de travail inachevé
• Révèle les goulots : si une colonne est toujours pleine, c’est le goulot
• Encourage la collaboration : on aide les autres pour débloquer le flux

Attention

Limiter le WIP est inconfortable au début. L’équipe aura l’impression de « ne rien faire » quand elle attend. C’est normal : elle découvre le temps d’attente qui était invisible auparavant.

Scénario concret : une équipe qui améliore son flow

Situation initiale : L’équipe Produit A déploie une fois par mois. Le Cycle Time moyen est de 6 semaines. Les développeurs sont frustrés car leurs fonctionnalités mettent « une éternité » à arriver en production.

Étape 1 — Cartographier le flux : L’équipe dessine son flux de valeur et mesure les temps à chaque étape :

• Développement : 3 jours (travail)
• Attente revue : 5 jours (attente)
• Revue : 1 jour (travail)
• Attente test : 7 jours (attente)
• Test : 2 jours (travail)
• Attente déploiement : 18 jours (attente)
• Déploiement : 1 jour (travail)

Constat : 8 jours de travail, 30 jours d’attente. Le goulot est l’attente du créneau de déploiement mensuel.

Étape 2 — Attaquer le goulot : L’équipe automatise ses déploiements et passe à des releases hebdomadaires. L’attente déploiement passe de 18 à 4 jours en moyenne.

Étape 3 — Nouveau goulot révélé : Maintenant, c’est l’attente test qui devient le goulot (7 jours). L’équipe investit dans l’automatisation des tests et la parallélisation des environnements.

Résultat après 6 mois :

• Déploiements quotidiens
• Cycle Time moyen : 5 jours
• L’équipe livre 10x plus de fonctionnalités par trimestre

Pièges courants

Erreurs à éviter

Optimiser partout sauf au goulot : Des efforts dispersés qui n’améliorent pas le débit global. Identifiez d’abord votre contrainte principale.

Confondre activité et valeur : Être occupé ne signifie pas livrer de la valeur. Un développeur qui code 8h/jour mais dont le code attend 3 semaines en revue ne livre presque rien.

Ignorer le temps d’attente : C’est souvent 80-90% du Cycle Time. Ne mesurez pas que le temps de travail.

Augmenter les lots « pour réduire le risque » : C’est l’inverse qui se produit. Plus le lot est gros, plus le risque est élevé.

Ajouter du WIP pour « aller plus vite » : Démarrer plus de tâches ne les termine pas plus vite. Au contraire, ça ralentit tout.

À retenir

1. Le Value Stream est le chemin complet de l’idée à la production. Seule la production génère de la valeur pour le client.

2. Le temps d’attente domine : dans la plupart des organisations, 80-90% du Cycle Time est de l’attente, pas du travail.

3. Un seul goulot limite tout : identifiez-le et concentrez vos efforts dessus. Améliorer ailleurs ne sert à rien.

4. Petits lots = moins de risques : contrairement à l’intuition, les releases fréquentes de petites modifications sont plus sûres que les grosses releases rares.

5. Limiter le WIP révèle les problèmes : moins de tâches en cours = meilleur focus, plus de visibilité sur les goulots.

6. Mesurez pour progresser : Cycle Time et Throughput sont vos indicateurs clés. Ce que vous ne mesurez pas, vous ne pouvez pas l’améliorer.

Checklist

• Value stream cartographié avec temps de travail ET temps d’attente
• Goulot principal identifié (étape avec la plus longue file d’attente)
• Limite de WIP définie pour chaque étape du flux
• Taille de lot cible définie (viser des releases quotidiennes ou hebdomadaires)
• Métriques de flow en place (Cycle Time, Throughput)
• Plan d’action pour réduire le goulot principal

Pour aller plus loin

Approfondir le Flow

Métriques DORA Mesurer le flow avec les quatre indicateurs scientifiquement validés : Deployment Frequency, Lead Time, MTTR et Change Failure Rate.

Principes CI/CD Automatiser le flux de valeur avec l'intégration continue et le déploiement continu.

Revenir aux fondations

Three Ways et CALMS Comprendre les frameworks qui structurent la philosophie DevOps, dont le First Way (Flow).

Boucle de rétroaction Le Second Way : raccourcir les boucles de feedback pour détecter les problèmes plus tôt.

Parcours complet

Consultez le parcours Fondamentaux DevOps pour suivre la formation complète en 8 modules.

×

📖 Voir la documentation →