La fin du « Vibe Coding » ! Longue vie au SDD !

Il y a quelques mois, la communauté des développeurs a été captivée par un nouveau phénomène : le « vibe coding ». Le principe était d'une simplicité enivrante : pas besoin de plan, de diagramme de flux ou même d'une compréhension approfondie de la syntaxe ; il suffisait de décrire un sentiment à un agent d'IA et de regarder le code se matérialiser. C'était magique, jusqu'à l'apparition du premier bug majeur. Soudain, cette expérience fluide s'est transformée en une boucle frénétique de « répare ceci » et « maintenant cela ne marche plus », laissant le développeur piégé dans une conversation avec une machine qui avait perdu le fil.

Historiquement, nous passions des mois à peaufiner des documents d'exigences exhaustifs avant qu'une seule ligne de code ne soit écrite — un processus rigide qui étouffait souvent l'innovation ; aujourd'hui, nous livrons souvent du code avant même d'avoir décidé de ce que le produit est censé faire — une habitude chaotique qui crée une dette technique massive. Cette tension a donné naissance à un nouveau paradigme : le développement piloté par les spécifications (Spec-Driven Development ou SDD). C'est le juste milieu pragmatique, conçu pour donner aux agents d'IA les rails dont ils ont besoin sans revenir aux méthodes « waterfall » lourdes des années 1990.

Le contrat d'intention

À la base, le développement piloté par les spécifications consiste à créer une « source de vérité » que les humains et les machines peuvent lire. Den Delimarsky de Microsoft décrit une spécification comme un « contrôle de version pour votre pensée », et en pratique, elle fonctionne comme un contrat contraignant. Au lieu de lancer des instructions vagues à un écran en espérant le meilleur, le développeur écrit un document concis et structuré qui définit exactement comment le code doit se comporter.

Techniquement parlant, ce changement résout le problème de la « dérive contextuelle ». Les agents d'IA sont brillants pour l'exécution mais ont tendance à oublier le « pourquoi » d'une fonctionnalité après cinquante séries de révisions. En ancrant le processus de développement dans une spécification, nous nous assurons que l'IA reste un assistant plutôt qu'un électron libre. Birgitta Böckeler de Thoughtworks identifie trois niveaux de cette évolution : le « spec-first », où le plan précède le code ; le « spec-anchored », où le document perdure pour guider la maintenance ; et le visionnaire « spec-as-source », où l'humain ne touche qu'à la spécification, le code sous-jacent restant entièrement automatisé.

Kiro : Le CLI de l'architecte

Développé par une équipe aux avis tranchés au sein d'AWS, Kiro est un outil robuste qui traite la construction de logiciels comme une discipline d'ingénierie plutôt que comme un jeu de devinettes. Il propose à la fois un IDE et un CLI, mais sa véritable puissance réside dans ses exigences en markdown structuré. Kiro utilise EARS (Easy Approach to Requirements Syntax), une notation qui impose la clarté via un modèle simple : QUAND [condition], LE SYSTÈME DOIT [comportement].

À travers ce prisme utilisateur, l'écriture d'une exigence EARS ressemble moins à du « codage » qu'à une cartographie logique. Cette structure permet à Kiro de générer des tests basés sur les propriétés qui sont bien plus complets que les tests unitaires standards, capturant des cas limites qu'un codeur humain — ou une IA pilotée par le « feeling » — négligerait probablement. De plus, Kiro introduit le concept de fichiers de « pilotage ». Ces documents — product.md, tech.md et structure.md — agissent comme l'infrastructure invisible du projet, garantissant que chaque morceau de code généré respecte la pile technique et les conventions architecturales choisies.

Spec Kit : Standardiser le flux de travail des agents

Le Spec Kit de Microsoft adopte une approche différente, fonctionnant comme un pont open-source entre trente agents de codage différents et un processus structuré en quatre phases. Si le « vibe coding » ressemble à un remue-méninges non structuré, le Spec Kit ressemble à un atelier professionnel. Il introduit une suite de commandes — telles que /speckit.plan et /speckit.analyze — qui forcent l'agent à s'arrêter et à réfléchir avant de commencer à taper.

