Briser les habitudes linguistiques par défaut

Il fut un temps où choisir un langage de programmation relevait presque de la contrainte. Sur desktop, le système d’exploitation imposait souvent sa loi : Windows poussait vers C++, Unix vers C. Chacun acceptait ce diktat.

Puis le web est arrivé.

Aujourd’hui, quand on héberge soi-même ses applications, on décide du langage et du runtime. Le système d’exploitation n’a plus son mot à dire. Pourtant, beaucoup d’équipes n’exploitent pas vraiment cette liberté.

La pression du marché que vous subissez déjà

Le choix du langage est devenu un levier compétitif. Les fondateurs techniques l’oublent souvent.

Imaginez deux startups en course. L’une utilise un langage « sûr » : Go, Node.js ou Java. L’autre avance trois fois plus vite, corrige des bugs pendant que l’équipe adverse planifie son sprint. La différence ne vient pas du talent. Elle vient du paradigme de développement.

Paul Graham avait déjà observé ce phénomène avec les startups Lisp. Le principe reste valide : un langage conçu pour l’itération rapide donne un avantage asymétrique. On construit un minimum viable, on le teste en conditions réelles, et on l’évolue sans cesse.

L’avantage de l’itération rapide

En 2024, on ne passe plus des mois à dessiner une architecture parfaite avant d’écrire la première ligne de code. On livre des MVPs, on observe les vrais utilisateurs, pivote quand les données le montrent.

Certaines technologies facilitent vraiment cette approche :

• Boucles de retour rapides : écrire une fonctionnalité, la tester tout de suite, voir le résultat. Pas de compilation longue, pas de pipelines qui mangent du temps.
• Débogage en production : charger le code en cours, reproduire le problème client et le corriger en direct.<|eos|>