Préparer un projet au développement autonome, avec des validations humaines
L’ingénierie logicielle a toujours évolué, et elle change encore à l’ère du développement agentique. Ce qui n’a pas changé, c’est la qualité du code, et les quality gates qui garantissent que le code est couvert par des tests et que l’application fonctionne correctement. Je parle des tests unitaires et des tests end-to-end comme quality gates de base. En 2026, il n’y a plus d’excuse pour ne pas avoir au moins des tests unitaires pour le comportement, et encore mieux, des tests end-to-end pour le fonctionnement des fonctionnalités.
Voici mes notes et la checklist que je suis sur chaque projet que je prends en main, qu’il s’agisse d’un nouveau projet ou d’un projet existant. Le processus est le même, mais un projet existant demande plus d’attention : il y a déjà une base de code, de la dette technique, et probablement une mauvaise architecture à prendre en compte pour que les agents travaillent correctement.
Lecture rapide : l’article en une image
flowchart TB
accDescr: Les étapes 1 à 4 se font une fois par dépôt ; l'étape 5, une spec validée par un humain, se fait au niveau du projet ; ensuite commence le développement agentique autonome.
subgraph repo [Par dépôt]
audit([1. Audit : les manques]):::human --> critical([2. Fonctionnalités critiques, avec le métier]):::gate
critical --> gates(3. Quality gates et structure):::check
gates --> context([4. Fichier AGENTS minimum]):::human
end
subgraph project [Niveau projet]
spec([5. Spec validée par un humain]):::gate
end
context --> spec
spec --> dev[Développement agentique autonome]:::agent
classDef human fill:#e8f0ee,stroke:#006b56,color:#111827
classDef agent fill:#ffffff,stroke:#3d4654,color:#111827
classDef check fill:#f2f5f4,stroke:#6b7280,color:#111827
classDef gate fill:#e8f0ee,stroke:#006b56,stroke-width:2px,color:#111827
La checklist en un coup d’œil
| Étape | Ce que je fais | Ce que ça produit |
|---|---|---|
| 1. Audit | Lister ce qui existe et ce qui manque | Une liste des manques |
| 2. Fonctionnalités critiques | Définir avec le métier les fonctionnalités qui ne doivent jamais casser | Une checklist de scénarios |
| 3. Quality gates minimum et structure | Linter, tests unitaires, couverture, tests end-to-end, couches | Des scripts que les agents peuvent lancer |
| 4. Contexte pour les agents | Un fichier AGENTS minimum | Les règles et les pointeurs que les agents lisent |
| 5. Processus de spécification | Comment les specs sont écrites et validées par un humain | Des instructions claires pour les agents de développement |
Ces étapes sont nécessaires pour un pipeline entièrement automatisé, où des agents IA font l’implémentation, afin de garder l’application stable.
- Les recherches pour cet article n’ont trouvé aucune étude qui teste ces cinq étapes comme une séquence. La séquence vient de mon expérience ; les sources ci-dessous soutiennent les étapes une par une.
Sources. La documentation de Claude Code d’Anthropic dit que “in most cases, your first plain prompt in a fresh session already does the right thing, without any setup on your part”, et aussi : “If it has nothing to run that tells it whether the work actually is done, “looks done” is all it has to go on. In practice that makes you the test suite.” (Best practices for Claude Code)
1. Auditer le projet
Identifier ce que le projet a déjà comme quality gates et automatisations :
- l’architecture, la structure des dossiers et les couches (controllers, services, composants…),
- la sécurité,
- les linters,
- les tests unitaires et la couverture de code,
- les tests end-to-end, d’intégration et de performance,
- la CI/CD, et si le déploiement est manuel ou automatique,
- les agents déjà présents dans le projet,
- la dette technique connue.
Ce premier audit nous donne les manques à combler, et le plan de déploiement de l’étape 3 comme exigences minimum.
Sources.
- Google : “74.45% of the code changes and 69.46% of the edits were generated by the LLM” (Migrating Code At Scale With LLMs At Google).
- Airbnb : une migration de tests estimée à “1.5 years of engineering time” terminée en “6 weeks” ; “when a check fails, we bring in the LLM to fix it” (Accelerating Large-Scale Test Migration with LLMs).
- Birgitta Böckeler : “the harness is most needed where it is hardest to build” (Harness engineering for coding agent users).
2. Revoir les fonctionnalités critiques
Les fonctionnalités critiques sont, ou devraient être, définies avec le partenaire produit, ou quelqu’un dans l’entreprise qui connaît très bien les fonctionnalités critiques de l’application. Il faut surtout tester les fonctionnalités qui, si elles cassent, perturberaient fortement le service pour les utilisateurs. Par exemple :
- l’authentification,
- le parcours d’onboarding,
- les tunnels de vente,
- le processus de paiement.
Ces scénarios deviennent la base des tests end-to-end de l’étape 3. Ils peuvent aussi montrer le besoin d’un dispositif de tests plus complet, comme des tests de performance.
3. Planifier les quality gates minimum et la structure cible
Je planifie l’onboarding et le déploiement étape par étape. Le minimum pour démarrer un pipeline de développement entièrement automatisé :
| Quality gate | Pourquoi |
|---|---|
| Linter (et vérification des types, quand le langage en a une) | Des règles de style et de structure que l’agent ne peut pas discuter |
| Tests unitaires | Le comportement |
| Couverture de tests, avec un seuil imposé par le build | Le nouveau code arrive avec ses tests |
| Tests end-to-end sur les fonctionnalités critiques, avec des environnements dockerisés | L’application fonctionne toujours pour les utilisateurs |
| CI/CD pour les quality gates sur les PR, et le déploiement des environnements (sandbox, production) | Automatiser le processus |
Chaque quality gate vient avec un script clair, pour que les agents puissent facilement le lancer et investiguer. Passer les quality gates ne suffit pas à lui seul :
- les agents peuvent faire passer les tests sans corriger le code,
- des PR qui passent les tests échouent quand même à la revue humaine,
- donc une étape de revue reste toujours nécessaire avant de valider une PR.
La revue de code est aussi une partie clé de l’onboarding au développement agentique, car chaque retour sur les PR peut servir à l’auto-apprentissage, pour améliorer la configuration des agents.
Sources.
- Simon Willison : “If your project has a robust, comprehensive and stable test suite agentic coding tools can fly with it” (Vibe engineering).
- METR : “roughly half of test-passing SWE-bench Verified PRs written by mid-2024 to mid/late-2025 agents would not be merged into main” (Many SWE-bench-Passing PRs Would Not Be Merged into Main).
- Un agent “with access to unit tests may delete failing tests rather than fix the underlying bug” (ImpossibleBench).
La structure : où les agents écrivent le code
Par expérience, sur une application React Native qui manquait de structure et de couches d’architecture : les agents écrivaient parfois des imports d’accès à la base de données dans la couche controller, au lieu du service.
Pour ce projet, j’ai décidé de démarrer un processus de migration pour les nouvelles fonctionnalités, parce qu’une migration du backend faisait aussi partie du périmètre :
- une nouvelle structure de dossiers qui suit les couches de la clean architecture / architecture hexagonale,
- chaque nouvelle fonctionnalité va dans la nouvelle architecture,
- les fonctionnalités existantes sont migrées progressivement, avec une validation humaine,
- l’agent de revue de code a pour consigne de vérifier la structure d’architecture du nouveau code. C’est là que les imports de base de données ont été détectés et corrigés.
Un projet organisé permet aux agents de savoir où écrire le code pour chaque couche.
Sources.
- Les modèles montrent “strong accuracy for explicit, code-inferable decisions”, dans une étude des architecture decision records sur 109 dépôts (Evaluating Large Language Models for Detecting Architectural Decision Violations).
- Anthropic : “If something has to happen every time, make it a hook, a deny rule, or a managed setting” (Best practices for Claude Code).
- Böckeler : “Computational sensors catch the structural stuff reliably” (Harness engineering).
4. Mettre en place le contexte du projet pour les agents
Un fichier AGENTS minimum, et le minimum, c’est tout l’intérêt : un fichier long coûte des tokens et ne rend pas les agents meilleurs.
Ce qu’il contient, uniquement ce que le code ne montre pas déjà :
| Section | Ce qu’elle contient |
|---|---|
| Quality gates | La commande qui les lance toutes, et ce que la CI vérifie que les scripts ne vérifient pas |
| Garde-fous et blocages de sécurité | Chaque règle avec l’endroit où elle est appliquée (règle de lint, hook, CI) ; tout ce qui doit tenir à chaque fois vit là, pas dans le fichier |
| Structure du projet | Un pointeur vers la règle qui impose les couches, pas une vue d’ensemble |
| Vocabulaire métier | Là où les termes métier diffèrent des noms dans le code |
| Scripts de l’étape 3 | Seulement ceux qu’un agent ne trouverait pas dans package.json : prérequis, ports, fixtures |
| Pièges connus | Les erreurs que les agents ont déjà faites |
Sources. Une étude contrôlée de l’ETH Zurich a trouvé que “providing context files does not generally improve task success rates” tout en “increasing inference cost by over 20% on average”, que “context files are not effective at providing a repository overview”, et qu’un fichier “should only contain specific additional instructions beyond what is already available in the codebase” (Evaluating AGENTS.md).
5. Définir le processus de spécification
Les specs et le design doivent être faits avec un humain en amont. Si les specs sont claires, les agents de développement ont besoin d’instructions simples et claires.
- Une spec claire ne garantit pas qu’un agent la suive, donc les quality gates de l’étape 3 restent nécessaires.
- J’ai commencé avec GitHub Spec Kit pour de petites fonctionnalités en 2025, puis je suis passée à la BMAD Method pour des fonctionnalités de plus grande envergure.
- BMAD est plus complète, et s’inspire de la méthode Agile (“Agile AI-Driven Development”).
Sources.
- Böckeler, en essayant trois outils de spec, “frequently saw the agent ultimately not follow all the instructions” (Understanding Spec-Driven-Development).
- Le README de Spec Kit le présente maintenant comme une boîte à outils pour “SDD or any other process” (github/spec-kit).
Les étapes 1 à 4 se font par dépôt. Après plusieurs itérations, j’ai réussi à avoir des applications stables après une grosse itération de développement, avec de bons résultats sur les nouvelles PR. À ce moment-là, j’ai arrêté de gérer mes dépôts un par un, car certaines décisions viennent d’un contexte projet plus large. Donc maintenant, l’étape 5 se fait au niveau du projet, et non plus du dépôt. J’en partagerai les détails dans un prochain article.