update (#614)

Author: lacatoire

content/blog/claude-assistant-architecture-symfony-legacy.mdx

@@ -4,16 +4,16 @@ date: "2026-03-09"
 updatedAt: "2026-03-26"
 author: "Louis-Arnaud Catoire"
 category: "IA"
-excerpt: "Comment configurer Claude Code avec un CLAUDE.md qui encode tes conventions d'archi hexagonale, tes règles DDD et tes patterns Doctrine."
+excerpt: "Comment configurer Claude Code avec un CLAUDE.md qui encode vos conventions d'archi hexagonale, vos règles DDD et vos patterns Doctrine."
 image: "/images/blog/claude-symfony.webp"
 proficiencyLevel: "Expert"
 ---
 
-Tu ouvres Claude Code sur ton projet Symfony. Tu lui demandes de créer un use case. Il te génère un service avec 15 dépendances, des annotations Doctrine dans le domaine, et un contrôleur de 200 lignes. Exactement ce que tu passes tes journées à corriger en code review. Et sur un projet legacy, cette [dette technique accumulée](/article/la-dette-technique-faut-il-vraiment-en-avoir-peur) ne fait que s'aggraver si l'IA la reproduit.
+Vous ouvrez Claude Code sur votre projet Symfony. Vous lui demandez de créer un use case. Il vous génère un service avec 15 dépendances, des annotations Doctrine dans le domaine, et un contrôleur de 200 lignes. Exactement ce que vous passez vos journées à corriger en code review. Et sur un projet legacy, cette [dette technique accumulée](/article/la-dette-technique-faut-il-vraiment-en-avoir-peur) ne fait que s'aggraver si l'IA la reproduit.
 
-Le problème n'est pas Claude. C'est que Claude ne connaît pas ton architecture. Il génère du code Symfony "standard" parce que c'est ce qu'il a vu le plus souvent. Quand il s'agit de [reprise de projet Symfony](/reprise-projet-symfony), ce décalage entre le code généré et l'architecture existante est encore plus problématique. Ton archi hexagonale, tes conventions DDD, tes règles sur les repositories Doctrine : il ne les connaît pas tant que tu ne les lui expliques pas.
+Le problème n'est pas Claude. C'est que Claude ne connaît pas votre architecture. Il génère du code Symfony "standard" parce que c'est ce qu'il a vu le plus souvent. Quand il s'agit de [reprise de projet Symfony](/reprise-projet-symfony), ce décalage entre le code généré et l'architecture existante est encore plus problématique. Votre archi hexagonale, vos conventions DDD, vos règles sur les repositories Doctrine : il ne les connaît pas tant que vous ne les lui expliquez pas.
 
-La solution s'appelle `CLAUDE.md`. Un fichier à la racine de ton projet que Claude Code lit automatiquement à chaque session. C'est ton onboarding permanent. Et bien configuré, il transforme Claude en assistant qui respecte ton archi dès la première ligne de code.
+La solution s'appelle `CLAUDE.md`. Un fichier à la racine de votre projet que Claude Code lit automatiquement à chaque session. C'est votre onboarding permanent. Et bien configuré, il transforme Claude en assistant qui respecte votre archi dès la première ligne de code.
 
 ## Le CLAUDE.md minimal qui change tout
 
@@ -54,9 +54,9 @@ Avec ces dix lignes, Claude arrête de générer des contrôleurs-services et co
 
 ## Encoder les conventions Doctrine
 
-Doctrine est le point de friction numéro un entre Claude et ton archi. Par défaut, Claude traite les entités Doctrine comme des modèles domaine. Il colle des `#[ORM\Column]` partout et appelle `$entityManager->flush()` depuis les use cases.
+Doctrine est le point de friction numéro un entre Claude et votre archi. Par défaut, Claude traite les entités Doctrine comme des modèles domaine. Il colle des `#[ORM\Column]` partout et appelle `$entityManager->flush()` depuis les use cases.
 
-Ajoute une section dédiée dans ton `CLAUDE.md` :
+Ajoutez une section dédiée dans votre `CLAUDE.md` :
 
 ```markdown
 ## Doctrine
@@ -90,9 +90,9 @@ L'exemple concret est important. Claude apprend mieux par l'exemple que par la r
 
 Le DDD mal appliqué par un assistant IA donne du code pire que pas de DDD du tout. Des Value Objects partout sans raison, des Aggregates qui n'agrègent rien, des Domain Events qui ne servent à personne.
 
-Si tu as un projet legacy à faire évoluer, un [guide de migration structuré](/article/guide-de-migration-dans-un-projet-symfony) aide à définir les étapes avant même de configurer l'IA.
+Si vous avez un projet legacy à faire évoluer, un [guide de migration structuré](/article/guide-de-migration-dans-un-projet-symfony) aide à définir les étapes avant même de configurer l'IA.
 
-Sois prescriptif sur ce que tu utilises vraiment :
+Soyez prescriptif sur ce que vous utilisez vraiment :
 
 ```markdown
 ## DDD
@@ -121,11 +121,11 @@ Nommage : verbe + nom → CreateOrder, ValidateInvoice, GetProduct
 Toujours une seule méthode publique __invoke().
 ```
 
-Avec ces conventions, quand tu demandes à Claude "crée le use case pour annuler une commande", il génère un `CancelOrder` avec un `__invoke`, qui prend un `OrderId` en paramètre, appelle un port, et dispatche un `OrderCancelled`. Sans que tu aies à le guider ligne par ligne.
+Avec ces conventions, quand vous demandez à Claude "crée le use case pour annuler une commande", il génère un `CancelOrder` avec un `__invoke`, qui prend un `OrderId` en paramètre, appelle un port, et dispatche un `OrderCancelled`. Sans que vous ayez à le guider ligne par ligne.
 
 ## Les patterns de test
 
-Si tu ne dis rien sur les tests, Claude va générer des tests d'intégration avec `KernelTestCase`, une base de données SQLite, et des fixtures Doctrine. Sur un projet legacy, c'est exactement ce que tu essaies d'éliminer.
+Si vous ne dites rien sur les tests, Claude va générer des tests d'intégration avec `KernelTestCase`, une base de données SQLite, et des fixtures Doctrine. Sur un projet legacy, c'est exactement ce que vous essayez d'éliminer.
 
 ```markdown
 ## Tests
@@ -150,7 +150,7 @@ tests/
 │           └── DoctrineProductRepositoryTest.php  # KernelTestCase
 ```
 
-Claude va maintenant générer un `InMemoryProductRepository` quand tu lui demandes des tests, au lieu de monter toute la stack Symfony.
+Claude va maintenant générer un `InMemoryProductRepository` quand vous lui demandez des tests, au lieu de monter toute la stack Symfony.
 
 ## Les hooks Claude Code pour automatiser les vérifications
 
@@ -171,7 +171,7 @@ Un hook simple avec [Deptrac](https://github.com/qossmic/deptrac) qui vérifie l
 }
 ```
 
-À chaque fois que Claude modifie ou crée un fichier, Deptrac vérifie que les règles de dépendances sont respectées. Si un use case importe une classe Doctrine, le hook le signale immédiatement. Claude corrige avant même que tu aies lu le code.
+À chaque fois que Claude modifie ou crée un fichier, Deptrac vérifie que les règles de dépendances sont respectées. Si un use case importe une classe Doctrine, le hook le signale immédiatement. Claude corrige avant même que vous ayez lu le code.
 
 Combine ça avec PHPStan :
 
@@ -233,19 +233,19 @@ Quand Claude travaille dans `src/Order/`, il charge automatiquement ces règles
 
 ### Ne pas écrire un roman
 
-Un `CLAUDE.md` de 1000 lignes est contre-productif. Claude a une fenêtre de contexte limitée. Chaque ligne de `CLAUDE.md` consomme des tokens qui ne sont plus disponibles pour ton code. Sois concis. Une règle par ligne. Pas d'explications philosophiques sur pourquoi le DDD c'est bien.
+Un `CLAUDE.md` de 1000 lignes est contre-productif. Claude a une fenêtre de contexte limitée. Chaque ligne de `CLAUDE.md` consomme des tokens qui ne sont plus disponibles pour votre code. Soyez concis. Une règle par ligne. Pas d'explications philosophiques sur pourquoi le DDD c'est bien.
 
 ### Ne pas oublier les exemples
 
-Les règles abstraites sont ambiguës. "Utilise des Value Objects" peut donner n'importe quoi. Un exemple concret de Value Object tel que tu le veux dans ton projet élimine toute ambiguïté. Mets un exemple par pattern clé : un use case, un repository, un mapper, un test.
+Les règles abstraites sont ambiguës. "Utilise des Value Objects" peut donner n'importe quoi. Un exemple concret de Value Object tel que vous le voulez dans votre projet élimine toute ambiguïté. Mets un exemple par pattern clé : un use case, un repository, un mapper, un test.
 
 ### Ne pas figer les prompts système
 
-Le `CLAUDE.md` évolue avec ton projet. Quand l'équipe adopte une nouvelle convention, elle met à jour le `CLAUDE.md` dans la même PR. Traite-le comme du code : il est versionné, reviewé, et maintenu. Les [conventions de codage PHP et Symfony](/article/coding-conventions) constituent un bon point de départ pour définir le socle de règles à encoder.
+Le `CLAUDE.md` évolue avec votre projet. Quand l'équipe adopte une nouvelle convention, elle met à jour le `CLAUDE.md` dans la même PR. Traitez-le comme du code : il est versionné, reviewé, et maintenu. Les [conventions de codage PHP et Symfony](/article/coding-conventions) constituent un bon point de départ pour définir le socle de règles à encoder.
 
 ### Ne pas ignorer les cas limites du legacy
 
-Ton projet legacy a des exceptions. Des services qui ne suivent pas l'archi hexagonale parce qu'on n'a pas eu le temps de les migrer. Documente-les :
+Votre projet legacy a des exceptions. Des services qui ne suivent pas l'archi hexagonale parce qu'on n'a pas eu le temps de les migrer. Documentez-les :
 
 ```markdown
 ## Legacy (ne pas migrer)
@@ -257,7 +257,7 @@ Ne pas les refactorer sauf demande explicite :
 - App\Entity\Legacy\*
 ```
 
-Sans ça, Claude va essayer de refactorer ton code legacy en archi hexagonale à chaque fois qu'il le touche. Et tu vas passer plus de temps à annuler ses modifications qu'à avancer.
+Sans ça, Claude va essayer de refactorer votre code legacy en archi hexagonale à chaque fois qu'il le touche. Et vous allez passer plus de temps à annuler ses modifications qu'à avancer.
 
 ## Le résultat en pratique
 

content/blog/commandes-invocables-symfony-attributs-console.mdx

@@ -343,7 +343,7 @@ Si vous avez un projet Symfony en production, cette tendance est un signal clair
 
 - [Migrer du Serializer vers JsonStreamer : le guide honnête](/article/migrer-du-serializer-vers-json-streamer-le-guide-honnete) : une autre refonte majeure de Symfony 7.3+
 - [Symfony Messenger comme colonne vertébrale d'une archi hexagonale](/article/symfony-messenger-colonne-vertebrale-archi-hexagonale) : combinez commandes invocables et Messenger pour vos workers
-- [Pourquoi ton Domain ne devrait jamais connaître Symfony](/article/domain-ne-devrait-jamais-connaitre-symfony) : les DTOs `#[MapInput]` s'inscrivent dans cette philosophie
+- [Pourquoi votre Domain ne devrait jamais connaître Symfony](/article/domain-ne-devrait-jamais-connaitre-symfony) : les DTOs `#[MapInput]` s'inscrivent dans cette philosophie
 - [Les certifications Symfony, Twig & Sylius](/article/les-certifications-symfony-twig-symfony-sylius) : la Console fait partie de l'examen
 - [Documentation officielle : Console Commands](https://symfony.com/doc/current/console.html) : la référence Symfony
 - [PR originale : Invokable commands](https://github.com/symfony/symfony/pull/61748) : la PR de Kevin Bond qui a lancé le mouvement