Skip to content
Retour à Tech
GenAI · 11 min de lecture

Patterns de développement agentique — Construire du logiciel avec des agents IA

Patterns et workflows pratiques pour le développement logiciel agentique avec Claude Code, Cursor et des LLMs locaux — des workstreams parallèles aux usines d'agents nocturnes.

Patterns de développement agentique

Ma façon de construire du logiciel a fondamentalement changé. Au lieu d’écrire chaque ligne moi-même, j’orchestre désormais des agents IA qui gèrent l’implémentation pendant que je me concentre sur l’architecture, les spécifications et la qualité. Il ne s’agit pas de remplacer les développeurs — il s’agit d’amplifier ce qu’un développeur seul (ou une petite équipe) peut accomplir.

Après plus de 25 ans d’écriture de code, je peux affirmer avec certitude que c’est le plus grand gain de productivité que j’ai connu — plus important que le passage à l’agile, plus important que le cloud, plus important que le CI/CD. Voici les patterns qui fonctionnent.

Mon stack de développement

Principal : Claude Code (abonnement Max)

Claude Code est un outil CLI qui fonctionne comme un agent de codage autonome. Il lit les fichiers de votre projet, comprend le contexte via les spécifications CLAUDE.md, et exécute des tâches d’implémentation en plusieurs étapes : création de fichiers, édition de code, exécution de tests, correction d’erreurs, commits git.

Pourquoi c’est mon outil principal :

  • Compréhension profonde de la codebase : il lit et indexe l’ensemble de votre projet, pas seulement le fichier courant
  • Exécution autonome : confiez-lui une tâche, partez, revenez avec une implémentation fonctionnelle
  • Intégration CLAUDE.md : les spécifications au niveau projet guident chaque interaction sans répétition
  • Utilisation d’outils : il exécute des commandes shell, lit des fichiers, recherche dans le code — le cycle de développement complet
  • Conscience git : il crée des commits, comprend les branches, respecte votre workflow

Je lance mes sessions Claude Code dans tmux pour qu’elles persistent après la fermeture du terminal. Plusieurs sessions dans différents panneaux, chacune travaillant sur un worktree différent.

Secondaire : Cursor Pro (mode Agent)

Cursor complète Claude Code pour les tâches où le contexte visuel compte :

  • Revue de code : voir les diffs inline avec la coloration syntaxique est plus rapide que la revue en terminal
  • Travail UI : pour construire des composants frontend, voir le code et le résultat côte à côte
  • Exploration de refactoring : le mode agent pour “essaie ça de trois manières différentes et laisse-moi comparer”
  • Éditions rapides : pour des modifications petites et ciblées où lancer une session Claude Code serait excessif

Tertiaire : LLMs locaux (Qwen3-Coder via MLX/Ollama)

Pour les requêtes rapides, le travail hors ligne et le code sensible qui ne doit pas quitter ma machine :

  • Explications de code et consultations de documentation
  • Suggestions de refactoring simples
  • Brainstorming et rubber-ducking
  • Traitement de code propriétaire ou de données que je ne veux pas envoyer à des API cloud

Patterns fondamentaux

Pattern 1 : Développement piloté par les spécifications

Le pattern le plus important. Au lieu d’écrire du code, écrivez des spécifications détaillées et laissez les agents implémenter selon celles-ci.

# CLAUDE.md (ou spécification de tâche)

## Fonctionnalité : Tableau de bord des exceptions workflow

### Exigences
- Vue tableau avec colonnes triables : Type d'exception, Client, Montant, Ancienneté, Statut
- Barre de filtres avec menus déroulants multi-sélection pour chaque colonne
- Clic sur une ligne pour ouvrir le panneau de détail (glissement depuis la droite)
- Le panneau de détail affiche : détails de l'exception, piste d'audit, boutons d'action
- Actions : Approuver, Rejeter, Escalader, Réassigner

### Contraintes techniques
- Utiliser le composant DataTable existant de src/components/ui/
- Gestion d'état via Zustand store (pattern dans src/stores/)
- Appels API via React Query (pattern dans src/hooks/)
- Respecter les design tokens Tailwind existants

### Critères d'acceptation
- Toutes les colonnes triables ascendant/descendant
- Les filtres persistent à travers la navigation
- Le panneau de détail s'anime depuis la droite (300ms ease-out)
- États de chargement et d'erreur gérés
- Tests unitaires pour le Zustand store

