Les questions qui distinguent une équipe Laravel capable d’une équipe qui a suivi un tutoriel ne portent jamais sur le framework lui-même. Laravel est documenté, cohérent et facile à prendre en main : afficher une liste, enregistrer un formulaire, envoyer un courriel s’apprend en une semaine et se ressemble d’un prestataire à l’autre. Ce qui sépare les équipes, c’est tout ce que le framework ne fait pas à votre place : faire évoluer un schéma de base sans perdre de données, sortir du cycle de la requête ce qui prend plus d’une seconde, écrire des tests qui attrapent les régressions, déployer sans coupure, et reprendre un projet écrit par quelqu’un d’autre.
Cet article donne huit questions à poser en entretien, avec pour chacune la réponse qui distingue une équipe rodée d’une équipe qui découvrira le problème chez vous. Il détaille ensuite ce qu’un devis Laravel doit contenir et qui manque presque toujours, la méthode d’audit d’un projet existant en deux heures, et l’ordre de grandeur de la maintenance annuelle. Une mesure y est posée noir sur blanc : le nombre de requêtes qu’une liste déclenche selon la manière dont elle charge ses données — un nombre qui se compte, pas qui s’estime.
Pourquoi Laravel plutôt qu’un CMS — et quand c’est une erreur
Un système de gestion de contenu vous donne un modèle de données tout fait : des pages, des articles, des produits, des utilisateurs, avec une interface d’administration livrée. Tant que votre besoin rentre dans ce modèle, c’est imbattable : vous n’écrivez rien. Un cadre applicatif comme Laravel ne vous donne aucun modèle de données : il vous donne les outils pour construire le vôtre. Le jour où votre métier ne rentre dans aucune case prévue — des dossiers avec des états, des validations à plusieurs mains, des règles de prix qui dépendent du client et de la date, des flux entrants d’un logiciel de gestion —, ce vide devient un avantage décisif.
La bascule se repère à un signe fiable : le nombre de champs personnalisés et d’extensions qu’il faut empiler dans le CMS pour approcher le besoin. Quand la moitié des écrans de l’administration sont détournés de leur usage d’origine, quand un tableau de suivi est en réalité une liste d’articles avec douze champs libres, la solution n’est plus dans l’outil — elle est devenue un coût permanent de contournement. Nous détaillons le même arbitrage entre framework et framework dans notre comparaison Laravel ou Symfony ; la question CMS ou cadre applicatif se tranche avant celle-là, et elle est plus structurante.
L’erreur symétrique existe, et elle est plus fréquente qu’on ne le croit : choisir Laravel pour un site de quinze pages avec un formulaire de contact. Vous payez alors une construction complète — authentification, administration, gabarits — pour reproduire ce qu’un CMS installe en une heure, et vous vous privez de l’écosystème d’extensions qui fait sa valeur. La règle que nous appliquons est simple : si le cœur du besoin est de publier du contenu, prenez un CMS ; si le cœur du besoin est de traiter des données selon des règles qui vous appartiennent, prenez un cadre applicatif. Un prestataire qui répond « Laravel » avant d’avoir écouté le besoin ne vous renseigne que sur son catalogue.
Les huit questions à poser en entretien
Ces questions se posent à l’oral, en une heure, sans support. Aucune ne demande de compétence technique à celui qui la pose : ce qui s’évalue, c’est la précision de la réponse et la présence de détails qu’on n’invente pas.
| Question | Réponse qui rassure | Réponse qui alerte |
|---|---|---|
| 1. Comment faites-vous évoluer le schéma de base une fois en production ? | Migrations versionnées, jouées automatiquement au déploiement, avec une stratégie pour les colonnes non nulles et une reprise de données écrite | « On modifie la base directement » ou « on exporte, on adapte, on réimporte » |
| 2. Où passe un traitement de trois minutes ? | Dans une file d’attente, avec un travailleur supervisé, des tentatives limitées et une table des échecs relue | Dans la requête, avec un délai d’exécution augmenté |
| 3. Qu’est-ce que vous testez, concrètement ? | Les règles métier et les parcours qui engagent de l’argent, avec un chiffre de couverture qu’on assume plutôt que de viser 100 % | « Tout est testé » sans exemple, ou « on teste manuellement avant chaque livraison » |
| 4. Décrivez votre déploiement, de la validation à la mise en ligne | Étapes nommées, retour arrière prévu, coupure de quelques secondes ou nulle | Un dépôt de fichiers par FTP, ou « on fait un git pull sur le serveur » |
| 5. Comment repérez-vous une page qui déclenche 400 requêtes ? | Une sonde de développement qui compte les requêtes, un journal des requêtes lentes, un seuil d’alerte | « On ne l’a jamais eu » — tout projet un peu vivant l’a eu |
| 6. Qui a accès à la production, et comment ? | Comptes nominatifs, clés, secrets hors du dépôt, journal des accès | Un compte partagé dont le mot de passe circule dans un fil de discussion |
| 7. Que se passe-t-il si nous changeons de prestataire dans deux ans ? | Le dépôt, la documentation d’installation et les procédures sont à vous ; une reprise se prépare en quelques jours | Gêne, ou dépendance à un outil interne non livré |
| 8. Racontez un incident de production que vous avez causé | Un récit précis, avec la cause, la correction et ce qui a changé ensuite | Aucun incident en dix ans — c’est soit faux, soit très peu de production |
La huitième question est la plus révélatrice, et c’est celle que personne ne pose. Une équipe qui livre depuis des années a cassé quelque chose ; ce qu’elle en a fait — un correctif, un test ajouté, une procédure changée — dit tout de sa manière de travailler. Une équipe qui n’a rien à raconter n’a pas de mémoire des incidents, donc pas de mécanisme pour les éviter deux fois.
La question numéro 5 mérite qu’on s’y arrête
Elle porte sur le défaut le plus répandu des applications construites sur un cadre applicatif moderne, et il a un nom : la requête par ligne. Une liste affiche cent dossiers et, pour chacun, le nom du client rattaché. Écrit naïvement, le code exécute une requête pour la liste, puis une requête par dossier pour aller chercher son client : cent une requêtes. Écrit avec un chargement anticipé des relations, il en exécute deux — une pour les dossiers, une pour tous les clients concernés d’un coup.
La différence n’est pas une affaire de goût, elle se compte. Pour une liste de n lignes, le nombre de requêtes vaut n + 1 dans un cas et 2 dans l’autre, quel que soit n :
| Lignes affichées | Une requête par ligne | Chargement anticipé |
|---|---|---|
| 25 lignes | 26 requêtes | 2 requêtes |
| 100 lignes | 101 requêtes | 2 requêtes |
| 500 lignes | 501 requêtes | 2 requêtes |
| 1 000 lignes | 1 001 requêtes | 2 requêtes |
Le banc a été monté : cent mille clients, trois cent mille commandes, un index sur la clé étrangère. On affiche une liste de clients avec, pour chacun, le nombre de commandes et leur total. Deux stratégies : une requête par ligne, ou deux requêtes au total. Médiane de cinq exécutions.
| Lignes affichées | Requêtes | Une requête par ligne | Chargement anticipé | Rapport |
|---|---|---|---|---|
| 25 | 26 contre 2 | 0,3 ms | 0,1 ms | 3× |
| 100 | 101 contre 2 | 1,2 ms | 0,4 ms | 3× |
| 500 | 501 contre 2 | 7,2 ms | 3,1 ms | 2× |
| 2 000 | 2 001 contre 2 | 27,7 ms | 11,8 ms | 2× |
Deux à trois fois : autant dire rien. Et c’est exactement le problème. Sur un poste de développement, où la base est dans le même processus ou sur la même machine, le motif à une requête par ligne ne se voit pas. Il passe la recette, il passe la démonstration, et il part en production.
En production, la base est sur un autre serveur. Ajoutons une milliseconde d’aller-retour par requête — une valeur basse, prise dans le même centre de données.
| Lignes affichées | Une requête par ligne | Chargement anticipé | Rapport |
|---|---|---|---|
| 25 | 26 ms | 2,1 ms | 13× |
| 100 | 102 ms | 2,4 ms | 43× |
| 500 | 508 ms | 5,0 ms | 102× |
| 2 000 | 2 029 ms | 14,7 ms | 138× |
Deux secondes contre quinze millisecondes pour afficher deux mille lignes. Le rapport n’est plus de deux, il est de cent trente-huit, et il croît avec le nombre de lignes parce que chaque ligne ajoute un aller-retour complet. C’est la raison pour laquelle ce défaut se découvre toujours en production et jamais avant : la latence est le facteur que le poste de développement n’a pas.
D’où la question à poser en entretien, et la réponse qui distingue : « combien de requêtes fait la page de liste la plus chargée de votre dernier projet ? » Une équipe qui a installé une sonde de développement affichant le compte de requêtes par page donne un nombre. Une équipe qui répond « ça dépend » n’a jamais regardé.
Demandez à voir cette sonde pendant la démonstration. Une équipe qui l’a installée connaît ses chiffres ; une équipe qui découvre l’outil devant vous découvrira aussi les 400 requêtes de votre tableau de bord, mais plus tard, et à vos frais.
Ce qu’un devis Laravel doit contenir — et qui manque toujours
Un devis de projet sur cadre applicatif décrit en général des écrans et des fonctions. C’est nécessaire et insuffisant : les postes qui explosent en cours de route sont ceux qui ne se voient pas à l’écran. Cinq lignes doivent y figurer nommément.
| Poste | Ce qu’il couvre | Risque s’il est absent |
|---|---|---|
| Environnements | Développement, préproduction, production, avec des données de test réalistes | Les essais se font en production ; les incidents sont visibles des utilisateurs |
| Migrations et reprise de données | Schéma versionné, import de l’existant, contrôles de cohérence après import | Poste redécouvert en fin de projet, systématiquement sous-estimé |
| Traitements asynchrones | Files d’attente, travailleurs supervisés, gestion des échecs et des reprises | Pages qui expirent, courriels perdus, exports qui n’aboutissent jamais |
| Tests automatisés | Couverture des règles métier et des parcours qui engagent de l’argent | Chaque évolution casse une fonction livrée trois mois plus tôt |
| Déploiement et retour arrière | Mise en ligne reproductible, procédure de retour écrite et essayée | Livraisons redoutées, donc espacées, donc massives, donc risquées |
Ces cinq lignes ne sont pas des options de confort : ce sont les postes qui décident si le projet sera encore modifiable dans deux ans. Un devis qui les omet n’est pas moins cher — il est incomplet, et l’écart se paiera en avenants. C’est la même logique que pour un cahier des charges : ce qui n’est pas écrit n’est pas chiffré, et ce qui n’est pas chiffré sera facturé plus tard, dans un rapport de force moins favorable.
La question du déploiement
Le déploiement est le meilleur révélateur de maturité d’une équipe, parce qu’il est impossible à improviser. Une mise en ligne saine suit toujours la même séquence : récupération de la version validée, installation des dépendances à versions figées, exécution des migrations, vidage des caches de configuration et de routes, bascule de l’application vers la nouvelle version, redémarrage des travailleurs de files d’attente. Chacune de ces étapes a une raison d’être, et l’oubli de la dernière est le grand classique : l’application est à jour, les travailleurs tournent encore sur l’ancien code, et des traitements échouent silencieusement pendant des heures.
Deux exigences concrètes à poser. Le déploiement doit être scripté : la même commande produit le même résultat, que ce soit un mardi ou un vendredi soir, et n’importe qui de l’équipe peut la lancer. Et il doit avoir un retour arrière : un moyen de revenir à la version précédente en quelques minutes, essayé au moins une fois. Un déploiement scripté sans retour arrière essayé reste un pari — exactement comme une sauvegarde jamais restaurée.
Demandez enfin à voir où vivent les secrets — clés d’interfaces de programmation, identifiants de base, jetons de paiement. La bonne réponse est : dans la configuration du serveur ou un coffre, jamais dans le dépôt de code. Un fichier .env versionné par mégarde est l’une des fuites les plus banales qui soient, et elle se vérifie en une commande sur l’historique du dépôt.
Reprendre un projet Laravel existant : ce qu’on regarde en deux heures
La reprise d’un projet écrit par une autre équipe est le moment de vérité. Deux heures suffisent pour savoir si le projet est repris ou refait — et une agence sérieuse facture ces deux heures plutôt que de promettre une reprise à l’aveugle.
Ce qu’on regarde, dans l’ordre. L’historique du dépôt : rythme des contributions, taille des lots, présence de messages descriptifs. Un dépôt avec trois commits intitulés « maj » est un projet sans mémoire. Les dépendances : versions figées ou non, retard par rapport aux versions maintenues, et surtout l’existence du fichier de verrouillage — sans lui, deux installations ne donnent pas le même logiciel. Les migrations : le schéma se reconstruit-il à partir de zéro sur une base vide ? Si non, l’environnement de développement n’est pas reproductible, et chaque nouvel arrivant perdra deux jours. Les tests : combien, et passent-ils ? Une suite rouge depuis six mois équivaut à une absence de tests, en plus décourageant. Enfin les surcharges et les traitements planifiés : ce qui tourne la nuit sans que personne ne le regarde est toujours la source des surprises.
Un mot sur le cas le plus délicat, celui où l’équipe sortante et l’équipe entrante doivent se croiser. La bonne pratique est une période de recouvrement courte mais réelle — deux semaines suffisent —, pendant laquelle la nouvelle équipe déploie elle-même au moins une fois, avec l’ancienne disponible pour répondre. Un transfert par documentation seule échoue presque toujours, non par mauvaise volonté, mais parce que la connaissance qui compte n’est pas écrite : elle est dans les gestes du déploiement et dans la liste des choses qu’il ne faut surtout pas toucher.
Le verdict tient en une phrase, qu’il faut exiger par écrit : reprise possible en l’état, reprise après un chantier de remise à niveau chiffré, ou réécriture. Les trois sont des réponses acceptables ; l’absence de verdict ne l’est pas. Et si le projet doit dialoguer avec un logiciel de gestion, l’audit doit couvrir cette frontière en priorité — c’est là que se cachent les traitements les plus fragiles, comme nous l’expliquons dans notre article dédié à connecter un site et un ERP.
Ce que coûte la maintenance d’un projet Laravel
La maintenance d’une application sur cadre applicatif recouvre quatre choses distinctes, qu’il faut séparer dans un contrat pour savoir ce qu’on achète : la mise à jour des dépendances et du langage, la correction des anomalies, la supervision et les interventions d’exploitation, et les évolutions fonctionnelles. Les trois premières sont prévisibles et forfaitisables ; la quatrième ne l’est pas et doit rester en régie.
Sur les montants, nous ne donnerons pas de forfait type : il dépend du volume de code, du nombre d’intégrations et du niveau de disponibilité attendu, et une grille recopiée d’un autre projet serait un chiffre inventé. En revanche, la méthode de chiffrage est transposable : comptez le nombre de mises à jour de dépendances par an que votre prestataire s’engage à traiter, la durée de la fenêtre associée, et le délai de prise en charge d’une anomalie bloquante. Ces trois paramètres, multipliés par un taux horaire que vous connaissez, donnent un budget — et rendent comparables deux propositions qui affichaient des forfaits mensuels incomparables.
Un point d’attention souvent négligé : le rythme de sortie des versions du langage et du cadre applicatif impose son propre calendrier. Une version de PHP cesse d’être corrigée à date connue, publiée à l’avance ; rester dessus signifie faire tourner un socle qui ne reçoit plus de correctifs de sécurité. Vérifiez les dates en vigueur au moment de contractualiser — elles sont publiques — et faites-en une clause plutôt qu’un sujet de discussion annuel. Une équipe de développement Laravel qui planifie ces montées de version d’elle-même vous coûtera moins cher qu’une équipe qui attend que vous les demandiez.
Le tableau des signaux
| Signal observé | Lecture |
|---|---|
| Le devis nomme les environnements, les migrations et les files d’attente | L’équipe a déjà livré en production et sait où va le temps |
| La démonstration montre le nombre de requêtes par page | La performance est mesurée en continu, pas découverte après coup |
| Un incident passé est raconté avec sa cause et sa correction | Il existe une mémoire des incidents, donc un apprentissage |
| Le déploiement est scripté et le retour arrière a été essayé | Les livraisons sont fréquentes, donc petites, donc peu risquées |
| La question du changement de prestataire reçoit une réponse nette | Le projet vous appartient réellement |
| « Tout est testé » sans un seul exemple | Formule de vente : demandez à voir la sortie de la suite de tests |
| Les secrets sont dans le dépôt | Défaut de sécurité élémentaire, et symptôme d’absence de procédure |
| Aucune préproduction prévue au devis | Vos utilisateurs seront la préproduction |
Ce qu’il faut retenir
Choisir une équipe Laravel, ce n’est pas évaluer sa maîtrise du framework — elle est largement partagée — mais sa maîtrise de ce que le framework ne fait pas : migrations et reprise de données, traitements asynchrones, tests, déploiement avec retour arrière, reprise d’un existant. Les huit questions de cet article se posent en une heure et ne demandent aucune compétence technique à celui qui les pose : ce qui s’évalue, c’est la précision des réponses et la présence de détails qu’on n’invente pas, en particulier sur le dernier incident de production.
Le compteur de requêtes est le test le plus rapide. Une liste avec une relation exécute n + 1 requêtes si elle est écrite naïvement et exactement 2 si les relations sont chargées par anticipation : 1 001 contre 2 pour mille lignes, quelle que soit la machine. Une équipe qui affiche ce compteur pendant sa démonstration connaît ses chiffres ; une équipe qui le découvre devant vous découvrira aussi les lenteurs de votre application, plus tard et à vos frais.
Enfin, exigez cinq lignes nommées au devis — environnements, migrations, files d’attente, tests, déploiement — et un verdict écrit en cas de reprise d’un projet existant : repris en l’état, repris après remise à niveau chiffrée, ou réécrit. Un devis sans ces lignes n’est pas moins cher, il est incomplet ; l’écart se paiera en avenants, dans un rapport de force moins favorable qu’aujourd’hui.
