Piège 7 - Le gaspillage

Le vol d’une heure qui en prend cinq

Vous réservez un vol d’une heure. Parfait : un aller-retour rapide.

Puis la réalité se déroule. Un train jusqu’à l’aéroport. Une file au dépôt des bagages. Une autre à la sécurité. Une marche jusqu’à la porte d’embarquement, qui a changé. L’embarquement par zones. Vingt minutes sur le tarmac. Et, à l’arrivée, le tapis à bagages, la file des taxis, les embouteillages.

De porte à porte, cinq heures. Le vol lui-même, la seule partie que vous avez réellement payée, en a pris une.

Personne dans cette histoire n’a mal fait son travail. Le pilote a bien piloté. Les agents de sûreté ont contrôlé avec soin. Chaque étape avait du sens en elle-même. Le voyage a été lent à cause de tout ce qui se trouvait entre les étapes.

La plupart des programmes voyagent exactement ainsi. Le vrai travail, écrire du code, tester, décider, c’est le vol. Tout le reste, c’est l’aéroport. Et dans beaucoup de programmes que j’ai vus, l’aéroport prend quatre heures sur cinq.

Tout le monde est occupé, rien ne bouge

Voici le paradoxe au cœur de ce piège. Dans un programme qui gaspille, personne n’est inactif. Les agendas sont pleins. Les gens travaillent tard. Demandez à n’importe qui comment ça va, et la réponse sera : « Débordé. »

Et pourtant, un petit changement met toujours six semaines à atteindre la production.

La raison est que nous regardons les personnes, pas le travail. Les personnes sont occupées, alors nous supposons que le travail avance. Mais un élément de travail passe l’essentiel de sa vie immobile : dans une file, dans une boîte de réception, dans le backlog d’une autre équipe, à attendre une réunion ou une signature. Personne n’est responsable de ces attentes, donc personne ne les voit.

Quand un programme est en retard, le réflexe naturel est de pousser les gens plus fort : plus d’heures, plus de pression, plus de monde. Cela accélère le vol. L’aéroport reste exactement le même.

C’est cela, le piège du gaspillage : optimiser l’occupation des personnes, pendant que le travail lui-même passe l’essentiel de son temps à attendre.

Les dix visages du piège

Dix formes, en trois familles : l’attente, les passations, et l’agitation improductive. La plupart des programmes lents souffrent de cinq ou six à la fois.

L’attente

Attendre les outils. Un ticket pour obtenir un environnement de test, un autre pour un accès à la base de données, un troisième pour une règle de pare-feu. Chacun prend des jours, et chacun bloque un développeur qui était prêt à commencer.
Attendre une signature. Le travail est fait, et il attend le prochain comité d’architecture, la prochaine revue de sécurité ou le prochain comité des changements. Quelques minutes de revue, des semaines de file d’attente.
Attendre une autre équipe. Vous avez besoin d’un petit changement dans un service partagé. Il entre dans leur backlog, derrière leurs propres priorités. Votre sprint se termine avant que le leur ne commence.

Les passations

La course de relais. L’analyste écrit, l’architecte conçoit, le développeur construit, le testeur teste, l’équipe d’exploitation déploie. À chaque passage de témoin, du contexte se perd et les questions s’accumulent. Cinq passations, cinq traductions du même besoin.
Le ping-pong de tickets. « Peux-tu préciser ? » « Voir commentaire ci-dessus. » « Ce n’est pas ce qu’on voulait dire. » Une question qui prendrait deux minutes en face à face prend deux semaines dans un outil de ticketing.
Le document que personne ne lit. Quarante pages de spécifications qui ont pris un mois à écrire et que personne ne lit en entier. Les vraies décisions se prennent plus tard, dans un couloir, et ne reviennent jamais dans le document.

L’agitation improductive

