Résumé

  • La carrière de Greenberg relie la mesure du trafic des opérateurs, les réseaux de centres de données à très grande échelle et l’infrastructure de plateforme d’Uber, chaque étape considérant le réseau comme un système qui doit être mesuré et contrôlé dans son ensemble.
  • L’architecture 4D, VL2, DCTCP, Ananta, SWAN et Pingmesh ont traité différentes couches de ce système, mais chacun de ces travaux était collectif et leur impact en production ne peut être attribué à une seule personne.
  • Chez Uber, une étude de 2026 sur le basculement a fait état d’une meilleure utilisation après le passage de certains services d’une réserve uniforme de 2x à une capacité différenciée, tout en maintenant une disponibilité de 99,97 % dans le système étudié.
  • Le test durable de l’influence de Greenberg consiste à déterminer si les boucles de contrôle qu’il a contribué à façonner peuvent résister aux nouveaux matériels, aux charges de travail d’IA, aux changements organisationnels et aux pannes sans perdre leur explicabilité ni leur responsabilité.

Un objectif de basculement de 1,3x rend l’architecture visible

Pour aborder la carrière d’Albert Greenberg, une décision de capacité est plus utile qu’un intitulé de poste ou une distinction. Un article NSDI publié en 2026 par Uber décrit un système de planification du basculement qui a fait passer certains services d’un modèle uniforme de réserve de 2x à une planification différenciée autour de 1,3x. L’équipe a rapporté une meilleure utilisation et une disponibilité de 99,97 % dans le système étudié. Ce résultat appartient à une vaste équipe d’auteurs et à l’architecture de production d’Uber, non à un seul dirigeant.

Il met néanmoins en lumière une question présente depuis des décennies dans les travaux de Greenberg: de combien de capacité inutilisée, de contrôle et de mesure une plateforme a-t-elle besoin pour que la fiabilité devienne une propriété conçue plutôt qu’un simple espoir?

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

Le poste actuel de Greenberg chez Uber le place à proximité de ce problème, même si les sources publiques ne donnent pas un intitulé incontesté. Un profil publié en 2026 par ARCS Foundation le présente comme Senior Vice President and Chief Architect Officer, tandis qu’une biographie événementielle de l’University of Minnesota le décrit comme Vice President of Platform Engineering. Les deux sources sont suffisamment crédibles pour que cette divergence demeure explicite.

Elles s’accordent toutefois sur l’essentiel: Greenberg est un haut dirigeant des plateformes et de l’architecture dont le périmètre couvre l’infrastructure, et non un chercheur travaillant sur un protocole isolé.

Cette vision systémique apparaît bien plus tôt dans sa carrière. 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 déduit d’un seul compteur d’interface. Chez Microsoft, il s’agissait de faire fonctionner ensemble la fabrique d’un centre de données, le protocole de transport, l’équilibreur de charge, le réseau étendu et le système de télémétrie au sein d’une même plateforme cloud. Chez Uber, le contexte s’est encore déplacé vers les services mondiaux de plateforme, l’infrastructure d’IA et une résilience différenciée.

Les technologies ont changé, mais pas la discipline récurrente: observer l’ensemble, expliciter les décisions de contrôle, les appliquer en sécurité et mesurer si la réalité suit le modèle.

Les réseaux d’opérateurs ont appris à Greenberg à mesurer avant de contrôler

Greenberg a obtenu un doctorat en informatique à l’University of Washington en 1983, après des études de mathématiques au Dartmouth College, puis a effectué une grande partie de son début de carrière dans la recherche réseau chez AT&T et Bell Labs. L’élément pertinent n’est pas la succession de ses titres, mais le type de système rencontré: une dorsale d’opérateur en activité, avec des clients, des protocoles, des pannes et des profils de trafic impossibles à suspendre pendant que les chercheurs tentaient de comprendre le réseau.

La planification d’une dorsale dépend des matrices de trafic, des traces de panne et d’une vision de la demande sur de nombreux routeurs. Les compteurs de liens montrent la charge en un point, les tables de routage indiquent les chemins sélectionnés et les relevés de flux offrent une autre vue partielle. Aucun ne permet seul d’expliquer le volume de trafic entre les points d’entrée et de sortie ni les conséquences d’un changement de routage. Les équipes d’AT&T ont développé des méthodes de mesure et d’ingénierie du trafic qui ont rendu la dorsale plus accessible à une ingénierie empirique.

Les sources publiques n’exposant pas tous les systèmes ou jeux de données de production, l’affirmation défendable porte sur l’approche d’ingénierie plutôt que sur un inventaire complet d’outils propriétaires.

Une matrice de trafic transforme de nombreux indices dispersés en un modèle exploitable par les planificateurs de capacité. Lorsque le trafic augmente entre deux parties du réseau, l’opérateur peut demander si les chemins existants suffisent, si une panne créerait un goulet d’étranglement ou si la politique de routage dirige la demande vers les mauvais liens. L’estimation reste imparfaite: échantillonnage, agrégation, changements de routage et 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 considérée comme une vérité absolue.

Cette limite explique pourquoi la mesure est devenue davantage qu’une couche de reporting dans les travaux ultérieurs de Greenberg. Un système de contrôle ne peut optimiser les chemins qu’à partir d’un modèle crédible de la topologie et de la demande. Un équilibreur de charge ne peut distribuer les requêtes que s’il connaît l’état des serveurs et des routes. Un planificateur de basculement ne peut réduire la réserve que si les exercices et la télémétrie montrent ce qui se produit lorsqu’un site, un lien ou un service disparaît.

La boucle récurrente est simple à énoncer mais difficile à exploiter: observer, décider, appliquer, mesurer et réviser.

La chronologie étaye cette progression sans en faire un récit héroïque. Greenberg a achevé son doctorat en 1983; Clean Slate 4D Approach to Network Control and Management a été publié en 2005; VL2 en 2009; centres de données TCP en 2010; Ananta et SWAN en 2013; puis Pingmesh en 2015. Ses travaux chez AT&T et Bell Labs couvrent les années 1980 jusqu’au début des années 2000. Microsoft et Azure deviennent le principal cadre institutionnel de la fin des années 2000 à la décennie suivante, puis Uber celui des années 2020.

