Joseph HE

Le jeudi 12 juin 2025 restera gravé dans les annales comme une journée où l'internet a montré ses failles. Une panne généralisée a frappé un large éventail de services et de sites web populaires, révélant la vulnérabilité intrinsèque d'un écosystème numérique de plus en plus dépendant d'un nombre restreint de géants de l'hébergement.

La fragilité de notre écosystème numérique​

Cette panne a brutalement mis en lumière à quel point notre accès quotidien à internet repose sur une poignée d'acteurs majeurs. Comme l'a souligné Tim Marcin de Mashable, cet incident "peint un tableau de la fragilité de notre écosystème internet lorsque des rouages essentiels fonctionnent mal." Il est clair que de nombreux services couramment utilisés dépendent d'un petit nombre de grands fournisseurs, et un dysfonctionnement chez l'un d'eux peut avoir des répercussions en cascade considérables.

Les noms qui reviennent sont bien connus : AWS (Amazon Web Services), Google Cloud, Azure (Microsoft) et Cloudflare. La panne du 12 juin a principalement impliqué Google Cloud et Cloudflare, montrant une interdépendance qui a surpris même les experts de l'industrie.

Google Cloud au cœur de la tempête​

Au centre de cette interruption se trouvait un problème avec Google Cloud Platform (GCP). Google a rapidement reconnu des "problèmes avec son système de gestion d'API." Thomas Kurian, le PDG de Google Cloud, a présenté ses excuses, confirmant un rétablissement complet des services.

Ce qui est ressorti de cette situation, c'est une dépendance insoupçonnée de Cloudflare vis-à-vis de Google Cloud. Longtemps perçu comme ayant une infrastructure entièrement indépendante, Cloudflare a révélé que certains de ses services clés s'appuyaient sur GCP, notamment pour une "solution de stockage à froid à long terme" liée à son service Worker KV. Initialement, Cloudflare a attribué la faute à Google Cloud, affirmant qu'il s'agissait d'une "panne de Google Cloud" affectant un nombre limité de ses services.

L'impact en cascade de Cloudflare Worker KV​

Le service Cloudflare Worker KV (Key-Value) s'est avéré être le talon d'Achille de Cloudflare. Décrit comme un "magasin clé-valeur" et un "cœur pour des tonnes d'autres choses", sa défaillance a entraîné une cascade d'incidents.

La panne a duré 2 heures et 28 minutes, impactant mondialement tous les clients de Cloudflare utilisant les services affectés, y compris Worker KV, Warp, Access Gateway, Images, Stream, Workers AI, et même le tableau de bord Cloudflare lui-même. Cette situation a clairement démontré que Worker KV est une "dépendance critique pour de nombreux produits Cloudflare et est utilisé pour la configuration, l'authentification et la livraison d'actifs."

Transparence et responsabilité : l'exemple de Cloudflare​

Un aspect remarquable de cet incident a été la réaction de Cloudflare en termes de transparence et de prise de responsabilité. Bien que la cause première ait été attribuée à Google Cloud, Cloudflare a publié un rapport d'incident d'une rare franchise. Dane, le PDG de Cloudflare, a déclaré : "Nous avons laissé tomber nos clients chez Cloudflare aujourd'hui. [...] C'était un échec de notre part, et bien que la cause ou le déclencheur immédiat de cette panne ait été une défaillance d'un fournisseur tiers, nous sommes en fin de compte responsables de nos dépendances choisies et de la manière dont nous choisissons d'architecturer autour d'elles."

Cette attitude a été largement saluée comme un modèle d'entreprise, montrant une "volonté de partager les taux d'erreur absurdement élevés" et l'absence de "blâme envers Google" dans leur rapport, prouvant un engagement fort envers la transparence.

Leçons apprises et atténuation future​

Cloudflare a rapidement identifié et commencé à travailler sur des solutions. Le rapport d'incident détaille une chronologie rapide de la détection et de la classification de l'incident au plus haut niveau de gravité (P0). L'entreprise prévoit de renforcer la résilience de ses services en réduisant les dépendances singulières, notamment en migrant le stockage à froid de Worker KV vers R2, leur alternative à S3, pour éviter de dépendre d'infrastructures de stockage tierces.

Ils travaillent également à "implémenter des outils qui leur permettent de réactiver progressivement les espaces de noms pendant les incidents d'infrastructure de stockage," assurant que les services critiques puissent fonctionner même si l'ensemble du service KV n'est pas encore complètement rétabli.

