En bref

  • Le parcours de Greenberg relie la mesure du trafic des réseaux de télécommunications, les réseaux de centres de données à très grande échelle et l’architecture de la plateforme Uber; à chaque étape, le réseau est traité comme un système à mesurer et à contrôler comme un ensemble interconnecté.
  • L’architecture 4D, VL2, DCTCP, Ananta, SWAN et Pingmesh ont traité différentes couches de ce système, mais ce sont tous des projets collectifs dont l’impact en production ne peut être attribué à une seule personne.
  • Chez Uber, une étude de 2026 sur le basculement a fait état d’une utilisation accrue après le passage, pour certains services, d’une réserve uniforme de 2× à une planification différenciée proche de 1,3×, tout en maintenant une disponibilité de 99,97 % dans le système étudié.
  • Le test le plus durable de la contribution de Greenberg consiste à savoir si les boucles de contrôle qu’il a contribué à façonner peuvent résister à de nouveaux matériels, aux charges de travail d’IA, aux changements organisationnels et aux défaillances, sans perdre leur explicabilité ni leur capacité à rendre des comptes.

Un objectif de réserve de 1,3× rend l’architecture visible

Le meilleur point d’entrée dans le parcours d’Albert Greenberg n’est ni un intitulé de poste ni une récompense, mais une décision de capacité. Un article d’Uber présenté à NSDI 2026 a décrit un système de planification du basculement qui a fait passer certains services d’un modèle de réserve uniforme de 2× à une planification différenciée autour de 1,3×, et a signalé une meilleure utilisation tout en maintenant une disponibilité de 99,97 % dans le système étudié. Le résultat appartient à une vaste équipe d’auteurs et à l’architecture de production d’Uber, non à un seul dirigeant.

Mais il révèle la question qui accompagne depuis des décennies le travail de Greenberg: de combien de capacité de réserve, de contrôle et de mesure une plateforme a-t-elle besoin avant que la fiabilité ne devienne une propriété d’ingénierie plutôt qu’un simple espoir?

La question est plus difficile que ne le laisse penser le ratio. La capacité de réserve protège contre les pannes, mais elle consomme aussi du capital, de l’énergie et de l’espace. Sa réduction ne fonctionne que si les services sont correctement classés, les dépendances comprises, les chemins de basculement réellement indépendants et l’organisation capable de vérifier si le trafic s’est déplacé comme prévu. Un objectif de capacité n’est donc pas seulement une optimisation financière: il exprime aussi le degré de confiance que la plateforme place dans sa topologie, sa télémétrie, ses logiciels de contrôle et sa discipline opérationnelle.

Le rôle actuel de Greenberg chez Uber le place au plus près de ce problème, mais les sources publiques ne fournissent pas un intitulé unique et incontesté. Un profil publié en 2026 par ARCS Foundation le présente comme vice-président principal et directeur de l’architecture, tandis qu’une biographie d’événement publiée par University of Minnesota le décrit comme vice-président de l’ingénierie des plateformes. Les deux sources sont suffisamment crédibles sur le plan institutionnel pour que le désaccord reste visible au lieu d’être résolu silencieusement.

Plus important encore, elles s’accordent sur le fait que Greenberg est un haut responsable des plateformes et de l’architecture, avec un périmètre couvrant l’infrastructure, et non un chercheur travaillant sur un protocole isolé.

Cette vision systémique apparaît bien plus tôt dans son parcours. Chez AT&T et Bell Labs, le problème consistait à mesurer la demande et les anomalies dans un réseau d’opérateur dont l’état significatif ne pouvait être lu à partir d’un seul compteur. Chez Microsoft, il s’agissait de faire fonctionner l’infrastructure réseau des centres de données, le protocole de transport, le répartiteur de charge, le WAN et la télémétrie comme les composantes d’une même plateforme cloud.

Chez Uber, le contexte opérationnel a encore évolué vers des services de plateforme mondiaux, une infrastructure d’IA et une planification différenciée de la résilience. Les technologies ont changé, mais pas la discipline récurrente: observer le système dans son ensemble, expliciter les décisions de contrôle, les déployer en sécurité, puis mesurer si la réalité a suivi le modèle.

Les réseaux de télécommunications ont appris à Greenberg à mesurer avant de contrôler

Greenberg a obtenu en 1983 un doctorat en informatique à University of Washington après des études de mathématiques à Dartmouth College, puis a construit une grande partie du début de sa carrière dans la recherche sur les réseaux chez AT&T et Bell Labs. L’élément important n’est pas la succession des titres, mais la nature du système auquel il était confronté: le réseau dorsal en activité d’un opérateur, avec des clients, des protocoles, des pannes et des profils de trafic impossibles à interrompre pendant que les chercheurs tentaient de comprendre ce qui se passait à l’intérieur.

La planification d’un réseau dorsal dépend de matrices de trafic, d’indices de défaillance et d’une visibilité sur la demande à travers un grand nombre de routeurs. Les compteurs de liaison montrent la charge en un point, les tables de routage les chemins choisis et les enregistrements de flux apportent une autre vue partielle; aucun de ces éléments n’explique à lui seul le volume de trafic entre les points d’entrée et de sortie ni la manière dont une modification du routage transforme ce flux.

Les équipes d’AT&T ont développé des méthodes de mesure et d’ingénierie du trafic qui ont fait du réseau dorsal un objet d’ingénierie plus empirique. La documentation publique ne révèle pas tous les systèmes de production ni tous les jeux de données; l’affirmation défendable porte donc sur la méthode d’ingénierie, et non sur une liste exhaustive d’outils non publics.

Une matrice de trafic est utile parce qu’elle transforme de nombreux éléments dispersés en un modèle exploitable par les responsables de la capacité. Si le trafic augmente entre deux parties du réseau, l’opérateur peut demander si les chemins actuels suffisent, si une panne créerait un goulet d’étranglement ou si la politique de routage oriente la demande vers des liaisons inadaptées. L’estimation reste imparfaite.

L’échantillonnage, l’agrégation, les changements de routage et les applications chiffrées peuvent fausser l’interprétation; la mesure doit donc être associée à l’historique et au contexte opérationnel plutôt que traitée comme une vérité absolue.

Cette limite explique pourquoi la mesure est devenue davantage qu’une couche de compte rendu dans les travaux ultérieurs de Greenberg. Un système de contrôle ne peut optimiser les chemins sans disposer d’un modèle relativement fiable de la topologie et de la demande. Un répartiteur de charge ne peut distribuer les requêtes s’il ne connaît pas les services en aval et les chemins en bon état. Un planificateur de basculement ne peut réduire la capacité de réserve si les exercices et la télémétrie ne montrent pas ce qui se produit lorsqu’un site, une liaison ou un service disparaît.

La boucle récurrente est facile à décrire et difficile à exploiter: observer, décider, déployer, mesurer, puis réviser.

La chronologie documentée étaye cette évolution sans la transformer en récit de héros solitaire. Greenberg a obtenu son doctorat en 1983; Clean Slate 4D Approach to Network Control and Management a été publié en 2005, puis VL2 en 2009, centres de données TCP en 2010, Ananta et SWAN en 2013, et Pingmesh en 2015. Ses travaux chez AT&T et Bell Labs s’étendent des années 1980 au début des années 2000; Microsoft et Azure sont ensuite devenus son principal contexte institutionnel à partir de la fin des années 2000, avant qu’Uber ne devienne son contexte actuel dans les années 2020.

