Résumé

  • Eric Dumazet apparaît actuellement comme mainteneur de la mise en réseau générale, de TCP et des sockets dans Linux et siège au Technical Steering Committee de la Netdev Foundation. Ces rôles sont partagés avec d’autres mainteneurs et relecteurs: ils représentent une forte responsabilité d’intégration, et non une autorité exclusive sur le réseau du noyau.
  • Sa contribution nommée la plus claire est TCP Small Queues, introduite en 2012 pour empêcher qu’un seul flux TCP ne dépose trop de données dans les files d’attente situées sous la couche transport. En liant le crédit local du socket à l’achèvement des paquets, TSQ a réduit la latence et la pression mémoire côté émetteur sans éliminer toutes les files d’attente du chemin.
  • Le travail ultérieur sursch_fqet le pacing interne a fait du moment de transmission un contrôle explicite. Le fair queueing sépare les flux; le pacing répartit les paquets dans le temps. Ces mécanismes soutiennent plusieurs contrôles de congestion, y compris des environnements utilisant BBR, mais BBR a sa propre paternité et sa propre évolution.
  • Le travail le plus récent de Dumazet relie la disposition des structures, le trafic des lignes de cache et l’état par socket à l’efficacité des grands parcs de serveurs. La leçon est que la mise en réseau sous Linux est aussi une comptabilité de CPU, de mémoire, de profondeur de file et de temps. L’impact économique peut être significatif, mais les données publiques ne permettent pas d’attribuer une valeur financière exacte ni de promettre le même gain sur tous les systèmes.

Un serveur rapide peut encore perdre du temps derrière ses propres paquets

L’histoire commence dans une file de transmission. L’application a écrit des données, TCP a conclu qu’il pouvait en envoyer davantage et le noyau a transmis ces octets aux couches inférieures. Du point de vue de l’application, ils semblent être partis; en pratique, ils peuvent continuer à attendre sur la même machine.

Un débit élevé masque le retard. Une requête interactive se retrouve derrière un transfert volumineux, les tampons retiennent la mémoire et l’idée de données « en vol » cesse de coïncider avec ce qui est simplement accumulé localement. TCP Small Queues a modifié cette relation en limitant la quantité qu’un socket peut placer sous TCP et en restituant de la capacité d’envoi lorsque le matériel achève réellement le travail.

Le registre public est riche en ingénierie et délibérément limité sur le plan biographique

Les preuves les plus solides proviennent du noyau lui-même:MAINTAINERS, discussions de correctifs, documentation, présentations et des années de révision publique. Elles étayent sa responsabilité actuelle en matière de réseau général, de TCP et de sockets, sa participation à la Netdev Foundation et une affiliation visible à Google par le biais de l’adresse électronique de mainteneur.

Il n’existe pas de biographie complète et autorisée, de poste actuel vérifié en entreprise, de recensement total des correctifs ni de répartition exacte de son temps. Combler ces lacunes avec des détails plausibles réduirait la précision. Le profil se concentre sur les mécanismes et les décisions observables. Dumazet apparaît comme un ingénieur à responsabilité technique dont le travail ne devient une infrastructure qu’après révision, modification, test et déploiement par d’autres personnes.

Le statut de mainteneur le place près des décisions, pas au-dessus de la communauté

Le 4 août 2026, les registres de Linux le mentionnaient comme responsable de la mise en réseau générale, de TCP et des sockets. Un mainteneur peut demander la refonte d’une interface, refuser un coût de maintenance excessif, appliquer des modifications acceptées et représenter un sous-système vers la branche principale.

La même source montre une autorité partagée. David S. Miller, Jakub Kicinski et Paolo Abeni apparaissent pour la mise en réseau générale; Neal Cardwell partage TCP, et des relecteurs spécialisés interviennent selon le correctif. Les architectures, les pilotes, la sécurité, les tests, les versions stables et le processus final du noyau imposent d’autres limites. L’influence de Dumazet est grande précisément parce qu’elle s’exerce au sein de ce système distribué.

Linux est devenu une infrastructure économique lorsque le nombre de connexions a augmenté

Sur une petite machine, quelques octets supplémentaires par socket ou un défaut de cache supplémentaire peuvent passer inaperçus. Sur un serveur comptant des centaines de milliers de connexions, le coût se multiplie jusqu’à disputer le CPU, la mémoire et l’énergie à l’application elle-même.