La panne du 12 juin 2025 a servi de rappel brutal de l'interdépendance croissante du web et de l'importance cruciale de la redondance et de la diversification des dépendances, même pour les géants de l'hébergement. Elle nous pousse à réévaluer la résilience de nos architectures numériques et à renforcer la collaboration entre les acteurs pour un internet plus robuste.

source:https://mashable.com/article/cause-internet-outage-google-cloud-what-happened-june-12

La Disparition Silencieuse de Stack Overflow : Plus Qu'une Simple Histoire d'IA​

Vous souvenez-vous de Stack Overflow ? Pendant plus d'une décennie, c'était la cathédrale numérique incontestée des développeurs, le premier onglet que vous ouvriez lorsqu'un problème de code vous laissait perplexe. C'était le cerveau collectif du monde de la programmation, un lieu où les réponses étaient forgées grâce à la sagesse collective de la communauté et à une révision rigoureuse par les pairs.

Dans l'univers des startups tech est souvent fait de promesses grandioses, mais parfois, la réalité est bien plus terre à terre, voire choquante. L'affaire Builder AI en est un exemple frappant. Cette startup de développement "no-code", qui avait réussi à lever des centaines de millions de dollars et à s'attirer le soutien de géants comme Microsoft, a récemment fait la une pour de bien mauvaises raisons. La révélation ? Sa plateforme phare, censée être révolutionnaire et alimentée par une IA nommée Natasha, était en fait... un travail manuel réalisé par 700 ingénieurs humains basés en Inde.

C'est une histoire qui soulève de sérieuses questions sur l'exagération des capacités de l'IA dans l'écosystème des startups, les pratiques financières douteuses et la ligne de plus en plus floue entre l'automatisation assistée par l'homme et la véritable intelligence artificielle.

L'escroquerie au cœur de Builder AI : Natasha, l'IA qui n'en était pas une​

L'idée centrale de l'affaire est simple : Builder AI a commercialisé un produit en le présentant comme une merveille d'intelligence artificielle, alors qu'en coulisses, les demandes des clients étaient traitées par une armée d'humains. La source va jusqu'à qualifier cela de "biggest scam in the history of AI".

La promesse ? Une plateforme capable d'assembler des applications logicielles "comme des briques Lego" grâce à un assistant IA appelé Natasha. La réalité ? "Natasha neural network turned out to be 700 Indian programmers." Chaque requête client était envoyée à un bureau en Inde, où ces 700 ingénieurs écrivaient le code à la main. C'est "absolutely incredible," comme le souligne l'auteur.

Quand le travail humain se déguise en IA : Un schéma récurrent ?​

Ce n'est malheureusement pas un cas isolé. La source souligne que cette pratique de masquer un travail humain bon marché derrière un vernis d'IA n'est pas nouvelle. On a vu des entreprises prétendre à l'IA alors qu'elles s'appuyaient sur "a group of Indians that they hire on the back end and they call it and they call it AI".

Cela ouvre même une réflexion sur la complexité : ces ingénieurs indiens utilisaient-ils eux-mêmes des outils d'IA pour "prompter" et maintenir le rythme ? La frontière entre "AI-powered" et "human-assisted by AI" devient dangereusement poreuse.

La qualité sacrifiée sur l'autel de la tromperie​

Malgré l'utilisation de 700 ingénieurs, les résultats étaient loin d'être à la hauteur. Les produits livrés étaient "buggy, dysfunctional and difficult to maintain". Le code était décrit comme "unreadable" et les fonctions "did not work". Une ironie mordante quand on prétend délivrer de l'innovation par l'IA. "Nice okay everything was real artificial intelligence except the uh except that none of it was," commente la source avec sarcasme.

La chute financière : 445 millions de dollars envolés​

Grâce à cette supercherie, Builder AI a réussi à attirer 445 millions de dollars d'investissements sur huit ans, avec des noms prestigieux comme Microsoft à son tableau d'honneur. Mais le château de cartes n'a pas résisté. La chute a été brutale : un défaut de paiement envers le créancier Viola Credit, qui a saisi 37 millions de dollars des comptes de l'entreprise, a paralysé ses opérations. Des fonds supplémentaires en Inde sont restés bloqués par des restrictions réglementaires.

Après l'exposition de la tromperie, la startup a officiellement fait faillite. C'est une fin "absolutely ridiculous" pour une entreprise qui se voulait à la pointe de la technologie.

