Deux approches du SDLC agentique
Deux approches du SDLC agentique commencent à se dessiner. Elles s'appuient sur les mêmes agents de codage et placent pourtant le centre de gravité à deux endroits différents.
Un workflow laissé libre
Dans les pratiques publiées autour du SDLC utilisant Claude Code, Anthropic laisse volontairement beaucoup de liberté au développeur. Le workflow n'est pas imposé et la documentation projet reste relativement libre dans sa structure.
Cette souplesse s'appuie largement sur les capacités du modèle : explorer un codebase, comprendre le contexte, élaborer un plan, produire le code, tester puis itérer avec le développeur. La qualité du résultat dépend alors beaucoup de la capacité du modèle à reconstituer le contexte, et de celle du développeur à le guider.
Un SDD intégré à un SDLC
Une approche SDD intégrée à un SDLC, comme BMAD et sa déclinaison Niji ARC™, déplace beaucoup plus nettement le centre de gravité. La spécification devient l'un des principaux supports du delivery.
| Dimension | Workflow libre | SDD intégré au SDLC |
|---|---|---|
| Centre de gravité | Le modèle et le développeur | La spécification |
| Workflow | Non imposé | Organisé par des workflows et des skills |
| Documentation projet | Structure relativement libre | Référentiel commun : besoins, parcours, architecture, décisions, critères d'acceptation, tests, RUN |
| Qui contribue | Principalement le développeur, avec le modèle | Métier, Product Builder, direction de projet, designer, architecte, développeurs, QA |
| Où repose la qualité | Sur la capacité du modèle et de l'utilisateur à reconstruire le contexte | Sur un cadre partagé |
| Point fort | Tirer vite parti des progrès des modèles, forte autonomie du développeur | Cohérence et continuité du delivery |
La spécification, un référentiel commun au projet
Dans cette seconde approche, la spécification devient un référentiel commun au projet, au-delà du simple contexte destiné aux agents. Elle rassemble :
- les besoins métier ;
- les parcours ;
- l'architecture ;
- les décisions techniques ;
- les critères d'acceptation ;
- les tests ;
- les contraintes de RUN.
Métier, Product Builder, direction de projet, designer, architecte, développeurs et QA peuvent ainsi travailler à partir d'une même matière, également exploitable par les agents. Chacun contribue depuis son rôle, et ce que l'un produit alimente directement le travail des autres, humains comme agents.
C'est le principe que nous appliquons avec Niji ARC™ : la spécification est le produit, et les agents génèrent le code, les tests et la documentation directement depuis elle. Le rôle du Product Builder dans ce système est détaillé dans notre réflexion sur la taille des squads IA.
Workflows et skills : organiser la construction collective
Une matière partagée ne suffit pas : encore faut-il organiser la manière dont elle se construit. C'est le rôle des workflows et des skills, qui définissent qui contribue, à quel moment, avec quel niveau de contexte et quels contrôles.
Chaque rôle intervient depuis son périmètre : métier, produit, design, architecture, développement, QA. Les workflows rendent ces contributions explicites au lieu de les laisser à l'initiative de chacun.
Les contributions sont séquencées le long du cycle, de l'expression du besoin à la mise en production, avec des étapes identifiées de bout en bout.
Chaque agent et chaque contributeur reçoit le contexte utile à son étape, issu du référentiel commun, sans avoir à le reconstruire.
Des points de validation jalonnent le parcours : critères d'acceptation, tests, revues. La matière produite à une étape ne devient la base de la suivante qu'une fois contrôlée.
Nous appliquons la même logique de rôles, de skills et de workflows aux métiers de la data avec le framework MAD.
La différence se voit à l'industrialisation
La différence devient particulièrement visible lorsqu'on cherche à industrialiser.
Un workflow très libre permet de tirer rapidement parti des progrès des modèles et conserve une forte autonomie au développeur. Pour un développeur ou une petite équipe, c'est un atout réel.
Un SDLC davantage structuré cherche au contraire à faire reposer une part plus importante de la qualité, de la cohérence et de la continuité du delivery sur un cadre partagé, plutôt que sur la seule capacité du modèle et de l'utilisateur à reconstruire le contexte.
Trois questions pour situer votre contexte. Combien de personnes et de rôles contribuent au même produit ? Quelle est la durée de vie du produit, et qui le fera vivre en RUN ? Quand un contributeur change de projet, le contexte reste-t-il dans le référentiel ou dans la tête de quelqu'un ?
Du coding agentique au delivery agentique
L'enjeu n'est alors plus uniquement l'efficacité du coding agentique. Il devient celui d'un delivery logiciel agentique, dans lequel humains et agents contribuent au même système de référence, chacun depuis son rôle.
Les modèles continueront de progresser. La question de savoir sur quel référentiel humains et agents construisent ensemble se posera quel que soit le modèle utilisé.
À retenir. Un workflow libre tire parti de la puissance du modèle. Un SDLC structuré fait de la spécification un référentiel commun où humains et agents contribuent, chacun depuis son rôle.