Chaque phase 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 personne aurait transporté un plan achevé d’un employeur au suivant.

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

L’architecture 4D, élaborée et publiée avec plusieurs collaborateurs au milieu des années 2000, remettait en cause un trait classique de la gestion centrée sur les routeurs: chaque équipement combinait configuration locale, protocoles distribués et comportement d’acheminement, rendant difficiles les raisonnements sur les politiques et les pannes à l’échelle du réseau. La proposition répartissait le contrôle entre quatre plans: décision, diffusion, découverte et données.

La découverte recueillait les informations sur la topologie et l’état; le plan de décision calculait le contrôle global; la diffusion installait l’état obtenu; le plan de données acheminait les paquets.

Le changement essentiel était cette séparation. En considérant le raisonnement politique comme une fonction logique distincte, les concepteurs pouvaient envisager un contrôleur disposant d’une vue globale sans centraliser physiquement l’acheminement. Les politiques pouvaient être vérifiées sur un modèle plus large et l’état résultant diffusé par un mécanisme contrôlé. Cette architecture a anticipé des idées ensuite associées aux réseaux définis par logiciel, mais elle ne doit pas être présentée comme l’origine unique du SDN.

Le domaine possède plusieurs filiations intellectuelles; les preuves disponibles établissent 4D comme un précurseur et un apport influents, non comme une invention exclusive.

La séparation du contrôle déplace également les risques. Un service de décision peut tomber en panne ou utiliser des données de découverte périmées. La diffusion peut n’appliquer qu’une partie d’un changement. Un moteur de politiques logiquement central peut propager une mauvaise décision plus vite qu’un ensemble de routeurs faiblement coordonnés. Les protocoles et équipements historiques doivent en outre continuer à fonctionner pendant la transition.

L’architecture ne supprimait donc pas la complexité: elle en rendait certaines parties plus explicites tout en concentrant une part de la responsabilité dans les logiciels et les processus opérationnels.

Ce compromis est devenu central dans les systèmes cloud ultérieurs. La question n’était plus de savoir si le raisonnement global pouvait être séparé de l’acheminement, mais comment le rendre disponible, répliqué, observable et compatible avec des chemins de données distribués. Déploiement progressif, retour arrière, contrôles d’état et comportement local d’acheminement sont essentiels, car la vision plus large du contrôleur s’accompagne d’un rayon d’impact plus vaste. Les travaux ultérieurs de Greenberg chez Microsoft ont abordé ces questions au moyen de systèmes concrets plutôt que d’un plan de contrôle universel.

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

Lorsque Greenberg a rejoint les travaux de Microsoft sur les réseaux de centres de données, l’échelle et le modèle de panne ont changé. Les grands services en ligne voulaient placer ou déplacer leurs charges de travail sans redessiner le réseau autour de chaque serveur, alors que les réseaux hiérarchiques traditionnels pouvaient limiter la bande passante et lier trop étroitement les adresses à la topologie physique.

VL2, conçu par une importante équipe d’auteurs de Microsoft, associait une fabrique Clos repliée, l’indirection des adresses et l’équilibrage de charge de Valiant afin de prendre en charge des placements de services et des profils de trafic imprévisibles.

L’objectif de service était l’élément le plus utile: les charges de travail devaient conserver des identités stables pendant que la fabrique physique utilisait en dessous une structure de couche 3 extensible. Des mécanismes d’annuaire et de contrôle pouvaient associer les adresses de service à des emplacements, tandis qu’une topologie Clos multichemin fournissait plusieurs routes à travers le centre de données. Le réseau devenait ainsi une fabrique dont la capacité pouvait être utilisée plus souplement au gré des déplacements de services.

L’équilibrage de Valiant ajoute un mécanisme contre-intuitif. Plutôt que de prédire le meilleur chemin de bout en bout pour chaque matrice de trafic, il répartit le trafic par des points intermédiaires choisis aléatoirement afin qu’aucun profil de demande inconnu ne domine les mêmes liens. Un flux peut suivre un itinéraire moins direct, tandis que le réseau global devient plus prévisible sous des charges variées. Le mécanisme conserve des limites: longueur supplémentaire, déséquilibre du hachage, flux très volumineux et pannes peuvent affecter les résultats individuels.

L’influence de VL2 doit être décrite comme une filiation de conception, non comme un plan de production figé. Azure n’a pas simplement déployé l’article de recherche sans le modifier. 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é d’évoluer. L’affirmation défendable est que VL2 a contribué à établir un vocabulaire devenu central dans les réseaux à très grande échelle: fabriques Clos, séparation entre adresse et emplacement, utilisation multichemin et contrôle assisté par logiciel.

L’économie découle de l’architecture. Des fabriques uniformes reposant sur des commutateurs modulaires ou courants peuvent permettre une expansion plus progressive que des conceptions dépendant de quelques très grands châssis. La moindre dépendance à chaque boîtier ne supprime toutefois pas les coûts: elle 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 pannes. Un fournisseur cloud ne peut économiser sur une couche qu’en exploitant mieux le système distribué qui la remplace.

DCTCP a fait de la congestion un problème partagé entre commutateurs et hôtes

Le trafic des centres de données mêle des flux courts sensibles à la latence et de gros transferts. Le TCP classique peut former des files profondes avant de réduire sa fenêtre d’envoi, de sorte que le réseau affiche une forte utilisation des liens alors que les tâches courtes attendent derrière les paquets accumulés. DCTCP, également conçu par plusieurs auteurs, utilisait Explicit Congestion Notification avec des files peu profondes dans les commutateurs et adaptait l’émetteur à la proportion de paquets marqués. L’objectif était de maintenir de faibles files sans sacrifier le débit.