L' "Endgame" des escroqueries de l'IA : Le "Fake it till you make it" poussé à l'extrême ?​

Pourquoi une telle entreprise ? Qu'est-ce qui motive des fondateurs à s'engager dans une telle voie ? Est-ce simplement pour "ride the hype" de l'IA et "embezzle money" ? La source s'interroge sur l'intention.

Une hypothèse est qu'il s'agissait initialement d'un produit différent qui a muté. Les fondateurs auraient pu croire qu'ils pourraient utiliser les développeurs comme une solution temporaire ("stop gap") en attendant de développer une véritable IA, mais qu'ils ont échoué à atteindre cet objectif. C'est le "fake it till you make it" poussé à son paroxysme, avec des conséquences désastreuses.

L'IA doit "multiplier les rôles", pas les "remplacer"​

L'auteur de la source exprime un profond scepticisme envers les entreprises d'IA qui se vantent de pouvoir "remplacer tous les ingénieurs". Il suggère qu'une approche plus saine et plus réaliste pour l'IA est de construire des outils qui "multiplient les rôles" des ingénieurs, en les rendant plus efficaces ou en simplifiant leur travail, plutôt que de chercher à les éliminer.

Les systèmes "fully working independent AI sucks," conclut-il, arguant que nous devrions avoir compris après "3 years" que l'IA autonome totale est moins efficace que l'IA qui assiste les humains.

Une connexion avec Versailles Innovations​

Au milieu de cette débâcle, le nom de Versailles Innovations a fait surface en raison de son association commerciale avec Builder AI à partir de 2021. La co-fondatrice de Versailles, qui était aussi l'ancienne directrice générale de Facebook en Inde, a nié toute faute financière ou irrégularité dans les transactions avec Builder AI, qualifiant les allégations d' "absolutely baseless and false".

L'affaire Builder AI est un rappel brutal des dangers du "vaporware" et de la "hype" excessive autour de l'IA, surtout lorsque des sommes colossales sont en jeu. Elle souligne que le remplacement complet du travail humain par l'IA est encore un fantasme, et que les outils d'IA les plus prometteurs sont ceux qui augmentent les capacités humaines, plutôt que ceux qui prétendent les anéantir en secret. C'est une leçon coûteuse pour les investisseurs et une mise en garde pour le secteur technologique tout entier.

Le langage de programmation C. Il est souvent salué comme la « mère de presque tous les langages modernes », formant la pierre angulaire de tout, des systèmes d'exploitation et compilateurs aux moteurs de jeu et outils de chiffrement. Sa puissance et son contrôle de bas niveau sont inégalés, le rendant indispensable pour les infrastructures critiques. Pourtant, cette même puissance s'accompagne d'une responsabilité exigeante : la gestion manuelle de la mémoire.

À la différence des langages dotés d'un ramasse-miettes automatique, le C oblige les développeurs à « grandir et à gérer la mémoire par eux-mêmes ». Cela signifie allouer de la mémoire avec malloc et la libérer scrupuleusement avec free une fois qu'elle n'est plus nécessaire. Ce contrat apparemment simple entre malloc et free cache un champ de mines de pièges potentiels. Une mauvaise gestion de cette responsabilité peut entraîner des vulnérabilités de sécurité catastrophiques et une instabilité du système, se manifestant souvent par un « comportement indéfini » – un cauchemar pour les programmeurs, où tout peut arriver, d'un dysfonctionnement mineur à une compromission complète du système.

Examinons quelques-unes des erreurs de gestion de la mémoire les plus courantes et les plus dangereuses en C, illustrées par des incidents historiques tristement célèbres.

Les périls du C : Risques courants liés à la gestion de la mémoire​

1. Les débordements de tampon (Buffer Overflows) : Quand les données débordent

Un débordement de tampon se produit lorsqu'un programme tente d'écrire plus de données dans un tampon de taille fixe qu'il n'a été alloué pour en contenir. Le C, de par sa conception, n'effectue pas de vérification automatique des limites. Cette absence de filet de sécurité signifie que si vous écrivez au-delà de la fin d'un tableau ou d'un tampon, vous pouvez écraser des données adjacentes en mémoire, y compris des instructions de programme critiques ou des adresses de retour sur la pile.

