180ms contre 8ms : une comparaison séduisante qui cache l'essentiel
Un endpoint d'authentification Laravel répond en 180ms. Le même endpoint réécrit en Go répond en 8ms. Sur le papier, c'est un argument massue. Mais ce que cette comparaison ne dit pas, c'est que la migration a coûté 8 mois de productivité à l'équipe. Est-ce vraiment un bon deal ?
C'est la question posée par un article de Tuấn Anh sur dev.to, et elle mérite une réponse rigoureuse. Chez MulerTech, nous accompagnons des équipes PHP/Symfony depuis des années, et ce débat revient régulièrement. Voici notre grille de lecture.
Ce que la performance brute ne mesure pas
La latence d'un endpoint est une métrique facile à mesurer et facile à agiter. Mais elle n'est qu'une variable parmi d'autres dans l'équation réelle d'un projet logiciel.
Lorsqu'on parle de Coût Total de Possession (TCO), on intègre des dimensions que les benchmarks ignorent :
- Coût de migration : réécriture du code, tests, recette, déploiement. Sur une application métier Symfony, comptez entre 6 et 18 mois selon la taille.
- Courbe d'apprentissage : une équipe PHP senior doit se reformer sur Go, ses idiomes, son écosystème, sa gestion des goroutines. Le temps de montée en compétence est rarement nul.
- Vélocité pendant la transition : pendant la réécriture, les nouvelles fonctionnalités sont au mieux gelées, au pire livrées en double sur deux bases de code.
- Écosystème et outillage : Symfony dispose de composants matures (Messenger, Security, Doctrine, API Platform). Go offre plus de liberté, mais aussi plus de code à écrire et à maintenir à la main.
- Recrutement : le vivier de développeurs PHP/Symfony en France est large. Celui de développeurs Go expérimentés est plus restreint, et les salaires reflètent cette rareté.
Les 8 mois de perte de productivité évoqués dans l'article source ne sont pas une anomalie. Ils sont la norme.
Quand la réécriture est justifiée (et quand elle ne l'est pas)
Il existe des cas légitimes où migrer vers Go — ou vers tout autre langage compilé — a du sens. Mais ils sont plus rares qu'on ne le croit.
Cas où la réécriture est pertinente
- Goulot d'étranglement prouvé : vous avez des métriques de production, des traces APM, et vous savez avec certitude que le langage est le facteur limitant — pas la base de données, pas le réseau, pas un ORM mal configuré.
- Volume extrême : des dizaines de milliers de requêtes par seconde sur un endpoint critique où chaque milliseconde se traduit en coût infrastructure réel et mesurable.
- Équipe déjà formée : vous recrutez ou disposez déjà d'ingénieurs Go expérimentés, et le projet est suffisamment long pour amortir l'investissement.
- Service isolé : vous n'êtes pas en train de réécrire un monolithe, mais d'extraire un microservice bien délimité, avec une API stable et des dépendances claires.
Cas où l'optimisation PHP/Symfony suffit
- Cache non exploité : un endpoint à 180ms qui interroge la base à chaque appel peut passer à 5ms avec Redis et une stratégie de cache adaptée.
- Requêtes N+1 : Doctrine mal utilisé génère des dizaines de requêtes là où une suffit. Le gain potentiel est souvent supérieur à ce qu'apporterait un changement de langage.
- PHP-FPM vs FrankenPHP/Swoole : les runtimes modernes PHP changent radicalement le profil de performance en maintenant le processus en mémoire entre les requêtes.
- Profiling absent : si vous n'avez jamais utilisé Blackfire ou Xdebug en production, vous ne savez pas encore où est votre vrai problème.
Le cadre de décision TCO appliqué à PHP/Symfony
Plutôt que de décider sur l'intuition ou sur un benchmark isolé, posez-vous ces quatre questions dans l'ordre.
1. Avez-vous un problème de performance prouvé en production ?
Si la réponse est non, arrêtez-vous là. Optimisez en priorité ce qui est déjà en place.
2. Avez-vous épuisé les leviers PHP/Symfony ?
Cache, profiling, optimisation des requêtes, configuration OPcache, runtime alternatif (FrankenPHP), autoscaling horizontal. Ces leviers sont souvent sous-exploités et leur ROI est bien meilleur qu'une réécriture.
3. Quel est le coût réel de la migration ?
Estimez honnêtement : temps de développement × coût journalier moyen × facteur de risque (généralement 1,5 à 2). Ajoutez la perte de vélocité pendant la transition. Comparez à l'économie infrastructure annuelle attendue.
4. Quel est l'horizon de rentabilité ?
Si le point mort est au-delà de 24 mois, la réécriture est rarement justifiable — les besoins métier auront évolué d'ici là.
Ce cadre n'est pas spécifique à Go. Il s'applique à toute décision de migration technologique majeure.
Ce que cela change concrètement pour vos projets Symfony
La leçon principale n'est pas que PHP est lent ou que Go est magique. C'est que la décision technologique doit être pilotée par les données, pas par les benchmarks marketing.
En pratique, pour la grande majorité des applications PHP/Symfony — plateformes e-commerce, SaaS B2B, APIs métier — les performances sont largement suffisantes avec une architecture bien pensée. Symfony 7, PHP 8.3, et un stack de cache correctement dimensionné permettent de traiter plusieurs milliers de requêtes par seconde sur du matériel modeste.
Là où Go apporte une valeur réelle, c'est sur des services à contraintes ultra-spécifiques : traitement de flux temps réel, proxies réseau, outils CLI à haute fréquence. Des cas qui représentent une minorité des projets web.
Conclusion : optimiser avant de réécrire
La prochaine fois qu'un benchmark vous donne envie de tout réécrire en Go, Rust ou Node, prenez le temps de calculer le TCO complet. Intégrez les coûts cachés, mesurez vos goulots d'étranglement réels, et épuisez d'abord les optimisations disponibles dans votre stack actuel.
Php et Symfony ont 30 ans d'outillage derrière eux. Avant de les abandonner pour 170ms de gain sur un endpoint, assurez-vous que ce gain vaut vraiment 8 mois de votre équipe.
Source originale : "Laravel auth = 180ms. The same endpoint in Go = 8ms." par Tuấn Anh sur dev.to
