Linear, GitHub, Slack : 200 notifications réduites à 5
Les notifications de Linear, GitHub et Slack submergent votre équipe ? Pourquoi l'architecture est en cause – et les 5 signaux qui comptent vraiment.
By Ellis Keane · 2026-03-13
Le problème n'est pas que vous recevez trop de notifications. Le problème est que vous en recevez exactement le bon nombre – de trois outils différents, sur le même événement, au même moment.
Chaque webhook se déclenche correctement. Chaque intégration livre précisément ce qu'elle a promis. GitHub vous notifie du PR. Linear vous notifie de la tâche que le PR clôture. Slack vous notifie parce que quelqu'un, à un moment donné (probablement vous, il y a trois mois, dans un élan d'optimisme mal placé concernant la « visibilité »), a connecté un bot au canal du projet. Trois outils, trois notifications, un événement, et tous fonctionnant exactement comme conçus. L'ingénierie est irréprochable. L'expérience est misérable.
Vos notifications Linear, GitHub et Slack ne sont pas envahissantes parce que quelque chose est cassé. Elles le sont parce que rien ne l'est. Chaque outil exécute fidèlement son contrat de notification sans aucune conscience que les autres existent. Il n'y a pas de bus d'événements partagé. Il n'y a pas de couche de déduplication. Il n'existe nulle part dans la pile le concept « cet humain est déjà au courant. » Vous ne souffrez pas d'une mauvaise configuration. Vous souffrez du point d'aboutissement logique de brancher six outils dans le même flux de travail et de laisser chacun crier de façon indépendante dans le vide.
« Le système de notifications n'échoue pas. Il réussit tellement qu'il vous ensevelit. » – Chris Calo
Progrès.
Anatomie d'un seul merge – l'autopsie des doublons
Permettez-moi de vous guider à travers un événement – un unique merge de PR – et de tracer ce qui se passe dans la couche de notifications. Non parce que c'est inhabituel, mais parce que c'est déprimamment ordinaire.
Un coéquipier merge un PR sur GitHub. Voici la cascade :
- GitHub déclenche un webhook dans votre boîte de notifications. Vous avez rédigé une révision sur ce PR, vous y êtes donc abonné. C'est la notification numéro un.
- L'intégration GitHub de Linear détecte la tâche liée et fait passer automatiquement son statut de « En cours » à « Terminé. » Linear génère une notification pour tous ceux qui suivent la tâche – ce qui vous inclut, car vous êtes dans la même équipe. C'est la notification numéro deux.
- Le bot Slack (celui que vous avez connecté dans cet élan d'optimisme que j'ai mentionné) publie un résumé du merge dans #frontend. Si quelqu'un réagit à ce message avec un emoji ou un commentaire, Slack génère une notification de fil. C'est la notification numéro trois, potentiellement quatre.
- CI s'exécute sur le commit du merge. GitHub déclenche un autre webhook. Si CI réussit, cela vous importe probablement peu, mais vous recevez quand même la notification car le modèle d'abonnement de GitHub est binaire – soit vous suivez, soit vous ne suivez pas. C'est la notification numéro cinq.
Cinq notifications. Un événement. Et vous étiez dans l'appel où le merge a été discuté, donc vous le saviez déjà avant qu'aucune d'elles n'arrive.
Multipliez cela par chaque PR, chaque transition de tâche et chaque exécution CI pour une équipe de six, et vous regardez 30 à 40 événements en double par personne par jour avant même de compter les signaux genuinement nouveaux. Le système de notifications n'échoue pas. Il réussit tellement qu'il vous ensevelit.
Pourquoi la mise en sourdine est un pansement sur une hémorragie
Le conseil standard est une mise en sourdine agressive. Désactivez les notifications par e-mail de GitHub. Configurez Slack pour ne notifier que sur les mentions directes. Arrêtez de suivre tous les issues de Linear sauf ceux qui vous sont assignés. C'est l'équivalent en notifications de traiter un poignet fracturé en enlevant votre montre – techniquement vous avez réduit la complexité liée au poignet, mais vous avez aussi perdu la capacité de savoir l'heure.
J'ai essayé l'approche de la mise en sourdine (bien sûr que je l'ai fait – nous le faisons tous, c'est la première chose que tout le monde essaie, juste avant la deuxième chose que tout le monde essaie, qui est une chaîne Zapier qui l'empire d'une façon ou d'une autre). J'ai été agressif : j'ai complètement coupé les e-mails GitHub, mis en sourdine chaque canal Slack qui n'était pas le canal de travail de mon équipe, et je me suis désabonné de tout dans Linear sauf de mes propres issues. Félicité pendant environ trois jours.
Ensuite, j'ai raté deux révisions de PR bloquantes parce que les discussions avaient eu lieu dans des canaux que j'avais mis en sourdine. Les ingénieurs qui avaient besoin de ma révision m'ont finalement envoyé un DM – ce qui n'est qu'une notification avec des étapes supplémentaires et une touche d'énergie passivo-agressive « hé, tu as vu mon message ? ». Une semaine plus tard, une décision de design a atterri dans un fil de commentaires Figma qui a complètement changé le composant que je construisais à moitié, et je ne l'ai appris que lorsque mon PR a été rejeté. Ce qui était amusant.
Le problème fondamental de la mise en sourdine est qu'elle applique des règles statiques à un contexte dynamique. Vos paramètres de notification de mardi dernier ne savent rien du bug urgent qui est arrivé ce matin. Et plus vous mettez en sourdine de façon agressive, plus les lacunes dans votre connaissance s'élargissent – des lacunes que les coéquipiers comblent avec des DMs de « je voulais juste vérifier que tu avais vu... ». Ce qui, si vous tenez le score, signifie que la mise en sourdine agressive ne réduit pas vos notifications. Elle les déplace simplement des bots (qui ne vous jugent pas) aux humains (qui le font certainement).
Les cinq signaux qui justifient réellement une interruption
Après avoir enregistré les notifications pendant quelques semaines (dans un fichier texte brut, car je suis exactement le genre de personne dont vous vous attendriez à ce qu'elle écrive un article sur l'architecture des notifications), un schéma est apparu. Parmi environ 200 pings quotidiens, ceux qui nécessitaient genuinement une action dans l'heure tombaient dans cinq catégories :
- Quelqu'un est bloqué par vous. Une demande de révision de PR sur du code que vous possédez, une question que vous seul pouvez répondre, une décision attendant votre avis. C'est la seule catégorie où le retard a un coût cumulatif – chaque heure où vous ne répondez pas est une heure où quelqu'un d'autre ne peut pas travailler.
- Quelque chose que vous avez déployé est cassé. Des échecs CI sur votre branche, des pics d'erreurs après votre merge, une demande de retour arrière. La catégorie « votre code est en feu. »
- Une décision a été prise qui affecte votre travail en cours. Un changement de design, une mise à jour de contrat d'API, un changement de priorité du côté produit. Ces cas sont rares mais coûteux à manquer (voir : mon PR rejeté, ci-dessus).
- Une date limite a bougé. La portée du sprint a changé, une démo a été avancée, une dépendance a glissé. Des événements qui modifient le calendrier.
- Quelqu'un a besoin d'aide et vous êtes la bonne personne. Pas chaque @channel. Pas chaque @here. Les spécifiques où votre expertise est genuinement pertinente – et même alors, seulement si personne d'autre ne peut répondre.
Tout le reste – transitions de statut, messages automatisés de bots, réactions emoji « ça semble bien », CI réussis sur des branches que vous ne suivez pas – sont des informations qui pourraient être utiles éventuellement mais qui n'ont pas besoin d'interrompre la fonction que vous êtes en train d'écrire. Le complexe industriel des notifications nous a convaincus que tout mérite une urgence égale. Ce n'est pas le cas.
Sur 200 notifications quotidiennes, environ cinq catégories justifient réellement d'interrompre ce que vous faites. Le reste est une information qui pourrait être utile éventuellement – mais les outils traitent tout avec la même urgence, ce qui signifie que rien ne l'est vraiment.
Un cadre de triage pour les architecturalement trahis
Voici un cadre que vous pouvez commencer à utiliser aujourd'hui – aucun outil requis, juste de la discipline et environ 20 minutes de configuration. Cela ne résoudra pas le problème architectural (rien de moins qu'une couche de déduplication ne peut le faire), mais cela arrêtera l'hémorragie pendant que vous évaluez des solutions à long terme.
Le balayage deux fois par jour : Au lieu de vérifier les notifications en continu, regroupez-les en deux balayages – une fois en milieu de matinée, une fois en milieu d'après-midi. Lors de chaque balayage, parcourez vos notifications GitHub, votre boîte de réception Linear et vos messages non lus Slack, et triez chacun dans l'un des trois seaux :
| Seau | Règle | Action | |------|-------|--------| | Agir maintenant | Quelqu'un est bloqué, quelque chose est cassé, ou une décision a besoin de vous | Traiter immédiatement | | Regrouper | Important mais pas urgent dans le temps | Ajouter à une liste « répondre plus tard », traiter en fin de journée | | Archiver | Bavardages de bots, mises à jour de statut, fils résolus, doublons | Marquer comme lu, passer à autre chose |
Définir des valeurs par défaut au niveau des canaux dans Slack : Pour chaque canal, décidez : est-ce un canal « agir maintenant » (le canal de travail de votre équipe, les canaux d'incidents) ou un canal « regrouper » (annonces générales, mises à jour inter-équipes) ? Mettez en sourdine les canaux de regroupement et ne les vérifiez que lors de vos balayages. Oui, c'est techniquement de la mise en sourdine, quelque chose que je viens de moquer pendant deux paragraphes – la différence est que vous les vérifiez toujours selon un calendrier plutôt que de prétendre qu'ils n'existent pas.
Utilisez les filtres de notifications de GitHub : Mettez en signet github.com/notifications?query=reason:review-requested – cette URL n'affiche que les révisions de PR explicitement assignées à vous, éliminant entièrement le bruit des abonnements/CI. Pour les e-mails, GitHub inclut un en-tête de raison (review_requested, mention, subscribed, ci_activity) sur lequel vous pouvez filtrer : archivez automatiquement « subscribed » et « ci_activity » et vous ne perdrez rien dont vous avez vraiment besoin. Le fait que GitHub enterre ces métadonnées utiles dans les en-têtes d'e-mail plutôt que de les exposer dans l'interface de notification vous dit tout sur la réflexion accordée au côté consommation de ces systèmes.
Cette approche ne capturera pas les signaux contextuels (vous souvenez-vous de ce commentaire Figma qui a torpillé mon PR ? Le balayage deux fois par jour ne l'aurait pas non plus capturé). Mais cela réduira le bruit de 60 à 70 pour cent, ce qui est suffisant pour arrêter l'alt-tab compulsif pendant que vous évaluez si le problème justifie une vraie solution.
Ce qu'une couche de déduplication devrait vraiment faire
C'est là que cela devient architecturalement intéressant – et là où j'ai cessé de penser à cela comme un problème de paramètres de notification et commencé à y penser comme un problème de classification.
L'approche naïve est la correspondance de mots-clés et la détection de mentions. Si votre nom apparaît, faites-le remonter. Si c'est une demande de révision qui vous est assignée, faites-la remonter. Cela capture les cas évidents mais passe complètement à côté des contextuels – la décision de design dans un fil où personne ne vous a @mentionné parce qu'ils ne savaient pas que vous construisiez le composant concerné. (Celui-là va me hanter un moment.)
Ce dont vous auriez réellement besoin est un graphe de relations : quelles tâches vous appartiennent, quels PRs sont liés à quels issues, quels fils Slack parlent de quelles fonctionnalités, quelles personnes ont tendance à avoir besoin de votre avis sur quels sujets. Quand un nouveau signal arrive – un message Slack, un événement GitHub, une transition Linear – vous le classifiez par rapport à ce graphe. Non pas « est-ce que ça mentionne Chris ? » mais « est-ce que ça affecte quelque chose sur lequel Chris travaille activement, qu'il attend ou dont il est responsable ? »
La classification devrait se décomposer en quelque chose comme :
| Classification | Ce que cela signifie | Action | |----------------|----------------------|--------| | Urgent | Vous bloquez quelqu'un, ou quelque chose est cassé | Faire remonter immédiatement | | Important | Affecte votre travail en cours, mais pas critique en temps | Regrouper dans un digest quotidien | | Informatif | Bon à savoir, aucune action requise | Disponible si vous allez chercher | | Bruit | Doublons, bavardages de bots, fils résolus | Filtré entièrement |
La partie difficile est que la confiance en la classification n'est pas binaire. Un message Slack dans un canal que vous ne visitez jamais pourrait quand même être urgent s'il référence une issue qui vous est assignée. Une notification GitHub concernant un dépôt auquel vous n'avez pas touché depuis des mois pourrait avoir de l'importance si quelqu'un vient de rouvrir un bug que vous pensiez corrigé. Vous avez besoin de deux couches travaillant de concert : une couche de normalisation d'événements qui hache chaque webhook entrant contre une clé composite – dépôt, ID d'issue, acteur, type d'événement – et la vérifie contre une fenêtre de déduplication TTL (essentiellement une fenêtre glissante d'empreintes d'événements récents), et derrière cela, un graphe de relations en direct mappant la propriété de tâches, les liens de PR, les participants aux fils et les schémas d'activité récente. Vous construisez essentiellement un modèle de lecture de l'état de travail complet de l'équipe, mis à jour en quasi-temps réel, et le requêtant à chaque signal entrant. La couche de déduplication capture les doublons évidents. Le graphe répond à la question plus difficile : « est-ce pertinent pour vous spécifiquement, en ce moment ? »
La boucle de classification centrale gère bien les cas clairs, et cela seul réduit substantiellement le bruit – mais les signaux genuinement ambigus (où vous n'êtes pas assez confiant pour supprimer mais pas assez confiant pour faire remonter non plus) sont encore un problème ouvert. Nous expérimentons avec leur regroupement dans un digest « peut-être », mais je ne prétendrai pas que nous l'avons résolu.
Ce qui change quand le flot s'arrête
Ce que je n'attendais pas – je pensais genuinement que le bénéfice serait juste « moins de pings » – c'est à quel point votre relation avec vos outils change profondément quand ils cessent de vous crier dessus.
Quand chaque notification pourrait être importante, vous développez cette anxiété de bas grade concernant les compteurs de non-lus. La barre latérale Slack avec ses noms de canaux en gras. La cloche GitHub. La boîte de réception Linear. Vous vérifiez de façon compulsive, non parce que vous attendez quelque chose d'urgent, mais parce que le coût de manquer quelque chose semble plus élevé que le coût de vérifier 50 choses qui s'avèrent être du bruit. J'avais l'habitude de faire alt-tab vers Slack entre l'écriture d'une signature de fonction et son corps. Pas une décision consciente – juste un réflexe, comme vous vérifieriez vos rétroviseurs à un feu rouge.
L'auto-interruption préemptive est sans doute pire que les notifications elles-mêmes, car vous brisez votre propre concentration avant même qu'un ping n'arrive. Vous vivez dans un état d'attention partielle permanente, et vous le ressentez dans le code que vous écrivez – des révisions plus superficielles, des choix architecturaux plus sûrs, le chemin de moindre résistance plutôt que l'approche qui est réellement correcte, parce que vous ne faites pas confiance à avoir 45 minutes ininterrompues pour y réfléchir.
Quand le flot s'arrête – quand vous faites confiance au fait que les signaux importants vous trouveront et que le bruit ne le fera pas – ce réflexe s'estompe. Pas immédiatement, parce que les vieilles habitudes sont tenaces. Mais en quelques semaines vous remarquez que vous passez de plus longues périodes dans votre éditeur sans l'alt-tab compulsif. Vous commencez à terminer vos pensées. Vous écrivez de meilleur code, non pas parce que vous êtes soudainement devenu plus intelligent, mais parce que vous avez arrêté de vous porter volontaire pour 30 changements de contexte par heure au nom d'un système de notifications qui ne vous l'avait jamais demandé.
Arrêtez de vous noyer dans les notifications. Sugarbug classe chaque signal de Linear, GitHub et Slack par pertinence – et ne fait remonter que ce qui a réellement besoin de vous.
Q: Sugarbug réduit-il les notifications envahissantes de Linear, GitHub et Slack ? A: Oui. Sugarbug se connecte à Linear, GitHub et Slack via API et classe chaque signal par urgence et pertinence. Au lieu de transmettre chaque notification, il ne fait remonter que celles qui requièrent votre attention – réduisant généralement des centaines de pings quotidiens à la poignée qui vous nécessite genuinement.
Q: Sugarbug peut-il prioriser les notifications de PR GitHub en fonction de ce sur quoi je travaille ? A: Sugarbug construit un graphe de connaissances de vos tâches, PRs et conversations. Il sait quels PRs sont liés à votre travail en cours et fait remonter en premier les demandes de révision, les conflits de merge et les échecs CI pour ceux-ci – tout en archivant discrètement le reste.
Q: En quoi Sugarbug diffère-t-il des paramètres de notifications intégrés de Slack ? A: Les paramètres de Slack vous permettent de mettre des canaux en sourdine ou de définir des mots-clés, mais ils ne peuvent pas comprendre le contexte entre les outils. Sugarbug lit conjointement Linear, GitHub et Slack, et sait donc qu'un fil Slack concernant un PR que vous avez rédigé est urgent même s'il se trouve dans un canal que vous avez mis en sourdine.
Q: Quel est le vrai coût de la surcharge de notifications pour les équipes d'ingénierie ? A: La recherche de Gloria Mark à UC Irvine suggère qu'il faut environ 23 minutes pour retrouver une concentration profonde après une interruption. Au-delà des pings eux-mêmes, le comportement de vérification compulsive qu'ils engendrent fragmente la concentration soutenue qu'exige le travail d'ingénierie complexe.
Si les notifications de votre équipe d'ingénierie ont franchi la ligne de « rester informé » à « rester anxieux », c'est probablement le signe que l'architecture a besoin d'être corrigée, pas vos préférences de notification.