L'histoire méconnue de Matt Wright et la démocratie du code

Bien avant WordPress, avant Squarespace, avant même que le terme « no-code » ne devienne un mot magique dans la bouche de tous les investisseurs, il y avait un lycéen nommé Matt Wright. Son arme secrète ? Des scripts Perl qu'il partageait généreusement sur internet.

Une archive qui a tout changé

En 1995, Wright lance Matt's Script Archive : une collection simple de scripts pour sites web. Des formulaires de contact. Des livres d'or. Des compteurs de visites. Et un outil appelée WWWboard qui permet aux visiteurs de laisser des messages.

En quelques mois, des milliers de sites utilisent son code.

Des gens ordinaires — des personnes qui n'avaient aucune idée de ce que signifiait « Perl » ou « CGI » — se retrouvent soudain avec des forums fonctionnels et des sites interactifs. C'était la première vraie démocratisation des outils web. Avec tout ce que ça implique de chaos.

L'écart entre ceux qui codent et ceux qui utilisent

Le succès des scripts de Matt reposait sur une réalité simple : ils fonctionnaient. Pas proprement. Pas sécurisé. Mais ils marchaient.

Un artisan en 1996 ne se souciait pas des failles SQL ni de la validation des entrées. Il voulait juste que ses clients puissent lui envoyer un message depuis son site.

Les développeurs expérimentés, eux, voyaient un cauchemar. Des mots de passe stockés dans des dossiers accessibles. Des variables d'environnement exposées dans les URLs. Son script textcounter affichait un score CVSS parfait de 10.0 — une porte d'entrée directe vers le serveur.

La communauté Perl a fini par réagir avec le projet nms (nongreedy's modifications), des replacements drop-in plus sûres. Leur verdict était sans appel : « Ces scripts sont connus pour être mal écrits, bogués et dangereux. »

Le paradoxe de la popularité

Voilà où ça devient intéressant.

Les scripts de Matt n'étaient pas particulièrement pires que les autres代码 de l'époque. Beaucoup de code web de cette époque était pleine de failles. Ce qui rendait son travail dangereux, c'était son ampleur.

Quand des milliers de sites utilisent le même logiciel vulnérable, la surface d'attaque devient énorme. Une faille théorique se transforme en épidémie réelle.

Ce schéma s'est répété depuis à l'infini. Windows. WordPress. jQuery. N'importe quel outil suffisamment populaire devient une cible — non pas parce qu'il est mal conçu, mais parce qu'il est partout.

Le travail de la communauté sécurité n'est pas seulement de corriger les bugs. C'est de convaincre les gens que « suffisant pour l'instant » ne le sera peut-être plus demain.

Mais voici le paradoxe : parfois, « suffisant pour l'instant » est exactement ce qui permet la croissance. Une startup qui utilise un outil imparfait pourrait construire le prochain WordPress. Empêcher les gens de construire avec des outils imparfaits signifie les empêcher de construire tout court.

Hello, Vibe Coding

Avançons de trente ans. Nous avons une nouvelle génération d'outils « suffisants » : les plateformes de code assistées par IA, les apps vibe-codées, les snippets générés par LLM déployés directement en production.

La réponse de la communauté sécurité est déjà en place. Oui, il y a des inquiétudes sur les vulnérabilités subtiles dans le code généré par IA. Oui, les débats sur le vibe coding responsable font rage. Et oui, certaines personnes déploient absolument des horreurs non sécurisées en production.

Mais voici ce que les critiques oublient : le vibe coding fait exactement ce que les scripts de Matt ont fait. Il permet à des gens qui ne sont pas développeurs professionnels de livrer des produits fonctionnels. Un solopreneur peut aujourd'hui construire une application web opérationnelle en un après-midi.

Ce n'est pas rien. C'est la démocratisation pure de la création.

La question n'est pas de savoir si les apps vibe-codées sont sécurisées. Elles ne le sont souvent pas. La question est de savoir si les bénéfices de l'accessibilité compensent les compromis sécurité. Et l'histoire suggère que la réponse est compliquée mais plutôt positive — avec la condition qu'on développe de meilleurs outils, de meilleures configurations par défaut, et une meilleure éducation.

L'histoire du domaine

Il y a un épilogue à cette histoire particulièrement pertinent pour ceux qui voient les domaines comme plus que de simples adresses.

Worldwidemart.com — le domaine qui hébergeait autrefois Matt's Script Archive — a fini par expirer. Pendant un moment, il a hébergé le genre de contenu spam casino qui donne des cauchemars aux antivirus. Puis, fin 2023, quelqu'un a racheté ce domaine expiré spécifiquement pour préserver l'histoire de l'archive.

Quelqu'un s'est soucié de l'histoire du web au point de sauver un morceau des griffes des cybersquatteurs. Ça mérite d'être remarqué.

Les domaines ne sont pas que des actifs techniques. Ce sont des artefacts culturels. Parfois, l'histoire qu'un domaine raconte compte plus que sa valeur SEO.

Ce que ça signifie pour vous

Quel est le message pour les développeurs modernes, les fondateurs de startups, les entrepreneurs tech ?

« Suffisant » a toujours driving l'adoption. Ne négligez pas des outils simplement parce que les experts les moquent. Les outils que les gens utilisent réellement comptent plus que ceux que les experts approuvent.

La dette sécurité s'accumule. Si vous construisez sur des fondations « suffisantes », comprenez ce que vous héritez. Planifiez la dette technique. Intégrez des audits sécurité dans votre roadmap.

Accessibilité et qualité ne sont pas ennemies, mais elles demandent un équilibre. L'objectif n'est pas d'empêcher les gens de construire — c'est de rendre la construction sécurisée plus facile que l'insécurisée. Ça incombe aux créateurs d'outils. Aux plateformes. À nous tous.

Matt Wright n'a pas cherché à façonner internet. Il a simplement rendu des scripts disponibles pour ceux qui en avaient besoin. Parfois, c'est exactement ce dont le monde a besoin.

Juste... peut-être gardez vos dépendances à jour.