« L’économie des serveurs » n’est pas un chiffre public d’économies. C’est la traduction du surcoût technique en densité, en capacité CPU restante, en mémoire réservée au réseau et en retard causé par les files locales. Les distributions et les opérateurs choisissent le noyau, la qdisc, l’algorithme de congestion et la NIC. Dumazet ne contrôle pas ces choix; il améliore le point de départ commun.

La fonction familière de TCP cache un système dense de comptabilité

TCP est présenté comme un flux fiable d’octets, mais il doit décider combien peut rester en attente, quand retransmettre, comment facturer la mémoire, ordonner les paquets et répartir le CPU et les files entre des milliers de sockets.

Une implémentation peut être correcte et néanmoins mal fonctionner: un arriéré local important, des rafales, des verrous ou des structures qui gaspillent le cache. Le fil conducteur du travail de Dumazet est comptable. Les octets sont attribués au socket, les achèvements restituent du crédit, les temps d’envoi sont calculés et les champs chauds sont séparés des champs froids. L’objectif est de maintenir le lien productif sans créer un second réseau caché à l’intérieur de l’hôte.

Avant TCP Small Queues, l’émetteur pouvait créer un arriéré qu’il ne contrôlait plus

Avant TSQ, TCP pouvait remettre trop de trafic à la qdisc et au pilote. La fenêtre de congestion pouvait être correcte alors qu’une file locale retenait encore des paquets sous la couche transport. L’application ne pouvait pas les récupérer lorsqu’un flux plus urgent apparaissait.

Cela affaiblissait le retour d’information: TCP observait les accusés de réception du chemin, mais une partie des données n’avait même pas quitté l’hôte. Cela consommait aussi de la mémoire, surtout lorsque de nombreux flux faisaient de même. Il fallait préserver le débit sans permettre à chaque socket de traiter les couches inférieures comme un stockage illimité.

La série TSQ de 2012 a rendu au socket un budget de file locale

Les correctifs de 2012 ont limité, par socket, la quantité de données mises en file sous TCP. Lorsque le crédit local était épuisé, le socket s’arrêtait; à l’achèvement des paquets, il retrouvait la permission d’envoyer.

L’idée était simple: comptabiliser les octets locaux et utiliser l’achèvement comme signal de progression. Le contrôle revenait à la couche transport qui comprenait le flux. Il n’était plus nécessaire de déposer un gros lot d’un seul coup pour occuper le lien. Les applications qui n’avaient jamais entendu parler de TSQ ont hérité d’un comportement plus discipliné.

L’achèvement des paquets est devenu un signal utile à l’intérieur de l’hôte

L’achèvement pouvait sembler n’être qu’un nettoyage. TSQ l’a utilisé comme information: la couche inférieure a progressé, donc le socket peut recevoir un nouveau crédit.

Ce retour local complète les accusés de réception distants. L’un décrit la progression sous TCP; l’autre, la progression sur le chemin. Les statistiques de qdisc, de pilote et de NIC montrent d’autres points. Aucun signal ne résout tout. TSQ exploite l’un d’eux pour limiter l’excès local sans remplacer le contrôle de congestion de bout en bout.

TSQ a réduit une source de bufferbloat, pas toutes les files du chemin

TSQ n’a pas éliminé le bufferbloat. Il limite l’arriéré local de l’émetteur. Des files subsistent dans la qdisc, le pilote, la NIC, l’accès, les routeurs, les commutateurs et le récepteur.

L’affirmation précise est plus utile: le mécanisme réduit la capacité d’un socket à créer une file cachée trop importante. Il peut diminuer la latence et la mémoire et rapprocher l’état de TCP de la progression du dispositif. Il ne remplace ni la gestion active des files, ni une configuration appropriée, ni le contrôle de congestion.

Limites, déports et charges de travail déterminent l’aide apportée par TSQ

L’effet dépend de la limite locale, de la taille des paquets, de la qdisc, des files du dispositif, de la segmentation et du mélange de flux. Un service interactif et une réplication massive ne réagissent pas de la même manière.

L’implémentation a aussi évolué depuis 2012. D’autres contributeurs ont ajusté l’intégration et corrigé des cas. Il est exact de créditer Dumazet pour l’origine sans présenter le mécanisme actuel comme une pièce figée et exclusivement à lui.

