Qu’est-ce que Laravel : ce que ce choix signifie pour l’entreprise qui commande un système

Ce que l’offre écrit « PHP 8.4, Laravel 13 » n’est pas un détail technique : ces deux lignes fixent jusqu’à quand le système recevra des correctifs de sécurité, ce qui y coûtera en plus, et combien coûtera la reprise par un autre développeur.

L’offre arrive le vendredi après-midi, et dans sa partie technique se trouvent deux lignes que personne ne lit à voix haute en réunion : « PHP 8.4 » et « Laravel 13 ». Le prix se comprend, le délai se comprend, et ces deux lignes ont l’air de la cuisine interne du prestataire — à peu près aussi importantes que le modèle de perceuse avec lequel on percera le trou dans le mur, et c’est pourquoi on les passe d’ordinaire comme un détail technique dont quelqu’un d’autre est responsable. La signature, pourtant, porte sur le document entier, et ce sont précisément ces deux lignes qui déterminent jusqu’à quand le système recevra encore des correctifs de sécurité, ce qui y entraînera une facture mensuelle en plus du prix de développement, et combien coûtera, dans trois ans, sa reprise par quelqu’un d’autre.

Cet article n’est pas là pour dire si PHP est un bon langage et si Laravel est un bon framework, parce que c’est une question à laquelle les développeurs se répondent entre eux et dont l’acheteur n’a rien de pratique à tirer. Il porte sur quatre choses que l’acheteur peut vérifier lui-même, sans connaissance technique : le calendrier de support, la licence, le marché du travail et les conditions de reprise. Les quatre sont publiques, trois d’entre elles sont des dates ou des sommes, la quatrième est ce que l’on peut et ne peut pas savoir du marché, et aucune ne dépend de la conviction avec laquelle l’offre est rédigée — c’est pourquoi il vaut la peine de les contrôler précisément cette semaine-là, tant que le prix peut encore se discuter.

Qu’est-ce que Laravel, qu’est-ce que PHP, et pourquoi ce n’est pas un seul choix

PHP est le langage de programmation dans lequel est écrit le côté serveur du système — la part qui tourne chez le prestataire ou chez votre hébergeur et que l’utilisateur ne voit jamais. Laravel, de son côté, est un framework, c’est-à-dire une base de code déjà écrite en PHP, qui résout ce qui se répète dans presque chaque projet : l’authentification des utilisateurs, les requêtes de base de données, les files d’attente, le stockage des fichiers, l’envoi des courriels. Dans l’offre ils se tiennent côte à côte comme un seul choix, alors que ce sont deux produits distincts, maintenus par deux équipes différentes avec deux calendriers de support différents, et c’est précisément pour cela qu’il vaut la peine de les lire séparément.

Dire à quel point le langage est répandu s’avère plus difficile qu’on ne l’attendrait. W3Techs, qui balaie régulièrement plus de vingt millions de sites, écrit en août de cette année que PHP est utilisé par 70,2 % de tous les sites dont cet outil connaît le langage côté serveur. Cette dernière condition est celle qui disparaît d’ordinaire lorsqu’on recopie le chiffre dans une présentation : il ne s’agit pas de 70 % de tous les sites du monde, mais de 70 % de ceux que cet outil particulier est seulement capable de reconnaître, une part de cette reconnaissance étant d’ailleurs décrite par l’outil lui-même comme déduite indirectement — si la page est WordPress, alors c’est du PHP.

Pour l’acheteur, un autre chiffre de la même page est plus utile. Parmi les sites auxquels W3Techs attribue aussi une version de PHP, 63,3 % tournent sur la huitième, 28,7 % sur la septième et 7,9 % encore sur la cinquième, bien que la septième ait perdu jusqu’aux correctifs de sécurité il y a déjà quatre ans. Cela signifie qu’environ un tiers de l’internet PHP mesurable fonctionne aujourd’hui sur un code auquel plus personne ne fabrique de correctifs, et cela n’est pas arrivé parce que le langage serait mauvais ou parce que quelqu’un aurait commis une erreur de développement. Cela est arrivé parce que personne n’a commandé ni payé un changement de version, et c’est précisément cette part du risque que l’acheteur peut à la fois voir et maîtriser.

