Vous avez écrit du code PHP fonctionnel sur la dernière version, vous l’avez poussé en production, et vous recevez une avalanche de rapports de bugs de la part de clients sur des hébergements obsolètes. Cela vous semble familier? Une syntaxe qui vous paraît «évidente» se transforme en erreur fatale sous PHP 7.0. Installer une douzaine de versions périmées en local pour vérifier chaque extrait prend une demi-journée, quand c’est seulement possible.

Le problème est plus profond qu’il n’y paraît. Les anciennes versions de PHP disparaissent des dépôts officiels, ne compilent plus sur les noyaux Linux modernes et entrent en conflit avec les extensions. WordPress tourne encore sur des serveurs où l’hébergeur n’a pas pris la peine de mettre à jour PHP. Résultat: votre plugin ou votre thème casse pour des centaines d’utilisateurs simplement parce que vous avez utilisé un argument typé string ou la syntaxe courte des tableaux.

Mais il existe un outil qui résout ce problème en quelques secondes: 3v4l.org, un testeur de code PHP en ligne gratuit sur plus de 300 versions simultanément. Pas d’installation, pas de machines virtuelles. Dans ce guide, je vais vous montrer comment détecter les incompatibilités avant la mise en production et vous présenter des erreurs bien réelles que nous avons nous-mêmes livrées en production.

💡 Aperçu rapide:

• Collez un extrait de code PHP dans 3v4l.org et exécutez-le sur toutes les versions, de PHP 4.3.0 jusqu’à la dernière 8.5
• Examinez la sortie groupée: le site indique où le code fonctionne, où il génère des erreurs et où le comportement diffère
• Étudiez deux exemples classiques d’incompatibilité qui cassent les plugins WordPress sur les anciens hébergements, avec le code et des liens vers des tests en direct
• Comparez les méthodes de vérification alternatives: conteneurs Docker, PHPBrew, l’inspecteur intégré de PhpStorm, leurs avantages et inconvénients
• Regardez une vidéo en anglais qui montre le workflow TemPHPest + 3v4l directement depuis VSCode

Pourquoi l’installation manuelle d’anciennes versions de PHP est pénible

Si vous administrez un serveur Linux, vous l’avez forcément remarqué: les anciennes branches de PHP non maintenues disparaissent tout simplement des gestionnaires de paquets. Le dépôt ppa:ondrej/php, principale source de paquets PHP pour Ubuntu, prévient honnêtement lors de l’installation:

Seules les versions de PHP prises en charge pour les versions d’Ubuntu prises en charge sont fournies.

En juin 2026, les branches officiellement prises en charge sont 8.2, 8.3, 8.4 et 8.5. PHP 8.1 a pris sa retraite en décembre 2025. PHP 7.4 appartient depuis longtemps à l’histoire. Mais sur les hébergements mutualisés et les VPS obsolètes, on rencontre encore PHP 7.0, voire 5.6. Vérifier son code par rapport à ces versions en local relève du parcours du combattant.

PHPBrew a longtemps sauvé la mise: l’utilitaire pouvait compiler n’importe quelle version de PHP depuis les sources et basculer de l’une à l’autre avec une seule commande. Mais le projet n’a quasiment pas été mis à jour depuis 2020, et compiler PHP 5.6 sur un noyau Linux 6.x est un véritable casse-tête, entre correctifs et drapeaux de compatibilité. Les conteneurs Docker sont plus simples, mais ils exigent d’écrire un Dockerfile pour chaque version, de télécharger les images et de sacrifier plusieurs gigaoctets d’espace disque.

Il existe une alternative, et elle fonctionne directement dans votre navigateur.

3V4l.org: votre testeur en ligne pour plus de 300 versions de PHP

3v4l.org (leetspeak pour «eval») est un bac à sable en ligne qui exécute votre code PHP sur plus de 300 versions de l’interpréteur simultanément. De l’antique PHP 4.3.0 jusqu’au tout dernier 8.5. Le créateur du projet a compilé et maintient chaque version significative publiée au cours de l’histoire du langage.

Le mécanisme est simple jusqu’au génie: collez un extrait dans le panneau de gauche, cliquez sur eval(), et en quelques secondes vous obtenez un tableau de résultats. Le site regroupe les versions par sortie: les lignes vertes signifient que le code s’est exécuté de manière identique, les jaunes/rouges indiquent un comportement différent ou une erreur. Vous voyez immédiatement à partir de quelle version minimale de PHP votre syntaxe devient acceptable.

