# Passer une extension de PHP 8.4 à 8.5 : le script de vérification qu’on utilise

> Avant de recommander à un client de monter son serveur en PHP 8.5, un script maison balaie le code de l'extension à la recherche des usages qui méritent une vérification manuelle.

- Auteur : Clément Hadrot
- Publié le : 2026-07-01
- Mis à jour le : 2026-07-01
- Catégorie : Extensions
- URL : https://wpmoderne.dev.wordpress-developpement.fr/extensions/migrer-extension-php-8-4-vers-8-5-script-verification/

## L’essentiel

- Un script de repérage n'est pas un outil de correction automatique
- Les usages à risque se classent par gravité, pas tous au même niveau
- La revue manuelle reste obligatoire sur les points signalés

`php -l` ne suffit jamais à garantir qu'une extension fonctionnera sans accroc sur une nouvelle version majeure de PHP : la syntaxe peut rester parfaitement valide tout en s'appuyant sur un comportement modifié ou déprécié. Avant de recommander à un client de faire monter son serveur de PHP 8.4 vers PHP 8.5, un script maison, exécuté sur l'ensemble du code de l'extension, repère les motifs connus pour mériter une vérification manuelle avant bascule.

Ce billet ne traite pas la migration de PHP 8.3 vers 8.4, déjà largement documentée ailleurs : il porte sur la préparation d'une extension existante, déjà compatible 8.4, avant son passage à la version suivante.

## Pourquoi un script maison plutôt qu'un outil du marché

Des outils d'analyse de compatibilité existent déjà pour PHP, notamment via des jeux de règles PHPCS dédiés. Le script maison décrit ici ne les remplace pas : il les complète en ciblant spécifiquement les motifs propres au code d'extensions WordPress rencontrés en agence — usage de fonctions dépréciées du cœur, appels directs à des fonctions PHP sensibles aux changements de signature, structures de données anciennes encore présentes dans du code repris de clients.

## Le script : une recherche de motifs, pas une correction automatique

```
#!/usr/bin/env bash
# verifier-compatibilite-php85.sh
DOSSIER="${1:-.}"

echo "Recherche des motifs à risque avant montée vers PHP 8.5..."

grep -rn "create_function(" "$DOSSIER" --include="*.php" && echo "-> Fonction supprimée, à remplacer par une closure"
grep -rn "each(" "$DOSSIER" --include="*.php" && echo "-> each() supprimée depuis PHP 8.0, vérifier un reliquat"
grep -rn "\${.*}" "$DOSSIER" --include="*.php" && echo "-> Interpolation de variable à l'ancienne syntaxe, à vérifier"
grep -rln "dynamic" "$DOSSIER" --include="*.php" | xargs -r grep -l "public \$" \
    && echo "-> Propriétés potentiellement dynamiques à contrôler"
grep -rn "strtolower( *null" "$DOSSIER" --include="*.php" && echo "-> Passage explicite de null à vérifier"
```

Ce script ne corrige rien automatiquement : il liste des candidats à revoir, avec un message expliquant pourquoi le motif est signalé. C'est volontaire — une correction automatique sur un motif de recherche textuelle simple risquerait de produire des faux positifs plus coûteux à démêler que l'examen manuel initial.

> L'essentiel à retenir : Un script de repérage n'est pas un outil de correction automatique ; Les usages à risque se classent par gravité, pas tous au même niveau ; La revue manuelle reste obligatoire sur les points signalés

## Compléter avec l'outil de compatibilité PHPCompatibility

Le script maison couvre les motifs spécifiques rencontrés dans le code d'extensions WordPress, mais il ne remplace pas une analyse statique complète. En complément, le jeu de règles PHPCompatibility, exécuté via PHP_CodeSniffer, couvre plus systématiquement les changements de signature de fonctions natives et les dépréciations documentées officiellement.

```
vendor/bin/phpcs --standard=PHPCompatibility --runtime-set testVersion 8.5 chemin/vers/extension
```

## Classer les résultats par gravité avant de les traiter

Tous les motifs signalés ne méritent pas la même urgence. Le script maison classe ses résultats en trois niveaux, affichés séparément dans son rapport final :

- **Bloquant** : usage d'une fonction réellement supprimée d'une version à l'autre, qui provoquera une erreur fatale immédiate.
- **À vérifier** : comportement modifié dans certains cas précis (typage plus strict, gestion différente d'une valeur limite), qui peut fonctionner sans erreur mais produire un résultat différent.
- **Signalement préventif** : usage ancien qui fonctionne encore mais dont la dépréciation est déjà annoncée pour une version ultérieure.

## Exécuter le script sur un environnement de test avant le serveur du client

Le script s'exécute d'abord sur une copie de l'extension installée dans un conteneur de test configuré avec la nouvelle version de PHP, jamais directement sur le serveur de production du client. Cette copie permet également de lancer la suite de tests automatisés de l'extension, quand elle existe, avec le nouvel interpréteur, avant toute recommandation officielle de montée de version.

```
wp --path=/var/www/test-php85 plugin list --status=active
wp --path=/var/www/test-php85 eval-file bin/lancer-tests-fonctionnels.php
```

## Documenter le résultat pour le client, pas seulement pour l'équipe technique

Le rapport final ne reste pas un simple fichier journal technique : il se traduit en une liste synthétique à trois colonnes, présentée au client avant la bascule — point signalé, gravité estimée, action recommandée. Cette traduction évite qu'un client sans compétence technique ne perçoive la migration comme une boîte noire, et facilite l'arbitrage sur les points qui demandent un correctif avant la bascule, contre ceux qui peuvent attendre une prochaine mise à jour planifiée.

## En résumé

Un script de repérage maison, même simple, réduit considérablement le temps passé à relire manuellement l'intégralité d'une extension avant une montée de version PHP. Il ne remplace ni l'analyse statique outillée, ni la revue humaine des points signalés, ni les tests fonctionnels sur un environnement dédié : il sert uniquement à concentrer l'attention là où elle est réellement utile, plutôt que de la disperser sur l'ensemble du code.