L'illusion du Vibe Coding : pourquoi l'IA peut écrire du code mais ne remplace pas les architectes système

Soyons honnêtes : on est tous passés par là. Vous découvrez un nouvel outil de coding boosté à l'IA, et soudain vous avez l'impression de pouvoir construire n'importe quoi. Des années à vous dire "si seulement j'avais le temps de coder cette idée" ? Le temps est arrivé. Décrivez ce que vous voulez, itérez avec l'IA, et déployez.

Cette sensation est enivrante. Et dangereuse.

La tentation du code "qui fait le job"

Le mois dernier, j'ai décidé de tester les limites du vibe coding en construisant un système de mémoire pour des agents IA. Vous savez, le genre de chose qui permettrait à un assistant de retenir ce qu'il a appris d'une session à l'autre, au lieu de recommencer à zéro à chaque fois.

Qu'est-ce qui pouvait être compliqué ? Stocker des faits, les retrouver quand c'est pertinent, détecter les incohérences. Une base de données intelligente avec une belle API.

Le code est arrivé vite. Vraiment vite. L'agent avec lequel je bossais a pondu un daemon en Rust, un système de classification, quatre stratégies de retrieval avec re-ranking via des modèles locaux. Objectivement, ça faisait envie. Les tests passaient. Le compilateur était content.

Et puis j'ai essayé d'utiliser le bousin.

Le problème avec les systèmes de mémoire pour agents : c'est pas vraiment une question de stockage. C'est une question de sens. Et le sens, figurez-vous, c'est philosophiquement épineux d'une façon qui rend vos lignes de code bien typées un peu ridicules. Comme si vous aviez construit une fusée et oublié de tenir compte de la gravité.

Le problème de contradiction que personne n'aborde

Mon objectif de départ était simple : si l'agent apprend quelque chose de nouveau, vérifier si ça contredit ce qu'il "sait" déjà. Ça paraît raisonnable. Une mémoire qui contredit d'autres mémoires sans explication, c'est pas juste inutile — c'est activement nuisible. Vous polluent le context window avec des informations contradictoires.

Quoi de plus simple ? Comparez deux faits. Signalez le conflit.

Sauf que.

Qu'est-ce qu'une vraie contradiction dans un système pareil ? Si l'agent a appris lundi que "le Projet X utilise PostgreSQL" et mardi que "le Projet X utilise MySQL", c'est une contradiction ? Peut-être que la stack technique a changé. Peut-être qu'une source avait tort. Peut-être que "Projet X" désigne deux projets différents. Peut-être que "utilise" veut dire des choses différentes selon le contexte.

Les humains gèrent ça grâce à des années de bon sens accumulé, de contexte, et cette capacité de dire "ça me paraît pas juste" sans pouvoir expliquer exactement pourquoi. Les systèmes IA peuvent générer du texte confiant sur chacune de ces interprétations, mais cette confiance n'est souvent que du pattern matching sans vraie compréhension.

Là où le vibe coding s'effondre

Le vibe coding est excellent pour résoudre des problèmes que vous pouvez articuler clairement. Vous avez un bug ? Décrivez les symptômes. Vous avez besoin d'une fonction ? Spécifiez les entrées et les sorties. L'IA gère l'implémentation avec une compétence remarquable.

Mais le system design — le vrai — c'est résoudre des problèmes que vous ne pouvez pas articuler clairement. C'est anticiper les interactions entre des composants qui n'existent pas encore. C'est poser la question "qu'est-ce qui se passe si..." pour des scénarios que vous n'avez pas imaginés.

Quand j'ai demandé à mon assistant IA d'implémenter de la "détection de contradictions," je lui demandais essentiellement de résoudre un problème que je ne savais pas définir précisément. Les résultats étaient... créatifs. On a exploré les treillis de Belnap, la logique à quatre valeurs, la vérification formelle avec des preuves Agda, les réseaux de Petri. L'assistant était partnant pour tout ce que je suggérais, et honnêtement, certaines idées étaient vraiment intéressantes.

Mais "intéressant" ne veut pas dire "qui fonctionne."

La preuve en Agda était correcte. L'architecture était bien documentée. Et le système ne détectait toujours pas les contradictions de manière fiable parce qu'on formalisait la mauvaise abstraction. On construisait une belle cathédrale sur un foundations de sable, et ni l'IA ni moi ne l'avons vu avant d'y avoir passé des mois.

La vérité qui fait mal

Voici ce que les défenseurs du vibe coding ne vous disent pas : la partie difficile du développement logiciel n'a jamais été de taper le code. C'est de savoir quoi construire.

Ça a toujours été vrai. Ce qui a changé, c'est que l'écart entre "j'ai eu une idée" et "j'ai du code" s'est effondré. C'est génial pour le prototypage, pour l'apprentissage, pour explorer ce qui est possible.

Mais ça signifie aussi que vous pouvez échouer plus vite et plus cher qu'avant. Vous pouvez générer des montagnes de code qui ont l'air de résoudre le problème, et vous pourriez ne pas vous en rendre compte avant d'avoir construit tout un système sur des fondations bancales.

Ce qui aide vraiment

Rien de tout ça ne signifie que le développement assisté par IA est une mauvaise idée. Ce n'est pas le cas. Mais l'utiliser efficacement demande des compétences différentes de la simple capacité de coder :

Vous devez savoir ce que vous ne savez pas. Quand l'IA suggère une solution dans un domaine que vous ne maîtrisez pas, c'est pas le moment de dire "ok, go." C'est le moment d'approfondir.

Les preuves de concept doivent être testées sans pitié contre des cas d'usage réels. Si vous construisez un système de mémoire, passez autant de temps à essayer de le casser que vous en avez passé à le construire. Essayez surtout de casser les hypothèses de base que vous ne saviez pas que vous faisiez.

La confiance n'est pas la vôtre. Quand un assistant IA est très confiant sur une décision de design, cette confiance réside dans le modèle, pas dans votre compréhension. Un système que vous ne comprenez pas profondément est un système que vous ne pouvez pas maintenir ou débugger.

Le system design reste une discipline. Vous pouvez utiliser l'IA pour explorer des designs plus vite, pour implémenter des morceaux de systèmes plus rapidement, pour prototyper des idées qui auraient pris des semaines à construire manuellement. Mais vous avez toujours besoin de quelqu'un capable d'évaluer si le design a du sens, si les composants interagissent correctement, si les abstractions de base tiennent la route.

Le mot de la fin

Je construis toujours mon outil de mémoire. Il s'améliore, lentement. J'ai appris à poser d'autres questions, à tester plus rigoureusement, à me méfier des résultats "qui font le job."

Mais j'ai aussi appris à respecter l'écart entre "le code fonctionne" et "le système est correct." Cet écart a toujours existé. Les outils IA ne l'ont pas comblé — ils ont juste rendu plus facile de l'ignorer.

Les meilleurs vibe codeurs ne sont pas ceux qui ont les meilleures compétences en prompting. Ce sont ceux qui savent quand le vibe est mauvais.

Prêt à explorer ce qui est possible avec l'hébergement et le développement assistés par IA ? Le Vibe Hosting de NameOcean combine une infrastructure puissante avec les outils dont vous avez besoin pour construire, déployer et faire évoluer votre prochain projet.