Et si PHP était la meilleure option pour votre prochain projet ?

D'où vient la mauvaise réputation de PHP ?

Pour comprendre pourquoi il est mal aimé, il faut remonter à ses origines. Ce langage n'a pas été conçu comme un langage de programmation au sens strict. Rasmus Lerdorf l'a créé en 1994 comme un ensemble de scripts Perl pour gérer son CV en ligne. Le nom d'origine était "Personal Home Page Tools". La technologie n'a pas été théorisée en amont par des ingénieurs logiciel : elle s'est construite au coup par coup pour répondre à des besoins immédiats, grandissant au rythme de son adoption bien avant l'apparition des premières tentatives de standardisation.

Résultat : les premières versions étaient effectivement chaotiques. Les noms de fonctions étaient incohérents, certaines utilisaient des underscores, d'autres non, l'ordre des arguments variait selon la fonction, les types étaient gérés de façon approximative. On mélangeait allègrement le HTML et la logique métier dans le même fichier. Il existait des centaines de façons de faire la même chose, pas toujours sécurisées. Les tutoriels sur internet montraient les pires pratiques comme des exemples à suivre, et ces guides restent indexés sur Google jusqu'à aujourd'hui.

Le problème des exemples qui ne vieillissent pas bien

Quand un développeur cherche "PHP tutorial" ou une aide pour une connexion à une base de données, il tombe encore sur des articles qui utilisent mysql_connect(), une fonction dépréciée depuis la version 5.5 et supprimée avec la 7.0. Il voit du code sans préparation de requêtes, sans gestion des erreurs, sans séparation entre le HTML et la logique. Ce n'est pas du code contemporain. C'est du développement d'il y a quinze à vingt ans. Mais l'impression reste.

Les développeurs qui ont appris à programmer dans les années 2010 ont souvent vu cette mouture-là en premier, ou entendu des histoires dessus, et ont associé le langage à ces pratiques. Depuis, ils sont passés à d'autres technologies et n'ont jamais eu de raison de regarder ce qu'il était devenu. Leur jugement est sincère, il est juste figé dans le temps.

L'effet "ça fait pas sérieux"

Il existe aussi une dimension de culture technique. Dans certains milieux, les choix technologiques sont des signaux d'appartenance autant que des décisions pragmatiques. Dire qu'on utilise Go, Rust ou même Node.js envoie un message. Dire qu'on l'utilise en envoie un autre, souvent associé à des agences web qui livrent des sites WordPress pour des PME locales. Ce n'est pas un jugement de valeur, c'est une observation : la réputation d'une technologie dépend aussi du contexte, pas seulement de sa qualité technique.

Ce biais est réel et il a des conséquences concrètes : des développeurs l'évitent par peur du regard de leurs pairs, des entreprises choisissent des stacks plus "tendance" pour attirer des profils, et le langage reste confiné dans certaines niches malgré ses qualités réelles.

77 % du web, ça veut dire quoi concrètement ?

Selon les données de W3Techs, PHP est utilisé comme langage serveur sur environ 77 % des sites web dont la technologie est identifiable. Pour mettre ce chiffre en perspective : le deuxième acteur côté serveur est loin derrière. Ce n'est pas une niche historique qui se maintient par inertie sur des vieux projets. C'est une réalité active, entretenue, qui concerne des millions de sites en production aujourd'hui.

Qu'est-ce qui tourne réellement avec ce langage ?

WordPress représente à lui seul plus de 43 % des sites web mondiaux, et il est écrit avec cette technologie. Mais ce serait réducteur de s'arrêter là. Derrière elle, on trouve aussi Drupal, Joomla, Magento pour le e-commerce, Prestashop, Moodle pour la formation en ligne, et des milliers de plateformes métier développées sur mesure. Wikipedia tourne sur cette stack. Facebook a été construit avec et a investi massivement dans son évolution, c'est d'ailleurs Meta qui est à l'origine de HHVM, une machine virtuelle haute performance dédiée. Slack l'a utilisé pendant des années. Etsy aussi.

Ce n'est pas le langage des petits projets artisanaux. C'est le moteur de certains des services les plus utilisés au monde, qui ont simplement choisi de ne pas en parler trop fort.

Le PHP d'aujourd'hui n'a plus grand-chose à voir avec celui d'avant

La version 7, sortie fin 2015, a été une rupture majeure. Les performances ont quasiment doublé par rapport à la version 5. Le typage a été renforcé. La gestion des erreurs a été refactorisée. Depuis, chaque version majeure a apporté des améliorations substantielles : la 8.0 a introduit les types union, les attributs, les named arguments et le JIT compiler. La 8.1 a ajouté les enums, les fibres et les propriétés en lecture seule. Les moutures 8.2 et 8.3 ont continué dans cette direction avec les classes en lecture seule et des améliorations du système de types.

