# PHP 8.3 et les fonctions dépréciées : l’audit qu’impose chaque montée > PHP 8.3 arrive dans quelques semaines. Certaines fonctions dépréciées de longue date peuvent réintroduire des comportements non sécurisés dans une extension ancienne. - Auteur : WordPress Développement - Publié le : 2023-11-05 - Mis à jour le : 2023-11-05 - Catégorie : Sécurité - URL : https://www.wpmoderne.fr/securite/php-8-3-fonctions-depreciees-audit-montee-version/ ## L’essentiel - Une fonction dépréciée qui échoue silencieusement peut désactiver un contrôle de sécurité sans erreur visible - Tester en environnement de recette avant toute montée de version PHP en production - Les extensions non maintenues depuis plusieurs années sont les plus à risque PHP 8.3 doit sortir dans les prochaines semaines, et sa phase de release candidate est déjà disponible pour qui souhaite tester ses projets en avance. Chaque montée de version majeure de PHP s'accompagne d'un lot de fonctions dépréciées, parfois supprimées, et l'expérience des montées précédentes montre qu'une extension WordPress ancienne peut receler des dépendances à ces fonctions bien plus profondément liées à la sécurité qu'il n'y paraît au premier abord. Sur un projet client audité en amont de cette montée de version, quatre fonctions dépréciées ont été identifiées dans une seule extension métier vieille d'une dizaine d'années, dont deux directement liées à des vérifications de sécurité qui, en cas d'échec silencieux plutôt que d'erreur bloquante, pourraient laisser passer une entrée qui aurait dû être rejetée. Voici la checklist utilisée pour cet audit, transposable à tout projet qui prépare sa compatibilité avec PHP 8.3. ## Pourquoi une dépréciation peut devenir un problème de sécurité Une fonction dépréciée en PHP ne cesse pas immédiatement de fonctionner : elle déclenche généralement un avertissement `E_DEPRECATED`, souvent masqué en production où l'affichage des erreurs est désactivé par convention. Le risque ne vient donc pas d'un plantage visible, mais d'un changement silencieux de comportement à une version ultérieure, ou d'un comportement déjà légèrement différent qui affaiblit une vérification sans qu'aucune erreur ne remonte à l'équipe technique. - Une fonction de validation qui retourne désormais `null` au lieu de `false` dans un cas limite peut passer un test `if ( ! $resultat )` comme valide alors qu'elle signalait un échec. - Un comportement de type dépendant du contexte d'appel (typage implicite modifié) peut changer subtilement le résultat d'une comparaison utilisée dans un contrôle d'accès. - Une extension qui masque ses avertissements avec un `@` devant chaque appel de fonction dépréciée rend ce risque totalement invisible sans audit dédié. ## La checklist d'audit avant montée vers PHP 8.3 > L'essentiel à retenir : Une fonction dépréciée qui échoue silencieusement peut désactiver un contrôle de sécurité sans erreur visible ; Tester en environnement de recette avant toute montée de version PHP en production ; Les extensions non maintenues depuis plusieurs années sont les plus à risque 1. **Lister les fonctions dépréciées ou supprimées annoncées pour PHP 8.3** à partir de la documentation officielle des migrations publiée sur php.net, en priorisant celles liées à la manipulation de chaînes, de tableaux et à la sérialisation. 2. **Rechercher chaque fonction dans le code des extensions du projet**, y compris les extensions tierces non maintenues activement, à l'aide d'un simple `grep` récursif sur le répertoire `wp-content/plugins`. 3. **Activer l'affichage complet des erreurs sur un environnement de recette** dédié, avec `error_reporting( E_ALL )` et `display_errors` activé, pour faire remonter chaque avertissement `E_DEPRECATED` réellement déclenché en usage normal du site. 4. **Prioriser les fonctions liées à une logique de sécurité** : validation d'entrée, comparaison de hachages, vérification de type avant traitement d'une donnée sensible. 5. **Tester chaque parcours critique** (connexion, formulaire de contact, paiement) sur l'environnement de recette avec PHP 8.3 avant toute bascule en production. ### Un exemple concret rencontré durant l'audit ``` function verifier_jeton_legacy( $jeton_recu, $jeton_attendu ) { if ( create_function( '', 'return true;' ) ) { // fonction supprimée return strcmp( $jeton_recu, $jeton_attendu ) === 0; } return false; } ``` Ce code, retrouvé tel quel dans l'extension auditée, combinait deux problèmes distincts : `create_function()`, supprimée depuis PHP 8.0, aurait déjà dû être retirée avant même l'audit PHP 8.3, et la comparaison de jeton via `strcmp()` n'est de toute façon pas une comparaison à temps constant adaptée à un contexte de sécurité. L'audit a permis de remplacer l'ensemble par une vérification moderne utilisant `hash_equals()`, résistante aux attaques par mesure de temps de réponse. ## Distinguer dépréciation et suppression La checklist distingue systématiquement deux catégories, dont le traitement diffère : - **Fonctions dépréciées** : elles continuent de fonctionner mais déclenchent un avertissement ; leur remplacement peut être planifié sans urgence absolue, mais doit figurer sur la feuille de route. - **Fonctions supprimées** : leur appel provoque une erreur fatale bloquante ; leur détection avant la montée de version est impérative, sous peine de site inaccessible dès la mise à jour de PHP. > Une dépréciation qui ne casse rien aujourd'hui reste une dette technique à traiter avant qu'elle ne devienne, à la version suivante, une suppression qui casse tout d'un coup. ## Le cas particulier des extensions abandonnées Sur ce projet, l'extension concernée n'était plus maintenue par son auteur d'origine depuis plusieurs années. Ce constat a soulevé une question qui dépasse la seule compatibilité PHP 8.3 : une extension qui accumule des fonctions dépréciées sans mise à jour corrective est un signal d'alerte plus large sur la maintenance générale du projet, qui mérite d'être documenté et remonté à la décision, indépendamment du correctif ponctuel appliqué en urgence. ## En résumé Chaque montée de version majeure de PHP est l'occasion de réexaminer le code hérité d'un projet WordPress ancien, bien au-delà du seul objectif de compatibilité. L'audit préparatoire à PHP 8.3, mené avant sa sortie officielle grâce aux versions de test disponibles, permet de traiter ces dettes techniques à froid plutôt que dans l'urgence d'une panne de production le jour de la montée de version réelle.