Coder avec l'IA : pourquoi le “spec-driven” dépasse le vibe coding

Un projet livré en trois semaines. Une démo qui tourne. Un client satisfait... jusqu'au jour où il faut ajouter une fonctionnalité. À ce moment-là, personne ne sait par quel bout prendre le code. L'agence qui a livré ne peut pas garantir que la modification ne va rien casser. L'équipe interne qui reprend le projet ne comprend pas l'architecture. Et le budget de maintenance commence à gonfler.

Ce scénario se produit de plus en plus souvent depuis que les outils d'IA générative ont rendu le code facile à produire en grande quantité, très vite.

Le vibe coding, c'est quoi concrètement ?

Le vibe coding désigne une façon de travailler où l'on demande à l'IA de générer du code sans passer par les étapes qui précèdent normalement l'écriture : pas de spécifications, pas de cadrage technique, pas de revue, peu ou pas de tests. On prompt, on itère, on livre.

Le résultat peut être impressionnant en démo. Le problème, c'est ce qu'il y a sous le capot.

Du code produit sans architecture définie tend à s'organiser selon la logique du moment, pas selon une cohérence pensée à l'avance. Chaque feature ajoutée à la hâte renforce les dépendances involontaires. Les nommages deviennent incohérents. Les failles de sécurité passent inaperçues parce que personne n'a défini ce qui devait être protégé et comment.

La vitesse qui coûte cher

Le vrai piège du vibe coding, c'est qu'il mesure la vitesse au mauvais endroit.

Produire du code vite est réel. Mais le coût d'un projet ne s'arrête pas à la livraison initiale. En pratique, la maintenance, les corrections de bugs, les évolutions et les passages de relais entre équipes représentent souvent une part plus importante du coût total qu'on ne l'anticipe au départ.

Un projet livré en trois semaines avec un workflow non structuré peut devenir plus coûteux sur 12 mois qu'un projet livré en cinq semaines avec une base propre. La différence ne se voit pas sur le devis initial. Elle se voit sur la deuxième, troisième et quatrième intervention.

Et quand il faut changer d'équipe, faire un audit de sécurité ou intégrer un nouveau développeur, la qualité du code de départ a un impact direct sur le temps et le budget que ça prend.

Ce qu’une approche "spec-driven" change dans le processus

Une approche “spec-driven” ne ralentit pas le développement. Elle déplace le travail de réflexion avant l'écriture du code plutôt que de le laisser se faire implicitement au fil du développement.

Le mot “spec” renvoie ici aux spécifications : la description claire de ce que l’on veut construire avant de passer à l’exécution. Autrement dit, une approche “spec-driven” commence par une phase d’analyse préalable solide, où l’on transforme une intention en plan fonctionnel et technique.

L'idée de base est simple : avant que l'IA n'écrive la première ligne, on sait précisément ce qui doit être construit, pourquoi, et comment ça doit s'intégrer dans l'ensemble. Les fonctionnalités attendues, les contraintes métier, les choix d'architecture, le comportement de l’interface, tout ça est défini, documenté et validé par des humains avant que la génération de code ne commence.

L'IA travaille ensuite dans ce cadre, avec des règles explicites sur le style, la structure et les patterns à respecter. Ce qu'elle produit est relu et mesuré, pas simplement intégré parce que ça compile.

Ce n'est pas une façon de brider l'IA. C'est une façon de s'assurer qu'elle produit quelque chose d'utile sur la durée, pas seulement quelque chose qui tourne le jour de la démo.

Ce que le client peut vérifier

Un client qui mandate une agence n'a pas forcément accès au détail du code produit. Mais il peut poser quelques questions simples pour évaluer sérieusement le niveau de rigueur de l'équipe en face de lui.

• Est-ce qu'il y a un document de spécifications avant que le développement ne commence ?
• Est-ce que les choix techniques sont documentés, ou transmis uniquement à l'oral ?
• Est-ce qu'une revue de code a lieu avant chaque mise en production ?
• Suis-je dépendant d’un prestataire, d’une plateforme ou d’un outil propriétaire pour faire évoluer le projet ?
• Est-ce que le projet passe par un outil d'analyse qualité ?
• Qui peut relire le code produit si un problème survient dans six mois ?

Les réponses à ces questions distinguent une équipe qui utilise l'IA comme outil de vitesse d'une équipe qui l'intègre dans un processus de livraison mûr.

Le vrai argument

Ce n'est pas que l'IA est bonne ou mauvaise pour coder. C'est que la qualité d'un livrable ne dépend pas de l'outil utilisé pour l'écrire. Elle dépend du processus dans lequel cet outil s'inscrit.

Un modèle d'IA dans un workflow rigoureux peut produire du code propre, lisible et maintenable. La différence, c'est ce qui entoure l'écriture, pas l'écriture elle-même.

Ce qui implique aussi l'inverse : l'IA n'est pas toujours la bonne réponse. Il y a des projets où le contexte, les contraintes ou les exigences de sécurité font que le jeu n'en vaut pas la chandelle. Savoir le reconnaître fait partie du même niveau de rigueur.

Alors, vibe coding ou “spec-driven” ?

Chez Nubios, nous ne pensons pas que l’IA doive toujours être encadrée de la même manière. Pour un besoin interne simple, à faible impact, le vibe coding peut être un bon moyen d’aller vite, de tester une idée ou d’automatiser une tâche ponctuelle.

Mais lorsqu’un projet doit être maintenu, audité, transmis à une autre équipe ou utilisé dans un contexte métier important, la vitesse seule ne suffit plus. C’est là que nous privilégions une approche spec-driven.

Le développement IA “spec-driven” chez Nubios

Chez Nubios, nous utilisons l’IA pour accélérer le développement, pas pour remplacer le savoir-faire nécessaire à un vrai projet logiciel.

Avant tout codage, nos développeurs-analystes cadrent le projet avec le client : besoins fonctionnels, contraintes métier, choix techniques, risques, évolutivité. Cette phase produit un document fonctionnel et un document technique, qui servent de base au développement.

L’IA intervient ensuite dans un processus contrôlé. Plusieurs agents spécialisés peuvent produire, tester, documenter ou relire le code, mais ils travaillent à partir de nos librairies, de nos standards et des décisions prises par l’équipe. Le code est ensuite soumis à des tests qualité, à des revues IA et à des revues humaines.

C’est cette combinaison qui fait la différence : la vitesse de l’IA, mais avec le savoir-faire d’une équipe capable de cadrer, arbitrer, relire et livrer proprement.

Le résultat, ce n’est pas seulement une démo qui fonctionne. C’est une base maintenable, documentée, évolutive, qu’un client peut faire reprendre, auditer ou modifier sans repartir de zéro.

Vous cherchez à construire vite sans vous retrouver dépendant d’un prototype difficile à maintenir ? Prenons 30 minutes.