Ce qui est particulièrement précieux: 3v4l.org affiche le texte de l’erreur pour chaque version problématique. Pas un abstrait «incompatible», mais un concret Parse error: syntax error, unexpected '[' in ..., avec le numéro de ligne indiqué. Cela fait gagner des heures de débogage.

Chaque test reçoit une URL unique, le lien peut être joint à un ticket, envoyé à un chef de projet ou utilisé comme documentation: «Voici la preuve que les expressions match cassent sous PHP 7.4.»

Exemple 1: la syntaxe courte des tableaux, une mine pour WordPress

Un développeur écrit en JavaScript, passe à PHP et, par habitude, crée un tableau:

1
$a = [];

Cela semble inoffensif. Sur votre machine locale avec PHP 8.4, cela fonctionne. Sur un serveur de test avec PHP 8.2, cela fonctionne aussi. Vous poussez en production, et les clients sous PHP 5.6 obtiennent un écran blanc.

La syntaxe courte des tableaux [] n’est apparue qu’en PHP 5.4. Avant cela, uniquement array(). Et bien que PHP 5.4 soit sorti en 2012, les statistiques de WordPress.org ont montré pendant des décennies une part significative d’installations sur des versions de PHP inférieures à 5.4. La situation s’est améliorée aujourd’hui, mais les plugins WordPress doivent encore tenir compte des nuances de compatibilité.

Exécutez cet extrait sur 3v4l.org, et vous obtenez un verdict sans appel:

1
PHP 5.3.x and older: Parse error: syntax error, unexpected '['
2
PHP 5.4.x and newer: OK

Pas de conjectures, pas besoin de consulter la documentation pour chaque construction. Gain de temps: 30 secondes au lieu de 15 minutes à chercher «quelle version de PHP prend en charge la syntaxe courte des tableaux».

Exemple 2: les indications de type, quand le code casse silencieusement sur un vieux PHP

Les déclarations de type rendent PHP plus strict et plus prévisible. Mais l'évolution des indications de type a été inégale, ce qui crée un piège. Regardez ce code:

1
function handleException(Exception $e) {}
2
function greet(string $name) {}
3
function processItems(array $items) {}
4
 
5
handleException(new Exception('Test'));
6
greet("hello");
7
processItems([1, 2, 3]);

On dirait trois déclarations identiques. Pourtant, un test sur 3v4l.org révèle une surprise:

Les types scalaires string, int et bool ne sont arrivés qu'avec PHP 7.0, soit 12 ans après les types de classe! Si votre plugin déclare une version minimale de PHP 5.6 et que vous utilisez function register(string $username), cela produit sur un hébergement ancien une erreur fatale cryptique:

1
Catchable fatal error: Argument 1 passed to greet() must be an instance of string,
2
string given in...

Le message est déroutant: «must be an instance of string, string given». Le client lit cela comme du charabia et rédige un avis furieux. La raison est simple: PHP 5.6 ne comprend pas les indications de type scalaires et tente d'interpréter string comme un nom de classe.

Avec 3v4l.org, vous détectez ce genre d'incompatibilités en une minute, et non après une dizaine de rapports de bugs.

Alternatives: IDE, Docker et utilitaires en console

3v4l.org couvre la plupart des scénarios de vérification de compatibilité, mais pas tous. Voici ce que l'on trouve d'autre dans l'arsenal, avec leurs avantages et inconvénients.

PhpStorm. L'inspecteur intégré de JetBrains signale la syntaxe incompatible avec la version de PHP sélectionnée: vous indiquez «PHP 7.4» dans les paramètres, et l'éditeur souligne match(), les propriétés typées, str_contains(). Cependant, PhpStorm est payant (abonnement à partir de 99 $/an) et la vérification est statique, il n'y a pas d'exécution réelle du code. L'inspecteur ne montrera pas la différence de comportement de array_key_last() entre les versions, alors que 3v4l.org le fera.

Docker. L'approche la plus flexible: docker run -v $(pwd):/app php:5.6 php /app/test.php exécute le code dans un environnement précis. Mais tester 10 versions nécessite 10 conteneurs, 10 images différentes et un script d'automatisation. Pour une vérification rapide d'un extrait, c'est disproportionné.

PHPBrew en local. Comme mentionné plus haut, le projet est gelé, et compiler d'anciennes versions de PHP sur un noyau moderne demande de jongler avec des correctifs. En 2026, il est plus simple d'ouvrir 3v4l.org.

