PHP vs Go pour les applications backend : performance, DX et déploiements

PHP vs Go : ce que vous choisissez vraiment

Choisir entre PHP et Go n'est pas seulement une préférence de langage — c'est une décision sur la façon dont votre backend sera construit, livré et exploité.

Une application backend inclut généralement un mélange de :

• Applications web qui rendent des pages et gèrent des formulaires
• APIs qui servent des applications mobiles, des SPA ou des intégrations partenaires
• Jobs en arrière-plan comme les emails, imports, facturation, files d'attente et tâches planifiées

PHP et Go peuvent couvrir tout cela, mais ils tendent à vous pousser vers des choix par défaut différents.

Le compromis en termes simples

PHP est souvent synonyme d'itération rapide dans un écosystème web mature : frameworks complets, hébergement peu coûteux, et une longue histoire d'utilisation pour le web. Il excelle quand votre équipe veut des conventions fortes pour construire des produits web typiques — auth, panneaux d'administration, CRUD, templating et sites riches en contenu.

Go est souvent axé sur des performances prévisibles et une simplicité opérationnelle : un binaire compilé, une concurrence claire, et une bibliothèque standard couvrant beaucoup de besoins backend. Il convient aux services à fort débit, au travail en temps réel efficace ou lorsque l'on souhaite des artefacts de déploiement simples.

Ce qui détermine le “meilleur” choix

Le bon choix dépend moins des benchmarks abstraits que de vos contraintes :

• Expérience de l'équipe et recrutement : ce que vos développeurs peuvent livrer en confiance
• Objectifs de trafic et latence : où la performance affecte réellement l'expérience utilisateur ou le coût
• Modèle de déploiement : hébergement partagé vs conteneurs, serverless ou Kubernetes
• Orientation architecturale : monolithe, monolithe modulaire ou microservices

Dans la suite de cet article, nous comparerons le comportement de PHP et Go en production — notions de performance, runtime et concurrence, frameworks, outils développeur, modèles de déploiement, préoccupations de sécurité et comment choisir (ou migrer) avec un risque minimal.

Bref aperçu de PHP et Go

PHP et Go peuvent tous deux supporter des backends solides, mais ils partent d'hypothèses différentes. PHP a grandi autour du web : omniprésent en hébergement partagé, profondément intégré au modèle requête/réponse, et entouré d'un écosystème mature. Go a été conçu plus tard en pensant aux services : compilé en un seul binaire, favorisant une bibliothèque standard limitée et encourageant des programmes serveurs simples et efficaces.

Forces typiques de PHP

PHP est orienté web. Vous pouvez passer rapidement de l'idée à un endpoint fonctionnel, surtout avec des frameworks et conventions qui gèrent routage, validation, templating, files d'attente et accès aux bases de données.

L'écosystème est aussi énorme : paquets, plateformes CMS et options d'hébergement abondent. Pour les équipes qui valorisent l'itération rapide et des bibliothèques prêtes à l'emploi, PHP est souvent le chemin le plus court entre les exigences et une fonctionnalité déployée.

Forces typiques de Go

Go est compilé : le résultat est généralement un exécutable autonome. Cela peut simplifier et rendre plus prévisible les déploiements.

Le modèle de concurrence de Go est aussi un argument majeur. Les goroutines et les channels rendent relativement simple la construction de services qui effectuent beaucoup de travail en parallèle (appels en fan‑out, jobs en arrière‑plan, connexions en streaming) sans code de threading complexe.

Où ils sont utilisés aujourd'hui

PHP est largement utilisé pour les applications web, sites orientés contenu, tableaux de bord SaaS et APIs JSON construites avec des frameworks populaires. Il est aussi courant lorsque des équipes veulent tirer parti de bases de code PHP existantes ou du pool de talents PHP.

Go est fréquent pour les APIs, services internes, outils CLI et composants sensibles aux performances dans une architecture microservices — surtout quand on veut un comportement d'exécution cohérent et un empaquetage opérationnel simple.

