Ce que personne ne mesure et qui tue votre productivité

Il y a une chose que j'ai mis des années à vraiment comprendre. Pas une technologie, pas un pattern d'architecture. C'est beaucoup plus simple et beaucoup plus douloureux à admettre.

Les équipes techniques ne ralentissent pas parce que les devs codent mal. Elles ralentissent parce qu'on ne mesure jamais le temps qui disparaît entre les lignes de code.

On appelle ça le overhead.

Qu'est-ce que le overhead, concrètement ?

Quand j'étais développeur junior, je pensais que la productivité c'était juste une question de vitesse à coder. Plus tu tapes vite, plus tu livres. Simple.

Puis j'ai été mid. Senior. Tech lead. CTO. Et j'ai commencé à voir les chiffres autrement.

Dans une équipe de 5 développeurs, tu as en théorie 200h de travail par semaine. Sauf que sur ces 200h, combien vont réellement à construire du produit ? Dans la plupart des équipes que j'ai vues ou accompagnées, c'est rarement plus de 50 à 60%.

Le reste, c'est du overhead.

Le overhead, c'est tout ce qui consomme du temps et de l'énergie sans produire directement de valeur. Les réunions qui auraient pu être un message Slack. Les PRs qui traînent 3 jours parce que personne n'a le temps de les reviewer. Le développeur qui passe 2 heures à comprendre un ancien bout de code non documenté. La CI qui met 40 minutes à tourner. Le ticket Jira mal spécifié qui génère 5 échanges pour clarifier ce que le PO voulait dire.

Tout ça, c'est du overhead.

Et le problème avec le overhead, c'est qu'il est invisible. Personne ne le met dans un burndown chart. Personne n'ouvre un ticket "temps perdu en réunions inutiles". Il s'accumule en silence et au bout d'un moment tu te demandes pourquoi les sprints glissent alors que l'équipe travaille dur.

Les 4 types de overhead que j'ai rencontrés

Après 12 ans à naviguer entre les rôles développeur, tech lead, CTO, formateur, consultant, j'ai appris à les reconnaître. Il y en a quatre grandes familles.

1. L'overhead organisationnel

C'est le plus visible mais paradoxalement le moins traité.

Le standup de 15 minutes qui dure 45 minutes parce qu'on règle des bugs en live. La réunion de planning sans agenda préparé où on passe l'heure à rediscuter des décisions déjà prises. Le sprint review qui tourne en débat de fond sur la roadmap.

J'ai travaillé dans une équipe où on avait en moyenne 3h30 de réunions par jour. 3h30. Pour des devs. C'était institutionnalisé, personne ne le remettait en question et on s'étonnait que les features ne sortaient pas.

2. L'overhead de coordination

Celui-là, il est sournois. Il arrive souvent quand l'équipe grandit ou quand les sujets se complexifient.

C'est le développeur qui bloque sur une décision technique parce qu'il faut valider avec l'archi mais l'archi est en réunion, donc il switch sur autre chose, puis il oublie de revenir et la tâche dort 2 jours. C'est la PR qui attend une review côté backend alors que le frontend est bloqué. C'est la dépendance inter-équipes qui n'est pas anticipée et qui génère une semaine de blocage.

La coordination mal gérée, c'est de la latence pure. Du temps qui s'évapore sans que personne ne soit "en faute".

3. L'overhead technique

Mon sujet de prédilection. Et souvent le plus coûteux sur le long terme.

La dette technique, c'est du overhead qui se capitalise. Chaque feature devient plus longue à développer parce que le code est fragile. Chaque bugfix risque de casser autre chose. Les tests sont inexistants ou pas fiables, donc le dev n'a pas confiance en ses propres modifications et il ralentit par prudence.

J'ai audité des codebases où un développeur senior passait sa journée à naviguer dans du code spaghetti non documenté juste pour comprendre où ajouter 10 lignes. Le problème n'était pas sa compétence. C'était l'absence totale de standards sur le projet.

Une CI/CD qui prend 40 minutes, c'est aussi du overhead technique. Chaque push devient une pause forcée. Ça brise le flow. Ça démotive.

4. L'overhead cognitif

C'est le plus sous-estimé. Et pourtant, c'est probablement celui qui détruit le plus de valeur.

Un développeur interrompu toutes les 15 minutes par des notifications Slack ne fait pas vraiment du deep work. Il fait l'illusion du travail. Le cerveau a besoin d'environ 20 à 25 minutes pour rentrer en pleine concentration sur un problème complexe. Si tu l'interromps avant, il recommence à zéro.

Multiplié sur une journée, sur une semaine, sur une équipe entière… c'est colossal.

Il y a aussi le context switching! Le développeur qui jongle entre 4 projets en parallèle parce que l'organisation ne sait pas prioriser. Chaque changement de contexte a un coût mental. Et les incertitudes sur les priorités ont le même effet : le dev dépense de l'énergie mentale à se demander sur quoi se focaliser plutôt qu'à vraiment avancer.

