Changement de contexte Slack–code: coût caché du deep work
Le changement de contexte entre Slack et code coûte des heures de travail profond par semaine. Comment le mesurer, réduire et protéger son état de flow.
By Ellis Keane · 2026-03-13
Combien de minutes de travail profond avez-vous réellement obtenues aujourd'hui? Pas le temps passé au bureau. Pas le temps avec l'IDE ouvert. Une concentration vraie, soutenue, sans interruption sur un seul problème. Si vous pouvez répondre à cela avec certitude, soit vous mentez, soit vous n'avez jamais vécu le changement de contexte entre Slack et le code – auquel cas, sincèrement, montrez-moi comment vous faites.
Je pose la question parce que je ne connais honnêtement pas mon propre chiffre la plupart des jours. Je sais que je me suis assis à 9 h pour travailler sur une migration de base de données. Je sais qu'à un moment j'ai levé les yeux et il était 13 h. Et je sais qu'entre les deux, j'avais ouvert Slack peut-être deux douzaines de fois – non pas parce que quelqu'un avait besoin de moi, mais parce que ce petit badge rouge a une force d'attraction qui ferait honte à une petite lune. La migration, qui aurait dû prendre une matinée, s'est étalée jusqu'au mercredi.
Le mythe des 23 minutes (et ce qui est réellement vrai)
Vous avez probablement vu la statistique: «il faut 23 minutes pour se refocaliser après un changement de contexte.» Cela provient des recherches de Gloria Mark à l'UC Irvine, et même si la recherche est réelle, le chiffre est si souvent mal cité qu'il est devenu une vague intuition. Le chiffre de 23 minutes correspond au temps nécessaire pour revenir à la tâche originale – pas au temps pour retrouver le même niveau de concentration – et a été mesuré sur les travailleurs du savoir en général, pas spécifiquement sur les développeurs.
Pour les développeurs, le coût réel dépend entièrement de ce que vous avez en tête. Vous déboguez une subtile condition de course pour laquelle, après vingt minutes à fixer l'écran, vous avez enfin construit un modèle mental de trois machines à états imbriquées? Perdre ce modèle vous coûte à nouveau les vingt minutes entières. Corriger une faute de frappe dans un fichier de configuration? Des secondes. L'important n'est pas le chiffre exact. C'est que le changement de contexte entre Slack et le code a un coût totalement invisible sur le moment, mais qui apparaît clairement dans la vélocité de votre sprint en fin de semaine.
Le rapport sur la fatigue des outils de Lokalise a révélé que les travailleurs changent d'application en moyenne 33 fois par jour, 17 % le faisant plus de 100 fois. Nous avons construit tout un écosystème de logiciels de «productivité» dont l'effet mesurable principal est d'interrompre la productivité. Quelque part, un product manager célèbre des chiffres de DAU composés entièrement de personnes qui vérifient si elles peuvent enfin reprendre le travail.
Pourquoi le changement de contexte entre Slack et le code est particulièrement coûteux
Je veux être juste envers Slack. C'est un outil genuinement bon et je ne vais pas soutenir que les équipes d'ingénierie devraient revenir à IRC (même si la pensée me traverse l'esprit certains jours). Mais le changement de contexte de Slack vers l'IDE est catégoriquement plus coûteux que de passer d'un onglet de navigateur à un autre, et il vaut la peine de comprendre pourquoi.
Le décalage du modèle mental. Lorsque vous êtes profondément dans le code, vous maintenez un modèle complexe dans votre tête – les états des variables, les chaînes d'appels de fonctions, la forme générale du système que vous modifiez, et la séquence particulière de modifications à effectuer dans un ordre précis. Slack fonctionne dans un mode cognitif totalement différent: contexte social, fil de conversations, déterminer qui parle de quoi et si c'est pertinent pour vous. Passer entre ces deux modes n'est pas comme basculer entre des onglets. C'est comme passer entre deux types de pensée totalement différents, et votre cerveau n'a pas de bouton «sauvegarder l'état» pour l'un ou l'autre.
L'impôt d'incertitude. Voici ce qui tue vraiment votre concentration: ce n'est pas l'interruption elle-même, c'est la possibilité de l'interruption. Quand un badge de notification apparaît, vous ne savez pas si c'est important jusqu'à ce que vous vérifiez. Cette incertitude s'installe dans votre mémoire de travail comme une question non résolue, grignotant votre attention même si vous résistez au changement. Et, soyons honnêtes, je résiste à cela aussi mal que n'importe qui – je me suis surpris à faire ⌘-Tab vers Slack au milieu d'un message de commit parce que le badge est apparu dans mon champ de vision périphérique. Le message de commit portait sur la suppression de code mort. La notification Slack, c'était quelqu'un qui réagissait à un gif avec un gif. Après-midi productive pour tout le monde.
Le piège du fil. Vous ouvrez Slack, voyez une notification, cliquez dans un fil, lisez trois messages, réalisez que ça ne nécessite pas votre contribution, revenez en arrière, remarquez qu'un autre canal a un badge, le vérifiez aussi – et soudain cinq minutes se sont évaporées et votre logique de migration est un souvenir lointain. L'ironie est que le modèle de fils de Slack, conçu pour réduire le bruit, augmente en réalité le nombre de clics entre «j'ai vu un badge» et «j'ai confirmé que rien ne me concerne». Des fils dans des fils. C'est des tortues jusqu'en bas.
Le coût du changement de contexte entre Slack et le code ne réside pas dans les secondes passées dans Slack. C'est la charge cognitive liée au passage entre deux modes de pensée fondamentalement différents, amplifiée par l'incertitude de ne pas savoir si la notification valait l'interruption.
Ce qui aide vraiment (et ce qui n'aide pas)
J'ai essayé la plupart des conseils standard – et je veux dire vraiment essayé, pas «lu l'article de blog et hoché la tête». Voici où j'en suis arrivé après environ six mois à observer activement mes propres schémas d'interruption.
Ce qui fonctionne
- Des fenêtres Slack planifiées. Consulter Slack à 9 h, 12 h et 15 h les jours de travail profond, et fermer l'application (vraiment fermer – pas réduire, fermer) entre les deux. Réduit le nombre de changements de la vingtaine à un seul chiffre. Masquer complètement l'icône du dock les jours de concentration est absurde mais efficace.
- Ne pas déranger avec des exceptions par mots-clés. Le mode Ne pas déranger de Slack, configuré pour laisser passer les messages contenant des termes spécifiques ou provenant de personnes précises. Silence face au bruit, alertes pour l'urgence réelle. Imparfait, mais mieux que binaire.
- Regrouper les messages sortants. Noter les messages Slack sur un bloc-notes et les envoyer en lots. Réduit les interruptions pour les autres membres de l'équipe, et élimine les «attends, ignore mon dernier message».
Ce qui semble raisonnable mais ne résiste pas à la réalité
- «Il suffit de désactiver les notifications.» Protège parfaitement l'état de flow. Signifie aussi que vous manquez le fil où votre équipe change le contrat d'API que vous êtes en train d'implémenter. Le remède crée sa propre maladie.
- «Mettre son statut sur occupé.» Les gens ignorent les statuts. Le statut ne porte aucune information réelle parce que tout le monde se prétend occupé en permanence – c'est l'équivalent professionnel de «comment ça va?» / «bien».
Filtrer au niveau du système
L'approche des fenêtres planifiées fonctionne, mais c'est une solution de discipline – et les solutions de discipline ont une durée de vie. Vous les maintenez trois semaines, quelque chose d'urgent brise le schéma, et vous revenez à vérifier Slack chaque fois que le badge tressaute. J'ai traversé ce cycle suffisamment de fois pour savoir que la solution n'est pas plus de volonté. C'est un meilleur filtre.
Ce qui résoudrait vraiment le problème du changement de contexte au niveau du système, c'est quelque chose qui comprend à la fois ce sur quoi vous travaillez et ce qui se passe dans Slack, et qui peut faire la différence entre «il y a une décision dans un fil qui affecte directement le code que vous êtes en train d'écrire» et «quelqu'un débat des options de déjeuner dans #random».
C'est ce que nous construisons avec Sugarbug. Il se connecte à Slack (et à GitHub, Linear, Figma, entre autres), classifie chaque signal par type – décision, blocage, question, mise à jour de statut, bruit – et les lie aux tâches et aux personnes auxquelles ils se rapportent. Vous voyez quelle activité Slack est pertinente pour votre tâche actuelle sans ouvrir Slack. Pas de badge. Pas d'impôt d'incertitude. Pas cinq minutes à fouiller dans les fils pour découvrir que non, cette notification ne vous concernait pas.
Exemple concret de la semaine dernière: j'étais plongé dans une migration de recherche vectorielle, et un membre de l'équipe a pris une décision dans un fil Slack concernant le modèle d'embedding que nous utiliserions désormais. Sans filtrage, je l'aurais soit complètement manqué (mode Ne pas déranger), soit découvert des heures plus tard en parcourant manuellement les fils. Le classificateur de Sugarbug l'a remonté comme signal «décision – pertinente pour votre tâche actuelle». Un coup d'œil, retour à la migration.
Nous n'avons pas encore résolu cela parfaitement – le classificateur rate encore des cas limites, et nous itérons sur la façon de présenter les signaux filtrés sans créer encore une autre surface de notifications (ce qui serait un magnifique contre son camp). Mais même un filtrage imparfait bat l'option binaire «toutes les notifications» ou «aucune notification». Ce jour de migration, j'estime qu'au moins vingt de mes visites sur Slack étaient inutiles – vingt rechargements de contexte qu'un bon filtre aurait entièrement prévenus.
Arrêtez de payer l'impôt de contexte à chaque fois qu'un badge apparaît. Sugarbug ne remonte que les signaux Slack qui affectent réellement votre travail en cours.
Q: Quel est le vrai coût du changement de contexte entre Slack et le code? A: Les recherches de Gloria Mark à l'UC Irvine ont montré qu'il faut environ 23 minutes pour revenir à votre tâche originale après une interruption, bien que le coût réel varie énormément selon la complexité de ce que vous faisiez. Pour les développeurs qui basculent entre Slack et leur IDE des dizaines de fois par jour, cela représente des heures de travail profond perdues chaque semaine – et le modèle mental que vous aviez laborieusement construit survit rarement à l'aller-retour intact.
Q: Sugarbug aide-t-il à réduire le changement de contexte entre Slack et le code? A: Oui. Au lieu de basculer vers Slack pour vérifier si quelque chose requiert votre attention, Sugarbug classifie les messages Slack par type et les lie à la tâche sur laquelle vous travaillez. Les décisions, blocages et questions pertinentes pour votre travail actuel remontent sans que vous ayez besoin de les chercher. L'objectif est d'éliminer les changements «je vérifie juste au cas où» – ceux où vous ouvrez Slack, ne trouvez rien d'actionnable, puis passez trois minutes à vous rappeler ce que vous faisiez.
Q: Faut-il désactiver les notifications Slack pour réduire le changement de contexte? A: Couper les notifications protège l'état de flow, mais vous fait manquer des choses qui comptent vraiment – comme le fil où votre équipe décide de changer une API contre laquelle vous implémentez. La meilleure approche est le filtrage: distinguer les signaux qui nécessitent votre attention immédiate du bruit qui peut attendre. Les fenêtres Slack planifiées sont une bonne version manuelle de cela; Sugarbug est la version automatisée.
Q: Quelle est la différence entre changement de contexte et multitâche? A: Le multitâche consiste à essayer de faire deux choses simultanément (ce que les humains font vraiment mal). Le changement de contexte consiste à passer d'une tâche à l'autre de manière séquentielle – le coût réside dans le temps et l'énergie cognitive pour recharger le modèle mental du code. Pour un développeur qui tient un système complexe dans sa tête, ce rechargement peut prendre de quelques secondes à une demi-heure selon la profondeur du travail.
Q: Sugarbug peut-il filtrer quels messages Slack méritent une interruption? A: Sugarbug classifie les signaux par type et les lie aux tâches sur lesquelles vous travaillez. Donc au lieu d'ouvrir Slack et de parcourir chaque canal, vous voyez quelle activité est pertinente pour votre travail actuel. Nous itérons encore sur le scoring de pertinence (ce n'est pas parfait), mais c'est significativement mieux que l'approche tout-ou-rien du mode Ne pas déranger.
---
Si l'aller-retour Slack vers l'IDE épuise vos heures de travail profond – et si masquer l'icône du dock pour éviter un badge de notification ressemble à une stratégie de productivité raisonnable – c'est l'impôt que nous avons construit Sugarbug pour réduire. Rejoignez la liste d'attente.