Je livre des fonctionnalités production plus vite que jamais. Pas parce que j'écris plus de code—mais parce que j'en écris à peine.
La différence, ce n'est pas le modèle IA. C'est le processus autour.
Le Problème
La plupart des développeurs utilisent les agents de codage IA comme une fenêtre de chat. Demander du code, le coller, demander des corrections, perdre le contexte, recommencer. Ça ship—parfois. Mais la qualité est inconsistante, le processus chaotique, et rien ne se transmet d'une session à l'autre.
Sans workflow
Pas de définition claire de 'terminé'
Pas de code review systématique
Pas de quality gates sauf si on y pense
Impossible de reprendre après perte de contexte
Les apprentissages disparaissent à chaque session
Avec le workflow skill
La spec définit 'terminé' avant que le code existe
Tests E2E-first avec hiérarchie d'évitement des mocks
Debugging scientifique dédié avec règles de prévention
Je voulais un système où je définis quoi construire, et l'agent gère toute la boucle d'implémentation jusqu'à ce que le code soit prêt pour la production.
Alors j'en ai construit un.
Le Workflow Skill
Un cycle de développement structuré pour agents de codage IA. 10 actions, de l'idée au code livré :
Action
Ce qu'elle fait
focus
Scanner le codebase pour identifier la prochaine tâche, priorisée par impact
plan
Créer une spec avec critères d'acceptation et analyse d'impact codebase
spec-review
Challenge adversarial de la spec avant le début de l'implémentation
spike
Exploration time-boxée pour les inconnues, décision go/no-go à la fin
ship
Implémenter, tester, reviewer—en boucle jusqu'à ce que tous les ACs passent
fix
Debugging scientifique avec investigation par hypothèses et anti-cascade TDD
review
Code review multi-perspective (9 perspectives, scalée par risque)
done
Validation finale, rétro, mise à jour mémoire, archivage
drop
Abandonner proprement, conserver les apprentissages
workflow
Afficher l'état actuel et suggérer la prochaine action
L'idée centrale : la spec est la source de vérité. Tout en découle—implémentation, tests, review, validation.
Le Workflow Complet
1. Focus : Sur quoi travailler ?
Pas d'idée de quoi construire ensuite ? Demandez au codebase :
~/mon-projet
~ /workflow sur quoi devrais-je me concentrer ?
L'agent lance des scans parallèles sur tout le projet—qualité du code, tests manquants, failles de sécurité, problèmes de performance, accessibilité. Les résultats reviennent scorés par impact, effort et risque-si-ignoré.
Il produit une liste de tâches priorisées et crée des specs dans specs/backlog/ pour les éléments prioritaires.
Au lieu de décider quoi faire, le codebase vous le dit.
2. Plan : Définir ce que "Terminé" veut dire
On ne commence pas par le code. On commence par une spec.
~/mon-projet
~ /workflow plan ajouter du rate limiting à l'API
L'agent lit d'abord le codebase—patterns existants, code lié, conflits potentiels. Puis il rédige une spec avec :
Parcours utilisateur : Qui fait quoi, et pourquoi (ACTOR/GOAL/PRECONDITION/POSTCONDITION)
Critères d'acceptation (ACs) : Format GIVEN/WHEN/THEN—testables, objectifs
Scope items : Exactement ce qui sera construit, traçable vers les ACs
La spec passe 13 règles de validation avant le début de l'implémentation. Trop grosse (>8 heures) ? Elle est découpée. Critères d'acceptation vagues ? L'agent refuse.
Aucune spec ne passe la gate si "terminé" n'est pas clairement défini.
3. Spec-Review : Challenger avant de construire
Avant d'écrire une seule ligne de code, challengez le plan :
~/mon-projet
~ /workflow review @specs/active/rate-limiting.md
L'agent lance une analyse adversariale de la spec :
Cas limites manquants
Scope qui ne trace pas vers les critères d'acceptation
Hypothèses potentiellement fausses
Angles morts dans l'analyse d'impact
Attrapez les problèmes dans la spec—pas en production.
4. Spike : Explorer avant de s'engager
Pas sûr de l'approche ? Lancez une exploration time-boxée :
~/mon-projet
~ /workflow spike Redis vs in-memory pour le rate limiting
Limite de temps stricte (défaut 1h, max 4h). Le résultat est une décision GO/NO-GO—pas du code. Le code du spike est jetable, supprimé avant de continuer. L'apprentissage est consigné.
Ça évite de s'engager sur une approche avant de savoir si elle fonctionne.
5. Ship : La boucle d'implémentation
Une fois la spec solide :
~/mon-projet
~ /workflow ship @specs/active/rate-limiting.md
L'agent entre dans une boucle :
On ne fait pas du pair programming. On délègue. L'agent gère la boucle. Vous reviewez le résultat.
Deux modes s'adaptent au contexte :
One-shot : Pas de spec nécessaire pour les quick fixes—crée une spec inline, implémente, valide
Loop : Une spec active existe—itère jusqu'à ce que tous les critères d'acceptation passent
Les tests suivent un protocole E2E-first. Chaque critère d'acceptation est mappé vers un test E2E par défaut. Les tests unitaires sont réservés aux fonctions pures uniquement. Une hiérarchie d'évitement des mocks impose les systèmes réels :
Priorité
Stratégie
1 (meilleur)
Système réel (test DB, API sandbox)
2
Docker/conteneur
3
Équivalent in-memory
4 (dernier recours)
Mock (uniquement pour les APIs tierces sans sandbox)
Mocker son propre code—services, base de données, endpoints HTTP, authentification—n'est jamais autorisé. Chaque mock exige un commentaire de justification.
Le TDD est structurellement enforced : chaque test doit échouer d'abord (RED_CONFIRMED), puis passer après implémentation (GREEN_CONFIRMED). Le skill trace tout dans un registre de scénarios E2E—pas de raccourcis.
6. Fix : Debugging scientifique
Les corrections de bugs ont leur propre action dédiée :
~/mon-projet
~ /workflow fix les utilisateurs ne peuvent pas réinitialiser leur mot de passe
L'agent classifie le bug (simple, complexe ou hautement complexe) et adapte son investigation :
Bugs simples (cause claire, fichier unique) : pas d'investigation, directement au fix
Bugs complexes : test d'hypothèses séquentiel, probabilité la plus haute en premier
Bugs hautement complexes : investigation parallèle depuis plusieurs perspectives—traceur de chemin d'exécution, inspecteur d'état, investigateur d'historique, analyseur de concurrence
Chaque cause racine doit passer une validation en 3 points avant tout changement de code :
Explique : Est-ce que ça rend compte de TOUS les symptômes observés ?
Prédit : Peut-on nommer le changement exact qui corrigera le bug ?
Reproduit : Peut-on faire apparaître et disparaître le bug à volonté ?
Puis l'Anti-Cascade TDD entre en jeu :
Baseline : Enregistrer l'état complet de la suite de tests
Red : Écrire un test E2E de régression qui échoue (RED_CONFIRMED)
Green : Implémenter le fix, le test passe (GREEN_CONFIRMED)
Diff : Relancer toute la suite—comparer au baseline. Tout nouvel échec = le fix a introduit des régressions
Scan : Chercher les bugs cousins dans le codebase (même pattern ailleurs)
Learn : Mettre à jour la spec si liée, proposer des règles de prévention pour la config de l'agent
La phase LEARN est ce qui rend ça composable : après chaque correction, l'agent propose max 2 règles de prévention pour que la même classe d'erreur ne se reproduise pas. Les règles sont toujours proposées—jamais auto-appliquées—et ciblent les fichiers de config de l'agent.
7. Quality Gates : Validation automatique
Chaque batch d'éditions déclenche un quick pass :
Gate
Scope
Lint
Fichiers modifiés
Typecheck
Fichiers modifiés
Avant de marquer done, un full pass fait tourner les 6 gates :
Gate
Scope
Lint
Fichiers modifiés
Typecheck
Projet complet
Build
Projet complet
Test
Tests liés
Registre E2E
Tous les critères d'acceptation mappés vers des tests E2E
Preuve TDD
Chaque GREEN_CONFIRMED a un RED_CONFIRMED préalable
La couverture tourne en gate advisory—alerte sur les baisses de plus de 5% mais ne bloque jamais.
Le skill auto-détecte l'outillage. Biome ou ESLint ? Vitest ou Jest ? pnpm, yarn ou bun ? Il lit les fichiers de config et se débrouille.
Pas de setup spécial. Validation production dès le premier jour.
8. Review : Neuf perspectives, scalées par risque
Le code review tourne automatiquement pendant la boucle ship—et à la demande :
~/mon-projet
~ /workflow review the code
Perspective
Question
Quand
Correctness
Est-ce que ça fait ce qu'il faut ?
Toujours
Security
Est-ce sécurisé ?
Toujours
Reliability
Est-ce que ça gère les erreurs ?
Toujours
Performance
C'est assez rapide ?
Toujours
DX
C'est agréable à maintenir ?
Toujours
Scalability
État partagé, multi-instance ?
Conditionnel
Observability
Debuggable en production ?
Conditionnel
Testability
Logique complexe couverte ?
Conditionnel
Accessibility
Clavier, lecteur d'écran, contraste ?
Conditionnel
La profondeur du review s'adapte au risque :
Scope
Profondeur
1-2 fichiers, risque faible
Rapide (5 perspectives)
3-5 fichiers
Standard
6+ fichiers ou risque élevé
Approfondi (les 9)
Contexte de déploiement détecté
Mode production
9. Done : Valider, apprendre, archiver
Quand tout passe :
~/mon-projet
~ /workflow done @specs/active/rate-limiting.md
Validation finale :
Tous les critères d'acceptation passent
Quality gates verts
Les nouveaux comportements ont de nouveaux tests
Pas de problèmes bloquants en review
Puis une rétro tourne automatiquement :
Estimation vs temps réel
Ce qui a marché, ce qui n'a pas marché
Patterns appris
L'agent propose des mises à jour mémoire—patterns de codage, conventions du projet, anti-patterns découverts. Elles sont écrites dans la config de votre agent pour que la prochaine session démarre plus intelligente.
La spec s'archive dans specs/shipped/. Historique consigné. Savoir conservé.
10. Drop : Abandonner sans perdre
Parfois une fonctionnalité ne fonctionne pas :
~/mon-projet
~ /workflow drop @specs/active/rate-limiting.md
Capture pourquoi c'est abandonné. Préserve les morceaux réutilisables. Documente les leçons "si on y revient." Archive dans specs/dropped/.
Pas d'abandon silencieux. Chaque fonctionnalité abandonnée enseigne la suivante.
Pourquoi ça produit du meilleur logiciel
Qualité spec-driven
La spec définit ce que "prêt pour la production" signifie avant que le code existe. Les critères d'acceptation sont testables—chacun mappé vers un test E2E avec preuve TDD (RED_CONFIRMED avant GREEN_CONFIRMED). Les scope items tracent vers les ACs. L'agent valide contre la spec—pas au feeling.
La qualité est structurelle, pas accidentelle.
Livraison le jour même
Tout est scopé pour livrer aujourd'hui. Les fonctionnalités de plus de 8 heures sont découpées. Le système de tiers l'impose :
Taille
Cérémonie
< 5 LOC
Aucune—on fait, c'est tout
< 30 LOC
Spec en commentaire inline
< 100 LOC
Template mini
100+ LOC
Spec complet avec state machines
Pas de sprints de deux semaines. Pas de surcharge de cérémonie. Les idées shipent le jour où elles naissent.
L'humain contrôle le déploiement
Le skill ne lance jamais git push ni de commande de déploiement. L'agent gère la qualité du code. Vous gérez la production.
Cette séparation compte pour la confiance. Je délègue la boucle de build parce que je sais que l'agent ne touchera rien d'irréversible sans demander.
Résilience de session
Le contexte se perd. Ça arrive. Le fichier spec permet une reprise parfaite :
~/mon-projet
~ /workflow ship @specs/active/rate-limiting.md
L'agent lit la spec, vérifie l'état actuel, reprend exactement là où il s'est arrêté. Pas de "rappelle-moi ce qu'on construisait."
Agnostique
Pas verrouillé sur un seul outil. Le même skill fonctionne avec Claude Code, Codex, OpenCode, Cursor, Windsurf, Aider—tout agent qui lit les fichiers SKILL.md.
Le paysage des outils IA évolue vite. Le workflow reste portable.
Pas de config nécessaire. Le skill auto-détecte l'outillage du projet.
Compromis
Ce n'est pas magique. De vrais compromis :
Overhead pour les petits changements : Un fix de typo d'une ligne n'a pas besoin d'une spec. Le skill détecte les changements triviaux et saute la cérémonie—mais parfois on veut juste éditer et commit.
Courbe d'apprentissage : Le format de la spec et les actions prennent du temps à intégrer. La première semaine semble plus lente. Après, c'est plus rapide qu'avant.
Qualité de l'agent variable : La boucle est aussi bonne que l'implémentation de l'agent. Les algorithmes complexes et le code métier spécifique nécessitent toujours un review humain attentif.
Consommation de tokens : Le review multi-perspective et les corrections itératives consomment des tokens. Ça vaut le coup pour le code production. Excessif pour les scripts jetables.
Pourquoi j'ai construit ça
Le momentum compte plus que la perfection.
Avant, je perdais la moitié de mon énergie dans le processus—où j'en étais ? Qu'est-ce que je construisais ? Est-ce que j'ai testé ce cas limite ? Maintenant la spec contient tout l'état. Les quality gates tournent automatiquement. L'agent review son propre code depuis 9 perspectives, enforce le TDD E2E-first, et apprend même des bugs pour empêcher la même classe d'erreur de se reproduire.
Le résultat : du meilleur logiciel, livré plus vite, dès le premier jour.
Critères d'acceptation (ACs) — Conditions testables qui définissent quand une fonctionnalité est "terminée." Écrits au format GIVEN/WHEN/THEN. Exemple : GIVEN un utilisateur envoie 100 requêtes en 1 minute, WHEN il envoie la requête 101, THEN il reçoit un status 429 avec un header Retry-After. Chaque scope item trace vers au moins un AC. Si on ne peut pas écrire un AC, c'est hors scope.
Scope Items — Les tâches d'implémentation spécifiques qui remplissent les ACs. Chaque scope item mappe vers un ou plusieurs ACs, créant une traçabilité bidirectionnelle.
Quality Gates — Vérifications de validation automatiques qui doivent passer avant que le code soit considéré terminé. Le quick pass (lint, typecheck sur les fichiers modifiés) tourne après chaque édition. Le full pass (lint, typecheck, build, test, registre E2E, preuve TDD) tourne avant complétion. La couverture est advisory.
Tests E2E-First — Par défaut, on écrit des tests end-to-end. Les tests unitaires sont réservés aux fonctions pures sans I/O ni effets de bord. Une hiérarchie d'évitement des mocks impose les systèmes réels (test DB, API sandbox) plutôt que les doubles de test. Mocker son propre code n'est jamais autorisé.
Anti-Cascade TDD — Protocole de correction de bugs qui empêche les fixes d'introduire de nouvelles régressions. Baseline la suite de tests complète, écrire un test de régression qui échoue (RED), implémenter le fix (GREEN), puis comparer la suite complète au baseline (DIFF). Tout nouvel échec signifie que le fix a introduit des régressions.
SKILL.md — Le format de fichier standard pour définir les skills d'agent. Tout agent de codage IA qui lit les fichiers SKILL.md peut charger et exécuter le workflow skill.
Plus d'articles sur la construction logicielle dans la catégorie Construire.
BNTVLLNT
> Je construis des systèmes d'exécution logicielle AI-native