Le calendrier de support de PHP est le premier document qu’il vaut la peine d’ouvrir

La règle du groupe des développeurs PHP est brève et publique : chaque branche de version reçoit un support actif pendant deux ans à compter de la première version stable, puis encore deux ans de correctifs de sécurité uniquement, et au bout de quatre ans elle n’est plus maintenue du tout — c’est la fin de vie (EOL). Dans cette règle se trouve un détail que les résumés coupent presque toujours : les véritables dates de fin du tableau sont alignées sur le dernier jour de l’année, et non sur l’anniversaire de publication en novembre, si bien que « deux ans à compter de la sortie » et ce qui est écrit dans le tableau de php.net diffèrent d’un mois ou deux.

Concrètement, cela donne ce qui suit. La version 8.2 n’est plus, en ce moment, qu’en régime de correctifs de sécurité uniquement, et son support s’achève déjà à la fin de cette année, donc dans environ quatre mois. La version 8.3 a perdu le support actif à la fin de l’année dernière et recevra des correctifs de sécurité jusqu’à la fin de 2027, donc encore environ seize mois. La version 8.4 reste en support actif jusqu’à la fin de cette année, puis demeure deux ans en régime de correctifs de sécurité uniquement, tandis que la plus récente, la 8.5, sortie en novembre de l’année dernière, reçoit encore un support actif pendant toute l’année prochaine et des correctifs de sécurité jusqu’à la fin de 2029.

Le support de la version 8.1 s’est achevé le dernier jour de l’année dernière, et c’est précisément ce cas qui mérite attention si vous avez déjà un système, et non une offre. Si le prestataire l’a écrit il y a trois ans sur 8.1 et que personne n’a rien changé depuis, alors il tourne aujourd’hui sur une branche à laquelle les correctifs de sécurité ne viennent plus, et ni le serveur, ni le navigateur, ni le système lui-même n’en avertit. La page s’ouvre exactement comme hier, les clients ne remarquent rien, et le seul endroit où l’on peut le voir est ce même tableau public, que l’on ouvre en moins de temps qu’il n’en faut pour lire la page de titre de l’offre.

Le calendrier de Laravel est plus court que celui de PHP

Laravel formule sa politique plus brièvement encore : correctifs de bogues dix-huit mois, correctifs de sécurité deux ans, et une nouvelle version majeure chaque année vers le premier trimestre. Il n’y a plus, aujourd’hui, de version à support à long terme, que le métier appelle LTS — les anciennes versions en avaient bien une, mais dans le tableau de cette année cette colonne n’existe plus du tout, si bien qu’une offre où il est écrit « LTS Laravel » décrit quelque chose que personne ne vend en ce moment. C’est une promesse plus courte que celle que beaucoup d’acheteurs attendent d’un framework sur lequel on construira le système des cinq prochaines années.

En chiffres, d’après la documentation de Laravel elle-même, l’ordre est le suivant. Laravel 13 est sorti en mars de cette année, recevra des correctifs de bogues jusqu’au troisième trimestre de l’année prochaine, et des correctifs de sécurité jusqu’au 17 mars 2028. La fenêtre de correctifs de bogues de Laravel 12 s’est fermée à la mi-août de cette année, c’est-à-dire dix-sept jours avant l’écriture de ces lignes, et ses correctifs de sécurité s’achèveront en février de l’année prochaine. Le support de sécurité de Laravel 11 s’est achevé au printemps de cette année, donc un système qui tourne aujourd’hui sur la onzième version tourne déjà sans correctifs, si bon qu’il paraisse de l’extérieur.

Prêtez attention au fait que la fin des correctifs de bogues de Laravel 13 est indiquée comme un trimestre, et non comme une date précise. C’est l’imprécision de la formulation de Laravel elle-même, et ce n’est pas un problème tant qu’on la recopie exactement comme elle se trouve là ; le problème commence au moment où le prestataire ou l’acheteur l’arrondit à un jour précis, puis planifie le budget sur un chiffre qui n’est pas dans la source. Une autre limite à connaître avant de choisir la version : Laravel 13 exige au moins PHP 8.3, si bien que l’on ne peut pas laisser un système sur la treizième version avec du 8.2, même si la 8.2 elle-même recevait encore quelque temps des correctifs de sécurité.

