Avant ChatGPT, il y avait Stack Overflow. Retour sur les posts qui ont marqué la culture du développement logiciel.
Le déclin est vertigineux. Depuis le lancement de ChatGPT fin 2022, le trafic de Stack Overflow a chuté de 35 à 50 % selon les métriques. Le volume de questions posées, qui culminait à plus de 200 000 par mois en 2014, est retombé sous les 50 000 — un niveau que la plateforme n'avait plus connu depuis 2008. En une poignée de mois, l'IA générative a fait à Stack Overflow ce que Stack Overflow avait fait aux forums techniques une décennie plus tôt.
Mais pendant 15 ans, Stack Overflow a été la référence absolue. Le réflexe universel de toute une génération de développeurs : copier l'erreur, la coller dans Google, cliquer sur le premier lien mauve. Et dans cette histoire colossale — des millions de questions, des milliards de vues — se cachent des posts devenus légendaires. Des réponses qui ont transcendé le debugging, des catastrophes nées d'un copier-coller malheureux, et des questions dont la communauté parle encore des années plus tard.
La réponse Zalgo : quand un post devient de la littérature
Tout commence par une question innocente sur Stack Overflow en 2009 : "RegEx match open tags except XHTML self-contained tags". Un développeur demande comment utiliser une expression régulière pour parser du HTML.
La réponse de bobince, devenue l'une des plus célèbres de l'histoire de la plateforme, est un chef-d'œuvre de pédagogie par l'absurde. Le texte commence de manière rationnelle, puis descend progressivement dans une spirale lovecraftienne à mesure que l'auteur tente d'expliquer pourquoi les regex sont fondamentalement incapables de parser du HTML — un langage contextuel qui dépasse les capacités des automates finis.
You can't parse [X]HTML with regex. Because HTML can't be parsed by regex. Regex is not a tool that can be used to correctly parse HTML. As I have answered in HTML-and-regex questions here so many times before, the use of regex will not allow you to consume HTML. Regular expressions are a tool that is insufficiently sophisticated to understand the constructs employed by HTML. HTML is not a regular language and hence cannot be parsed by regular expressions. Regex queries are not equipped to break down HTML into its meaningful parts.[....]
Le texte se désagrège littéralement sous les yeux du lecteur, avec des caractères Unicode « Zalgo » qui corrompent la mise en page, illustrant visuellement la folie qui attend quiconque s'aventure sur cette voie. La conclusion est sans appel : on ne parse pas du HTML avec des regex. Point.
Ce post a durablement marqué la culture dev. Le texte Zalgo est devenu un meme à part entière — il existe aujourd'hui des générateurs dédiés pour produire ce type de texte corrompu. Et répondre "you can't parse HTML with regex" est presque un réflexe pavlovien dans la communauté.
Quand man casse vos tests à minuit et demi
En novembre 2017, un sysadmin nommé Jaroslav Kucera poste une question sur Unix & Linux Stack Exchange avec un problème étrange : ses tests automatisés échouent de manière intermittente. Pas toujours, pas de façon reproductible — uniquement quand ils tournent aux alentours de 00h30 du matin. Dans les logs, un message inexplicable apparaît en stderr : "gimme gimme gimme".
We've noticed that some of our automatic tests fail when they run at 00:30 but work fine the rest of the day. They fail with the message
gimme gimme gimme
instderr, which wasn't expected. Why are we getting this output?
L'explication, quand elle arrive, est un chef-d'œuvre d'absurde: "er, that was my fault, I suggested it. Sorry."
En 2011, Thomas Thurman avait lancé à son ami Colin Watson, mainteneur de man-db, que "if you call man after midnight, it should say 'gimme gimme gimme'" — une référence au titre d'ABBA "Gimme! Gimme! Gimme! (A Man After Midnight)". Watson avait trouvé l'idée drôle. Il avait committé le code. Et pendant six ans, personne ne l'avait remarqué.
Watson a reconnu le fait avec élégance : "Six years seems like a pretty good run for that sort of thing."
L'easter egg a été retiré dans man-db 2.8.0. Mais il a fallu qu'un sysadmin perplexe poste sur Stack Exchange pour que le secret sorte — le genre d'histoire que seule cette plateforme pouvait produire.
Le clip Gimme Gimme Gimme de ABBA
Le bug du GUID copié-collé : quand Stack Overflow infecte l'industrie
C'est peut-être l'histoire la plus emblématique du lien entre Stack Overflow et le monde réel. En 2020, le chercheur en sécurité Foone découvre un bug étrange : Docker Desktop et Razer Synapse (le logiciel des périphériques gaming Razer) s'excluent mutuellement sous Windows. Lancer l'un empêche l'autre de démarrer.
En analysant le code, Foone trouve que les deux applications utilisent un mutex global en .NET pour empêcher les instances multiples, avec cette ligne :
string.Format("Global\{0}",
Assembly.GetExecutingAssembly().GetType().GUID);Le problème est subtil mais dévastateur : GetType() ne récupère pas le GUID de l'application, mais celui du type de l'assembly — c'est-à-dire le type du framework .NET lui-même. Ce GUID est donc identique pour toute application .NET utilisant ce pattern. Docker et Razer Synapse se croyaient mutuellement être une seconde instance d'eux-mêmes.
En remontant la piste, Foone découvre l'origine : une question Stack Overflow de 2009 où un développeur nommé Nathan demandait comment récupérer le GUID de son application. La réponse la plus votée contenait cette erreur. Un an et un mois plus tard, un autre utilisateur avait signalé le bug et proposé la correction — mais trop tard, le code erroné avait déjà été copié-collé dans des dizaines de projets à travers le monde — un scénario qui rappelle les bugs informatiques les plus célèbres de l'histoire.
Comme le résumait Korben dans son article sur le sujet : "Je copie, je colle, je compile, je regarde, ça marche, youpi et je passe à autre chose." — la philosophie involontaire de toute une génération de développeurs.
Marco Marsala : le (faux) hébergeur qui a tout effacé
En avril 2016, un message de détresse apparaît sur ServerFault. Un certain Marco Marsala, qui affirme gérer un hébergeur de 1 535 clients, raconte avoir accidentellement exécuté via Ansible un script Bash contenant rm -rf {foo}/{bar} — avec les variables foo et bar non définies à cause d'un bug dans les lignes précédentes. Résultat : un rm -rf / exécuté sur l'ensemble de ses serveurs. Les backups offsite ? Également supprimés, car le script de maintenance les avait montés juste avant.
Les réponses sont devenues légendaires. André Borie : "If you really don't have any backups I am sorry to say but you just nuked your entire company."
Michael Hampton, encore plus lapidaire : "You're going out of business. You don't need technical advice, you need to call your lawyer."
L'histoire a fait le tour du monde en quelques heures, reprise par The Independent, ScienceAlert et des dizaines de médias tech. Mais quelques jours plus tard, retournement : Marsala avoue au journal italien La Repubblica que tout était inventé. C'était un coup marketing viral pour promouvoir son entreprise de gestion de serveurs externalisée. Il affirme que la commande décrite est en réalité inoffensive car Ansible empêche ce type d'erreur, et que "presque personne parmi les répondeurs ne l'a remarqué".
Les modérateurs de ServerFault, pas du tout amusés, ont supprimé le post. Stack Overflow a publié un communiqué sec confirmant que "the moderators were not particularly amused by this stunt".
L'ironie est que l'histoire a survécu à sa propre réfutation : la plupart des gens se souviennent du rm -rf catastrophique, pas du démenti.
Le vrai "Monday morning mistake"
Contrairement au hoax de Marsala, cette question ServerFault de 2014 est authentique, et le titre dit tout : "Monday morning mistake: sudo rm -rf --no-preserve-root /".
L'administrateur système raconte avoir voulu exécuter :
sudo rm -rf --no-preserve-root /mnt/hetznerbackup/Mais un espace de trop s'est glissé avant le / final :
sudo rm -rf --no-preserve-root /mnt/hetznerbackup /Le shell a interprété ça comme deux arguments : /mnt/hetznerbackup et /. Quelques secondes plus tard, la totalité du serveur de production Hetzner partait en fumée. Le mystère non résolu : pourquoi avait-il tapé --no-preserve-root en premier lieu, alors que ce flag existe précisément pour empêcher la suppression accidentelle de / ?
Un conseil pratique est sorti de ce thread : toujours mettre les flags -rf à la fin de la commande plutôt qu'au début. Ainsi, si on appuie sur Entrée trop tôt après avoir tapé rm /, il ne se passe rien de catastrophique. Un autre : ne jamais inclure un / dans les arguments de rm — changer plutôt de répertoire et utiliser des chemins relatifs.
Comment sortir de Vim : la question existentielle
La question "How do I exit the Vim editor?" sur Stack Overflow (2012) est devenue un meme universel. Avec plus de 3 millions de vues, Stack Overflow a calculé qu'un visiteur sur 20 000 vient uniquement pour résoudre ce problème. La plateforme a publié un article de blog intitulé "Helping One Million Developers Exit Vim" pour célébrer le cap symbolique du million de vues, avec des statistiques détaillées par pays et par langage de programmation.
La réponse est pourtant simple : :q! pour quitter sans sauvegarder, :wq pour sauvegarder et quitter. Mais quand on ne sait pas qu'on est en mode commande et que chaque touche du clavier semble aggraver la situation, Vim devient un piège dont le seul échappatoire connu est de fermer le terminal.
Pourquoi un tableau trié est plus rapide : le meilleur cours de CPU jamais donné
Le post le plus upvoté de toute l'histoire de Stack Overflow est "Why is processing a sorted array faster than processing an unsorted array?" (2012). Un développeur C++ constate qu'un simple if dans une boucle est 6 fois plus rapide sur un tableau trié que non trié.
La réponse utilise l'analogie d'un aiguilleur ferroviaire pour expliquer la prédiction de branchement du processeur : quand les données sont triées, le if prend toujours la même direction pendant de longues séries, et le CPU anticipe correctement. Sur des données aléatoires, il se trompe une fois sur deux et doit annuler le travail spéculatif, ce qui coûte cher en cycles.
Ce post a probablement enseigné l'architecture CPU à plus de développeurs que n'importe quel cours universitaire.
Pourquoi chucknorris est une couleur HTML
En 2011, un développeur découvre que <body bgcolor="chucknorris"> produit un fond rouge foncé dans le navigateur. La question "Why does HTML think 'chucknorris' is a color?" a donné lieu à une explication technique fascinante.
Les anciens parsers HTML (et les navigateurs modernes en mode legacy) tentent d'interpréter n'importe quelle chaîne comme un code hexadécimal. Les caractères non valides sont remplacés par des zéros, puis le résultat est tronqué pour obtenir une valeur RGB. Avec "chucknorris", le parser produit c00c00000000, divisé en trois canaux de longueur égale puis tronqué en deux caractères chacun : c0, 00, 00 — du rouge. La réputation de Chuck Norris est intacte : même HTML lui obéit.
La morale de l'histoire
Ce qui rend Stack Overflow et le réseau Stack Exchange si fascinants, ce n'est pas seulement leur utilité technique — c'est qu'ils constituent un miroir fidèle de la culture du développement logiciel. On y trouve la brillance (la réponse sur la prédiction de branchement), l'humour (la couleur Chuck Norris), la sagesse transmise par l'expérience douloureuse (le Monday morning mistake), et les dangers de nos propres habitudes (le GUID copié-collé pendant 11 ans).
Chaque post légendaire raconte la même histoire sous un angle différent : le code est fragile, les humains sont faillibles, et la frontière entre le génie et la catastrophe tient souvent à un espace en trop, une variable non définie, ou une réponse Stack Overflow lue trop vite.
Aujourd'hui, ChatGPT a remplacé le réflexe "copier l'erreur dans Google". Mais ces posts restent. Ils font partie du patrimoine commun des développeurs — et aucun LLM ne produira jamais une réponse Zalgo.
Pour aller plus loin sur sfeir.dev :
- L'histoire des bugs informatiques les plus célèbres — d'Ariane 5 à CrowdStrike, les bugs qui ont marqué l'industrie
- Egoless programming : quels bienfaits pour notre équipe ? — humilité et collaboration dans la culture dev