La conséquence importante est que le contrôle de congestion devient une boucle coordonnée entre les équipements réseau et les terminaux. Les commutateurs doivent utiliser des seuils de marquage adaptés, et les hôtes un comportement compatible. Le profil de trafic, la topologie et le matériel influencent tous 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 peut activer isolément.

Ces travaux ont contribué à faire de la congestion des centres de données un problème opérationnel distinct. L’Internet ouvert comprend de longs chemins, des opérateurs variés et des terminaux faiblement coordonnés, tandis qu’un fournisseur cloud peut souvent gérer à la fois les serveurs et les commutateurs. Ce périmètre administratif permet des mécanismes difficiles à coordonner mondialement, mais crée aussi des obligations: versions des terminaux, paramètres des commutateurs et télémétrie doivent évoluer ensemble pour éviter la dérive de la boucle de contrôle.

Cette limite reste importante parce que des systèmes ultérieurs poursuivent ou étendent le même objectif. Nouveaux algorithmes, fabriques plus rapides et conceptions de mémoire tampon différentes ne suppriment pas les questions fondamentales: où les files se forment-elles, comment les terminaux l’apprennent-ils et quelle équipe possède la configuration? La contribution de Greenberg appartient à un portefeuille de recherche et d’ingénierie qui considère constamment 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 constituaient qu’une partie du problème des réseaux cloud. Les services avaient encore besoin d’entrées extensibles, les centres de données devaient partager la capacité étendue et les opérateurs devaient distinguer une panne réseau d’un symptôme applicatif. Les équipes de Microsoft ont traité ces questions avec Ananta, SWAN et Pingmesh, chacun ayant ses propres auteurs et limites de déploiement.

Ananta s’attaquait à l’équilibrage de charge de couche 4 à l’échelle du cloud. Au lieu de concentrer le traitement dans un seul équipement, le système distribuait le traitement des paquets, la gestion des routes et le contrôle des services entre de nombreuses machines. Le chemin de données pouvait ainsi évoluer horizontalement, mais cette distribution imposait ses propres exigences en matière d’état, de cohérence, de santé des serveurs et de gestion des pannes. L’équilibreur devenait un service d’infrastructure plutôt qu’un boîtier placé en périphérie.

SWAN appliquait une optimisation logiquement centrale au réseau étendu. Les liens entre centres de données sont coûteux, la demande varie et les pannes peuvent supprimer brutalement de la capacité. Un contrôleur disposant d’une vue étendue peut attribuer les chemins selon la priorité des services et l’état du réseau, éloigner le trafic de la congestion et utiliser plus délibérément les rares liaisons longue distance. Cette vision centrale devient cependant un risque lorsque les estimations sont erronées, les mises à jour dangereuses ou une partie du réseau inaccessible.

Pingmesh abordait la visibilité. Des agents produisaient et recueillaient des mesures de latence et de perte de paquets dans une vaste flotte, créant un maillage continu de preuves synthétiques. Un lien peut être déclaré actif alors qu’un chemin fonctionne mal; un service peut échouer à cause d’un segment réseau sans propriétaire unique. Les mesures à l’échelle de la flotte fournissent une référence partagée, même si les sondes synthétiques ne reproduisent pas chaque chemin applicatif, file ou dépendance.

Ces trois systèmes montrent pourquoi le parcours de Greenberg ne se réduit pas à un article célèbre sur la topologie. Ananta associe le trafic des services aux ressources, SWAN attribue la capacité étendue et Pingmesh mesure le comportement des chemins. DCTCP gère le retour d’information sur les files dans la fabrique, tandis que VL2 propose la conception de cette fabrique. La fiabilité résulte de l’interaction entre ces mécanismes, ce qui impose aussi une attribution collective.

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

Lorsque Greenberg a occupé des fonctions dirigeantes au sein d’Azure Networking, le défi n’était plus de savoir si un article fonctionnait dans une expérience définie. Azure devait exploiter comme un même service cloud les fabriques physiques, réseaux virtuels, équilibreurs, passerelles, liens étendus, systèmes de télémétrie et mécanismes de déploiement. Les clients attendaient isolation, programmabilité et disponibilité sans avoir à comprendre le matériel ou les processus de contrôle sous-jacents.

Les réseaux virtuels rendent cette abstraction concrète. Le client voit des adresses, routes, règles de sécurité et points de terminaison; le cloud traduit cette intention sur des hôtes, commutateurs et passerelles partagés. Le plan de contrôle doit traiter des changements rapides sans qu’une configuration affecte un autre client. Le plan de données doit continuer à acheminer à haut débit, tandis que les API, journaux d’audit, retours arrière et exigences de cohérence régionale transforment le réseau en un problème de cycle de vie logiciel autant que d’acheminement des paquets.

Ce cycle de vie modifie le sens de l’architecture. Une version peut changer le routage ou la sécurité de nombreux clients. Une panne du plan de contrôle peut empêcher de nouvelles configurations alors que les flux existants continuent. Une lacune de télémétrie peut faire paraître l’infrastructure saine tandis que les utilisateurs constatent une panne. Les planificateurs doivent prévoir simultanément la croissance normale et le basculement régional. L’organisation d’ingénierie devient ainsi une partie du contrat de service, car les clients ne peuvent ni inspecter ni réparer la majeure partie du système caché.

La période du discours de Greenberg à SIGCOMM en 2015 est pertinente parce qu’elle présentait le réseau cloud comme un portefeuille de systèmes interdépendants plutôt que comme la recherche d’une fabrique définitive. Topologie, transport, virtualisation, équilibrage, ingénierie étendue, surveillance et opérations doivent rester cohérents pendant que la plateforme change. Ce cadre est plus durable que n’importe quel détail d’implémentation et correspond au parcours de Greenberg au sein de multiples équipes.

Son autorité formelle chez Microsoft étaye une affirmation de leadership, non une propriété exclusive des technologies. Les sources publiques le décrivent comme Corporate Vice President et Technical Fellow d’Azure Networking; des documents historiques d’AT&T mentionnent aussi des fonctions dirigeantes, dont executive director et AT&T Fellow, selon les périodes. Les systèmes concernés ont de nombreux coauteurs et ingénieurs de production.