Chaque étape a introduit de nouveaux collaborateurs et de nouvelles contraintes de production. La continuité réside donc dans le problème systémique, non dans l’idée qu’une seule personne aurait transporté un plan complet d’une entreprise à l’autre.

L’architecture 4D a séparé le raisonnement de l’acheminement

L’architecture 4D, mise au point et publiée avec des collaborateurs au milieu des années 2000, a remis en cause un aspect familier de la gestion des réseaux centrée sur le routeur: chaque appareil combinait configuration locale, protocoles distribués et comportement d’acheminement, ce qui rendait difficile le raisonnement sur les politiques et les pannes à l’échelle de tout le réseau. L’approche divisait le contrôle en quatre plans: décision, diffusion, découverte et données.

La découverte rassemble les informations de topologie et d’état, la décision calcule les politiques et le contrôle à l’échelle du réseau, la diffusion propage l’état qui en résulte et le plan de données assure l’acheminement.

Le changement le plus important était la séparation elle-même. Dès lors que le raisonnement sur les politiques devenait une fonction logique indépendante, il devenait possible d’envisager un contrôleur disposant d’une vue d’ensemble du réseau sans centraliser physiquement l’acheminement. Une politique pouvait être vérifiée par rapport à un modèle plus large, puis l’état résultant pouvait être distribué de manière contrôlée. Cette architecture a précédé des idées ultérieurement associées aux réseaux définis par logiciel, mais elle ne doit pas être décrite comme l’origine unique du SDN.

Le domaine possède plusieurs filiations intellectuelles; les preuves permettent de considérer 4D comme un précurseur et une contribution influente, non comme une invention solitaire.

La séparation du contrôle isole certains risques tout en les déplaçant. Le service de décision peut tomber en panne ou agir à partir de données de découverte anciennes. La diffusion peut n’installer qu’une partie d’une modification. Un moteur de politiques logiquement centralisé peut propager une mauvaise décision plus vite qu’un grand nombre de routeurs faiblement coordonnés. Les protocoles hérités et les anciens appareils doivent également coexister pendant la transition.

L’architecture 4D n’a donc pas supprimé la complexité: elle en a rendu certaines parties plus visibles et a concentré une part de la responsabilité dans les logiciels et les processus opérationnels.

Cet arbitrage est devenu central dans les systèmes cloud ultérieurs. La question n’était plus de savoir s’il était possible de séparer le raisonnement réseau de l’acheminement, mais comment rendre ce raisonnement disponible, répliqué, observable et compatible avec des chemins de données distribués. Le déploiement progressif, le retour arrière, les contrôles d’état et la continuité de l’acheminement local deviennent importants parce que la vue plus large du contrôleur s’accompagne d’un rayon d’impact plus large.

Les travaux ultérieurs de Greenberg chez Microsoft ont traité ces questions au moyen de systèmes concrets plutôt que d’un plan de contrôle universel unique.

VL2 a fait du placement des services un problème de conception réseau

Lorsque Greenberg s’est fortement engagé dans les travaux de Microsoft sur les réseaux de centres de données, l’échelle et le modèle de défaillance ont changé. Les grands services en ligne voulaient pouvoir déplacer ou redistribuer les charges de travail sans reconcevoir le réseau autour de chaque emplacement de serveur, tandis que les réseaux hiérarchiques traditionnels pouvaient limiter la bande passante et lier étroitement les adresses à l’emplacement physique.

VL2, développé par une vaste équipe de Microsoft, associait une infrastructure Clos repliée, l’indirection d’adressage et la répartition de charge de Valiant afin de prendre en charge le placement des services et des profils de trafic difficiles à prévoir.

La finalité de service est l’élément le plus utile de cette idée. Les charges de travail doivent pouvoir conserver des identités de service stables tandis que l’infrastructure physique sous-jacente utilise une structure extensible de couche 3. Des mécanismes d’annuaire et de contrôle peuvent relier les adresses de service aux emplacements, tandis qu’une topologie Clos multichemin offre plusieurs parcours dans le centre de données. Le réseau passe ainsi d’un ensemble de couloirs fixes à une infrastructure dont la capacité peut être utilisée avec davantage de souplesse lorsque les services se déplacent.

La répartition de charge de Valiant ajoute un mécanisme contre-intuitif. Au lieu de tenter de prévoir le meilleur chemin de bout en bout pour chaque matrice de trafic, le trafic peut être distribué par des points intermédiaires choisis de manière pseudo-aléatoire afin qu’une demande inconnue ne domine pas toujours le même ensemble de liaisons. Un flux donné peut emprunter un chemin qui semble plus long, mais le comportement global du réseau devient plus prévisible sous des charges variées. Le mécanisme conserve des limites, notamment l’allongement des chemins, le déséquilibre du hachage, les flux éléphants et les pannes.

L’impact de VL2 doit être décrit comme une filiation conceptuelle, non comme un plan de production figé. Azure n’a pas mis en œuvre l’article de recherche à l’identique avant de cesser d’évoluer. Les générations de matériel, les réseaux virtuels, les logiciels hôtes, les systèmes de contrôle et les exigences opérationnelles ont continué à changer. L’affirmation la plus solide est que VL2 a contribué à établir un vocabulaire devenu central dans les réseaux à très grande échelle: infrastructures Clos, séparation de l’adresse et de l’emplacement, usage du multichemin et contrôle assisté par logiciel.

La même logique économique découle de l’architecture. Des infrastructures uniformes construites avec des équipements de commutation standard ou modulaires peuvent permettre une croissance plus progressive que des conceptions dépendant de quelques châssis massifs. Mais réduire la dépendance à un seul équipement ne supprime pas le coût: cela déplace les dépenses et les compétences vers les logiciels de contrôle, la télémétrie, l’automatisation et la gestion des défaillances. Un fournisseur cloud ne peut économiser sur une couche que s’il devient meilleur dans l’exploitation du système distribué qui la remplace.

DCTCP a fait de la congestion un problème commun aux commutateurs et aux hôtes

Le trafic d’un centre de données mélange des flux courts sensibles à la latence et des transferts volumineux. Le TCP classique peut accumuler de longues files d’attente avant de réduire la fenêtre d’émission, ce qui signifie que l’utilisation de la liaison peut rester élevée tandis que les tâches courtes attendent derrière des paquets accumulés. DCTCP, également issu d’un travail collectif, utilisait la notification explicite de congestion lorsqu’un faible seuil de file d’attente était atteint dans les commutateurs, puis ajustait l’émetteur selon la proportion de paquets marqués.

L’objectif était de maintenir des files courtes sans sacrifier le débit.

Le résultat essentiel est que le contrôle de congestion devient une boucle coordonnée entre les appareils réseau et les points de terminaison. Les commutateurs ont besoin de seuils de marquage adaptés au déploiement, et les hôtes d’un comportement de contrôle de congestion compatible. La composition du trafic, la topologie et le matériel influencent le résultat. Un seuil mal choisi ou un déploiement mixte peut modifier l’équité et la latence; DCTCP n’est donc pas un simple algorithme qu’un serveur isolé peut activer.

