Symfony ou WordPress site client : la grille honnête
Une agence me demande de trancher pour un de ses clients : Symfony ou WordPress. Le client vend des équipements industriels, veut un catalogue avec des règles de tarification par volume, une connexion à son ERP et un espace revendeur. L'agence penche pour WordPress parce qu'elle sait le maintenir. Sur ce cas précis, elle a tort. Mais la fois d'avant, sur un magazine en ligne, elle aurait eu raison. La réponse n'est jamais absolue, elle dépend de critères que je vais poser.
WordPress est le bon choix plus souvent qu'un développeur ne l'admet
Je code en Symfony et je gagne ma vie avec, donc quand je dis que WordPress est souvent le meilleur choix, ce n'est pas de la complaisance. Pour un site dont la valeur est le contenu, un blog, un magazine, une vitrine que le client met à jour lui-même chaque semaine, WordPress apporte un back-office que des millions de gens savent utiliser, un écosystème de plugins pour 90 pour cent des besoins courants, et un coût de démarrage imbattable. Refaire ça en Symfony, c'est réécrire un CMS de contenu que WordPress fournit gratuitement depuis vingt ans. C'est du sur-mesure injustifié, et le client le paiera deux fois : à la construction, puis en dépendance à vous pour la moindre virgule.
Le piège du sur-mesure, c'est qu'il flatte le prestataire. Un socle Symfony fait sérieux, technique, défendable en réunion. Mais si le besoin réel est de publier des articles et de changer un bandeau, vous avez vendu un camion pour aller chercher le pain. Le client s'en apercevra le jour où il voudra modifier une page seul et découvrira qu'il faut un ticket et une demi-journée de dev.
Le vrai basculement, c'est la logique métier spécifique
Symfony devient le bon choix quand le site cesse d'être un site de contenu pour devenir une application. Des règles de tarification qui dépendent du client connecté, un tunnel de commande avec des contraintes métier, une synchronisation avec un ERP ou un logiciel de compta, un espace utilisateur avec des rôles et des permissions fines, un calcul, un flux, une intégration. Dès que vous vous surprenez à chercher quel plugin WordPress fait ça, et que la réponse est un plugin à 200 euros par an qui fait ça à 80 pour cent, vous êtes en train de construire sur du sable.
Le coût caché de WordPress dans ces cas, c'est le contournement. Vous empilez trois plugins qui se marchent dessus, un peu de code dans le fichier functions.php, un plugin premium dont la mise à jour casse un autre plugin. Au bout de deux ans, personne ne sait plus pourquoi ça tient, et la reprise devient un cauchemar. J'ai décrit ce scénario dans reprendre un site quand le prestataire est parti. Un socle Symfony sur le même besoin est plus cher au départ, mais la logique est explicite, testable, et lisible par le développeur suivant.
La grille de décision, critère par critère
| Critère | Penche WordPress | Penche Symfony |
|---|---|---|
| Nature du besoin | Contenu éditorial, vitrine | Application, logique métier |
| Volume et fréquence de contenu | Le client publie souvent, seul | Contenu rare, structuré par des règles |
| Besoins métier spécifiques | Couverts par un plugin établi | Tarification, flux, ERP, rôles fins |
| Budget de maintenance sur 3 ans | Serré, peu d'évolutions | Évolutif, on préfère payer la dette une fois |
| Équipe qui reprendra | Généraliste, connaît WordPress | Dev, ou maintenance sous-traitée durablement |
| Tolérance au risque plugin | Acceptable, mises à jour suivies | Faible, on veut du code maîtrisé |
La règle que j'applique : si cinq critères sur six penchent du même côté, le choix est clair. Quand c'est trois-trois, c'est presque toujours la compétence de l'équipe qui reprendra qui doit trancher, parce que c'est elle qui vivra avec le choix pendant trois ans, pas moi.
La compétence de reprise pèse plus lourd que la supériorité technique
C'est le critère que les développeurs sous-estiment le plus. Un site Symfony élégant que votre équipe ne sait pas faire évoluer est un actif mort. À chaque modification, vous rappelez le prestataire, et si le prestataire disparaît, le client est bloqué avec une base de code que personne dans son entourage ne lit. À l'inverse, un WordPress un peu bricolé mais dont n'importe quel freelance comprend la structure reste manipulable par tout le marché.
Donc avant de proposer Symfony à une agence dont l'équipe ne fait que du WordPress, je pose une seule question : qui maintiendra ce site dans dix-huit mois. Si la réponse est vous, alors il faut un contrat de maintenance clair, et je le dis, parce que sans ça je vends une dépendance déguisée. J'ai formalisé cette logique dans la maintenance d'un site pour une agence et dans le contrat de sous-traitance.
La limite que j'assume : le sur-mesure injustifié piège d'abord le client
La plus grosse erreur que je vois n'est pas de choisir WordPress à tort, c'est de choisir Symfony à tort. Un développeur qui veut faire du beau code, une agence qui veut facturer un projet ambitieux, et voilà un site vitrine de dix pages construit sur un framework applicatif. Le client se retrouve prisonnier : il ne peut rien changer seul, chaque évolution passe par un devis, et le jour où il veut partir, personne ne veut reprendre un sur-mesure sans documentation. WordPress, dans ce cas, lui aurait rendu sa liberté.
Ma règle personnelle : je propose Symfony seulement quand je peux nommer précisément la fonction métier que WordPress ne fait pas proprement. Si je n'y arrive pas, le besoin est un besoin de contenu, et WordPress gagne. Ce n'est pas une position dogmatique, c'est du respect pour la trésorerie du client final, qui est aussi ce qui fait revenir l'agence. Si vous voulez déléguer cet arbitrage sur un dossier concret, je travaille avec des agences sur ce type de décision via mon offre partenaires, et la mécanique de délégation est détaillée dans la sous-traitance de développement web.