L’attribution la plus solide consiste donc à nommer chaque travail collectif, à identifier l’employeur comme institution de production et à réserver les affirmations personnelles au leadership architectural et aux contributions documentés.

Le leadership passe par les équipes, non par l’invention solitaire

La carrière de Greenberg se prête à des raccourcis capables de transformer une histoire de systèmes en récit héroïque. Les faits sont plus intéressants: VL2, DCTCP, Ananta, SWAN, Pingmesh et les travaux d’Uber sur le basculement ont tous été réalisés en équipe. L’architecture 4D est issue d’une communauté de recherche comptant plusieurs contributeurs. Azure Networking a évolué pendant des années grâce à un travail de produit et d’exploitation qu’aucun article ni aucune biographie ne décrit entièrement.

Les preuves publiques montrent néanmoins une continuité inhabituelle. Greenberg est passé de la mesure des réseaux d’opérateurs à l’architecture de contrôle repensée, des réseaux de centres de données à très grande échelle à la direction d’une plateforme cloud, puis à l’organisation de plateforme d’Uber. Son influence est à la fois technique et organisationnelle: il apparaît à plusieurs reprises dans des travaux portant sur la mesure de l’état global, la séparation du contrôle, l’attribution du trafic et le raisonnement collectif sur les pannes.

La reconnaissance de ses pairs reflète cette ampleur, mais les distinctions ne doivent pas remplacer les preuves relatives aux projets. Greenberg a reçu l’ACM SIGCOMM Award et l’IEEE Koji Kobayashi Computers and Communications Award en 2015, a été élu à la US National Academy of Engineering en 2016 et est ACM Fellow. Ces distinctions montrent que le domaine juge ses travaux importants; elles ne prouvent ni une invention solitaire, ni une autorité opérationnelle actuelle, ni la filiation exacte d’un système de production particulier.

La divergence sur son titre chez Uber rappelle la même discipline. ARCS Foundation le présente en 2026 comme Senior Vice President and Chief Architect Officer, tandis que des documents de l’University of Minnesota pour 2025–2026 parlent de Vice President of Platform Engineering. Plutôt que de choisir arbitrairement, il faut dater les sources et décrire leur point commun: Greenberg occupe une fonction dirigeante de plateforme et d’architecture dont les droits de décision internes ne sont pas entièrement publics. L’intitulé RH exact reste un point à vérifier.

Cette distinction importe parce que l’architecture répartit aussi l’autorité. Un architecte en chef ou un dirigeant de plateforme peut établir des principes communs, imposer des examens, approuver des mécanismes partagés ou influencer la politique de capacité, sans configurer personnellement chaque commutateur ni écrire chaque service de contrôle. Équipes réseau, équipes de services, ingénieurs sécurité, planificateurs de capacité, fonctions financières et dirigeants conservent des droits distincts. Le leadership architectural vise à les rendre compatibles avec un modèle commun de panne, non à prétendre qu’ils se confondent dans une personne.

Uber applique la même discipline à un autre profil de demande

L’infrastructure d’Uber sert la mobilité, la livraison et d’autres services dont la demande varie fortement selon la géographie et l’heure. Des biographies officielles associent les responsabilités de Greenberg aux centres de données, au calcul, aux réseaux, au stockage, aux données, à la recherche, à la surveillance, à la productivité des développeurs, à l’informatique interne et à l’infrastructure destinée à l’IA et aux véhicules autonomes. Cette étendue établit le contexte de plateforme, sans montrer qu’il a personnellement conçu chaque système ni les modèles applicatifs qu’elle héberge.

Le problème opérationnel diffère de celui d’un cloud public, car Uber contrôle son portefeuille applicatif tout en exploitant des services mondiaux en temps réel et de grands systèmes de données internes. Les décisions relatives au réseau, au stockage et au calcul interagissent avec la fiabilité, l’apprentissage automatique et les opérations régionales. L’architecture de plateforme doit déterminer quelles infrastructures seront partagées, quels domaines de panne sont réellement 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 donne un exemple mesurable. Le passage de certains services d’une capacité uniforme de 2x à une planification différenciée autour de 1,3x ne libère des ressources que si le modèle est exact. La disponibilité rapportée de 99,97 % concerne le système et la période nommés chez Uber; elle ne doit pas être généralisée à tous les services d’Uber ni à d’autres entreprises. Le résultat illustre l’échange géré: une réserve plus faible améliore l’utilisation, mais exige une meilleure classification, une cartographie des dépendances, de la télémétrie et des répétitions.

Il s’agit autant d’une boucle de contrôle économique que technique. Machines de réserve, chemins réseau, énergie et capacité des centres de données ont tous un coût d’opportunité. Une plateforme capable de distinguer les services selon leurs besoins de reprise peut réserver moins de capacité inactive qu’une plateforme traitant toutes les charges de manière identique. Le gain n’est réel que si une panne ne révèle pas de dépendances cachées entre zones ou services supposés indépendants; les essais et l’apprentissage post-incident font donc partie du raisonnement financier.

Les charges actuelles d’IA et de véhicules autonomes accentuent ces décisions. L’entraînement et l’inférence peuvent créer d’importants flux est-ouest, contraindre l’emplacement des accélérateurs et rendre les performances extrêmes plus importantes. Les données de véhicules et de mobilité ajoutent des besoins de stockage, de transfert et de traitement régional. Les biographies fournies rendent ces domaines pertinents pour le rôle de Greenberg, mais ne permettent pas d’affirmer qu’il conçoit des modèles d’IA ou des logiciels de conduite autonome.

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

La fiabilité est une décision d’allocation, non un adjectif