Ces travaux ont contribué à faire de la congestion des centres de données un problème opérationnel distinct. L’Internet public comprend de longs chemins, des opérateurs variés et des points de terminaison qui ne relèvent pas d’une autorité unique, tandis qu’un fournisseur cloud peut généralement contrôler ensemble serveurs et commutateurs. Ce périmètre administratif ouvre la voie à des mécanismes difficiles à coordonner mondialement. Il crée aussi des obligations pour la plateforme: les versions des points de terminaison, les réglages des commutateurs et la télémétrie doivent évoluer ensemble, faute de quoi la boucle de contrôle dérive.

Les limites restent importantes, car des systèmes ultérieurs poursuivent ou étendent le même objectif. De nouveaux algorithmes de contrôle de congestion, des infrastructures plus rapides et des conceptions différentes de mémoire tampon ne suppriment pas la question: où les files se forment-elles, comment les points de terminaison en sont-ils informés et quelle équipe maîtrise la configuration? La contribution de Greenberg s’inscrit dans un portefeuille de recherche et d’ingénierie qui a traité à plusieurs reprises ces dépendances entre couches comme le véritable problème.

Ananta, SWAN et Pingmesh ont fermé différentes parties de la boucle

La topologie et le transport ne représentaient qu’une partie du problème des réseaux cloud. Les services avaient besoin d’un trafic entrant extensible, les centres de données devaient partager la capacité du réseau étendu et les opérateurs avaient besoin de preuves suffisantes pour distinguer une panne réseau du symptôme d’une application. Les équipes de Microsoft ont traité ces questions au moyen de systèmes tels qu’Ananta, SWAN et Pingmesh, chacun avec sa propre équipe d’auteurs et ses propres limites de déploiement.

Ananta a traité la répartition de charge de couche 4 à l’échelle du cloud. Au lieu de concentrer le traitement des paquets dans un équipement unique, son architecture a distribué le traitement, la gestion des routes et le contrôle des services sur un grand nombre de machines. Le chemin de données peut ainsi évoluer horizontalement, mais de nouvelles exigences apparaissent en matière d’état, de cohérence, de santé des services en aval et de gestion des pannes. Le répartiteur de charge cesse d’être un équipement à la périphérie du réseau pour devenir un service d’infrastructure.

SWAN a appliqué une optimisation logiquement centralisée au WAN. Les liaisons entre centres de données sont coûteuses, la demande varie et les pannes peuvent supprimer brutalement de la capacité. Un contrôleur doté d’une vue large peut attribuer les chemins selon la priorité des services et l’état du réseau, détourner le trafic de la congestion et utiliser plus délibérément les rares liaisons longue distance. Cette même vue centralisée crée un risque lorsque les estimations de la demande sont erronées, les mises à jour peu sûres ou le contrôleur coupé d’une partie du réseau.

Pingmesh a attaqué un autre problème: la visibilité. Le système a créé des agents et recueilli des mesures de latence et de perte de paquets à travers un vaste parc, formant un maillage continu de preuves synthétiques. Une liaison peut être déclarée active tout en offrant un chemin médiocre, et un service peut tomber en panne à cause d’un segment réseau dont aucune équipe n’est clairement propriétaire. La mesure à l’échelle du parc fournit aux opérateurs une référence commune pour ces incidents, même si les sondes synthétiques ne reproduisent pas tous les chemins, toutes les files ni toutes les dépendances des applications.

Ces trois systèmes sont particulièrement utiles lorsqu’ils sont lus ensemble, car ils montrent pourquoi le parcours de Greenberg ne peut être réduit à un article célèbre sur la topologie. Ananta relie le trafic des services aux ressources, SWAN attribue la capacité du WAN et Pingmesh mesure si les chemins se comportent comme prévu. DCTCP gère le retour d’information sur les files au sein de l’infrastructure, tandis que VL2 fournit une conception de cette infrastructure. La fiabilité naît de l’interaction entre ces mécanismes; l’attribution doit donc rester collective.

Azure Networking est devenu un système d’exploitation autour de ces mécanismes

Lorsque Greenberg occupait d’importantes fonctions de direction au sein d’Azure Networking, le défi central n’était plus de savoir si un article fonctionnait dans une expérience particulière. Azure devait exploiter les infrastructures physiques, les réseaux virtuels, les répartiteurs de charge, les passerelles, le WAN, la télémétrie et les systèmes de déploiement comme un seul service cloud. Les clients attendaient isolation, programmabilité et disponibilité sans devoir comprendre le matériel ni les processus de contrôle sous-jacents.

Les réseaux virtuels rendent cette abstraction concrète. Le client voit des adresses, des routes, des règles de sécurité et des points de terminaison de service, tandis que le cloud traduit cette configuration souhaitée en règles pour des hôtes, des commutateurs et des passerelles mutualisés. Le plan de contrôle doit absorber des changements rapides sans permettre à la configuration d’un client d’affecter celle d’un autre.

Le plan de données doit continuer à acheminer les paquets à grande vitesse, tandis que les API, les journaux d’audit, les mécanismes de retour arrière et la cohérence régionale font du réseau un problème de cycle de vie logiciel autant qu’un problème d’acheminement.

Ce cycle de vie change le sens de l’architecture. La mise en production d’une fonctionnalité peut modifier le routage ou le comportement de sécurité pour un grand nombre de clients. Une panne du plan de contrôle peut empêcher de nouvelles configurations tandis que les flux existants continuent. Une lacune de télémétrie peut donner l’impression que l’infrastructure est saine alors que les utilisateurs subissent une panne. Les responsables de la capacité doivent planifier simultanément la croissance ordinaire et le basculement régional.

L’organisation d’ingénierie fait ainsi partie du contrat de service, car les clients ne peuvent ni voir la majeure partie du système caché ni la réparer eux-mêmes.

La conférence plénière de SIGCOMM en 2015 est importante dans ce contexte parce qu’elle présentait le réseau cloud comme un portefeuille de systèmes interconnectés plutôt que comme la recherche d’une infrastructure finale unique. Topologie, transport, virtualisation, répartition de charge, ingénierie du trafic WAN, supervision et opérations doivent rester cohérents pendant que la plateforme évolue. Ce cadrage est plus durable que n’importe quel détail d’implémentation et correspond au parcours de Greenberg à travers plusieurs équipes.

L’autorité officielle de Greenberg chez Microsoft étaye l’affirmation d’un rôle de direction, mais ne prouve pas une propriété individuelle de la technologie. Les sources publiques le présentent comme vice-président d’entreprise et expert technique d’Azure Networking; des documents historiques d’AT&T mentionnent également des fonctions importantes, dont celles de directeur exécutif et de Fellow d’AT&T selon les périodes. Les systèmes fondamentaux associés à ces institutions portent de longues listes de coauteurs et d’ingénieurs de production.

L’attribution la plus solide se fait donc projet par projet: nommer le travail collectif, préciser l’employeur comme cadre de production et limiter les affirmations personnelles à la direction architecturale et aux contributions documentées.

Le leadership s’exerce entre les équipes, non par une invention isolée

Le parcours de Greenberg attire un type de raccourci qui peut facilement transformer l’histoire des systèmes en récit de héros solitaire. La version la plus prudente est aussi plus intéressante. VL2, DCTCP, Ananta, SWAN, Pingmesh et les travaux d’Uber sur le basculement ont été construits par des équipes. L’architecture 4D est née d’une communauté de recherche comprenant de nombreux contributeurs. Le réseau Azure a également évolué pendant des années grâce au travail sur les produits et les opérations, qu’aucun article ni aucune biographie de dirigeant ne peut résumer.

