DevOps, Lean, chaîne de valeur : optimiser la production logicielle

La transformation DevOps est un levier stratégique pour les entreprises souhaitant améliorer la performance de leur production logicielle. Trop souvent, les organisations se focalisent sur de l’automatisation ou l’intégration de nouveaux outils. Très peu entament une évolution de manière holistique. En combinant les principes du DevOps, du Lean et de la chaîne de valeur, il est alors possible d’obtenir une vision globale de ses processus et d’optimiser la collaboration entre les équipes.

Cet article propose d’explorer ces trois concepts clés avant d’expliquer comment la chaîne de valeur peut structurer et accélérer la mise en place du DevOps.

1. DevOps, Lean et chaîne de Valeur

a. Qu’est-ce que la méthode DevOps ? Définition

Le DevOps est une approche qui favorise une collaboration étroite entre les équipes de développement et les opérations. Principal objectif : livrer des logiciels plus rapidement et avec une meilleure qualité à moindre coût. Il repose sur un ensemble de pratiques qui favorisent une culture d’amélioration continue et la suppression des silos organisationnels. Cette approche est souvent adoptée par les entreprises en pleine croissance ou souhaitant optimiser leurs performances.

Le DevOps s’appuie sur des pratiques issues d’autres cadres méthodologiques tels que ITIL, Lean et Agile. Parmi elles, on retrouve l’optimisation des processus Lean, la cartographie de la chaîne de valeur et le management visuel. Ces outils permettent d’identifier les inefficacités et de fluidifier la production logicielle.

Il est important de noter que le DevOps ne se limite pas à un simple rôle dans une entreprise, ni à une suite d’outils permettant l’automatisation. Il ne s’agit pas non plus d’une méthode réservée aux startups ou aux applications web, ni d’une démarche visant à contourner ou à éliminer les équipes opérationnelles. C’est avant tout une philosophie qui repose sur la coopération et l’adaptabilité.

Comment fonctionne le DevOps ?

Nous proposons une vision du DevOps qui s’appuie sur un ensemble de quinze pratiques, dont plusieurs sont directement issues du Lean telles que le Lean Process Optimization, Value Stream Mapping et le Visual Management.

Principaux écueils à éviter

La mise en œuvre du DevOps ne se résume pas aux pratiques listées ci-dessous. Néanmoins, certaines d’entre elles peuvent être mises en œuvre afin d’atteindre vos objectifs DevOps.

b. Qu’est-ce que le Lean ?

Le Lean est une méthode de gestion qui vise à améliorer les performances d’une chaîne de production. De ce fait, on cherche à éliminer les gaspillages. Sept types de gaspillages principaux sont identifiés : 

1. La surproduction ;
2. Les stocks et encours inutiles ;
3. Les délais d’attente ;
4. Les transports inutiles ;
5. Les traitements superflus ;
6. Les mouvements inutiles ;
7. Et les défauts.

Ces éléments ralentissent la production et nuisent à la qualité des livrables.

Dans un cadre Lean, l’approche DMAIC (Définir, Mesurer, Analyser, Améliorer (Improve) et Contrôler) est souvent utilisée pour structurer l’optimisation des processus. Elle permet d’identifier et d’éliminer les inefficacités en suivant une méthodologie rigoureuse. Dès la phase Mesurer, la cartographie de la chaîne de valeur est réalisée pour visualiser les flux et détecter les goulets d’étranglement. Par la suite, les améliorations mises en place sont suivies et ajustées pour garantir leur pérennité.

c. Qu’est-ce que la chaîne de valeur ?

La chaîne de valeur en production logicielle représente l’ensemble des étapes nécessaires pour transformer une demande métier en un produit final. Elle est généralement modélisée sous forme de cartographie et comprend quatre éléments essentiels :

1. Les entrants ;
2. Les activités 
3. Les sortants ;
4. Et les stocks.

Cette vision permet d’évaluer le temps et le coût de chaque activité, d’analyser le flux de valeur et de repérer les blocages qui ralentissent le cycle de production.