sch_fqa séparé les flux et intégré le temps dans l’ordonnanceur

En 2013, Dumazet a publié l’ordonnanceursch_fq. Il maintient un état par flux et une structure ordonnée dans le temps pour libérer les paquets selon l’instant d’envoi. Les nouveaux flux peuvent être servis tôt; les flux régulés par pacing attendent leur moment.

La conception évite qu’un transfert volumineux ne monopolise la file locale et offre à TCP un endroit où exécuter le pacing. Elle ne garantit pas l’égalité entre applications; elle fournit une politique de service plus disciplinée et une interface pratique pour les horodatages d’envoi.

Le fair queueing est un choix de politique, pas une promesse de résultats égaux

« Équitable » ne signifie pas que toutes les applications auront les mêmes performances. La taille des paquets, le chemin, le récepteur, la congestion, les déports et le nombre de connexions continuent de modifier le résultat.

La définition même du flux est politique. Une application peut ouvrir de nombreuses connexions et une autre une seule.sch_fqréduit la domination locale, mais ne décide pas de l’équité entre utilisateurs ou entreprises. Pour l’opérateur, c’est un outil d’arbitrage, pas une garantie universelle.

Le pacing transforme un débit estimé en une séquence d’instants d’envoi

Un algorithme peut choisir le bon débit et néanmoins le libérer en rafale. La moyenne paraît bonne, mais la file subit un pic.

Le pacing répartit les paquets dans le temps. Il peut stabiliser les files, améliorer la coexistence et mieux exprimer le modèle de congestion. L’implémentation dépend des horodatages, des minuteries, de la qdisc, de la segmentation et de la NIC. Un débit logiciel n’est réel que lorsqu’il se traduit en instants physiques sur le lien.

Le pacing et le contrôle de congestion résolvent des problèmes différents

Le contrôle de congestion décide combien utiliser le chemin; le pacing décide quand les données autorisées sortent. Un bon modèle peut être détruit par des rafales, et un pacing parfait peut exécuter un mauvais débit.

L’infrastructure de Dumazet permet à plusieurs algorithmes d’exprimer un débit dans le temps. La paternité de chaque modèle appartient à ses propres concepteurs.

BBR utilise le pacing, mais possède sa propre paternité et sa propre histoire

BBR est souvent associé à Dumazet parce qu’il dépend du pacing et qu’il est apparu dans l’environnement Google. Cela n’en fait pas l’inventeur unique. L’algorithme possède des auteurs, un modèle et des versions distincts.

La contribution de Dumazet est fondatrice: files d’attente, pacing, instrumentation et sockets rendent d’autres contrôles viables. Cette formulation reconnaît son importance et préserve le crédit de Neal Cardwell et d’autres ingénieurs spécialistes de la congestion.

TSO économise du CPU et peut recréer la rafale que le pacing cherchait à éviter

Le TCP Segmentation Offload permet de remettre un grand segment à la NIC, qui le divise ensuite. Cela réduit le coût par paquet, mais insère le matériel entre la décision temporelle et l’émission réelle.

Si un gros bloc sort d’un coup, la NIC peut créer une rafale. TSQ, qdisc, TSO, pilote et matériel doivent être traités comme un système. Une économie de CPU peut dégrader la latence en l’absence de coordination.

Quantum, horodatages et comportement de la NIC doivent décrire la même réalité

Le noyau travaille avec des quanta, la résolution des minuteries, les horodatages, les unités de déport et les files physiques. Un quantum important recrée des rafales; un quantum réduit consomme du CPU; une NIC avec une autre granularité modifie la sortie.

C’est pourquoi la qdisc fait partie de la planification de capacité. Les développeurs doivent mesurer le chemin complet, et les benchmarks qui ne citent que le contrôle de congestion ou la vitesse du lien omettent une bonne part de la mécanique.

Le pacing interne de TCP a réduit la dépendance à une qdisc spécifique

En 2017, Dumazet a publié le pacing interne dans TCP. La couche transport a gagné une plus grande capacité à retenir le trafic selon le débit et les minuteries, sans dépendre entièrement d’une discipline particulière.

La qdisc est restée pertinente pour l’ordonnancement et la politique. La logique s’est rapprochée du sous-système porteur de l’intention, mais l’émission finale est demeurée répartie entre TCP, l’ordonnanceur, le pilote et la NIC. Ce fut une évolution par couches, pas un remplacement complet.

