Dimanche 19 juillet, vers 9h45, Facebook est retombé. Message d’erreur classique : « Compte temporairement indisponible… suite à un problème du site. » Messenger, Instagram et WhatsApp ont suivi de près, comme souvent, parce qu’ils partagent la même infrastructure (TotalBug). L’incident a duré au moins une heure quarante, avec près de 500 signalements en 24h sur les outils de suivi (Entireweb Status), avant de se résorber comme la plupart de ces épisodes — sans que Meta n’ait communiqué en détail sur son origine.
Rien de spectaculaire en apparence. Pas de coupure mondiale de six heures, pas de titre en boucle sur BFM. Juste une panne de plus, presque banale, presque routinière. Et c’est précisément ça qui m’a arrêté ce dimanche matin : je n’ai même plus été surpris. J’ai eu ce réflexe qu’on a tous, aujourd’hui, quand une app plante deux minutes : « ah, encore. »
Ce réflexe m’a semblé intéressant à interroger. Est-ce qu’on assiste vraiment à une dégradation, ou est-ce mon biais de disponibilité qui me joue des tours parce que j’ai plus de fil d’actu tech qu’il y a dix ans ? J’ai voulu vérifier, avec des chiffres plutôt qu’avec une impression. Voici ce que dix ans de pannes Meta racontent, et surtout ce qu’elles nous apprennent — pas pour pointer du doigt, mais pour comprendre un mécanisme qui, j’en suis convaincu, dépasse largement Meta.
Dix ans de pannes : ce que disent vraiment les chiffres
Première chose à clarifier : en intensité pure, on n’a rien vu de pire depuis longtemps. Les deux pannes les plus sévères de la décennie restent celle du 13-14 mars 2019 (plus de 14 heures, environ 7,5 millions de signalements, la pire panne pour Meta depuis 2008 selon l’entreprise elle-même) et celle du 4 octobre 2021 (environ 6 heures, mais un record absolu de 10,6 millions de signalements sur Downdetector) (BBC, Ookla, BBC). Rien de comparable depuis, en ampleur brute.
Ce qui a changé, c’est le rythme. Entre 2016 et 2021, une grande panne mondiale survenait à peu près une à deux fois par an. On se souvient encore de chacune, parce qu’elles étaient rares. Puis quelque chose a basculé. Le service de suivi IsDown recense 535 incidents Meta depuis mai 2023, dont 141 sur les douze derniers mois et 38 sur une seule fenêtre de 90 jours récente (IsDown). Sur le seul mois de juin 2026, j’en compte quatre distincts dans la presse (12, 18, 23 et 24 juin), et un nouveau cluster début juillet (6, 16 puis 19 juillet, celui de ce dimanche) (Reuters, StatusGator).
Une explication technique revient systématiquement, et elle mérite d’être expliquée simplement : Facebook, Instagram, WhatsApp, Messenger et Threads partagent la même brique d’authentification et une bonne partie de leur infrastructure backend. Concrètement, ça veut dire qu’une erreur de configuration sur un seul composant partagé — un certificat, une règle de routage, un service d’auth — se propage instantanément à toutes les applications du groupe. C’est ce mécanisme qui a produit la panne BGP de 2021 comme les vagues de déconnexions forcées de 2024 et 2026 (Cloudflare).
Je dois aussi une honnêteté méthodologique : une partie de cette hausse apparente vient probablement de la multiplication des outils de suivi tiers (Downdetector, StatusGator, IsDown) depuis 2021, qui détectent aujourd’hui des micro-incidents qui passaient sous les radars avant. Mais ce biais de mesure n’explique pas tout : le resserrement de plusieurs pannes à six chiffres de signalements sur quelques semaines mi-2026 ressemble bien à un changement de régime, pas seulement à une meilleure instrumentation.
Bref : l’ampleur des pires pannes n’a pas augmenté. Leur fréquence, elle, oui, nettement. Et c’est là que la question intéressante commence : pourquoi ?
De la confiance à la prudence : ce qui a changé dans l’ingénierie
Il y a quelques années, une anecdote circulait souvent dans le milieu tech : un ingénieur qui rejoignait l’équipe Facebook était mis directement sur un vrai bug, en production, dès sa première semaine. Ce n’était pas une légende urbaine — Facebook avait construit tout un rite de passage autour de ça, le fameux « Bootcamp », où les nouveaux arrivants livraient du code en prod dès les premiers jours (Business Insider). Ce qui rendait ça possible n’était pas de l’inconscience, mais l’inverse : une chaîne de confiance extrêmement mature — revue de code systématique, déploiements quotidiens testés par une armée de bêta-testeurs, canary release, rollback quasi instantané (Engineering at Meta). C’est exactement le principe que je défendais dans mon article « Et si on déployait aussi le vendredi ? » : plus votre pipeline est fiable, moins vous avez besoin d’interdire, de sur-contrôler, d’avoir peur. La confiance se construit, elle ne se décrète pas.
Cette confiance-là semble s’être fragilisée chez Meta ces deux dernières années, et je tiens à le dire sans procès d’intention : ce n’est pas une histoire de mauvaise volonté ou d’incompétence, c’est une histoire de priorités qui ont changé, et de vitesse à laquelle elles ont changé.
Deux mouvements se sont produits en même temps, et je pense qu’il faut vraiment les lire ensemble plutôt que comme deux causes concurrentes.
Le premier, c’est une réallocation massive de budget vers l’IA. Meta a annoncé mi-2026 la suppression d’environ 8 000 postes — environ 10 % des effectifs — pour financer une enveloppe d’investissement IA de 135 à 145 milliards de dollars sur l’année (Reuters). Zuckerberg a été assez direct en interne sur le sujet : selon lui, l’entreprise ne pouvait pas absorber à la fois une embauche au pic du cycle et un investissement en infrastructure au pic du cycle — c’est une question de structure de coûts, pas de jugement sur la productivité de ses équipes (Insignia Business Review). Dans les faits, ce sont notamment les équipes d’infrastructure, de sécurité et de « trust & safety » qui ont été les plus touchées par ces réorganisations — précisément celles qui, historiquement, jouaient le rôle de garde-fou avant qu’un changement n’atteigne la production.
Le second, c’est l’adoption rapide et peu encadrée de l’IA dans le code lui-même. Les objectifs internes rapportés évoquent 55 à 65 % de code assisté par IA d’ici fin 2025-début 2026, avec des équipes ML visant jusqu’à 80 % (The Pragmatic Engineer). Le problème n’est pas l’IA en tant qu’outil — j’écrivais déjà en 2017, en parlant de Chaos Engineering, que la personnalisation croissante de nos systèmes « va empirer avec le déploiement de l’intelligence artificielle », dans le sens où elle complexifie la représentativité de nos environnements de test (mon article sur le Chaos Engineering). Le vrai sujet, c’est la vitesse à laquelle cette IA a été introduite, sans que les garde-fous — revue de code humaine approfondie, couverture de test, observabilité — soient renforcés en proportion. Plusieurs ingénieurs ont même décrit un système de mesure de la performance individuelle qui pousse, presque malgré eux, à produire plus de code généré par IA pour ne pas être mal noté — un effet pervers d’incitation qu’aucune équipe n’a probablement voulu créer intentionnellement.
Ce qui rend ces deux dynamiques difficiles à démêler, c’est qu’elles se renforcent mutuellement : les équipes qui auraient normalement pu absorber, tester et challenger cette vague de code généré par IA sont précisément celles qui ont perdu le plus d’effectifs. On ne peut pas dire que « c’est la faute de l’IA » ou que « c’est la faute des coupes budgétaires » — c’est la combinaison des deux qui a érodé, en quelques mois, une culture de fiabilité qui avait mis quinze ans à se construire.
Ce que cette histoire nous apprend, sans jugement
Je ne partage pas cette analyse pour pointer Meta du doigt. Je pense même que c’est tout le contraire de l’intérêt de cet article : ce mécanisme n’a rien de spécifique à une entreprise, et je pense que beaucoup d’organisations qui accélèrent leur adoption de l’IA aujourd’hui prennent, sans toujours s’en rendre compte, le même chemin.
Trois enseignements, que je formule volontairement comme des questions à se poser plutôt que comme des reproches :
La confiance dans un pipeline n’est jamais acquise pour toujours. Elle se construit avec de la couverture de tests, de l’observabilité, du feature flipping, du rollback rapide — tout ce qui permettait, hier, de déployer le vendredi sans angoisse. Chaque changement de priorité (budget, org, outillage) doit se demander s’il préserve ou fragilise cette chaîne de confiance. Ce n’est pas un acquis qu’on peut mettre en pause pendant deux ans sans conséquence.
L’IA dans le code n’est pas le problème — l’IA sans garde-fous renforcés l’est. Introduire un générateur de code massivement plus rapide sans muscler en parallèle la revue, les tests automatisés et l’observabilité, c’est un peu comme accélérer sur l’autoroute en désactivant l’ABS. Le vrai sujet DevOps de la décennie qui vient n’est pas « faut-il utiliser l’IA », mais « comment reconstruire, au même rythme que son adoption, les mécanismes de confiance qui permettaient historiquement d’aller vite sans casser ».
Les équipes qu’on dégraisse en premier sont souvent celles qui protègent la production. Infrastructure, sécurité, qualité — ce sont rarement les lignes les plus visibles d’un budget, et donc souvent les premières ciblées quand il faut financer autre chose. Le retour de bâton, lui, est différé : on ne le voit pas au moment de la décision, on le voit dix-huit mois plus tard, sous la forme d’incidents à répétition.
La panne de ce dimanche a été résolue en quelques heures, comme toutes les autres. Ce qui m’intéresse, ce n’est pas cet incident isolé, mais ce qu’il révèle en creux : la fiabilité d’un système d’information n’est jamais qu’une photographie de la confiance — technique, organisationnelle et culturelle — qu’on lui accorde à un instant donné. Et cette confiance, comme toute chose de valeur, se construit lentement et peut se dilapider vite.
Pour aller plus loin sur les mécanismes évoqués ici : « Et si on déployait aussi le vendredi ? » sur la culture de la confiance en DevOps, et « Qu’est-ce que le Chaos Engineering ? » sur l’anticipation des pannes en production.