Du vibe coding à l'agentic engineering

Il y a un an, Andrej Karpathy disait à tout le monde de se laisser porter par les vibes. Des millions l'ont fait. À coups de prompts, ils ont produit des MVP, des projets de week-end et des prototypes de startup où 95% du code venait d'un LLM.

Le Collins Dictionary a fait de vibe coding son mot de l'année 2025. Y Combinator a rapporté qu'un quart de son batch Winter 2025 tournait sur des bases de code presque entièrement générées par l'IA.

Puis est venue la gueule de bois.

La gueule de bois que personne n'avait prévue

En septembre 2025, Fast Company écrivait déjà sur des ingénieurs seniors coincés dans l'enfer du développement avec du code généré par l'IA. Une analyse de CodeRabbit portant sur 470 pull requests GitHub open source a constaté que "le code co-écrit avec l'IA contenait environ 1.7 fois plus de problèmes majeurs que le code écrit par des humains." Lovable, une plateforme suédoise de vibe coding, a livré 170 apps avec des failles de sécurité qui exposaient des données personnelles au premier venu.

Le schéma s'est répété partout : une équipe vibe-code un prototype, les parties prenantes s'enthousiasment, les ingénieurs doivent choisir entre reconstruire avec une vraie architecture ou durcir un prototype qui n'a jamais été pensé pour la production. Aucune des deux options n'est rapide. Aucune n'est bon marché.

METR a mené un essai contrôlé randomisé avec des développeurs open source expérimentés. Le résultat est brutal : les développeurs utilisant des outils de codage IA étaient 19% plus lents, alors qu'ils prédisaient être 24% plus rapides et croyaient encore après coup avoir été 20% plus rapides. L'écart de confiance entre performance perçue et performance réelle est la découverte la plus dangereuse de cette étude.

Le problème n'a jamais été l'IA

C'est là que la plupart des analyses se trompent. Le problème n'était pas que l'IA générait du mauvais code. Le problème, c'est que les gens ont sauté l'ingénierie.

Pas d'architecture. Pas de spécifications. Pas de tests. Pas de review. Juste des prompts et des prières.

Comme le dit Addy Osmani de Google Cloud : "Ce n'est pas l'IA qui a causé le problème. C'est d'avoir sauté la réflexion de conception."

Je l'ai vu de mes propres yeux. Dans mon article de février 2025 sur le codage assisté par IA, j'ai retracé l'évolution du no-code au low-code jusqu'au développement assisté par IA. La thèse tenait. L'IA permet aux ingénieurs de se concentrer sur l'architecture et la résolution de problèmes plutôt que sur le codage répétitif. Ce que j'ai sous-estimé, c'est le nombre de gens qui allaient complètement zapper la partie ingénieur.

Le vibe coding traitait le logiciel comme une conversation. Tape un prompt, reçois une app. Les vibes étaient super. Le code, non.

Voici l'agentic engineering

Le 5 février 2026, exactement un an après avoir inventé vibe coding, Karpathy a publié une mise à jour. Le nouveau terme : agentic engineering.

Beaucoup de gens ont retweeté ça comme le premier anniversaire du vibe coding. Petite rétrospective - j'ai un compte Twitter depuis 17 ans maintenant (omg) et je n'arrive toujours à peu près pas à prédire l'engagement de mes tweets. C'était un tweet jetable, une pensée sous la douche, que j'ai balancé comme ça… Andrej Karpathy (@karpathy) 4 février 2026

Son raisonnement : agentic parce que les développeurs n'écrivent plus la majorité du code directement. Ils orchestrent des agents et jouent le rôle de superviseurs. Engineering parce que le processus reste à la fois un art et une science, exige de l'expertise et s'apprend.

Ce n'est pas un rebranding. C'est un modèle de fonctionnement fondamentalement différent.

En vibe coding, tu promptes et tu espères. En agentic engineering, tu planifies, tu diriges et tu passes en revue. L'IA fait le travail répétitif. Toi, tu portes l'architecture, les garde-fous et les résultats.

Le 2026 Agentic Coding Trends Report d'Anthropic décrit le basculement : les équipes ne s'appuient plus sur un seul assistant de codage mais sur une flotte d'agents. L'un écrit du code, un autre génère des tests, un autre passe les changements en revue, un autre gère le déploiement. Le tout sous supervision humaine. TELUS a créé plus de 13,000 solutions IA sur mesure tout en livrant du code d'ingénierie 30% plus vite. Zapier a atteint 89% d'adoption de l'IA dans toute son organisation avec 800+ agents déployés en interne.