La discipline de file reste une décision opérationnelle ayant un effet sur le service

Linux propose des qdiscs pour des objectifs distincts.sch_fqfavorise le pacing; FQ-CoDel associe la séparation par flux et la gestion active des files. Ils ne sont pas identiques.

Les valeurs par défaut varient selon la distribution et l’environnement. Les images cloud, les appliances et les hôtes de conteneurs peuvent choisir différemment, et le déport peut déplacer l’exécution. L’amont fournit le mécanisme; l’opérateur décide s’il façonne réellement le service.

Quelques octets par socket deviennent une contrainte de parc

Chaque connexion conserve des séquences, des minuteries, un état de congestion, des files et des compteurs. À grande échelle, chaque octet se multiplie et chaque champ fréquent occupe du cache.

Moins de mémoire par socket peut augmenter la densité; une meilleure disposition réduit les défauts et le trafic de cohérence. C’est le pont le plus solide vers l’économie des serveurs, mais cela ne permet pas de calculer un gain financier universel ni de valoriser personnellement le travail.

Une ligne de cache devient une infrastructure lorsqu’elle est touchée à chaque paquet

Le CPU déplace des lignes entières. Des données chaudes à côté de champs froids font circuler des octets inutiles; deux CPU modifiant la même ligne génèrent de la cohérence même en touchant des valeurs distinctes.

Le travail récent de Dumazet adopte cette lecture physique. Séparer les champs chauds et froids réduit le trafic mémoire qui croît avec les paquets et les sockets. Le gain dépend du processeur et de la charge; un profil de production ne peut pas devenir une loi universelle.

Le travail de 2024 sur les structures montre une phase mûre d’ingénierie de la performance

La présentation de 2024 a commencé par des profils: quels champs sont chauds, quelles lignes se déplacent et quelles structures dominent la mémoire. Les outils peuvent suggérer des réarrangements, mais ne remplacent pas la révision sur l’alignement, le verrouillage, la compatibilité et la maintenance.

Dans une infrastructure mûre, un grand gain peut venir de la suppression d’un défaut de cache ou du déplacement d’un champ, et non du lancement d’un nouvel algorithme. C’est moins visible, mais décisif à l’échelle.

Les profils hyperscale sont des preuves solides et une science publique incomplète

Les grands opérateurs voient des volumes et du matériel difficiles à reproduire. Ils peuvent détecter des coûts absents des microbenchmarks. L’affiliation de Dumazet à Google le place dans ce contexte.

Une partie des charges et des données reste privée. Une présentation peut montrer la méthode et la direction sans exposer toutes les entrées. Cela exige une qualification, pas un rejet. Le meilleur résultat est de transformer davantage d’observations privées en tests et charges de travail publics.

Verrous et files de réception font partie de la même histoire de ressources

Bien que l’axe soit la transmission, la trajectoire de Dumazet couvre aussi les sockets et le chemin de réception. Les paquets entrants exigent du polling, de l’allocation, de la classification, des files et une livraison entre CPU. À haut débit, les verrous et l’état partagé deviennent un coût.

Linux réduit cela en déplaçant le travail, en groupant les opérations et en diminuant la contention. Le principe est le même: utiliser une coordination suffisante pour la correction sans laisser la comptabilité consommer l’application.

Le regroupement augmente le débit et modifie la latence et l’équité

Regrouper les paquets ou les achèvements amortit les verrous, les appels et le cache. NAPI, les pilotes et les déports en dépendent.

Le lot attend pour se former et peut arriver en rafale. De grands lots augmentent l’efficacité et l’attente. TSQ, le fair queueing et le pacing ne combattent pas le regroupement; ils imposent des limites pour préserver le retour d’information et la latence.

La performance TCP émerge de couches qui peuvent s’annuler mutuellement

L’algorithme définit l’intention; TCP crée les paquets; TSQ limite l’arriéré; la qdisc ordonne; TSO regroupe; le pilote mappe; la NIC transmet; le réseau ajoute des files et des pertes.

Un pacing précis peut être défait par une segmentation grossière; une qdisc à faible latence, par un excès d’enfilement; une disposition compacte, par un nouveau verrou. Dumazet travaille sur ces coutures et améliore le chemin installé au lieu de l’ignorer.

