Le 1er janvier 2026 à 2h00 du matin, j'étais déjà indubitablement en train de dormir les ami(e)s codeurs. Mais contrairement à moi, des millions de fan de Stranger Things, eux, étaient bel et bien réveillés, prêt à dévorer le finale tant attendu de la série. Malheureusement pour eux, tel le monde à l'envers, Netflix s'est effondré sous leurs pieds.
Ce qui est intéressant dans cette histoire ce n'est pas tant le crash en lui même. C'est surtout que visiblement Netflix savait que ca allait être énorme. Ils ont agi en conséquence, mais ca n'a pas suffi. Reformulons mon propos ! Une entreprise qui gère jusqu'à 35% du trafic internet américain aux heures de pointe, avec un CDN propriétaire pesant le milliard de dollars, 17 000 serveurs edge répartis dans plus de 150 pays et une décennie d'expérience dans la gestion de pics de trafic... a quand même crashé malgré une préparation explicite.
Cette ironie ouvre une refléxion qui va au-delà du simple "Netflix est nul" qui est de toute façon totalement erroné et peu intéressante. Elle est surtout de se demander comment gérer un évènement de 5 minutes qui ne survient que 3 fois par an ?
Avant d'aller plus loin, posons le contexte. Stranger Things saison 5, épisode final, 2h08 de visionnage. La conclusion d'une saga de 9 ans. Netflix a mis l'épisode en ligne mondialement à 2h00 du matin en France. Les chiffres sont absolument déments. 59,6 millions de vues en première semaine. Le meilleur démarrage jamais enregistré pour un contenu anglophone sur Netflix. 8,47 milliards de minutes visionnées. Plus gros jour de Noël de l'histoire de la plateforme pour le volume 2.
Ce n'est pas juste "beaucoup de monde". C'est des dizaines et des dizaines de millions de personnes qui tentent d'accéder au même contenu à la même seconde.
Et c'était pas la première fois pour les petits gars de Netflix. La saison 5 avait déjà crashé Netflix deux fois avant. Le 26 novembre et le 25 décembre pour les précédent lancement de la dernière saison de la série. Le pattern est clair. A chaque sortie d'épisodes, crash. Sauf que Netflix a appris de ses erreurs. La sortie de Noël a mieux tenu que celle de novembre. Ils ont visiblement fait des ajustements.
Et pourtant, le Nouvel An les a quand même mis à genoux…
D'après Ross Duffer, le co-créateur de la série, (sa parole vaut ce qu'elle vaut on est loin de l'expert bien évidemment) Netflix avait augmenté la bande passante de 30% avant la première de novembre. 30%. C'est pas symbolique. C'est un investissement d’infrastructure conséquent les ami(e)s codeurs. D'autant plus sur l'existant de Netflix à ce moment là.
Et pourtant ça n'a pas suffi…
Le fait est que quand vous avez un pic de trafic "normal", augmenter la capacité de 30% vous donne effectivement 30% de marge. C'est le genre de métrique que l'on utilise pour simuler par exemple des tests de charge avec K6. Mais c'est théorique. Généralement chez Apizr on s’appuie sur des métriques de trafic existante et on extrapole des cas à la marge conséquent pour définir ces scénarios de tests.
Mais quand vous avez des millions de requêtes parfaitement synchronisées sur la même ressource, la courbe de charge ne ressemble plus à une montée progressive et la métrique de 30% s'avère complétement caduc. C'est un mur qui apparaît ! Imaginez que vous gérez une boutique qui accueille normalement 100 clients par heure. Vous savez qu'un événement spécial va attirer du monde, donc vous ouvrez 30% de caisses supplémentaires. Cool. Sauf que le jour J, 10 000 personnes débarquent en même temps, toutes dans les 60 premières secondes. Vos caisses supplémentaires ne servent à rien parce que le goulot d'étranglement est maintenant à la porte d'entrée, mais aussi sur le système de file d'attente, ou encore la capacité du réseau électrique à allumer tous les terminaux simultanément.
C'est exactement ce qui s'est passé avec Netflix. Quand des millions de requêtes frappent simultanément les services backend, même avec 30% de capacité en plus, ca sature.
C'est ce qu'on appelle le thundering herd. Ce phénomène où un grand nombre de processus ou de clients tentent d'accéder à la même ressource simultanément après qu'elle devienne disponible ou qu'un verrou soit levé. Dans le contexte Netflix, on parle effectivement des millions d'utilisateurs qui cliquent sur "Play" dès lors que l'épisode fut disponible.
Netflix a probablement des serveurs edge pour son contenu. Super. Mais pour servir ce contenu, Netflix doit aussi probablement passer par d'autres logiques à exécuter au préalable. Probablement vérifier que l'utilisateur a le droit de le voir et donc interroger un service d'authentification. Générer une URL de streaming avec un token, etc... Normalement ces services sont dimensionnés pour gérer le trafic sur la journée. Même aux heures de pointe. Car les requêtes arrivent normalement de façon relativement étalée. Mais là elles arrivent toutes en même temps. Les pools de connexion à la base peuvent être épuisé en quelques secondes, les courts circuits se déclenchent et les mécanismes de retry amplifient le problème au lieu de le résoudre.
La concurrence, elle aussi, a possiblement ses limites. Un service peut traiter, disons, 10 000 requêtes concurrentes, c’est à dire en même temps. En temps normal, largement suffisant. Mais là, vous recevez 100 000 requêtes dans les 30 premières secondes. Les 90 000 dernières se retrouvent en timeout. Les clients retentent. Vous vous retrouvez avec 300 000 requêtes. Le service s'effondre complètement.
C'est exactement le genre de problème en cascade qu'on souhaite essayer d'éviter en tant que développeur. Et Netflix, avec toute leur expertise, leurs pratiques, leurs outils sophistiqués, se sont quand même pris ce mur dans la figure.
Mais ont-ils foncer volontairement dans ce mur ?
Apparemment, Netflix utilisent des stratégies nombreuses pour tenter de palier a ces problématiques à leur échelle. Par exemple, ils ont implémenté ce que l'on nomme du load shedding. Le principe, c'est qu'au lieu de rejeter les requêtes équitablement quand vous êtes en surcharge, vous priorisez. Netflix a aussi implémenté un système où les requêtes utilisateur critiques (cliquer sur "Play" par exemple) sont préservées en priorité, tandis que les autres requêtes sont sacrifiées en premier. C'est du "fail gracefully" appliqué à grande échelle. Ils utilisent également de l'auto scaling basé sur le nombre de requête par seconde, et non sur la charge CPU, avec des métriques remontées à un rythme très soutenu.
Toutes ces stratégies sont brillantes et sûrement très intéressante à analyser plus en détail. Elles ont probablement évité que le crash soit 10 fois pire. Mais effectivement, elles paraissent en fait beaucoup plus conçues pour lisser la charge, pas pour multiplier la capacité instantanément par 10 ou par 20. Le load shedding permet de dégrader gracieusement. L'autoscaling permet de réagir en quelques minutes. Mais quand vous avez un pic de requêtes parfaitement synchronisé qui dépasse votre capacité totale par un facteur de 5 ou 10, aucune de ces stratégies ne peut absorber le choc initial.
C'est pour ça que Netflix a probablement quand même crashé. Pas par manque de préparation. Mais par impossibilité physique d'absorber un tel pic sans dimensionnenement pour lui spécifiquement.
Et voilà où on arrive au cœur du problème, celui qui m'intéresse vraiment les ami(e)s codeurs. Celui qui me questionne.
Netflix aurait pu provisionner assez de capacité pour absorber ce pic. C'est techniquement faisable. Le problème est que ça coûterait probablement une fortune en ressources qui seraient inutilisées 99,9% du temps. Car oui, c’est un événement qui n’arrive que très rarement, dû au phénomène qu’est Stranger Things.
Faisons un calcul rapide, complètement hypothétique mais qui illustre le principe. Disons que le trafic normal de Netflix aux heures de pointe représente 100 unités de capacité. Ils ont ajouté 30%, donc 130 unités. Le pic Stranger Things a probablement nécessité 200 à 300 unités pendant les 5 premières minutes après la mise a disposition du final de la série, avant de redescendre rapidement quand les utilisateurs se sont répartis temporellement (certains ont réussi à se connecter, d'autres ont réessayé quelques minutes plus tard, etc...). Pour absorber ce pic sans crash, Netflix aurait dû provisionner peut-être 250 à 300 unités de capacité permanente. Ça veut dire payer pour 120 à 170 unités qui ne servent strictement à rien 99,9% du temps. Des serveurs qui tournent à vide. Des instances AWS qui consomment par exemple. Du personnel pour les maintenir.
Et pour quoi ? Pour éviter 5 minutes de dégradation 3 fois par an.
Le calcul du retour sur investissement est brutal. Si vous provisionnez pour le pic absolu, vous gaspillez des millions de dollars en capacité dormante une grande partie du temps. Si vous provisionnez pour la demande normale +30%, vous crashez 3 fois par an pendant quelques minutes mais vous économisez une fortune.
Netflix a clairement choisi la deuxième option. Et franchement si c'est vraiment ça, je pense qu'ils ont eu raison.
Pour moi, le problème à résoudre n'est pas "comment avoir assez de capacité pour le pic", mais "comment éviter que le pic soit aussi concentré temporellement". Il y a plusieurs options possible, sans que je ne sache si c'est viable dans le contexte de Netflix. Ils auraient pu par exemple donner accès à l'épisode à différents groupes d'utilisateurs à des heures légèrement décalées. Genre, les comptes premium avant, puis les comptes standard, etc... Ça distribue la charge sur un laps de temps plus large au lieu de tout concentrer sur la même seconde. Problème, ça frustre les utilisateurs et crée un sentiment d'inégalité. Mais c'est un peu le principe des différents tiers d'abonnement en soi non ? Ou comme les systèmes de ticketing pour les concerts, ils auraient pu mettre les utilisateurs en file d'attente et les laisser entrer progressivement. Problème encore une fois, une frustration utilisateur maximale, et ça ne fait que déplacer le problème.
Aucune de ces solutions n'est parfaite. Toutes ont des points faibles significatifs. Peut être même qu'ils ont évalué eux même en interne ce genre de solution sans les trouver convaincante. Et c'est précisément pour ça que Netflix accepte probablement que quelques minutes de dégradation occasionnelle valent mieux que de compliquer massivement l'expérience utilisateur ou l'architecture.
Alors ok, chez Apizr dans mon boulot on ne gère pas ce que gère Netflix. Mais le pattern est finalement assez universel et s'applique à toutes les échelles selon moi.
Vous avez une app de réservation de restaurants qui marche tranquillement toute l'année, sauf le soir du réveillon de Noël où tout le monde réserve en même temps. Vous avez un site e-commerce qui tourne bien, sauf pendant les soldes où le trafic explose. Vous avez une plateforme de formation en ligne qui est stable, sauf quand vous lancez une nouvelle formation et que tout le monde veut s'inscrire dans la première heure.
Le pattern est le même, un événement rare, prévisible, qui génère un pic de charge massif et concentré temporellement.
La tentation naturelle est de se dire "je vais scale pour absorber le pic". Mais comme on vient de le voir avec Netflix, ce n’est souvent pas économiquement viable. Si votre site est lent pendant 5 minutes une fois par an, c'est probablement acceptable. La perfection absolue coûte exponentiellement cher. Il faut juste que la dégradation soit gracieuse (messages d'erreur clairs, retry transparent, pas de perte de données, etc...). Si vous êtes en surcharge, priorisez les fonctionnalités critiques. Sacrifiez les recommandations, les analytics, le prefetch, mais gardez les opérations les plus importantes fonctionnelles. C'est mieux d'avoir un site qui marche lentement mais qui marche, qu'un site complètement down.
Netflix n’a pas publié de post-mortem détaillé. Leur communication officielle était minimale : "Some members briefly experienced an issue streaming on TV devices, but service recovered for all accounts within five minutes."
Je pense que c'est parce que le vrai message qu'ils voudraient communiquer serait trop honnête pour être acceptable : "On a choisi de pas dépenser des millions pour éviter 5 minutes de dégradation 3 fois par an, parce que ça aurait été un gaspillage d'argent délirant."
C'est la réalité technique et économique. Mais ça sonne terrible en communication publique. Alors ils restent vagues et laissent les gens penser que c'était un problème technique inattendu. Spoiler : c'était pas inattendu pour moi. C'était un choix délibéré de leur part.
Certains événements culturels génèreront inévitablement une dégradation temporaire. Le thundering herd est, par nature, un problème de timing autant que de capacité. Vous ne pouvez pas juste "ajouter plus de serveurs" au problème. La synchronisation temporelle crée des goulots d'étranglement qui ne se résolvent pas en augmentant linéairement la capacité. Netflix a visiblement amélioré son Time To Recover. De plusieurs heures historiquement (crash de Noël 2012) à quelques minutes aujourd'hui. C'est énorme. Mais la prévention totale nécessiterait soit un investissement économiquement absurde en capacité dormante, soit des changements d'expérience utilisateur qui auraient leurs propres coûts. Ils ont choisi d'optimiser pour l'expérience utilisateur 99,9% du temps, et d'accepter quelques minutes de dégradation pour les 0,1% restants. C'est, à mon avis, le bon choix.
La vraie leçon pour nous, Ce n’est pas qu'on doit tout faire pour éviter les incidents à tout prix. C'est qu'on doit comprendre le coût réel, et faire des choix conscients sur où placer le curseur entre coût, complexité, et disponibilité.
Parfois, laisser le système crasher gracieusement pendant 5 minutes vaut mieux que de payer pour une capacité qui servira jamais. Netflix l'a compris. Peut-être qu'on devrait aussi.
Un petit saignement de nez, parfois, c’est pas si grave.
Si ce contenu vous a plus les ami(e)s codeurs, n’hésitez pas à vous abonner a la newsletter afin d’être averti des prochains billets !