Fil de 向阳乔木 (@vista8)

Claude 4.5, écrit par Sonnet, est, à mon avis, plutôt bien écrit. (Le texte intégral contient 17 000 mots ; ceci est la première partie.) Le Dieu du Code : Biographie de Jeff Dean Jeff Dean est né à Hawaï le 23 juillet 1968. Cet archipel du Pacifique est connu pour ses volcans, ses plages et sa culture diversifiée, mais on le considère rarement comme un berceau de génies scientifiques. Mais l'enfance de Dean était vouée à être tout sauf ordinaire. Son père, Andy, était chercheur en maladies tropicales. Sa mère, Virginia Lee, était une anthropologue médicale qui parlait six langues. Ce contexte familial a impliqué des migrations internationales tout au long de son enfance : d'Hawaï aux Centres de contrôle et de prévention des maladies à Atlanta, en passant par l'Organisation mondiale de la santé à Genève, pour finalement s'installer au Minnesota. À l'âge de treize ans, il a même séché les trois derniers mois de sa huitième année pour se rendre dans un camp de réfugiés de l'ouest de la Somalie afin d'aider ses parents. Cet environnement en constante évolution a favorisé son intuition précoce concernant les systèmes complexes : **qu’il s’agisse des schémas de transmission des maladies ou, plus tard, du flux de données dans les réseaux informatiques, tous suivaient certaines règles qui pouvaient être comprises, modélisées et optimisées.** Pour s'amuser, le père et le fils ont programmé ensemble un ordinateur équipé de la suite IMSAI 8080. Ils ont soudé des pièces de mise à niveau sur la machine et ont appris à connaître chaque composant. Cette expérience de compréhension des ordinateurs du point de vue matériel deviendra la pierre angulaire de la carrière de Dean. Il comprend non seulement la logique du code, mais aussi comment le courant électrique circule dans la plaquette de silicium. Au lycée, Dean a commencé à écrire un programme de collecte de données appelé Epi Info, destiné aux épidémiologistes. Ce programme est devenu un outil standard dans le domaine, finissant par être distribué à des centaines de milliers d'exemplaires et prenant en charge plus d'une douzaine de langues. Un site web intitulé « The Story of Epi Info », géré par les Centres américains de contrôle et de prévention des maladies (CDC), conserve encore une photo de Jeff prise lors de sa remise de diplôme du lycée. Mais il n'a jamais mentionné cet exploit de sa propre initiative. Des années plus tard, sa femme Heidi a pris conscience de l'importance de ce programme. « Il ne se vante jamais de ces choses-là », dit-elle. « Il faut le lui soutirer. » À l'Université du Minnesota, Dean a choisi une double spécialisation en informatique et en économie. Cette combinaison apparemment inhabituelle révèle en réalité la double dimension de sa pensée : la recherche de l’excellence technologique tout en se concentrant sur l’efficacité des ressources. Il a rencontré Heidi à l'université. Leur premier rendez-vous était d'aller voir un match de basket-ball féminin. Jeff était déguisé en mascotte de gaufre et encourageait les gens. En 1990, il a soutenu sa thèse de licence sur les réseaux neuronaux. Ce détail pouvait paraître insignifiant à l'époque, mais avec le recul de vingt ans plus tard, il apparaît comme un présage du destin. À cette époque, la recherche sur les réseaux neuronaux était en fin de « période de stagnation de l'IA », et la communauté universitaire était généralement pessimiste quant à ses perspectives. Mais le jeune Dean explorait déjà les secrets de la façon dont les machines « apprennent » grâce aux données. Après avoir obtenu son diplôme, Dean a fait un choix inhabituel : au lieu d'aller directement dans une entreprise technologique, il est allé à Genève travailler pour le Programme mondial de lutte contre le sida de l'Organisation mondiale de la santé. Là-bas, il a développé un logiciel de modélisation statistique des épidémies, utilisant du code pour aider les humains à comprendre et à combattre la propagation des maladies mortelles. Cette expérience a façonné sa compréhension initiale de la notion d’« échelle » — non pas l’échelle des clusters de serveurs, mais l’échelle d’une crise sanitaire mondiale. Lorsque votre logiciel doit traiter des données concernant des millions de vies, la « défaillance » n'est plus un terme technique abstrait, mais une véritable tragédie humaine. ## Acte I : La naissance du concepteur de systèmes ### Apprentissage : La magie du compilateur En 1996, Dean a obtenu son doctorat en informatique à l'Université de Washington. Ses recherches doctorales portaient sur les compilateurs. Logiciel qui traduit le code écrit par l'homme en instructions en langage machine optimisées, exécutables par les ordinateurs. « En termes d'attrait, les compilateurs sont parmi les choses les plus ennuyeuses. » Son manager ultérieur, Alan Eustace, a déclaré. En revanche, elles vous amènent « au plus près de la machine ». Un compilateur agit comme un traducteur entre les programmeurs et les machines, et ceux qui optimisent les compilateurs doivent maîtriser à la fois la pensée humaine abstraite et les limitations physiques des puces en silicium. Cette « capacité bilingue » deviendra un atout concurrentiel majeur pour la carrière de Dean. Lorsque Sanjay a décrit Jeff plus tard, il a fait un cercle avec son index près de sa tempe. « Pendant que vous écrivez du code, il a un modèle qui fonctionne dans son esprit », a-t-il déclaré. « Quelles seront les performances de ce code ? » Il envisageait presque automatiquement tous les cas extrêmes. Après avoir obtenu son doctorat, il a rejoint le légendaire laboratoire de recherche DEC Western (acquis plus tard par Compaq). Là-bas, il a travaillé avec un groupe d'ingénieurs de haut niveau, se concentrant sur les outils d'analyse, l'architecture des microprocesseurs et la recherche d'informations. Ces trois années d'expérience ont jeté des bases solides pour son travail ultérieur chez Google : Les outils d'analyse lui ont appris à comprendre les goulots d'étranglement des systèmes, l'architecture des microprocesseurs lui a permis d'acquérir une compréhension approfondie de l'essence du matériel, et la recherche d'informations est le problème fondamental des moteurs de recherche. Jeff a un jour distribué une liste intitulée « Les chiffres de latence que tout programmeur devrait connaître ». En fait, voici une liste de nombres que presque aucun programmeur ne connaît : **L'accès au cache L1 prend généralement une demi-nanoseconde, tandis que la lecture séquentielle d'un mégaoctet en mémoire prend 250 microsecondes.** Ces chiffres sont profondément gravés dans sa mémoire. ### Sanjay : L'autre moitié du cerveau En décembre, Dean a rencontré Sanjay Ghemawat. Sanjay est né à West Lafayette, dans l'Indiana, en 1966, mais a grandi à Kota, une ville industrielle du nord de l'Inde. Son père, Mahipal, était professeur de botanique. Sa mère, Shanta, s'occupait de Sanjay et de ses deux frères et sœurs aînés. Le frère de Sanjay, Pankai, a été le plus jeune professeur titulaire de l'histoire de la Harvard Business School. (Il est aujourd'hui professeur à la Stern School of Business de l'Université de New York.) Pankai et Sanjay fréquentaient la même école et étaient connus pour leur érudition. « Je vis un peu dans l'ombre de mon frère », a déclaré Sanjay. Même à l'âge adulte, il a conservé un don pour l'humilité envers soi-même. Lorsqu'il a été admis à l'Académie américaine des arts et des sciences en 2016, il ne l'a pas dit à ses parents ; ce sont leurs voisins qui le leur ont annoncé. Sanjay n'a eu affaire aux ordinateurs qu'à l'âge de dix-sept ans, lorsqu'il est entré à l'université Cornell. Pendant ses études supérieures au MIT, son conseillère était Barbara Liskov, une informaticienne influente dont les domaines de recherche comprenaient la gestion de bases de code complexes. Selon elle, un bon code est comme un bon article. Cela nécessite une structure bien pensée, où chaque mot doit jouer un rôle. Programmer de cette manière exige de l'empathie pour le lecteur. Cela signifie également considérer le code non seulement comme un moyen d'atteindre un but, mais aussi comme une œuvre d'art à part entière. « Je pense que son plus grand atout est la conception de systèmes », a déclaré Craig Silverstein, le premier employé de Google. « Il suffit de regarder un fichier de code écrit par Sanjay pour constater que sa beauté est comparable à celle d'une sculpture aux proportions harmonieuses. » Au DEC, Jeff marchait deux pâtés de maisons depuis son laboratoire de recherche jusqu'au laboratoire de Sanjay. « Il y avait une gelateria italienne au milieu », se souvient Jeff. Sanjay s'exclama avec enthousiasme : « Alors c'est à cause de ce glacier ! » Ils ont commencé à programmer ensemble : au lieu de travailler sur leurs propres ordinateurs, ils partageaient un seul ordinateur, l'un manipulant le clavier et l'autre le guidant et le corrigeant. Ce type de collaboration est rare dans le développement logiciel. Dans son ouvrage de 2001, *Collaboration Circles: The Dynamics of Friendships and Creative Work*, le sociologue Michael P. Farrell souligne que : « La plupart des intuitions fragiles qui constituent la base de nouvelles perspectives n'émergent ni lorsque le groupe au complet se réunit, ni lorsque les membres travaillent seuls, mais lorsqu'ils collaborent par paires et interagissent entre eux. » C’est Monet et Renoir, travaillant côte à côte durant l’été 1869, qui ont développé le style qui allait devenir plus tard l’impressionnisme. Durant les six années de collaboration qui ont donné naissance au cubisme, Picasso et Braque ne signaient souvent que le dos de la toile pour dissimuler qui avait réalisé quel tableau. « Je ne comprends pas pourquoi davantage de personnes ne font pas cela », a déclaré Sanjay, faisant référence à la programmation en partenariat. « Pour faire de la programmation en binôme, vous devez trouver quelqu'un dont la façon de penser est compatible avec la vôtre, afin que vous puissiez vous compléter mutuellement », a déclaré Jeff. Au milieu de l'année 1999, la bulle Internet approchait de son apogée. Jeff a quitté DEC et a rejoint une petite entreprise appelée « Google ». À l'époque, Google ne comptait que quelques dizaines d'employés et ses bureaux étaient situés dans un bâtiment discret à Mountain View, en Californie. Dix mois plus tard, Sanjay a suivi. Leur collaboration légendaire est sur le point de changer l'histoire d'Internet. ### Mars 2000 : Catastrophe et renaissance Un jour de mars 2000, six des meilleurs ingénieurs de Google se sont réunis dans une salle de crise improvisée. L'entreprise est confrontée à une situation d'urgence sans précédent. En octobre dernier, son système principal — le système chargé d'explorer les pages web pour constituer un « index » — a cessé de fonctionner. Bien que les utilisateurs puissent toujours effectuer des requêtes sur https://t.co/cHDYnkjtpa, ils obtiendront des données datant de cinq mois. Pour ne rien arranger, les cofondateurs de Google, Larry Page et Sergey Brin, négociaient un accord pour fournir un moteur de recherche à Yahoo, promettant de fournir un index dix fois plus important qu'il ne l'était à l'époque. En cas d'échec, https://t.co/cHDYnkjtpa restera bloqué dans le passé, l'accord avec Yahoo échouera probablement et l'entreprise risquera de se retrouver à court de fonds et de faire faillite. Dans une salle de conférence près de l'escalier, les ingénieurs ont installé les panneaux de porte de la scierie et ont branché leurs ordinateurs. Craig Silverstein, le premier employé de Google, était assis près du mur du fond. Lui et un ingénieur système roumain nommé Bogdan Cocosel ont travaillé pendant quatre jours et quatre nuits, mais en vain. « Toutes nos analyses étaient inutiles », se souvient Silverstein. « Tout était cassé, et nous ne savions pas pourquoi. » Silverstein remarqua à peine la présence de Sanjay Gomawater à son arrière gauche. Sanjay avait rejoint l'entreprise il y a seulement quelques mois, après avoir travaillé chez DEC avec Jeff Dean. Dans la salle d'opération, Jeff glissa sa chaise à côté du bureau de Sanjay, se laissant une place vide. Sanjay manipulait le clavier, tandis que Jeff se penchait près de lui, le corrigeant et le guidant comme un producteur chuchotant à l'oreille d'un présentateur de journal télévisé. Jeff et Sanjay ont commencé à examiner de plus près l'indice de stagnation. Ils ont découvert que certains mots manquaient : la recherche de « boîte aux lettres » ne donnait aucun résultat, tandis que d’autres mots étaient mal classés. Pendant des jours, ils avaient cherché des failles dans le code, s'immergeant dans sa logique. Après avoir vérifié chaque section, tout semblait en ordre. Ils n'ont pas pu trouver le bug. Au bout de cinq jours passés en salle d'opération, Jeff et Sanjay commencèrent à soupçonner que le problème qu'ils recherchaient n'était pas logique, mais physique. Ils ont converti le fichier d'index désordonné en sa représentation la plus primitive : **code binaire**. Ils voulaient voir ce que leur machine voyait. Sur l'écran de Sanjay, une colonne dense de 1 et de 0 apparut, chaque ligne représentant un terme d'index. Sanjay a pointé du doigt un nombre qui aurait dû être 0 mais qui était devenu 1. Lorsque Jeff et Sanjay ont rassemblé tous les mots mal ordonnés, ils ont constaté une régularité : chaque mot présentait les mêmes petits défauts. La puce mémoire de leur machine était endommagée pour une raison inconnue. Sanjay regarda Jeff. Google a constaté une augmentation du nombre de pannes matérielles ces derniers mois. Le problème, c'est que la croissance de Google s'accompagne également d'une expansion de son infrastructure informatique. Le matériel informatique tombe rarement en panne, sauf si vous en avez beaucoup – auquel cas il tombera fréquemment en panne. Câbles usés, panne de disque dur, surchauffe de la carte mère. De nombreuses machines ne fonctionnent pas dès le départ ; certaines ralentissent inexplicablement. D'étranges facteurs environnementaux ont également commencé à se manifester. Lorsqu'une supernova explose, l'onde de choc produit des particules de haute énergie qui se dispersent dans toutes les directions ; les scientifiques pensent que ces particules errantes, connues sous le nom de rayons cosmiques, ont une très faible probabilité de heurter les puces informatiques sur Terre et de transformer les 0 en 1. Les systèmes informatiques les plus robustes au monde, tels que ceux utilisés par la NASA et les sociétés financières, utilisent un matériel spécial capable de tolérer les inversions de bits. Mais à l'époque, Google fonctionnait encore comme une start-up, achetant des ordinateurs bon marché dépourvus de cette fonctionnalité. Dans un bâtiment de Santa Clara, en Californie, Google a empilé 1 500 cartes mères et disques durs nus comme des sandwichs dans une tour de 1,80 mètre de haut. En raison d'une panne matérielle, seules 1 200 unités sont opérationnelles. L'entreprise a atteint un tournant. Ses grappes de calcul sont devenues si vastes que même les rares pannes matérielles sont devenues inévitables. Jeff et Sanjay ont écrit ensemble un code pour compenser le dysfonctionnement des machines. Peu de temps après, le nouvel index fut achevé et la salle d'opérations fut dissoute. ### Réécriture du week-end : La naissance des systèmes élastiques Cette crise a marqué un tournant. Jeff et Sanjay ont compris qu'à mesure que Google se développait, les pannes matérielles ne seraient plus accidentelles, mais la norme. Lorsque vous avez des milliers, voire des dizaines de milliers de serveurs, il y aura quotidiennement des pannes machine, des défaillances de disques durs et des interruptions de réseau. Si le système ne peut pas gérer ces pannes, Google ne peut pas évoluer. Ils doivent construire une infrastructure entièrement nouvelle : **un système capable de maintenir l'ordre au milieu du chaos.** La philosophie de conception fondamentale qui sous-tend la réécriture de ce week-end est **s'attendre à l'échec**. Plutôt que de supposer que le matériel est parfait, il est préférable de supposer qu'il *tombera* en panne. Le système doit pouvoir détecter automatiquement les données corrompues, signaler les machines défectueuses et les contourner pour continuer à fonctionner. Cette idée de « tolérance aux pannes » est aujourd'hui une évidence dans les systèmes distribués, mais elle était radicale en 2000. Avant l'effondrement de l'index en mars, le système de Google reposait sur un code écrit par ses fondateurs lorsqu'ils étaient étudiants diplômés à l'université de Stanford. Page et Brin ne sont pas des ingénieurs logiciels professionnels. Ce sont des chercheurs qui mènent des expériences sur les technologies de recherche. Lorsque leur robot d'exploration Web a planté, aucun message de diagnostic n'a fourni d'informations, juste la phrase « Oh là là, cheval ! » Les premiers employés appelaient un logiciel appelé BigFiles, écrit par Page et Brin, « BugFiles » (fichiers remplis d'erreurs). Leur code d'indexation, essentiel à leur fonctionnement, prend des jours à finaliser, et en cas de problème, ils doivent tout recommencer à zéro. Dans le jargon de la Silicon Valley, Google manquait alors de « scalabilité ». Wayne Rosing avait auparavant travaillé chez Apple sur le précurseur de l'ordinateur Macintosh avant de rejoindre Google en novembre 2000 pour gérer son équipe de 100 ingénieurs. « Ce sont eux les dirigeants », a-t-il déclaré. Jeff et Sanjay ont travaillé ensemble pour reconstruire l'infrastructure de Google. Ils travaillent 90 heures par semaine à écrire du code pour qu'une simple panne de disque dur n'entraîne pas le plantage de tout le système. Ils ont ajouté des points de contrôle pendant le processus d'exploration afin qu'il puisse être redémarré en cours de route. En développant de nouveaux schémas d'encodage et de compression, ils ont effectivement doublé la capacité du système. Ce sont des optimiseurs impitoyables. Lorsqu'une voiture tourne, les roues extérieures doivent couvrir une plus grande surface de sol. De même, le bord extérieur d'un disque dur rotatif se déplace plus vite que le bord intérieur. Google a déplacé les données les plus fréquemment consultées vers l'extérieur afin que les bits de données puissent circuler plus rapidement sous la tête de lecture/écriture, mais l'intérieur est à moitié vide ; Jeff et Sanjay utilisaient cet espace pour stocker des données prétraitées pour les requêtes de recherche courantes. En quatre jours, en 2001, ils ont prouvé que l'index de Google pouvait être stocké à l'aide d'une mémoire vive (RAM) rapide au lieu d'un disque dur relativement lent. Cette découverte a remodelé le modèle économique de l'entreprise. Page et Brin savaient que les utilisateurs se tourneraient massivement vers les services capables de fournir des réponses instantanées. Le problème, c'est que la vitesse nécessite une puissance de calcul, et la puissance de calcul coûte cher. Jeff et Sanjay ont astucieusement résolu le problème grâce à un logiciel. Alan Eustace a pris la tête de l'équipe d'ingénierie après le départ de Rossin en 2005. « Pour résoudre le problème de la mise à l'échelle, paradoxalement, il faut comprendre les plus petits détails », a déclaré Eustace. Jeff et Sanjay comprennent les ordinateurs au niveau du bit. Lors des nombreuses réécritures du logiciel principal de Google qu'ils ont contribué à mener, la capacité du système a été multipliée par plusieurs ordres de grandeur. Pendant ce temps, dans l’immense centre de données de l’entreprise, les techniciens empruntent désormais des parcours sinueux, suivant les instructions générées par un logiciel, pour remplacer les disques durs, les alimentations et les modules de mémoire. Même si ses composants s'usent et tombent en panne, le système peut toujours fonctionner normalement. ### MapReduce : Simplifier le chaos En 2004, Dean et Gemmawater ont publié un article intitulé « MapReduce : Traitement simplifié des données sur de grands clusters ». Cet article ne compte que deux auteurs, mais il va bouleverser toute l'industrie. L'idée de base de MapReduce est extrêmement simple : **elle abstrait le calcul distribué complexe en deux fonctions — `Map` et `Reduce`.** La fonction `Map` traite les données d'entrée et génère des paires clé-valeur intermédiaires. La fonction `Reduce` regroupe les valeurs ayant la même clé pour générer le résultat final. Les programmeurs n'ont qu'à définir ces deux fonctions, et le système gérera automatiquement la parallélisation, la planification des tâches, la communication inter-machines et la récupération après panne. La force de cette abstraction réside dans sa **simplicité**. Avant MapReduce, l'écriture de programmes distribués nécessitait une connaissance approfondie des systèmes : il fallait gérer manuellement les threads, la communication réseau et les pannes de machines. Ces complexités dissuadent la plupart des programmeurs. Cependant, MapReduce masque ces complexités au sein du système, permettant ainsi aux ingénieurs sans expérience des systèmes distribués de gérer facilement des téraoctets de données. Un exemple cité dans l'article consiste à compter les occurrences de chaque mot dans un grand nombre de documents. La fonction `Map` lit un document et produit des paires clé-valeur de `(mot, 1)`. La fonction `Reduce` additionne les occurrences des mêmes mots. Le programme entier ne nécessite que quelques lignes de code, mais il peut s'exécuter en parallèle sur des milliers de machines, traitant des pages web sur l'ensemble d'Internet. Une autre contribution clé de MapReduce est sa **tolérance aux pannes**. Le système surveillera en permanence l'exécution de la tâche et, en cas d'échec sur une machine, il la réexécutera automatiquement sur une autre machine. Cette stratégie de « réexécution » fonctionne car les fonctions `Map` et `Reduce` sont conçues pour être « fonctionnelles » — elles ne modifient pas les données d'entrée, elles ne font que produire la sortie. Cela signifie que la réexécution d'une tâche ne produira pas d'effets secondaires et que le résultat sera déterministe. Cette conception s'inspire directement des leçons de la crise de l'an 2000 : le matériel peut tomber en panne, mais le système doit continuer à fonctionner. MapReduce a rapidement gagné en popularité au sein de Google. Il sert à créer des index de recherche, à traiter les données de journalisation, à générer des rapports et à entraîner des modèles d'apprentissage automatique. Au moment de la publication de l'article en 2004, des centaines de programmes MapReduce étaient déjà exécutés au sein de Google. Plus important encore, les idées à l'origine de MapReduce se sont répandues dans toute l'industrie. Yahoo a développé Hadoop, une implémentation open source de MapReduce, basée sur cet article, qui est devenue la pierre angulaire de l'ère du big data. ### Bigtable : L’art du rangement Si MapReduce résout le problème du calcul à grande échelle, Bigtable résout celui du stockage à grande échelle. En 2006, Dean et Gemmawater, ainsi que plusieurs autres ingénieurs de Google, ont publié « Bigtable : un système de stockage distribué pour les données structurées ». Bigtable est conçu pour gérer des pétaoctets de données structurées tout en prenant en charge le traitement par lots à haut débit et les requêtes en temps réel à faible latence. Cela présente une exigence apparemment contradictoire : **le traitement par lots doit analyser de grandes quantités de données, tandis que les requêtes en temps réel doivent renvoyer rapidement un seul résultat.** Les bases de données relationnelles traditionnelles ne peuvent pas satisfaire simultanément à ces deux exigences. La solution de Bigtable est un modèle de données unique : il s'agit d'une « carte multidimensionnelle triée, clairsemée, distribuée et persistante ». Chaque élément de données est indexé selon trois dimensions : clé de ligne, clé de colonne et horodatage. Ce modèle offre une grande flexibilité : - **Clé de ligne** : Les données sont stockées triées par clé de ligne, les clés de ligne adjacentes étant stockées sur la même machine. Cela rend l’analyse d’une plage de données très efficace. - **Familles de colonnes** : Les colonnes sont organisées en familles, et chaque famille peut avoir ses propres politiques de contrôle d’accès et de compression. Cela permet au système d’optimiser le stockage en fonction des différents modèles d’accès. - **Horodatage** : Chaque donnée peut avoir plusieurs versions, distinguées par un horodatage. Le système peut conserver automatiquement les N dernières versions, ou la version des T derniers jours ; les versions plus anciennes seront supprimées. Une autre caractéristique clé de la conception de Bigtable est qu'il ne s'agit *pas* d'une base de données relationnelle. Il ne prend pas en charge les requêtes SQL complexes ni les transactions inter-lignes. Ces limitations sont intentionnelles — elles permettent au système de s'étendre horizontalement sur des milliers de machines sans être entravé par des protocoles de cohérence complexes. Chez Google, Bigtable est utilisé pour stocker les index des pages web, les données géographiques de Google Earth, les données comportementales des utilisateurs issues de Google Analytics, et bien plus encore. Son influence s'est également étendue à l'ensemble du secteur : DynamoDB d'Amazon, Cassandra de Facebook et HBase d'Apache ont tous été inspirés par Bigtable. ### Spanner : Le summum de la cohérence globale MapReduce et Bigtable ont posé les bases de l'infrastructure de Google, mais ils partagent une limitation commune : ils ont été principalement conçus pour être utilisés dans un seul centre de données. Avec l'expansion mondiale de Google, les données doivent être réparties sur tous les continents. Le prochain défi consiste à assurer la cohérence des données à l'échelle mondiale. En 2012, Dean et Gemmawater, ainsi que d'autres ingénieurs, ont publié « Spanner : la base de données distribuée mondiale de Google ». Spanner est la première base de données distribuée au monde à prendre en charge les « transactions distribuées à cohérence externe ». L'innovation majeure de Spanner réside dans l'**API TrueTime**. Dans les systèmes distribués, le temps est une question délicate. Les horloges de différentes machines peuvent être désynchronisées, et la latence du réseau signifie qu'on ne peut pas être sûr de l'ordre réel de deux événements. La solution de Spanner consiste à exploiter le GPS et les horloges atomiques pour construire une API capable de *détecter les incertitudes liées à l'horloge*. TrueTime ne vous dira pas « Il est 12:00:00 maintenant », mais plutôt « Il est 12:00:00 maintenant, avec une marge d'erreur de ±7 millisecondes ». En connaissant précisément cette incertitude, Spanner est capable d'attribuer des horodatages de validation significatifs aux transactions globales. Si l'incertitude est trop grande, le système attendra proactivement que l'incertitude se dissipe — c'est ce qu'on appelle « l'attente de validation ». Cette attente ne prend généralement que quelques millisecondes, mais elle garantit la cohérence externe de la transaction : si la transaction T1 est validée avant la transaction T2, alors l'horodatage de T1 doit être inférieur à l'horodatage de T2. La création de Spanner a marqué l'achèvement de la "Trilogie des systèmes" de Dean. De MapReduce (calcul tolérant aux pannes) à Bigtable (stockage tolérant aux pannes), puis à Spanner (cohérence globale). Ces trois systèmes constituent ensemble le fossé technologique de Google. Ils ont non seulement soutenu les activités principales de Google telles que la recherche, la publicité et Gmail, mais ont également fourni l'infrastructure nécessaire à la vague ultérieure d'intelligence artificielle. En 2025, Spanner a reçu le prix ACM SIGMOD System Award pour avoir « réinventé la gestion des données relationnelles afin d'atteindre la sérialisabilité avec une cohérence externe à l'échelle mondiale ». Il s'agit de la plus récente reconnaissance du travail accompli par Dean et Gemmawater il y a plus de dix ans. ### Effets de queue de l'échelle : le summum de la philosophie des systèmes En 2013, Dean et Gemmawater ont publié un autre article influent : « La queue à l'échelle ». Cet article explore un problème fréquent dans les systèmes à grande échelle mais souvent négligé : la **latence de queue**. Dans le système de Google, une simple requête utilisateur peut nécessiter l'accès à des centaines de serveurs. Même si le temps de réponse moyen de chaque serveur est rapide, si seulement 1 % des serveurs sont lents (par exemple, en raison du nettoyage de la mémoire, des E/S disque ou de la congestion du réseau), cela ralentira la plupart des requêtes des utilisateurs. En effet, les requêtes des utilisateurs doivent attendre les réponses de *tous* les serveurs, et c'est le serveur le plus lent qui détermine la latence globale. L’idée fondamentale de cet article est que tenter d’éliminer toutes les sources de retard est « irréaliste ». Le matériel tombera en panne, les réseaux seront saturés et les systèmes d'exploitation connaîtront des ralentissements. Plutôt que de viser la perfection, il est préférable de concevoir un système « tolérant aux pannes », un concept qui fait écho à sa philosophie post-crise de 2000, axée sur la conception de systèmes « tolérants aux pannes ». L'article propose une série de techniques pour remédier à la latence de queue : - **Requête de couverture** : Envoyer la même requête à plusieurs répliques et utiliser la réponse la plus rapide. - **Requête de liaison** : Envoie une requête à plusieurs répliques, mais annule les requêtes aux autres répliques une fois qu’une réplique a commencé le traitement. - **Micro-partitionnement** : Divise les données en partitions plus petites, permettant une migration plus flexible de la charge de travail entre les machines. - **Réplication sélective** : Créez davantage de répliques pour les données fréquemment consultées afin de répartir la charge. L'idée centrale de ces technologies est de construire des services performants et élastiques sur du matériel peu fiable et à vitesse inégale grâce à la redondance et à une planification intelligente. En 2025, « The Tail at Scale » a reçu le prix ACM SIGOPS Hall of Fame, qui récompense sa capacité à « résister à l'épreuve du temps ». Ce document a non seulement influencé la conception du système de Google, mais il est également devenu un document de référence dans l'ensemble du secteur. ### Dean et Gemmawater : une collaboration légendaire Lorsqu'on raconte l'histoire de Dean, on ne peut faire l'impasse sur sa collaboration avec Sanjay Gormwalt. Ils sont les *seuls* auteurs de l'article sur MapReduce, les concepteurs principaux de Bigtable et Spanner, et co-auteurs de « The Tail at Scale ». Ils ont commencé à collaborer chez DEC, ont surmonté ensemble la « crise de l'an 2000 » chez Google et ont travaillé ensemble pour bâtir les fondements technologiques de Google pour les deux décennies suivantes. En 2012, ils ont reçu conjointement le prix ACM Computing Award en reconnaissance de leur « conception, de leur design et de leur mise en œuvre de l'infrastructure logicielle révolutionnaire de Google ». En 2009, ils ont tous deux été élus membres de l'Académie nationale d'ingénierie. Leur collaboration a été décrite comme « l'amitié qui a sauvé Google et inventé l'internet moderne ». Mais ce partenariat a également donné naissance à un phénomène culturel intéressant : les « faits sur Jeff Dean ». ### "Mème Jeff Dean" : Admiration et regret Aux alentours du 1er avril 2007, une série de blagues sur Jeff Dean ont commencé à circuler en interne chez Google, imitant la « blague sur Chuck Norris ». Ces blagues exagéraient les compétences techniques de Dean, par exemple : - « Jeff Dean a écrit directement le code binaire ; le code source n'était qu'une documentation destinée à être lue par d'autres. » - « Le clavier de Jeff Dean n'a pas de touche Ctrl, car il a toujours le contrôle. » - « Le compilateur n'avertira pas Jeff Dean. C'est Jeff Dean qui avertira le compilateur. » « La vitesse de la lumière dans le vide était autrefois très lente, mais Jeff Dean a optimisé la physique en un seul week-end. » Ces mèmes se sont rapidement répandus au sein de Google, puis ont imprégné l'ensemble du secteur technologique. Ces témoignages reflètent l'admiration des ingénieurs pour Dean : il n'était pas seulement un expert technique hors pair, mais aussi un « dieu du code » capable de résoudre n'importe quel problème. Mais ces mèmes posent aussi un problème : ils donnent l'impression que « Jeff est meilleur que Sanjay ». En réalité, les contributions de Dean et de Gemmawater étaient égales, et leur collaboration était complémentaire. Le créateur du mème aurait par la suite exprimé des regrets, estimant que « la seule raison était que le nom 'Jeff' semblait 'plus intéressant' ». Ce détail révèle le décalage entre la perception du public et la réalité historique. La légende de Dean n'est pas l'œuvre d'un seul homme, mais une collaboration qui dure depuis plus de 20 ans.