La surcharge de réunions. Des réunions récurrentes qui ont survécu à leur raison d’être, des points d’avancement où les gens lisent à voix haute ce qu’ils auraient pu écrire, et des invitations envoyées à douze personnes « juste pour les tenir informées ». Les agendas se remplissent, et le travail se fait dans les interstices.
La taxe du reporting. Le même statut réécrit quatre fois, pour quatre comités, dans quatre modèles. On consacre plus d’efforts à expliquer l’avancement qu’à le produire.
Le faire deux fois. Des exigences mal comprises, des défauts trouvés tard, des fonctionnalités reconstruites après la première démo. La reprise est le gaspillage le plus coûteux, parce qu’on paie le travail deux fois, plus le retard entre les deux.
Les corvées manuelles. Des déploiements manuels, des tests de non-régression manuels, des données copiées à la main entre systèmes. Chaque répétition est lente, source d’erreurs et discrètement épuisante.

Mesurer l’aéroport, pas le vol

La pensée lean a une mesure simple pour cela : l’efficacité du flux. C’est le temps pendant lequel quelqu’un travaille réellement sur un élément, divisé par le temps total entre la demande et la livraison.

Prenons un exemple typique. Un changement demande trois jours de vrai travail : analyse, code, test. Il atteint la production au bout de six semaines, environ trente jours ouvrés. Efficacité du flux : 10 %. Les 90 % restants, c’est l’aéroport.

Ce chiffre explique pourquoi les remèdes habituels échouent. Recrutez des développeurs plus rapides et ramenez les trois jours de travail à deux : la livraison passe de trente jours à vingt-neuf. Supprimez une file d’attente de deux semaines, et la livraison tombe à vingt jours sans que personne ne travaille une minute de plus.

Il y a un second effet, contre-intuitif. La théorie des files d’attente, popularisée pour le développement de produits par Don Reinertsen, montre qu’à mesure que les personnes approchent de 100 % d’utilisation, les files ne grossissent pas doucement ; elles explosent. Une équipe sans marge ne peut pas absorber la moindre surprise, donc chaque demande attend derrière toutes les autres. Le programme qui garde tout le monde pleinement occupé est précisément celui où rien ne bouge.

Le coût humain suit. Les personnes qui passent leurs journées à attendre, relancer et rapporter perdent la satisfaction de terminer les choses. Occupé et improductif, c’est la façon la plus fatigante de travailler.

Signaux précoces

On peut repérer un aéroport surdimensionné sans aucun outil :

Personne ne peut dire combien de temps prend un changement typique entre la demande et la production.
« Bloqué » est le statut le plus courant sur le tableau.
Un ticket traverse quatre équipes avant que quoi que ce soit ne soit livré.
Les développeurs ont moins d’une demi-journée par semaine sans réunion.
Le même statut vit dans plusieurs présentations, chacune légèrement différente.
Les nouveaux arrivants attendent des semaines leurs accès avant d’écrire leur première ligne.
Chaque mise en production exige un week-end et une cellule de crise.
Tout le monde est surchargé, et pourtant le rythme de livraison ne s’améliore pas.
La réponse à chaque retard est « il nous faut plus de monde ».

Comment réduire l’aéroport

La réponse n’est pas de travailler plus dur. C’est de regarder le travail plutôt que les travailleurs, et de supprimer ce qu’il attend.