Les sources publiques montrent néanmoins une continuité inhabituelle entre ces équipes. Greenberg est passé de la mesure des réseaux d’opérateurs à une architecture de contrôle repensée de fond en comble, puis aux réseaux de centres de données à très grande échelle et à la direction d’une plateforme cloud, avant de rejoindre l’organisation de plateforme d’Uber. Son influence est donc à la fois technique et organisationnelle: il apparaît régulièrement dans des travaux demandant comment mesurer l’état de tout un réseau, où placer le contrôle, comment attribuer le trafic et comment les équipes doivent traiter les défaillances.

Les distinctions reflètent cette ampleur, mais elles ne doivent pas remplacer les preuves propres aux projets. Greenberg a reçu l’ACM SIGCOMM Award et l’IEEE Koji Kobayashi Computers and Communications Award en 2015, a été élu membre de US National Academy of Engineering en 2016 et est Fellow de l’ACM. Ces distinctions étayent la conclusion selon laquelle le domaine considère ses travaux comme influents. Elles ne prouvent ni une invention solitaire, ni une autorité opérationnelle actuelle, ni la filiation précise de production d’un système donné.

Le désaccord sur son titre chez Uber rappelle utilement la même discipline. Un profil publié en 2026 par ARCS Foundation le présente comme vice-président principal et directeur de l’architecture, tandis que des documents de University of Minnesota couvrant la période 2025-2026 le décrivent comme vice-président de l’ingénierie des plateformes. Plutôt que d’en choisir un et de rendre les sources plus ordonnées qu’elles ne le sont, il faut dater les documents et décrire leur terrain commun: Greenberg occupe une fonction importante dans les plateformes et l’architecture, mais ses droits de décision internes ne sont pas entièrement publics.

Son intitulé RH actuel reste un point à vérifier, non une raison d’affaiblir les preuves plus larges sur ses responsabilités.

C’est important parce que l’architecture est aussi une répartition de l’autorité. Un architecte en chef ou un dirigeant de plateforme peut établir des principes communs, imposer des revues, approuver des mécanismes mutualisés ou influencer la politique de capacité; il ne contrôle pas personnellement chaque commutateur et n’écrit pas chaque service de contrôle. Les équipes réseau, les équipes de service, les ingénieurs de sécurité, les responsables de la capacité, les fonctions financières et les dirigeants conservent des droits de décision distincts.

La valeur du leadership architectural consiste à aligner ces droits sur un modèle de défaillance commun, non à prétendre qu’ils se fondent tous dans une seule personne.

Uber applique la même discipline à un profil de demande différent

L’infrastructure d’Uber dessert la mobilité, la livraison et d’autres services dont l’utilisation et la demande de calcul varient fortement selon la zone géographique et l’heure. Des biographies officielles relient les responsabilités de Greenberg aux centres de données, au calcul, aux réseaux, au stockage, aux données, à la recherche, à la supervision, à la productivité des développeurs, à l’informatique d’entreprise et à l’infrastructure prenant en charge l’IA et les véhicules autonomes.

Cette ampleur établit le contexte de la plateforme, mais ne prouve pas qu’il ait personnellement conçu chaque système mentionné ni les modèles applicatifs qui s’exécutent au-dessus.

Le problème opérationnel diffère de celui du cloud public parce qu’Uber contrôle son propre portefeuille d’applications tout en exploitant des services mondiaux en temps réel et de vastes systèmes de données internes. Les choix de réseau, de stockage et de calcul interagissent avec la fiabilité des services, les charges d’apprentissage automatique et les opérations régionales.

L’architecture de plateforme doit donc décider quelles infrastructures sont mutualisées, quels domaines de défaillance peuvent réellement être traités comme indépendants et comment les équipes applicatives utilisent les services communs sans reconstruire chacune les mêmes mécanismes.

L’étude de 2026 sur le basculement transforme ce problème en exemple mesurable. Faire passer certains services d’une capacité uniforme de 2× à une planification différenciée proche de 1,3× ne peut libérer de l’infrastructure que si le modèle sous-jacent est juste. La disponibilité de 99,97 % concerne le système et la période décrits chez Uber; elle ne doit pas être généralisée à tous les services d’Uber ni à d’autres entreprises.

L’intérêt du résultat est de rendre visible l’arbitrage géré: réduire la capacité de réserve peut améliorer l’utilisation, mais exige une meilleure classification, une cartographie plus précise des dépendances, une télémétrie plus fiable et des répétitions régulières.

Il s’agit d’une boucle de contrôle économique autant que technique. Les machines de réserve, les chemins réseau, l’énergie et la capacité des centres de données ont tous un coût d’opportunité. Une plateforme capable de distinguer les services selon leurs exigences en cas de panne peut nécessiter moins de réserve inutilisée qu’une plateforme traitant toutes les charges de travail de la même façon. Les gains ne sont pas réels si une panne révèle un couplage caché entre des zones ou des services supposés indépendants; les tests et l’apprentissage après incident deviennent donc une composante du dossier économique lui-même.

Les charges actuelles d’IA et de véhicules autonomes rendent ces décisions plus aiguës. L’entraînement et l’inférence peuvent produire d’importants flux est-ouest, exercer une pression sur le placement des accélérateurs et rendre les latences de longue traîne plus sensibles. Les données issues des véhicules et de la mobilité ajoutent aussi des exigences de stockage, de transfert et de traitement régional. Les biographies disponibles rendent ces domaines pertinents pour le rôle de Greenberg dans la plateforme, mais elles ne permettent pas d’affirmer qu’il conçoit des modèles d’IA ou des logiciels de conduite autonome.

L’affirmation plus étroite est la plus solide: la plateforme doit transporter, protéger et restaurer les données dont dépendent ces applications.

La fiabilité est une décision d’allocation, pas un attribut

Les organisations de cloud et de plateforme décrivent souvent leurs systèmes comme résilients, hautement disponibles ou tolérants aux pannes. Mais ces qualificatifs cachent des allocations de capacité, de géographie, de complexité logicielle et de temps de travail. Une infrastructure réseau offre un certain niveau de diversité des chemins; un WAN dispose d’une certaine capacité de réserve; un répartiteur de charge possède un état et un modèle de défaillance donnés; un système de télémétrie surveille certains chemins et pas d’autres. La fiabilité résulte de ces choix: elle n’est pas conférée par la formulation d’un document de conception.

Un contrôle centralisé ou logiquement centralisé peut améliorer ces allocations grâce à une vue large. SWAN peut coordonner la capacité du WAN plus délibérément que des décisions locales indépendantes, et un contrôleur de réseau virtuel peut appliquer une politique cohérente à de nombreux hôtes. La contrepartie est la concentration. Une mauvaise politique, un état corrompu ou un déploiement défectueux peut rapidement affecter une plus grande part du réseau.

La centralisation ne devient donc convaincante qu’avec la réplication, le déploiement progressif, le retour arrière et la capacité de l’acheminement local à survivre à certaines interruptions du contrôle.