Les organisations cloud qualifient couramment leurs systèmes de résilients, hautement disponibles ou tolérants aux pannes. Ces termes masquent des allocations de capacité, de géographie, de complexité logicielle et d’attention humaine. Une fabrique offre une certaine diversité de chemins; un réseau étendu possède une quantité déterminée de capacité libre; un équilibreur a un modèle particulier d’état et de panne; une plateforme de télémétrie observe certains chemins et pas d’autres. La fiabilité résulte de ces choix, non de l’adjectif inscrit dans un document de conception.

Un contrôle central ou logiquement central peut améliorer ces allocations grâce à une vision étendue. SWAN peut coordonner la capacité du réseau étendu plus délibérément que des décisions locales indépendantes, et un contrôleur de réseau virtuel appliquer des politiques cohérentes sur de nombreux hôtes. Le compromis est la concentration: une mauvaise politique, un état corrompu ou un déploiement défectueux peut rapidement affecter une vaste partie du réseau. La centralisation exige donc réplication, déploiement progressif, retour arrière et capacité de l’acheminement local à survivre à certaines interruptions du contrôle.

Le même principe vaut pour la capacité. Une réserve uniforme de 2x est simple à expliquer mais potentiellement coûteuse. Une réserve différenciée améliore l’utilisation tout en augmentant la dépendance envers l’exactitude de la classification des services et des modèles de panne. Aucun réglage n’est prudent par nature. La bonne valeur dépend des éléments qui tombent en panne ensemble, de la vitesse de déplacement du trafic, de la tolérance des services à la dégradation et de l’incertitude que l’organisation accepte de financer.

L’examen architectural devient ainsi une allocation de pouvoir autant que de technologie. Les équipes de services expriment leurs besoins de latence et de disponibilité. Les équipes réseau et plateforme choisissent les mécanismes partagés. La capacité et la finance déterminent la réserve financée. La sécurité définit les exigences d’isolation. Les dirigeants fixent la tolérance au risque. Un architecte peut imposer un langage commun et un modèle cohérent, sans supprimer les responsabilités et incitations distinctes.

Les travaux de Greenberg proposent un test utile: la conception ferme-t-elle la boucle entre demande, décision, acheminement et preuves? VL2 traitait le placement et la topologie; DCTCP le retour sur les files; Ananta et SWAN l’attribution du trafic; Pingmesh l’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 si ces boucles restent cohérentes pendant les changements.

Le portefeuille dépasse son étiquette la plus connue

Greenberg est surtout associé aux réseaux de centres de données, mais son parcours couvre plusieurs catégories distinctes. La mesure du trafic des opérateurs rendait la demande et les anomalies visibles. L’architecture 4D séparait conceptuellement les fonctions de contrôle. VL2 traitait la topologie et le placement des services. DCTCP contrôlait les files grâce au retour des terminaux et commutateurs. Ananta gérait l’entrée des services, SWAN l’attribution étendue et Pingmesh l’observabilité à l’échelle de la flotte. Les réseaux virtuels Azure ont ensuite intégré 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 chez les opérateurs profite surtout aux exploitants et planificateurs, tandis qu’une grande partie des détails reste propriétaire. L’architecture 4D est une conception de recherche dont l’influence est conceptuelle, non la preuve d’un déploiement universel. VL2 et DCTCP disposent de mécanismes et d’évaluations publiés, alors que leurs descendants de production ont évolué chez Microsoft. Ananta, SWAN et Pingmesh décrivent des services de plateforme ayant leurs propres équipes, dépendances et limites.

Le fil conducteur n’est pas un produit unique, mais une succession de mécanismes rendant différentes décisions explicites. La mesure estime la demande; l’architecture détermine où réside le raisonnement politique; la fabrique fournit les chemins; le contrôle de congestion régule leur usage; l’équilibrage associe le trafic aux ressources; l’ingénierie étendue attribue la capacité intersite; la télémétrie vérifie le résultat; et la direction architecturale coordonne les institutions qui entretiennent ces boucles.

Cette distinction permet de comparer ces travaux à des systèmes voisins. VL2 appartient à une filiation comprenant les fabriques Clos, PortLand, SEATTLE, Jupiter de Google et d’autres architectures de centres de données. DCTCP relève de la recherche sur le contrôle de congestion, SWAN de l’ingénierie du trafic étendu et Pingmesh de l’observabilité. Les réseaux définis par logiciel et OpenFlow constituent une filiation parallèle du contrôle programmable. Les équilibreurs commerciaux et produits d’observabilité peuvent résoudre des problèmes apparentés selon d’autres modèles opérationnels.

La comparaison ne vise pas à classer les personnes ni à désigner une architecture gagnante. Jupiter et B4 de Google, les fabriques de Meta, les produits Clos et leaf-spine, les travaux SDN de l’époque OpenFlow, les équilibreurs gérés et les fournisseurs d’observabilité traitent des problèmes de contrôle qui se recouvrent, avec des frontières institutionnelles différentes. Un équipement commercial peut simplifier une tâche en concentrant la responsabilité dans le produit; une plateforme cloud peut intégrer davantage de couches parce qu’elle contrôle hôtes, commutateurs et logiciels.

Une architecture de recherche peut révéler une abstraction utile sans prouver que l’institution nécessaire pour l’exploiter sera facile à construire.

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

Les travaux de Greenberg s’inscrivent dans un réseau d’institutions plutôt que dans une organisation continue. AT&T Labs a fourni l’environnement de recherche d’opérateur dans lequel mesure du trafic et gestion réseau sont devenues centrales. Microsoft Research et Azure ont relié la recherche sur les centres de données à la production à très grande échelle. Uber constitue le contexte actuel. Dartmouth College et l’University of Washington appartiennent à sa formation; ACM SIGCOMM, IEEE et la National Academy of Engineering figurent parmi les institutions professionnelles ayant reconnu ses travaux.

Ces relations n’ont pas le même sens. L’emploi établit un contexte institutionnel, non la propriété personnelle de l’infrastructure. La coauteurisation prouve une participation à un résultat de recherche, non un contrôle exclusif de sa mise en production. Une distinction montre la reconnaissance des pairs, non l’état actuel d’un système. Une conférence ou une communauté d’architecture peut montrer l’influence et les échanges sans prouver une relation commerciale.