Les ingénieurs qui s'en sortent le mieux ne sont pas les prompteurs les plus rapides. Ce sont ceux qui pensent le plus clairement à ce qu'ils construisent et pourquoi.

Ce qui a vraiment changé

Le passage du vibe coding à l'agentic engineering reflète un schéma que j'ai vu dans chaque vague tech au cours de mes deux décennies à construire des sociétés de logiciels.

Phase un : l'euphorie de la démocratisation. Tout le monde peut le faire. Les barrières ont disparu.

Phase deux : la gueule de bois. Il s'avère qu'en supprimant les barrières, on a aussi supprimé les contrôles qualité.

Phase trois : la professionnalisation. L'outil reste. La discipline revient.

Nous entrons dans la phase trois en ce moment même.

Dario Amodei écrivait en janvier 2026 que "les modèles d'IA sont devenus si compétents en programmation que certains des meilleurs ingénieurs qu'il connaît confient presque tout leur travail de codage à l'IA." Mais, et c'est le mais décisif, ce sont des ingénieurs solides. Ils savent quoi déléguer, quoi vérifier, et quand l'agent se trompe avec assurance.

Meta vient de publier une recherche sur les Just-in-Time Tests. Des tests générés par l'IA, créés à la volée pour chaque changement de code, parce que les suites de tests traditionnelles ne suivent plus la vitesse du développement agentique. La discipline de test n'a pas disparu. Elle a évolué.

Ce que ça change pour les product managers et les fondateurs

Si tu construis du logiciel en 2026, que tu sois PM, fondateur ou responsable technique, voici ce qui compte vraiment maintenant.

Les spécifications avant les prompts. Les équipes qui tirent de la valeur de l'agentic engineering écrivent des documents de conception avant de toucher à un agent de codage. Des specs claires donnent un meilleur output IA. Des prompts vagues donnent du code vague qui casse à l'échelle.

L'output de l'IA n'est pas fiable par défaut. Traite chaque ligne de code générée par l'IA comme tu traiterais la pull request d'une nouvelle recrue. Passe-la en revue, teste-la, questionne-la. Le scan de sécurité automatisé à chaque point d'intégration n'est pas optionnel.

Le moat, c'est le workflow, pas le modèle. L'intelligence est une commodité. La valeur de ton produit vit dans le contexte, la gestion d'état et les couches de confiance, pas dans le LLM que tu loues. Si on enlève l'IA et qu'il ne reste qu'une zone de texte, tu as construit un tableur avec des étapes en plus.

Le rôle passe de l'écriture à l'orchestration. Les product managers qui utilisent des outils comme Claude Code ne codent pas. Ils explorent des bases de code, synthétisent de la recherche et construisent des compétences réutilisables. Le même basculement vaut pour l'ingénierie : moins taper, plus réfléchir.

Le passage où je me contredis

Le vibe coding n'est pas mort. Et il ne devrait pas l'être.

Pour des outils personnels, des dashboards internes, des prototypes qui ne verront jamais la production, prompter jusqu'à une app fonctionnelle en un après-midi reste génial. Le logiciel pour un seul cas d'usage est réel et a de la valeur.

L'erreur a été de traiter une technique de prototypage comme une méthodologie de production. Un état d'esprit de hackathon appliqué au logiciel d'entreprise. C'est là que ça a cassé.

L'agentic engineering ne tue pas la vibe. Il met la vibe dans un cadre qui livre vraiment.

La suite

La ligne d'évolution est claire : no-code, low-code, codage assisté par IA, vibe coding, agentic engineering. Chaque étape a donné à plus de gens plus de pouvoir pour construire. Chaque étape a aussi créé une nouvelle catégorie de problèmes que seule la discipline pouvait résoudre.

Les organisations qui prennent de l'avance en 2026 ne sortent pas les ingénieurs de la boucle. Elles font compter l'expertise d'ingénierie là où elle pèse le plus : architecture, sécurité, conception de systèmes. Les agents s'occupent de l'implémentation.

La question pour ton équipe n'est pas de savoir s'il faut utiliser l'IA pour le développement. Ce débat est clos.

La question, c'est de savoir si tu vibes ou si tu fais de l'ingénierie.

L'un des deux scale. L'autre génère des factures de conseil pour le nettoyage.