Le même principe vaut pour la capacité. Une réserve uniforme de 2× est simple à expliquer, mais peut être coûteuse. Une réserve différenciée peut améliorer l’utilisation tout en accroissant la dépendance à la précision de la classification des services et de la modélisation des pannes. Aucune de ces valeurs n’est intrinsèquement prudente. Le choix dépend de ce qui tombe en panne simultanément, de la vitesse à laquelle le trafic peut être déplacé, des services capables de tolérer une dégradation et du niveau d’incertitude que l’organisation accepte de financer.

La revue d’architecture devient ainsi une répartition du pouvoir autant qu’un choix technique. Les équipes de service décrivent leurs besoins en latence et en disponibilité. Les équipes réseau et plateforme choisissent les mécanismes mutualisés. Les responsables de la capacité et la finance déterminent le volume de réserve financé. Les équipes de sécurité définissent les exigences d’isolation. Les dirigeants fixent la tolérance au risque.

Un architecte peut créer un langage commun et exiger que les conceptions locales s’inscrivent dans un modèle cohérent, mais il ne peut supprimer les incitations et les responsabilités distinctes qui façonnent un système de production.

Les travaux de Greenberg offrent un test utile à ces revues: la conception ferme-t-elle la boucle entre demande, décision, acheminement et preuves? VL2 a traité le placement et la topologie. DCTCP a traité le retour d’information sur les files d’attente. Ananta et SWAN ont attribué le trafic. Pingmesh a fourni une observation continue. Azure et Uber ont transformé ces mécanismes en systèmes organisationnels. Le réseau ne se comporte comme un ordinateur distribué que lorsque ces boucles restent cohérentes pendant le changement.

Le portefeuille est plus large que sa catégorie la plus connue

Greenberg est souvent fortement associé aux réseaux de centres de données, mais son parcours couvre plusieurs types de travaux qui ne doivent pas être comprimés dans une seule catégorie. La mesure du trafic des réseaux d’opérateurs a rendu la demande et les anomalies visibles. L’architecture 4D a séparé conceptuellement les fonctions de contrôle. VL2 a traité la topologie de l’infrastructure et le placement des services. DCTCP a contrôlé les files grâce au retour d’information entre points de terminaison et commutateurs.

Ananta a traité le trafic entrant des services, SWAN l’allocation à grande distance et Pingmesh l’observabilité à l’échelle du parc. Les réseaux virtuels d’Azure ont ensuite placé plusieurs de ces idées dans une plateforme cloud destinée aux clients.

Chaque couche possède des utilisateurs et des preuves différents. La mesure des réseaux d’opérateurs sert surtout les opérateurs et les responsables de la planification, tandis qu’une grande partie des détails de production reste non publique. L’architecture 4D est une conception de recherche, dont l’influence est plus conceptuelle qu’elle ne constitue la preuve d’un déploiement mondial unique. VL2 et DCTCP disposent de mécanismes publiés et d’évaluations publiques, mais les systèmes de production qui leur ont succédé ont évolué au sein de Microsoft.

Ananta, SWAN et Pingmesh décrivent pour leur part des services de plateforme avec des équipes, des dépendances et des limites différentes.

Le fil conducteur n’est pas un produit unique, mais une série de mécanismes qui rendent différentes décisions explicites. La mesure du trafic estime la demande. L’architecture de contrôle définit où réside le raisonnement sur les politiques. L’infrastructure fournit les chemins. Le contrôle de congestion régit leur utilisation par les points de terminaison. La répartition de charge relie le trafic des services aux ressources. L’ingénierie du WAN attribue la rare capacité entre sites. La télémétrie révèle si le résultat correspond aux attentes.

Une fonction de direction architecturale coordonne ensuite les organisations chargées de maintenir ces boucles.

Cette distinction est utile pour comparer les travaux de Greenberg aux systèmes voisins. VL2 appartient à une filiation comprenant les infrastructures Clos, PortLand, SEATTLE, Google Jupiter et d’autres architectures de centres de données. DCTCP relève de la recherche sur le contrôle de congestion. SWAN appartient à l’ingénierie du trafic à grande distance, et Pingmesh à l’observabilité. Les réseaux définis par logiciel et OpenFlow forment une filiation parallèle du contrôle programmable.

Des répartiteurs de charge commerciaux et des produits d’observabilité réseau peuvent résoudre des problèmes proches avec des modèles de produit et d’exploitation différents.

La comparaison n’a pas pour but de classer les personnes ni de déclarer une architecture gagnante. Google Jupiter et B4, les infrastructures de centres de données de Meta, les produits Clos et leaf-spine commerciaux, les travaux de SDN de l’époque OpenFlow, les répartiteurs de charge sous forme d’équipements ou de services gérés et les fournisseurs d’observabilité résolvent tous des problèmes de contrôle qui se chevauchent, dans des cadres institutionnels différents.

Un équipement fourni par un prestataire peut simplifier une tâche opérationnelle en concentrant la responsabilité dans un produit, tandis qu’une plateforme cloud peut intégrer davantage de couches parce qu’elle contrôle les hôtes, les commutateurs et les logiciels. Une architecture de recherche peut révéler une abstraction utile sans prouver que l’organisation nécessaire à son exploitation sera facile à construire.

Les systèmes relient les groupes de recherche, les fournisseurs et les opérateurs

Les travaux de Greenberg s’inscrivent dans un réseau d’institutions plutôt que dans une organisation unique et continue. AT&T Labs a fourni l’environnement de recherche d’un opérateur où la mesure du trafic et la gestion du réseau sont devenues des questions centrales. Microsoft Research et Azure ont relié la recherche sur les centres de données à la production à très grande échelle. Uber fournit le contexte actuel de plateforme.

Dartmouth College et University of Washington appartiennent à sa formation universitaire, tandis qu’ACM SIGCOMM, IEEE et National Academy of Engineering font partie du parcours professionnel ayant reconnu ces travaux.

Ces relations n’ont toutefois pas la même signification. La relation d’emploi définit un contexte institutionnel, mais ne prouve pas la propriété personnelle de l’infrastructure. La qualité de coauteur prouve une participation à un résultat de recherche, mais ne donne pas le contrôle exclusif de sa mise en œuvre en production. Une distinction atteste une reconnaissance par les pairs, mais ne décrit pas l’état actuel d’un système. Une conférence ou une communauté d’architecture peut démontrer une influence et un échange de connaissances sans établir de relation commerciale.

La distinction devient plus importante dans les infrastructures à très grande échelle, car de nombreux détails de production ne sont pas publics. Les articles révèlent des mécanismes, des hypothèses et certaines mesures, mais un fournisseur cloud peut modifier le matériel, les logiciels de contrôle et les pratiques opérationnelles après publication. Un article peut donc établir ce qu’une équipe a construit et évalué à un moment donné sans décrire intégralement le réseau actuel d’Azure ou d’Uber.

La même prudence vaut pour les descriptions de fonctions actuelles. Un titre élevé indique une autorité formelle, mais les droits de décision internes sont rarement publics. Les communautés d’architecture, les revues de conception et les organisations de plateforme peuvent créer une forte autorité informelle en définissant des interfaces, des modèles de défaillance ou des processus de déploiement qui deviennent des pratiques communes. Les preuves étayent le rôle de Greenberg comme dirigeant au sein de ces mécanismes, mais ne révèlent pas tous ses droits de veto, liens hiérarchiques ou pouvoirs budgétaires.

