Pourquoi une équipe technique saturée livre plus lentement.
La théorie des files d'attente explique pourquoi occuper chaque développeur allonge les délais, et comment limiter le travail en cours accélère les livraisons.
Publié le · 7 min de lecture
Quand une équipe logicielle est en retard, le réflexe est de s'assurer que tout le monde est occupé. Remplir chaque sprint, lancer le projet suivant avant la fin du précédent, garder la liste de tâches de chaque développeur bien pleine. Cela semble efficace. C'est aussi l'un des moyens les plus sûrs de ralentir les livraisons, et la raison n'est ni la motivation ni la compétence. Ce sont des mathématiques que l'industrie et les télécoms ont apprises il y a des décennies.
Le travail attend dans des files
Une demande qui arrive dans une équipe est rarement traitée tout de suite. Elle attend qu'une personne se libère, puis attend encore une revue, un environnement de test, une décision ou un créneau de mise en production. Dans la plupart des équipes, le temps qu'un travail passe à attendre est bien plus long que le temps que quiconque passe à le faire.
La théorie des files d'attente décrit le comportement de ces attentes. Son résultat central s'énonce simplement : quand une ressource approche de son occupation maximale, l'attente devant elle ne croît pas régulièrement. Elle explose.
| Taux d'occupation de l'équipe | Attente |
|---|---|
| 5 % | 0 × |
| 10 % | 0 × |
| 15 % | 0 × |
| 20 % | 0 × |
| 25 % | 0 × |
| 30 % | 0 × |
| 35 % | 1 × |
| 40 % | 1 × |
| 45 % | 1 × |
| 50 % | 1 × |
| 55 % | 1 × |
| 60 % | 1 × |
| 65 % | 2 × |
| 70 % | 2 × |
| 75 % | 3 × |
| 80 % | 4 × |
| 85 % | 6 × |
| 90 % | 9 × |
| 95 % | 19 × |
Dans le modèle le plus simple, une équipe occupée à 50 % fait attendre le travail, en moyenne, à peu près aussi longtemps que le travail lui-même dure. À 80 %, l'attente représente quatre fois le travail. À 90 %, neuf fois. À 95 %, dix-neuf fois. Les derniers points « d'efficacité » se paient en semaines de retard.
C'est pourquoi une équipe qui paraît pleinement productive peut sembler lente à tout son entourage. Chaque personne est occupée, et chaque travail passe l'essentiel de son temps à l'arrêt.
Un travail irrégulier aggrave les choses
La courbe ci-dessus suppose un niveau d'aléa modéré. Le travail logiciel est souvent plus irrégulier : certaines tâches prennent une heure et d'autres deux semaines, et des demandes urgentes arrivent sans prévenir. La formule de Kingman, une approximation classique de la théorie des files d'attente, montre que l'attente augmente avec cette variabilité autant qu'avec la charge.
À la même occupation de 85 %, une équipe dont le travail est régulier et de taille homogène attend environ deux fois moins que le cas de référence. Une équipe submergée d'urgences et de tâches très inégales attend environ deux fois plus. Les deux leviers se multiplient : une forte charge combinée à une forte variabilité, c'est là que les livraisons se bloquent.
Moins de travail en cours, des livraisons plus rapides
La loi de Little, un résultat valable pour presque tout système stable, relie trois grandeurs : le délai moyen est égal au travail en cours divisé par le débit. Si une équipe termine dix éléments par semaine et en a quarante ouverts, chaque élément met en moyenne quatre semaines du début à la fin.
La conséquence utile est qu'une équipe peut raccourcir ses délais sans travailler plus vite. Il suffit de lancer moins de travail à la fois. Le débit reste identique, mais chaque élément passe moins de temps à attendre derrière les autres, et les retours sur ce travail arrivent plus tôt.
Moins de travail en cours apporte aussi des bénéfices qui n'apparaissent pas dans la formule. Les personnes changent moins souvent de contexte, les problèmes apparaissent pendant que le travail est encore frais, et les fonctionnalités terminées commencent à produire de la valeur plus tôt.
Ce que cela change pour la planification
Rien de tout cela ne plaide pour des équipes inoccupées. Cela plaide pour une planification qui tient compte de la courbe.
- Planifier à 70 à 80 % de la capacité. Le temps restant absorbe les correctifs urgents, les revues et l'imprévu sans bloquer tout le reste. Une équipe planifiée à 100 % est en retard dès le premier jour.
- Limiter le travail en cours. Fixez un plafond au nombre d'éléments en cours, par équipe ou par étape, et terminez avant de commencer autre chose. Un tableau avec moins de cartes en cours avance généralement plus vite.
- Réduire la variabilité quand c'est possible. Découpez les gros éléments en petits éléments de taille comparable. Faites passer les demandes urgentes par un canal dédié et limité plutôt que de les laisser tout interrompre.
- Observer les files, pas les personnes. Mesurez combien de temps le travail attend une revue, un test ou une mise en production. L'attente la plus longue est en général l'endroit où gagner du temps coûte le moins, et l'automatisation, comme l'intégration continue et le déploiement en un clic, supprime plusieurs files d'un coup.
Une remarque sur les modèles
Ces chiffres proviennent de modèles classiques reposant sur des hypothèses simplificatrices, pas de mesures sur une équipe donnée. Les équipes réelles sont plus désordonnées. La forme, elle, est robuste : l'attente croît fortement avec la charge, croît avec la variabilité, et baisse quand il y a moins de travail en cours. Les équipes qui mesurent leurs propres délais retrouvent presque toujours ce schéma.
Par où commencer
Mesurez deux chiffres pendant un mois : combien d'éléments votre équipe termine par semaine, et combien sont en cours un jour ordinaire. Divisez le second par le premier et comparez le résultat avec le temps réel qu'il faut pour que le travail arrive aux utilisateurs. Si les chiffres vous surprennent, nous pouvons vous aider à trouver où le travail attend. Nos services d'ingénierie logicielle incluent la mise en place des chaînes de livraison qui suppriment ces files.