2. Comment analyser et améliorer sa chaîne de valeur de production logicielle ?

Afin de comprendre l’état de la chaîne de valeur, nous regardons plusieurs indicateurs (liste non exhaustive) :

• Lead Time (LT) : temps écoulé entre une demande issue d’un client et sa réalisation en production.
• Cycle Time (CT) : temps moyen entre le début et la fin du travail sur une demande. Elle se mesure généralement à partir du commencement de la demande (ici, le début du code de la demande). Elle permet de mesurer l’efficacité de l’équipe durant les phases actives.
• Process Time (PT) : il s’agit du CT, en ne prenant en compte que les actions à valeur ajoutée (en retranchant les actions sans valeur ajoutée).
• Takt Time (TT) : durée idéale de traitement d’une demande.
• Débit de sortie (throughput) ou productivité : cette métrique quantifie le nombre de demandes réalisées dans un délai donné (appelé cycle). Elle mesure la productivité de l’équipe.
• Croissance du backlog : augmentation du backlog d’un cycle à l’autre.
• Process cycle Efficiency (PcE) : efficience du processus (= PT / LT).
• Rendement de Premier Passage (RPP) : pour une étape, taux de sorties exemptes d’erreurs du premier coup.
• Time-to-market : temps entre la définition initiale de l’user story (US) et sa mise en service auprès des utilisateurs.

Lead Time VS Cycle Time VS Process Time VS Takt Time : le Takt time varie en fonction de la demande, d’où les pointillés. Il est possible qu’il soit inférieur au Process Time.

Il est à noter que l’ensemble de ces métriques peuvent également être analysées au niveau d’une activité, et non sur l’ensemble de la chaîne.

En observant une chaîne de valeur sur plusieurs cycles représentatifs, on peut identifier des métriques utiles. Prenons l’exemple de la chaîne de valeur ci-dessous, qui représente le Lead Time, Process Time et le Rendement de Premier Passage (RPP) pour chaque étape de la chaîne de production logicielle pour un batch de 32 US.

1). Définir (Define)

La phase de Define va permettre de prendre de la hauteur de vue et définir l’objectif et le périmètre du projet. Afin de réaliser cela, nous allons définir les trois voix :

• Voix du client ;
• Voix des opérations ;
• Voix du business.

Ces trois voix sont résumées dans le tableau ci-dessous :

Les trois voies	Problème
Voix du client Les clients se plaignent de l’attente de nouvelles fonctionnalités, ainsi que des bugs fréquents.	Lenteur de livraison (Efficacité) Qualité de livraison (Qualité)
Voix des opérations Collaborateurs surchargés & démotivés.	Charge inéquitablement répartie Travail sur des tâches à faible valeur ajoutée
Voix du business Coût élevé de la production & CA en baisse.	Profitabilité / durabilité de l’activité

 L’objectif principal est de réduire les temps d’attente de production des US. Le second objectif est l’amélioration de la qualité des livraisons et du suivi opérationnel.

2). Mesurer (Measure)

La phase Mesurer permet d’identifier les données utiles et de les récupérer afin de mesurer l’existant. Elle sert de point de départ afin de réaliser un suivi factuel de l’amélioration du processus.

Sur une période d’un an, 420 nouvelles demandes sont créées et ajoutées au backlog. 220 sont effectivement terminées et mises en service.

Nous observons les données suivantes :

Étape	Lead Time (jours)	Process Time (jours)	RPP
Plan	10	1	75%
Waiting in backlog	20	0	–
Code	15	5	50%
Build	1	0	80%
Test	5	0,5	50%
Deploy	1	0	90%
Release	1	0	100%
TOTAL	52	6,5	13,5%

Nous commençons par observer le Lead Time, le Process Time ainsi que le RPP :

• Lead Time = 52 jours pour 32 US, soit 1,625 jour par US.
• Process Time = 6,5 jours pour 32 US, soit 0,3 jour par US.
• RPP = 13,5 %.