Le code qu'on écrit aujourd'hui ressemble davantage à du Java moderne ou à du TypeScript strict qu'au style procédural des débuts. Le typage fort est possible, les interfaces sont là, les traits permettent la composition, les générateurs existent, la programmation asynchrone est accessible via les fibres. Ce n'est plus un langage qu'on choisit par défaut faute de mieux. C'est une solution qu'on peut adopter avec conviction.

Qui maintient PHP, et pourquoi ça compte ?

L'écosystème est maintenu par un groupe de contributeurs bénévoles et professionnels coordonnés via la PHP Foundation, créée fin 2021 avec le soutien financier d'entreprises comme JetBrains, Automattic, Zend, Shopware et d'autres. Ce n'est pas un projet de hobbyistes qui pourrait disparaître si le mainteneur principal change de travail. C'est une infrastructure de développement structurée, avec un calendrier de versions prévisible et un processus de RFC transparent.

Chaque version majeure est supportée avec des mises à jour de sécurité pendant deux ans après sa date de fin de vie active. Le cycle est régulier : une nouvelle version mineure chaque année en novembre. Si vous commencez un projet aujourd'hui, vous pouvez planifier sur plusieurs années avec une visibilité raisonnable sur les évolutions de la technologie.

L'argument économique : faire tourner vos scripts pour presque rien

C'est peut-être l'argument le plus concret pour un projet qui démarre ou un produit qui n'a pas encore de budget infrastructure. Le code tourne sur n'importe quel hébergement mutualisé. Pas besoin d'un VPS, pas besoin de Docker, pas besoin de Kubernetes. Pour quelques euros par mois, voire moins, vous avez un environnement fonctionnel, avec une base de données MySQL, un accès FTP et parfois même un panneau d'administration.

Hébergement mutualisé : la réalité du coût zéro ou presque

O2Switch, Infomaniak, PlanetHoster, OVH : tous ces hébergeurs proposent des offres mutualisées qui incluent cette technologie par défaut. Certaines formules à moins de cinq euros par mois permettent de propulser un site qui gère plusieurs centaines de milliers de visites par mois, à condition que le code soit raisonnable. Pour un logiciel interne, un outil métier, un site e-commerce de taille moyenne ou une API simple, c'est souvent largement suffisant.

Comparez avec le coût d'une infrastructure Node.js ou Python qui nécessite a minima un serveur dédié ou une instance cloud, une configuration de reverse proxy, une gestion des processus, et souvent un pipeline de déploiement. La différence de coût et de complexité est réelle, surtout au démarrage d'un projet quand on ne sait pas encore quelle charge on va avoir.

Le déploiement qui ne demande pas un ingénieur DevOps

Mettre en ligne du code peut se résumer à copier des fichiers sur un serveur via FTP comme à l'ancienne ou avec rsync. C'est basique, c'est daté comme approche, mais ça fonctionne et ça ne demande aucune connaissance en infrastructure. Pour des petites équipes, des freelances ou des projets internes, cette simplicité a une vraie valeur. On peut évidemment faire plus sophistiqué avec des pipelines CI/CD, des déploiements Dockerisés et des environnements de staging, mais on n'est pas obligé pour démarrer.

WordPress, PHP, Laravel, Symfony : c'est quoi la différence ?

PHP, c'est le langage. Tout le reste est construit dessus.

Il s'agit du langage de programmation de base. WordPress, Laravel et Symfony sont des logiciels ou des frameworks écrits avec lui. La relation est la même qu'entre JavaScript et React, ou entre Python et Django. Le langage seul n'est qu'un ensemble de fonctions et de syntaxe. Ce qu'on fait avec dépend de ce qu'on choisit de construire ou d'utiliser par-dessus.

WordPress : un CMS, pas un framework

WordPress est un système de gestion de contenu, un CMS. Son objectif premier est de permettre à des non-développeurs de créer et gérer des sites web sans écrire de code. Il est extensible via des thèmes et des plugins, et c'est là que la grande majorité des développeurs interviennent : non pas en le construisant, mais en créant des extensions pour leurs clients.

Ce CMS n'est pas une bonne base pour un système web complexe avec une logique métier avancée. Il n'a pas été conçu pour ça. L'utiliser comme framework applicatif, c'est le détourner d'un usage qui n'est pas le sien. En revanche, pour un site éditorial, un blog, une vitrine, une plateforme e-commerce avec WooCommerce ou un portail d'information, il reste imbattable en termes de rapidité de mise en place et d'écosystème disponible.

Laravel : le framework applicatif qui a changé la donne

Lancé en 2011, Laravel a profondément modernisé cet univers en standardisant l'architecture MVC. Sa force a été d'intégrer nativement un ensemble d'outils complet pour répondre aux besoins courants des applications : l'ORM Eloquent pour la gestion de la base de données, un système de migrations, le moteur de template Blade, ainsi que des modules dédiés aux tâches en arrière-plan (queues et jobs) et aux événements. Cette approche, associée à un outillage robuste pour les tests automatisés, a positionné cette solution comme une alternative rigoureuse pour les projets d'envergure.