Paradoxalement, en ajoutant ces « points de friction », le Spec Kit accélère réellement le développement. Il empêche les « boucles d'hallucination » où un agent tente de corriger un bug en introduisant un nouveau bug plus complexe. Que vous construisiez un projet à partir de zéro ou que vous essayiez de démêler une base de code héritée fragmentée, le Spec Kit fournit une constitution pour le projet. Il déplace le développeur humain du rôle de dactylo vers celui de réviseur, se concentrant sur la logique de haut niveau tandis que l'agent gère les détails d'implémentation fastidieux.

Tessl et le registre des compétences

Tessl introduit une couche fascinante à l'écosystème SDD : le registre de paquets. Si nous considérons le code comme une recette, Tessl fournit les ingrédients et les techniques de cuisson standardisés via ses « tuiles » (tiles). Ces tuiles contiennent des flux de travail procéduraux (compétences), des normes de codage obligatoires (règles) et une documentation que les agents peuvent consulter à la demande.

En termes quotidiens, utiliser Tessl, c'est comme donner à votre agent d'IA une carte de bibliothèque et un ensemble de règles de vie. En installant la tuile SDD de Tessl et en demandant simplement à l'agent d'« utiliser le développement piloté par les spécifications », le flux de travail change. L'agent cesse d'agir comme une saisie semi-automatique servile et commence à agir comme un ingénieur junior qui pose des questions de clarification et rédige un plan avant de toucher au dépôt. Cette transparence est vitale ; elle transforme la « boîte noire » opaque de la génération par IA en un processus visible et auditable.

Zenflow : Orchestration avec vérification

Si les autres outils se concentrent sur le « quoi » et le « comment », Zenflow se concentre sur le « qui » et le « où ». Développé par l'équipe Zencoder, Zenflow agit comme une couche d'orchestration, coordonnant plusieurs agents d'IA pour travailler en parallèle sans corrompre la base de code. Il traite chaque fonctionnalité comme un flux de travail, utilisant des arbres de travail Git isolés pour s'assurer que les modifications sont testées et révisées avant d'atteindre la branche principale.

En prenant du recul au niveau de l'industrie, Zenflow représente un mouvement vers les systèmes « multi-agents ». Dans ce modèle, un agent peut écrire la spécification, un autre implémente le code, et un troisième effectue une revue de code croisée. Ce système de freins et contrepoids imite une équipe d'ingénierie humaine performante. Pour l'utilisateur, le résultat est un cycle de développement résilient où les tests échoués déclenchent des corrections automatiques, et le code n'est « livré » qu'une fois qu'il a passé toutes les étapes de vérification.

Le changement silencieux de la culture numérique

La transition du « vibe coding » vers le développement piloté par les spécifications révèle un changement profond dans notre relation avec le logiciel. Nous réalisons que la « magie » de l'IA est plus efficace lorsqu'elle est guidée par l'intentionnalité humaine. Tout comme un placard en désordre est facile à remplir mais impossible à explorer, une base de code non structurée est facile à générer mais impossible à maintenir.

En fin de compte, l'essor d'outils comme Kiro, Spec Kit, Tessl et Zenflow suggère que l'avenir de la programmation ne réside pas dans la disparition de la rigueur technique, mais dans son évolution. Nous nous éloignons de l'ère du « hacker solitaire » pour nous diriger vers celle de l'« architecte technique ». Dans ce nouveau monde, notre valeur en tant qu'humains ne réside pas dans notre capacité à mémoriser la syntaxe, mais dans notre capacité à définir des spécifications claires, éthiques et efficaces pour les machines qui construisent notre monde.

Alors que nous naviguons dans ces changements, nous devrions observer nos outils numériques avec un œil plus hyper-observateur. La prochaine fois qu'une mise à jour d'application semble lourde ou mal conçue, demandez-vous : a-t-elle été construite avec une spécification, ou était-ce juste une « vibe » ? Reprendre le contrôle de nos logiciels commence par exiger la clarté que seule une spécification bien écrite peut fournir.

Sources

• AWS Documentation: Kiro Agent and EARS Notation Standards (2025-2026).
• Microsoft Open Source: Spec Kit Repository and 'Version Control for Thinking' by Den Delimarsky.
• Thoughtworks Technology Radar: 'The Three Levels of Spec-Driven Development' by Birgitta Böckeler.
• Tessl Official Registry: Tile and Skill Documentation for AI Agents.
• Zencoder Engineering Blog: Zenflow Orchestration and Verification Gate Mechanics.