Symfony chez Digitz
Symfony répond à un besoin que le contenu ne couvre plus. Le client ne veut plus publier des pages, il veut faire tourner un métier : suivre des dossiers, appliquer des règles de gestion qui changent selon le client et la date, calculer des droits, orchestrer des étapes de validation, parler à un ERP qui n'a pas été pensé pour le web. Là, le CMS atteint sa limite. On peut le forcer à coups de plugins et de champs ajoutés un à un, mais on empile une dette qui se paiera au premier changement de règle. C'est le terrain de Symfony.
On documente ce qu'on produit. Pas l'inverse.
Symfony est un framework PHP. Un socle sur lequel on écrit l'application qui correspond exactement à ce que le métier fait. La distinction n'est pas cosmétique. Avec un CMS, on part d'un logiciel existant et on l'adapte tant qu'on peut, en restant prisonnier de ses choix de départ. Avec Symfony, on part du besoin et on assemble ce qu'il faut, rien de plus. Ce qui varie d'un projet à l'autre, ce sont les entités du métier, les règles de gestion, les rôles et leurs droits, les systèmes auxquels il faut se connecter : tout ça s'écrit ligne à ligne. Le code qui sort, c'est votre métier traduit en logique, taillé à sa forme exacte.
C'est aussi ce qui le sépare nettement de deux voisins qu'on entend souvent dans la même phrase. WordPress est un CMS éditorial : il excelle à publier, organiser et faire vivre du contenu, et quand c'est ça le besoin, on le choisit sans hésiter. React vit côté navigateur : il sert à construire des interfaces réactives, des écrans qui réagissent au clic sans recharger la page. Symfony, lui, tient le back et l'applicatif. Il porte la logique, les données, les règles, la sécurité des accès. Les trois ne se concurrencent pas, ils occupent des étages différents. Confondre les étages, c'est se retrouver avec un CMS qui simule une application ou un front qui cache un back inexistant.
Le parti pris qu'on tient sur Symfony : la structure d'abord, la fonctionnalité ensuite. Un framework de cette taille n'a d'intérêt que si on respecte sa discipline. On modélise le domaine avant d'écrire la première route, on isole la logique métier des détails techniques, on s'appuie sur l'injection de dépendances et sur Doctrine pour que la base de données reste un détail d'implémentation et pas le centre de gravité du projet. Le bus de messages encaisse les traitements lourds en tâche de fond, les formulaires et la couche de sécurité gèrent la validation et les droits sans qu'on réinvente la roue. Le code qui en résulte se lit. Une nouvelle personne ouvre le projet et retrouve les entités du métier nommées comme le client les nomme, les règles regroupées là où on les cherche, des tests qui décrivent le comportement attendu. C'est long à poser et ça paie sur la durée.
Cette durée, c'est le cœur du sujet. On sort Symfony pour livrer une base qui tiendra pendant que le métier évolue. Une application de gestion vit cinq, dix ans. Pendant ce temps, les règles changent, un module s'ajoute, un service tiers est remplacé, une équipe interne reprend la main, la charge grimpe parce que l'activité a grandi. Un développement écrit à la va-vite devient vite illisible et chaque évolution coûte de plus en plus cher, jusqu'au jour où plus personne n'ose y toucher. C'est exactement la dette qu'on cherche à éviter. Symfony bien employé garde le code modulaire : on change une règle sans tout casser, on remplace un composant sans réécrire le reste, on monte une version majeure du framework parce que la structure a été pensée pour ça. La dette ne disparaît jamais tout à fait, mais elle reste sous contrôle, visible, payable au fur et à mesure, par petites touches.
Ce qu'on construit en Symfony couvre un éventail large. Des applications métier internes : back-offices qui pilotent une activité, outils de gestion qui remplacent un tableur devenu ingérable, plateformes qui font travailler ensemble plusieurs équipes avec des droits et des vues différents selon le rôle. Des intégrations : connecter un site ou une application à un ERP, un CRM, un outil de facturation, une API partenaire, en gérant les cas où le système d'en face répond mal ou pas du tout. Des API qui exposent vos données dans les règles à un front, à une application mobile ou à un partenaire, avec API Platform quand le besoin s'y prête. Et la logique lourde qu'aucun CMS ne porte sans souffrir : moteurs de calcul, règles de tarification, workflows de validation à plusieurs mains, traitements par lots qui tournent la nuit. À chaque fois, le point commun est le même : il y a une règle métier derrière l'écran, et c'est elle qui dicte le code.
Sur ces projets, l'architecture compte autant que le code. On sépare ce qui change souvent de ce qui change rarement, on documente les choix structurants au fil de l'écriture, on met en place une intégration continue qui rejoue les tests à chaque modification. Le code est versionné, les environnements sont reproductibles, un nouvel arrivant peut lancer le projet en local et comprendre la logique sans qu'on lui tienne la main pendant trois semaines. L'idée est simple : quand vous reprenez le code, ou quand vous le confiez à quelqu'un d'autre, rien ne doit reposer sur une connaissance qui n'existe que dans nos têtes. Une application métier qu'on ne peut faire évoluer qu'avec son auteur d'origine est une application à moitié livrée. On code pour qu'elle se passe de nous.
Le passage de WordPress à Symfony mérite qu'on s'y arrête, parce que c'est une bascule qu'on accompagne souvent et qui se décide mal quand on la prend à l'envers. Beaucoup de projets démarrent sur un CMS, à raison : il fallait publier vite, montrer quelque chose, valider une idée. Puis le besoin se déplace. On ajoute un espace client, puis des règles de droits, puis un calcul, puis une connexion à l'outil comptable. Chaque ajout passe encore, jusqu'au jour où le CMS devient une superposition de greffes qui se gênent. Le signal tient à la nature de ce qu'on demande au site. Quand l'essentiel du travail n'est plus de publier du contenu mais d'exécuter de la logique métier, le CMS travaille contre vous, et réécrire le cœur en Symfony coûte moins cher que d'empiler une greffe de plus. On ne migre pas par principe, et rarement d'un bloc : souvent on garde le CMS pour ce qu'il fait bien, l'éditorial, et on bascule en Symfony la seule partie applicative. On migre quand le contenu n'est plus le sujet.
L'inverse est tout aussi vrai, et on le dit avant de signer. Symfony peut être surdimensionné. Pour un site vitrine, un blog, une boutique standard, un projet dont le cœur est éditorial ou catalogue, sortir un framework applicatif revient à mobiliser un moteur d'application là où un CMS bien posé ferait le travail en une fraction du temps et du budget. La maîtrise d'une techno, c'est aussi savoir quand elle est de trop. Si votre besoin tient dans WordPress, Astro ou une boutique e-commerce existante, on vous le dira, même si Symfony nous arrangerait davantage. Une application écrite de toutes pièces quand un produit du marché suffisait, c'est de l'argent immobilisé et une maintenance qu'on vous laisse sur les bras.
L'IA, sur ce terrain, n'entre que si elle a un sens technique réel. Une application Symfony manipule des données structurées et de la logique : c'est le bon endroit pour brancher un appel à un modèle qui classe des demandes entrantes, extrait l'information utile d'un document, ou pré-remplit un dossier à partir d'un texte libre. On l'intègre comme un composant parmi d'autres, encadré, testé, avec un comportement prévu quand le modèle se trompe ou ne répond pas. L'IA ne réécrit pas l'architecture et ne justifie pas à elle seule qu'on écrive une application entière. Elle se pose en couche sur une base saine, quand le gain est réel et mesurable. Le reste du temps, on s'en passe et on le dit.
Reste ce qu'on garantit, et la limite est honnête. On garantit une base lisible, testée, documentée, qu'une autre équipe peut reprendre. On garantit qu'on choisit Symfony pour ce que le projet vit, sur un besoin réel. Ce qu'on ne fait pas : promettre un délai avant d'avoir cadré le périmètre réel d'une application métier, parce que la complexité se mesure une fois la logique posée à plat, sur du concret. Un même écran peut cacher trois règles ou trente, une intégration peut être une API propre ou un vieux système qui répond une fois sur deux : on a besoin de regarder avant de chiffrer. On commence par comprendre le métier, on découpe, on chiffre sur du concret. Le reste est du code, et le code, on sait le tenir.