La version la plus solide du profil est donc celle qui maintient les collaborateurs visibles. Les coauteurs de VL2, DCTCP, Ananta, SWAN, Pingmesh et des travaux d’Uber sur le basculement doivent rester dans le récit technique, tandis que les employeurs restent dans le récit de production. L’importance individuelle de Greenberg vient de la continuité des questions architecturales à travers ces contextes, non de l’effacement des équipes qui y ont répondu.

Le financement et la géographie bornent ce qui peut être affirmé

Les travaux de Greenberg ont été financés en grande partie par les organisations de recherche et d’ingénierie qui l’employaient. Les éléments disponibles n’étayent aucun modèle personnel de revenus, aucune estimation de participation au capital ou de patrimoine net, ni aucune attribution financière auditée au niveau d’un produit. Des titres élevés et des systèmes influents ne suffisent pas à estimer sa rémunération ni à attribuer les revenus d’Azure ou d’Uber à un seul architecte.

Les articles sur des systèmes de production peuvent publier des mesures d’efficacité ou de disponibilité, comme l’illustre l’étude d’Uber sur le basculement. Ces chiffres appartiennent au système et à l’équipe d’auteurs cités, avec les hypothèses propres à l’architecture et à la période concernées. Ils ne doivent être transformés ni en économies à l’échelle de l’entreprise sans publication financière, ni en affirmation sur les performances personnelles de Greenberg. Les citations et les distinctions mesurent également la reconnaissance, pas les revenus.

Sur le plan géographique, la formation de Greenberg et ses principaux employeurs se situent aux États-Unis, tandis que l’infrastructure concernée s’étend au monde entier. La recherche sur le réseau dorsal d’AT&T, les régions Azure et l’empreinte des services d’Uber font face à des contraintes différentes de capacité, de réglementation et de défaillance. Un principe de conception valable dans plusieurs contextes ne signifie pas que chaque région utilise un matériel, une topologie ou une politique de réserve identiques.

Cette portée mondiale devient encore plus importante dans le contexte actuel de l’IA et de la mobilité. L’entraînement, l’inférence, le stockage et les données de parc dépendent de centres de données, de réseaux et de chaînes d’approvisionnement qui traversent les régions, même si la direction architecturale est établie dans un seul pays. Les sources publiques ne révèlent pas chaque topologie ni chaque relation fournisseur.

Il faut donc s’en tenir à l’affirmation la plus solide: les travaux de Greenberg concernent une infrastructure dont les conséquences opérationnelles dépassent les institutions où la recherche a été publiée pour la première fois.

Le contre-argument: le contrôle intégré peut aussi intégrer les défaillances

Le meilleur argument contre cette architecture se trouve dans ce qui la rend attrayante. Une vue d’ensemble du réseau peut mieux coordonner les politiques, la capacité et la reprise qu’un ensemble d’appareils isolés, mais elle peut également donner à une seule erreur logicielle un rayon d’impact beaucoup plus large. L’architecture 4D l’a rendu clair sur le plan conceptuel, et les systèmes cloud ultérieurs ont dû l’affronter en production: lorsque le contrôle est séparé et logiquement centralisé, le contrôleur, ses données d’entrée et son mécanisme de déploiement deviennent des infrastructures critiques.

La télémétrie ne supprime pas ce problème parce que l’observation reste incomplète. Pingmesh peut créer une solide référence de latence et de perte, mais les sondes synthétiques ne représentent pas chaque chemin d’application ni chaque file. Les matrices de trafic peuvent estimer la demande, mais elles sont affectées par l’échantillonnage et les changements de route. La corrélation entre les signaux du réseau, des hôtes et des services peut réduire le périmètre d’une panne sans prouver sa cause première. Un système qui accorde trop de confiance à sa télémétrie peut automatiser une mauvaise interprétation plus vite qu’une équipe humaine.

L’optimisation de la capacité présente une asymétrie similaire. De meilleurs modèles peuvent réduire le gaspillage, comme le suggèrent les travaux d’Uber sur le basculement, mais la valeur d’une réserve plus faible dépend d’hypothèses sur l’indépendance et la reprise. Si deux zones partagent une dépendance cachée, un modèle qui les considère comme indépendantes peut réduire la capacité nécessaire face à une panne réelle. Plus la plateforme optimise agressivement ses ressources de réserve, plus elle doit tester les scénarios dont dépendent les économies.

L’écart entre recherche et production crée une autre source d’erreur. Une architecture publiée est un instantané avec une liste d’auteurs, une charge de travail et une méthode d’évaluation connues. Les systèmes de production, eux, combinent des révisions matérielles, des migrations logicielles, des couches de compatibilité, des exceptions d’urgence et des pratiques organisationnelles qui peuvent ne jamais être publiées.

Traiter VL2 comme l’architecture Azure actuelle ou l’étude d’Uber de 2026 comme une politique permanente pour tous les services transforme donc des preuves sur un système précis en affirmation que ces preuves ne soutiennent pas.

La version individuelle du même risque est la personnalisation excessive. Le parcours de Greenberg est exceptionnellement vaste, ce qui rend tentant de lui attribuer toute une trajectoire allant du contrôle défini par logiciel à l’infrastructure moderne d’IA. Les preuves ne le permettent pas. Il n’a pas été l’unique auteur des grands systèmes, ne possède pas personnellement les infrastructures d’AT&T, de Microsoft ou d’Uber et ne peut être décrit comme le concepteur de modèles applicatifs ou de logiciels de conduite autonome au seul motif que les biographies de la plateforme mentionnent ces charges de travail.

Ces limites ne réduisent pas sa contribution; elles la définissent avec davantage de précision. L’influence de Greenberg réside dans l’aide apportée à la conception et à la direction de systèmes qui traitent le comportement du réseau comme une combinaison de topologie, de transport, de contrôle, de mesure et de réponse organisationnelle. Le contre-argument est que chaque couche supplémentaire d’intégration crée une nouvelle dépendance susceptible de tomber en panne, de dériver ou de devenir difficile à vérifier de l’extérieur.

Les matrices de trafic ont fait du réseau un objet d’ingénierie

Les réseaux d’opérateurs produisent une immense quantité de preuves opérationnelles sans offrir une description simple de la demande. Un compteur de liaison peut montrer qu’une interface est saturée, mais il n’explique pas quelles demandes de bout en bout ont produit la charge ni ce qui se passerait si un autre chemin tombait en panne. Les enregistrements de flux, les tables de routage et l’historique des performances apportent chacun une vue partielle. Une matrice de trafic tente de combiner ces vues dans un modèle estimant le volume de demande entre les points d’entrée et de sortie.

Pour les responsables de la capacité, ce modèle change les questions qu’il est possible de poser. Une liaison surchargée peut être un problème local, le résultat d’une politique de routage ou le signe d’une croissance structurelle ailleurs. Une maintenance planifiée peut être sûre sous une demande ordinaire et dangereuse lors d’un pic corrélé. Les estimations à l’échelle du réseau permettent aux ingénieurs de tester ces possibilités avant de s’engager dans une nouvelle capacité ou une nouvelle politique de routage.

