Home | Blog | Data study

Coût du changement de contexte : que disent 5 M de PRs

Nous avons analysé 5 M+ de PRs pour mesurer le vrai coût du changement de contexte pour les développeurs – ce n'est pas là où vous pensez.

By Ellis Keane · 2026-03-29

Le coût du changement de contexte que la plupart des articles citent – 23 minutes pour se recentrer après une interruption, issu de la recherche de Gloria Mark à UC Irvine – est un vrai résultat d'une vraie étude. Mais elle mesurait des travailleurs du savoir en général en 2008, pas des ingénieurs logiciels. Et l'industrie artisanale des articles de blog qui multiplie 23 minutes par un nombre estimé d'interruptions pour produire des chiffres annuels alarmants en dollars (toujours accompagnés d'une photo de stock de quelqu'un se tenant la tête) fait quelque chose que la recherche originale n'a jamais voulu.

J'ai un intérêt personnel dans cette question. Dans une entreprise précédente, j'ai passé – et ce n'est pas une hyperbole – entre 80 et 100 % de certaines journées à être un routeur humain. Pas à écrire du code, pas à le relire. À router de l'information entre des personnes et des outils, parce qu'aucun système unique ne les connectait. Cette expérience est en partie pourquoi nous avons construit Sugarbug, mais c'est aussi pourquoi je suis sceptique quant aux calculateurs standard de coût de changement de contexte. Ils mesurent l'interruption. Ils ne mesurent pas les journées que vous passez sans jamais arriver à la chose sur laquelle vous étiez censé travailler.

Nous voulions donc savoir ce que le changement de contexte coûte vraiment dans le travail d'ingénierie – non pas en termes abstraits de productivité du développeur, mais mesuré dans l'artefact que les équipes produisent quotidiennement : les pull requests. Nous avons synthétisé les résultats de trois études à grande échelle couvrant plus de 5 millions de PRs dans des milliers de projets open source, et nous avons examiné ce qui détermine vraiment le temps de revue des pull requests.

Le résultat principal : le changement de contexte le plus coûteux n'est pas la notification Slack qui brise votre flux. C'est le pull request qui reste dans une file d'attente de revue pendant une journée, obligeant l'auteur à reconstruire tout un modèle mental quand les questions arrivent enfin.

Les jeux de données dont nous nous sommes inspirés

Nous n'avons pas construit un scraper personnalisé pour analyser 10 000 PRs de façon isolée. Nous avons synthétisé les résultats de deux études évaluées par les pairs et d'un grand jeu de données industriel, puis nous avons confronté leurs conclusions les unes aux autres.

stat: "3,35 M" headline: "Pull requests analysés par Zhang et al." source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"

Les trois jeux de données principaux :

Zhang et al. (2022), évalué par les pairs : 3 347 937 PRs fermés dans 11 230 projets. A utilisé une régression linéaire à effets mixtes pour identifier ce qui entraîne des retards de revue de PRs. Publié dans Empirical Software Engineering.
Adadot (2023), jeu de données industriel : Plus de 300 000 PRs fusionnés de ~30 000 développeurs. Non évalué par les pairs, mais l'échantillon est grand et la méthodologie (corrélation tau de Kendall) est transparente. Axé sur la taille des PRs par rapport au délai d'exécution.
Étude de revue multiple (2019), évaluée par les pairs : 1 836 280 PRs dans 760 projets GitHub. Publié dans Information and Software Technology. Examine le comportement de revue simultanée – un proxy direct du changement de contexte dans la revue de code.

