TL;DR. Quand la cadence de livraison bouge, ton système IT te dit quelque chose sur l'équilibre entre capacité et demande. La stabilité est le signal de l'équilibre. La vitesse, non.
Proposition
Une variation de la fréquence de livraison logicielle indique un déséquilibre entre la capacité de production IT et la demande.
Rappel : la loi de Little
Formulée par John D. C. Little en 1961, appliquée depuis aux centres d'appels, aux usines, aux hôpitaux et à la livraison logicielle, la loi énonce que dans tout système stable :
Temps de cycle (W) = Travail en cours (L) / Débit (λ)
Taux d'arrivée (λ) : le rythme auquel la nouvelle demande entre dans le système. En logiciel, c'est le flux entrant de requêtes, features, incidents, change requests.
Travail en cours (L) : le stock d'items actuellement dans le système, ni arrivés ni livrés.
Temps de cycle (W) : le temps moyen qu'un item passe dans le système, de l'arrivée à la livraison. C'est ce que la fréquence de livraison mesure à la sortie.
Dans un système stable, taux d'arrivée et débit sont égaux, d'où le symbole partagé λ.
L'équation est mécanique. Deux conséquences suivent.
Première conséquence. Si taux d'arrivée et débit restent égaux, le WIP se stabilise et le temps de cycle se stabilise. La fréquence de livraison est stable.
Seconde conséquence. Si le taux d'arrivée dépasse le débit, le WIP s'accumule et le temps de cycle croît. La fréquence de livraison chute. Si le débit dépasse le taux d'arrivée, le WIP se vide et le système génère de la capacité oisive. La fréquence de livraison monte, souvent sur du travail artificiel.
Ce n'est pas un framework. C'est une identité. Ce qui explique pourquoi les trois scénarios ci-dessous ne sont pas des possibilités parmi d'autres. Ce sont les trois seuls régimes que le système peut occuper.
Démonstration
Dans une organisation Agile en livraison continue, la demande de logiciels et services s'écoule en continu, et le périmètre s'ajuste en continu en retour. Dans ce flux, trois scénarios façonnent la cadence de livraison.
1. La demande excède la capacité
Le cycle de production ralentit. La qualité décroche sous la pression, le cadrage grignote le temps, la priorisation tourne en rond, le moral s'effrite. La productivité suit. Une injection brutale de capacité ne règle rien. L'onboarding crée de l'inertie, perturbe la dynamique d'équipe, retarde le bénéfice. La fréquence de livraison tend à la baisse.
C'est le territoire que Brooks a cartographié en 1975 : ajouter des personnes à un projet logiciel en retard le retarde davantage.¹
2. La capacité excède la demande
Les ingénieurs ont besoin de construire quelque chose. Le temps libre devient dérive fonctionnelle : du travail superflu ajouté pour rester occupé. Les solutions sur-ingénieriées génèrent du retravail et des releases correctives. Le temps de cycle se raccourcit, l'output se multiplie, la fréquence de livraison tend à la hausse. Les chiffres sont bons ; la substance est du bruit. C'est la loi de Parkinson en code : le travail s'étend pour remplir le temps disponible.²
Cas d'espèce : les assistants de code IA, 2024 à 2026. GitHub Copilot a atteint vingt millions d'utilisateurs à mi-2025. Une estimation : 41 % du nouveau code est généré ou assisté par IA, montant à 46 % chez les utilisateurs de Copilot. Le débit de pull requests par auteur est en hausse de 20 % sur un an. La fréquence de livraison a rarement été aussi élevée.³
Maintenant l'autre côté du registre. La taille médiane des pull requests a augmenté d'un tiers sur 2025. Les incidents par pull request ont monté de 23 %. Le Stack Overflow Developer Survey 2025 désigne le code généré par IA qui a l'air juste mais qui est subtilement faux comme la première source de frustration pour les développeurs. Près de la moitié disent que déboguer du code IA prend plus de temps que l'écrire eux-mêmes.⁴
L'effet atteint les utilisateurs. Les organisations font tourner en moyenne 130 applications SaaS, en hausse de 18 % sur un an. 96 % des employés se disent insatisfaits de leurs outils de travail. Les recherches sur l'usage SaaS montrent systématiquement que 80 % de la valeur d'un produit vient de 20 % de ses fonctionnalités, mais les inventaires de features continuent de grossir.⁵ Les utilisateurs surpondèrent la capacité avant l'achat et l'utilisabilité après. La capacité vend. L'utilisabilité retient.⁶
La capacité dépasse la demande à l'échelle industrielle. La cadence monte. La substance est du bruit.
3. La capacité correspond à la demande
Les équipes livrent des features pertinentes, dans les temps, à un rythme soutenable. La qualité tient. Le temps de cycle se stabilise. La fréquence de livraison aussi. C'est l'état vers lequel tous les autres scénarios pointent.
Cas d'espèce : un programme au sein d'une infrastructure mondiale de messagerie financière. Sur deux trimestres, la cadence de livraison a chuté de 50 %. Le backlog était saturé, l'équipe épuisée, la qualité commençait à s'éroder. La réponse instinctive : ajouter de la capacité. La réponse qui fonctionne : l'inverse. On a ouvert une conversation de cadrage avec le produit et le sponsor, arbitrée feature par feature : qu'est-ce qui est obligatoire ce trimestre, qu'est-ce qui ne l'est pas. 60 % du backlog a été reporté à une release ultérieure. Une initiative supplémentaire a été conservée, conditionnée à la stabilisation des taux d'incidents. Le périmètre résiduel correspondait au débit réaliste. Trois sprints plus tard, la cadence avait récupéré et s'était stabilisée. Le débit est revenu sans un seul recrutement supplémentaire. L'équilibre était à une conversation de cadrage, pas à un cycle de recrutement.
Le principe tient bien au-delà de ce cas. Donald Reinertsen l'a formalisé en 2009 à travers 175 principes du flux de développement produit : la cadence est un mécanisme de régulation, pas une cible.⁷ Le Heijunka de Toyota, le lissage de production pour coller au temps takt, est la même idée appliquée aux voitures depuis les années 1950. Le terrain le sait. Les organisations l'oublient.
Lire le signal
Une cadence qui monte suggère une surcapacité.
Une cadence qui baisse suggère une sous-capacité.
Une cadence stable signale l'équilibre : le flux de production correspond au flux de demande.
Scholia
Courir après une fréquence de livraison plus élevée est un objectif, pas une stratégie. La bonne cible est la stabilité dans le temps, avec la capacité ou la demande ajustées au contexte.
La stabilité n'est pas un nombre figé. La fréquence de livraison doit rester un indicateur flottant dont les mouvements pilotent les décisions structurelles.
Deux distinctions comptent.
Écart long terme à la moyenne. Signal de sur ou sous-capacité structurelle. Action structurelle requise.
Écart temporaire. Déséquilibre attendu ou périodique. Pas d'action structurelle requise.
Un pic de releases soudain pour absorber une vague de demande, produit par une marge de sécurité préexistante, est désirable. Un creux saisonnier pendant les congés d'hiver, porté par une capacité réduite, est attendu.
Ce n'est pas un argument contre la haute fréquence de déploiement. Les recherches sur les organisations d'ingénierie haute performance montrent que les équipes d'élite déploient plusieurs fois par jour.⁸ L'argument porte sur le ciblage. La loi de Goodhart s'applique : quand une mesure devient une cible, elle cesse d'être une bonne mesure. La fréquence de livraison a de la valeur comme diagnostic. Elle est dangereuse comme objectif.
Lire le signal. Agir sur le signal, pas sur le nombre. C'est le premier mouvement de la méthode : Read. Reduce. Deliver.
Notes
¹ Fred Brooks, The Mythical Man-Month (1975).
² C. Northcote Parkinson, « Parkinson's Law » (The Economist, 1955).
³ Adoption de GitHub Copilot et productivité du code assisté par IA. Voir AI Coding Assistant Statistics 2026, GitHub Copilot Statistics 2026, AI Is Writing 46% of All Code.
⁴ Volume de code, taille des PR, taux d'incidents et fatigue de debug sous développement assisté par IA. Voir AI Copilot Code Quality 2025 (GitClear), The AI Productivity Trap (CIO), AI vs Human Code Generation Report (CodeRabbit).
⁵ Inventaire SaaS, insatisfaction des employés vis-à-vis des outils, et règle des 80/20 sur la valeur des features. Voir SaaS Fatigue Syndrome 2025 (Lemon Learning), App Fatigue (Strety), Feature Fatigue (Userpilot).
⁶ Thompson, Hamilton, Rust, « Feature Fatigue: When Product Capabilities Become Too Much of a Good Thing » (Journal of Marketing Research, 2005). Voir aussi AI and Feature Bloat (Medium).
⁷ Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development (2009). John D. C. Little, « A Proof for the Queuing Formula L = λW » (Operations Research, 1961).
⁸ Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: The Science of Lean Software and High Performing Technology Organizations (2018). Voir aussi le DORA Research Program.