Cette distinction est essentielle dans les infrastructures à très grande échelle, dont de nombreux détails restent privés. Les articles exposent des mécanismes, hypothèses et mesures sélectionnées, mais un fournisseur cloud peut modifier matériel, logiciels de contrôle et pratiques d’exploitation après publication. Un article montre donc ce qu’une équipe a construit et évalué à un moment donné sans constituer une description complète du réseau Azure ou Uber actuel.

La même prudence vaut pour les fonctions actuelles. Un titre dirigeant indique une autorité formelle, mais les droits de décision internes sont rarement publics. Les communautés d’architecture, examens de conception et organisations de plateforme peuvent exercer une forte autorité informelle en déterminant les interfaces, modèles de panne ou procédures de déploiement communs. Les preuves montrent Greenberg comme dirigeant dans ces mécanismes, sans révéler tous ses droits de veto, lignes hiérarchiques ou choix budgétaires.

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

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

Les travaux de Greenberg ont été financés principalement par les organisations de recherche et d’ingénierie de ses employeurs. Les éléments fournis ne permettent d’établir ni modèle personnel de revenus, ni estimation de participation ou de patrimoine, ni attribution financière auditée à un produit. Des titres dirigeants et des systèmes influents ne permettent pas d’estimer sa rémunération ni d’attribuer les revenus d’Azure ou d’Uber à un architecte.

Les articles de production peuvent rapporter des mesures d’efficacité ou de disponibilité, comme l’étude d’Uber. Ces chiffres appartiennent au système et à l’équipe d’auteurs nommés, avec des hypothèses propres à l’architecture et à la période. Ils ne doivent être transformés ni en économies à l’échelle de l’entreprise sans informations financières, ni en évaluation personnelle de Greenberg. Les citations et distinctions mesurent également la reconnaissance, non les revenus.

Sur le plan géographique, sa formation et ses principaux employeurs sont basés aux États-Unis, alors que les infrastructures concernées sont mondiales. La dorsale d’AT&T, les régions Azure et l’empreinte de services d’Uber rencontrent chacune des contraintes différentes de capacité, de réglementation et de panne. Un principe valable dans ces environnements n’implique pas que chaque région emploie le même matériel, la même topologie ou la même politique de réserve.

Cette portée mondiale compte pour l’IA et la mobilité. Entraînement, inférence, stockage et données de flotte dépendent de centres de données, de réseaux et de chaînes d’approvisionnement transrégionaux, même si le leadership architectural se situe dans un pays. Les sources publiques ne révèlent pas toutes les topologies ni tous les fournisseurs. L’affirmation la plus solide reste que les travaux de Greenberg concernent une infrastructure dont les effets opérationnels dépassent largement les organisations où la recherche a été publiée.

Le contre-argument: le contrôle intégré peut aussi intégrer la panne

L’argument le plus fort contre cette architecture se trouve dans son attrait. Une vue globale peut mieux coordonner politiques, capacité et reprise qu’un ensemble d’équipements isolés, mais elle peut aussi donner à une erreur logicielle un rayon d’impact beaucoup plus large. La proposition 4D le montrait conceptuellement; les systèmes cloud ont dû l’affronter en production: lorsque le contrôle est séparé et centralisé logiquement, le contrôleur, ses entrées et le mécanisme de déploiement deviennent une infrastructure critique.

La télémétrie ne supprime pas ce problème, car l’observation reste incomplète. Pingmesh peut fournir une référence puissante pour la latence et les pertes, mais les sondes synthétiques ne reproduisent pas chaque chemin applicatif ni chaque file. Les matrices de trafic peuvent être faussées par l’échantillonnage et les changements de route. La corrélation entre signaux réseau, hôte et service peut réduire le champ des causes sans établir l’origine. Un système trop confiant dans sa télémétrie peut automatiser une mauvaise explication plus rapidement qu’une équipe humaine.

L’optimisation de capacité présente la même asymétrie. De meilleurs modèles peuvent réduire le gaspillage, comme le suggèrent les travaux d’Uber, mais la valeur d’une réserve réduite dépend d’hypothèses d’indépendance et de reprise. Si deux zones partagent une dépendance cachée, un modèle les considérant séparées peut sous-estimer la capacité requise. Plus l’optimisation est agressive, plus il devient important de tester les scénarios dont dépendent les économies.

L’écart entre recherche et production constitue une autre source d’erreur. Une architecture publiée est un instantané avec une liste d’auteurs, une charge et une méthode d’évaluation connues. Les systèmes de production accumulent révisions matérielles, migrations, couches de compatibilité, exceptions d’urgence et pratiques rarement décrites publiquement. Considérer VL2 comme l’architecture Azure actuelle ou l’étude Uber de 2026 comme une politique permanente pour tous les services dépasserait les preuves.

Dans un profil personnel, le risque équivalent est la personnalisation excessive. L’étendue du parcours de Greenberg pourrait conduire à lui attribuer toute la trajectoire du contrôle défini par logiciel jusqu’à l’infrastructure moderne d’IA. Les preuves ne le permettent pas. Il n’a pas écrit seul les grands systèmes, ne possède pas personnellement l’infrastructure d’AT&T, Microsoft ou Uber, et ne peut être présenté comme le concepteur de modèles applicatifs ou de logiciels de conduite autonome au seul motif que ses biographies mentionnent ces charges.

Ces limites ne diminuent pas sa contribution; elles la situent plus précisément. Son influence tient à sa participation à la conception et à la direction de systèmes où le comportement réseau combine topologie, transport, contrôle, mesure et réponse organisationnelle. Le contre-argument est que chaque couche d’intégration ajoute aussi une 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 d’immenses volumes de données sans fournir un compte rendu simple de la demande. Un compteur peut indiquer qu’une interface est chargée, sans expliquer quelles demandes de bout en bout ont produit cette charge ni ce qui arrivera si un autre chemin tombe en panne. Relevés de flux, tables de routage et performances historiques offrent chacun une vue partielle. Une matrice de trafic tente de les combiner pour modéliser la demande entre points d’entrée et de sortie.