Les conséquences sont graves : comportement indéfini, plantages du programme ou, le plus dangereusement, exécution de code arbitraire. Un exemple classique est le ver Morris de 1988. Ce fléau des débuts d'Internet exploita des débordements de tampon dans des utilitaires UNIX courants comme Fingered et Sendmail pour injecter du code malveillant, infectant environ 10 % d'Internet à l'époque. Une simple vérification conditionnelle de la taille de l'entrée aurait pu éviter ce chaos généralisé.

2. Heartbleed : Une leçon sur les vérifications de longueur manquantes

Bien qu'il s'agisse d'un type spécifique de débordement de tampon, la vulnérabilité Heartbleed (2014) dans l'extension heartbeat d'OpenSSL illustre parfaitement le danger des validations de longueur manquantes. Le serveur était conçu pour renvoyer un message de « battement de cœur » d'un client. Le client déclarait une certaine longueur de message, puis envoyait les données. La faille ? Le code du serveur ne vérifiait pas si la longueur réelle du message reçu correspondait à la longueur déclarée.

Les attaquants pouvaient envoyer un message minuscule (par exemple, « hello ») mais le déclarer d'une longueur de 64 000 octets. Le serveur, faisant confiance à la longueur déclarée, lisait et renvoyait alors 64 000 octets de sa propre mémoire, y compris le message « hello » plus 63 995 octets supplémentaires de tout ce qui se trouvait immédiatement après le message en mémoire. Cela a permis aux attaquants de divulguer passivement des données sensibles comme des clés de chiffrement privées, des noms d'utilisateur et des mots de passe, affectant de vastes pans d'Internet.

3. Le "Use-After-Free" : Accéder à une mémoire fantôme

Cette vulnérabilité apparaît lorsqu'un programme tente d'accéder à un bloc de mémoire après qu'il a été libéré à l'aide de free(). Une fois la mémoire libérée, le système d'exploitation peut la réallouer à d'autres fins. Si un pointeur pointe toujours vers cette mémoire maintenant libérée (et potentiellement réallouée), y accéder peut entraîner :

• Plantages : Si la mémoire a été réallouée et son contenu modifié, y accéder peut faire planter le programme.
• Corruption des données : Écrire dans une mémoire réallouée peut corrompre d'autres parties du programme, voire d'autres programmes.
• Exécution de code arbitraire : Un attaquant peut intentionnellement déclencher un "use-after-free", faire en sorte que la mémoire soit réallouée avec des données malveillantes, puis exploiter l'ancien pointeur pour exécuter son propre code.

La vulnérabilité d'Internet Explorer 8 (2013) en a fait la démonstration. Elle impliquait que JavaScript supprimait des éléments HTML, mais un pointeur vers l'objet libéré persistait. Un attaquant pouvait alors créer une page web malveillante qui déclencherait le "use-after-free", menant à la compromission du système par la simple visite du site.

4. Les erreurs de décalage (Off-By-One Errors) : La petite erreur de calcul à fort impact

Les erreurs de décalage sont des erreurs subtiles de calcul, impliquant souvent les limites de boucle ou l'indexation de tableau. En C, une manifestation courante est d'oublier de tenir compte du caractère de fin de chaîne (\0) lors de l'allocation d'espace pour les chaînes. Par exemple, si vous devez stocker une chaîne de 10 caractères, vous avez en fait besoin de 11 octets (10 pour les caractères + 1 pour \0).

