Sommaire
En juin 2025, j’écrivais un article pour opposer deux manières de développer avec l’intelligence artificielle. D’un côté, le Vibe Coding : on formule une intention, on laisse l’IA produire, on teste, on corrige, puis on avance tant que le résultat semble fonctionner. De l’autre, une approche plus structurée que j’appelais alors Prompt-Driven Development, dans laquelle on essayait de mieux cadrer l’IA avec du contexte, des contraintes, une architecture, des tests et des règles de développement.
RSS
Le RSS envoie les nouveaux articles dans le lecteur de votre choix, sans algorithme ni newsletter.
Un peu plus d’un an plus tard, on pense toujours que cette distinction était pertinente. Mais elle ne suffit déjà plus à décrire ce qui est en train de se passer. Le débat ne se limite plus à savoir s’il faut “viber” ou mieux rédiger ses prompts. Entre-temps, les agents de développement ont profondément changé la manière dont nous travaillons. Le vrai sujet est désormais beaucoup plus large : il ne s’agit plus seulement de savoir comment parler à une IA, mais de savoir dans quel environnement on la fait travailler.
Mon article de 2025 n’était pas faux, il appartenait simplement à une autre étape
Quand on relis ce que j’écrivais à l’époque, on vois surtout à quel point notre manière d’utiliser l’IA a évolué rapidement. En 2025, une grande partie du développement assisté par IA reposait encore sur une logique conversationnelle. On demandait une fonctionnalité, l’IA proposait du code, on le copiait dans le projet, on rencontrait éventuellement une erreur, puis on retournait dans la conversation pour demander une correction.
Dans ce contexte, la qualité de la demande avait énormément d’importance. Plus on donnait de contexte, plus on détaillait les contraintes et plus on décrivait précisément ce qu’on attendait, plus on augmentait les chances d’obtenir une réponse exploitable. C’est ce qui m’avait amené à opposer le Vibe Coding à une approche plus structurée.
Aujourd’hui, cette représentation me paraît déjà presque limitée. Quand on travaille avec un agent de développement, on ne lui demande plus simplement de produire du code. On lui donne accès à un projet, à ses fichiers, à ses conventions, à ses tests, à ses outils et parfois à d’autres agents. On lui donne un environnement dans lequel il peut explorer, modifier, vérifier et recommencer.
La différence peut sembler légère dans la formulation, mais elle change profondément la nature du travail.
Le Vibe Coding reste extrêmement efficace
Il faut tout de même commencer par reconnaître quelque chose : le Vibe Coding fonctionne très bien dans de nombreux cas. Pour prototyper une idée, expérimenter rapidement, construire un outil personnel ou tester une technologie, il est difficile de faire plus rapide. On décrit ce que l’on souhaite obtenir, l’IA produit quelque chose, on regarde si cela correspond au besoin et on ajuste progressivement.
Dans ce contexte, chercher immédiatement une architecture parfaite ou une couverture de tests complète peut même être contre-productif. Tout dépend de ce que l’on est en train de construire et surtout de la durée de vie attendue du projet.
Le problème apparaît lorsque cette logique d’exploration devient la méthode de développement principale d’un logiciel destiné à vivre plusieurs années. Un programme peut très bien fonctionner aujourd’hui tout en étant fragile, difficile à maintenir ou incompréhensible quelques mois plus tard. Une fonctionnalité peut donner le bon résultat tout en introduisant une mauvaise abstraction ou une faille de sécurité. Un agent peut également terminer une tâche en ayant modifié bien plus de choses que ce qui était réellement nécessaire.
C’est là que le constat de mon premier article reste valable : obtenir quelque chose qui fonctionne n’est pas la même chose que construire quelque chose que l’on comprend et que l’on pourra maintenir.
Le prompt a perdu une grande partie de son statut central
Pendant longtemps, beaucoup de discussions autour de l’IA générative dans le développement tournaient autour du prompt engineering. On expliquait qu’il fallait apprendre à parler aux modèles, à structurer les demandes, à définir des rôles, à fournir des exemples et à détailler chaque étape.
Ces bonnes pratiques n’ont pas disparu, mais dans ma manière de travailler aujourd’hui, le prompt est loin d’être la partie la plus importante du système. On peux envoyer une instruction assez simple comme “corrige ce bug et ajoute les tests nécessaires” et déclencher derrière une séquence de travail beaucoup plus complexe.
L’agent va explorer le dépôt, identifier les fichiers concernés, rechercher comment une fonctionnalité similaire est implémentée ailleurs, modifier plusieurs fichiers, lancer des commandes, exécuter des tests, analyser leurs résultats, puis corriger son propre travail. À ce stade, la qualité du résultat ne dépend plus uniquement de la phrase que j’ai écrite au départ.
Elle dépend surtout de ce que l’agent trouve autour de lui.
S’il comprend correctement l’architecture, s’il connaît les conventions du projet, s’il dispose de tests pertinents et s’il peut utiliser les bons outils, une instruction relativement courte peut suffire. À l’inverse, le meilleur prompt du monde ne compensera jamais totalement un projet mal documenté, sans tests et rempli de règles implicites que seule l’équipe connaît.
C’est pour cette raison que le débat sur le prompt me semble aujourd’hui beaucoup moins intéressant que celui sur le contexte et l’environnement de travail.
Le repository devient lui aussi un outil pour l’IA
C’est probablement l’un des changements les plus importants de cette dernière année. Lorsque on construis aujourd’hui un projet fortement assisté par des agents, on ne réfléchis plus uniquement à ce que les développeurs humains doivent comprendre. On réfléchis également à ce que les agents doivent pouvoir comprendre sans devoir tout réinventer à chaque tâche.
Cela change la manière de documenter un projet. Les conventions, les décisions d’architecture, les commandes utiles, les règles de sécurité ou les comportements métier ne sont plus seulement une documentation destinée à un développeur qui rejoindra l’équipe dans six mois. Elles deviennent directement exploitables par les agents qui travaillent quotidiennement sur le code.
Des fichiers comme AGENTS.md, des documentations internes bien entretenues, des exemples d’implémentation, des tests automatisés ou des scripts de validation prennent alors une nouvelle valeur. Ils servent toujours aux humains, mais ils deviennent également une partie du contexte opérationnel de l’IA.
On commence donc progressivement à concevoir le repository comme un environnement capable d’expliquer lui-même comment il doit être modifié.
Et à mon sens, c’est beaucoup plus intéressant que de chercher le prompt parfait.
De plus en plus, on parle de harnais de développement
J’utilise de plus en plus le mot “harnais” pour décrire cet environnement. L’image me paraît assez juste : un modèle peut être extrêmement puissant, mais cette puissance doit être canalisée si l’on veut l’utiliser sur un projet réel.
Un agent peut proposer une excellente solution. Il peut également inventer une API, prendre une mauvaise hypothèse métier pour une vérité ou considérer qu’une tâche est terminée simplement parce que son code compile. Son principal problème n’est pas forcément un manque de capacité. C’est souvent un manque de contraintes et de feedback.
Le harnais sert précisément à réduire cet espace d’incertitude.
Git permet de voir ce qui a réellement changé. Les tests donnent un retour objectif sur certains comportements. Le lint empêche certaines dérives de style ou de structure. La documentation fournit le contexte nécessaire. Les outils permettent de rechercher une information réelle plutôt que de laisser le modèle la deviner. Les règles définissent ce qui est autorisé, ce qui est interdit et ce qui nécessite une validation humaine.
Pris séparément, aucun de ces éléments n’est nouveau. Git, les tests et la documentation existaient évidemment bien avant les LLM. Ce qui change, c’est qu’ils deviennent désormais des composants directs du système de travail des agents.
En 2025, on pensais beaucoup à la qualité de l’instruction donnée à l’IA. En 2026, on pense beaucoup plus à la qualité du système qui l’entoure.
Un mauvais environnement pousse l’IA à inventer
Prenons un exemple simple. Vous demandez à un agent de modifier une fonctionnalité métier relativement complexe. Vous pouvez passer énormément de temps à rédiger une demande détaillée, mais si le projet ne contient aucune documentation métier, peu de tests et beaucoup de conventions implicites, l’agent devra combler les trous.
Et c’est précisément ce que les modèles savent faire.
Le problème est qu’en développement logiciel, compléter ce qui semble probable n’est pas toujours ce que l’on souhaite. On ne veut pas simplement une réponse plausible. On veut une réponse compatible avec la réalité du produit, de son historique et de ses contraintes.
À l’inverse, lorsqu’un projet contient une documentation claire, des tests cohérents et des règles explicites, l’agent peut travailler avec des instructions beaucoup plus simples. Il dispose de suffisamment d’éléments pour vérifier ses hypothèses au lieu de devoir les inventer.
C’est une évolution importante dans ma propre manière de travailler : lorsque l’IA se trompe, ma première réaction n’est plus systématiquement de réécrire le prompt. On me demande d’abord ce qui manquait dans l’environnement pour qu’elle prenne cette mauvaise décision.
Parfois, il faut ajouter une règle. Parfois, il faut écrire un test. Parfois, il faut documenter une décision d’architecture. Parfois, il faut simplement empêcher l’agent d’accéder à certaines actions.
Dans tous les cas, on améliore le système plutôt que la conversation.
Le code est devenu abondant, pas le bon logiciel
Il y a également une transformation économique derrière tout cela. Pendant longtemps, écrire du code représentait une part importante du coût de développement. Produire une implémentation demandait du temps, parfois beaucoup de temps, et la capacité à produire rapidement du code correct avait évidemment beaucoup de valeur.
Avec les agents, le coût de cette production s’effondre.
Générer plusieurs variantes d’une implémentation n’est plus réellement un problème. Réécrire une partie d’un composant, créer des tests ou produire une migration peut désormais prendre quelques minutes là où cela représentait auparavant une quantité de travail beaucoup plus importante.
Mais cela ne signifie pas que produire du bon logiciel est devenu facile.
Un logiciel n’est pas seulement du code. Il est composé d’un historique, de décisions métier, de dépendances, de contraintes de sécurité, de performances, d’utilisateurs et parfois de compromis qui semblent étranges si l’on ne connaît pas leur origine.
C’est là que la différence entre produire du code et construire un logiciel devient encore plus visible.
Le code est progressivement devenu abondant. Le jugement technique, lui, reste rare.
Le métier de développeur ne disparaît pas, son centre de gravité se déplace
La question “l’IA va-t-elle remplacer les développeurs ?” me paraît de moins en moins intéressante. Elle suppose que le métier serait une activité homogène que l’on pourrait automatiser d’un seul bloc.
La réalité est beaucoup plus progressive.
Certaines tâches sont déjà largement absorbées par les agents. Créer un CRUD, ajouter un endpoint simple, écrire une migration, générer des tests basiques, refactorer du code répétitif ou explorer un repository inconnu sont devenus beaucoup plus rapides.
Cela ne signifie pas que le développeur n’a plus de rôle. Cela signifie surtout que sa valeur se déplace vers les parties que l’agent gère moins bien : comprendre le vrai problème, découper correctement le travail, choisir une architecture, identifier les contraintes invisibles, reconnaître une abstraction inutile ou décider qu’une solution techniquement correcte est mauvaise pour le produit.
Il faut également décider ce que l’on souhaite automatiser et, parfois plus important encore, ce que l’on ne veut pas automatiser.
Plus les agents deviennent capables, plus cette capacité de décision prend de la valeur.
Savoir coder reste essentiel
Il existe pourtant un paradoxe assez intéressant. Plus les agents produisent facilement du code, plus certains considèrent qu’il devient inutile de comprendre ce code.
On pense exactement l’inverse.
Lorsque on travaille avec plusieurs agents, on peux générer bien plus de modifications dans une journée qu’auparavant. Mais cela signifie également que on dois évaluer beaucoup plus de décisions techniques. La vitesse de production augmente, donc la capacité de validation doit augmenter avec elle.
Le goulot d’étranglement n’est plus nécessairement l’écriture.
Il devient progressivement la compréhension.
Un agent peut générer plusieurs centaines de lignes de code très rapidement. Cela ne signifie pas qu’elles devraient exister. Il peut proposer une architecture cohérente sans qu’elle soit adaptée au produit. Il peut également écrire des tests parfaitement verts qui ne vérifient pas réellement le comportement important.
Et surtout, il peut expliquer avec beaucoup d’assurance pourquoi tout cela est correct.
Cette explication n’est toujours pas une preuve.
Git, les diffs et les tests deviennent encore plus importants
C’est peut-être l’un des paradoxes les plus intéressants du développement agentique : plus les outils deviennent modernes, plus certains fondamentaux du développement deviennent importants.
Git est plus utile que jamais. Les diffs sont plus utiles que jamais. Les tests sont plus utiles que jamais.
Lorsqu’un agent m’annonce qu’une fonctionnalité est terminée, ce n’est pas réellement cette phrase qui m’intéresse. On veux savoir quels fichiers ont changé, quelles dépendances ont été ajoutées, quelles commandes ont été exécutées et quels comportements ont réellement été vérifiés.
On veux également être capable de comprendre ce qui s’est passé plusieurs semaines plus tard si quelque chose casse.
Dans un monde où générer du code coûte de moins en moins cher, la traçabilité devient paradoxalement plus précieuse.
Le développeur doit pouvoir reconstruire le raisonnement technique derrière les modifications, même si une grande partie de la production a été automatisée.
Le prochain défi sera la supervision des agents
Nous sommes encore au début de cette transformation. Aujourd’hui, beaucoup de développeurs utilisent principalement un agent dans un terminal. Mais on voit déjà apparaître des environnements dans lesquels plusieurs agents travaillent simultanément sur différentes parties d’un projet.
Un agent peut s’occuper du frontend pendant qu’un autre travaille sur l’API. Un troisième peut analyser les tests, un quatrième vérifier les changements et un autre rechercher de la documentation ou analyser un problème remonté en production.
À ce stade, le problème devient très différent de celui du Vibe Coding.
Il faut savoir quel agent a fait quoi, comprendre pourquoi une décision a été prise, éviter que plusieurs agents modifient simultanément les mêmes fichiers et s’assurer que le contexte circule correctement entre eux. Il faut aussi pouvoir détecter lorsqu’un agent tourne en boucle, lorsqu’un sous-agent n’a pas réellement été lancé ou lorsqu’une étape supposée être automatisée ne l’a finalement pas été.
On commence donc à toucher à des problématiques proches de l’orchestration, de l’observabilité et de la supervision.
Et là encore, le prompt n’est plus le sujet principal.
Nous passons de “coder avec l’IA” à “architecturer le travail de l’IA”
Si on devais résumer cette évolution en une phrase, ce serait probablement celle-ci : en 2025, j’apprenais surtout à coder avec l’IA ; en 2026, j’essaie surtout d’architecturer la manière dont elle travaille.
Dans le premier modèle, l’IA est essentiellement un outil que le développeur interroge. Dans le second, elle devient un acteur du système de développement. Elle possède un contexte, des outils, des responsabilités, des contraintes et parfois la capacité de déléguer une partie de son travail.
Le rôle du développeur se rapproche alors progressivement de celui d’un architecte ou d’un orchestrateur. Il ne s’agit plus simplement de produire chaque ligne de code soi-même, mais de construire un environnement dans lequel les agents peuvent produire, vérifier et corriger leur travail tout en restant sous contrôle.
Cela demande une compétence différente.
Pas nécessairement moins technique.
Probablement même l’inverse.
Alors, Vibe Coding ou Prompt-Driven ?
Un an plus tard, on répondrais donc différemment à la question qui était au cœur de mon premier article.
Le Vibe Coding reste une excellente méthode d’exploration. Une approche structurée reste préférable dès que l’on souhaite davantage de maîtrise, de sécurité et de maintenabilité.
Mais on ne pense plus que cette opposition décrive correctement le futur du développement assisté par IA.
Nous entrons dans une troisième phase, dans laquelle la qualité du résultat dépend de moins en moins d’un prompt isolé et de plus en plus de l’ensemble du système autour du modèle. Le contexte, les outils, les tests, les règles, la mémoire, l’observabilité et les mécanismes de validation deviennent des éléments essentiels du processus.
Le développeur ne doit donc plus seulement apprendre à demander correctement quelque chose à une IA.
Il doit apprendre à construire les conditions dans lesquelles cette IA pourra travailler correctement.
Et c’est probablement là que se situe aujourd’hui la véritable rupture.
Dans le Vibe Coding, on fait confiance au résultat parce qu’il semble fonctionner.
Dans une approche agentique mature, on essaie de construire un système capable de nous donner de bonnes raisons de lui faire confiance.
Cet article fait suite à mon analyse publiée en juin 2025 : Vibe Coding vs Prompt-Driven : deux approches de l’IA générative pour développer. Un peu plus d’un an plus tard, il constitue surtout une photographie intéressante de la vitesse à laquelle notre manière de développer est en train de changer.
