La scène, tu l'as vécue. 18h, fin de journée. Tu regardes ce que tu as livré : presque rien. Tu as enchaîné six créneaux de réunions, tu as répondu à 40 messages Slack, tu as ouvert ton IDE quatre fois pour des sessions de 20 minutes interrompues. Tu as bossé toute la journée, et tu n'as pas avancé sur le ticket important que tu devais finir.
Toi, tu te dis "il y a quelque chose qui cloche avec moi, je n'arrive plus à me concentrer comme avant". Tu envisages d'aller voir un médecin. Tu te demandes si c'est l'âge. Tu te culpabilises de ne pas livrer.
Le problème n'est pas dans ta tête. Il est dans la structure de ta journée. Coder demande un état mental spécifique, qu'on appelle le "deep work" ou le flow. Cet état est fragile. Il faut entre 15 et 25 minutes pour l'atteindre, et il s'effondre à la première interruption. Une journée fragmentée en six réunions de 30 minutes ne contient quasiment aucun moment où tu peux atteindre cet état. Ton cerveau est en alerte permanente, prêt à passer à autre chose dans dix minutes. Coder dans ces conditions, c'est impossible.
Cet article explique pourquoi le travail dev a des contraintes que peu de métiers ont, comment cette réalité s'oppose frontalement à la culture réunion qui s'est installée partout, et la méthode concrète pour protéger les créneaux où tu produis vraiment.
Le problème : le coût d'une interruption est invisible
Quand un collègue te demande "tu as cinq minutes ?", tu réponds oui par politesse. Tu interromps ton travail, tu lui réponds, tu retournes à ton code. Tu te dis que tu as perdu cinq minutes. En réalité, tu en as perdu trente.
Voici ce qui se passe dans ta tête. Quand tu codes, tu charges en mémoire de travail un modèle mental complexe : la structure du code, les variables en cours, le bug que tu chasses, l'algorithme que tu construis. Ce chargement prend 15 à 25 minutes. Une interruption ne casse pas seulement les 5 minutes pendant lesquelles tu réponds, elle vide aussi tout ce modèle mental. Tu dois le reconstruire après. Au total, l'interruption coûte 30 à 45 minutes, pas 5.
Multiplie par le nombre d'interruptions d'une journée. Six réunions de 30 minutes te font perdre 6x30 minutes en réunion, plus 6x25 minutes de récupération avant de coder de nouveau, soit 5h30 minutes au total pour des réunions qui ne pesaient "que" 3 heures sur ton calendrier. Il te reste 2h30 de travail effectif sur ta journée. Et c'est pour ça que tu n'as rien livré.
Le calcul est documenté depuis longtemps. Paul Graham a écrit un essai célèbre sur le sujet en 2009, "Maker's Schedule, Manager's Schedule". Les études sur le contextswitching confirment depuis : pour les tâches cognitivement complexes, chaque interruption coûte 20 à 30 minutes de productivité réelle.
Le principe : protéger ton temps de focus est ton vrai travail
La conclusion paraît évidente : si les interruptions tuent ta productivité, il faut les éliminer. Sauf que tu n'es pas seul à décider de ton calendrier. Les réunions sont posées par d'autres, le Slack ne te demande pas la permission, l'urgence du collègue est sa priorité, pas la tienne.
Le principe à intérioriser, c'est que protéger ton temps de focus n'est pas un caprice individuel, c'est ton vrai travail. Pas le code que tu produis, le créneau qui te permet de produire ce code. Sans temps protégé, le code ne sort pas. Tu peux apprendre toutes les bonnes pratiques techniques du monde, si ton calendrier est en miettes, tu ne livreras rien de substantiel.
Voici les quatre leviers, par ordre d'impact croissant.
1. Bloquer des créneaux de focus dans ton calendrier
Tu mets toi-même des événements "Focus - ne pas planifier" dans ton calendrier, idéalement le matin sur des plages de 90 minutes ou plus. Visibles par tes collègues. Ces événements ont le même statut que n'importe quelle réunion : on ne planifie pas par-dessus.
C'est la base. Si tu n'as pas de créneaux protégés visibles, n'importe qui pose des réunions n'importe où, et ta journée est ingérable.
2. Batcher les réunions sur certaines plages
Plutôt que d'avoir six réunions étalées dans la journée, tu négocies pour qu'elles se concentrent sur des plages dédiées. Par exemple, "mes réunions, c'est mardi et jeudi après-midi". Le reste du temps, tu codes.
Ce levier demande une négociation en équipe, parce que tu ne décides pas seul. Mais beaucoup d'équipes adoptent ce principe quand un membre le propose : ça profite à tout le monde, pas seulement à toi.
3. Mettre Slack en pause active
Slack (ou Teams, ou Discord) est le plus gros destructeur de focus moderne. Chaque notification coûte un fragment de ta concentration, et tu en reçois cent par jour.
Le réflexe : pendant tes créneaux de focus, tu coupes les notifications. Pas "tu mets le téléphone en silencieux", tu coupes vraiment : tu fermes l'onglet, tu actives le "Ne pas déranger" sur Slack, tu sors le téléphone de ton bureau. Tu rouvres au prochain créneau de communication. Le monde ne s'écroulera pas, l'urgence absolue n'arrive presque jamais.
4. Apprendre à dire non aux réunions qui ne te concernent pas
Les invitations à des réunions où tu n'es pas vraiment nécessaire. La "réunion d'alignement" mensuelle où tu écoutes sans parler. Le standup à 14 personnes où ton sujet prend une minute sur 45.
Tu refuses, ou tu demandes le compte-rendu écrit, ou tu négocies un format réduit. Cette posture demande du courage au début. Très vite, tu réalises que personne ne se vexe et que ta productivité explose.
Exemple : ce à quoi ressemble une journée bien structurée
Voici à quoi ressemble une journée de dev structurée pour produire vraiment, comparée à une journée typique qui fait que tu n'avances pas.
Journée mal structurée (la norme actuelle dans beaucoup d'équipes) :
- 9h00 - 9h15 : standup
- 9h15 - 9h45 : tu ouvres ton ticket, tu te plonges dedans
- 9h45 - 10h15 : réunion alignement produit
- 10h15 - 11h00 : tu reprends, tu cherches où tu en étais
- 11h00 - 11h30 : entretien candidat
- 11h30 - 12h00 : Slack, mails
- 14h00 - 15h00 : revue de PR collective
- 15h00 - 15h30 : ton ticket, encore
- 15h30 - 16h30 : réunion sprint planning
- 16h30 - 18h00 : tu codes vraiment, mais tu es fatigué
Bilan : 2h30 de code effectif, dans des créneaux courts et fragmentés. Tu finis épuisé sans avoir avancé.
Journée bien structurée :
- 9h00 - 11h00 : focus, code, Slack coupé
- 11h00 - 11h15 : standup
- 11h15 - 12h30 : focus, suite
- 14h00 - 16h00 : créneau réunions et communications (revue PR, entretien, planning regroupés ici)
- 16h00 - 18h00 : focus, code, Slack coupé
Bilan : 5h30 de code effectif, dans des créneaux longs et continus. Tu finis avec ton ticket bouclé et l'esprit plus calme. Les réunions ont eu lieu, mais regroupées pour ne pas hacher tes blocs de production.
Pièges classiques à éviter
Croire que la solution passe par un outil
Tu installes une app de Pomodoro, tu testes Notion AI, tu changes de gestionnaire de tâches. Aucun outil ne résout le problème, parce que le problème n'est pas un outil manquant. C'est une structure de journée à reprendre en main.
Les outils aident une fois que la structure est en place. Avant, ils sont de la procrastination productive : tu as l'impression d'agir, tu n'agis pas.
Attendre que ton manager change les choses
"Mon manager devrait protéger nos créneaux de focus, ce n'est pas à moi de le faire." Sauf qu'il ne le fera pas, parce que ce n'est pas son problème quotidien. C'est ton problème, donc c'est à toi de le porter.
Tu peux proposer des règles d'équipe (no-meeting morning, créneaux dédiés), tu peux montrer l'exemple, tu peux refuser certaines réunions. Mais tu ne peux pas attendre que la solution descende du ciel.
Compenser en travaillant le soir
Tu n'arrives pas à coder dans la journée, donc tu reprends à 21h pour rattraper. Tu produis dans le calme, tu te dis que c'est la solution. En réalité, tu gagnes deux heures aujourd'hui contre une fatigue cumulée qui te casse demain.
Cette stratégie marche une semaine, pas un an. Si tu dois coder le soir pour livrer, c'est que ta journée a un problème structurel à corriger. Le burnout commence comme ça.
Multiplier les pauses pour "récupérer"
Tu finis fatigué le soir, alors tu prends une pause toutes les heures pour rester frais. Mais chaque pause coûte 15 à 25 minutes de réentrée en focus. Tu fatigues moins, et tu produis encore moins.
Les vraies pauses se prennent entre deux blocs de focus, pas au milieu. Tu codes 90 minutes, tu prends 15 minutes vraies (loin de l'écran), tu reprends 90 minutes. Tu fatigues comparablement et tu produis dix fois plus.
Accepter le télétravail sans cadre
Tu télétravailles, donc tu te dis que la fragmentation est moins grave parce que "tu es chez toi, tu peux switcher facilement". Faux. Le coût cognitif d'une interruption est le même partout. Et le télétravail ajoute ses propres distractions : famille, livraisons, tâches domestiques, frigo.
Si tu télétravailles, tu appliques les mêmes règles qu'au bureau, plus quelques règles supplémentaires : un espace dédié au travail, des horaires fixes de communication, et la fin claire de la journée.
Penser que ce sont des problèmes de freelances ou de seniors
"Moi je suis junior, je dois être disponible, je ne peux pas refuser des réunions." Faux. Plus tu es junior, plus tu as besoin de créneaux de focus longs pour apprendre et progresser. Coder est ce qui te fait progresser, pas être en réunion.
Tu présentes la chose à ton manager comme un investissement dans ta progression, pas comme un caprice. Tu demandes deux créneaux de focus protégés par semaine. C'est minimal et facile à accorder.
La conversation à avoir avec ton équipe cette semaine
Si tu veux changer les choses, voici comment ouvrir le sujet sans braquer personne.
Tu attends un moment calme, en standup ou en rétro. Tu poses la question : "j'ai l'impression qu'on a beaucoup de réunions courtes éparpillées dans la journée, et que ça fragmente notre temps de code. Est-ce qu'on pourrait essayer de les regrouper sur une plage, par exemple les après-midis de mardi et jeudi ?".
Dans 80% des cas, tes collègues acquiescent, parce qu'ils vivent le même problème en silence. Tu viens de nommer ce que tout le monde ressent. La conversation se déroule, vous testez sur deux semaines, vous gardez ce qui marche.
Si l'équipe résiste, tu commences par toi-même : tu mets tes créneaux de focus dans ton calendrier dès la semaine prochaine. Tu produis plus, c'est visible. D'autres suivent.
Pour aller plus loin
La protection du temps de focus est une des soft skills modernes du dev, au même titre que savoir estimer une tâche ou communiquer en réunion. L'article sur les soft skills du développeur moderne couvre ce paysage plus large. Et pour la partie sur estimer correctement ta charge sans surengagement, l'article sur estimer une tâche que tu n'as jamais faite donne les bonnes pratiques.
Côté lectures externes, "Deep Work" de Cal Newport est la référence sur le sujet. "Maker's Schedule, Manager's Schedule" de Paul Graham (essai gratuit en ligne) est le texte fondateur, court et puissant. À lire avant de discuter avec ton manager.