La spécification devient le contrat entre l’intention humaine et l’exécution machine. J’ai constaté que 30 minutes passées à écrire une spécification claire économisent plus de 3 heures d’allers-retours avec les agents. La spécification me force à réfléchir clairement avant que l’implémentation ne commence — une discipline qui améliore les résultats, que ce soient des humains ou des agents qui écrivent le code.

Pattern 2 : Workstreams agents parallèles

En utilisant des git worktrees, je lance plusieurs agents simultanément sur des fonctionnalités indépendantes. Chaque agent dispose de son propre environnement isolé — sa propre branche, son propre répertoire de travail, zéro interférence avec les autres.

# Mise en place des workstreams parallèles
git worktree add ../project-feature-a feature/dashboard-redesign
git worktree add ../project-feature-b feature/api-v2-migration
git worktree add ../project-feature-c feature/test-coverage

# Terminal 1 : Claude Code sur la feature A
cd ../project-feature-a && claude

# Terminal 2 : Claude Code sur la feature B
cd ../project-feature-b && claude

# Terminal 3 : Cursor mode agent sur la feature C
# Ouvrir ../project-feature-c dans Cursor

Je lance typiquement 2-3 workstreams parallèles pendant les sessions de travail concentré. Chaque agent travaille sur une fonctionnalité indépendante sans état partagé. Je bascule entre les panneaux pour vérifier la progression, fournir des indications quand les agents sont bloqués, et examiner le travail terminé.

Discipline clé : les fonctionnalités doivent être véritablement indépendantes. Si deux agents doivent modifier les mêmes fichiers, ils créeront des conflits de merge qui annulent les gains de productivité. Planifiez votre décomposition du travail en conséquence.

Pattern 3 : L’usine d’agents nocturne

Mon pattern à plus fort levier. Avant de terminer la journée :

  1. Écrire les spécifications pour 2-3 fonctionnalités ou tâches
  2. Créer les worktrees et branches pour chacune
  3. Lancer les sessions Claude Code dans des panneaux tmux avec des instructions claires
  4. Dormir
  5. Revue matinale : évaluer les résultats, corriger les problèmes, merger ce qui est bon

Ce que j’ai appris pour que ça fonctionne :

  • Des spécifications complètes sont non négociables. Des instructions vagues produisent des résultats vagues pendant la nuit sans possibilité de clarification.
  • Des suites de tests sont essentielles. Les agents ont besoin de validation automatisée pour s’autocorriger. Si votre projet a de bons tests, les agents peuvent itérer jusqu’au vert. Sinon, vous obtenez du code non testé.
  • Des tâches bien délimitées fonctionnent le mieux. “Implémenter cet endpoint API avec ces 5 tests” réussit pendant la nuit. “Redessiner l’architecture” non.
  • Attendez-vous à un taux de réussite de 70-80%. Peut-être 2 tâches nocturnes sur 3 produisent du code livrable. La troisième nécessite des ajustements. C’est quand même un levier énorme.

Pattern 4 : Revue de code assistée par agent

Utiliser un agent pour implémenter et un autre pour examiner :

  1. L’agent de fonctionnalité implémente un changement
  2. L’agent de revue lit le diff et la spécification
  3. L’agent de revue identifie les problèmes : cas limites manquants, incohérences avec les patterns de la codebase, bugs potentiels
  4. L’agent de fonctionnalité traite le feedback

Cela crée une forme de pair programming IA où les désaccords entre agents font souvent surface des problèmes de conception réels. Ce n’est pas parfait — les deux agents peuvent partager les mêmes angles morts — mais ça détecte un nombre surprenant de vrais problèmes.

Pattern 5 : Délégation progressive

Tout ne devrait pas être piloté par des agents. Ma hiérarchie :

Type de tâcheApprocheOutil
Décisions d’architecturePilotée par l’humain, conseillée par l’IATableau blanc + chat Claude
Logique métier complexePilotée par l’humain, implémentée par l’agentClaude Code avec spécification détaillée
Fonctionnalités standardPilotée par l’agent, examinée par l’humainClaude Code autonome
Boilerplate / CRUDPilotée par l’agent, revue légèreClaude Code ou Cursor agent
Tests à partir de code existantPilotée par l’agent, vérification de passageClaude Code
DocumentationPilotée par l’agent, revue minimaleClaude Code
RefactoringPiloté par l’agent, revue du diffCursor mode agent

L’insight clé : adapter le niveau d’implication humaine au niveau de jugement requis. Ne perdez pas votre temps à écrire manuellement des endpoints CRUD. Ne déléguez pas l’architecture de sécurité à un agent.

Pattern 6 : CLAUDE.md comme documentation vivante