Pour les planificateurs, ce modèle change les questions possibles. Un lien saturé peut être un problème local, une conséquence de la politique de routage ou le signe d’une croissance structurelle ailleurs. Une maintenance peut être sûre en temps normal et dangereuse pendant un pic corrélé. Les estimations globales permettent de tester ces possibilités avant d’engager de nouvelles capacités ou politiques.

L’estimation reste conditionnelle, car les données réseau ne sont jamais complètes. L’échantillonnage peut manquer des pointes, l’agrégation masquer certains flux et le chiffrement limiter l’interprétation applicative. Un changement de route peut rendre la matrice d’hier peu pertinente pour le risque d’aujourd’hui. La valeur opérationnelle vient de la comparaison de plusieurs signaux imparfaits dans le temps, non de l’attente d’une réponse définitive.

Cette approche empirique sous-tend les travaux cloud ultérieurs. VL2 a besoin d’une vision de la demande pour distribuer les flux; SWAN de prévisions et de l’état courant pour attribuer la capacité; un plan de basculement différencié de preuves sur les dépendances et la reprise. Les mécanismes diffèrent, mais tous transforment des observations en un modèle révisable lorsque la réalité ne lui correspond pas.

Une fabrique n’est utile que si son contrôle peut changer en sécurité

Les topologies Clos repliées sont devenues attrayantes parce qu’elles offrent de nombreux chemins et une expansion modulaire. VL2 reliait cette structure physique à l’indirection des adresses et à la répartition du trafic afin que les services puissent se déplacer sans hiérarchie rigide d’emplacements. L’architecture cherchait à offrir aux applications une connectivité large et uniforme, bien que le réseau sous-jacent reste un ensemble distribué de commutateurs et de liens.

Cette abstraction déplace la responsabilité vers les logiciels de contrôle. Le système doit associer les identités de service aux emplacements, sélectionner ou répartir le trafic et réagir aux pannes. Si ces mécanismes sont périmés ou incohérents, une fabrique peut disposer d’une forte bande passante brute tout en fournissant un service médiocre. Une topologie est 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; le fournisseur traduit leur intention en règles hôtes, routes, tunnels, passerelles et capacité physique partagée. Les changements doivent être versionnés et déployés prudemment, car le client ne voit pas tout l’état caché. Un défaut du plan de contrôle peut toucher les nouvelles configurations tandis que les flux existants continuent, produisant des symptômes différents selon la date de création ou de déplacement d’une charge.

L’architecture devient ici un contrat opérationnel. L’équipe de plateforme retire de la complexité aux équipes applicatives et assume en échange la compatibilité, l’observabilité et la reprise. Les abstractions partagées accélèrent l’organisation uniquement si les équipes qui les exploitent peuvent en expliquer les limites et offrir une issue lorsqu’elles échouent.

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

DCTCP traverse une frontière souvent traitée comme séparée: les commutateurs marquent les paquets lorsque les files dépassent un seuil et les terminaux adaptent l’envoi à la proportion de marques. Aucun côté ne peut fournir seul le résultat attendu. Les équipes réseau et système 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 ponctuels. Les générations matérielles modifient les mémoires tampons; les images hôtes introduisent d’autres codes de transport; les charges passent des échanges courts à de gros transferts ou à des communications d’IA. Un réglage efficace avec un profil peut produire de l’injustice ou de la latence avec un autre. La boucle doit donc être surveillée à mesure que le système environnant change.

C’est aussi pourquoi la distinction entre recherche et production importe. Un article peut isoler un mécanisme et démontrer un résultat sous des hypothèses contrôlées. Les équipes de production doivent préserver ces hypothèses ou savoir quand elles ne tiennent plus. Une bonne architecture rend les dépendances assez visibles pour tester une mise à niveau avant son déploiement sur toute la flotte.

Le portefeuille de Greenberg revient régulièrement à ce problème. Ananta distribue une fonction autrefois centralisée dans des équipements. SWAN centralise le raisonnement sur un réseau étendu dont l’acheminement reste distribué. Pingmesh crée des preuves communes entre des équipes qui pourraient autrement se renvoyer la responsabilité d’une panne. Chaque système modifie une frontière technique et, avec elle, la frontière organisationnelle de la coordination.

L’observabilité n’a de valeur que si elle change une décision

Une grande plateforme peut recueillir plus de télémétrie qu’une personne ne peut en examiner. Le défi n’est pas seulement de mesurer davantage, mais de relier la mesure à une action. Pingmesh rendait la latence et les pertes continuellement observables entre de nombreux terminaux, fournissant une référence pendant les incidents. Cela aide lorsque les équipements semblent sains alors que les utilisateurs rencontrent un problème de chemin.

Les mesures synthétiques peuvent fonctionner en continu même si une application est inactive. Leur limite est qu’elles ne sont pas l’application: une sonde peut emprunter un autre chemin, manquer une condition de file ou éviter une dépendance applicative responsable du symptôme. Le jugement opérationnel associe donc preuves réseau synthétiques, télémétrie des services, état de la topologie et historique des déploiements.

La même logique vaut pour les matrices de trafic et les tests de panne. La mesure devient infrastructure lorsqu’elle participe à une boucle décisionnelle répétable. Un planificateur modifie un plan d’expansion; un contrôleur déplace du trafic; une équipe d’incident annule un déploiement. Les métriques incapables d’influencer une décision relèvent du reporting; celles qui peuvent la changer deviennent une partie du contrôle.

Cette distinction explique la pertinence durable de Greenberg à mesure que les réseaux deviennent plus programmables. Davantage de programmabilité signifie davantage de décisions rapides et accroît la valeur des preuves permettant d’en vérifier les effets. L’automatisation sans mesure est aveugle; la mesure sans capacité de changement est passive. L’architecture devient utile lorsque les deux sont réunies sans qu’un mauvais signal ne déstabilise le système.