Nous les avons croisés avec le 2024 DORA State of DevOps Report et le Atlassian Developer Experience Report 2024 (enquête auprès de plus de 2 100 développeurs sur le changement de contexte, la productivité des développeurs et le côté humain de l'équation).

La file d'attente est le vrai tueur

Zhang et al. ont constaté que le temps qu'il faut à un PR pour recevoir sa première réponse – premier commentaire, première revue, n'importe quoi en premier – explique 58,7 % de la variance dans la durée de vie totale du PR. C'est le prédicteur observé le plus fort dans le jeu de données – devant la taille du PR, la complexité du code ou le nombre de fichiers modifiés ! Et ce n'est pas proche.

Le coût le plus élevé du changement de contexte dans la revue de code n'est pas le changement lui-même – c'est la file d'attente qui se forme pendant que tout le monde est occupé à changer entre d'autres choses.

Réfléchissez à ce que cela signifie en pratique. Un ingénieur ouvre un PR à 10h. Le relecteur désigné est plongé dans sa propre branche de fonctionnalité, ou en réunion, ou en train de trier des messages Slack (et honnêtement, probablement les trois à la suite). Le PR attend. Au moment où quelqu'un le prend à 15h, l'auteur est passé à autre chose. Maintenant le relecteur a des questions, ce qui signifie que l'auteur doit faire un changement de contexte vers du code qu'il a écrit il y a cinq heures, reconstruire le modèle mental et répondre. Cette réponse arrive à 16h30, mais le relecteur est rentré chez lui.

Le PR vieillit d'un jour de plus.

Les données suggèrent que c'est davantage un problème de file d'attente qu'un problème de discipline – et le coût du changement de contexte de cette file se compose d'une façon que les calculateurs d'interruption manquent complètement.

Les petits PRs ne vous sauveront pas

Vous avez déjà entendu celui-là : les PRs plus petits sont relus plus vite, donc gardez vos PRs petits. Ce n'est pas exactement faux, mais la taille de l'effet est (vraiment) plus petite que vous ne vous y attendriez.

L'analyse d'Adadot portant sur plus de 300 000 PRs a trouvé une corrélation tau de Kendall de seulement 0,06 entre la taille du PR et le délai d'exécution – une association faible, même si l'étude n'a pas rapporté d'intervalles de confiance pour le chiffre agrégé. Les PRs de moins de 100 lignes ont environ 80 % de probabilité d'être complétés en une semaine, ce qui semble formidable jusqu'à ce que vous réalisiez que c'est le même taux de complétion qu'un PR resté six jours dans la file d'attente de revue de quelqu'un !

stat: "0,06" headline: "Corrélation entre la taille du PR et le délai d'exécution" source: "Analyse Adadot de plus de 300 000 PRs de ~30 000 développeurs (2023)"

Le résultat le plus intéressant : cette corrélation variait considérablement entre les organisations, allant de 0,1 à près de 0,7 selon l'entreprise. Ce qui suggère que la taille des PRs n'est pas intrinsèquement le goulot d'étranglement – c'est la culture de revue et le processus autour du PR. Une équipe avec une cadence de revue solide peut traiter des PRs plus grands efficacement. Une équipe où les revues sont une réflexion après coup aura du mal avec des PRs de n'importe quelle taille.

Le seuil de 400 lignes de l'étude de revue de code SmartBear/Cisco tient comme heuristique utile – les données d'Adadot ont également montré que l'engagement dans la revue chute au-delà de cette plage. Mais optimiser la taille des PRs sans corriger la cadence de revue sous-jacente revient à (et je dis cela avec une réelle affection pour chaque engineering manager qui a essayé) réarranger les chaises longues sur le Titanic.

Tout le monde relit tout en même temps

L'étude de revue multiple a révélé que 62 % des pull requests impliquent des développeurs qui relisent simultanément plusieurs PRs. Plus important encore, ils ont trouvé une corrélation statistiquement significative : plus de revues simultanées par relecteur était associé à une latence de résolution de PR plus longue.

62 % des pull requests impliquent des développeurs qui relisent simultanément plusieurs PRs – et la revue multiple corrèle directement avec des délais de résolution plus longs. attribution: Étude de revue multiple de pull requests, 1,8 M de PRs dans 760 projets

Le mécanisme est intuitif (même si l'étude, étant observationnelle, ne prouve pas la direction de la causalité). Un relecteur prend le PR n° 1, lit le diff, commence à former un modèle mental de ce que le code essaie de faire. Puis une notification arrive – le PR n° 2 a besoin d'une revue car il bloque un déploiement. Le relecteur change. Quand il revient au PR n° 1, il doit relire la moitié du diff car le modèle mental s'est dégradé.

Étendez cela à une équipe de huit ingénieurs, chacun ayant deux ou trois PRs ouverts, chacun relisant pour deux ou trois collègues, et la surcharge de coordination commence à s'expliquer d'elle-même. Séparément, le 2024 DORA Report a constaté que le groupe des "hautes performances" a diminué de 31 % à 22 % tandis que le groupe des faibles performances a augmenté de 17 % à 25 %. DORA n'isole pas la concurrence de revue de PRs comme facteur, mais l'augmentation de la surcharge de coordination est un contributeur plausible à ce changement.

Ce que les estimations de coût du changement de contexte ratent

Permettez-moi d'être direct sur le chiffre de « 50 000 $ par développeur et par an » qui circule largement dans les articles sur le coût du changement de contexte. La méthodologie derrière la plupart de ces estimations est : prenez les 23 minutes de temps de recentrage, multipliez par le nombre estimé d'interruptions quotidiennes (généralement entre 6 et 15, selon à quel point l'auteur est dramatique), multipliez par un taux horaire de développeur, et annualisez.

Le problème n'est pas que les mathématiques soient fausses. Le problème est que cela traite tous les changements de contexte comme équivalents. Passer d'une programmation profonde à un message Slack demandant où est le déjeuner d'équipe – c'est un changement de contexte. Passer de la revue d'un PR à la revue d'un PR différent dans une base de code complètement différente – c'est aussi un changement de contexte. Mais le coût cognitif n'est pas du tout comparable, et les aplatir en un seul taux horaire obscurcit là où les vrais dommages se produisent.

Pour le dire concrètement : à mon dernier emploi, une journée typique signifiait basculer entre Notion, Linear, Mattermost, Proton Mail, Proton Calendar, Discord, Twitter, Farcaster et d'innombrables canaux Telegram et Signal – et je suis sûr d'oublier une demi-douzaine. Maintenant j'en utilise une poignée (Signal, Obsidian, Figma, GitHub, e-mail, calendriers). Le coût par changement n'a pas changé. Ce qui a changé, c'est le nombre de contextes en attente d'attention – et lesquels avaient vraiment de l'importance.

Les données des PRs suggèrent que les changements coûteux sont ceux qui créent des files d'attente, pas ceux qui interrompent le flux. Un développeur qui est pingué immédiatement (en minutes) pour relire un PR et fait une revue rapide de 50 lignes – c'est une courte interruption avec un rendement élevé. Un développeur qui met cette demande de revue en file d'attente avec quatre autres et s'en occupe demain – c'est une interruption plus longue pour le relecteur mais crée un coût bien plus important pour l'auteur et l'équipe.

Ce que mesurent les calculateurs de coût

Interruptions individuelles – à quelle fréquence le flux de quelqu'un est brisé
Temps de recentrage – combien de temps pour revenir à la tâche précédente
Multiplication par le taux horaire – grands chiffres annuels effrayants

Ce que les données des PRs montrent vraiment

Formation de files d'attente – PRs attendant une première réponse
Concurrence des revues – relecteurs jonglant avec plusieurs PRs
Retards en cascade – les changements de contexte de l'auteur amplifiant les retards du relecteur

Ce que cela signifie pour votre équipe

Si vous essayez de réduire le coût du changement de contexte pour les développeurs de votre équipe, la réponse pratique est ennuyeuse – ce qui explique probablement pourquoi on n'en écrit pas beaucoup. Ce n'est pas un outil. Ce n'est pas un cadre de processus avec un programme de certification. C'est la cadence de revue. (Je sais, je sais. Personne n'a jamais été promu pour avoir amélioré la cadence de revue.)

Les benchmarks d'ingénierie 2025 de LinearB, tirés de 6,1 millions de PRs dans 3 000 organisations, ont révélé que les équipes atteignant des temps de cycle élite (moins de 2,5 jours) partageaient un trait : elles relisaient les PRs rapidement. Non pas parce qu'elles avaient moins de PRs, ni parce que leurs PRs étaient plus petits (bien qu'ils l'étaient souvent), mais parce que répondre aux demandes de revue en quelques heures était une norme d'équipe, pas une réflexion après coup.

Pour ce que ça vaut, Ben et moi – une équipe de deux – mettons en moyenne des minutes pour la première réponse aux PRs, pas des heures. Ce n'est pas une démonstration de discipline (nous n'en avons pas). C'est un accord d'équipe : les demandes de revue sont la seule notification qu'on ne met pas en file d'attente. Les actions CI et les tests automatisés gèrent les vérifications mécaniques, ce qui signifie que la revue humaine – la partie qui nécessite un vrai contexte – est plus courte et se produit immédiatement. L'accord est venu en premier. Les outils l'ont juste rendu durable.

Concrètement, cela signifie :

Mesurez le temps jusqu'à la première réponse, pas seulement le temps de cycle. Si vous suivez des métriques DORA, ajoutez celle-ci. C'est le prédicteur individuel le plus fort du débit de PRs (explique 58,7 % de la variance de durée de vie, selon Zhang et al.).

Limitez la concurrence des revues. Si un relecteur a trois demandes de revue en attente, une quatrième n'aura pas une bonne revue de toute façon. Les données de revue multiple ont montré une association claire entre la concurrence et la latence. Commencez avec une limite WIP de deux revues simultanées et surveillez l'impact.

Arrêtez d'optimiser la taille des PRs de façon isolée. Les petits PRs sont bien, mais ils ne remplacent pas une équipe qui relit vraiment les choses. Une équipe produisant vingt PRs de 50 lignes par jour avec un backlog de revue de 48 heures est dans une situation pire qu'une équipe produisant cinq PRs de 200 lignes avec des revues le jour même.

Reconnaissez que la revue est un vrai travail. L'enquête Atlassian de 2024 a constaté que 69 % des développeurs perdent plus de 8 heures par semaine à cause d'inefficacités. La revue n'a pas à être l'une de ces inefficacités – mais seulement si elle est traitée comme une activité d'ingénierie de premier ordre, pas comme une interruption du "vrai" travail.

Et voici la partie que personne dans l'espace des outils de productivité (nous-mêmes inclus, pour être honnêtes) ne veut dire à voix haute : l'intervention la plus impactante pour le coût du changement de contexte dans les équipes d'ingénierie n'est pas un outil. C'est un accord d'équipe sur quand les PRs sont relus. Si la norme implicite de votre équipe est « je m'occuperai des revues quand j'aurai un créneau », aucun outil ne pourra prévenir la cascade de files d'attente que les données des PRs révèlent.

Les outils aident – pouvoir voir le contexte complet d'un PR sans ouvrir quatre onglets de navigateur réduit la charge cognitive par changement, et faire ressortir quelles revues bloquent le travail d'autres personnes aide à prioriser. Mais le levier central est l'accord, et les accords sont gratuits. Aucun calculateur de 23 minutes requis.

Le changement de contexte le plus coûteux n'est pas la notification qui brise votre flux. C'est la demande de revue qui reste en file d'attente pendant une journée, obligeant l'auteur à reconstruire le contexte mental quand les questions arrivent enfin.

Recevez l'intelligence des signaux directement dans votre boîte de réception.

Questions fréquemment posées

Q: Quel est le coût du changement de contexte par développeur et par an ? A: Les estimations varient, mais la recherche sous-jacente est plus mince que la plupart des articles ne le suggèrent. L'étude de Gloria Mark à UC Irvine a révélé 23 minutes de temps de recentrage par interruption, et l'enquête Atlassian 2024 auprès de plus de 2 100 développeurs a constaté que 69 % perdent plus de 8 heures par semaine à cause d'inefficacités. Le montant en dollars dépend fortement des hypothèses salariales, de la fréquence des interruptions et de la définition du « changement » – c'est pourquoi nous nous sommes concentrés sur les données de PRs.

Q: Sugarbug aide-t-il à réduire le changement de contexte pour les équipes d'ingénierie ? A: Oui. Sugarbug connecte des outils comme Linear, GitHub, Slack et Figma dans un unique graphe de connaissances, afin que les ingénieurs puissent voir le contexte complet d'une tâche – le PR concerné, la discussion Slack, le commentaire Figma – sans ouvrir quatre onglets. L'objectif est moins de changements, pas moins d'outils.

Q: Quelle est la taille idéale d'une pull request pour minimiser les délais de revue ? A: L'analyse d'Adadot portant sur plus de 300 000 PRs a révélé que les PRs de moins de 100 lignes de code ont environ 80 % de probabilité d'être terminés en une semaine. Au-delà de 400 lignes, la qualité de la revue et la vitesse d'achèvement diminuent toutes les deux. Les PRs plus petits réduisent également la charge de changement de contexte pour le relecteur.

Q: Sugarbug s'intègre-t-il avec les pull requests GitHub ? A: Oui. Sugarbug scrape l'activité GitHub – PRs, commentaires, revues et changements de statut – et les relie aux signaux connexes dans vos autres outils. Si un issue Linear a engendré le PR, et qu'un fil Slack a débattu de l'approche, Sugarbug connecte les trois automatiquement.

Q: D'où vient la statistique des « 23 minutes pour se recentrer » ? A: Elle provient des recherches de Gloria Mark à UC Irvine, publiées dans « The Cost of Interrupted Work: More Speed and Stress » (CHI 2008). L'étude a révélé que les travailleurs mettaient en moyenne 23 minutes et 15 secondes à revenir à leur tâche initiale après une interruption. Il convient de noter que l'étude a observé des travailleurs du savoir en général, et non des ingénieurs logiciels spécifiquement.