Votre fichier CLAUDE.md n’est pas un artefact ponctuel — il évolue avec le projet :

  • Jour 1 : Vue d’ensemble du projet, stack technique, structure des fichiers
  • Semaine 1 : Ajouter les conventions de codage apprises des premiers résultats agents (“Pas d’exports par défaut”, “Toujours utiliser des fonctions nommées”)
  • Mois 1 : Inclure les patterns courants, les décisions architecturales et les anti-patterns à éviter
  • En continu : Mettre à jour lors de l’ajout de nouvelles bibliothèques, du changement de patterns, ou de l’apprentissage des erreurs des agents

Chaque correction que vous apportez à la production d’un agent devrait être réinjectée dans le CLAUDE.md sous forme de règle. Au fil du temps, les agents font moins d’erreurs car la spécification s’améliore. C’est un effet volant d’inertie.

Ce qui fonctionne et ce qui ne fonctionne pas

Les agents excellent dans

  • Boilerplate et CRUD : générer des patterns standards, endpoints API, schémas de base de données, composants de formulaire
  • Génération de tests : écrire des tests unitaires et d’intégration à partir de code existant
  • Refactoring : renommer, restructurer, appliquer des patterns cohérents à travers une codebase
  • Conversion de formats : migrer entre frameworks, mettre à jour des versions d’API, convertir entre langages
  • Documentation : générer de la documentation à partir du code, fichiers README, documentation API
  • Implémenter des fonctionnalités bien spécifiées : quand la spécification est claire, les agents livrent de manière fiable
  • Apprendre de nouveaux frameworks : agent + documentation = montée en compétence plus rapide que lire la doc soi-même

Les agents peinent avec

  • Décisions d’architecture nouvelles : ils savent implémenter des patterns mais ne devraient pas les choisir
  • Exigences ambiguës : données en entrée médiocres, résultats médiocres — des spécifications vagues produisent des implémentations vagues
  • Logique métier profonde : des règles métier qui nécessitent le contexte organisationnel et l’empathie avec les parties prenantes
  • Optimisation de performance : ils optimisent pour la correction, pas toujours pour l’efficacité
  • Sécurité : ne jamais faire confiance au code généré par un agent pour les chemins critiques en matière de sécurité sans revue approfondie
  • Coordination à grande échelle : des changements multi-services avec des dépendances complexes nécessitent encore une orchestration humaine

La réalité de la productivité

Pour un développeur expérimenté qui investit dans l’apprentissage de ces patterns, le multiplicateur est réel :

  • Vitesse d’implémentation : 5-10x pour les fonctionnalités bien spécifiées
  • Couverture de tests : 3-5x plus de tests écrits car le coût marginal tend vers zéro
  • Cohérence du code : plus élevée, car les agents suivent les conventions CLAUDE.md plus fidèlement que les humains ne suivent les guides de style
  • Débit total : un développeur seul avec des outils agentiques égale la production d’une équipe de 3-4 personnes pour de nombreuses charges de travail

Mais le multiplicateur dépend entièrement de la qualité des spécifications et de l’infrastructure du projet (tests, CI, architecture claire). Un agent opérant dans une codebase bien structurée avec de bonnes spécifications et de bons tests est 10x. Un agent dans une codebase désordonnée sans spécifications ni tests est 1x — ou pire, car vous déboguez du spaghetti généré par un agent.

Le rôle en évolution du développeur

Le plafond de compétences a augmenté, pas diminué. Vous devez être un meilleur ingénieur pour diriger efficacement des agents IA que pour écrire du code manuellement :

  • Meilleur en spécification : des spécifications claires produisent du code clair
  • Meilleur en architecture : les agents implémentent votre conception ; la conception doit toujours être bonne
  • Meilleur en revue de code : vous examinez plus de code, plus vite, avec des enjeux plus élevés
  • Meilleur en décomposition : découper le travail en morceaux indépendants, adaptés aux agents, est une compétence
  • Meilleur en jugement qualité : savoir distinguer “suffisamment bon” de “nécessite plus de travail” en examinant la production d’un agent

Les développeurs qui peinent avec les outils agentiques sont souvent ceux qui sautent l’étape de spécification, n’examinent pas attentivement la production de l’agent, ou essaient d’utiliser les agents pour des tâches nécessitant un jugement profond. Ceux qui prospèrent traitent les agents comme des développeurs juniors extrêmement compétents qui ont besoin de directions claires et d’une revue de code approfondie.

agentic-developmentclaude-codecursorllmdeveloper-toolsworkflow