L’infrastructure d’IA accroît le coût des boucles défaillantes

L’infrastructure actuelle d’IA n’annule pas les anciennes leçons; elle en augmente les enjeux. Les systèmes d’entraînement génèrent des flux est-ouest soutenus entre accélérateurs, stockage et nœuds de calcul. L’inférence ajoute des chemins sensibles à la latence. Le placement des accélérateurs, le déplacement des données et la reprise font du réseau une partie de l’ordonnancement des charges. Une décision qui immobilise de la capacité ou crée de la congestion peut gaspiller du calcul coûteux autant que de la bande passante.

Les preuves fournies relient le périmètre actuel de Greenberg chez Uber aux infrastructures d’IA et de véhicules autonomes, sans nommer tous les systèmes ni lui attribuer leur conception individuelle. Cette limite doit rester visible. La conclusion pertinente est que les mêmes disciplines architecturales — topologie, capacité, équilibrage, télémétrie et domaines de panne — comptent pour ces charges, non qu’un dirigeant soit responsable des algorithmes qu’elles hébergent.

Les fabriques spécialisées d’IA peuvent aussi diverger des réseaux cloud généralistes. Les grappes d’entraînement utilisent parfois des interconnexions contrôlées et des hypothèses d’ordonnancement différentes des réseaux Ethernet/IP des applications ordinaires. Même si les technologies divergent, les questions de contrôle demeurent: quelle est la demande, où réside la politique, comment l’état est-il appliqué, quelles pannes sont indépendantes et quelles preuves montrent le comportement obtenu?

La vision intégrée de Greenberg reste alors plus utile qu’un nom de produit. L’histoire suggère que l’infrastructure progresse lorsque topologie, transport, équilibrage, capacité étendue et télémétrie ne sont plus traités comme des spécialités sans lien. L’IA rend le coût de la fragmentation plus visible, car des accélérateurs inactifs, des tâches échouées et des données retardées peuvent transformer une erreur de contrôle réseau en perte majeure de calcul et de capital.

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

Les articles techniques s’arrêtent souvent là où commence la production. Une topologie est décrite, un algorithme évalué et des mesures montrent que le mécanisme peut fonctionner. Des années d’exploitation exigent autre chose: propriété, processus de publication, astreinte, plans de capacité, renouvellement matériel, examen de sécurité, compatibilité et possibilité de changer la conception sans arrêter le service.

La carrière de Greenberg traverse régulièrement cette frontière. Les travaux d’AT&T se déroulaient dans un réseau actif impossible à suspendre. Les idées de Microsoft Research sont entrées dans une organisation Azure servant des clients sur plusieurs générations et régions. Les équipes de plateforme d’Uber servent des groupes applicatifs aux besoins différents. Le mécanisme change, mais le test organisationnel demeure: une idée globale peut-elle devenir un ensemble de décisions répétables prises par de nombreuses équipes?

Les abstractions communes concentrent le travail spécialisé. Une fabrique uniforme simplifie l’expansion. Les réseaux virtuels donnent aux clients une surface de contrôle stable pendant que le réseau physique change. Un équilibreur partagé évite à chaque équipe de recréer son architecture d’entrée. Une télémétrie commune offre une vue partagée aux intervenants. Des classes standard de basculement permettent aux planificateurs de distinguer les charges sans renégocier chaque service.

Cette concentration crée des obligations. L’équipe de plateforme doit publier les limites, protéger la compatibilité et fournir des preuves lorsque l’abstraction fuit. Un client ne peut réparer seul une fabrique ou un plan de contrôle caché. Le raisonnement central n’est justifié que si l’équipe centrale maîtrise son rayon d’impact par la réplication, les changements progressifs, le retour arrière et une responsabilité claire pendant les incidents.

L’économie de l’hyperscale renforce ce point. Une petite amélioration de l’utilisation, des files, de la répartition ou de la réserve peut affecter une vaste flotte. La même échelle amplifie les erreurs. Un mauvais seuil de congestion, une erreur de distribution de routes ou une lacune de télémétrie peut toucher de nombreux services. Un paramètre technique devient alors une décision économique: il modifie à la fois l’infrastructure à financer et le risque opérationnel supporté.

La boucle de contrôle doit survivre à ses concepteurs

Les grands systèmes réseau ne sont jamais déployés une fois pour toutes. Les générations matérielles se succèdent, les charges évoluent, les produits acquièrent de nouvelles exigences et les organisations redistribuent les responsabilités. Une architecture qui ne fonctionne qu’en présence de ses concepteurs n’est pas durable. Le test consiste à savoir si de nouvelles équipes peuvent la modifier tout en conservant une explication intelligible de la demande, des décisions, de l’acheminement et des pannes.

Les principaux projets de Greenberg rendent explicites différentes parties de cette continuité. Les matrices rendent la demande visible; 4D sépare les rôles de contrôle; VL2 dissocie le placement de l’emplacement physique; DCTCP transforme la congestion en retour partagé; Ananta et SWAN attribuent le trafic à l’échelle des services et du réseau étendu; Pingmesh fournit des preuves continues sur les délais et les pertes.

La production transforme ces mécanismes en mémoire institutionnelle. Les interfaces doivent être versionnées, la télémétrie rester comparable malgré les mises à niveau et les modèles de capacité être recalibrés avec les charges. Les exercices de panne doivent éprouver les hypothèses d’indépendance et de réserve. Les retours d’incident doivent changer l’architecture autant que le code lorsqu’une dépendance partagée ou une faiblesse du plan de contrôle est découverte.

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

Le test observable n’est donc pas une nouvelle distinction ni un nouveau titre général. Il consiste à voir 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 vécu. Les nouvelles charges d’IA, les nouveaux matériels et les nouveaux modèles de panne déplaceront sans cesse la cible. Une architecture durable rendra 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.