Ce que les deux calendriers, ensemble, signifient pour le système que vous commandez aujourd’hui

Si le système est remis sur Laravel 13 avec PHP 8.4 ou 8.5, alors la première date à laquelle quelque chose doit forcément bouger est mars 2028, quand s’achèvent les correctifs de sécurité de Laravel, et c’est environ dix-huit mois et demi à compter d’aujourd’hui. PHP, dans cet assemblage, n’est pas la contrainte, parce que ces deux branches reçoivent des correctifs de sécurité plus longtemps que le framework, si bien que le premier à vieillir est Laravel, et non le langage. C’est aussi la seule façon honnête de répondre à la question « combien de temps ce système tiendra-t-il sans investissement supplémentaire » — non par un sentiment, mais par la plus proche des deux dates publiques.

Si le même système est remis sur Laravel 13, mais PHP 8.3, alors l’ordre s’inverse et la première échéance arrive dans environ seize mois, quand s’achèvent les correctifs de sécurité de cette branche PHP. Si le prestataire construit sur Laravel 12, ce qui, pour un projet existant, reste un choix tout à fait normal, alors les correctifs de sécurité s’achèvent en février de l’année prochaine, et la vie du nouveau système commence avec six mois avant le premier changement de version obligatoire. L’écart entre la première et la troisième option est une année, que l’on peut gagner dans une seule conversation avant le contrat, et que l’on ne peut plus acheter une fois la signature posée.

Deux erreurs, dans ce calcul, sont si répandues qu’il vaut la peine de les nommer à part. La première est de confondre le support actif avec le support de sécurité, si bien qu’en entendant que « le support de PHP 8.4 s’achève à la fin de l’année », il vaut la peine de demander laquelle des deux fenêtres est visée : la correction des bogues ordinaires s’arrête, mais les correctifs de sécurité viennent encore deux ans. La seconde est de croire la phrase de Laravel elle-même, selon laquelle le passage à une nouvelle version majeure prendrait d’ordinaire un jour ou moins ; c’est un objectif formulé par les développeurs, non une moyenne mesurée, et on ne peut pas l’inscrire dans un contrat comme un délai.

La licence coûte zéro, et cela n’est vrai que du langage et du framework

Le framework Laravel est distribué sous licence MIT, qui est l’une des licences open source les plus simples et permet d’utiliser le code, de le modifier et de le revendre, en n’exigeant que de conserver la mention de copyright. Avec PHP, c’est un peu plus complexe, et cette complexité est d’actualité précisément maintenant, parce que la licence change : les versions jusqu’à 8.5 incluse sortent avec la rédaction 3.01 de la licence PHP, mais à partir de 8.6 elles passent à la quatrième rédaction, que php.net lui-même décrit comme une licence « Modified BSD » et qui, en pratique, coïncide avec BSD-3-Clause. Aucune de ces variantes ne prévoit de paiement.

Cela signifie que, pour le langage lui-même et pour le framework lui-même, l’entreprise ne paie ni par utilisateur, ni par cœur de processeur, ni par année, et que ce zéro n’est pas une promotion destinée à s’arrêter un jour. Pour comparaison, le modèle de Microsoft SQL Server convient : la licence s’y calcule soit au nombre de cœurs, soit par serveur assorti de licences d’accès client, l’édition Standard est limitée par le plus petit de ces deux plafonds, quatre sockets de processeur ou vingt-quatre cœurs, et l’édition Express gratuite — par un socket ou quatre cœurs. Nous n’écrivons pas ici de montants précis, parce que le tarif change et qu’il faut le lire chez Microsoft ; pour l’acheteur, c’est le modèle qui se compare, non le chiffre — un produit facture selon le volume de matériel, l’autre ne facture pas du tout.