Un RPP de 13,5 % révèle des goulots d’étranglement causés par un fort taux de défauts sur une ou plusieurs étapes. L’analyse du RPP étape par étape permet d’identifier les maillons les plus défaillants et de cibler les actions d’amélioration pour optimiser le rendement global.

Les deux étapes avec le RPP le plus faible (50 %) sont « Code »et « Test ». À partir de ce constat, il est nécessaire d’identifier les causes et les contre-mesures.

Le Process Time nous indique que le temps passé sur du travail à valeur ajoutée sur une demande est de 6,5 jours. Cela nous indique que de manière optimale, 32 demandes pourraient être traitées tous les 6,5 jours (ouvrés ici), soit 1083 demandes par an. Ce chiffre est théorique et ne peut être atteint. Il correspondrait à une efficience maximale.

Afin d’identifier les niveaux de performance atteignables, les calculs de l’efficience du processus, ainsi que des débits d’entrée-sortie permettent d’identifier les performances actuelles et les comparer à l’attendu :

• PcE = Process Time / Lead Time = 12,5 %.
• Croissance du backlog (par an) = 420 – 220 = 200 US supplémentaires dans le backlog.

Nous observons un Process cycle Efficiency (PcE) de 12,5%. Cela n’est pas si mal : en général, un processus non « huilé » a un PcE de moins de 5 %. Cependant, cela peut être amélioré afin d’atteindre au moins les 30 %, ce qui correspondrait à un lead time d’environ 22 jours. Cela permettrait de produire 320 demandes par an. Afin de répondre à l’ensemble de la demande annuelle, il faudrait un PcE de 38,8 % et un Lead Time de 16,8 jours.

Le PcE maximal dépend du temps passé à réaliser des actions nécessaires mais sans valeur ajoutée. Au sens Lean, une action est considérée sans valeur ajoutée si elle n’apporte pas de valeur directement au client final. Par exemple, une réunion n’apporte pas de valeur ajoutée, tandis que coder la fonctionnalité apporte directement de la valeur ajoutée. Cela implique que les réunions agiles (Daily, Sprint Retrospective…) et autres réunions en tout genre (ex. : CAB…) ne font pas partie des tâches à valeur ajoutée, même si elles sont nécessaires. Il s’agit d’actions dites sans valeur ajoutée nécessaire. En prenant en compte ces considérations, le PcE ne peut pas excéder 75 % – 80 % du fait des tâches sans valeur ajoutée nécessaire dans le processus agile.

Le débit de sortie est bien moindre que le débit d’entrée. Si on s’attend à ce que l’ensemble des demandes soient traitées, on peut dire que les performances de l’usine logicielle ne sont pas suffisantes vis-à-vis des objectifs fixés. Cependant, si on s’attend à traiter 40 % des demandes prioritaires, soit environ 168 demandes, alors l’usine logicielle semble bien dimensionnée. Cela va également dépendre des moyennes des métriques Lean de ces 168 demandes. Celles-ci peuvent être plus ou moins élevées que les moyennes pour l’ensemble des 420 demandes.

La croissance du backlog va également faire croître le Lead Time, directement corrélé au temps d’attente dans le backlog. Cela va réduire les performances (PcE) du processus.

Enfin, nous calculons deux métriques Lean importantes nous indiquant “l’écoulement” optimal à atteindre :

• Cycle Time = 220/220 = 1 jour par demande.
• Takt time = 220 jours / 420 demandes = ~0,52 jour par demande.

Le Cycle Time est 2 fois supérieur au Takt Time. Ce dernier indique la durée idéale pour le traitement d’une demande. Aujourd’hui, le traitement d’une demande est donc 2 fois plus long que l’attendu.

3). Analyser (Analyze)

Plusieurs éléments d’analyse viennent compléter les premiers constats chiffrés.

Risque de retard et de perte d’opportunité

En prenant comme hypothèses que les demandes sont affinées, il est possible de préciser la capacité à allouer pour résorber la demande globale entrante.

