Résumé: La panne AWS a démarré par une défaillance DNS qui a révélé des dépendances cachées en Europe. Que doivent retenir les équipes de développement logiciel sur mesure, au-delà de l’appel classique à la redondance cloud? Nous mettons l’accent sur les tests de bout en bout, l’intégrité des pipelines CI/CD, et l’organisation des rôles pour maintenir la stabilité et accélérer la reprise.
La semaine dernière, nous avons analysé le risque plateforme, et Amazon Web Services a subi une perturbation mondiale centrée sur US-EAST-1 qui a dégradé plus d’une douzaine de services et impacté des applications grand public et entreprises. Le Monde a évoqué des problèmes DNS, avec des premières alertes à 00:11. Même si le DNS a été « totalement atténué » à 02:24, des pannes en cascade sur Elastic Compute Cloud (EC2) sont apparues vers 03:35. Un second incident majeur, les sondes de santé Network Load Balancing (NLB), est survenu entre 07:00 et 08:00. AWS a respecté ses SLA, cependant de nombreux sites ont signalé 12 à 15 heures d’indisponibilité.
La réaction en Europe a été immédiate et visible.
« Mon robot aspirateur ne marche plus, et quelqu’un peut m’expliquer pourquoi un robot à Paris dépend de serveurs aux États-Unis? » a écrit Ulrike Franke, chercheuse senior au sein de l’European Council on Foreign Relations (ECFR). Son post est devenu viral, car il résumait en deux lignes l’absurdité de cette dépendance.
Les décideurs publics ont réagi dans le même sens. Selon Yahoo Actualités, la panne mondiale d’AWS a mis en évidence la dépendance croissante à l’infrastructure d’Amazon, rappelant qu’un simple incident technique peut perturber des millions d’utilisateurs et d’entreprises dans le monde entier.
Vous n’avez pas acheté AWS directement. Votre fournisseur non plus. Un fournisseur de votre fournisseur, oui.
La chaîne d’interdépendances est apparue dès la dégradation d’US-EAST-1, et un service « européen » a hérité d’une panne distante. Le robot parisien pointait en réalité vers Data Center Alley, en Virginie du Nord.
Un post d’ingénierie sur Reddit a résumé avec ironie: « Le junior IA a commité le changement, le senior IA l’a relu, le test lead IA l’a validé, et le DevOps IA l’a poussé en prod. »
Les développeurs IA font tout. Ils écrivent du code avec Claude et Codex CLI, et génèrent les tests unitaires. Sundar Pichai estime que l’IA produit plus d’un quart du nouveau code chez Google. Satya Nadella annonce une part encore plus élevée chez Microsoft. Andy Jassy est resté silencieux sur le code d’Amazon, mais le CEO d’AWS a été cité dans le scandale du code généré par l’IA.
Amazon, Google, Microsoft, et désormais Meta, tiennent à recruter des ingénieurs « all-star ». Des talents de niveau mondial et des processus innovants soutiennent leur prestige, et ils paient le prix fort. Chez Google ou Amazon, les ingénieurs senior atteignent 520 000 $, les niveaux staff et principal dépassent souvent 700 000 $. Ce surcoût reflète la complexité des systèmes, et place chaque ingénieur sous une pression accrue, travail passé au microscope.
La stratégie « all-star » fonctionne pour les clubs de football les plus riches et pour les méga-entreprises IT/IA. La plupart des entreprises « normales », éditeurs ou prestataires, excellent plutôt avec des équipes multifonctionnelles. La combinaison d’architectes systèmes, développeurs front-end et back-end, QA automatisée et ingénieurs DevOps résout les problèmes clients sans exiger un budget « all-star ».
L’autre effet de cette logique « all-star », c’est la réduction des postes QA dédiés chez les grands acteurs cloud au cours de la dernière décennie. La hausse du coût des visas H-1B, historiquement attribués en majorité à des ingénieurs QA venus d’Inde, accélère la disparition de cette espèce déjà menacée. La qualité est désormais intégrée aux workflows des développeurs et à l’automatisation, et beaucoup d’équipes affichent fièrement zéro QA. Le rôle du sceptique, celui qui ose remettre en question les hypothèses, disparaît rapidement.
Culturellement, on part du principe qu’un ingénieur all-star ne fait pas d’erreur, comme Messi ne marque pas contre son camp. Les tests manuels sont relégués à l’exploration, parfois rejetés comme un anachronisme. Après tout, quel ingénieur respectable voudrait encore inscrire « test manuel » sur son CV ? Résultat : les bugs réapparaissent au pire moment, en production.
Un pipeline CI/CD tombe quand ses hypothèses cèdent en séquence. Ces cascades partent souvent d’un petit changement. En juillet 2024, CrowdStrike a expédié un contenu défectueux qui a touché des millions de Windows, écran bleu à la clé. Contrôles insuffisants, déploiement non étagé, rayon d’explosion immense. Différents environnements, différents processus, mais au final le résultat est le même : des millions de systèmes hors ligne.
Nous travaillons dans l’assurance et d’autres secteurs régulés. Les sinistres, l’onboarding et le service client sont des obligations à la fois légales et réputationnelles. Les pannes ne sont pas abstraites. L’approche ci-dessous reflète cette réalité et place le DevOps au centre, avec la QA intégrée dans la livraison plutôt que traitée comme une étape séparée.
Dans l’assurance, les pipelines sont le vrai système de production. Nous concevons des chaînes simples, traçables et opérables sous stress. Chaque étape, du build au release, reste maîtrisée et récupérable. Résultat : les équipes voient ce qui tourne, corrigent ce qui casse et rétablissent vite le service.
Un test bout en bout a de la valeur seulement s’il reflète l’exploitation réelle. L’objectif est de confirmer que les parcours essentiels tiennent quand la plateforme ralentit, renvoie des données périmées, ou coupe les connexions.
Nous mettons en place des cadres de test qui simulent ces contraintes pour préserver les chemins critiques quand les dépendances dysfonctionnent. Nous concevons une télémétrie indépendante de la région testée, pour garder la visibilité pendant une panne et refléter ce que vivent les utilisateurs, pas seulement ce que rapporte la plateforme.
La panne AWS a montré qu’une dépendance régionale peut se diffuser entre services et continents. La vraie redondance dépasse la sauvegarde. Elle sépare régions, comptes et racines d’identité, afin que les charges critiques continuent quand un plan de contrôle vacille. Tout ne doit pas être multi-région ou multi-cloud, les composants critiques si.
Nous traitons la résilience d’infrastructure dès la phase de conseil et d’architecture. Nous cartographions les dépendances, isolons les charges de travail critiques et concevons les bascules conformes aux exigences de performance et de régulation. Le résultat est une redondance opérationnelle, pas un schéma décoratif.
Après CrowdStrike, focus sur « le fichier qui a cassé Windows ». Après US-EAST-1, focus sur « la dépendance à AWS a cassé Internet ». Le premier cas ressemblait à un manque QA clair. Le second interroge la résilience de chaque maillon externe d’un pipeline CI/CD, aujourd’hui presque tous.
Les hyperscalers ont accru leur vélocité de développement en misant sur des ingénieurs all-star et sur l’automatisation de la qualité. Leurs profits battent des records, difficile donc de contester la méthode. Mais le talent de niveau mondial reste rare par définition. Les autres entreprises doivent compter sur des ingénieurs expérimentés et talentueux, même s’ils ne gagneront jamais de prix Nobel comme Demis Hassabis.
Si la trajectoire actuelle de l’IA se poursuit, une grande partie du travail IT passera aux agents et systèmes automatisés. La panne d’AWS en est un avant-goût du banquet de désastre qui nous attend dans cinq ans, lorsque la majorité du code sera écrite et maintenue par l’IA. Le travail s’interromprait, car de nombreux services dépendraient de la même usine d’IA, alimentée par des puces NVIDIA.
Peut-être qu’à ce moment-là, chacun disposera d’un NVIDIA DGX Spark, déjà capable d’exécuter des modèles de 200 milliards de paramètres. Même avec une IA locale et puissante, la question de la responsabilité dans le développement logiciel restera ouverte.
Le but n’est pas de faire la leçon à un hyperscaler. L’enjeu est d’apprendre et d’appliquer là où cela compte. Cette approche s’inscrit dans une véritable philosophie de l’ingénierie, fondée sur l’analyse des causes, la résilience opérationnelle et la rigueur du cycle SDLC. Nous revisitons ces principes qui structurent nos missions, avec une pertinence particulière pour l’assurance et la finance.
Récapitulatif: la panne AWS rouvre le débat sur le coût EC2 et les arbitrages de dépendance. Elle rappelle que même des infrastructures avancées peuvent trébucher, et que la reprise à l’échelle est possible quand automatisation, visibilité et coordination fonctionnent. Nos équipes opérant déjà sur plusieurs clouds, nous aidons nos clients à concevoir des systèmes multi-cloud ou agnostiques qui équilibrent performance, coûts et résilience. Nos prestations AWS incluent observabilité et monitoring, en complément d’un SOC.
