PHP en 2026 : toujours vivant, et mieux structuré que jamais

PHP est utilisé par 77 % des sites web côté serveur selon W3Techs en 2026. Malgré les prédictions funèbres répétées depuis 10 ans, le langage s'est profondément modernisé. PHP 8.4 (sorti fin 2024) a introduit les property hooks, les asymmetric visibility et des performances encore améliorées. Laravel 12 (Q1 2025) a poussé l'architecture modulaire avec son système de bundles repensé. Symfony 7 a continué d'améliorer le découplage des composants. Dans ce contexte, comment structurer un projet PHP qui dure sans accumuler une dette technique paralysante ?

Le problème du monolithe : quand tout dépend de tout

La plupart des projets PHP démarrent sains. Un fichier index.php, quelques includes, une connexion PDO propre. Puis le projet grandit. Les fonctionnalités s'accumulent. Les développeurs changent. Et progressivement, le code devient un monolithe couplé où toucher la gestion des emails casse l'authentification, où ajouter une fonctionnalité push nécessite de comprendre 15 fichiers qui s'appellent mutuellement. ADRD Workspace est né de cette frustration vécue sur des projets clients.

La solution : 10 modules autonomes avec interfaces claires

ADRD Workspace est structuré en 10 modules indépendants, chacun avec son propre répertoire, ses migrations, ses tests et son interface API interne :

Les règles d'or de la modularité PHP

Trois règles ont guidé la conception et maintenu l'architecture saine sur 3 ans :

  1. Pas de dépendance directe entre modules : les modules communiquent exclusivement via un bus d'événements interne (EventEmitter maison, 80 lignes) ou via l'API gateway. Module A n'importe jamais directement une classe de Module B.
  2. Chaque module est testable en isolation : un test unitaire de module Chat IA ne doit pas avoir besoin d'une connexion BDD réelle ni du module Portal opérationnel. Les dépendances sont mockées via des interfaces.
  3. Configuration centralisée, état distribué : la table settings (BDD) contient toute la configuration applicative. Chaque module lit ses paramètres au démarrage sans accès croisé aux configs des autres modules.

Un exemple concret : l'évolution du module Chat IA

En 2023, le module Chat IA appelait directement l'API OpenAI. En 2024, nous avons ajouté Ollama comme alternative locale. En 2025, nous avons intégré Gemini pour certains cas d'usage. À aucun moment ces évolutions n'ont nécessité de modifier le module Communication ou le module Portal. La couche d'abstraction LLMProvider (une interface PHP de 12 méthodes) a absorbé tous ces changements. C'est ça, la modularité en action.

Déploiement module par module

Un avantage méconnu de l'architecture modulaire : le déploiement incrémental. En cas de bug sur le module Push, nous pouvons désactiver uniquement ce module (flag en BDD) sans toucher au reste de l'application. Les utilisateurs continuent de se connecter, de chatter, d'utiliser l'API — seules les notifications push sont suspendues. Ce feature flagging natif réduit le risque de chaque déploiement et simplifie le rollback.

Ce que PHP 8.4 change concrètement

Les property hooks de PHP 8.4 ont simplifié nos Value Objects : plus besoin de getter/setter verbeux, la logique de validation est directement dans la définition de propriété. Les asymmetric visibility permettent de définir une propriété publiquement lisible mais uniquement modifiable depuis la classe (public private(set)), ce qui renforce l'encapsulation sans céder à l'illisibilité des accesseurs classiques. Sur les 10 modules, nous avons réduit le code de définition des entités de 35 % en moyenne après migration PHP 8.4.

Vous repartez de zéro ou vous rénovez un projet PHP existant ? ADRD Consulting peut auditer votre architecture actuelle, identifier les couplages toxiques et proposer un plan de modularisation progressif — sans tout casser, module par module. Prenez rendez-vous.