Intrinsèquement résilients ? Quand les géants technologiques trébuchent
Pour que les infrastructures cloud fassent la Une des médias grand public, il faut qu’il y ait eu une actualité choquante que les particuliers aient ressenti dans leur quotidien. Autrement dit, une perturbation de « l’internet mondial » comme le veut l’expression consacrée. C’est bien ce qui s’est passé lundi avec la panne aux États-Unis d’Amazon Web Services (AWS). Entre-temps, pendant plus de quinze heures, le public a pu constater l’impact sur les réservations Airbnb, les transactions en ligne, les communications WhatsApp, les jeux-vidéos ou même les IA génératives chatGPT et Perplexity. L’occasion pour certains de découvrir le fonctionnement (et la concentration) de nos activités autour de quelques plateformes technologiques. Il est d’ailleurs intéressant de voir que sur des articles à destination du grand public comme ceux publiés sur Le Monde ou Le Nouvel Obs, c’est bien cette situation de dépendance, en particulier vis-à-vis de géants américains qui est épinglée. Mais au-delà des considérations géostratégiques, l’événement illustre la difficulté de résilience auxquelles sont confrontées les organisations, et même les plus grandes d’entre elles.
Pannes en cascade
« Cette panne particulière met en évidence les problèmes fondamentaux liés à la résilience du cloud, qui découlent d'une dépendance excessive à des services tels que le DNS, qui n'ont pas été conçus pour répondre aux exigences technologiques de l'ère du cloud » a mis notamment en avant Brent Ellis, analyste chez Forrester, dans une communication suite à la panne. Pour lui, cet incident majeur (le quatrième en cinq ans sur la région Est des Etats-Unis), souligne le risque de concentration systémique autour d’un fournisseur de cloud. Mais il met aussi en lumière le fait que le problème est aussi lié à la complexité et aux « dépendances logiques à travers la plateforme. DynamoDB, le premier service identifié comme étant affecté par les problèmes DNS, joue un rôle central dans d'autres services AWS pour l'analyse, l'apprentissage automatique, la recherche, etc. » détaille-t-il. Et effectivement, l’analyse de la panne montre que si AWS a réussi à rectifier le problème initial en moins de deux heures, l’entreprise a ensuite dû courir après les défauts en cascade que celui-ci avait propagés en aval, luttant contre une propagation de pannes, beaucoup plus problématiques.
La belle promesse de résilience
De quoi faire dire que la fragilité devient inhérente à la façon dont sont conçus les grandes plateformes cloud. L’analyste reconnaît que le problème n’est pas l’apanage d’AWS, mais il épingle le caractère de plus en plus récurrent de la situation et le fait que par nature les « clients sont laissés pour compte lorsqu’il s’agit de faire face aux conséquences », alors que le fournisseur cloud s’appuie sur son « modèle de responsabilité partagé » dans ses contrats pour soutenir qu’il n’y a pas, in fine, de manquement à la promesse de résilience. Cette dernière est pourtant sous-jacente à la proposition de valeur des hyperscalers depuis des années : prendre le parti des géants américains, c’est bénéficier de la fiabilité de leur service due à leurs capacités massives par rapport à d’autres acteurs. Malheureusement, l’engagement en matière de commodité d’usage se retrouve régulièrement percuté par les difficultés à gérer « des dépendances complexes et imbriquées » de nature à fissurer l’image de fiabilité.
Des méthodes pour reprendre la main
L’analyste va plus loin : pour lui, l’interdépendance des services, l’externalisation généralisée des logiciels et la visibilité « quasi nulle » sur les dépendances, est une combinaison délétère. « [Ce] n'est pas un bug, mais bien une caractéristique d'un risque hautement concentré ». Une situation qui jette une lumière crue sur le mythe qui voudrait que les géants soient « intrinsèquement résilients ». Ce contexte encourage les directeurs du numérique dans les organisations à reprendre la main en développant des outils et méthodes pour anticiper ces problèmes technologiques et pour éviter du même coup de se faire piéger par les « zones d’ombre contractuelles » des modèles de responsabilité du cloud.
