Tous les langages ont leurs détracteurs. PHP, lui, a des blagues. Elles circulent depuis une vingtaine d'années, elles ressortent dès qu'un fil de discussion porte sur le choix d'un premier langage côté serveur, et elles tiennent en une ligne : PHP n'est pas un vrai langage de programmation.
La phrase est courte, elle ne s'appuie sur rien de précis, et elle suffit pourtant à faire hésiter quelqu'un qui envisageait une formation PHP ou une candidature sur une offre Symfony. Répondre à une critique qui ne dit pas ce qu'elle reproche demande un travail que personne n'a envie de faire un dimanche soir.
Le fond du malentendu tient à un mot que personne ne définit. Un « vrai » langage, mesuré à quoi ? La formule sert à disqualifier sans argumenter, et elle mélange le code hérité qu'on croise dans de vieux projets avec ce que le langage permet en 2026.
Cet article sépare les deux. Origine documentée de la critique, ce qu'elle visait à l'époque, ce que PHP 8.5 met à disposition aujourd'hui, code à l'appui, et les critères qui permettent de trancher pour toi-même la prochaine fois que la remarque tombe.
La remarque, telle qu'elle arrive
Le scénario est toujours le même. Une personne en reconversion demande par où commencer côté serveur. Trente réponses arrivent. Une partie recommande Python, une autre Node, et quelqu'un ajoute que PHP, de toute façon, ce n'est pas de la programmation. Personne ne développe. La discussion part ailleurs et la personne qui posait la question repart avec un doute au lieu d'une réponse.
Quand on demande des précisions, quatre reproches reviennent :
- le langage serait mal conçu, avec des noms de fonctions incohérents et un ordre d'arguments imprévisible ;
- il ne serait pas typé, donc impossible à sécuriser sur un gros projet ;
- il servirait juste à coller des morceaux de HTML entre deux requêtes SQL ;
- il serait lent, et réservé aux sites vitrines sous WordPress.
Ces reproches ont une histoire. Deux d'entre eux ont été justes pendant longtemps, un troisième décrit une pratique de développeur plutôt que le langage, et le dernier ne résiste pas à trois minutes de vérification. Encore faut-il savoir lequel est lequel, et c'est précisément ce que la formule « pas un vrai langage » empêche de faire, puisqu'elle regroupe tout dans un même jugement sans jamais s'exposer à une réfutation.
D'où vient la critique
La documentation officielle de PHP raconte elle-même cette histoire, et elle est plus honnête que ses détracteurs. En 1994, Rasmus Lerdorf écrit en C un jeu de binaires CGI pour compter les visites sur son CV en ligne. Le tout s'appelle Personal Home Page Tools. Le manuel décrit la version suivante, FI, comme un outil CGI qui gagnait des utilisateurs sans être encore un langage.
Le passage au statut de langage est daté, lui aussi. En avril 1996, PHP/FI ajoute les fonctions définies par l'utilisateur et le support de plusieurs bases. En 1997, Andi Gutmans et Zeev Suraski réécrivent complètement l'analyseur syntaxique, et PHP 3.0 est annoncé en juin 1998 avec le support objet et une syntaxe plus cohérente. PHP 4 arrive en mai 2000 sur le moteur Zend, PHP 5 en juillet 2004 avec un nouveau modèle objet.
La réputation, elle, s'est fixée entre 2005 et 2012. À cette période, le langage n'avait pas de déclarations de types scalaires, la bibliothèque standard cumulait des conventions de nommage héritées de dix ans de contributions, et une bonne partie du code publié en ligne concaténait des variables issues d'un formulaire directement dans une requête SQL. L'extension historique mysql, celle qui rendait ces injections si faciles, a été retirée du langage avec PHP 7.0 en 2015.
Mon avis après quatorze ans à écrire du code : la critique était fondée jusqu'à PHP 5.6. Elle a cessé de l'être avec PHP 7, dont le manuel officiel indique qu'il tourne jusqu'à deux fois plus vite que la 5.6. La répéter aujourd'hui renseigne surtout sur la date à laquelle son auteur a ouvert le langage pour la dernière fois.
Quatre critères pour évaluer un langage avant d'y investir six mois
Il n'existe aucune définition technique du « vrai langage de programmation ». Aucun organisme ne délivre ce label. Quand on veut évaluer sérieusement un langage avant d'y investir six mois d'apprentissage, quatre questions donnent des réponses vérifiables.
Qui décide de ce qui entre dans le langage ?
Chez PHP, toute modification du langage passe par une RFC publiée sur le wiki officiel, discutée sur la liste de diffusion internals, puis soumise au vote. Le texte de gouvernance en vigueur exige une majorité des deux tiers pour accepter un changement du langage. Un développeur seul ne peut donc pas ajouter une syntaxe parce qu'il la trouve pratique, et les propositions rejetées le restent, avec leur historique consultable par n'importe qui.
Qui maintient l'implémentation, et avec quel argent ?
La PHP Foundation finance des développeurs qui travaillent sur le cœur du langage. Son rapport trimestriel publié le 21 juillet 2026 fait état de treize contractants répartis dans huit pays, travaillant sur le moteur, les extensions, la sécurité de l'écosystème et les builds Windows. Une équipe payée pour maintenir un interpréteur écrit en C reste un signe assez fiable qu'on a affaire à un langage et non à un bricolage.
Le cycle de vie est-il prévisible ?
Une version mineure par an, sortie en novembre. Chaque branche reçoit deux ans de support actif, puis deux ans de correctifs de sécurité critiques. Le tableau officiel de php.net donne les dates : PHP 8.5, sortie le 20 novembre 2025, est en support actif jusqu'au 31 décembre 2027 puis en sécurité jusqu'au 31 décembre 2029. Pour un responsable technique qui planifie des montées de version, ce calendrier vaut mieux qu'une promesse.
Est-ce que ça tourne en production, ailleurs que dans des tutoriels ?
Relevé W3Techs du 8 septembre 2026 : PHP est détecté sur 70,2 % des sites dont le langage serveur est identifiable, devant JavaScript à 7,2 % et Ruby à 7,0 %. La méthode a ses limites, elle compte des sites et non des développeurs ni du chiffre d'affaires, et elle surpondère les CMS. Elle suffit pour écarter l'idée d'un langage mort.
Ce que PHP 8.5 permet d'écrire
Les exemples ci-dessous ciblent PHP 8.5, version stable au moment où ces lignes sont écrites. Ils utilisent la syntaxe recommandée par la documentation de cette version, pas des écritures antérieures encore tolérées.
Le typage strict, fichier par fichier
Les types scalaires sont arrivés avec PHP 7.0. Avec declare(strict_types=1) en tête de fichier, le moteur refuse les conversions silencieuses et lève une TypeError à l'appel fautif.
<?php
// Tous les exemples de cet article ciblent PHP 8.5
declare(strict_types=1);
function surface(float $largeur, float $hauteur): float
{
return $largeur * $hauteur;
}
surface(3, 4); // 12.0 : un entier est élargi en flottant
surface('3', 4); // TypeError : le paramètre $largeur attend un floatLa déclaration s'applique au fichier dans lequel elle est écrite, ce qui permet d'introduire le typage strict progressivement sur un projet existant.
Objets immuables et énumérations
Les énumérations existent depuis PHP 8.1, les classes en lecture seule depuis 8.2. PHP 8.5 ajoute la modification de propriétés pendant le clonage, ce qui rend enfin lisible le motif des méthodes qui renvoient une copie modifiée.
enum Statut: string
{
case Brouillon = 'brouillon';
case Publie = 'publie';
}
final readonly class Article
{
public function __construct(
public string $titre,
public Statut $statut = Statut::Brouillon,
) {}
public function publier(): self
{
return clone($this, ['statut' => Statut::Publie]);
}
}
$brouillon = new Article('PHP est-il un vrai langage');
$publie = $brouillon->publier();
var_dump($publie->statut === Statut::Publie); // bool(true)
var_dump($brouillon->statut === Statut::Brouillon); // bool(true)L'objet de départ n'a pas bougé. Un statut ne peut prendre que les valeurs déclarées dans l'énumération, et une faute de frappe sur une chaîne devient une erreur détectée avant l'exécution par les outils d'analyse statique.
Les hooks de propriété, à la place des getters et setters
PHP 8.4 a introduit les hooks de propriété. La logique de lecture et d'écriture se déclare sur la propriété elle-même, sans écrire deux méthodes pour chaque champ.
class Utilisateur
{
public string $email {
set (string $value) {
$this->email = mb_strtolower(trim($value));
}
}
public function __construct(string $email)
{
$this->email = $email;
}
}
$utilisateur = new Utilisateur(' Adel@LaPolaris.FR ');
echo $utilisateur->email; // adel@lapolaris.frL'opérateur pipe
Nouveauté de PHP 8.5, l'opérateur |> enchaîne des appels de gauche à droite. Les fonctions imbriquées qui se lisaient de l'intérieur vers l'extérieur se lisent maintenant dans l'ordre d'exécution.
$slug = ' PHP est un vrai langage '
|> trim(...)
|> mb_strtolower(...)
|> (fn (string $texte) => str_replace(' ', '-', $texte));
echo $slug; // php-est-un-vrai-langageAjoute à ça les attributs natifs depuis 8.0, les fibres depuis 8.1, la visibilité asymétrique depuis 8.4 et l'extension URI intégrée en 8.5, et la liste des choses qu'on reprochait au langage en 2010 se réduit sérieusement. Ces mécanismes se travaillent dans la formation PHP orienté objet, et les bases côté serveur dans PHP moderne.
Les pièges qui entretiennent le malentendu
Juger le langage sur le parc installé
Le même relevé W3Techs du 8 septembre 2026 montre que parmi les sites qui utilisent PHP, 63,5 % tournent en version 8, 28,5 % en version 7 et 7,9 % en version 5. Plus d'un tiers du parc fonctionne donc sur une branche sans support. Le code qu'on croise en ouvrant un vieux projet ne dit rien de ce que le langage permet, il dit que personne n'a payé la montée de version.
Attendre du JIT qu'il accélère un site
L'annonce officielle de PHP 8.0 est explicite sur ce point : le JIT en mode tracing donne environ trois fois mieux sur des tests synthétiques et de 1,5 à 2 fois sur certaines applications longues, mais les performances d'une application typique restent au niveau de PHP 7.4. Activer le JIT sur un site lent ne réglera rien. Les gains viennent d'OPcache, des requêtes SQL et de l'architecture.
Oublier que le typage strict est déclaratif
Sans declare(strict_types=1), PHP applique le mode coercitif et convertit ce qu'il peut. Un fichier qui oublie la ligne accepte une chaîne là où un entier était annoncé. Sur un projet à plusieurs, la ligne se met dans le modèle de fichier de l'éditeur et se vérifie en intégration continue.
Croiser les fonctions de chaîne historiques et l'UTF-8
Les fonctions comme strtolower() ou strlen() raisonnent en octets. Sur du texte accentué, elles renvoient des résultats surprenants, d'où les versions mb_* utilisées dans les exemples plus haut. Cet héritage existe, il s'explique par la compatibilité ascendante, et c'est le genre de détail qui alimente les moqueries quand on le découvre en production.
Confondre le langage et son application la plus visible
Beaucoup de développeurs ne rencontrent PHP qu'à travers un thème WordPress modifié à la main. C'est une porte d'entrée légitime, elle donne du travail, et elle ne représente qu'une fraction de ce qui s'écrit en PHP. Une application Symfony avec injection de dépendances, tests automatisés et analyse statique n'a plus grand-chose en commun avec un fichier functions.php de 2 000 lignes. La roadmap Symfony détaille cet écart étape par étape.
Rester sur une branche en fin de vie
Le tableau officiel des versions supportées est net : PHP 8.2 ne reçoit plus que des correctifs de sécurité critiques jusqu'au 31 décembre 2026, et le support actif de PHP 8.3 s'est arrêté fin 2025. Un projet qui démarre aujourd'hui vise 8.4 ou 8.5. Un projet existant regarde d'abord la date de fin de support de sa branche, et ensuite seulement les nouveautés de syntaxe.
Alors, vrai langage ou pas
PHP a une grammaire, un moteur d'exécution écrit en C, un système de types, un gestionnaire de dépendances, des outils d'analyse statique, un processus de décision documenté et une fondation qui paie treize personnes pour l'entretenir. La question de départ n'a pas de réponse technique parce qu'elle n'était pas une question technique.
Reste une chose que cet article ne tranchera pas à ta place : savoir si c'est le bon langage pour toi. Ça dépend du marché que tu vises, des offres autour de chez toi et du type de projets qui te motivent. Si tu passes par Symfony, la formation Symfony 7 couvre le passage du langage au framework professionnel.
La prochaine fois que la remarque tombe dans un fil de discussion, une question suffit à voir ce qu'elle vaut : sur quelle version.
