Vibe coding ou agentic coding ? La différence qui décide de la responsabilité

Le vibe coding juge le résultat, l'agentic coding pilote le chemin. Avec le vibe coding, vous vérifiez si le programme fait ce qu'il doit faire. Avec l'agentic coding, un agent travaille selon un plan validé, avec des points de contrôle définis et une trace traçable. La différence n'est pas une querelle de mots — elle décide si quelqu'un peut, au final, assumer la responsabilité.

Quelle est la différence entre le vibe coding et l'agentic coding ?

Les deux utilisent les mêmes modèles et souvent le même outil. Ce qui les sépare, c'est ce qui se passe entre l'intention et le résultat.

Quand le vibe coding est-il le bon mode ?

Chaque fois que le résultat est de toute façon jetable. Une maquette qui répond à une question n'a pas besoin d'être maintenable — elle doit répondre à la question. Investir de l'effort de vérification dans un prototype qui sera supprimé demain n'est pas de la rigueur, mais du gaspillage.

L'erreur commence plus tard : le prototype convainc, quelqu'un dit « mais ça tourne », et la maquette jetable devient la première version. Comment réussir proprement ce passage, l'article Du prototype à la production l'explique.

Quand ai-je besoin de l'agentic coding ?

Dès que le code vit plus longtemps que la session dans laquelle il est né. Trois caractéristiques définissent ce mode dans la pratique.

• Un plan avant la première modification. Que doit-il se passer, quels fichiers sont concernés, à quoi mesure-t-on le succès ? Un plan est vérifiable, un historique de prompts ne l'est pas.
• Une validation explicite aux endroits critiques. Toutes les lignes n'ont pas besoin d'une validation. Une refonte de schéma, un déploiement ou une nouvelle dépendance, si.
• Une preuve plutôt qu'une affirmation. À la fin, on ne lit pas « c'est fait », mais la sortie de l'exécution des tests, du contrôle d'état, du diff.

Comment savoir dans quel mode mon équipe travaille actuellement ?

À une seule question : quelqu'un peut-il reconstituer pourquoi une modification a l'aspect qu'elle a ?

Si la réponse est « c'est ce que l'IA a fait », vous travaillez en mode vibe, indépendamment de l'outil utilisé et du caractère professionnel que paraît avoir le déroulement. Ce n'est pas un reproche — c'est un état des lieux dont vous avez besoin pour décider si cet état est approprié pour le code concerné.

Trois autres indices affinent le tableau, et tous les trois peuvent être vérifiés n'importe quel mercredi :

• Le diff n'a pas été ouvert. Lorsque les modifications sont validées en bloc parce que « les tests sont verts », l'exécution des tests remplace la lecture — alors qu'elle ne vérifie que ce que quelqu'un savait auparavant devoir vérifier.
• Les erreurs sont corrigées en reformulant. Un échec conduit au prompt suivant au lieu de la recherche de cause. Le symptôme disparaît, la cause reste et se manifeste ailleurs.
• Personne ne sait quels paquets sont nouveaux. Si la réponse à « qu'est-ce qui s'est ajouté cette semaine ? » est un coup d'œil au fichier de verrouillage au lieu d'un souvenir, personne n'a pris la décision.

La Stack Overflow Developer Survey 2025 fournit le contexte : 84 pour cent des personnes interrogées utilisent des outils d'IA ou prévoient de le faire, mais seuls 33 pour cent font confiance à l'exactitude des résultats, tandis que 46 pour cent s'en méfient expressément. Une équipe qui se méfie majoritairement de ses outils et travaille pourtant sans points de contrôle n'a pas un problème d'outil, mais un problème de processus.

Pourquoi la distinction devient juridiquement pertinente

Parce qu'à partir de décembre 2026, le logiciel est expressément responsable en tant que produit. Le calendrier : la directive européenne sur la responsabilité du fait des produits (UE) 2024/2853 est entrée en vigueur le 9 décembre 2024, le législateur allemand a adopté la réforme en 2026, et les nouvelles obligations s'appliquent à partir du 9 décembre 2026. Sont alors couverts les logiciels et les systèmes d'IA en tant que produits, avec des allègements de la charge de la preuve pour les personnes lésées et des obligations de divulgation pour les fabricants.

Concrètement, cela signifie que celui qui doit démontrer en cas de litige qu'il a développé avec soin a besoin de quelque chose de présentable. Un plan, une validation et une preuve de test sont présentables. Un historique de chat l'est à peine. Les détails sont traités dans l'article Qui est responsable du code généré par IA.

Comment passer du mode vibe au mode agentique ?

En trois étapes, qui peuvent être introduites séparément et qui fonctionnent chacune déjà seule.

• Étape un : un plan avant la modification, mais seulement pour la liste critique. Authentification, paiement, schéma, déploiement, nouvelle dépendance. Tout le reste continue comme avant. Cette restriction est la raison pour laquelle l'étape est acceptée — elle ne ralentit pas quatre-vingt-dix pour cent du travail.
• Étape deux : consigner les décisions. Lorsque deux voies étaient possibles dans le plan, une phrase doit dire pourquoi celle-ci a été retenue. C'est l'information qui manquera dans six mois et qu'aucun diff ne contient.
• Étape trois : une preuve plutôt qu'une promesse. Le message de fin contient la sortie de l'exécution des tests. Pas l'affirmation qu'elle a eu lieu.

L'ordre repose sur une observation : les équipes qui commencent par l'étape trois produisent des preuves pour un travail que personne n'a planifié. Les équipes qui commencent par l'étape un ont, au bout de quelques semaines, quelque chose qui vaut la peine d'être prouvé.

Questions fréquentes

L'agentic coding est-il simplement du vibe coding avec plus de bureaucratie ?

La différence n'est pas la quantité de formalisme, mais son emplacement. L'agentic coding déplace l'effort vers l'amont — dans le plan et la validation — et l'économise en aval, lors de la recherche d'erreurs dans du code que personne n'a lu.

Un agent peut-il aussi travailler en mode vibe ?

Oui, et c'est l'abus le plus fréquent du terme. Un outil agentique seul ne crée pas un processus agentique. Sans plan, validation et preuve, un agent n'est qu'un vibe coding plus rapide avec une portée plus grande.

Chaque modification a-t-elle besoin d'une validation ?

Non. Une gradation selon le dommage est judicieuse : pas pour une correction de texte, toujours pour une refonte de schéma, un déploiement, une modification de l'authentification ou du paiement. Où se situe exactement le seuil est une décision d'équipe — elle doit seulement être prise et consignée, et non improvisée au cas par cas.

Comment commencer l'agentic coding ?

Avec une seule règle : avant toute modification d'une liste définie de domaines critiques, il y a un plan qui est validé. Tout le reste en découle.

Plan, validation et preuve ne fonctionnent que s'ils ne dépendent pas de la forme du jour. Code Guardian en fait un déroulement fixe : analyse en lecture seule, chaque décision ouverte soumise une par une, plan avec journal des décisions, et ce n'est qu'après votre validation que l'on construit.

Sources

• Stack Overflow Developer Survey 2025, section « AI » (usage, confiance).
• Directive (UE) 2024/2853 relative à la responsabilité du fait des produits défectueux, en vigueur le 9 décembre 2024, délai de transposition le 9 décembre 2026.

État au 27 juillet 2026. Information générale, pas un conseil juridique.