L’arrivée des assistants IA dans le développement logiciel a changé une chose très concrète : écrire du code est devenu plus rapide. Mais cette accélération a un effet secondaire. Quand le code devient facile à générer, le vrai goulot d’étranglement se déplace. Le problème n’est plus seulement de produire du code. Le problème est de produire le bon code. C’est là que le Spec Driven Development — ou développement piloté par la spécification — redevient central. L’idée n’est pas nouvelle. Les bonnes équipes ont toujours su qu’un besoin mal formulé produit une mauvaise solution. Mais avec l’IA, cette vérité devient encore plus visible. Un assistant IA peut générer beaucoup de code très vite. Si la demande est floue, il générera très vite quelque chose de flou.  

L’IA ne devine pas le besoin métier

Un développeur humain, face à une demande ambiguë, peut poser des questions, détecter une incohérence, se souvenir d’un historique projet, interpréter une contrainte implicite. Un LLM, lui, complète. Il prend ce qu’on lui donne et produit la suite la plus plausible. C’est très puissant pour accélérer une tâche bien cadrée. C’est dangereux quand le cadrage est insuffisant. Demandez-lui : “Crée un système de gestion des demandes de congés.” Il va probablement produire :

• un modèle LeaveRequest ;
• quelques statuts ;
• une API CRUD ;
• une logique d’approbation ;
• peut-être une interface simple.

Mais il ne saura pas forcément :

• si les règles diffèrent selon les pays ;
• si un manager peut valider rétroactivement ;
• si certaines demandes doivent être bloquées selon la période ;
• si les données doivent être exportables vers un outil paie ;
• si une règle conventionnelle spécifique s’applique.

Le code peut être propre. L’architecture peut sembler correcte. Et pourtant, le produit peut être faux.  

La spécification devient une interface avec l’IA

Avant, une spécification servait principalement à aligner des humains : métier, produit, tech, QA. Aujourd’hui, elle sert aussi à guider les systèmes IA. Plus la spécification est claire, plus l’IA devient utile. Moins elle l’est, plus l’IA produit du bruit. Une bonne spec pour travailler avec l’IA doit contenir plusieurs éléments :

• Le contexte métier. Pourquoi cette fonctionnalité existe ? Quel problème résout-elle ? Qui l’utilise ?
• Les règles fonctionnelles. Quels comportements sont attendus ? Quels cas doivent être refusés ? Quelles exceptions existent ?
• Les contraintes techniques. Stack utilisée, patterns existants, conventions du projet, contraintes de performance, sécurité, compatibilité.
• Les critères d’acceptation. Comment sait-on que la fonctionnalité est terminée ? Quels scénarios doivent passer ?
• Les cas limites. Que se passe-t-il si les données sont incomplètes ? Si l’utilisateur n’a pas les droits ? Si un service externe ne répond pas ?

Sans ces éléments, l’IA comble les trous. Et c’est précisément ce qu’il faut éviter.  

Le problème du “vibe coding”

Le “vibe coding” — coder en décrivant vaguement ce qu’on veut et en laissant l’IA produire — peut fonctionner sur des petits projets, des prototypes ou des scripts isolés. Le problème apparaît quand on l’applique à une codebase réelle. Dans un projet d’entreprise, chaque modification s’inscrit dans un système existant :

• architecture déjà en place ;
• dette technique ;
• conventions d’équipe ;
• règles métier accumulées ;
• tests existants ;
• contraintes de sécurité ;
• dépendances externes.

Un prompt vague du type “ajoute la gestion des rôles utilisateur” peut produire une implémentation correcte en apparence, mais incompatible avec le modèle d’autorisation existant. Le risque n’est pas que l’IA échoue totalement. Le risque est qu’elle réussisse partiellement, de manière suffisamment convaincante pour que l’erreur passe en revue trop vite.  

Le bon pattern : spec → plan → code → vérification

Une utilisation saine de l’IA dans le développement suit rarement le chemin direct “prompt → code”. Elle suit plutôt une séquence en quatre étapes.  