Inspiré par la philosophie de Ruby on Rails, il privilégie les conventions de configuration et met l'accent sur l'expérience de développement. Il est aujourd'hui le framework le plus adopté pour la création de nouvelles applications. Son environnement s'est étendu avec des outils comme Livewire pour les interfaces dynamiques, Inertia.js pour l'intégration de frameworks JavaScript (Vue ou React), ou encore Filament pour la génération rapide de panneaux d'administration.

Symfony : la fondation sur laquelle tout repose

Symfony est plus ancien que Laravel (2005) et adopte une approche différente. C'est un ensemble de composants réutilisables, indépendants les uns des autres, que vous pouvez utiliser seuls ou assembler pour construire une structure complète. Il est plus verbeux, plus explicite, plus orienté vers des applications d'entreprise où la configuration fine et la maintenabilité à long terme priment sur la vitesse de développement initial.

Ce qui est particulièrement intéressant, c'est que son concurrent direct utilise plusieurs de ses composants en interne. Symfony est aussi la base sur laquelle est construit API Platform, un outil de référence pour créer des API REST et GraphQL. Si vous en entendez parler dans un contexte d'entreprise ou de grand groupe, c'est souvent parce que les équipes techniques recherchent une architecture robuste, testable et documentée, où chaque décision est explicite plutôt qu'implicite.

Faut-il apprendre ce langage en 2026 ?

Si vous allez toucher à WordPress un jour, il est incontournable

Ce CMS représente 43 % du web. Si vous travaillez en agence, en freelance, ou dans une entreprise qui l'utilise, la probabilité que vous ayez un jour besoin de comprendre un template, modifier un plugin ou corriger un comportement bizarre dans functions.php est très haute. Vous n'avez pas besoin de le maîtriser à fond, mais en avoir les bases vous évitera de vous retrouver bloqué devant un fichier indéchiffrable.

Et acquérir ces notions prend quelques jours pour quelqu'un qui sait déjà programmer. La syntaxe est proche du JavaScript et du Java, les concepts sont les mêmes, et la documentation s'avère exhaustive.

Si vous lancez un projet avec un budget limité

On revient sur l'argument de l'hébergement mutualisé. Si vous développez une solution interne, un produit pour un client, ou votre propre MVP sans financement initial, réduire les coûts d'infrastructure pendant la phase de validation est une décision intelligente. Cet écosystème vous donne accès à des hébergements fonctionnels pour quelques euros par mois. Les performances sont amplement suffisantes pour valider un concept, et vous pourrez toujours migrer vers une infrastructure plus sophistiquée si le volume grossit.

Si vous maintenez du code existant

Des millions de plateformes tournent grâce à lui aujourd'hui. Si vous rejoignez une équipe dont la stack principale s'appuie sur Laravel ou Symfony, ne pas connaître le langage est un handicap réel. Les recruteurs y sont actifs, les salaires restent comparables aux autres environnements backend, et la demande ne diminue pas. Le fait qu'on n'en parle pas beaucoup dans les conférences à la mode n'est pas un indicateur de désuétude, c'est une preuve de maturité.

Les limites de la technologie

Ce qu'elle ne fait pas bien

Le langage n'est pas adapté au traitement temps réel avec de nombreuses connexions simultanées persistantes. Pour un service de messagerie instantanée, un système de streaming ou un serveur de jeux, des solutions comme Node.js avec sa boucle d'événements ou Go avec ses goroutines sont naturellement plus adaptées. Ici, chaque requête est gérée de façon indépendante, ce qui est un avantage pour la simplicité mais une contrainte pour certains patterns de concurrence.

Pour le machine learning, la data science ou l'automatisation de scripts complexes, Python domine avec un écosystème de bibliothèques sans équivalent. On ne trouve ici ni NumPy, ni Pandas, ni TensorFlow. On peut faire du traitement de données, mais ce serait choisir le mauvais outil pour le mauvais travail.

Ce n'est pas non plus un excellent choix pour les logiciels de bureau ou les programmes système. Ce n'est pas sa vocation et personne ne le lui reproche.

Le domaine où il reste imbattable

Pour un site web classique, une API REST, une interface d'administration, une plateforme e-commerce, un portail client ou un SaaS de taille raisonnable, l'associer à Laravel ou Symfony permet de faire le travail proprement, efficacement, et sans surprises. La documentation est là, la communauté est immense, et les réponses aux problèmes courants existent déjà. C'est exactement le type de projet qui représente l'essentiel des besoins réels des entreprises, et c'est précisément là que cette technologie a passé trente ans à se perfectionner.

Ce choix n'est pas le bon parce qu'il est populaire, ni le mauvais parce qu'il est vieux. C'est un outil mature, bien maintenu, économiquement accessible et techniquement capable pour une large catégorie de projets web. La vraie question n'est pas de savoir s'il est "cool", mais s'il répond à votre besoin mieux qu'une autre option, compte tenu de vos contraintes réelles. Pour beaucoup de structures, la réponse est oui, et il n'y a aucune raison d'en avoir honte.