Ces erreurs apparemment mineures peuvent entraîner des débordements de tampon (écriture d'un octet au-delà de la fin allouée) ou d'autres accès hors limites, provoquant un comportement imprévisible ou ouvrant des portes à l'exploitation.

5. La double libération (Double Free) : Libérer ce qui a déjà été libéré

Appeler free() deux fois sur le même bloc de mémoire est une « double libération ». Cela entraîne un comportement indéfini immédiat et peut gravement corrompre les structures de données internes utilisées par l'allocateur de mémoire (comme malloc et free).

Les implications sont graves :

• Plantage du programme : Le programme peut planter immédiatement en raison d'une corruption de la mémoire.
• Corruption du tas (Heap Corruption) : L'état interne du gestionnaire de mémoire peut devenir incohérent, entraînant un comportement imprévisible par la suite.
• Exécution de code arbitraire : Un attaquant sophistiqué peut souvent manipuler les structures du tas via une double libération pour obtenir des primitives de lecture/écriture arbitraires, conduisant finalement à l'exécution de code à distance. Lorsque votre code entre dans le territoire du comportement indéfini, « tous les paris sont ouverts ».

Conclusion : La nature imprévisible du comportement indéfini​

Le fil conducteur de ces erreurs de gestion de la mémoire est le « comportement indéfini ». Lorsque votre code C présente un comportement indéfini, le compilateur et l'environnement d'exécution sont libres de faire n'importe quoi. Votre programme peut sembler fonctionner, il peut planter, ou, le plus terrifiant, il pourrait créer une vulnérabilité subtile qu'un attaquant peut exploiter méticuleusement pour prendre le contrôle de votre système.

La puissance du C est indéniable, mais elle s'accompagne d'une exigence non négociable de minutie dans la gestion de la mémoire. Les incidents historiques soulignés ici servent de rappels frappants qu'un seul oubli dans la manipulation de malloc et free peut avoir des conséquences dévastatrices et concrètes. La programmation C sécurisée ne consiste pas seulement à écrire du code correct ; il s'agit d'anticiper et de prévenir toutes les manières possibles de mal gérer la mémoire.

Pourquoi Facebook (Meta) a-t-il dit "non" à Git ? Une histoire de scaling, de communauté et de monorepos géants​

Dans le monde du développement logiciel, Git est omniprésent. C'est l'outil par défaut pour des millions de développeurs et de projets, une évidence presque "aussi courante que l'eau", comme le souligne l'auteur de notre source. On le perçoit comme la seule solution viable pour gérer le code. Alors imaginez la surprise de découvrir que Facebook (aujourd'hui Meta), l'une des plus grandes entreprises technologiques du monde, n'utilise pas Git comme système de contrôle de version principal pour ses immenses monorepos.

C'est une histoire fascinante qui met en lumière des défis d'ingénierie à une échelle colossale, les limites d'outils populaires, et l'importance cruciale des facteurs humains dans les décisions technologiques. Plongeons dans les raisons pour lesquelles Meta a choisi un chemin différent.

L'étonnante absence de Git chez Meta​

Pour beaucoup, l'idée que Facebook ne tourne pas sous Git est contre-intuitive. L'auteur, dont l'expérience personnelle des systèmes de contrôle de version a commencé avec SVN avant l'explosion de Git, confesse sa propre surprise : "Throughout my life a git was common as water it was so common in fact that I assumed it was the only viable tool for creating and managing code changes". Il raconte comment les ingénieurs de Facebook qu'il a rencontrés étaient "deeply trained on material patterns and Facebook stack diffs workflow" plutôt que sur Git.

Historiquement, même Google, dont l'ingénierie "predates git by over 5 years," utilise son propre système interne. Mais pour Facebook, c'était une décision plus active et récente.

Le mythe de la complexité de Git (et pourquoi ce n'était pas la raison principale)​

Avant d'aborder les vraies raisons, il est intéressant de noter que la "difficulté" perçue de Git n'était pas le moteur de cette décision. L'auteur lui-même s'interroge : "I've never understood this kind of commenting get is so confusing how is G confusing like what about git is confusing". Il attribue souvent cette confusion à un manque d'apprentissage fondamental, suggérant que "most of you have just never taking taken the two hours of time it takes to learn get well enough to not be confused by any of it."

Non, la raison du virage de Facebook était bien plus profonde et technique.

Le cauchemar du scaling en 2012 : Quand Git a atteint ses limites​

Le véritable point de rupture s'est produit autour de 2012. À cette époque, la base de code de Facebook était déjà "many times larger than even the Linux kernel" (qui comptait 17 millions de lignes et 44 000 fichiers). Avec une croissance exponentielle, Git a commencé à montrer des signes de faiblesse significatifs pour les opérations sur un monorepo aussi gigantesque.

Le goulot d'étranglement clé ? Le processus de "statting" (vérification de l'état) de tous les fichiers. "G examines every file and naturally becomes slower and slower as the number of files increase." Les opérations Git de base, loin d'être "crippling slow," étaient suffisamment lentes pour justifier une enquête approfondie. Les simulations étaient "horrifying," montrant que de simples commandes Git pourraient prendre "over 45 minutes to complete" à mesure que la base de code continuait de croître. C'était intenable pour des milliers d'ingénieurs.

L'appel à l'aide et la réponse surprenante des mainteneurs de Git​

Face à ces défis, l'équipe de Facebook a fait ce que beaucoup d'entreprises technologiques auraient fait : elle a contacté les mainteneurs de Git. Leur objectif était de collaborer pour étendre Git et mieux prendre en charge les grands monorepos.