GitHub Actions / CI. Une matrice de versions PHP dans la CI (par exemple, strategy.matrix.php: ['7.4', '8.0', '8.1', '8.2', '8.3', '8.4', '8.5']) détecte les problèmes à chaque envoi de code. C'est indispensable pour les bibliothèques, mais pour les auteurs de plugins WordPress qui codent dans Sublime Text ou VSCode sans CI, 3v4l.org reste l'outil le plus accessible et le plus rapide.

Vidéo: TemPHPest + 3v4l directement depuis VSCode

L'extension TemPHPest pour VSCode intègre 3v4l.org dans l'éditeur: sélectionnez du code, appuyez sur un raccourci clavier et obtenez les résultats sur toutes les versions de PHP sans ouvrir de navigateur. L'auteur de l'extension a enregistré une courte démonstration:

La combinaison VSCode + TemPHPest + 3v4l.org offre une expérience quasi transparente: écrivez le code, vérifiez immédiatement la compatibilité, corrigez les erreurs. Cela fonctionne plus vite que de passer sans cesse de l'éditeur au navigateur.

⁉️🤔 Questions fréquentes

3v4l.org est-il gratuit?

Oui, totalement. Pas d’inscription, pas de limite sur le nombre d’exécutions, pas de publicité. Le service est open source et tourne sur le serveur personnel de son créateur. Si vous l’utilisez régulièrement, vous pouvez soutenir l’auteur via GitHub Sponsors, ce qui aide à couvrir les frais d’hébergement et d’électricité.

Quelles versions de PHP sont disponibles sur 3v4l.org?

Toutes les versions majeures, depuis PHP 4.3.0 (publié en 2002) jusqu’à la dernière 8.5 (novembre 2025). Chaque version mineure correspond à une ligne distincte dans le tableau des résultats. Au total, plus de 300 versions. Si une version dont vous avez besoin n’est pas dans la liste, l’auteur ajoute les nouvelles releases rapidement.

Peut-on tester des projets entiers ou seulement des extraits?

3v4l.org est conçu pour des fragments de code isolés, des fonctions, des classes, des algorithmes individuels. Vous pouvez coller plusieurs centaines de lignes, mais sans require ni include avec l’autoloading de Composer et les connexions à une base de données. Pour des tests d’intégration complets d’un projet, des conteneurs Docker ou GitHub Actions avec une matrice de versions PHP sont plus adaptés.

Est-il sûr de coller du code sensible sur un serveur tiers?

Non. Le code sur 3v4l.org obtient une URL publique et est techniquement accessible via un lien direct. N’utilisez pas le service pour des données confidentielles, des clés API, des mots de passe ou de la logique métier propriétaire. Pour du code propriétaire, exécutez un conteneur Docker en local: docker run -v $(pwd):/app php:7.4 php /app/private-code.php.

En quoi 3v4l.org est-il meilleur que la vérification intégrée d’un IDE?

L’analyse statique dans un IDE (PhpStorm, PHPStan) vérifie la syntaxe et les types, mais n’exécute pas le code. 3v4l.org exécute réellement l’extrait via les interpréteurs de toutes les versions et montre la sortie réelle, les différences de comportement de array_key_last(), json_encode() et preg_match() entre les versions. De plus, cela ne nécessite pas l’achat d’un IDE, cela fonctionne dans un navigateur.

Que choisir pour vérifier la compatibilité du code PHP en 2026

Pour le travail quotidien d’un auteur de thèmes et de plugins, le schéma est le suivant. Un extrait qui soulève un doute passe directement sur 3v4l.org. Résultat en 5 secondes, le lien vers le test est joint au commit. Pour un projet où la compatibilité avec une dizaine de versions de PHP est importante, une matrice dans GitHub Actions: vous la configurez une fois, et chaque push s’exécute automatiquement. Pour une vérification rapide du code de quelqu’un d’autre avant une revue de code, TemPHPest dans VSCode (gratuit, intégré à 3v4l.org).

La principale chose qui a changé par rapport à 2020 (quand la version originale de ce contenu est apparue pour la première fois): PHP 5.6 a finalement quitté la plupart des plateformes d’hébergement, la barre minimale est devenue PHP 7.4, et à l’horizon se profile PHP 8.5 avec de nouvelles fonctionnalités et de nouvelles incompatibilités potentielles. Mais le principe reste inchangé: vérifiez la compatibilité avant la mise en production, dormez sur vos deux oreilles. 3v4l.org rend cette vérification triviale.