1. Spec

On commence par formuler précisément le besoin. Pas nécessairement dans un document de 30 pages. Mais suffisamment pour rendre les règles explicites. Exemple :  

2. Plan

Avant de générer le code, on demande à l’IA de proposer un plan d’implémentation. C’est une étape clé. Elle permet de vérifier si l’IA a compris le système, les fichiers à modifier, les dépendances, les risques. Un bon prompt n’est pas : “Code cette fonctionnalité.” C’est plutôt : “Analyse la codebase et propose un plan d’implémentation. Ne modifie aucun fichier pour l’instant. Liste les fichiers concernés, les risques et les tests à ajouter.”  

3. Code

Une fois le plan validé, l’IA peut générer le code par petites étapes. Pas toute la fonctionnalité d’un coup. Pas dix fichiers modifiés sans contrôle. Une étape, une intention, une revue. Le développeur reste responsable de la décision. L’IA exécute, propose, accélère. Elle ne remplace pas l’arbitrage technique.  

4. Vérification

La dernière étape est non négociable : tests, revue, exécution locale, analyse des effets de bord. L’IA peut aider à écrire les tests, mais elle ne doit pas être la seule juge de sa propre production. Le développeur doit vérifier que les tests couvrent réellement les règles métier, pas seulement les chemins heureux.  

Ce que ça change dans le rôle du développeur

L’IA ne rend pas les développeurs moins utiles. Elle rend certaines compétences encore plus importantes. Savoir formuler un besoin. Un développeur capable de transformer une demande floue en spec claire devient beaucoup plus efficace avec l’IA. Savoir découper. Les assistants IA fonctionnent mieux sur des tâches bornées. Le découpage technique devient une compétence majeure. Savoir relire. Plus le code est facile à produire, plus la capacité à évaluer ce code devient critique. Savoir dire non. Toutes les suggestions de l’IA ne doivent pas être acceptées. Certaines sont inutiles, surdimensionnées ou incompatibles avec le contexte projet. Le bon développeur augmenté n’est pas celui qui laisse l’IA coder à sa place. C’est celui qui sait transformer l’IA en exécutant fiable sur un périmètre maîtrisé.  

Ce que ça change pour les équipes

Le Spec Driven Development n’est pas seulement une pratique individuelle. C’est une pratique d’équipe. Si chacun utilise l’IA avec ses propres prompts, ses propres standards et son propre niveau de contrôle, la codebase devient rapidement incohérente. Les équipes doivent donc formaliser :

• des templates de specs ;
• des règles d’utilisation des assistants IA ;
• des conventions de prompt pour les tâches fréquentes ;
• des critères de revue spécifiques au code généré ;
• une politique claire sur les données projet qu’on peut ou non envoyer à un outil externe.

C’est particulièrement important dans les environnements clients, où les contraintes de confidentialité, de sécurité et de conformité peuvent varier fortement.  

Notre conviction chez Olympp

Chez Olympp, nous ne voyons pas l’IA comme un raccourci pour moins réfléchir. Nous la voyons comme un levier pour mieux exécuter — à condition d’avoir mieux cadré. Les consultants qui tirent le plus de valeur des outils IA sont souvent ceux qui structurent le mieux leur pensée avant de demander du code. Ils savent expliciter les contraintes, challenger le plan proposé, découper les tâches et relire avec exigence. C’est exactement ce que nous cherchons à développer : une culture d’ingénierie augmentée, pas une culture de génération automatique.  

En synthèse

L’IA accélère le développement. Mais elle ne remplace pas la spécification. Au contraire : plus l’IA devient puissante, plus la qualité de la spec devient déterminante. Un besoin flou produit du code flou. Un besoin clair produit un assistant utile. Et une équipe qui sait spécifier, planifier et vérifier peut transformer l’IA en avantage réel.   Olympp accompagne ses consultants et ses clients dans l’intégration concrète de l’IA dans les pratiques de développement. Notre approche : outiller les équipes, renforcer les méthodes, et garder l’exigence d’ingénierie au centre.