Une application Symfony traite commandes, tarifs, factures et support dans le même déploiement. Après une panne sur un export comptable, le comité conclut que le monolithe est devenu trop gros et demande des microservices. Le problème vient pourtant d’une requête sans limite et d’un module facturation accessible depuis partout. Distribuer le code déplacerait cette confusion sur le réseau sans donner de propriétaire aux données ni à la reprise.
Ce qui compte vraiment n’est pas la taille du dépôt. Il faut vérifier si une équipe peut modifier une capacité sans parcourir toute l’application, si une transaction reste compréhensible et si le support retrouve la causalité d’un échec. Un monolithe bien tenu réunit processus et déploiement, mais sépare vocabulaire, règles et dépendances. Un monolithe désordonné partage simplement toutes ses décisions.
Paradoxalement, la distribution ajoute d’abord des états à exploiter : appels partiels, versions de contrats, files, délais et données dupliquées. Elle devient rentable quand une contrainte indépendante — charge, disponibilité, cadence ou responsabilité — compense ce coût. Avant ce seuil, des modules explicites dans un même processus peuvent offrir davantage d’autonomie qu’une constellation de services reliés oralement.
Dans un développement web sur mesure, la trajectoire prudente consiste à modulariser avant d’extraire. Cette méthode expose les frontières, mesure les dépendances et prépare les données. Elle permet de conserver le monolithe lorsque ses avantages restent nets ou d’isoler une capacité sans réécrire le produit.
Distinguer monolithe, désordre et modularité
Observer le changement plutôt que le nombre de classes
Un monolithe signifie que les capacités s’exécutent et se déploient principalement ensemble. Il ne dit rien de leur organisation interne. Le diagnostic suit trois changements récents : combien de modules ont été touchés, quelles tables ont été écrites et quelles équipes ont dû se coordonner. Une modification locale qui exige dix validations révèle un couplage plus sûrement qu’un diagramme volumineux.
Les signaux faibles apparaissent lorsque les imports traversent les namespaces, lorsque toute entité possède des relations vers toutes les autres ou lorsqu’un listener modifie un domaine sans contrat. La compilation continue peut rester verte pendant que l’autonomie disparaît. L’équipe mesure donc les dépendances et les chemins de changement, pas seulement la couverture de tests.
Nommer un module par sa responsabilité
Commande, facturation, catalogue ou identité décrivent des capacités ; Controller, Service ou Entity décrivent des mécanismes. Le premier découpage rend les discussions métier possibles. Chaque module annonce ce qu’il possède, les commandes qu’il accepte, les informations qu’il publie et les dépendances qu’il consomme.
Rendre visible le coût d’une distribution
Un appel local devient un contrat réseau avec timeout, authentification, version et observabilité. Une transaction devient une orchestration avec états intermédiaires et compensation. Une recherche devient une projection ou un agrégat traversant plusieurs sources. Ces coûts peuvent être justifiés, mais ils existent avant la première amélioration métier.
Le coût complet comprend pipelines, environnements, secrets, alertes, astreinte, capacité et gouvernance de schémas. Une petite équipe peut perdre davantage de temps à maintenir cette plateforme qu’à faire évoluer le produit. Le calcul compare le délai et les incidents actuels au coût durable de l’autonomie promise.
Ne pas confondre processus et service indépendant
Déployer deux conteneurs sur le même cluster avec une base partagée ne crée pas deux services autonomes. L’un peut toujours casser le schéma de l’autre. La séparation devient réelle lorsque propriété des données, contrat, mise en production et reprise sont attribués.
Tracer des frontières métier dans le même dépôt
Chaque module possède son espace de noms, ses cas d’usage, ses règles et ses adaptateurs. L’interface publique reste courte : commandes, requêtes ou événements métier. Une classe d’un autre module n’accède pas directement aux détails de persistance. Cette règle peut être contrôlée par un test d’architecture et par la revue de code.
Le conteneur de services Symfony rend les dépendances visibles et permet des alias ou décorateurs. La documentation officielle du conteneur décrit l’assemblage et l’injection. Le conteneur ne crée toutefois aucune frontière à lui seul : l’équipe doit limiter les services exposés et refuser les injections croisées opportunistes.
Garder une traduction entre deux vocabulaires
Le module facturation ne réutilise pas aveuglément l’entité Commande. Il reçoit une référence, des lignes facturables et un mandat. Cette traduction absorbe les différences de cycle de vie. Elle réduit le risque qu’un changement commercial modifie silencieusement les règles comptables.
Contrôler les dépendances entre modules
Une carte orientée montre qui connaît qui. Les cycles sont traités en priorité, car ils empêchent l’extraction et brouillent la responsabilité. Un échange synchrone reste acceptable pour une décision immédiate ; un événement convient à une information passée qui peut être consommée plus tard. Choisir un événement uniquement pour supprimer une flèche déplace le couplage dans le temps.
Les dépendances partagées — fichiers utilitaires, exceptions génériques, entités communes — paraissent innocentes. Elles forment souvent le vrai noyau rigide. L’équipe distingue un socle technique stable d’un modèle métier prétendument commun. Deux modules peuvent utiliser la même notion de client avec des attributs et des règles différents.
Faire échouer la CI sur une violation
Un test d’architecture peut interdire l’accès de Facturation à InfrastructureCommande ou imposer un sens entre couches. La règle est simple, versionnée et accompagnée d’une exception temporaire avec échéance. Un diagramme sans contrôle finit par décrire l’intention plutôt que le dépôt réel.
Conserver les transactions utiles au métier
Le monolithe peut protéger un invariant dans une transaction de base : réserver le stock et confirmer la commande, enregistrer une facture et ses lignes, ou attribuer un numéro unique. Cet avantage réduit les états intermédiaires. Le découpage ne doit pas abandonner cette propriété sans définir l’attente, la compensation et le statut visible.
Les transactions ne doivent pas englober un appel HTTP lent. L’application valide et écrit son état local, puis publie un travail sortant de manière fiable. Une table outbox peut relier l’écriture et la publication. Le consommateur traite plusieurs livraisons sans produire plusieurs effets.
Exposer l’état inconnu
Après un timeout, l’absence de réponse ne prouve pas l’échec. Le modèle distingue à transmettre, en cours, confirmé, refusé et résultat inconnu. Le support rapproche la référence avant toute relance. Cette sémantique reste nécessaire dans un monolithe comme dans un système distribué.
Déployer un ensemble sans tout coupler
Un seul artefact peut contenir des modules dont les fonctionnalités sont activées progressivement. Les migrations restent compatibles avec la version précédente ; les nouvelles lectures sont introduites avant le retrait de l’ancien champ. Un drapeau permet de basculer un flux sans dupliquer les règles.
La suite de tests est organisée par capacité et par contrat. Une modification Catalogue n’a pas besoin d’exécuter uniquement des tests unitaires ; elle déclenche aussi les contrats des consommateurs affectés. La CI peut paralléliser ces groupes sans prétendre que le déploiement est indépendant.
Réduire le rayon d’un incident
Le mode dégradé coupe l’export lourd sans arrêter la prise de commande. Des limites de concurrence et des files distinctes empêchent une tâche secondaire de saturer les workers critiques. La séparation opérationnelle peut donc progresser avant la séparation réseau.
Cas concret : isoler la facturation d’une commande
Cas concret hypothétique. Une plateforme B2B facture une commande après validation logistique. Le code actuel calcule la TVA dans le contrôleur, lit des remises depuis Commande et écrit directement les tables comptables. Une évolution de promotion modifie deux fois les montants. Le support ne sait pas quelle version a produit le document.
L’équipe crée un module Facturation. Il accepte une commande « ÉmettreFacture » contenant la référence commerciale, les lignes figées, le pays fiscal et la version tarifaire. Le module possède numérotation, taxes et documents. Commande reçoit seulement l’identifiant et l’état de facturation. La même base reste utilisée, mais les écritures croisées sont interdites.
Le pilote porte deux cents factures de test et vingt cas de correction. Le seuil local exige zéro écriture directe hors module, zéro numéro dupliqué et une explication de l’écart en moins de quinze minutes à partir du journal. Un cycle de dépendance ou un montant inexpliqué bloque l’extension. Ces seuils qualifient ce pilote, pas tous les monolithes.
Préparer sans promettre l’extraction
Les contrats et la propriété des données rendent une extraction possible, mais le comité ne la finance que si une contrainte apparaît. La modularisation produit déjà des gains de compréhension et de test. L’absence d’extraction n’est donc pas un échec du chantier.
Préparer les données à une séparation éventuelle
Un module identifie les tables ou colonnes qu’il possède et les lectures qu’il expose. Les autres capacités ne joignent pas librement ces tables pour prendre une décision. Une vue de lecture ou une requête publique peut fournir les informations nécessaires. Les rapports transverses utilisent une projection adaptée.
La séparation future exige des identifiants stables, des événements versionnés et une stratégie de synchronisation. Elle n’exige pas de dupliquer immédiatement toute donnée. L’équipe commence par éliminer les écritures étrangères et documenter les besoins de cohérence.
Mesurer les requêtes transverses
Les usages qui traversent les modules sont recensés avant toute extraction. Un écran de synthèse peut tolérer une projection décalée ; une validation de crédit peut exiger une lecture actuelle. La décision de stockage suit cette tolérance plutôt qu’une règle absolue.
Traiter performance et capacité sans découpage réflexe
Une requête lente ne devient pas plus rapide parce qu’elle traverse une API. Le diagnostic examine plan SQL, volume chargé, cache, sérialisation et concurrence. Une optimisation locale ou un worker dédié résout souvent le problème sans introduire un contrat distribué.
L’extraction est pertinente quand une capacité possède un profil de charge indépendant et que son isolation protège le reste. Un moteur de génération documentaire peut nécessiter beaucoup de CPU, tandis que la commande reste légère. Il peut être séparé avec une file et un stockage de résultat sans déplacer les règles de facturation.
Qualifier un seuil de capacité
Le pilote augmente progressivement le volume et observe latence, saturation et file. Le seuil local correspond au point où l’objectif métier n’est plus tenu malgré les optimisations raisonnables. Il doit être mesuré sur l’infrastructure cible et révisé après chaque changement majeur.
Aligner l’architecture sur l’autonomie des équipes
Une architecture distribuée demande des équipes capables de posséder code, déploiement, données et astreinte. Si une plateforme centrale doit approuver chaque changement, les services ne créent pas d’autonomie. Ils ajoutent des files de coordination. Le monolithe modulaire peut alors offrir un flux de livraison plus court.
Les responsabilités sont attribuées par capacité, même dans le même dépôt. Une équipe relit les changements sur ses contrats et répond des incidents. Le collectif partage l’outillage, la sécurité et les conventions. Cette combinaison évite de répliquer les fondations dans chaque microservice.
Savoir quand le monolithe reste le meilleur compromis
Il convient à une équipe compacte, à des règles fortement transactionnelles et à un produit dont les capacités évoluent ensemble. Il simplifie le développement local, la recette de bout en bout et le diagnostic. Sa simplicité opérationnelle est une qualité tant qu’elle ne masque pas les frontières.
Il devient insuffisant quand une capacité exige une disponibilité, une charge ou une cadence réellement indépendante, ou lorsqu’une équipe peut la posséder de bout en bout. Même alors, l’extraction commence par le module le mieux borné. Un grand programme de découpage simultané multiplie les inconnues.
Erreurs fréquentes d’un monolithe mal tenu
Partager toutes les entités
Les relations ORM deviennent un raccourci entre domaines. Une modification charge des graphes imprévus et donne à chacun le droit d’écrire partout. Les modules échangent des références et des contrats plutôt que leurs objets internes.
Créer une couche « commun » sans propriétaire
Tout code difficile à placer rejoint un dossier partagé. Chaque module en dépend et aucune équipe ne peut le faire évoluer. Le socle commun doit rester technique et stable ; une notion métier appartient à une capacité ou reçoit un contrat explicite.
Extraire pour résoudre un conflit d’équipe
Un service ne corrige pas une responsabilité floue. Sans propriété et conventions, le conflit se transforme en incidents de contrat. Le comité attribue d’abord la décision, puis choisit le mécanisme.
Décider une extraction avec des preuves
La matrice examine autonomie d’équipe, charge indépendante, disponibilité, fréquence de changement, sensibilité des données et besoin transactionnel. Chaque critère cite une mesure. Une extraction doit résoudre une contrainte identifiée, pas seulement améliorer un dessin.
Le bloc de décision propose trois verdicts : garder et renforcer le module, isoler opérationnellement dans le même déploiement, ou extraire un service. Le troisième exige un contrat testé, une source de données, une reprise et un budget d’exploitation. Si ces conditions manquent, l’extraction est différée.
- D’abord, conserver le module si les transactions et la cadence communes produisent encore un coût net inférieur.
- Ensuite, isoler workers, ressources ou déploiement progressif lorsque seule la capacité opérationnelle diverge.
- Puis, extraire si une équipe possède le contrat, les données, le monitoring et le rollback.
- Enfin, refuser le découpage tant que l’état intermédiaire et la reprise restent sans responsable.
Plan d’action pour modulariser sans rupture
Semaines une et deux : cartographier
L’équipe choisit une capacité douloureuse, relève changements récents, tables écrites, dépendances et incidents. Elle nomme un propriétaire métier et un responsable technique. Les entrées, sorties et invariants sont validés sur des dossiers réels.
Semaines trois et quatre : fermer la frontière
Les cas d’usage rejoignent un namespace dédié. Les écritures étrangères sont remplacées par des contrats ; la CI interdit les nouvelles violations. Les tests couvrent refus, transaction et erreur externe. La journalisation ajoute module et corrélation.
Semaines cinq et six : éprouver le run
Le pilote active la nouvelle frontière sur un périmètre limité. Le monitoring suit erreurs, latence et appels transverses. Le support exécute le runbook et le rollback. Les seuils d’extension sont comparés aux mesures avant l’élargissement.
Semaine sept : décider la suite
Le comité conserve le module, poursuit la fermeture ou prépare une extraction. Le dossier décrit responsabilités, dépendances, contrat, données, instrumentation, seuil et repli. Chaque dette acceptée reçoit une échéance. La prochaine décision part de cette preuve, pas de la préférence architecturale du moment.
La répétition finale coupe le relais outbox après l’écriture, redémarre un worker et rejoue une requête transversale pendant la charge. Le support doit retrouver la corrélation, vérifier l’état de facturation et choisir une reprise sans requête SQL libre. Le test contrôle ainsi la frontière dans les conditions où les dépendances invisibles deviennent habituellement coûteuses.
Le rapport compare le temps de changement, le nombre d’écritures étrangères, les défauts échappés et le temps de diagnostic avant et après le pilote. Il ne promet pas une productivité générale à partir d’un seul module. Si les résultats restent ambigus, l’équipe conserve le périmètre limité et prolonge l’observation au lieu d’engager une extraction irréversible.
Une revue de sécurité vérifie enfin qu’un contrat public ne contourne pas les permissions et qu’une projection ne révèle pas les données d’un autre périmètre. Le module doit appliquer la même politique depuis le web, la console et les workers. Cette vérification évite qu’une frontière technique propre introduise une faille métier au moment où les lectures transverses sont réorganisées.
- D’abord, décider si les transactions communes restent un avantage à conserver.
- Ensuite, isoler les ressources lorsque seule la capacité opérationnelle diverge.
- Puis, extraire uniquement si contrat, données, monitoring et rollback possèdent un responsable.
Guides complémentaires pour tenir les frontières
Organiser le domaine
Organiser un domaine Symfony qui grossit approfondit capacités, dépendances et conventions de dépôt.
Faire suivre l’architecture par les flux
Choisir une architecture qui suit les flux aide à confronter les frontières au travail réel.
Tester les exceptions
Tester un workflow métier complète les contrats avec les refus, délais et reprises.
- Mesurer les écritures croisées et les cycles avant de déplacer du code.
- Isoler le module dans le dépôt avant de financer son extraction réseau.
- Vérifier propriété des données, monitoring et retour arrière avec les opérations.
Conclusion : distribuer seulement la contrainte
Un monolithe Symfony peut rester une architecture solide lorsque ses modules possèdent leurs règles, leurs données et leurs contrats. Le déploiement commun évite alors de nombreux états intermédiaires.
La distribution devient utile quand une capacité présente une contrainte autonome et qu’une équipe peut l’exploiter de bout en bout. Elle n’est pas une récompense accordée à un dépôt devenu volumineux.
Modulariser d’abord produit une valeur immédiate et prépare toutes les options. Le comité peut renforcer le monolithe, isoler une charge ou extraire un service à partir de preuves.
Dawap peut cartographier les dépendances, fermer une première frontière et éprouver sa reprise dans le cadre d’un accompagnement en développement web sur mesure adapté au produit et à l’équipe.
