Le framework PHP qui va vite, sans aller n’importe où

Une bibliothèque plutôt qu’un socle nu

Là où d’autres frameworks fournissent des composants qu’on assemble, Laravel livre l’essentiel déjà branché : authentification, couche de données, files d’attente, tâches planifiées, envoi d’e-mails, notifications, tests. Sur une application métier classique, une bonne part du travail consiste à câbler ces briques — les avoir d’emblée fait gagner des semaines.

C’est ce qui explique sa réputation de rapidité de mise en route. Le revers existe aussi : le confort encourage à s’en remettre au cadre, et une application qui suit trop docilement les conventions devient parfois difficile à faire sortir de ces conventions.

Ce qu’il y a dans la boîte

Concrètement, et c’est ce qui fait gagner les semaines annoncées :

• Eloquent, la couche de données. On décrit les tables comme des objets et leurs relations comme des méthodes ; les requêtes courantes s’écrivent en une ligne. Le revers est connu : mal employé, il produit des requêtes en cascade qu’il faut ensuite débusquer — c’est le premier point que nous regardons sur une application lente.
• Les migrations, qui décrivent le schéma de la base dans le code. La structure se rejoue à l’identique sur un poste neuf, en recette et en production. C’est ce qui rend une application reprenable.
• Artisan, la ligne de commande, où vivent les traitements ponctuels, les imports et tout ce qu’on lance à la main une fois par an.
• Les files d’attente, avec un tableau de bord pour les surveiller.
• La validation, l’authentification et les droits, fournis et éprouvés — trois domaines où réécrire soi-même est une mauvaise idée.
• Les tests, intégrés dès le départ. Sur une application qui doit vivre, ce n’est pas un luxe : c’est ce qui permet de mettre à jour sans trembler.

Le front : trois façons de faire

Le choix se pose tôt et engage la suite.

Les gabarits classiques, rendus côté serveur : le plus simple, le plus rapide à écrire, et suffisant pour un outil interne. Des composants interactifs sans écrire de JavaScript — l’écosystème Laravel propose des outils pour ça, à mi-chemin entre la page classique et l’application. Ou une application front séparée, en VueJS ou React, l’application Laravel ne servant plus que les données.

Nous partons du plus simple et ne montons d’un cran que si l’usage le demande. Une application de gestion interne n’a presque jamais besoin du troisième.

L’écosystème payant, et ce qu’on peut ignorer

Un point que les comparatifs passent sous silence : une partie de l’écosystème Laravel est commerciale — gestion de serveurs, hébergement sans serveur, interface d’administration clé en main. Ce sont de bons produits, et ils ne sont pas nécessaires.

Nous n’en employons aucun : l’exploitation se fait sur notre propre infrastructure, avec les outils qui servent déjà nos autres hébergements. Votre application ne dépendra donc d’aucun abonnement tiers pour être déployée ou administrée — c’est une dépendance de moins, et une facture de moins.

Le rythme des versions

Laravel publie une version majeure par an, avec une fenêtre de correctifs plus courte que celle de certains frameworks d’entreprise. Ce n’est pas un défaut en soi, mais cela suppose de prévoir les montées de version plutôt que de les subir : une application laissée trois ans sans mise à jour devient coûteuse à rattraper.

C’est un point que nous posons au devis, pas après.

Le même avantage économique que PHP

Comme toute application PHP, une application Laravel tourne sur une plateforme mutualisée à ressources dédiées et garanties, sans machine à administrer — là où Java ou Node.js demandent un serveur à eux. Sur un outil interne consulté par quelques dizaines de personnes, cet écart de coût court pendant des années.

Une nuance toutefois, et elle compte : Laravel s’appuie volontiers sur des files d’attente et des ouvriers qui tournent en permanence. Dès que l’application s’en sert vraiment, un serveur privé devient plus adapté.

Laravel ou Symfony

La réponse honnête est que les deux font le travail, et que les projets se ressemblent davantage qu’on ne le dit dans les discussions d’écosystème.

Symfony est le plus répandu en entreprise en France, avec des composants réutilisables et une gouvernance stable — c’est celui que nous employons le plus souvent, notamment pour des extranets et des intranets. Laravel va plus vite à démarrer et couvre plus de besoins d’emblée.

Le critère qui devrait trancher n’est ni l’un ni l’autre de ces arguments : c’est ce que pratique l’équipe qui reprendra le projet. Si vos développeurs sont sur Laravel, le débat est clos.

Ce que nous ne prétendrons pas

Que le choix du framework décide de la réussite du projet. Ce qui la décide, c’est le périmètre de la première version, la qualité du modèle de données et la personne qui saura reprendre le code dans deux ans. Le framework vient après.