Pour l’acheteur, cela a deux conséquences qu’il vaut la peine d’écrire tout de suite. La première est agréable : pas d’audit de licences, pas de réévaluation annuelle pour des utilisateurs qui ont augmenté dans l’année, et pas de situation où le fournisseur du logiciel revient au bout de trois ans avec une facture pour une limite dépassée. La seconde est celle que l’on oublie souvent : l’open source enlève la dépendance vis-à-vis du propriétaire du framework, mais n’enlève pas la dépendance tout court. La dépendance se déplace ailleurs — vers l’agence qui seule sait comment le projet est assemblé, vers les produits payants qui se tiennent à côté du code, vers un abandoned package que plus personne ne maintient, et vers une version majeure dont le support s’est achevé. Ces quatre endroits sont ceux que l’acheteur doit vérifier, parce que la ligne de licence n’en dit rien.

Où Laravel commence pourtant à coûter : les produits qui ne sont pas le framework

La même équipe qui maintient Laravel vend aussi plusieurs produits, et dans l’offre ils tendent à se tenir sur la même ligne que le framework, comme s’ils en étaient une pièce. Laravel, sur son propre site, sépare lui-même ces deux choses : les packages — Horizon, Telescope, Pulse, Scout, Sanctum, Octane et d’autres — sont sous licence MIT et gratuits, tandis que les produits sont Cloud, Forge, Nightwatch, Vapor et Nova, et ils coûtent de l’argent chaque mois ou chaque année. Envoyer se vend encore à part. Aucun de ces produits n’est nécessaire pour qu’un système Laravel fonctionne, et c’est précisément pour cela que leur présence dans l’offre est un choix, non une nécessité.

Les prix, en août de cette année, se présentaient ainsi. Forge, avec lequel on gère les serveurs, coûte 12, 19 ou 39 dollars US par mois selon le plan. Nova, qui est un panneau d’administration, coûte 99 dollars une fois pour un projet, avec les mises à jour d’une année, et 79 dollars par an pour poursuivre les mises à jour, tandis que la licence illimitée coûte respectivement 299 et 249 dollars, et qu’elle couvre vos propres projets, non ceux de vos clients. Nightwatch, qui rassemble les événements du système, commence par un plan gratuit et monte jusqu’à 20, 60 et 300 dollars par mois, en ajoutant un supplément pour les événements au-dessus de la limite incluse. Laravel Cloud commence à 5 dollars par mois plus la consommation, et Envoyer coûte de 10 à 50 dollars par mois.

La question, pour l’acheteur, n’est pas de savoir si ces produits sont bons, parce qu’ils le sont d’ordinaire et qu’ils font gagner au développeur plusieurs jours par mois. La question est de savoir lesquels sont inclus dans le prix nommé, sur quel compte ils sont enregistrés, et ce qu’il en advient si vous changez de prestataire dans deux ans. Un abonnement qui se tient sur le compte de l’agence et n’est pas mentionné dans le contrat est précisément cette dépendance que la licence MIT n’enlève pas, parce que MIT parle du code, non du compte dans lequel il est déployé et surveillé.

Que se passe-t-il si le développeur disparaît ?

« N’importe quel développeur Laravel peut reprendre le code » est une phrase juridiquement vraie et pratiquement incomplète, et nous l’avons écrite nous aussi. La licence MIT permet vraiment à une autre entreprise de travailler avec ce code, sans demander d’autorisation ni à nous, ni à l’équipe Laravel. Quatre tout autres choses décident si le nouveau développeur sera utile dès la première semaine, et les quatre peuvent se vérifier avant même que le contrat soit signé.

La première est la version majeure. Une reprise de Laravel 11 vers une nouvelle équipe n’est pas une reprise, mais un projet de changement de version, parce que le support de sécurité y est déjà fini et que le premier travail ne sera pas une fonctionnalité nouvelle, mais le changement de version en retard jusqu’à une version encore maintenue. La deuxième est la distance aux conventions du framework : la documentation de Laravel suppose une disposition donnée des dossiers et des classes, et plus le projet s’en est éloigné, plus l’entrée en matière est chère. Il n’y a pas de chiffre ici, et il n’y en a dans aucune source, il y a seulement une direction ; en revanche l’acheteur peut demander, de façon tout à fait concrète, ce qui, dans le projet, est écrit autrement que par défaut, et de quel besoin cela procédait.