Suivre un élément, de bout en bout. Prenez un changement récent et reconstituez son parcours : chaque file, chaque passation et chaque signature, avec les dates. Un après-midi de cet exercice en apprend plus qu’un mois de rapports d’avancement. C’est la cartographie de la chaîne de valeur dans sa forme la plus simple.
Mesurer l’efficacité du flux et le délai de livraison. Deux chiffres, suivis chaque mois : combien de temps le travail met entre la demande et la production, et quelle part de ce temps quelqu’un y travaillait réellement.
S’attaquer d’abord à la plus grande attente. Ce n’est presque jamais le code. C’est généralement une approbation, un environnement ou le backlog d’une autre équipe. Supprimez celle-là, puis mesurez à nouveau.
Rendre les outils accessibles en libre-service. Environnements, accès et données de test à la demande, en quelques minutes, avec les contrôles intégrés. Chaque ticket supprimé rend des jours.
Construire des équipes qui possèdent tout le vol. Une équipe capable de concevoir, construire, tester et déployer sa propre capacité n’a pas besoin de course de relais. Moins de passations vaut mieux que des passations plus rapides.
Donner un budget aux réunions. Chaque équipe reçoit un budget hebdomadaire de réunions et du temps de concentration protégé. Les points d’avancement deviennent des mises à jour écrites ; les réunions sont réservées aux décisions et aux vraies conversations.
Un seul statut, généré à partir du travail. Tirez l’avancement du tableau, du pipeline et des tests, et partagez la même vue avec chaque comité. Personne ne le réécrit.
Automatiser ce qui se répète. Les déploiements, les tests de non-régression et les copies de données sont les premiers candidats. Le but n’est pas l’élégance ; c’est d’arrêter de payer le même péage chaque semaine.
Garder délibérément de la marge. Une équipe qui n’est jamais complètement réservée peut absorber les surprises et aider les autres. La marge n’est pas de la paresse ; c’est ce qui garde les files courtes.
Supprimer une chose par mois. Une réunion, un rapport, une porte, un modèle. Le gaspillage repousse discrètement, alors l’élagage doit être une habitude, pas un projet.

Ce qu’il faut éviter

Mesurer à quel point les gens sont occupés plutôt qu’à quelle vitesse le travail avance.
Ajouter des personnes à un programme dont le goulot d’étranglement est une file d’attente.
Des approbations sans temps d’attente maximal.
Inviter des gens à des réunions « pour information ».
Écrire des documents que personne n’a demandé à lire.
Créer un nouveau rapport pour chaque nouveau comité.
Planifier tout le monde à 100 % de sa capacité.

Le tournant de l’IA

L’IA raccourcit le vol, pas l’aéroport.

Les assistants de code et les agents peuvent rendre le travail concret considérablement plus rapide. Mais revenez à l’exemple : si le vrai travail représente 10 % du délai de livraison, le diviser par deux fait gagner 5 %. Les informaticiens reconnaîtront la loi d’Amdahl : accélérer une partie d’un processus ne peut jamais faire gagner plus que le temps que prend cette partie. Un voyage de six semaines avec un vol plus rapide reste un voyage de six semaines.

Pire, un code plus rapide peut encombrer davantage l’aéroport. Plus de changements arrivent aux mêmes comités d’approbation, aux mêmes environnements de test et aux mêmes fenêtres de mise en production. Les files grossissent, et le gain s’évapore.

La bonne nouvelle, c’est que l’IA peut aussi travailler sur l’aéroport. Elle peut rédiger la réponse de clarification avant que le ticket ne rebondisse, générer le statut à partir du travail lui-même, préparer des données de test, et repérer les éléments qui attendent depuis le plus longtemps. Dirigée là, elle rapporte bien plus que sur le seul vol.

Regarder l’horloge, pas l’agenda

Les programmes les plus rapides sur lesquels j’ai travaillé n’étaient pas ceux où les gens étaient les plus occupés. C’étaient ceux où quelqu’un posait sans cesse une question simple : où le travail attend-il en ce moment ? Puis supprimait cette attente, une à la fois.

Alors cette semaine, essayez sur un élément. Prenez un changement qui vient d’atteindre la production, et retracez son parcours jusqu’à la première demande. Comptez les jours de travail et les jours d’attente. Le résultat est généralement surprenant, et c’est le meilleur point de départ que je connaisse.

Combien de temps dure l’aéroport dans votre programme ? J’aimerais sincèrement connaître vos chiffres, et vos histoires.

Toutes les situations décrites ici sont des composites, tirés de nombreux programmes sur 25 ans.