Notions de performance qui comptent pour le backend

Quand on compare PHP vs Go sur la « performance », on mélange souvent deux idées différentes : latence et débit.

Latence vs débit (en clair)

Latence : le temps qu'une seule requête met entre « client envoie » et « client reçoit ». Si un endpoint semble lent, c'est généralement un problème de latence.

Débit : combien de requêtes votre système peut traiter par seconde (ou par minute) tout en restant stable. Si le serveur tombe pendant des pics de trafic, c'est généralement un problème de débit.

Un langage peut influencer les deux, mais beaucoup de ralentissements backend proviennent de ce qui se passe autour de votre code.

Goulots CPU vs goulots I/O

Certains travaux sont CPU-bound : parsing de gros payloads, traitement JSON intensif, chiffrement, manipulation d'images, transformations de données complexes. Sur ces chemins CPU-bound, Go a souvent un avantage parce qu'il compile en natif et s'exécute efficacement.

Mais la plupart des applications backend sont I/O-bound : elles attendent une requête base de données, un autre service, une API tierce, lisent une file ou écrivent dans un stockage d'objets. Dans ces cas, le runtime compte moins que :

• la vitesse des requêtes (index, plans, pooling de connexions)
• la latence réseau entre services
• le nombre d'aller‑retour effectués

Les « gros gains » ne sont généralement pas des changements de langage