L’estimation reste conditionnelle parce que les données réseau sont incomplètes. L’échantillonnage peut manquer des rafales, l’agrégation masquer des flux individuels et le chiffrement limiter l’interprétation au niveau des applications. Un changement de route peut déplacer le trafic assez vite pour que la matrice de demande de la veille devienne un mauvais indicateur du risque présent. La valeur opérationnelle vient de la comparaison, dans le temps, de plusieurs signaux imparfaits, non de l’attente d’un système de mesure unique fournissant une réponse définitive.

Cette approche empirique sous-tend les travaux ultérieurs sur le cloud. VL2 a besoin d’une visibilité sur la demande pour distribuer les flux dans l’infrastructure. SWAN a besoin de prévisions et de l’état actuel pour attribuer la capacité du WAN. Une planification différenciée du basculement a besoin de preuves sur les dépendances des services et leur comportement de reprise. Les mécanismes diffèrent, mais chacun transforme des observations en un modèle qui peut être modifié lorsqu’il ne correspond plus à la réalité.

Une infrastructure réseau n’est utile que si son contrôle peut évoluer en sécurité

Les topologies Clos repliées sont devenues attrayantes pour les centres de données à très grande échelle parce qu’elles offrent plusieurs chemins entre les serveurs et le reste de l’infrastructure, tout en rendant l’expansion plus modulaire. VL2 a associé cette structure physique à l’indirection d’adressage et à la distribution du trafic afin que les services puissent se déplacer sans rester contraints par une hiérarchie d’emplacements rigide. L’architecture visait à offrir aux applications une connectivité large et uniforme, même si le réseau sous-jacent restait un ensemble distribué de commutateurs et de liaisons.

Cette abstraction déplace la responsabilité vers les logiciels de contrôle. Le système doit relier les identités de service aux emplacements, choisir ou distribuer le trafic entre les chemins et réagir aux pannes de liaison ou de commutateur. Si ces mécanismes sont périmés ou incohérents, l’infrastructure peut disposer d’une grande bande passante brute tout en fournissant un service médiocre. La topologie constitue donc une ressource de capacité, non une garantie de fiabilité.

Il en va de même pour les réseaux virtuels. Les clients voient un réseau programmable, tandis que le fournisseur traduit leur configuration souhaitée en règles d’hôte, routes, tunnels, passerelles et capacité physique mutualisée. Les modifications doivent être versionnées et déployées en sécurité parce que le client ne voit pas l’état caché. Un défaut du plan de contrôle peut affecter les nouvelles configurations tandis que les flux existants du plan de données continuent, donnant à l’incident des symptômes différents selon le moment où une charge de travail a été créée ou déplacée.

L’architecture devient ici un contrat opérationnel. L’équipe de plateforme retire la complexité aux équipes applicatives et accepte en échange la responsabilité de la compatibilité, de l’observabilité et de la reprise. Les abstractions mutualisées peuvent accélérer l’organisation, mais seulement si les équipes qui les exploitent savent expliquer leurs limites et fournir une voie de contournement lorsque l’abstraction échoue.

Le contrôle de congestion montre pourquoi les frontières entre équipes font partie de la conception

DCTCP est un exemple utile parce que son mécanisme traverse une frontière que les organisations traitent souvent comme une séparation. Les commutateurs marquent les paquets lorsque les files dépassent un seuil, tandis que les points de terminaison ajustent leur comportement d’émission selon la proportion de marques. Aucun des deux côtés ne peut produire seul le résultat voulu. L’équipe réseau et l’équipe chargée des hôtes ou du système d’exploitation doivent s’accorder sur le comportement, les seuils, le déploiement et la mesure.

À l’échelle d’un centre de données, ces accords ne sont pas des choix de configuration ponctuels. Les générations de matériel peuvent modifier la mise en mémoire tampon. Les images des hôtes peuvent introduire un code de transport différent. Les charges de travail peuvent passer de courtes interactions requête-réponse à de volumineux transferts de stockage ou à des échanges liés à l’IA. Un réglage efficace pour une composition donnée peut créer de l’iniquité ou de la latence pour une autre; la boucle de contrôle doit donc être surveillée pendant que le système environnant évolue.

Cela explique aussi l’importance de la distinction entre recherche et production. Un article peut isoler un mécanisme et montrer un résultat sous des hypothèses contrôlées. Les équipes de production doivent préserver ces hypothèses ou savoir à quel moment elles cessent d’être valables. Une bonne architecture rend les dépendances assez visibles pour qu’une mise à niveau puisse être testée avant d’atteindre l’ensemble du parc.

Greenberg revient régulièrement à ce problème. Ananta distribue une fonction auparavant concentrée dans des équipements. SWAN centralise le raisonnement sur le WAN tandis que l’acheminement reste distribué. Pingmesh crée des preuves communes entre des équipes qui peuvent ne pas être d’accord sur l’origine réseau ou applicative d’une panne. Chaque système déplace une frontière technique et, avec elle, la frontière organisationnelle entre les équipes appelées à coopérer.

L’observabilité n’a de valeur que lorsqu’elle modifie une décision

Une grande plateforme peut recueillir plus de télémétrie qu’aucune personne ne peut en examiner directement. Le défi ne consiste pas seulement à mesurer davantage, mais à relier la mesure à une action. La contribution de Pingmesh a été de rendre la latence et la perte continuellement observables entre de nombreuses paires de points de terminaison, en fournissant une référence utilisable par les opérateurs pendant les incidents. Cela aide lorsque l’état des appareils semble sain alors que les utilisateurs subissent un problème au niveau du chemin.

Les mesures synthétiques présentent un avantage important: elles peuvent fonctionner en continu, même lorsqu’une application est inactive. Elles ont aussi une limite importante: elles ne sont pas l’application. Une sonde peut emprunter un chemin différent, manquer une condition de file d’attente ou éviter la dépendance applicative responsable du symptôme. Le jugement opérationnel vient donc de la combinaison des preuves synthétiques du réseau avec la télémétrie des services, l’état de la topologie et l’historique des déploiements.

La même logique s’applique aux matrices de trafic et aux tests de panne. La mesure devient une infrastructure lorsqu’elle entre dans une boucle de décision reproductible. Un responsable de la capacité modifie un plan d’expansion parce que les preuves sur la demande révèlent un goulet d’étranglement. Un contrôleur déplace le trafic parce que l’état courant révèle une panne. Une équipe d’intervention annule un déploiement parce que la télémétrie relie une modification à un profil de perte. Les indicateurs incapables de modifier une décision relèvent du compte rendu; ceux qui peuvent la modifier deviennent une partie du contrôle.

Cette distinction aide à comprendre pourquoi les travaux de Greenberg restent pertinents à mesure que progressent les réseaux définis par logiciel. Une programmabilité accrue permet de prendre des décisions plus vite, ce qui augmente la valeur des preuves indiquant si elles ont réussi. L’automatisation sans mesure est aveugle. La mesure sans voie d’action est passive. L’architecture devient utile lorsque les deux sont reliées sans rendre la boucle de retour si agressive qu’un seul mauvais signal déstabilise le système.

L’infrastructure d’IA augmente le coût des erreurs des boucles de contrôle

L’infrastructure actuelle d’IA n’annule pas les anciennes leçons; elle en relève les enjeux. Les systèmes d’entraînement peuvent générer un trafic est-ouest continu entre accélérateurs, stockage et nœuds de calcul. L’inférence peut ajouter des chemins de service sensibles à la latence. Le placement des accélérateurs, le déplacement des données et la reprise après panne font du réseau une composante de l’ordonnancement des charges de travail plutôt qu’un service d’arrière-plan. Une décision de contrôle qui immobilise de la capacité ou crée de la congestion peut gaspiller du calcul coûteux en plus de la bande passante.