Cependant, la réponse a été inattendue et, selon l'auteur, "wasn't cooperative." Les mainteneurs de Git "pushed back on improving performance and instead recommended that Facebook shared the uh Shard their monor repo" (diviser leur monorepo en plusieurs dépôts).

Cette suggestion, bien que techniquement possible, était un "non-starter" pour Facebook. Ils avaient investi massivement dans un workflow de monorepo et la complexité d'une telle fragmentation aurait été énorme. Plus surprenant encore, Facebook s'attendait à ce que leur offre de "free open source labor by a major tech company is well received," une opportunité d'améliorer un projet open source largement utilisé. Le manque de coopération a été un facteur décisif.

Mercurial : L'alternative inattendue et son architecture propre​

Face aux limitations de Git et au manque de soutien pour les monorepos massifs, Facebook a exploré des alternatives. En 2012, les options étaient "scarce". Perforce a été écarté en raison de défauts architecturaux perçus. C'est là que Mercurial est entré en scène.

Mercurial avait des performances "similar to git," mais possédait une architecture bien plus propre. Alors que Git était une "complex web of bash and C code," Mercurial était "engineered in Python using object-oriented code patterns and was designed to be extensible." Cette extensibilité était cruciale.

L'équipe a décidé d'assister à un hackathon Mercurial à Amsterdam. Ce qu'ils ont découvert n'était pas seulement un système flexible, mais aussi "a community of maintainers who were impressively welcoming to aggressive changes by the Facebook team." C'était le contraste parfait avec leur expérience précédente.

La migration interne : Une masterclass en gestion du changement​

Convaincre l'ensemble de l'organisation d'ingénierie de migrer de Git vers Mercurial était une tâche "intimidating." Les ingénieurs peuvent être "extremely sensitive about tooling changes." Pourtant, ce qui a suivi "sounds like a masterclass in internal Dev tools migrations."

L'équipe a méthodiquement :

1. Socialisé l'idée : Communiquer la nécessité et les avantages.
2. Documenté les workflows : S'assurer que chacun savait comment utiliser le nouvel outil.
3. Écouté les préoccupations : Permettre aux développeurs d'exprimer leurs doutes.
4. Basculé en force : Couper le cordon avec Git une fois que le terrain était prêt.

Le succès de cette migration massive est également attribué, avec une pointe d'ironie, au fait que peu d'ingénieurs de Facebook connaissaient Git en profondeur. Comme l'auteur le note, "it's not even a big deal" de changer d'outil si les ingénieurs ne sont pas attachés à des subtilités spécifiques de Git.

L'héritage de la décision de Facebook : Stack Diffs et un Mercurial amélioré​

La décision de Facebook n'a pas été sans conséquences pour l'écosystème open source :

• Mercurial amélioré : Facebook a "contributed performance improvements to Mercurial making it the best option for large monor repos."
• Les "Stack Diffs" : S'appuyant sur les concepts de Mercurial, Facebook a créé un workflow innovant de revue de code appelé "stack diffs" (diffs empilés). Cela a "unlocking novel code review parall parallelization" et a révolutionné leur processus de développement. Des ex-ingénieurs de Facebook ont exporté ce workflow vers d'autres entreprises, créant un "small but vocal Cult of Stack diff Enthusiast," inspirant même l'auteur à créer des outils comme Graphite.

Le facteur humain et l'évolution constante de la technologie​

En fin de compte, l'histoire de Facebook et de Git est un rappel poignant que "so many of History's key technical decisions are human driven not technology driven." La réceptivité d'une communauté, l'adaptabilité d'une équipe et la capacité à collaborer peuvent l'emporter sur des avantages techniques perçus.

Il est également crucial de noter que le paysage a évolué. "A decade later GI has made significant improvements to support monor repos... today get now with some knowledge of how to do it operates well with really really large repos now." Git a progressé, et il est possible qu'il puisse aujourd'hui gérer les besoins de Facebook.

L'histoire de Facebook est celle d'une entreprise qui a dû s'adapter à une croissance fulgurante. Face aux limites de performance d'un outil pourtant dominant, et à une communauté qui n'était pas prête à soutenir ses besoins spécifiques à l'époque, ils ont fait un choix pragmatique. Ce n'était pas un rejet de Git en soi, mais une réponse à un problème de scaling unique, résolue avec une solution innovante, et un témoignage du pouvoir des décisions humaines dans l'ingénierie à grande échelle.