La révision publique transforme une optimisation locale en infrastructure partagée

Une amélioration commence comme une affirmation de latence, de mémoire ou de CPU réduits. Pour entrer dans Linux, elle affronte netdev: méthodologie, abstraction générique, architectures rares, tests et coût futur.

Le mainteneur peut diviser la série, rejeter une interface de fournisseur ou reporter un correctif. C’est plus lent qu’un changement privé et plus durable. L’autorité de Dumazet consiste notamment à évaluer non seulement le résultat d’aujourd’hui, mais la maintenance de demain.

netetnet-nextséparent la réparation urgente du développement futur

Les corrections vont normalement versnet; les fonctions, versnet-next. Cela évite de mélanger la maintenance urgente avec les refactorisations de la prochaine version.

La frontière exige du jugement. Une correction peut modifier le comportement; une fonctionnalité peut révéler un ancien bug. Les mainteneurs divisent les séries pour expliciter le risque et empêcher qu’un calendrier commercial ne remplace la maturité technique.

Révision, rejet et refonte n’apparaissent pas dans les comptages de commits

Les commits mesurent la paternité visible, mais pas la phrase qui oblige à une refonte ni le rejet qui évite des années de coût. Appliquer un correctif signifie assumer l’intégration, pas inventer l’idée.

Le profil combine des mécanismes attribuables et une intendance. TSQ,sch_fq, le pacing et la disposition sont clairs, mais ne résument pas des décennies de révision et ne transforment pas tous les correctifs intégrés en création personnelle.

Les tests réduisent le risque sans représenter toute machine que Linux rencontrera

Les compilations, les autotests, KUnit, syzbot, les laboratoires et les branches aval détectent des régressions, mais ne couvrent pas tous les CPU, NIC, qdiscs et charges.

Une amélioration hyperscale peut nuire à un appareil rare. L’expérience, la compatibilité et la restauration restent nécessaires. Les tests renforcent la gouvernance; ils n’éliminent pas le jugement.

Les rétroportages stables exigent une seconde décision après la branche principale

Un correctif de la branche principale n’entre pas automatiquement dans toutes les branches stables. Il doit être une correction réelle, délimitée et sûre. Les distributions décident à nouveau.

Les changements de performance peuvent dépendre de code absent d’une ancienne branche. L’impact arrive par étapes: amont, stable, distribution, cloud et configuration. Personne ne contrôle toute la chaîne.

La maintenance actuelle de TCP et des sockets est délibérément partagée

MAINTAINERSrépartit le travail entre Dumazet, Neal Cardwell et d’autres relecteurs. Cela réduit la dépendance à une seule personne et combine les connaissances sur la congestion, les sockets, les pilotes et les tests.

La pluralité exige une propriété claire. Des domaines qui se chevauchent créent des lacunes si chacun attend l’autre. Une succession saine répartit l’autorité et préserve les raisons des décisions.

La Netdev Foundation peut financer sans devenir une autorité de fusion

La fondation, sous l’égide de la Linux Foundation, soutient l’intégration continue, les outils, les déplacements et la recherche. Dumazet participe au TSC. Une subvention ne garantit pas une fusion.

La distinction est saine: une maintenance approfondie coûte de l’argent, mais la légitimité amont vient de la preuve publique. Le financement doit augmenter la capacité de décision, pas acheter une exception.

L’affiliation à Google apporte une capacité sans propriété sur le TCP de Linux

L’adresse électronique Google prouve une affiliation, pas un poste complet. Un hyperscaler peut financer le profilage, le matériel et la révision qui profitent ensuite à tout l’écosystème.

L’asymétrie est que les charges de travail et les données ne sont pas entièrement publiques. La révision ouverte est le contrepoids: le correctif doit être générique et acceptable hors de Google. L’entreprise fournit du temps et des preuves; elle ne possède pas la pile.

Les opérateurs en aval décident si l’amélioration modifie le service

Les distributions choisissent les noyaux; les clouds, la qdisc et la congestion; les appliances, les versions; les fabricants, les capacités; les applications, le trafic. Il n’existe pas de recensement complet de l’usage de TSQ ou desch_fq.

Un mécanisme peut être présent et inactif, ou actif par défaut sans être remarqué. L’impact de Dumazet est large et indirect: il modifie l’ensemble commun d’options; chaque opérateur le convertit en expérience.

