PHP Enterprise : comment les grandes entreprises écrivent leur code

Pourquoi PHP domine encore l'Enterprise (et comment ne pas faire d'erreur)

Quand on entend « PHP », on pense souvent à un site vitrine monté en une soirée ou à un petit blog WordPress. Pourtant, regardez les offres d'emploi des grandes banques, des géants du retail ou des opérateurs télécoms : elles regorgent de postes pour développeurs PHP. Et il ne s'agit pas de « coder vite fait ». C'est ce qu'on appelle le PHP Enterprise. Tout un univers avec ses propres règles, ses patterns architecturaux et sa culture du code review.

En quoi le développement PHP dans une grande entreprise diffère-t-il de celui d'une startup ? Vous ne vous contentez pas d'écrire du code qui « marche ». Vous construisez un système qui doit vivre des années, traverser des dizaines de releases et supporter la charge de milliers d'utilisateurs. Dans cet article, je décortique les spécificités du développement PHP en environnement Enterprise : de l'architecture au déploiement. Attendez-vous à du code, des conseils pratiques et un minimum de blabla.

Architecture : SOLID, couches et zéro magie noire

En Enterprise, la règle numéro un est que le code doit être prévisible et facile à tester. Pas question de « bricoler une requête SQL directement dans le contrôleur ». Dans les gros projets, vous devez suivre les principes SOLID et séparer clairement les responsabilités entre les couches.

Voici l'architecture typique d'une application PHP en Enterprise :

\n
• Couche de présentation — contrôleurs, routes, Middleware.
\n
• Couche applicative — services, DTO, commandes/Handlers (CQRS).
\n
• Couche domaine — entités, Value Objects, repositories (interfaces).
\n
• Couche infrastructure — ORM, API externes, cache, files d'attente.
\n

Voici à quoi cela ressemble en pratique. Au lieu d'écrire du SQL directement dans le contrôleur :

// ❌ Mauvais : mélange des couches\nclass OrderController {\n    public function create(Request $request) {\n        $db = new PDO('mysql:...');\n        $db->exec("INSERT INTO orders (user_id, total) VALUES ({$request->get('user_id')}, {$request->get('total')})");\n        return new JsonResponse(['status' => 'ok']);\n    }\n}

En Enterprise, vous verrez plutôt ceci :

// ✅ Bon : séparation des responsabilités\nclass OrderController {\n    public function __construct(\n        private OrderService $orderService\n    ) {}\n\n    public function create(CreateOrderRequest $request): JsonResponse {\n        $dto = new CreateOrderDTO(\n            userId: $request->getUserId(),\n            total: $request->getTotal()\n        );\n\n        $order = $this->orderService->createOrder($dto);\n\n        return new JsonResponse(['id' => $order->getId()]);\n    }\n}\n\nclass OrderService {\n    public function __construct(\n        private OrderRepositoryInterface $orderRepository,\n        private EventDispatcher $eventDispatcher\n    ) {}\n\n    public function createOrder(CreateOrderDTO $dto): Order {\n        $order = new Order($dto->userId, $dto->total);\n        $this->orderRepository->save($order);\n        $this->eventDispatcher->dispatch(new OrderCreatedEvent($order));\n        return $order;\n    }\n}

Vous voyez la différence ? La deuxième version est testable, réutilisable et facile à modifier. C'est ça, le PHP Enterprise : un code non seulement fonctionnel, mais aussi bien conçu.

Value Objects et typage strict

Dans les gros projets, vous ne verrez jamais string $email en paramètre. On utilise plutôt des Value Objects. C'est du code auto-documenté qui protège des erreurs dès la compilation.

class Email {\n    public function __construct(private string $value) {\n        if (!filter_var($value, FILTER_VALIDATE_EMAIL)) {\n            throw new \\InvalidArgumentException('Email invalide');\n        }\n    }\n\n    public function getValue(): string {\n        return $this->value;\n    }\n}\n\nclass User {\n    public function __construct(\n        private UserId $id,\n        private Email $emai