Les preuves disponibles relient le périmètre actuel de Greenberg chez Uber à l’infrastructure d’IA et de véhicules autonomes, mais elles ne vont pas jusqu’à nommer chaque système ou à lui attribuer une responsabilité individuelle de conception. Cette lacune doit rester visible. La conclusion appropriée est que les mêmes disciplines — topologie, capacité, répartition de charge, télémétrie et domaines de défaillance — sont importantes pour ces charges de travail, non qu’un seul dirigeant soit responsable des algorithmes exécutés au-dessus.

Les infrastructures spécialisées pour l’IA peuvent également différer des réseaux cloud généralistes. Les grappes d’entraînement peuvent utiliser des interconnexions étroitement contrôlées et des hypothèses d’ordonnancement différentes de celles des réseaux de services Ethernet/IP qui transportent les applications ordinaires. Même si les technologies divergent, les questions de contrôle restent familières: quelle est la demande, où réside la politique, comment l’état est-il installé, quelles pannes sont indépendantes et quelles preuves montrent que le comportement prévu s’est produit?

C’est ici que la vision intégrée de Greenberg reste plus utile qu’une étiquette de produit. Son parcours suggère que l’infrastructure s’améliore lorsque les concepteurs cessent de traiter topologie, transport, répartition de charge, capacité du WAN et télémétrie comme des spécialités séparées. L’IA rend le coût de cette fragmentation plus visible: des accélérateurs inactifs, des tâches échouées et des déplacements de données retardés peuvent transformer une erreur de contrôle réseau en perte importante de calcul et de capital.

L’architecture ne tient que si les organisations savent l’exploiter

Les articles techniques se terminent souvent là où commence le travail de production. Une topologie est décrite, un algorithme évalué et des mesures montrent qu’un mécanisme peut fonctionner. Des années d’exploitation exigent une autre machinerie: attribution des responsabilités, processus de publication, systèmes d’astreinte, plans de capacité, renouvellement du matériel, revue de sécurité, politique de compatibilité et méthode pour modifier la conception sans interrompre le service.

Le parcours de Greenberg franchit cette frontière à plusieurs reprises. Les travaux d’AT&T se sont déroulés dans un environnement d’opérateur en activité où le trafic ne pouvait être arrêté pour les besoins de la recherche. Les idées de Microsoft Research sont entrées dans l’organisation Azure, qui devait servir des clients à travers plusieurs générations de matériel et plusieurs régions. Les équipes de plateforme d’Uber doivent servir des groupes applicatifs aux exigences différentes de fiabilité et de performance.

Les mécanismes évoluent, mais le test organisationnel reste proche: une idée à l’échelle du réseau peut-elle devenir un ensemble de décisions reproductibles prises par de nombreuses équipes?

Les abstractions communes sont utiles parce qu’elles concentrent le travail spécialisé. Une infrastructure uniforme donne une forme familière à l’expansion. Les réseaux virtuels fournissent aux clients une surface de contrôle stable tandis que le fournisseur modifie le réseau physique. Un service mutualisé de répartition de charge évite à chaque équipe applicative de construire sa propre architecture de trafic entrant. Une télémétrie commune permet aux intervenants de travailler à partir d’une vue partagée.

Des classes standard de basculement permettent aux responsables de la capacité de différencier les charges sans renégocier chaque service depuis le début.

La concentration crée en contrepartie des obligations. L’équipe de plateforme doit publier les limites, protéger la compatibilité et fournir des preuves lorsque l’abstraction laisse apparaître l’infrastructure sous-jacente. Un client ne peut réparer lui-même une infrastructure ou un plan de contrôle cachés. Un raisonnement central n’est justifié que si l’équipe centrale peut soutenir son rayon d’impact plus large par la réplication, les changements progressifs, le retour arrière et une attribution claire des incidents.

L’économie des très grandes échelles renforce cette idée. Une faible amélioration en pourcentage de l’utilisation, des files d’attente, de la distribution de charge ou de la capacité de réserve peut affecter un immense parc. La même échelle amplifie les erreurs. Un mauvais seuil de congestion, une erreur de distribution des routes ou un angle mort de télémétrie peut toucher de nombreux services à la fois. Un paramètre technique devient alors une décision économique: il modifie le volume d’infrastructure que l’entreprise doit financer et le niveau de risque opérationnel qu’elle supporte.

La boucle de contrôle doit survivre à ses concepteurs

Les grands systèmes réseau ne sont pas déployés une fois pour rester inchangés. Les générations de matériel se succèdent, les charges de travail évoluent, les produits acquièrent de nouvelles exigences et les organisations redistribuent les responsabilités. Une architecture qui ne fonctionne que tant que ses concepteurs d’origine sont présents n’est pas une infrastructure durable. Le test le plus difficile consiste à savoir si de nouvelles équipes peuvent modifier le système tout en conservant une explication intelligible de la demande, de la décision, de l’acheminement et de la défaillance.

Les grands projets associés à Greenberg rendent explicites différentes parties de cette continuité. Les matrices de trafic rendent la demande assez visible pour planifier. L’architecture 4D sépare les fonctions de contrôle afin que le raisonnement sur les politiques puisse être examiné indépendamment de l’acheminement. VL2 sépare le placement des services de l’emplacement physique. DCTCP transforme la congestion en retour d’information commun entre commutateurs et points de terminaison. Ananta et SWAN attribuent le trafic au niveau des services et du WAN, tandis que Pingmesh crée des preuves continues sur le délai et la perte.

La production transforme ces mécanismes en mémoire institutionnelle. Les interfaces doivent être versionnées, la télémétrie rester comparable au fil des mises à niveau et les modèles de capacité être recalibrés lorsque les charges changent. Les exercices de panne doivent mettre à l’épreuve les hypothèses sur l’indépendance et la réserve. Les revues après incident doivent modifier l’architecture autant que le code lorsqu’il apparaît qu’un chemin supposé indépendant partage une dépendance, ou lorsqu’un déploiement révèle une faiblesse du plan de contrôle.

C’est également la frontière la plus claire du rôle individuel de Greenberg. Il n’a inventé ni les réseaux définis par logiciel, ni les réseaux cloud, ni chaque système associé à AT&T, Microsoft et Uber. Les preuves étayent une contribution durable à une conception du réseau comme ordinateur distribué intégré, dont la topologie, le transport, le contrôle, la télémétrie et l’organisation opérationnelle doivent être élaborés ensemble. Cette influence est plus forte lorsque la discipline subsiste après la personne qui a contribué à l’établir.

Le test observable n’est donc ni une nouvelle récompense ni un autre titre général. La question est de savoir si les plateformes façonnées par cette approche peuvent continuer à changer sans perdre le lien entre ce qu’elles voulaient faire, ce qu’elles ont installé et ce que les utilisateurs ont réellement constaté. Les charges d’IA, le matériel et les nouveaux modèles de défaillance continueront à déplacer la cible. Une architecture robuste rend ces changements assez explicables pour être testés, assez réversibles pour être exploités et assez explicites pour que la responsabilité ne disparaisse pas dans le système.