Aller au contenu

Brainstorm sur un SDLC agentique

Billet #256 : Réflexion sur un SDLC agentique — Spec Kit & LangChain
Type : Gouvernance / SDLC / IA
Composants concernés : .github/agents/, .specify/, specs/008-agentic-brainstorm/, docs/activity_report/, docs/fr/activity_report/

1. Contexte et objectif

Depuis le départ, la vision du projet AFA est claire : en faire un laboratoire concret d'automatisation du SDLC avec l'IA, et pas seulement une application métier. La réflexion présentée dans ce rapport marque un pas décisif dans cette direction.

L'idée de départ consistait à construire un univers agentique inspiré d'une entreprise virtuelle. Dans ce modèle, je joue le rôle du Président — un profil non technique qui exprime ses besoins et ses attentes en langage simple. Un premier agent, le Directeur Général, reçoit ces directives, les traduit en plan d'action technique, coordonne l'exécution par une équipe de VP spécialisés, puis me restitue les résultats et les pistes d'amélioration toujours en langage non technique. Chaque VP est un expert dans son domaine : produit, infrastructure, développement, assurance qualité.

L'objectif de cette session de réflexion était donc de déterminer si cette vision pouvait être mise en œuvre de façon réaliste, sans compromettre la gouvernance, la sécurité et la maintenabilité du SDLC déjà en place avec Spec Kit.

2. Doutes et évaluation des risques

Dès les premiers échanges avec Gemini, mon assistant de réflexion pour cette session, plusieurs questions légitimes ont émergé, chacune soulevant un risque concret.

  1. Risque de doublon : en ajoutant une hiérarchie d'agents LangChain, ne risquions-nous pas de reproduire ce que Spec Kit fait déjà avec ses propres agents de cadrage et de livraison ?
  2. Risque de sur-automatisation : à quel point fallait-il laisser l'IA agir de façon autonome, en particulier sur des opérations aussi sensibles que le déploiement et le rollback en production ?
  3. Risque de dette d'orchestration : un trop grand nombre d'agents interagissant entre eux ne coûterait-il pas finalement plus cher à maintenir que la valeur qu'ils produisent ?
  4. Risque de dilution de la gouvernance : comment préserver l'approbation obligatoire du propriétaire et les garde-fous déterministes déjà en place, si des agents prennent des décisions de façon autonome ?

Ces quatre risques ont guidé l'ensemble de la réflexion qui a suivi.

3. Clarification structurante issue des échanges

Pour avancer, une distinction fondamentale s'est imposée d'elle-même.

Spec Kit est la couche de cadrage et de livraison : spécification, planification, décomposition en tâches, implémentation guidée. C'est le squelette du SDLC. LangChain, pour sa part, ne doit pas venir concurrencer ce rôle. Son apport le plus utile réside ailleurs : dans l'analyse, la synthèse et l'aide à la décision, en complément de ce que Spec Kit fait déjà.

En posant cette frontière clairement, on élimine le principal piège identifié : reconstruire Spec Kit en LangChain, avec deux orchestrateurs qui se chevauchent et se contredisent.

4. Point de convergence final

Cette réflexion a abouti à un consensus articulé en quatre décisions fermes.

  1. Maintenir la couche déterministe comme autorité de release : GitHub Actions et Pytest restent les arbitres finaux — une suite de tests qui passe ou qui casse, sans ambiguïté ni probabilisme.
  2. Préserver le Human-in-the-loop : toute action sensible en écriture reste conditionnelle à l'approbation explicite du propriétaire du dépôt.
  3. Démarrer LangChain avec seulement deux agents analytiques :
    • un Incident Analyzer, pour diagnostiquer les anomalies et proposer des pistes de remédiation, en mode conseil uniquement ;
    • un Retrospective Synthesizer, pour produire des brouillons de rapports d'activité et de leçons apprises à partir des artefacts de session, également en mode conseil.
  4. Exclure explicitement toute autonomie LLM sur le déploiement ou le rollback à ce stade.

5. Décision actée et traçabilité

Pour formaliser ce consensus et préparer la suite, un billet parent a été créé dans le dépôt GitHub : #256.

Ce billet sert de conteneur stratégique pour la décomposition future en billets enfants, couvrant l'architecture, les contrats d'interface, l'implémentation incrémentale, l'observabilité et les critères de validation.

6. Impact business et engineering

Ce cadre offre un équilibre robuste entre accélération et maîtrise des risques.

  • Vitesse : l'IA continue d'accélérer la production de contenu et l'analyse des incidents.
  • Contrôle : la qualité de chaque release reste validée par des systèmes déterministes, sans dépendance à un modèle probabiliste.
  • Gouvernance : la responsabilité finale des décisions critiques reste clairement humaine.
  • Maintenabilité : en limitant le nombre d'agents dès le départ, on évite l'explosion prématurée de la complexité d'orchestration.

En pratique, on évite l'« usine à agents » tout en préservant la valeur concrète que l'IA peut apporter.

7. Leçons apprises

Trois enseignements clés ressortent de cette réflexion.

  1. La meilleure stratégie n'est pas d'automatiser le plus grand nombre de tâches possible, mais d'automatiser la bonne couche au bon moment.
  2. Lorsque deux approches semblent toutes les deux valides, la bonne décision émerge généralement d'une séparation nette des responsabilités entre les couches.
  3. L'IA produit plus de valeur durable dans l'analyse après coup et la synthèse décisionnelle que dans le contrôle autonome d'actions de production.

8. Prochaine étape

La prochaine étape consiste à décomposer le billet parent #256 en sous-billets exécutables, puis à lancer un premier lot minimal :

  1. contrat d'interface de l'Incident Analyzer,
  2. contrat d'interface du Retrospective Synthesizer,
  3. critères d'acceptation SDLC et garde-fous de gouvernance.