La troisième, ce sont les dépendances, c’est-à-dire les packages tiers sur lesquels le système s’appuie. Composer, qui les gère dans le monde Laravel, conserve un fichier aux versions exactes, et il vaut précisément parce qu’un nouveau développeur peut installer exactement ce que voyait le précédent, et non ce qui est le plus récent aujourd’hui. Ce que ce fichier ne garantit pas, ce sont deux choses : que le package sera encore disponible au téléchargement, et qu’on n’y a pas trouvé, depuis, une vulnérabilité. La commande composer audit montre les deux en un seul appel, et c’est la forme de question la plus courte que l’on puisse poser sur une base de code étrangère.

La quatrième est un abandoned package, et ici les mots trompent. Packagist, le catalogue public de Composer, marque que les mainteneurs se sont arrêtés, mais cela ne signifie pas que le package disparaît ou cesse de fonctionner : swiftmailer continue d’être servi, il a 449 millions d’installations enregistrées, la dernière publication date de 2021, et il a en même temps trois vulnérabilités connues. Dans notre propre base de code de ce site, qui est Laravel 13 avec le panneau d’administration Filament, il y a 109 packages de production et aucun abandoned package — c’est notre chiffre sur notre projet, non une moyenne du métier, parce qu’une moyenne du métier publiée n’existe nulle part.

Quelle est la taille du marché du travail, et pourquoi personne ne dira de chiffre précis

À la question de savoir s’il est facile, en France, de trouver quelqu’un qui reprend le système, la réponse honnête est qu’il n’existe pas de statistique publique sur les développeurs PHP ou Laravel en France. Il y a des données indirectes, et elles valent exactement autant qu’on les décrit avec précision. Dans l’enquête PHP de JetBrains de l’année dernière, parmi 1 720 personnes pour qui PHP est le langage principal, 64 % travaillent avec Laravel, 25 % avec WordPress et 23 % avec Symfony ; le travail de terrain a eu lieu au printemps, l’enquête est biaisée en faveur des utilisateurs d’outils JetBrains, ce que l’entreprise reconnaît elle-même, et les plus grands groupes de répondants viennent du Japon, des États-Unis, de Russie, de Chine et de France, non des pays baltes.

Au niveau européen, Eurostat, en mai de cette année, indique que l’année dernière 10,45 millions de spécialistes des technologies de l’information et de la communication travaillaient dans l’Union européenne, soit 5,0 % de l’ensemble des personnes occupées et 2,6 % de plus que l’année précédente. Pour la France, une compilation antérieure de la même source donne un autre chiffre, plus utile à l’acheteur que la croissance d’ensemble : en 2023, 7,68 % des entreprises françaises cherchaient ou tentaient d’embaucher de tels spécialistes. Le taux français de postes restés vacants n’est pas publié (fiabilité insuffisante) ; parmi les entreprises européennes qui cherchaient, 57,5 % n’arrivaient pas à pourvoir le poste.

Ces chiffres portent sur les spécialistes du secteur dans leur ensemble, non sur PHP, et on n’a pas le droit de les recopier comme une affirmation sur le marché du travail Laravel en France — ni nous, ni le prestataire qui les citerait dans votre offre. Nous-mêmes, sur notre page de service, avons écrit qu’il est facile de trouver des développeurs qui reprennent le travail ; en préparant cet article, nous n’avons pas trouvé de source à cette affirmation, c’est pourquoi nous ne la répétons pas ici. Pour l’acheteur, la séquence pratique est de toute façon autre : non pas croire à la taille du marché, mais faire en sorte que la base de code soit telle qu’une personne nouvelle y entre à bas coût, indépendamment du nombre de telles personnes.

Où nous traçons nous-mêmes la limite dans une offre

