# Les property hooks de PHP 8.4 appliqués à un outil maison de supervision serveur

> Comment les property hooks de PHP 8.4 remplacent les paires get/set d'un tableau de bord interne et simplifient la validation d'une métrique lue et écrite.

- Auteur : Clément Hadrot
- Publié le : 2025-03-06
- Mis à jour le : 2025-03-06
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/property-hooks-php-84-outil-supervision-serveur/

## L’essentiel

- Une syntaxe get/set directement sur la propriété
- Validation centralisée sans dupliquer les accesseurs
- Compatible avec un tableau de bord de métriques existant

`public float $value { get; set; }` : cette ligne suffit désormais à remplacer une paire de méthodes `getValue()` et `setValue()` qui traînait dans le code depuis des années. PHP 8.4, sorti en novembre 2024, introduit les property hooks, une fonctionnalité qui change la façon d'écrire les classes de données dans un outil interne, notamment un tableau de bord de supervision serveur où chaque métrique doit être validée avant d'être stockée.

Ce billet ne parle pas des extensions WordPress ni de leur compatibilité avec PHP 8.4, un sujet déjà traité par ailleurs. Il s'agit ici d'un cas concret : un petit outil maison, développé en PHP pur, qui collecte des métriques (charge CPU, latence de requête, taux d'erreur PHP-FPM) et les affiche sur une page interne. Ce type d'outil accumule vite des accesseurs répétitifs, et les property hooks apportent une réponse directe à ce problème.

## Le problème des accesseurs répétitifs

Avant PHP 8.4, la seule façon de valider une valeur au moment de son affectation consistait à rendre la propriété privée et à écrire un accesseur dédié :

```
class MetricGauge
{
    private float $raw = 0.0;

    public function getValue(): float
    {
        return round($this->raw, 2);
    }

    public function setValue(float $value): void
    {
        if ($value < 0) {
            throw new InvalidArgumentException("La valeur ne peut pas être négative.");
        }
        $this->raw = $value;
    }
}
```

Sur une classe qui expose une dizaine de métriques, cela représente vingt méthodes pour un comportement finalement très simple. Le code devient verbeux, et chaque nouvelle métrique impose de recopier le même schéma.

## Ce que changent les property hooks

Avec PHP 8.4, la même classe s'écrit directement sur la propriété publique, sans perdre le contrôle sur la lecture et l'écriture :

```
class MetricGauge
{
    private float $raw = 0.0;

    public float $value {
        get => round($this->raw, 2);
        set {
            if ($value < 0) {
                throw new InvalidArgumentException("La valeur ne peut pas être négative.");
            }
            $this->raw = $value;
        }
    }
}
```

> L'essentiel à retenir : Une syntaxe get/set directement sur la propriété ; Validation centralisée sans dupliquer les accesseurs ; Compatible avec un tableau de bord de métriques existant

La propriété `$value` reste publique du point de vue de l'appelant : `$gauge->value = 42.5;` continue de fonctionner exactement comme si la propriété n'avait aucune logique associée. Mais chaque affectation passe désormais par le bloc `set`, et chaque lecture par le bloc `get`, sans qu'il soit nécessaire d'exposer deux méthodes séparées.

## Application au tableau de bord de supervision

Dans l'outil maison utilisé ici, chaque serveur du parc remonte ses métriques via une requête HTTP interne toutes les trente secondes. Ces valeurs sont ensuite injectées dans des objets `MetricGauge` avant d'être affichées. Les property hooks permettent d'ajouter une contrainte métier directement là où la donnée entre dans le système :

- Rejeter une latence négative, symptôme d'une horloge desynchronisée entre deux collecteurs.
- Arrondir automatiquement un pourcentage de charge CPU à deux décimales pour l'affichage, sans dupliquer ce calcul à chaque endroit du code qui lit la valeur.
- Journaliser un dépassement de seuil directement dans le bloc `set`, sans toucher au reste de la classe.

Un autre apport intéressant concerne les propriétés en lecture seule depuis l'extérieur mais calculées à la volée. Le hook `get` seul, sans `set`, permet d'exposer une propriété qui se comporte comme un calcul dérivé :

```
public string $status {
    get => match (true) {
        $this->raw > 90 => "critique",
        $this->raw > 70 => "attention",
        default => "normal",
    };
}
```

Ici, `$gauge->status` retourne toujours un état cohérent avec la valeur brute, sans qu'aucune méthode ne doive être appelée explicitement pour recalculer ce statut.

## Interopérabilité et rétrocompatibilité

Les property hooks n'imposent aucune rupture : une classe qui n'utilise pas cette syntaxe continue de fonctionner à l'identique sous PHP 8.4. C'est un ajout de langage, pas un remplacement des pratiques existantes. Pour un outil interne qui vit depuis plusieurs années, la migration peut donc se faire progressivement, classe par classe, en commençant par celles qui comptent le plus d'accesseurs redondants.

Un point de vigilance concerne la sérialisation. Les frameworks ou bibliothèques qui inspectent les propriétés via la réflexion doivent être à jour pour reconnaître correctement les hooks ; sur un outil maison sans dépendance lourde, ce risque reste limité, mais il vaut la peine d'être vérifié avant une bascule en production.

## En résumé

Les property hooks de PHP 8.4 ne révolutionnent pas l'architecture d'un outil de supervision, mais ils suppriment une source de code répétitif qui s'accumule silencieusement au fil des mois. Sur une classe de métriques comme celle présentée ici, le gain se mesure en dizaines de lignes supprimées et en un seul endroit où la règle de validation est écrite, au lieu de deux. Pour toute équipe qui maintient un outillage interne en PHP pur, c'est une fonctionnalité à adopter dès la mise à niveau vers PHP 8.4, sans attendre un projet de refonte plus large.