Exemple : si on considère qu’il existe déjà 100 demandes affinées dans le backlog, et que 200 nouvelles viennent s’ajouter, il faudrait 300*1,3 = 390 jours ouvrés (soit environ 20 mois !) afin de résorber le backlog. Il faut également prendre en compte que celui-ci continue d’être alimenté par des demandes entrantes. De plus, une partie des demandes seront traitées en fonction de leur priorité. D’autres seront oubliées puis supprimées. Cet exercice peut également être réalisé sur les demandes à forte valeur : si elles représentent 20 % du backlog, en reprenant l’exemple précédent, il faudrait 79 jours ouvrés afin de les résorber.

Généralement, lorsqu’un retard conséquent est constaté, les entreprises font appel à des collaborateurs externes ou internes supplémentaires. Cependant, cela ne permet pas de réduire la charge de manière linéaire. De plus, le coût d’une telle pratique est élevé. Des travaux d’amélioration de l’efficience du processus permettent de réduire le taux de demandes dans le backlog avec un coût restreint et maîtrisé.

L’impact peut être important, notamment financièrement, si des demandes à forte valeur financière ne sont pas mises en service dans les temps.

La croissance du backlog de 200 demandes par an est énorme, car il est équivalent à la production logicielle annuelle. Il s’agit d’un effet boule de neige menaçant la viabilité du backlog et pouvant freiner la stratégie de croissance de l’entreprise.

L’efficience du processus peut être améliorée

L’augmentation du nombre d’US dans le backlog augmente mécaniquement le temps d’attente dans le backlog, ce qui rallonge les délais, donc le Lead Time. Cela impacte l’efficience du processus (PcE). 

Le Process Time est inférieur au Takt Time (0,3 jour contre 0,52 jour). Il est donc possible de répondre à la demande en réduisant fortement le temps passé sur les tâches sans valeur ajoutée.

Le Rendement de Premier Passage de 13,5 % indique que le nombre de défauts constatés est important. En traitant en priorité les étapes où le taux de défaut est élevé, il est possible d’améliorer le rendement global du processus.

4). Améliorer (Improve)

Dans cette partie, nous partageons quelques pistes afin d’améliorer la production logicielle.

Mettre en place de l’automatisation sur le pipeline DevOps

L’automatisation du pipeline DevOps réduit les erreurs humaines, accélère le cycle de développement et améliore la qualité des livraisons. La mise en place de CI/CD (Continuous Integration / Continuous Deployment) avec des tests automatisés permet de livrer plus rapidement et avec plus de fiabilité. L’automatisation des déploiements, des tests et de la gestion des infrastructures (Infrastructure as Code) renforce la résilience et l’efficacité globale du processus.

5). Contrôler (Control)

Une fois les actions d’améliorations mises en place, il est nécessaire d’avoir des systèmes de maintien de la performance dans le temps.

En appliquant cette démarche DMAIC, l’entreprise pourra réduire l’accumulation de backlog, améliorer le temps entre l’émission d’une demande et sa mise en service auprès des clients (time-to-market), et fluidifier la livraison des user stories tout en optimisant le processus. 

3. Pourquoi mettre en place une chaîne de valeur DevOps ?

a. Améliorer l’efficacité d’une production logicielle

L’amélioration de la productivité est un enjeu majeur pour les entreprises cherchant à optimiser leur rendement. Une analyse de la chaîne de valeur peut révéler des inefficacités notables, telles que des goulots d’étranglement et le taux de défauts.

Grâce à une approche Lean, ces problèmes peuvent être progressivement résolus. En rationalisant les processus puis en automatisant certaines étapes, les équipes gagnent en efficacité et peuvent se concentrer sur des tâches à plus forte valeur ajoutée. La mise en place d’une chaîne de valeur permet ainsi d’orienter les efforts vers des améliorations ayant un impact significatif sur la production logicielle dans son ensemble.

b. Améliorer la collaboration et la transparence