Les piles en espace utilisateur disputent des charges spécialisées, pas toute fonction de Linux

DPDK, VPP et les piles propriétaires évitent des parties du noyau pour obtenir un débit élevé, en échange de cœurs dédiés, de pages énormes et d’un modèle opérationnel séparé.

Linux intègre sockets, sécurité, espaces de noms, observabilité et pilotes. Le travail de Dumazet réduit le coût du chemin général sans affirmer qu’il est idéal pour tout. Le contournement sert des cas spécifiques; Linux reste la base large.

Linux demeure la norme parce que l’intégration vaut plus que la vitesse brute

Une pile doit être rapide, compatible, sûre, observable et maintenue. Un chemin isolé peut avoir plus de paquets par seconde et un coût opérationnel plus élevé.

Une application Linux hérite de TSQ, du pacing et de la comptabilité par sockets communs. Cette invisibilité est une force: le bénéfice demeure même lorsque l’utilisateur ignore le nom de l’auteur.

Un hôte plus rapide ne prouve pas que le chemin réseau s’est amélioré

Une file locale plus petite ne corrige pas un accès congestionné, une destination lente ou un routeur avec perte. TSQ et le pacing gouvernent l’émetteur, pas tout le chemin.

Ils peuvent réduire une source de retard et rendre le flux plus régulier. Ils ne garantissent pas le résultat applicatif. La performance de bout en bout continue de dépendre de l’application, du récepteur, de l’itinéraire et de la configuration.

Un benchmark ne représente pas tous les serveurs, NIC et charges de travail

La taille des paquets, les connexions, le CPU, le cache, la NIC, les déports, la qdisc, les minuteries, le noyau et la charge modifient le résultat. Un profil Google peut révéler un coût réel sans prédire un pourcentage sur un autre parc.

Une bonne communication préserve les conditions. Les présentations de Dumazet sont des preuves opérationnelles attribuées; des tests publics et des mesures indépendantes sont nécessaires pour généraliser.

La succession est un problème technique parce qu’une partie de la conception vit dans la mémoire

Des limites étranges peuvent exister à cause d’une ancienne NIC, d’une API encore utilisée ou d’une régression résolue il y a des années. Le code ne raconte pas toujours cette histoire.

Les mainteneurs chevronnés portent du contexte. La documentation, les tests, les fichiers et de nouveaux relecteurs transforment la mémoire privée en connaissance institutionnelle. La succession doit préserver les principes et permettre l’adaptation au matériel futur.

Le pacing matériel et la mémoire de périphérique peuvent déplacer à nouveau la frontière

Les NIC modernes programment les paquets, contrôlent les files et exposent de la télémétrie ou de la mémoire locale. Elles réduisent le CPU et déplacent le comportement vers le micrologiciel.

Linux doit exprimer l’intention, observer le résultat et se rétablir lorsque les modèles divergent. Les API de pilote, les horodatages et les erreurs deviennent aussi importants que le débit. Les principes demeurent: retour d’information, limite aux files cachées et observabilité.

L’économie de cache peut apporter plus de gains que de nouvelles formules de transport

De nouveaux algorithmes continueront d’apparaître, mais le prochain gain significatif peut venir d’une meilleure disposition, d’un verrou ou d’un lot. Il n’a pas de marque voyante et profite à plusieurs applications.

Le travail de 2024 montre une pile mûre évaluée par les coûts physiques. La question passe de « quel protocole gagne? » à « combien de machine chaque connexion consomme-t-elle? ».

La contribution durable de Dumazet est la discipline des ressources, pas un mythe héroïque

Une version exagérée en ferait l’inventeur du TCP moderne et de BBR; une autre effacerait l’individu dans la communauté. Les preuves permettent la précision.

Dumazet a introduit TSQ, signé un travail fondateur sursch_fq, développé le pacing interne et montré l’importance de la disposition. Il maintient aussi des domaines critiques dans un système partagé. Sa contribution consiste à traiter les paquets et les sockets comme des revendications sur le temps, la mémoire, la file et la localité CPU.

L’impact final se disperse entre conception, révision, intégration et exploitation. Un commit est attribuable; un parc plus dense ou une panne évitée ne l’est pas. Cette difficulté n’autorise ni l’exagération ni l’effacement: elle montre que la valeur d’une infrastructure naît d’une chaîne collective avec des décisions individuelles identifiables.