Spec-Driven Development:From Code to Contract in the Age of AI Coding Assistants
Cet article présente un guide complet du développement piloté par les spécifications (Spec-Driven Development ou SDD), décrivant ses principes, ses trois niveaux de rigueur de spécification et les outils de support pour démontrer comment le fait de traiter les spécifications comme l'artefact primaire peut exploiter efficacement les assistants de codage IA à travers divers domaines logiciels.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez que vous embauchiez un robot chef très talentueux, incroyablement rapide, mais légèrement littéral.
L'ancienne méthode (orientée Code) :
Vous vous approchez du robot et lui dites : « Prépare-moi un dîner délicieux. »
Le robot, désireux de vous faire plaisir, commence immédiatement à couper des légumes et à chauffer des poêles. Il devine que vous voulez des pâtes. Il devine que vous les voulez épicées. Il devine que vous voulez utiliser cette huile de truffe coûteuse que vous n'avez pas mentionnée.
Dix minutes plus tard, vous avez une assiette de pâtes à la truffe et épicées. Vous vouliez une salade.
Maintenant, vous devez dire au robot de s'arrêter, de jeter les pâtes et de recommencer. C'est ce que l'article appelle le « vibe coding » (codage par l'ambiance) : s'appuyer sur des instructions vagues où l'IA doit deviner votre intention. Le résultat est souvent un désastre qui nécessite des corrections constantes.
La nouvelle méthode (Développement piloté par la Spécification) :
Au lieu de crier des ordres, vous écrivez d'abord une fiche recette (la Spécification).
Vous écrivez exactement : « Je veux une salade. Utilisez des épinards, des tomates et de la feta. Pas de noix. La sauce à part. Servir à température ambiante. »
Vous remettez cette fiche au robot. Le robot la lit, vérifie sa compréhension, et ensuite commence à cuisiner.
Si le robot essaie d'ajouter des noix, il s'arrête parce que la fiche dit « Pas de noix ». S'il essaie de la servir chaude, il s'arrête.
Dans ce scénario, la fiche recette est le patron. La nourriture (le code) n'est que le résultat du suivi de la recette. Si la nourriture n n'est pas bonne, vous ne blâmez pas le chef ; vous vérifiez si la recette était claire.
Les trois niveaux de rigueur
L'article explique que vous n'avez pas toujours besoin d'un contrat de 50 pages. Il existe trois façons d'utiliser cette approche de la « fiche recette », selon votre degré de sérieux :
Spécification d'abord (Le « Croquis ») :
- Ce que c'est : Vous écrivez la recette avant de commencer à cuisiner pour vous assurer que tout le monde est d'accord sur ce que vous préparez.
- Quand l'utiliser : Idéal pour tester une nouvelle idée ou un projet ponctuel.
- Le bémol : Une fois le repas cuisiné, vous pourriez jeter la fiche recette. Si vous modifiez la recette plus tard, la fiche pourrait ne pas être mise à jour. C'est bien pour démarrer, mais pas pour la maintenance à long terme.
Spécification ancrée (Le « Menu vivant ») :
- Ce que c'est : La fiche recette est conservée sur le frigo, juste à côté de la cuisinière. Chaque fois que vous modifiez le plat (ajoutez plus de fromage, changez l'assaisonnement), vous devez mettre à jour la fiche immédiatement.
- Quand l'utiliser : C'est le point d'équilibre pour la plupart des cuisines professionnelles (logiciels en production).
- La magie : La cuisine dispose d'un inspecteur robotique. Si le chef modifie le plat mais oublie de mettre à jour la fiche, l'inspecteur déclenche une alarme. Cela garantit que le menu (la documentation) correspond toujours à la nourriture (le logiciel).
La Spécification comme Source (L'« Imprimante 3D ») :
- Ce que c'est : C'est la version la plus extrême. Vous ne touchez jamais directement à la nourriture. Vous ne modifiez que la fiche recette. Une machine imprime ensuite automatiquement la nourriture en se basant uniquement sur cette fiche.
- Quand l'utiliser : C'est utilisé dans des domaines à enjeux élevés comme la construction de moteurs de voitures ou de dispositifs médicaux, où une erreur pourrait être dangereuse.
- La règle : Si vous voulez changer les freins d'une voiture, vous ne mettez pas les mains sous le capot avec une clé. Vous modifiez le plan, et la machine reconstruit les freins parfaitement. Il ne vous est jamais permis de modifier manuellement les pièces générées.
Pourquoi l'IA rend cela nécessaire
L'article soutient que les assistants de codage par IA sont comme ce robot chef talentueux mais littéral. Ils sont excellents pour suivre des instructions, mais médiocres pour « lire dans les pensées ».
- Sans spécification : Vous demandez à l'IA d'« ajouter une fonctionnalité de connexion ». L'IA devine les règles de mot de passe, le type de base de données et le niveau de sécurité. Elle se trompe souvent.
- Avec une spécification : Vous donnez à l'IA un contrat clair : « La connexion nécessite un mot de passe de 12 caractères, utilise l'e-mail, et verrouille le compte après 3 tentatives infructueuses. » L'IA suit les règles à la perfection.
Le flux de travail : Une danse en quatre étapes
L'article suggère un rythme simple pour ce processus :
- Spécifier : Écrire le « Quoi ». (La Recette).
- Planifier : Écer le « Comment ». (La liste de courses et l'agencement de la cuisine).
- Implémenter : Construire. (La cuisine).
- Valider : Vérifier. (La dégustation). Si le goût ne correspond pas à la recette, vous corrigez la cuisine ou vous mettez à jour la recette, mais vous ne négligez jamais l'écart.
Quand l'utiliser (Et quand ne pas l'utiliser)
L'article fournit un guide de décision simple :
- Utilisez-le quand : Vous construisez quelque chose de grand, vous travaillez en équipe, vous utilisez l'IA, ou vous construisez quelquement où les erreurs coûtent cher (comme la banque ou l'automobile).
- Ne l'utilisez pas quand : Vous réalisez un prototype rapide destiné à être jeté, ou si vous êtes un développeur solo créant une simple application de liste de tâches où les exigences sont évidentes. Dans ces cas, écrire une recette détaillée est une perte de temps.
L'idée principale
Pendant des décennies, les développagers de logiciels écrivaient le code d'abord et écrivaient la « recette » (la documentation) plus tard, s'ils l'écrivaient seulement. Cet article dit : Inversez la tendance.
Faites de la Spécification la chose principale que vous créez. Traitez le Code comme étant simplement le résultat automatique de cette spécification.
En faisant cela, vous arrêtez de deviner, vous arrêtez de vous battre avec vos outils d'IA, et vous vous assurez de construire exactement ce que vous aviez l'intention de construire. Le code devient l'ombre de la spécification, et non l'inverse.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.