Vibe coding et développement guidé par des spécifications : deux façons de travailler avec l’IA

On peut demander à une intelligence artificielle de construire une application, regarder le résultat, puis lui dire : « Change ça, ajoute ceci, corrige cette erreur. » On peut aussi lui donner un besoin précis, des contraintes et des critères de réussite, puis examiner ce qu’elle produit à chaque étape.

Dans les deux cas, l’IA écrit du code. Pourtant, la manière de conduire le projet change profondément.

Le vibe coding privilégie l’exploration par la conversation et le résultat visible. Le développement guidé par des spécifications cherche à rendre les attentes explicites, puis à vérifier que le code les respecte. Pour les comparer, il faut regarder ce que le développeur comprend, décide et contrôle.

Ce que recouvre le vibe coding

Andrej Karpathy a popularisé le terme en 2025. Dans son bilan de cette année, il renvoie à son message d’origine et décrit une pratique où l’on demande des programmes en langage naturel, au point de ne plus se préoccuper du code lui-même.

Le terme a depuis pris des sens plus larges. Dans cet article, nous retenons ce sens précis : on pilote surtout par les demandes et les essais, sans nécessairement lire ni comprendre l’implémentation.

Une boucle typique ressemble à ceci : décrire une idée, laisser l’IA la réaliser, essayer, puis demander des ajustements. Une erreur apparaît ? On la transmet à l’assistant. L’écran ne convient pas ? On décrit le changement souhaité.

Cette démarche peut aider à explorer une interface, matérialiser une intuition ou fabriquer un petit outil provisoire. Voir une première version donne aussi matière à préciser un besoin encore flou.

La difficulté apparaît lorsque « ça marche dans mon essai » devient le seul critère de validation. Un parcours réussi ne dit pas comment le logiciel traite les erreurs, protège les données ou se comportera après plusieurs modifications.

Utiliser l’IA ne signifie pas abandonner la compréhension

Un développeur peut faire générer une grande partie de son code tout en gardant la maîtrise du projet : il examine les changements, comprend les choix importants, vérifie les comportements et refuse les solutions inadaptées.

Cela ne suppose pas de mémoriser chaque ligne. Il faut cependant pouvoir expliquer où les données circulent, quelles règles sont appliquées et pourquoi les vérifications donnent confiance dans le résultat.

Karpathy distingue lui-même, dans son compte rendu de Sequoia Ascent 2026, le vibe coding et une pratique professionnelle de supervision des agents, qu’il appelle agentic engineering. Le développement guidé par des spécifications peut participer à cette supervision ; il n’en couvre pas tous les aspects.

Ce qu’une spécification apporte

Une spécification décrit le comportement attendu. Elle répond à des questions concrètes : pour qui développe-t-on cette fonctionnalité ? Que doit-elle permettre ? Quelles limites faut-il respecter ? Comment saura-t-on qu’elle est correcte ?

Elle peut tenir dans une courte note pour une petite évolution. Sa valeur vient de sa précision et de son usage pendant le développement.

Il est utile de distinguer trois éléments :

• Le besoin : ce que l’utilisateur doit pouvoir accomplir.
• Les contraintes : les règles métier et les limites techniques à respecter.
• Les critères d’acceptation : des situations observables permettant de vérifier le résultat.

Le plan technique explique ensuite comment réaliser ce besoin. Cette séparation permet de discuter d’abord du comportement souhaité, puis des moyens de l’obtenir.

Des outils organisent ce travail. La documentation officielle de GitHub Spec Kit distingue la définition du besoin, la clarification, le plan, les tâches et l’implémentation. Elle prévoit aussi des contrôles de cohérence entre ces documents. Kiro structure ses spécifications autour des exigences, de la conception et des tâches.

Ces outils donnent une organisation au travail. Leur présence ne garantit pas que les exigences soient bonnes ni que le code soit correct.

Un même exemple : enregistrer des articles à lire

Imaginons une application où chaque personne connectée conserve une liste d’articles à lire. L’exemple suivant est fictif.

Dans une démarche de vibe coding, la première demande pourrait être :

Crée une liste de lecture. Je veux ajouter un lien, voir les articles enregistrés et supprimer ceux que j’ai lus.

L’IA propose une version. On l’essaie, puis on demande un bouton plus visible, un titre pour chaque lien ou un autre classement. Cette boucle aide à découvrir l’expérience souhaitée.

Mais plusieurs décisions restent implicites. La liste survit-elle à un rechargement ? Un utilisateur peut-il accéder à celle d’un autre ? Que se passe-t-il si l’enregistrement échoue ? L’IA devra proposer des réponses, qui peuvent ne pas correspondre au besoin.

Dans une démarche guidée par des spécifications, on rend ces attentes explicites avant l’implémentation :

• Une personne connectée ajoute un titre et une adresse HTTP ou HTTPS.
• Chaque entrée appartient à son compte. Le serveur vérifie ce droit pour la consulter ou la supprimer.
• La liste reste disponible après déconnexion et reconnexion.
• Si l’enregistrement échoue, un message apparaît et les champs saisis sont conservés.
• Cette première version ne télécharge pas le contenu des liens et ne crée pas de partage public.

On ajoute ensuite des critères d’acceptation :

Après avoir enregistré un article puis rechargé la page, je retrouve cet article dans ma liste.

Connecté avec un second compte, je ne peux ni consulter ni supprimer l’entrée du premier, même en envoyant directement une requête au serveur.

Si l’enregistrement échoue, l’interface ne présente pas l’article comme enregistré et conserve ma saisie.

L’IA peut alors proposer un plan, réaliser les changements et aider à écrire les tests correspondants. La relecture porte sur des engagements précis. Les inconnues apparaissent aussi plus facilement : par exemple, faut-il autoriser deux entrées avec la même adresse ?

Les spécifications ont aussi leurs limites

Une spécification vague peut donner une apparence de rigueur sans résoudre les ambiguïtés. « L’application doit être sécurisée » n’indique ni les accès autorisés ni les vérifications attendues.

Une spécification erronée pose un autre problème : l’IA peut réaliser fidèlement une mauvaise demande. Et si le document n’évolue plus avec le produit, il cesse d’être une référence fiable.

Il existe également un coût de préparation et de maintenance. Imposer plusieurs documents détaillés à une expérience de quelques heures peut ralentir l’exploration. Le cadre doit rester proportionné au projet.

Enfin, les tests demandent du jugement. Si l’IA invente à la fois une règle et le test qui la confirme, tout peut passer sans que le besoin réel soit satisfait. Il faut relier les tests aux comportements attendus, vérifier leurs assertions et essayer les parcours importants. La relecture du code complète ces vérifications.

Adapter le cadre à ce que l’on construit

Ces approches peuvent se succéder. On explore une idée, on observe ce qui est utile, puis on formalise les attentes avant de poursuivre. Le prototype doit alors être réexaminé : quelles hypothèses contient-il, quelles parties peut-on conserver et lesquelles faut-il reprendre ?

Pour un logiciel destiné à durer, à être maintenu par plusieurs personnes ou à traiter des données importantes, rendre les règles explicites devient particulièrement utile.

L’IA peut prendre en charge une part importante de l’écriture. Le développeur garde la responsabilité de définir les attentes, de comprendre les décisions essentielles et d’apporter des preuves que le résultat convient. Une spécification bien utilisée lui donne un point d’appui pour exercer cette responsabilité.