Ce que j'ai appris à faire

Je ne vais pas te donner une liste de 50 best practices théoriques juste partager ce qui a réellement changé la donne dans les équipes avec lesquelles j'ai travaillé.

Protect the deep work, sans négociation

La règle la plus impactante que j'ai instaurée dans mes équipes : deux "no meeting days" par semaine. Mardi et jeudi. Aucune réunion, aucune interruption non urgente. Les devs protègent leurs matins pour le travail de fond.

Le résultat est immédiat. En deux semaines, l'équipe produit plus et se plaint moins d'être stressée. Parce que le stress technique vient souvent du fait de ne jamais avoir le temps de vraiment finir quelque chose proprement.

Des PRs petites et des reviews en 24h max

Les grandes Pull Requests sont une des sources les plus courantes d'overhead de coordination. Une PR de 1500 lignes, personne ne veut la reviewer. Elle traîne. Elle crée des conflits de merge. Elle bloque.

La règle que j'applique: 200 à 400 lignes maximum par PR. Une PR = une intention claire. Et un SLA de review de 24 heures. Pas de review en 3 jours, ça devient un bloquant systémique.

Le linting et les tests automatiques passent en premier. Si la CI est rouge, la PR ne mérite pas d'œil humain. L'humain lit l'architecture et la logique, pas la syntaxe.

Couper la dette à la source, pas juste la gérer

La dette technique, tu ne la résoudras pas avec un "sprint de refacto" tous les 6 mois. J'ai essayé. Ça ne marche pas.

Ce qui marche, c'est la règle du 20% : une journée par semaine dédiée à améliorer le code existant, réduire la dette, écrire des tests, améliorer la documentation. Pas une feature, pas un bugfix. Juste rendre le terrain plus sain pour ce qui vient après.

Et surtout, no tolerance pour les tests flaky. Un test qui échoue de façon aléatoire, c'est un test qui détruit la confiance de toute l'équipe dans la CI. Quand les développeurs commencent à ignorer les pipelines rouges "parce que c'est souvent des faux positifs", vous avez perdu quelque chose d'important.

Les réunions ont une raison d'exister ou elles n'existent pas

Ce que j'applique depuis plusieurs années : toute réunion récurrente doit avoir un agenda écrit et un owner. S'il n'y a pas d'agenda, la réunion est annulée. Pas reportée, annulée.

Le standup async, pour les équipes matures et alignées, c'est souvent plus efficace qu'un call quotidien. Un message Slack structuré (hier / aujourd'hui / blocages) fait le même travail en moins de temps et laisse une trace.

Documenter les décisions, pas juste le code

Les ADR (Architecture Decision Records) c'est un outil simple et sous-utilisé. L'idée: chaque décision technique significative (pourquoi on a choisi ce framework, pourquoi on a migré cette base de données, pourquoi on a choisi ce pattern plutôt qu'un autre) est documentée en quelques paragraphes.

Ça ne prend pas longtemps à écrire. Mais ça économise des heures de discussions quand un nouveau dev arrive ou quand on remet en question un choix 6 mois plus tard. Et surtout, ça force l'équipe à vraiment réfléchir avant de décider.

La vérité que personne ne veut entendre

Le overhead, souvent, c'est un problème de culture avant d'être un problème de process.

J'ai vu des équipes adopter Jira, puis Linear, puis Notion, puis revenir à Jira. Changer d'outil de standup toutes les 6 semaines. Essayer Scrum, puis Kanban, puis SAFe. Et avoir toujours le même problème.

Parce qu'aucun outil ne résout un problème culturel. Si l'équipe ne comprend pas pourquoi elle fait des standups, elle les fera mal peu importe l'outil. Si le management interrompt les blocs de deep work pour des urgences "critiques" tous les jours, aucune règle interne de l'équipe ne tiendra.

Réduire le overhead, ça commence par une conversation honnête sur comment l'équipe travaille vraiment, pas comment elle pense travailler. Ça demande des données. Ça demande d'observer sans juger. Et ça demande de s'attaquer aux causes profondes, pas aux symptômes.

C'est du travail de fond. Mais c'est ce qui différencie une équipe qui avance d'une équipe qui s'épuise à rester en place.

Le overhead n'est pas une fatalité. C'est un choix, souvent inconscient, de laisser des inefficacités s'installer et se normaliser.

Les équipes qui livrent avec constance ne sont pas celles avec les meilleurs développeurs. Ce sont celles qui ont appris à protéger le travail qui compte, à éliminer ce qui ne sert à rien, et à cultiver les bonnes pratiques comme des réflexes.

12 ans de terrain m'ont appris une chose: la vélocité n'est pas une question de vitesse individuelle. C'est une question de clarté collective.

Tu as des questions sur l'organisation de tes équipes tech ou tu veux échanger sur ton architecture ? Réserve un appel  je réponds à chaque message.

TakkJokk,