#[AllowDynamicProperties] PHP 8.2 : autoriser une propriété dynamique choisie

« Deprecated: Creation of dynamic property Client::$telephone_mobile is deprecated » : ce message, ou une variante avec un autre nom de classe et de propriété, envahit soudainement le journal d’erreurs d’un site après une montée en PHP 8.2. La cause est connue : PHP déprécie désormais la création de propriétés d’objet qui n’ont pas été déclarées dans la classe.

Face à ce constat, deux réactions se présentent naturellement à un développeur qui maintient une extension WordPress construite avant cette version : réécrire chaque classe pour déclarer explicitement toutes ses propriétés, ou s’appuyer sur l’attribut #[AllowDynamicProperties] introduit précisément pour ce cas de figure. Comparons les deux approches.

Ce que change réellement PHP 8.2

Avant PHP 8.2, il était courant d’écrire du code comme $client = new Client(); $client->telephone_mobile = '0600000000'; même si la classe Client ne déclarait pas cette propriété. PHP créait alors la propriété à la volée, silencieusement. À partir de PHP 8.2, ce comportement déclenche un avertissement de dépréciation — pas encore une erreur fatale, mais un signal que ce comportement disparaîtra dans une future version majeure du langage.

Les classes qui héritent de stdClass, celles qui utilisent la magie __get/__set, ou celles marquées par l’attribut #[AllowDynamicProperties] échappent à cet avertissement. C’est ce dernier mécanisme qui offre la solution la plus rapide pour du code existant.

Comparatif : réécrire les propriétés ou autoriser l’attribut

Approche	Avantage	Limite
Déclarer chaque propriété explicitement	Documente réellement la forme de l’objet, aide l’auto-complétion et l’analyse statique	Demande de relire chaque classe concernée, plus long sur une base ancienne
Ajouter #[AllowDynamicProperties] sur la classe	Correction en une ligne par classe, sans risque de régression fonctionnelle	Ne documente rien : la classe reste ouverte à n’importe quelle propriété

Dans les deux cas, le comportement à l’exécution est identique une fois la dépréciation traitée : la propriété dynamique continue de fonctionner. Seule change la manière dont le code communique son intention à un futur lecteur, humain ou outil d’analyse statique.

Utiliser l’attribut concrètement

L’attribut se place juste avant la déclaration de la classe, avec la syntaxe des attributs PHP introduite en PHP 8.0 :

#[AllowDynamicProperties]
class Client {
    public $nom;
    public $email;

    // Le reste du code peut continuer à faire
    // $client->telephone_mobile = '0600000000';
    // sans avertissement de dépréciation.
}

Ce choix convient particulièrement à une classe héritée d’une bibliothèque tierce ou à un modèle de données historique dont la forme exacte n’est pas figée, et où une réécriture complète représenterait un effort disproportionné par rapport au bénéfice.

Pourquoi éviter l’attribut sur du code neuf

Sur une classe fraîchement écrite, ajouter systématiquement #[AllowDynamicProperties] par réflexe reviendrait à se priver d’un vrai gain apporté par PHP 8.2 : la possibilité de détecter, dès l’écriture, une faute de frappe dans un nom de propriété. Sans l’attribut, écrire $client->telephon au lieu de $client->telephone déclenche un avertissement visible immédiatement ; avec l’attribut, cette faute passe silencieusement et crée une propriété jamais lue ailleurs.

• Sur du code neuf : déclarer les propriétés, laisser la dépréciation agir comme garde-fou.
• Sur une classe héritée volumineuse : l’attribut évite une réécriture risquée à court terme.
• Sur une classe qui étend une bibliothèque tierce non maîtrisée : l’attribut reste souvent la seule option praticable.

Un chantier progressif plutôt qu’un correctif global

Certaines équipes sont tentées de désactiver l’affichage des dépréciations dans php.ini plutôt que de traiter le sujet classe par classe. Cette solution masque l’avertissement pour tout le site, y compris pour du code futur qui bénéficierait de la vérification. Traiter le sujet classe par classe avec #[AllowDynamicProperties] là où c’est justifié, et laisser la dépréciation agir ailleurs, donne une meilleure visibilité sur l’état réel du code au fil des mises à jour.

Sur une base de code étendue, mieux vaut traiter la dépréciation classe par classe au fil de l’eau, en documentant celles qui restent volontairement ouvertes, plutôt que de couper l’avertissement d’un seul coup pour tout le projet.

Notre verdict

#[AllowDynamicProperties] n’est pas une solution à appliquer partout par réflexe : c’est un outil de transition, utile pour faire taire une dépréciation légitime sur du code déjà en production sans en changer le comportement. Sur du code neuf, la meilleure pratique reste de déclarer les propriétés attendues, ce qui laisse PHP 8.2 jouer son rôle de garde-fou contre les fautes de frappe silencieuses. Le choix entre les deux dépend donc moins de préférence stylistique que de l’âge et de la stabilité du code concerné.