Depuis six mois, j’utilise Claude Code quotidiennement sur des projets Symfony en production — une API B2B multi-tenant, une application e-commerce avec catalogue complexe, et un backoffice métier avec workflow d’approbation. Ce retour d’expérience n’est ni un article de présentation ni un tutoriel de démarrage : c’est une analyse honnête de ce que Claude Code change réellement dans la pratique de l’architecture Symfony en 2026.
Claude Code vs autres outils IA pour l'architecture Symfony
La première question que posent les développeurs Symfony est toujours la même : pourquoi Claude Code plutôt que Cursor ou GitHub Copilot ?
La réponse tient en une capacité différenciante : la fenêtre de contexte. Claude Code gère jusqu’à 200 000 tokens, ce qui permet de charger l’intégralité d’un src/ de taille moyenne et d’obtenir une analyse architecturale cohérente sur l’ensemble du projet. Cursor et Copilot travaillent sur des fenêtres plus petites, efficaces pour l’autocomplétion mais insuffisantes pour raisonner sur une architecture de domaine.
Pour une comparaison détaillée des trois outils sur des critères objectifs, notre comparatif Copilot, Cursor et Claude Code pour les architectes Symfony couvre les fonctionnalités, le prix et la qualité du code généré sur des cas d’usage réels.
Sur l’architecture spécifiquement, Claude Code excelle dans trois scénarios :
Analyse de cohérence architecturale : soumettez votre src/ complet et demandez à Claude Code d’identifier les violations DDD (entités qui accèdent directement aux repositories d’autres bounded contexts, services anémiques déguisés en entités, etc.). Le résultat est d’une précision remarquable sur les projets de moins de 100 000 lignes.
Génération de structures de domaine : partez d’une spécification métier en français, Claude Code produit les entités, value objects, domain events et repository interfaces en une seule itération. La qualité est suffisante pour un premier draft que vous affinez.
Documentation architecturale à rebours : sur un projet legacy sans documentation, Claude Code génère les ADR (Architecture Decision Records) en analysant le code existant. Chronophage à faire manuellement, trivial avec Claude Code.
Configuration : CLAUDE.md et MCP Server pour Symfony
La configuration qui change tout est le fichier CLAUDE.md à la racine de votre projet Symfony. Ce fichier est lu automatiquement par Claude Code en début de session et fournit le contexte persistant que vous ne devez pas répéter à chaque prompt.
Un CLAUDE.md efficace pour Symfony contient :
# Projet : [NomProjet]
## Architecture
- Pattern : DDD avec bounded contexts (cf. src/Domain/)
- CQRS via Symfony Messenger (bus commandes/queries séparés)
- Event Sourcing pour les agrégats Order et Customer
## Conventions
- Entités : immutables hors factory methods
- Value Objects : dans Domain/{Context}/ValueObject/
- Repository interfaces dans Domain, implémentations dans Infrastructure/
## Stack
- Symfony 7.2, PHP 8.3, Doctrine ORM 3.x
- PostgreSQL 16 (JSONB pour event store)
- RabbitMQ pour les events asynchrones
## Contraintes métier
- Jamais de logique dans les controllers
- Les commandes CQRS ne retournent rien (void)
- Les queries retournent des DTOs, jamais des entitésCouplé à un MCP Server filesystem (voir notre guide des MCP Servers pour développeurs Symfony), Claude Code peut lire vos fichiers en temps réel et proposer des évolutions cohérentes avec votre base de code existante sans que vous ayez à coller du code dans le chat.
Domain-Driven Design assisté par Claude Code
Le Domain-Driven Design reste difficile à apprendre et à appliquer sans un pair expérimenté pour valider les décisions de modélisation. Claude Code ne remplace pas ce pair, mais il joue efficacement le rôle de devil’s advocate architecturel.
Définition des bounded contexts
Le prompt le plus efficace que j’utilise pour initier un nouveau projet :
À partir de ces user stories (ci-jointes), identifie les bounded contexts candidats.
Pour chaque contexte, liste : les entités racines, les value objects, les domain events,
et les points de contention potentiels avec les autres contextes.
Format : une section par bounded context avec un diagramme en ASCII.Claude Code produit une première modélisation en quelques secondes. L’important est de la questionner immédiatement : “Pourquoi Order est-il dans le contexte Sales et non Fulfillment ?”. Les justifications de Claude Code révèlent rapidement si la modélisation tient compte de la réalité métier ou si elle est générique.
Génération des entités et value objects
Pour la génération de code DDD, la structure de prompt qui donne les meilleurs résultats :
Génère l'entité racine `Order` pour le bounded context `Sales`.
Contraintes : immutable après création sauf via méthodes de domaine, utilise les
value objects OrderId (UUID), Money (montant + devise), OrderStatus (enum).
Les domain events sont : OrderPlaced, OrderConfirmed, OrderShipped.
N'utilise pas d'annotations Doctrine dans l'entité — la mapping sera dans Infrastructure.Le résultat est généralement propre et respecte les conventions DDD. Les erreurs fréquentes : Claude Code oublie parfois les invariants de domaine (validation des règles métier dans le constructeur) ou génère des getters publics sur des propriétés qui devraient rester privées. Relecture obligatoire.
CQRS avec Symfony Messenger : Claude Code comme copilote
Symfony Messenger est le socle naturel du CQRS dans l’écosystème Symfony. La configuration des bus, le routage des messages et la gestion des middlewares sont des tâches où Claude Code apporte une valeur immédiate.
Configuration des bus CQRS
Partez de votre messenger.yaml existant et demandez à Claude Code de le refactorer pour séparer proprement les buses commandes, queries et events :
Voici mon messenger.yaml actuel (joint).
Refactore-le pour : (1) un bus commandes synchrone avec middleware de validation,
(2) un bus queries synchrone sans middleware de journalisation,
(3) un bus events asynchrone via transport RabbitMQ.
Ajoute les types PHP correspondants (interface Commande, interface Query,
interface DomainEvent) avec leur routing automatique via les interfaces.Claude Code génère la configuration YAML et les interfaces PHP en une réponse cohérente. La configuration du routing par interface (via Symfony\Component\Messenger\Attribute\AsMessageHandler) est particulièrement bien gérée.
Génération des handlers
Pour chaque nouvelle fonctionnalité, le workflow que j’ai standardisé :
- Rédiger la commande ou la query en PHP simple (5 lignes)
- Soumettre à Claude Code avec le contexte du domain model concerné
- Demander le handler correspondant + le test unitaire PHPUnit
- Valider avec PHPStan niveau 8 + lancer les tests
Cette approche réduit le temps d’implémentation d’une nouvelle feature de 60 à 70% sur les projets où l’architecture CQRS est bien établie. La courbe décroît sur les premières features (mise en place des patterns) et s’accélère ensuite.
Pour les développeurs qui débutent avec Symfony et veulent comprendre ces architectures progressivement, notre guide complet pour apprendre Symfony en 2026 pose les fondamentaux avant d’aborder CQRS et DDD.
Event Sourcing et Symfony : les limites de l'assistance IA
L’Event Sourcing est le domaine où les limites de Claude Code deviennent les plus visibles. Le pattern est conceptuellement bien maîtrisé par le modèle, mais les implémentations concrètes pour Symfony divergent selon les bibliothèques (EventSauce, broadway, implémentation maison), et Claude Code produit des mix incohérents.
Les problèmes concrets que j’ai rencontrés :
Incohérence de bibliothèque : Claude Code mélange parfois les APIs d’EventSauce et de broadway dans une même implémentation. Spécifiez toujours explicitement la bibliothèque et sa version.
Gestion des snapshots : les implémentations de snapshot générées sont fonctionnelles mais non optimisées. Elles relistorisent systématiquement depuis le début plutôt qu’à partir du dernier snapshot. Correction simple, mais elle révèle que Claude Code ne “voit” pas les performances réelles de votre store.
Event store sur PostgreSQL avec JSONB : la configuration Doctrine pour un event store natif JSONB est souvent incorrecte du premier coup. Claude Code propose des solutions qui fonctionnent mais qui contournent les capacités de PostgreSQL JSONB plutôt que de les exploiter.
Sur l’Event Sourcing, Claude Code reste utile pour la génération des events, la reconstruction des agrégats depuis le stream, et les projections. Mais la conception du store et les optimisations de performance restent humaines.
Workflow concret : de la spécification à l'implémentation
Voici le workflow que j’applique sur chaque nouvelle feature dans un projet Symfony avec DDD+CQRS :
Étape 1 — Spécification domaine (5-10 min)
Rédiger en français : “En tant que gestionnaire des ventes, je veux pouvoir annuler une commande jusqu’à 24h après sa confirmation, sauf si elle est en cours de préparation.”
Étape 2 — Analyse Claude Code (2-3 min)
Analyse cette user story dans le contexte de notre bounded context `Sales`
(CLAUDE.md en contexte). Identifie : l'invariant de domaine à protéger,
la commande CQRS à créer, le domain event à publier, et les side effects
potentiels sur les autres bounded contexts.Claude Code identifie généralement correctement l’invariant (“annulation impossible si statut = PREPARING”), la commande (CancelOrderCommand), l’event (OrderCancelled), et les side effects potentiels (remboursement, stock, notifications).
Étape 3 — Implémentation guidée (15-20 min)
Génération en séquence : value objects si nécessaires → méthode de domaine sur l’agrégat → commande → handler → domain event → tests unitaires. Chaque étape est validée avant de passer à la suivante.
Étape 4 — Validation (5-10 min)
PHPStan niveau 8 + tests unitaires + test d’intégration sur le handler. Claude Code corrige les erreurs PHPStan en une itération dans 80% des cas.
L’ensemble de la feature prend 30 à 45 minutes au lieu de 2 à 3 heures en mode manuel. Le gain est réel et mesurable.
Pour les développeurs qui veulent adopter ce workflow et construire leur carrière autour de ces compétences, notre guide sur devenir développeur Symfony professionnel couvre la progression recommandée de junior à architecte.
Les 5 prompts d'architecture les plus efficaces
Après six mois d’utilisation intensive, ces cinq prompts donnent les résultats les plus constants sur des projets Symfony réels :
1. Audit d’architecture existante
Analyse le répertoire src/ de ce projet Symfony (joint via MCP filesystem).
Identifie les 5 principales violations des principes DDD et SOLID que tu observes.
Pour chaque violation, explique l'impact sur la maintenabilité et propose un refactoring
concret en 3 étapes progressives.2. Génération de bounded context complet
Génère la structure complète du bounded context `[Nom]` pour ce projet Symfony.
Include : entités racines, value objects, repository interfaces, domain events,
command/query handlers (vides), et la structure de répertoires dans src/Domain/[Nom]/.
Base-toi sur les conventions de CLAUDE.md.3. Refactoring service anémique → domaine riche
Ce service `[NomService]` (joint) est anémique — il contient de la logique métier
qui devrait être dans les entités. Refactore-le en : (1) déplaçant chaque règle métier
vers l'entité correspondante comme méthode de domaine, (2) transformant le service
en ApplicationService orchestrateur, (3) générant les tests unitaires manquants.4. Analyse d’impact avant refactoring
Je veux refactorer `[Entité]` pour la rendre immutable. Analyse toutes les dépendances
dans src/ et liste : (1) les endroits où l'état est muté directement, (2) les tests
à modifier, (3) les migrations Doctrine potentiellement nécessaires.
Donne-moi une checklist de refactoring dans l'ordre de dépendance.5. Génération de tests d’architecture PHPArch
Génère les règles PHPArch pour valider que notre architecture DDD est respectée :
- Les entités Domain ne dépendent pas d'Infrastructure
- Les handlers ne retournent rien (void)
- Les queries retournent uniquement des DTOs
- Les Value Objects sont immutables (pas de setters publics)
Utilise la syntaxe PHPArch 1.x.Ces prompts donnent les meilleurs résultats lorsque Claude Code a accès au CLAUDE.md et au code source via MCP filesystem. Sans ce contexte, les réponses sont génériques et moins applicables directement.
Les enjeux liés à la transformation des équipes de développement par l’IA montrent que ces compétences d’architecture assistée par IA deviennent un avantage concurrentiel mesurable pour les équipes qui les adoptent tôt.
Limites et risques : quand ne pas faire confiance à Claude Code
Un retour d’expérience honnête ne peut pas s’arrêter aux succès. Voici les situations où Claude Code m’a coûté du temps plutôt que d’en faire gagner :
Logique métier spécifique au secteur
Claude Code n’a pas de connaissance de votre secteur d’activité. Les règles métier spécifiques (calcul de TVA pour des cas particuliers, règles de stock pour le retail, règles de compliance financière) doivent venir de vous. Le modèle les implémente bien quand vous les lui donnez précisément, mais il ne les invente pas correctement.
Optimisation de performance Doctrine
Les requêtes Doctrine générées par Claude Code sont fonctionnellement correctes mais rarement optimisées. Les problèmes N+1, le manque d’index hints, et les jointures inutiles apparaissent systématiquement. Toujours passer les requêtes critiques dans EXPLAIN ANALYZE avant de les intégrer.
Sécurité et données sensibles
Claude Code génère du code qui respecte les bonnes pratiques de sécurité standards (CSRF, XSS, injection SQL via Doctrine). Mais il ne connaît pas vos contraintes de sécurité spécifiques (normes internes, exigences client, régulations sectorielles). Ne déléguez jamais la conception de la sécurité à Claude Code sans relecture par un expert.
Décisions d’architecture irréversibles
Les décisions comme le choix d’un event store, la stratégie de versioning des events, ou la granularité des bounded contexts ont des conséquences sur plusieurs années. Claude Code propose des solutions souvent raisonnables, mais il ne vit pas avec les conséquences de ses recommandations. Ces décisions doivent rester humaines, éclairées mais non déléguées.
Pour approfondir les enjeux de sécurité des outils IA en entreprise et construire une politique d’utilisation adaptée à votre contexte, des ressources spécialisées complètent utilement ce retour terrain.
L’avenir du développeur Symfony n’est pas de déléguer l’architecture à l’IA — c’est de devenir un meilleur architecte en utilisant l’IA pour itérer plus vite sur les décisions. Notre analyse sur l’avenir du développeur web face à l’intelligence artificielle explore cette transformation en profondeur.
En résumé : Claude Code est un outil de productivité architecturale réel pour les projets Symfony complexes, à condition de l’utiliser avec méthode (CLAUDE.md, MCP Server, prompts précis) et sans lui déléguer les décisions critiques. Le gain de productivité sur les tâches d’implémentation et de génération de structure est de l’ordre de 50 à 70%. La qualité de l’architecture reste votre responsabilité.