Chaque génération choisit la mauvaise stack technologique. Les Vibe Coders ne font pas exception.

7 min read

Maintenant, on peut créer une app sans comprendre ce qui tourne en dessous.

Bon, tant que ça marche, ça marche... Mais si vous avez plus d'ambition qu'un simple outil maison, si vous voulez le faire évoluer, le faire grandir, éventuellement le vendre, il faudra bien vous salir les mains à un moment donné. La vague no-code disait qu'on n'avait pas besoin de coder. La vague vibe coding dit qu'on n'a pas besoin de comprendre l'architecture. Les deux sont vraies, jusqu'à ce qu'elles ne le soient plus. Et quand elles cessent d'être vraies, on réécrit tout.

Les LLM n'éliminent pas ce schéma. Ils l'accélèrent.

Espace de travail de bureau en écran divisé montrant deux développeurs avec des approches technologiques contrastées : l'un submergé par une architecture complexe et des dépendances, l'autre détendu avec une configuration minimale, séparés par un homard robotique chevauchant un câble USB.
Votre stack technologique n'est pas mauvaise. Elle n'est juste pas aussi cool que la leur.

Le Même Scénario, 3 Fois

Dans les années 80, BASIC est arrivé avec une proposition claire : pas besoin de comprendre les pointeurs ou de gérer la mémoire, écrivez juste la logique. Et pendant un temps, c'était complètement vrai. On pouvait créer de vrais programmes sans jamais toucher aux détails bas niveau, ce qui était vraiment libérateur pour beaucoup de gens qui voulaient juste quelque chose qui fonctionne. Le problème n'était pas la promesse. Le problème était ce que la promesse gardait invisible. Quand votre programme BASIC devenait assez complexe, le couplage arrivait pile à l'heure. Logique d'interface et logique métier s'emmêlaient sans séparation nette et sans moyen de tester quoi que ce soit sans tout toucher. La réécriture n'était pas un échec de BASIC. C'était intégré dans le deal dès le départ.

Quelque part dans un tiroir, j'ai encore une disquette de 1993 avec un programme BASIC qui automatisait la liste des cartes d'anniversaire de ma petite sœur. Des enveloppes adressées, 47 au total, imprimées sur une matricielle à peu près à la vitesse de la dérive des continents. Je n'ai absolument aucune idée de pourquoi j'y pense maintenant.

Visual Basic a prolongé le même deal jusqu'au milieu des années 2000, juste avec des formulaires et des gestionnaires d'événements au lieu de numéros de ligne. Puis le no-code a débarqué avec une version encore plus propre de la proposition : pas besoin de coder du tout. Encore une fois, vrai, jusqu'à ce qu'on ait besoin d'une fonctionnalité que la plateforme ne supporte pas, ou qu'on atteigne le plafond tarifaire, ou qu'on doive déplacer des données là où la plateforme ne peut pas aller. Le plafond du no-code, c'est juste le bord de la plateforme. On le trouve au pire moment possible, quand l'enjeu est maximal.

Le vibe coding, c'est l'acte 3. La proposition est améliorée mais elle est presque mot pour mot identique en dessous : pas besoin de comprendre l'architecture. Décrivez juste ce que vous voulez, l'agent s'occupe du reste. Vrai, pour beaucoup de cas, pendant un temps. Ce qui est constant dans les 3 vagues, ce n'est pas l'outil. C'est la note de bas de page que la proposition omet : "vous n'avez pas besoin de comprendre X, sauf quand votre problème a la forme de X." Et cette condition, la personne qui débute ne peut pas la voir au moment de choisir. C'est ce qui fait que la promesse semble réelle jusqu'à ce que la réécriture commence.

Votre Agent Connaît le Problème Populaire

J'ai lu des fils cette semaine sur ce qu'il faut orchestrer autour du code généré par IA. Gestion d'état, logique de retry, rollback, toute la plomberie qui entoure ce que les agents produisent. Les outils dans ces fils sont techniquement corrects. Ils résolvent de vrais problèmes. Mais les vrais problèmes qu'ils résolvent ont été créés en amont, par des choix antérieurs : une SPA React complète, un client lourd, un état complexe distribué sur plusieurs services. Si vous n'avez pas ces problèmes, vous n'avez pas besoin de ces solutions.

Et chaque fois que quelqu'un demande comment gérer la complexité d'orchestration, au moins 1 commentaire dans chaque fil dit : "dites juste à vos agents de s'en occuper." Ce qui est complètement vrai. Et qui évite aussi la question plus utile, qui est pourquoi ces agents ont produit la complexité en premier lieu. (Ça marche sur ma machine. La machine a juste besoin de 14 services qui tournent dans Docker pour fonctionner.)

Quand vous demandez à un agent de construire une app, il produit la réponse statistiquement probable pour le type de problème sur lequel il a été le plus souvent entraîné : pas la réponse qui correspond à vos contraintes réelles, mais la réponse la plus susceptible d'être correcte sur toutes les fois où ce genre de question a été posée. L'agent optimise pour la réponse modale, ce qui en pratique signifie le pattern dominant dans l'écosystème. Donc vous demandez une app et vous obtenez la stack par défaut : React avec un bundler, une couche de gestion d'état, tout le setup. L'agent fait exactement ce qu'il est censé faire, je pense. Il ne peut juste pas savoir que votre problème spécifique n'a besoin de rien de tout ça.