Nous écrivons du Laravel depuis 2013, année de sortie de sa quatrième version, et cela signifie en pratique que nous sommes passés plusieurs fois par exactement ce contre quoi cet article met en garde — un changement de version majeure, qui n’est pas le travail d’une journée et que l’on ne peut pas faire entre d’autres tâches. Notre page de développement de systèmes Laravel indique un prix et des délais, et c’est une conversation à part ; dans cet article, il n’y a que ce que l’on peut vérifier dans une offre, indépendamment de qui l’a écrite et de la qualité de la rédaction.

Ce que nous n’affirmons pas, c’est que n’importe quel développeur reprend n’importe quelle base de code avec la même facilité, parce que la section précédente dit le contraire. Ce que nous affirmons est plus concret et plus vérifiable : le dépôt est au client dès le premier jour, il y a le fichier des dépendances, la documentation et la configuration de déploiement, et au moment de la remise la version est celle qui reçoit encore des correctifs de sécurité. Si vous avez l’impression que le choix est en réalité entre un produit du marché et un système sur mesure, alors c’est une autre conversation, que nous avons écrite à part, et si la question porte précisément sur un site e-commerce, alors la comparaison WooCommerce et Laravel répond plus précisément que cet article.

Concrètement, le dossier de remise comprend le dépôt avec tout l’historique, le fichier des dépendances aux versions exactes, un README avec les étapes de lancement, la configuration de déploiement et l’accès à tous les comptes dans lesquels le système fonctionne. C’est ce que l’on peut promettre et vérifier. Ce que l’on ne peut pas promettre, c’est le marché : combien de personnes, en France, prendront ce travail et à quel prix n’est pas entre nos mains et n’est dans aucune statistique publique, c’est pourquoi nous ne répondons pas à cette question par un chiffre convaincant. La seule chose qui, ici, travaille vraiment en faveur de l’acheteur, c’est que la base de code est ordinaire, que la version est encore prise en charge et que la documentation est écrite à ce moment-là, non reportée à la semaine de la remise.

Que demander avant de signer

La première question porte sur les dates : quelle version majeure de Laravel et quelle branche PHP seront dans le système le jour même de la remise, et quand s’achèvent leurs correctifs de sécurité. La réponse est deux dates, on peut les vérifier toutes les deux sur deux pages publiques en cinq minutes, et il faut les inscrire soit dans le contrat, soit au moins dans la correspondance. Si le prestataire nomme une version dont le support s’achève plus tôt que la durée de garantie, ce n’est pas interdit et c’est parfois même fondé, mais alors les deux parties doivent le savoir, et le prix doit rendre clair qui paiera le passage.

La deuxième question porte sur les abonnements : quels produits payants — Forge, Cloud, Nova, Nightwatch, Vapor ou Envoyer — sont nécessaires au fonctionnement du système, combien ils coûtent ensemble par mois et sur quel compte ils se tiennent. La troisième porte sur le dépôt : à partir de quel jour il est le vôtre, s’il y figure le fichier des dépendances et si le contrôle automatique inclut la commande composer audit. La quatrième est la question d’argent que l’on remet d’ordinaire à plus tard et que l’on trouve ensuite, par surprise, dans le budget : qui paiera le changement de version majeure dans un an et demi, et s’il entre dans un contrat de maintenance ou s’il sera une nouvelle commande.

Aucune de ces quatre questions n’exige que vous compreniez le code, et aucune n’est à prendre pour de la méfiance envers le prestataire. Toutes portent sur ce qui se passera une fois le projet terminé et la facture payée, et un bon prestataire y répond tout de suite, parce qu’il connaît ces dates par cœur. Si la réponse à l’une d’entre elles prend une semaine ou se transforme en explication de pourquoi la question n’est pas importante, alors c’est déjà une réponse.

Ces quatre questions ne remplacent pas une évaluation technique et ne répondent pas à la question de savoir si l’architecture proposée est bonne, mais elles évitent la plus grande part des mauvaises surprises qui arrivent d’ordinaire la deuxième ou la troisième année, quand l’enthousiasme du début s’est éteint et que le système, simplement, fonctionne. Si vous avez une offre en main et n’êtes pas sûr de ce que les versions qui y sont écrites signifient pour vos délais et votre budget, écrivez-nous — on peut préparer une réponse à ces quatre questions sans ouvrir le code.