Avant de réécrire un service PHP en Go (ou l'inverse), recherchez les correctifs à fort levier :

• Caching (caching HTTP, application, Redis/memcached) pour éviter de répéter des travaux coûteux
• Conception de la base (index, moins de requêtes, meilleur schéma, éviter les patterns N+1)
• Taille des payloads et choix de sérialisation

Si 70–90 % du temps de votre requête est du temps d'attente base de données et réseau, améliorer les requêtes et le caching battra la plupart des optimisations au niveau langage — souvent avec moins de risques et d'efforts.

Modèle d'exécution et comportement des serveurs

La différence la plus pratique entre PHP et Go n'est pas la syntaxe, mais la façon dont le code « vit » sur le serveur.

PHP : exécution par requête (avec FPM), plus des workers longue durée optionnels

Le PHP classique fonctionne dans un modèle par requête : un serveur web (souvent Nginx) remet chaque requête HTTP à PHP-FPM, PHP exécute votre code, produit une réponse, puis le contexte de requête est détruit.

Cela a quelques conséquences :

• Ardoise propre par défaut. La mémoire est récupérée à la fin de la requête, ce qui rend les « fuites » moins susceptibles de s'accumuler au fil du temps.
• Le warmup compte. Pour éviter de reparser le code à chaque requête, les environnements de production s'appuient sur OPcache pour réutiliser le bytecode compilé.
• Le débit dépend des workers. FPM utilise un pool de processus. Si tous les workers sont occupés, les nouvelles requêtes attendent en file.

Les applications PHP modernes utilisent aussi des workers longue durée (pour les queues, websockets, schedulers). Ceux‑ci se comportent davantage comme un processus serveur : ils restent en mémoire, gardent des connexions ouvertes et peuvent accumuler de la mémoire si on ne les gère pas correctement.

Go : processus serveur long compilé en un binaire

Go tourne généralement comme un binaire compilé qui démarre un serveur HTTP de longue durée. Il reste en mémoire, maintient des caches internes et gère les requêtes continuellement.

À l'intérieur de ce processus, Go utilise des goroutines (threads légers) pour exécuter de nombreuses tâches en parallèle. Au lieu de « lancer un interpréteur par requête », le même programme en cours d'exécution gère tout.

Ce que cela implique pour la mémoire, le démarrage et la vitesse en état stable

• Utilisation mémoire : PHP-FPM utilise souvent plus de mémoire totale parce que vous avez plusieurs processus workers. Go utilise un seul processus mais peut croître avec les caches et la charge concurrente ; il faut surveiller de véritables fuites à long terme.
• Temps de démarrage & déploiements : les binaires Go démarrent rapidement et ne dépendent pas d'un runtime au‑delà des bibliothèques OS basiques. Les déploiements PHP consistent plutôt à « livrer du code + config PHP-FPM », et les redémarrages concernent souvent le rechargement des workers.
• Performance en état stable : Go tend à être efficace une fois en mémoire car il évite le surcoût de l'interpréteur par requête. PHP peut aussi être très rapide — surtout avec OPcache — mais la performance dépend fortement du tuning de FPM (nombre de workers, limites mémoire) et des patterns de requêtes.

Concurrence et fonctionnalités temps réel

Si votre backend ne fait que « une requête entrant, une réponse sortant », les deux langages conviennent bien. La différence apparaît quand il faut beaucoup de choses en même temps : nombreux appels sortants, connexions longue durée ou streams continus.

Go : goroutines + channels (le travail parallèle est natif)

Go est construit autour de la concurrence légère. Une goroutine est une petite « tâche » qui peut s'exécuter en parallèle, et les channels sont un moyen sûr de passer des résultats.

Voici un simple pattern « nombreux appels en parallèle » (imaginez appeler 20 services et collecter les résultats) :

results := make(chan string, len(urls))
for _, url := range urls {
    go func(u string) {
        // pretend httpGet(u) does an API call
        results <- httpGet(u)
    }(url)
}

var out []string
for i := 0; i < len(urls); i++ {
    out = append(out, <-results)
}

Parce que la concurrence fait partie du runtime standard, Go convient particulièrement à :

• APIs à fort fan‑out (une requête déclenche de nombreux appels downstream)
• serveurs WebSockets et notifications en temps réel
• réponses en streaming (HTTP chunked, streams gRPC)

PHP : la concurrence est généralement « plus de workers », l'async en option

Le PHP classique (surtout avec PHP-FPM) gère la concurrence en faisant tourner plusieurs workers indépendants. Chaque requête est traitée par un worker, et vous augmentez le débit en ajoutant des workers/serveurs. Ce modèle est simple et fiable pour les applications web typiques.

Pour des charges temps réel, PHP peut y répondre, mais vous choisirez souvent une approche spécifique :

• Plus de processus/threads : scale bien la gestion des requêtes, mais chaque requête reste majoritairement synchrone.
• Bibliothèques async/event loop : ReactPHP ou Amp aident pour l'E/S concurrente.
• Serveurs longue durée : Swoole ou RoadRunner permettent à PHP de rester en mémoire et de gérer WebSockets/streaming comme un serveur applicatif.

Conseils pratiques

• WebSockets / chat / tableaux de bord live : Go est souvent le choix le plus direct ; PHP fonctionne bien avec Swoole/RoadRunner (prévoir une opération de type app‑server).
• Streaming (SSE, téléchargements chunkés, gRPC streaming) : Go est généralement plus simple à implémenter et exploiter.
• APIs à fort fan‑out : les goroutines de Go brillent ; en PHP vous utiliserez probablement des bibliothèques async ou déporterez le fan‑out vers des queues/workers.

Frameworks et patterns architecturaux

Le choix du framework influence la vitesse de livraison, l'évolution du codebase et ce que « bonne structure » signifie pour votre équipe. PHP et Go prennent en charge des backends propres, mais ils vous guident vers des choix différents.

PHP : frameworks full‑stack qui tracent les rails

Le centre de gravité de PHP est constitué de frameworks « batteries‑in‑cluded » — surtout Laravel et Symfony. Ils fournissent des patterns établis pour routage, controllers, templating, ORM, migrations, queues, jobs, validation et auth.

Cela aide lorsqu'on veut une « voie dorée » partagée dans l'équipe : structure de dossiers prévisible, pipeline middleware standard, et conventions qui réduisent la fatigue décisionnelle. Pour beaucoup d'applications backend, le framework devient aussi l'architecture : MVC (ou proche), plus classes de service, repositories, événements et jobs.

Le risque est une dépendance excessive à la « magie » du framework. La convention peut masquer de la complexité (injections implicites, comportement de l'ORM, hooks de cycle de vie) et les grandes apps peuvent devenir des monolithes façonnés par le framework sauf si vous imposez des limites délibérées.

Go : bibliothèque standard + composition explicite

Les équipes Go démarrent souvent avec net/http et composent avec de petites bibliothèques : un routeur (chi, gorilla/mux, httprouter), logging, configuration, métriques et accès DB. Des frameworks existent, mais le minimalisme est courant : votre architecture est un ensemble de packages aux interfaces claires.

Cette composition explicite permet de visualiser le flux de données et les dépendances. Elle favorise aussi des architectures comme les frontières « clean/hexagonales » ou un code orienté services où les HTTP handlers sont fins et la logique métier testable.

Le compromis : convention vs clarté

• Les frameworks PHP accélèrent les produits CRUD et les équipes qui apprécient des conventions partagées.
• L'approche Go favorise la clarté et le contrôle, mais vous assemblez plus d'éléments vous‑même.

Aucun n'est automatiquement meilleur — choisissez selon le degré d'autonomie que vous voulez laisser au framework versus ce que vous souhaitez décider explicitement.

Expérience développeur et outillage

L'expérience développeur est là où PHP et Go se ressentent le plus au quotidien : PHP optimise souvent pour « faire tourner quelque chose vite », tandis que Go optimise pour « rendre le comportement uniforme partout ».

Configuration locale et gestion des paquets

Avec PHP, votre configuration dépend de la façon dont vous l'exécutez (Apache/Nginx + PHP‑FPM, serveur intégré ou Docker). Beaucoup d'équipes standardisent sur Docker pour éviter les différences "ça marche sur ma machine" entre OS et extensions PHP.

La gestion des dépendances en PHP est mature et conviviale : Composer et Packagist rendent l'ajout de bibliothèques simple, et les frameworks fournissent des conventions pour config et bootstrap.

Go est typiquement plus simple à installer : un runtime, un compilateur et une toolchain prévisible. Les modules Go sont intégrés, le versionning est explicite et les builds sont reproductibles sans gestionnaire de paquets séparé.

Workflow de tests

PHP dispose de PHPUnit/Pest et d'un large écosystème pour les tests unitaires et d'intégration. Les frameworks offrent des helpers pour tester HTTP, les transactions DB et les fixtures, ce qui accélère l'écriture de tests réalistes.

Go inclut les tests dans la bibliothèque standard (go test). Cela rend les tests universels dans tous les projets. Le mocking est plus orienté vers les interfaces et les fakes ; certains teams utilisent la génération de code pour faciliter. Les tests d'intégration sont courants, mais vous composez généralement votre propre harness plutôt que d'appuyer sur un framework.

Debugging, profilage et observabilité

Le debugging PHP s'articule souvent autour de Xdebug (breakpoints, traces) et des pages d'erreur fournies par les frameworks. Le profilage se fait avec Blackfire ou le profiling Xdebug.

Go a de solides outils intégrés : dumps de pile, détection de race, et pprof pour le profiling CPU/mémoire. Pour l'observabilité, les deux écosystèmes fonctionnent bien avec OpenTelemetry et les APM courants — Go demande souvent une instrumentation plus explicite, tandis que les frameworks PHP peuvent offrir plus de hooks prêts à l'emploi.

Prototype rapide et comparaison

Si vous hésitez entre PHP et Go et voulez réduire le coût d'essayer les deux, il est utile de prototyper le même endpoint et job en parallèle. Certaines plateformes facilitent ces comparaisons : vous pouvez décrire le service en chat, générer une UI web (React) + backend (Go + PostgreSQL), puis itérer sur l'architecture (auth, queues, forme de l'API) avant de vous engager. Un vrai proof‑of‑concept aide à évaluer les réalités du "day 2" plus tôt.

Déploiement et exploitation

Le déploiement est l'endroit où PHP et Go se distinguent le plus : PHP est typiquement « une app qui s'exécute dans votre serveur web », tandis que Go est souvent « un serveur que vous envoyez et lancez ». Cette différence affecte tout, des choix d'hébergement à la manière de déployer des mises à jour.

Où les exécuter

PHP est difficile à battre pour un hébergement sans friction. Un hébergement mutualisé ou un VPS basique peut faire tourner PHP avec Apache ou Nginx + PHP‑FPM, et beaucoup de fournisseurs offrent des réglages par défaut sensés. Le déploiement consiste souvent à copier le code, installer les dépendances (Composer) et laisser la pile web gérer les requêtes.

Go s'expédie souvent comme un binaire statique (ou une petite image container). Cela le rend portable et prévisible entre environnements, mais vous oriente aussi vers VPS + systemd, Docker ou Kubernetes. Plutôt que de « configurer PHP‑FPM », vous lancez votre service sur un port et mettez Nginx (ou un LB) devant.

Préoccupations opérationnelles

Avec PHP, les mises à jour impliquent souvent de coordonner les versions PHP, les extensions et les dépendances Composer sur les serveurs. La gestion des processus est déléguée à PHP‑FPM, et les déploiements blue/green ou zero‑downtime sont possibles mais demandent de gérer OPcache, warmup et l'état partagé.

Avec Go, vous gérez un processus longue durée. Les déploiements zero‑downtime sont simples avec un load balancer et des mises à jour progressives (ou systemd socket activation). Adoptez des pratiques pour la config (vars d'environnement), les health checks et la fermeture gracieuse.

Adéquation avec des stacks courants

• Nginx : PHP via PHP‑FPM ; Go comme upstream service.
• Kubernetes : les containers Go sont souvent plus simples ; PHP fonctionne bien mais peut impliquer plusieurs conteneurs (PHP‑FPM + Nginx) et des étapes de build.
• Serverless : PHP peut s'adapter à certaines plateformes mais n'est pas universel ; Go est un choix fréquent quand « compiler en un petit artefact » est natif.

Adéquation équipe, recrutement et maintenabilité à long terme

Les choix techniques se transforment en problèmes d'humain : qui peut modifier le code en toute sécurité, combien de temps pour qu'un nouveau dev soit productif, et combien coûte la mise à jour des dépendances.

Maintenabilité : ce que vous paierez avec le temps

Les projets PHP accumulent souvent une large surface de framework et de paquets (surtout dans les apps full‑stack). Cela peut être acceptable, mais le coût à long terme est souvent guidé par les mises à jour de dépendances, les patchs de sécurité et les montées de version majeures du framework. Des frontières claires entre modules, une nomenclature cohérente et une discipline sur les packages comptent plus que le langage.

Go incite à des graphes de dépendances plus petits et une mentalité « standard library first ». Combiné à des outils de convention (gofmt), les codebases paraissent souvent plus uniformes entre équipes. L'inverse : si votre service Go grossit sans architecture claire, vous pouvez tout autant obtenir un bazar interne — Go ne l'empêche pas magiquement.

Courbe d'apprentissage et intégration

Si votre équipe connaît déjà PHP (ou Laravel/Symfony), l'intégration est généralement rapide : l'écosystème est familier et il existe beaucoup de pratiques communautaires partagées.

Go est simple à apprendre, mais peut demander un changement de posture autour de la concurrence, du traitement des erreurs et de la structuration des services. Les nouveaux ingénieurs peuvent être productifs rapidement sur de petits services, mais il faut plus de temps pour maîtriser les patterns de performance et de concurrence.

Recrutement et disponibilité des talents

Les talents PHP sont largement disponibles, surtout pour le développement web produit et en agence. Il est souvent plus simple d'embaucher pour du développement web « get it done ».

Les développeurs Go sont courants dans les sociétés qui construisent des APIs, de l'infra et des microservices, mais le vivier peut être plus restreint selon les régions. Si vous prévoyez une croissance rapide, vérifiez votre marché local ou votre volonté de former en interne.

Règle pratique : choisissez le langage que votre équipe pourra maintenir calmement à 2h du matin — et prévoyez du temps pour la maintenance des dépendances dans les deux cas.

Considérations de sécurité

La sécurité n'est pas une propriété "PHP vs Go" mais une habitude de construction et d'exploitation. Les deux peuvent être parfaitement sûrs — ou dangereusement exposés — selon les valeurs par défaut, les dépendances et l'exploitation.

Bases de la sécurité en PHP et Go

La validation des entrées et l'échappement des sorties sont la première ligne de défense dans les deux écosystèmes. En PHP, les frameworks comme Laravel et Symfony encouragent la validation des requêtes et des templates qui aident à éviter les XSS lorsqu'on les utilise correctement. En Go, vous assemblez souvent la validation vous‑même (ou via des bibliothèques), ce qui peut être plus sûr si vous êtes discipliné — mais aussi plus facile à oublier si l'équipe bouge vite.

AuthN/AuthZ sont matures dans les deux mondes. PHP dispose d'un large éventail de bibliothèques et d'intégrations de framework pour sessions, cookies, protection CSRF et hashing de mots de passe. Go propose de solides primitives (packages crypto, patterns middleware) et de nombreuses bibliothèques JWT/OAuth2, mais vous assemblez généralement les pièces de manière plus explicite.

Les mises à jour de dépendances comptent également. PHP utilise Composer ; Go utilise les modules avec un versioning fort et une toolchain standard pour fetch et vérifier. Aucun ne supprime le risque de chaîne d'approvisionnement — il faut revue, pinning et routines de mise à jour.

Zones de risque fréquentes

La mauvaise configuration est une cause fréquente.

En PHP : exposer le mode debug, divulguer .env, gérer permissivement les uploads, désérialiser de façon dangereuse et des règles de serveur web permettant l'accès au code source.

En Go : écrire un middleware d'auth personnalisé incorrectement, configurer un CORS trop large, logger des secrets par erreur, faire confiance sans validation aux headers proxy, ou désactiver la vérification TLS dans des clients.

Des paquets obsolètes et des defaults dangereux peuvent survenir dans les deux langages — surtout quand on colle des snippets copiés sans revue.

Checklist pratique (indépendante du langage)

Gardez ceci systématique pour toutes les équipes :

• Validez toutes les entrées ; encodez les sorties ; utilisez des requêtes paramétrées.
• Centralisez authN/authZ ; appliquez le principe du moindre privilège.
• Stockez les secrets dans un gestionnaire dédié ; jamais dans les logs.
• Patchez les dépendances régulièrement ; pinez les versions ; surveillez les avis de sécurité.
• Activez des en‑têtes sécurisés, un CORS strict et le rate limiting.
• Utilisez HTTPS partout ; validez les frontières de proxy/confiance.
• Ajoutez des logs d'audit et des alertes pour les activités suspectes.

Traitez la sécurité comme une partie de la « definition of done », pas comme une phase séparée.

Quand PHP gagne vs quand Go gagne

Choisir entre PHP et Go n'est pas déterminer quel langage est « meilleur ». C'est définir quel type de backend vous construisez, comment votre équipe travaille et où vous voulez la simplicité : dans le développement quotidien ou dans l'exécution et l'exploitation.

Quand PHP est le meilleur choix

PHP l'emporte quand le centre de gravité est le produit web lui‑même — pages, formulaires, admin, contenu et itération rapide.

• Apps CRUD : dashboards, outils internes, portails B2B et workflows centrés bases de données.
• Sites pilotés par CMS : écosystèmes WordPress/Drupal, plugins, theming et beaucoup d'intégrations prêtes.
• Itérations produit rapides : grands écosystèmes de frameworks (Laravel/Symfony), conventions fortes et bibliothèques matures pour les problèmes web standard.

Si la majorité des requêtes sont des interactions HTTP courtes (rendre une page, valider, lire/écrire des données, répondre), les forces de PHP apparaissent vite.

Quand Go est le meilleur choix

Go l'emporte quand le backend ressemble davantage à un service qu'à une app web traditionnelle.

• Services à forte concurrence : chat, feeds en temps réel, APIs de streaming ou systèmes effectuant beaucoup d'E/S parallèle.
• Outils CLI et automatisation : outils internes, utilitaires de migration de données, helpers de build/deploy.
• Services d'infrastructure : gateways, proxies, schedulers, workers background et microservices qui doivent être prévisibles sous charge.

Le runtime et la bibliothèque standard de Go en font un bon choix pour les processus longue durée et les charges où la concurrence est une caractéristique, pas une option.

Approches mixtes efficaces

Beaucoup d'équipes obtiennent le meilleur résultat en combinant les deux :

• Couche produit PHP + services Go : PHP gère l'UI web/admin/CMS, Go exécute les APIs à haut débit, WebSockets ou processeurs d'événements.
• Noyau Go + bords PHP : Go fournit l'API principale, PHP alimente les pages de contenu, sites marketing ou modules legacy coûteux à réécrire.

Cette approche réduit le risque : conservez ce qui est productif et introduisez Go là où il apporte des gains opérationnels ou de performance clairs.

Checklist de décision et voies de migration

Choisir entre PHP et Go devient simple quand vous transformez les préférences en un petit ensemble de contraintes. Le but n'est pas de prédire parfaitement l'avenir, mais d'éviter un choix qui impose des réécritures coûteuses six mois plus tard.

Checklist pour un greenfield

Posez-vous ces questions pour éprouver la direction :

• Prévisions de trafic : quelques requêtes/s ou attendez‑vous des pics fréquents (campagnes, jobs batch, intégrations B2B) ?
• Besoins de latence : les utilisateurs ressentent‑ils immédiatement les délais (checkout, recherche, dashboards temps réel) ou le travail peut‑il s'exécuter en arrière‑plan (rapports, emails) ?
• Délais et vitesse d'équipe : avez‑vous besoin d'un produit fonctionnel vite avec des patterns familiers, ou y a‑t‑il le temps d'investir dans un workflow compilé plus strict ?
• Forme du service : une grosse application avec beaucoup de pages et règles métier, ou beaucoup de petits services et APIs ?
• Confort opérationnel : souhaitez‑vous des déploiements simples via un binaire unique, ou êtes‑vous déjà équipé pour PHP‑FPM, process managers et scaling web workers ?

Raccourci pratique : si vous n'êtes pas sûr du trafic et avez besoin d'itération rapide, commencez par ce que l'équipe peut livrer en confiance — puis concevez des frontières pour pouvoir remplacer des parties plus tard.

Options de migration sans réécriture totale

Si vous avez déjà un système PHP et voulez Go pour certaines capacités, migrez par étapes :

• Services incrémentaux : gardez le noyau en PHP et développez en Go les nouvelles charges sensibles à la performance (webhooks, stream processing, APIs internes).
• Base partagée (avec précautions) : les deux services peuvent lire/écrire les mêmes tables pendant la transition, mais définissez la propriété pour éviter les écritures conflictuelles.
• Gateway/API edge : mettez une couche edge pour déplacer des endpoints de PHP vers Go sans changer les clients.

Étapes recommandées

1. Faites un proof‑of‑concept réduit : un endpoint réel + un job background, construit dans chaque stack.
2. Créez un plan de benchmarking : mesurez la latence p95 et l'utilisation des ressources sous une charge réaliste (pas seulement hello‑world).
3. Réalisez un sprint d'essai d'équipe : laissez l'équipe construire, déployer et exploiter de bout en bout. L'expérience "day 2" rend souvent la décision évidente.