J'ai fait le même exercice pour l'outillage, pas le code : si CLI ou MCP convient vraiment aux agents de production. L'option populaire a le même problème.

Avant d'Ouvrir le Prompt

J'ai 2 projets qui tournent en ce moment, construits à peu près dans la même période, même développeur, même workflow assisté par IA.

Le premier est un outil léger. Rendu côté serveur, Hono JSX, zéro bundler front-end. Le premier passage de mon agent est revenu avec 23 dépendances runtime. J'en avais besoin d'1. Les extras n'étaient pas faux dans l'absolu. Chacune résout un vrai problème dans un vrai contexte, mais aucun de ces contextes n'était le mien. (Claude Code n'arrêtait pas de proposer React Query pour une app rendue côté serveur avec zéro état client. J'ai résisté 3 fois. Au 4e prompt, il a finalement lâché la suggestion.) Il n'y a pas de complexité d'état qui vaille la peine d'être nommée et pas de flux assez complexe pour justifier une machine à états ici. XState aurait été de l'ingénierie pour un problème qui n'existe pas.

Vous êtes mort.

Le deuxième projet est un SaaS avec des clients payants et un flux d'import multi-étapes où les modes d'échec comptent vraiment. Si l'étape 2 échoue, l'étape 3 ne s'exécute pas. Si l'import meurt à mi-chemin, l'utilisateur voit l'état d'échec exact, pas une erreur générique. Ce projet utilise React 18 et XState v5, mais juste 1 machine, pour exactement ce 1 flux. Le reste de l'app ne touche pas à XState. Pas besoin. Un produit a généralement beaucoup de surfaces simples et 1 surface qui a une vraie complexité d'état, et l'erreur est de traiter tout le produit comme s'il avait la complexité de la partie la plus difficile.

Avant d'écrire un seul prompt pour l'un ou l'autre projet, je me suis posé 1 question : ce problème a-t-il des états nommés distincts avec des transitions explicites et des modes d'échec séparés ? Pour l'outil, non. Pour le flux d'import SaaS, oui, mais seulement pour ce flux spécifique.

L'agent ne peut pas répondre à cette question. Il ne connaît pas assez bien votre problème pour la poser.

Votre agent optimise pour le problème populaire. Assurez-vous que le vôtre en est vraiment un.

La Contrainte Qui Ne Se Délègue Pas

La compétence qui a survécu intacte à chaque vague, c'est savoir quelle complexité votre problème nécessite vraiment.

Aucune des 3 vagues ne l'a construite, parce qu'aucune n'avait à le faire. Chaque vague a convaincu assez de gens assez longtemps que la compétence n'était pas nécessaire. BASIC l'a fait en premier, puis le no-code a emballé la même promesse en glisser-déposer, et maintenant le vibe coding rejoue la même partition en langage naturel. Le plafond est le même à chaque fois.

Le vibe coding accélère les deux côtés de l'équation : la construction et la dette. La première réécriture arrive plus vite, pas jamais. La question de l'architecture ne disparaît pas. Elle est reportée à un moment où il y a plus de code à démêler et plus de décisions déjà cuites qui coûtent maintenant quelque chose à changer.

Ce qui ne se délègue pas, ce n'est pas le codage. C'est le diagnostic. Avant d'ouvrir le prompt, avant de décrire l'app à l'agent : pouvez-vous expliquer, en langage clair, pourquoi vous n'avez PAS besoin de X dans ce projet ? L'agent sait déjà que X est utile en général. La question est pourquoi votre projet spécifique, avec ses contraintes réelles, n'en a pas besoin maintenant. Si vous pouvez répondre à ça, vous pouvez contraindre l'agent à la stack adéquate au lieu de la modale. Si vous ne pouvez pas, l'agent fait du populaire par défaut, et ce ne sera pas techniquement faux, juste pas bon pour vous.

J'ai détaillé le mécanisme exact dans comment les contrats de prompt contraignent vraiment un agent. La contrainte est la 1 étape que l'agent ne peut pas faire pour vous. Tout le reste, l'agent s'en sort plutôt bien.

C'est aussi la compétence que BASIC, Visual Basic et le no-code ont tous dit qu'on n'avait pas besoin d'apprendre. Ça vaut le coup de le remarquer.

Quand vous amenez votre voiture au garage sans rien connaître de ce qu'il y a sous le capot, la facture est toujours une surprise. Le mécanicien connaît son boulot. Vous ne savez juste pas quoi questionner ou sur quoi résister. Pareil avec votre app. Vous découvrirez ce qui tourne en dessous au moment où vous voudrez changer quelque chose, ou la confier à quelqu'un d'autre. La facture a tendance à correspondre.

Sources

Cet article peut contenir des liens d'affiliation. Si vous cliquez dessus, je pourrais gagner une petite commission, ça ne vous coûte rien, et ça m'aide à continuer de livrer des articles de qualité chaque jour pour votre plaisir de lecture.