Prenons le cas d’une entreprise en pleine croissance qui rencontre plusieurs difficultés organisationnelles et techniques. Le manque de collaboration entre les équipes de développement et d’exploitation, combiné à l’obsolescence d’un logiciel vendu en mode on-premise, freine son évolution. La coexistence d’un double environnement (avec une solution SaaS en cours de développement) entraîne des coûts élevés et des retards dans la livraison des nouvelles fonctionnalités. Le top management, en manque de visibilité sur l’impact global, peine à prendre des décisions éclairées.

Face à cette situation, la cartographie de la chaîne de valeur joue un rôle clé. Elle permet de visualiser les impacts opérationnels des difficultés rencontrées, de donner aux différentes parties prenantes une vision plus claire des problématiques de l’usine logicielle et de restructurer l’organisation pour qu’elle soit orientée vers l’amélioration des performances. En mettant en évidence les interactions entre les différents services, cet outil de management visuel facilite la coopération et la prise de décision.

c. Maîtriser les performances et les coûts (efficience de la chaîne)

Le top management a besoin d’une vision claire des performances et des coûts de l’usine logicielle pour justifier les investissements, optimiser le retour sur investissement (ROI) et orienter les choix stratégiques. Une cartographie détaillée de la chaîne de valeur permet d’identifier les flux de production, d’évaluer le coût de production, et sa rentabilité à moyen et long terme.

En s’appuyant sur des indicateurs clés de performance (KPI) financiers et stratégiques, il devient possible d’aligner les décisions opérationnelles avec les objectifs économiques de l’entreprise :

• Coût moyen d’une demande = (Coûts engagés / Nombre de demandes finalisées)
  → Permet d’évaluer le coût des développements, de projeter les besoins financiers pour répondre à la demande.
• Coût total de possession (TCO – Total Cost of Ownership) = (Coût de cadrage + Coût de développement + Coût de maintenance + Coût des incidents en production)
  → Aide notamment à arbitrer entre développement technique VS fonctionnel, développement interne, externalisation, adoption de solutions SaaS, etc. en intégrant la vision long terme.
• Coût du backlog = (Volume de demandes non traitées x Valeur estimée par demande)
  → Met en évidence le coût des développements attendus. Peut être utilisé notamment afin de justifier des investissements complémentaires si ceux-ci sont moindres au regard de la perte d’opportunité financière liée aux retards de production.
• Ratio dépenses Build vs. dépenses Run
  → Permet de piloter l’équilibre entre Build et Run : une part excessive de maintenance peut indiquer une dette technique trop élevée impactant la compétitivité.
• Impact des incidents en production sur le chiffre d’affaires = (Coût des interruptions + Pertes de revenus clients + Impact sur la satisfaction client)
  → Justifie l’investissement dans la qualité logicielle, l’observabilité et la fiabilité des systèmes.

Grâce à ces KPIs financiers et opérationnels, les équipes peuvent relier leurs décisions techniques aux enjeux stratégiques de l’entreprise. Cette approche permet d’anticiper les efforts financiers nécessaires, d’aligner les budgets avec les capacités de production et d’optimiser l’allocation des ressources en fonction des objectifs de croissance et de rentabilité.

En traduisant les indicateurs techniques en données financières exploitables, le DevOps devient un levier de compétitivité où la performance logicielle affecte directement la performance économique de l’entreprise.

Conclusion

L’intégration du DevOps via le Lean et la cartographie de la chaîne de valeur offre une approche holistique pour transformer une production logicielle. Elle permet d’améliorer la collaboration et la transparence, d’augmenter la productivité en réduisant les gaspillages et de maîtriser les coûts tout en améliorant les performances.

Le DevOps est une transformation globale qui concerne toute l’entreprise, touchant à la fois l’organisation, les processus et la technologie. Pour initier cette transformation efficacement, il est essentiel de réaliser un audit de maturité DevOps. Cet audit permet d’évaluer votre niveau actuel, de définir une cible alignée sur votre stratégie et votre culture d’entreprise, et d’établir une feuille de route adaptée pour atteindre vos objectifs.