Soixante lignes de configuration avant la première ligne de code métier
Ouvrez votre modèle le plus volumineux. Dans beaucoup de projets Laravel, les premières dizaines de lignes ne contiennent aucune logique : un override de $table, un long tableau $fillable, des entrées dans $hidden et $casts, parfois un $touches dont personne ne se souvient plus de l'origine. C'est du bruit. Laravel 13, sorti le 17 mars 2026, apporte enfin une réponse structurée à ce problème : le support des attributs PHP natifs dans plus de quinze emplacements du framework.
Ce que sont les attributs PHP natifs
Les attributs PHP natifs (introduits dans PHP 8.0) permettent d'annoter des classes, des propriétés ou des méthodes avec des métadonnées que le framework peut lire à l'exécution via la réflexion. Syntaxiquement, ils s'écrivent entre crochets #[...] juste au-dessus de la déclaration concernée.
Laravel 13 les exploite pour remplacer les déclarations de propriétés de configuration des modèles Eloquent — et bien au-delà : les écouteurs d'événements, les notifications, les mailables et les événements broadcast bénéficient du même traitement. Le point crucial, signalé par la documentation officielle, est que aucun code existant n'est cassé : les propriétés classiques continuent de fonctionner exactement comme avant. La migration est donc progressive et sans risque.
Avant / après : un modèle Eloquent typique
Avant (style propriétés classiques)
class Server extends Model
{
protected $table = 'servers';
protected $fillable = [
'name',
'ip_address',
'region',
'provider',
'status',
'cpu_count',
'ram_gb',
'disk_gb',
'os_type',
'os_version',
'hostname',
'ssh_port',
'owner_id',
'team_id',
];
protected $hidden = [
'api_token',
'root_password',
];
protected function casts(): array
{
return [
'installed_at' => 'datetime',
'last_seen_at' => 'datetime',
'is_active' => 'boolean',
'cpu_count' => 'integer',
'ram_gb' => 'integer',
'disk_gb' => 'integer',
'config' => 'array',
'tags' => 'array',
'monthly_cost' => 'decimal:2',
];
}
protected $touches = ['team'];
// ... première méthode métier ligne 62
}
Après (style attributs PHP natifs)
#[Table('servers')]
#[Fillable(
'name', 'ip_address', 'region', 'provider', 'status',
'cpu_count', 'ram_gb', 'disk_gb', 'os_type', 'os_version',
'hostname', 'ssh_port', 'owner_id', 'team_id'
)]
#[Hidden('api_token', 'root_password')]
#[Cast('installed_at', 'datetime')]
#[Cast('last_seen_at', 'datetime')]
#[Cast('is_active', 'boolean')]
#[Cast('cpu_count', 'integer')]
#[Cast('ram_gb', 'integer')]
#[Cast('disk_gb', 'integer')]
#[Cast('config', 'array')]
#[Cast('tags', 'array')]
#[Cast('monthly_cost', 'decimal:2')]
#[Touches('team')]
class Server extends Model
{
// première méthode métier ligne 16
}
La logique de configuration remonte au-dessus de la déclaration de classe. Le corps du modèle ne contient plus que du comportement. Pour les équipes qui pratiquent une architecture orientée domaine, ce changement est particulièrement bienvenu : la frontière entre configuration et logique devient visible d'un seul coup d'œil.
Au-delà des modèles : les autres usages
Laravel 13 étend les attributs natifs à d'autres composants :
- Écouteurs d'événements : l'attribut
#[ListensTo(UserRegistered::class)] remplace le tableau de correspondances dans EventServiceProvider.
- Notifications et mailables : certaines métadonnées de routing peuvent être déclarées directement sur la classe.
- Événements broadcast : le canal de diffusion peut être spécifié par attribut plutôt que via une méthode dédiée.
Ces usages restent secondaires par rapport à l'impact sur les modèles, mais ils participent à la même philosophie : rapprocher la configuration de ce qu'elle configure, plutôt que de la centraliser dans des fichiers ou des méthodes délocalisés.
Stratégie de migration progressive
Puisque les deux styles coexistent sans conflit, voici l'approche recommandée pour une base de code existante :
- Mettre à jour Laravel et PHP : les attributs natifs nécessitent PHP 8.0 minimum. Laravel 13 requiert PHP 8.2+.
- Commencer par les modèles les plus lus : les modèles que toute l'équipe ouvre régulièrement bénéficient le plus immédiatement de la lisibilité gagnée.
- Migrer attribut par attribut si nécessaire : rien n'interdit de garder
$fillable comme propriété et de passer $hidden en attribut. La cohabitation est explicitement supportée.
- Profiter de la migration pour auditer : un
$touches dont l'origine est oubliée depuis 2024, un champ dans $fillable qui n'existe plus en base — la réécriture force une relecture bénéfique.
- Mettre à jour les conventions d'équipe : documenter quel style est désormais attendu dans les nouvelles classes pour éviter la divergence progressive.
Il n'existe pas d'outil de migration automatique officiel au moment de la rédaction. La refactorisation reste manuelle, ce qui est en réalité une opportunité : chaque modèle relu est aussi un modèle compris.
Conclusion : une évolution de surface, un impact de fond
Les attributs PHP natifs dans Laravel 13 ne changent pas ce que fait Eloquent. Ils changent l'endroit où vous l'exprimez. Ce déplacement peut sembler cosmétique, mais son effet sur la lisibilité du code — et donc sur la vitesse d'intégration, la revue de code et la réduction de la dette technique — est réel et mesurable dans la durée.
L'article original de Deploynix (publié sur dev.to) illustre ce point à partir de leur propre codebase : soixante lignes de configuration réduites à seize, et un modèle dont le comportement devient immédiatement visible à l'ouverture du fichier.
Si votre prochain projet PHP est en Symfony plutôt qu'en Laravel, cette tendance vous est familière : les attributs PHP y sont utilisés depuis plusieurs versions pour les routes, la sérialisation et la validation. L'alignement progressif des deux frameworks sur cette convention PHP moderne est une bonne nouvelle pour l'écosystème dans son ensemble.
