Issue-Based Development

Qu'est-ce que l'Issue-Based Development ?

L'Issue-Based Development (développement piloté par les issues) est une façon de confier du travail à un agent de codage : au lieu de décrire une fonctionnalité à ajouter, on signale un écart (un manque, un bug, une amélioration possible) et on laisse l'agent analyser l'existant, code, specs et architecture, pour produire une solution cohérente avec l'ensemble du système. Le mot issue vient des gestionnaires de tickets, où il désigne un signalement.

Didier Girard oppose ce modèle au spec-driven development dans sa présentation AI for IT : la stratégie du 10x (février 2026) : Spec-Driven en 2025, Issue-Based en 2026. Demander l'ajout d'une fonctionnalité isolée, une salle de bain par exemple, conduit l'IA à la coller sur la façade ; le résultat est une verrue logicielle. Signaler un manque et laisser l'IA s'appuyer sur le contexte de l'application donne une cohérence systémique.

D'où vient le terme

Le terme appartient au vocabulaire de SFEIR. Il apparaît dans la présentation de février 2026, matière interne, puis dans deux articles publiés sur ce site le 1er avril 2026 : Du Spec-Driven à l'Issue-Based et Écrire du code est un anti-pattern. Il prolonge une conviction de la même présentation : la valeur se déplace du code vers le contexte, et ce contexte se versionne dans Git comme un actif vivant.

Comment ça marche

Une issue traverse le cycle en cinq temps :

• Le signalement : l'App Owner, un utilisateur ou la supervision décrit l'écart observé et le comportement attendu, sans prescrire la solution.
• L'analyse : l'agent lit le contexte gouverné (architecture, décisions documentées, conventions, tests, règles métier), localise la cause et propose un plan qui respecte les patterns en place.
• La porte humaine : le plan passe au gate Plan du SDLC augmenté, où l'humain arbitre les choix d'architecture avant tout code.
• L'exécution et la revue : l'agent construit, les tests s'exécutent, une revue multi-agents puis humaine juge la modification avant livraison (gate Ship).
• La capitalisation : ce que le signalement a révélé (une règle absente, une convention non écrite) est consigné pour que le même écart ne revienne pas ; c'est l'étape Compound du compound engineering.

Le prérequis : un contexte gouverné

Sans un contexte structuré, versionné et maintenu (context engineering), l'agent qui reçoit une issue n'a rien d'autre à analyser que le code, et retombe dans la verrue. Sur un projet existant, ce premier contexte (auditer, documenter l'implicite, formaliser des années de décisions non tracées) est un investissement à faire avant de basculer. Sur un projet neuf, il se pose dès le départ.

Erreurs courantes

• Croire que l'issue remplace la spécification. La spec reste le gate Define du cycle ; ce qui change est sa granularité. Addy Osmani (Google Chrome) documente en janvier 2026 que les specs massives dégradent l'adhérence du modèle ; il recommande une vision haut niveau, puis des fichiers de spec modulaires.
• Signaler un écart sur un contexte vide. L'issue-based suppose que l'architecture, les conventions et les décisions sont écrites quelque part où l'agent peut les lire.
• Déverser un backlog de tickets à un agent sans porte humaine. Sans arbitrage au Plan et sans revue au Ship, l'agent traite vite des tickets dont personne n'a vérifié la cohérence d'ensemble.
• Laisser la leçon dans le ticket fermé. Le cycle SFEIR traite un bug vu deux fois comme un trou dans le système, à combler dans les règles rechargées au cycle suivant.

Ce que SFEIR en fait

L'issue-based est le régime de travail de la Sandwich Team : l'App Owner tient 80 % de l'application (UX, UI, front, API, back, sécurité) et fait produire l'IA à partir des écarts qu'il constate ; les contributeurs ponctuels, 20 % du volume, interviennent par le contexte partagé, d'où la règle de le garder dans Git. La présentation de février 2026 fixe aussi la répartition du temps : 80 % sur le plan et la revue, 20 % sur l'exécution du code.

Dans le SDLC augmenté, une issue entre par Define, est arbitrée au Plan, exécutée sous discipline de preuve et ressort par Compound. La même présentation laisse à chaque ingénieur le choix de son outil d'IA ; ce que SFEIR standardise, c'est le contexte et le code produit.