[{"data":1,"prerenderedAt":667},["ShallowReactive",2],{"i-ic:outline-arrow-upward":3,"Footer_afPiwGMwNiEyV4syWzw87ovzxHAgs4iwKtCn4zqBf8E":8,"\u002Farticles\u002Fvibe-coding-bmad-spec-driven-methode-developpement-ia":16,"i-material-symbols:home":653,"Brand_bAcjTzQpW6OVpFK319jfMki97vH1GrZiqHmeI7Xg4o":655,"i-material-symbols:ios-share":660,"ArticleDetails_RxZhQZT8shaVyMLsxUcIvV50e9iwRl6hj3aVt6XwBs":662},{"left":4,"top":4,"width":5,"height":5,"rotate":4,"vFlip":6,"hFlip":6,"body":7},0,24,false,"\u003Cpath fill=\"currentColor\" d=\"m4 12l1.41 1.41L11 7.83V20h2V7.83l5.58 5.59L20 12l-8-8z\"\u002F>",["Island",9],{"key":10,"result":11},"Footer_afPiwGMwNiEyV4syWzw87ovzxHAgs4iwKtCn4zqBf8E",{"head":12},{"style":13},[14],{"innerHTML":15},":where(.i-mdi\\:github){display:inline-block;width:1em;height:1em;background-color:currentColor;-webkit-mask-image:var(--svg);mask-image:var(--svg);-webkit-mask-repeat:no-repeat;mask-repeat:no-repeat;-webkit-mask-size:100% 100%;mask-size:100% 100%;--svg:url(\"data:image\u002Fsvg+xml,%3Csvg xmlns='http:\u002F\u002Fwww.w3.org\u002F2000\u002Fsvg' viewBox='0 0 24 24' width='24' height='24'%3E%3Cpath fill='black' d='M12 2A10 10 0 0 0 2 12c0 4.42 2.87 8.17 6.84 9.5c.5.08.66-.23.66-.5v-1.69c-2.77.6-3.36-1.34-3.36-1.34c-.46-1.16-1.11-1.47-1.11-1.47c-.91-.62.07-.6.07-.6c1 .07 1.53 1.03 1.53 1.03c.87 1.52 2.34 1.07 2.91.83c.09-.65.35-1.09.63-1.34c-2.22-.25-4.55-1.11-4.55-4.92c0-1.11.38-2 1.03-2.71c-.1-.25-.45-1.29.1-2.64c0 0 .84-.27 2.75 1.02c.79-.22 1.65-.33 2.5-.33s1.71.11 2.5.33c1.91-1.29 2.75-1.02 2.75-1.02c.55 1.35.2 2.39.1 2.64c.65.71 1.03 1.6 1.03 2.71c0 3.82-2.34 4.66-4.57 4.91c.36.31.69.92.69 1.85V21c0 .27.16.59.67.5C19.14 20.16 22 16.42 22 12A10 10 0 0 0 12 2'\u002F%3E%3C\u002Fsvg%3E\")}",{"id":17,"title":18,"author":19,"body":22,"description":644,"extension":645,"meta":646,"navigation":647,"path":648,"publicationDate":649,"seo":650,"stem":651,"__hash__":652},"articles\u002Farticles\u002Fvibe-coding-bmad-spec-driven-methode-developpement-ia.md","Vibe Coding, BMAD, Spec-Driven: développer avec l'IA est-il vraiment plus simple ?",{"name":20,"url":21},"@patrickfaramaz ","https:\u002F\u002Ftwitter.com\u002Fpatrickfaramaz",{"type":23,"value":24,"toc":616},"minimark",[25,29,32,35,38,63,66,71,76,79,82,85,89,92,98,102,105,108,114,120,126,132,136,139,141,145,148,152,155,158,177,180,184,190,197,200,207,210,220,224,231,234,237,245,249,255,258,261,268,272,278,290,293,300,304,310,313,316,323,327,333,340,343,350,356,359,367,371,378,381,384,387,390,394,397,412,419,422,428,434,461,464,471,485,487,491,494,497,501,504,507,510,514,517,534,537,541,544,547,550,552,556,559,562,565,568,571,573],[26,27,28],"p",{},"En 2025, Andrej Karpathy popularisait le \"vibe coding\" avec une idée séduisante: laissez l'IA écrire le code, suivez le flow, ne lisez même pas ce qui est généré. La promesse? N'importe qui pouvait créer un logiciel.",[26,30,31],{},"En 2026, pour \"bien\" développer avec l'IA, il faut maîtriser BMAD et ses 21 agents spécialisés. Ou comprendre les specs EARS de Kiro. Ou orchestrer des subagents avec GSD. Ou versionner des PRD dans OpenSpec. Plus simple, vraiment?",[26,33,34],{},"Quelque chose s'est passé entre ces deux moments. Les limites des LLMs, hallucinations, perte de contexte, incohérences à grande échelle, ont provoqué une réponse industrielle massive: des frameworks de plus en plus sophistiqués pour compenser ce que l'IA ne sait pas encore faire seule. La complexité n'a pas disparu. Elle s'est déplacée.",[26,36,37],{},"Cet article analyse honnêtement ce paradoxe. On compare les principales méthodes de développement avec l'IA disponibles en 2026, on regarde ce qu'elles apportent vraiment, et on tire une conclusion qui va à contre-courant du discours ambiant: les développeurs n'ont jamais été aussi indispensables.",[39,40,41,47],"blockquote",{},[26,42,43],{},[44,45,46],"strong",{},"Points clés",[48,49,50,54,57,60],"ul",{},[51,52,53],"li",{},"Le vibe coding fonctionne pour les prototypes rapides, pas pour les projets en production: la dette technique et le code spaghetti s'accumulent en 3 mois.",[51,55,56],{},"Les frameworks SDD (BMAD, Spec Kit, GSD, Kiro...) compensent les limites des LLMs en déplaçant la complexité vers la documentation et les specs.",[51,58,59],{},"Matt Pocock (Ralph Loop) défend l'inverse du vibe coding: les fondamentaux d'ingénierie (TDD, design, revue) comptent plus que jamais avec l'IA.",[51,61,62],{},"Les développeurs ne sont pas remplacés: ils sont repositionnés comme architectes, relecteurs de code IA, et concepteurs de specs.",[64,65],"hr",{},[67,68,70],"h2",{"id":69},"le-vibe-coding-la-promesse-et-ce-quelle-cache","Le Vibe Coding: la promesse et ce qu'elle cache",[72,73,75],"h3",{"id":74},"quest-ce-que-le-vibe-coding-exactement","Qu'est-ce que le vibe coding, exactement?",[26,77,78],{},"Le terme \"vibe coding\" a été popularisé par Andrej Karpathy, membre fondateur de l'équipe technique d'OpenAI et ancien directeur de l'IA chez Tesla, début 2025. Sa définition était claire: on interagit avec l'IA en langage naturel, on accepte les suggestions sans trop analyser, on \"vibre\" avec le flow plutôt que de lire chaque ligne.",[26,80,81],{},"L'idée résonnait avec une réalité: les LLMs avaient fait des progrès spectaculaires en génération de code. Pour un développeur solo avec un projet précis et borné, laisser Claude ou GPT écrire les fonctions de base permettait effectivement d'aller beaucoup plus vite.",[26,83,84],{},"Mais Karpathy lui-même avait posé une limite importante, souvent oubliée dans les articles enthousiastes: le vibe coding était conçu pour les \"throwaway weekend projects\". Pas pour la production.",[72,86,88],{"id":87},"ce-pour-quoi-le-vibe-coding-fonctionne-vraiment","Ce pour quoi le vibe coding fonctionne vraiment",[26,90,91],{},"Il faut être honnête: le vibe coding est redoutablement efficace dans certains contextes.",[26,93,94,97],{},[44,95,96],{},"Pour un MVP en 48h",", un prototype pour un client, une landing page, un script interne ou un outil personnel, la méthode fait gagner un temps considérable. Pas besoin de documentation, pas de réunion de conception, on itère en temps réel avec l'IA.",[72,99,101],{"id":100},"les-limites-concrètes-des-llms-qui-ont-tout-changé","Les limites concrètes des LLMs qui ont tout changé",[26,103,104],{},"Le problème n'est pas l'IA. C'est ce qu'un LLM est, fondamentalement: un modèle qui prédit le texte le plus probable, pas celui qui est correct.",[26,106,107],{},"Quatre limites se manifestent de façon répétée sur les projets réels:",[26,109,110,113],{},[44,111,112],{},"Les hallucinations."," Le modèle invente des fonctions, des APIs, des dépendances qui n'existent pas. Il génère du code qui compile mais fait faux. Sur un projet de 500 lignes, c'est détectable. Sur 50 000 lignes, c'est catastrophique.",[26,115,116,119],{},[44,117,118],{},"La perte de contexte."," Les LLMs ont une fenêtre de contexte limitée. Quand le projet grandit, le modèle perd le fil. Il réécrit des fonctions existantes, crée des incohérences entre modules, contredit ses propres choix d'architecture d'une session à l'autre.",[26,121,122,125],{},[44,123,124],{},"L'incohérence temporelle."," L'IA n'a pas de mémoire entre les sessions. Chaque conversation repart de zéro. Sans mécanisme pour maintenir un contexte partagé et persistant, le code produit diverge inexorablement.",[26,127,128,131],{},[44,129,130],{},"Le code spaghetti structurel."," C'est peut-être la limite la plus insidieuse. Un LLM optimise pour satisfaire la demande immédiate, pas pour produire un code maintenable sur la durée. Il génère des solutions localement correctes mais globalement incohérentes: des fonctions dupliquées avec des noms légèrement différents, des logiques métier éparpillées sans architecture claire, des couplages implicites entre modules qui rendent chaque modification risquée. Le code \"marche\" mais personne ne peut le lire, le tester, ni le faire évoluer sans tout casser. La maintenance devient exponentiellement coûteuse, et paradoxalement, même l'IA finit par ne plus comprendre ce qu'elle a elle-même produit quelques sessions plus tôt.",[72,133,135],{"id":134},"la-3-month-wall-quand-le-projet-vibe-codé-seffondre","La \"3-month wall\": quand le projet vibe-codé s'effondre",[26,137,138],{},"Red Hat Developer a publié en février 2026 \"The uncomfortable truth about vibe coding\": un constat documenté sur des dizaines de projets. La dette technique générée par le vibe coding ne se voit pas dans les premières semaines. Elle explose aux alentours du troisième mois, précisément quand le code spaghetti accumulé session après session rend chaque nouvelle fonctionnalité plus coûteuse que la précédente.",[64,140],{},[67,142,144],{"id":143},"la-réponse-de-lindustrie-une-prolifération-de-frameworks","La réponse de l'industrie: une prolifération de frameworks",[26,146,147],{},"Face à ces limites, l'industrie n'a pas attendu. En l'espace de quelques mois, des dizaines de frameworks ont émergé avec la même ambition: donner à l'IA les rails dont elle a besoin pour rester cohérente. Voici les principaux.",[72,149,151],{"id":150},"le-spec-driven-development-le-principe-fondateur","Le Spec-Driven Development: le principe fondateur",[26,153,154],{},"Avant de parler des frameworks, il faut comprendre le principe qui les sous-tend tous: le Spec-Driven Development (SDD).",[26,156,157],{},"L'idée est simple mais radicale. Au lieu de laisser le code être la source de vérité, on donne ce rôle à la spécification. Le code devient un artefact dérivé de la spec, pas l'inverse.",[26,159,160,161,164,165,168,169,172,173,176],{},"Concrètement, le workflow SDD suit trois phases: ",[44,162,163],{},"Requirements"," (définir précisément ce qu'on veut construire), ",[44,166,167],{},"Design"," (l'architecture et les choix techniques), puis seulement ",[44,170,171],{},"Tasks"," et ",[44,174,175],{},"Code",". L'IA intervient à chaque étape, mais toujours contrainte par les artefacts des étapes précédentes.",[26,178,179],{},"Le Thoughtworks Tech Radar a classé le spec-driven development en catégorie \"Adopt\" en 2026. C'est la recommandation la plus forte du radar. Autrement dit: ce n'est plus une tendance, c'est une pratique mainstream.",[72,181,183],{"id":182},"bmad-method-le-framework-le-plus-ambitieux","BMAD Method: le framework le plus ambitieux",[26,185,186,189],{},[44,187,188],{},"BMAD"," (Breakthrough Method for Agile AI-Driven Development) est le framework SDD le plus complet disponible. Il est open source, gratuit, et s'intègre directement dans Claude Code, Cursor et Windsurf.",[26,191,192,193,196],{},"Sa spécificité: il orchestre une équipe virtuelle de ",[44,194,195],{},"21 agents spécialisés",". Chaque agent a un rôle défini (Product Manager, Architect, Developer, Scrum Master, UX Designer...) et des responsabilités précises. Ils communiquent via des artefacts standardisés: PRDs, user stories, documents d'architecture.",[26,198,199],{},"Le concept central de BMAD est \"Agent as Code\": chaque agent est défini dans un fichier Markdown versionnable. Comme l'Infrastructure as Code, mais pour les comportements IA. Cela signifie que la configuration de votre équipe d'agents peut être commitée, reviewée et partagée comme du code ordinaire.",[26,201,202,203,206],{},"BMAD propose plus de ",[44,204,205],{},"50 workflows guidés"," qui s'adaptent à la complexité du projet. Son cycle principal: Analysis (capter le problème en une page) → Planning (user stories avec critères d'acceptation) → Solutioning (architecture + plan d'implémentation) → Implementation (itérations courtes, story par story).",[26,208,209],{},"La documentation officielle résume bien le changement de paradigme: \"Source code is no longer the sole source of truth, documentation is. Code becomes merely a downstream derivative of specifications.\"",[26,211,212,213],{},"Projet GitHub: ",[214,215,219],"a",{"href":216,"rel":217},"https:\u002F\u002Fgithub.com\u002Fbmad-code-org\u002FBMAD-METHOD",[218],"nofollow","github.com\u002Fbmad-code-org\u002FBMAD-METHOD",[72,221,223],{"id":222},"github-spec-kit-le-plus-adopté-le-plus-accessible","GitHub Spec Kit: le plus adopté, le plus accessible",[26,225,226,227,230],{},"Créé et maintenu par GitHub, le ",[44,228,229],{},"Spec Kit"," a dépassé les 75 000 étoiles sur GitHub, c'est le framework SDD le plus adopté par la communauté. Son avantage principal: il est compatible avec GitHub Copilot, Claude Code et Gemini CLI, ce qui le rend accessible aux équipes qui utilisent déjà ces outils.",[26,232,233],{},"Son workflow est plus simple que BMAD. On part d'une idée, on génère une spec structurée, on la décompose en tâches, et l'IA implémente tâche par tâche. Moins d'agents, moins de cérémonie, mais la même philosophie: la spec prime sur le code.",[26,235,236],{},"Pour les équipes qui cherchent à adopter le SDD sans une courbe d'apprentissage trop raide, le Spec Kit est souvent le bon point d'entrée.",[26,238,239,240],{},"Documentation: ",[214,241,244],{"href":242,"rel":243},"https:\u002F\u002Fgithub.blog\u002Fai-and-ml\u002Fgenerative-ai\u002Fspec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit\u002F",[218],"github.blog",[72,246,248],{"id":247},"gsd-get-shit-done-la-complexité-cachée-derrière-la-simplicité-affichée","GSD (Get Shit Done): la complexité cachée derrière la simplicité affichée",[26,250,251,254],{},[44,252,253],{},"GSD"," (Get Shit Done) adopte une philosophie différente: \"Move complexity into the system, not the workflow.\" Pour l'utilisateur, l'interface est simple, quelques commandes qui \"just work\". Mais en coulisses, GSD orchestre du context engineering avancé, du prompt XML, des subagents et de la gestion d'état.",[26,256,257],{},"GSD est utilisé par des ingénieurs chez Amazon, Google, Shopify et Webflow. Il est particulièrement adapté aux développeurs solo qui veulent aller vite sans gérer eux-mêmes la complexité de l'orchestration.",[26,259,260],{},"La nuance importante: GSD est simple à utiliser, pas simple à comprendre. Quand quelque chose ne fonctionne pas comme prévu, debugger le système peut être délicat.",[26,262,212,263],{},[214,264,267],{"href":265,"rel":266},"https:\u002F\u002Fgithub.com\u002Fgsd-build\u002Fget-shit-done",[218],"github.com\u002Fgsd-build\u002Fget-shit-done",[72,269,271],{"id":270},"openspec-pour-les-projets-existants","OpenSpec: pour les projets existants",[26,273,274,277],{},[44,275,276],{},"OpenSpec"," répond à un problème différent: comment utiliser l'IA sur un projet brownfield, un codebase existant avec de la dette technique, sans introduire de nouvelles incohérences?",[26,279,280,281,285,286,289],{},"Sa clé conceptuelle: \"version control for intent\". OpenSpec sépare physiquement l'état actuel du projet (dans un répertoire ",[282,283,284],"code",{},"specs\u002F",") des modifications proposées (dans un répertoire ",[282,287,288],{},"changes\u002F","). Avant d'écrire une seule ligne de code, on s'accorde sur ce qu'on veut construire. L'IA ne peut pas \"dériver\" parce que les frontières entre l'existant et le proposé sont explicites.",[26,291,292],{},"Pour les agences web qui travaillent sur des sites WordPress par exemple ou des applications existantes et veulent commencer à intégrer l'IA sans tout casser, OpenSpec mérite sérieusement d'être évalué.",[26,294,212,295],{},[214,296,299],{"href":297,"rel":298},"https:\u002F\u002Fgithub.com\u002FFission-AI\u002FOpenSpec",[218],"github.com\u002FFission-AI\u002FOpenSpec",[72,301,303],{"id":302},"claude-task-master-la-gestion-de-tâches-pour-lia","Claude Task Master: la gestion de tâches pour l'IA",[26,305,306,309],{},[44,307,308],{},"Claude Task Master"," est un système de task management pensé spécifiquement pour le développement assisté par l'IA. Il s'installe directement dans Cursor, Windsurf, Lovable ou Roo sans changer fondamentalement votre workflow.",[26,311,312],{},"Son principe: décomposer automatiquement une fonctionnalité en tâches granulaires, les prioriser par dépendances, et permettre à l'IA de les adresser une par une avec un contexte précis. Plutôt que de donner à l'IA une user story complexe et espérer un résultat cohérent, Claude Task Master découpe le problème en unités que le LLM peut traiter de façon fiable.",[26,314,315],{},"C'est un outil complémentaire plus qu'un framework complet. Il s'intègre bien avec BMAD ou le Spec Kit.",[26,317,212,318],{},[214,319,322],{"href":320,"rel":321},"https:\u002F\u002Fgithub.com\u002Feyaltoledano\u002Fclaude-task-master",[218],"github.com\u002Feyaltoledano\u002Fclaude-task-master",[72,324,326],{"id":325},"aws-kiro-le-seul-ide-nativement-spec-driven","AWS Kiro: le seul IDE nativement spec-driven",[26,328,329,332],{},[44,330,331],{},"Kiro"," est une catégorie à part. Ce n'est pas un framework à installer dans votre IDE existant: c'est un IDE complet construit par AWS autour du spec-driven development.",[26,334,335,336,339],{},"Son workflow: vous décrivez une fonctionnalité en langage naturel, Kiro génère automatiquement des ",[44,337,338],{},"requirements formalisés"," (en notation EARS, un standard pour les spécifications d'ingénierie), puis une architecture, puis un plan d'implémentation avec des tâches séquencées par dépendances. Vous validez chaque étape avant que le code soit écrit.",[26,341,342],{},"Kiro introduit aussi deux concepts originaux:",[26,344,345,346,349],{},"Les ",[44,347,348],{},"Agent Hooks",": des triggers automatiques qui exécutent des actions prédéfinies sur des événements (save, create, delete). Par exemple, à chaque fois que vous sauvegardez un fichier, Kiro peut automatiquement mettre à jour la documentation correspondante.",[26,351,345,352,355],{},[44,353,354],{},"Steering files",": des fichiers Markdown qui décrivent les conventions, librairies et standards de votre projet. Au lieu de répéter vos préférences à chaque session, vous les définissez une fois. Kiro les intègre en contexte persistant.",[26,357,358],{},"Pour les projets qui démarrent de zéro avec une volonté forte de structure dès le départ, Kiro est probablement la solution la plus mature.",[26,360,361,362],{},"Site officiel: ",[214,363,366],{"href":364,"rel":365},"https:\u002F\u002Fkiro.dev\u002F",[218],"kiro.dev",[72,368,370],{"id":369},"tdd-avec-lia-la-méthode-classique-qui-retrouve-une-nouvelle-jeunesse","TDD avec l'IA: la méthode classique qui retrouve une nouvelle jeunesse",[26,372,373,374,377],{},"Le ",[44,375,376],{},"Test-Driven Development"," n'est pas nouveau, c'est une pratique des années 1990. Mais avec l'IA, il prend une dimension nouvelle et particulièrement pertinente.",[26,379,380],{},"Le principe du TDD: écrire les tests avant le code. On définit ce que le code doit faire (les assertions), puis on écrit le code qui fait passer ces tests.",[26,382,383],{},"Avec un LLM, les tests deviennent une spec exécutable. On donne à l'IA les tests à passer, elle génère le code correspondant. L'avantage majeur: les tests agissent comme garde-fou contre les hallucinations. Si l'IA génère du code incorrect, les tests échouent immédiatement et visiblement.",[26,385,386],{},"Le site codemanship.wordpress.com l'exprime bien: \"TDD works so well in AI-assisted programming because the developer can set the quality barriers and define the design.\" L'IA écrit le code, le développeur définit les critères de succès. Chacun fait ce qu'il fait le mieux.",[26,388,389],{},"En pratique, TDD et SDD convergent: les specs deviennent des tests, les tests deviennent des specs. C'est d'ailleurs ce qu'AWS Kiro fait nativement avec les critères d'acceptation de ses Feature Specs.",[72,391,393],{"id":392},"ralph-loop-matt-pocock-les-fondamentaux-dabord-lautonomie-ensuite","Ralph Loop (Matt Pocock) — les fondamentaux d'abord, l'autonomie ensuite",[26,395,396],{},"Matt Pocock, formateur TypeScript et créateur d'AI Hero, défend une position qui résonne directement avec la thèse de cet article. Sa conférence \"It Ain't Broke\" (AI Engineer Europe, 2026) est explicite: les fondamentaux du développement logiciel ne sont pas rendus obsolètes par l'IA. Ils sont devenus encore plus critiques.",[26,398,399,400,411],{},"Son workflow complet: ",[44,401,402,403,406,407,410],{},"Idea → ",[282,404,405],{},"\u002Fwrite-a-prd"," → PRD → ",[282,408,409],{},"\u002Fprd-to-issues"," → Kanban → Ralph Loop → Manual QA",".",[26,413,414,415,418],{},"Le coeur de sa méthode est le ",[44,416,417],{},"Ralph Loop",", une technique pour faire tourner des agents IA en boucles autonomes prolongées. L'idée: au lieu de superviser chaque échange avec l'IA, on configure un agent qui lit le backlog, choisit la prochaine tâche, l'implémente en TDD (red-green-refactor), fait tourner les tests et les vérifications de types, committe si ça passe, et recommence. On revient quelques heures plus tard à du code fonctionnel et committé.",[26,420,421],{},"Deux concepts structurent son approche:",[26,423,424,427],{},[44,425,426],{},"La \"Smart Zone\"."," Les LLMs ont une fenêtre de performance optimale, autour de 100 000 tokens de contexte. En dessous, ils sont efficaces. Au-delà, ils entrent dans la \"dumb zone\": la qualité chute, les hallucinations augmentent. Sa règle: ne jamais donner à l'IA plus qu'elle ne peut \"chew\" à la fois. Décomposer les tâches en unités atomiques plutôt que de tout envoyer en une seule requête.",[26,429,430,433],{},[44,431,432],{},"Le prompt \"Grill me\"."," Avant d'écrire une spec, Pocock utilise un skill qui demande à l'IA de challenger ses hypothèses de conception. L'IA joue l'avocat du diable sur l'architecture envisagée. L'objectif: découvrir les angles morts avant de committer une direction, pas après avoir codé 500 lignes dans le mauvais sens.",[26,435,436,437,440,441,444,445,444,448,444,451,444,454,444,457,460],{},"Sa collection de 21 skills Claude Code (installables via ",[282,438,439],{},"npx",") formalisent ces pratiques: ",[282,442,443],{},"to-prd",", ",[282,446,447],{},"to-issues",[282,449,450],{},"grill-me",[282,452,453],{},"tdd",[282,455,456],{},"improve-codebase-architecture",[282,458,459],{},"git-guardrails-claude-code","... Chaque skill impose une discipline de workflow à l'agent, pas juste au développeur.",[26,462,463],{},"Ce qui distingue l'approche Pocock des autres frameworks: elle ne cherche pas à remplacer les pratiques d'ingénierie par des specs IA. Elle les renforce. Le TDD reste du TDD, le design reste du design. L'IA s'insère dans un processus éprouvé plutôt que de proposer un nouveau paradigme.",[26,465,466,467],{},"Vidéo d'explication : ",[214,468,469],{"href":469,"rel":470},"https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=v4F1gFy-hqg",[218],[26,472,473,474,479,480],{},"Skills: ",[214,475,478],{"href":476,"rel":477},"https:\u002F\u002Fwww.everydev.ai\u002Ftools\u002Fmattpocock-skills",[218],"everydev.ai\u002Ftools\u002Fmattpocock-skills"," — Ralph Loop: ",[214,481,484],{"href":482,"rel":483},"https:\u002F\u002Fgithub.com\u002Fsnwfdhmp\u002Fawesome-ralph",[218],"github.com\u002Fsnwfdhmp\u002Fawesome-ralph",[64,486],{},[67,488,490],{"id":489},"le-paradoxe-a-t-on-vraiment-simplifié-le-développement","Le paradoxe: a-t-on vraiment simplifié le développement?",[26,492,493],{},"Posons la question franchement. En 2025, vibe coding = ouvrir un chat et taper une demande. En 2026, \"bien développer avec l'IA\" = choisir entre 8 frameworks, apprendre leurs concepts (agents, PRDs, specs EARS, steering files, agent hooks...), configurer des dizaines de fichiers, et maintenir une documentation qui précède le code.",[26,495,496],{},"Est-ce vraiment plus simple?",[72,498,500],{"id":499},"la-complexité-sest-déplacée-pas-disparue","La complexité s'est déplacée, pas disparue",[26,502,503],{},"Ce qui a changé: vous écrivez moins de code bas niveau. Ce qui n'a pas changé: vous devez comprendre exactement ce que vous voulez construire, comment l'architecturer, et comment vérifier que ce qui est produit est correct.",[26,505,506],{},"En fait, les frameworks SDD ont révélé quelque chose d'intéressant. Les LLMs échouent précisément là où les développeurs juniors échouent aussi: sur les parties floues, mal définies, sans spécification claire. Quand le problème est précisément formulé, comme dans un bon test unitaire ou une user story bien rédigée, l'IA performe remarquablement. Quand c'est vague, elle hallucine.",[26,508,509],{},"Les frameworks SDD ne compensent pas les limites de l'IA. Ils compensent les limites de la formulation humaine. Ils forcent à définir précisément ce qu'on veut, et c'est exactement ce qu'un bon développeur senior faisait déjà avant même d'écrire la première ligne.",[72,511,513],{"id":512},"ce-qui-a-changé-pour-les-développeurs","Ce qui a changé pour les développeurs",[26,515,516],{},"Le repositionnement des compétences développeur avec l'IA est réel:",[48,518,519,525],{},[51,520,521,524],{},[44,522,523],{},"Avant",": savoir écrire du code, connaître les patterns, débugger à la main",[51,526,527,530,531],{},[44,528,529],{},"Maintenant",": savoir architecturer un système, rédiger des specs précises, et surtout ",[44,532,533],{},"relire et valider du code généré par l'IA",[26,535,536],{},"Cette dernière compétence est critique et sous-estimée. Un LLM peut produire du code qui compile, passe les tests basiques, et reste pourtant fondamentalement défaillant sur des edge cases ou des problèmes de sécurité. Un développeur qui ne sait pas lire du code, qui délègue entièrement la compréhension à l'IA, ne peut pas détecter ces défaillances.",[72,538,540],{"id":539},"ce-qui-na-absolument-pas-changé","Ce qui n'a absolument pas changé",[26,542,543],{},"Savoir comment un projet devrait fonctionner reste indispensable. Écrire une bonne spec ou un bon PRD demande de comprendre les cas d'usage, les contraintes techniques, les dépendances entre composants. Ça, aucune IA ne peut le faire à votre place, elle n'a pas accès à vos clients, à votre contexte métier, à vos contraintes d'infrastructure.",[26,545,546],{},"La dette technique existe toujours. Elle se génère même plus vite avec l'IA qu'à la main, précisément parce que la vitesse de production augmente. Si la direction est mauvaise, on va plus vite dans le mauvais sens.",[26,548,549],{},"Et savoir relire du code reste la compétence numéro un qui sépare un bon développeur d'un utilisateur d'IA. Les frameworks aident, mais ils ne remplacent pas le jugement.",[64,551],{},[67,553,555],{"id":554},"conclusion-lia-a-transformé-le-développement-pas-simplifié","Conclusion: l'IA a transformé le développement, pas simplifié",[26,557,558],{},"Ce n'est pas une tendance, c'est un mouvement de fond. L'industrie a collectivement reconnu que laisser l'IA \"vibe\" sans contraintes ne fonctionnait pas à l'échelle.",[26,560,561],{},"Mais voilà ce qu'il faut retenir: la complexité des frameworks n'est pas un échec de l'IA. C'est la preuve que le développement logiciel est intrinsèquement complexe, et que cette complexité ne disparaît pas, elle se déplace vers la conception, la spécification, la review.",[26,563,564],{},"Les développeurs qui prospèrent dans cet environnement ne sont pas ceux qui ont abandonné la lecture du code à l'IA. Ce sont ceux qui savent architecturer des systèmes, rédiger des specs précises, et valider ce que l'IA produit.",[26,566,567],{},"Le développeur du futur n'est pas remplacé. Il est repositionné. Chef d'orchestre d'une équipe d'agents, architecte des contraintes, relecteur critique de la production IA. C'est un rôle différent, plus stratégique, et qui demande encore plus de compétence réelle.",[26,569,570],{},"Choisissez votre framework selon la complexité de votre projet, pas selon l'effet de mode. Et si vous ne savez pas lire le code que l'IA génère pour vous, commencez par apprendre ça.",[64,572],{},[26,574,575],{},[576,577,578,579,444,584,444,588,444,592,444,595,444,598,444,601,444,606,444,611],"em",{},"Sources: ",[214,580,583],{"href":581,"rel":582},"https:\u002F\u002Fdocs.bmad-method.org\u002F",[218],"BMAD Method",[214,585,587],{"href":242,"rel":586},[218],"GitHub Spec Kit",[214,589,591],{"href":364,"rel":590},[218],"AWS Kiro",[214,593,253],{"href":265,"rel":594},[218],[214,596,276],{"href":297,"rel":597},[218],[214,599,308],{"href":320,"rel":600},[218],[214,602,605],{"href":603,"rel":604},"https:\u002F\u002Fwww.thoughtworks.com\u002Fradar\u002Ftechniques\u002Fspec-driven-development",[218],"Thoughtworks Tech Radar",[214,607,610],{"href":608,"rel":609},"https:\u002F\u002Fdevelopers.redhat.com\u002Farticles\u002F2026\u002F02\u002F17\u002Funcomfortable-truth-about-vibe-coding",[218],"Red Hat Developer",[214,612,615],{"href":613,"rel":614},"https:\u002F\u002Fthenewstack.io\u002Fvibe-coding-spec-driven\u002F",[218],"The New Stack",{"title":617,"searchDepth":618,"depth":618,"links":619},"",2,[620,627,638,643],{"id":69,"depth":618,"text":70,"children":621},[622,624,625,626],{"id":74,"depth":623,"text":75},3,{"id":87,"depth":623,"text":88},{"id":100,"depth":623,"text":101},{"id":134,"depth":623,"text":135},{"id":143,"depth":618,"text":144,"children":628},[629,630,631,632,633,634,635,636,637],{"id":150,"depth":623,"text":151},{"id":182,"depth":623,"text":183},{"id":222,"depth":623,"text":223},{"id":247,"depth":623,"text":248},{"id":270,"depth":623,"text":271},{"id":302,"depth":623,"text":303},{"id":325,"depth":623,"text":326},{"id":369,"depth":623,"text":370},{"id":392,"depth":623,"text":393},{"id":489,"depth":618,"text":490,"children":639},[640,641,642],{"id":499,"depth":623,"text":500},{"id":512,"depth":623,"text":513},{"id":539,"depth":623,"text":540},{"id":554,"depth":618,"text":555},"Vibe coding, BMAD, Spec-Driven, AWS Kiro, GSD: tour d'horizon des méthodes de développement IA en 2026 et pourquoi les développeurs restent indispensables.","md",{},true,"\u002Farticles\u002Fvibe-coding-bmad-spec-driven-methode-developpement-ia","2026-04-28",{"title":18,"description":644},"articles\u002Fvibe-coding-bmad-spec-driven-methode-developpement-ia","GFveb6sYMeLvYadSZ25Oal_qemQuj2goEMvS73K0Yzw",{"left":4,"top":4,"width":5,"height":5,"rotate":4,"vFlip":6,"hFlip":6,"body":654},"\u003Cpath fill=\"currentColor\" d=\"M4 21V9l8-6l8 6v12h-6v-7h-4v7z\"\u002F>",["Island",656],{"key":657,"result":658},"Brand_bAcjTzQpW6OVpFK319jfMki97vH1GrZiqHmeI7Xg4o",{"head":659},{},{"left":4,"top":4,"width":5,"height":5,"rotate":4,"vFlip":6,"hFlip":6,"body":661},"\u003Cpath fill=\"currentColor\" d=\"M6 22q-.825 0-1.412-.587T4 20V10q0-.825.588-1.412T6 8h3v2H6v10h12V10h-3V8h3q.825 0 1.413.588T20 10v10q0 .825-.587 1.413T18 22zm5-6V4.825l-1.6 1.6L8 5l4-4l4 4l-1.4 1.425l-1.6-1.6V16z\"\u002F>",["Island",663],{"key":664,"result":665},"ArticleDetails_RxZhQZT8shaVyMLsxUcIvV50e9iwRl6hj3aVt6XwBs",{"head":666},{},1777387242255]