Agence Laravel à Paris

Pour construire une application métier rapidement sans sacrifier la lisibilité : Laravel apporte l’authentification, les migrations, les files, la planification et les tests dans un cadre cohérent.

Le gain concret est la vitesse de départ. Les briques que tout projet redéveloppe — comptes, réinitialisation de mot de passe, droits, envoi de courriels, tâches planifiées, traitements en arrière-plan — existent et se comportent de la même manière d’un projet à l’autre. Un développeur qui reprend le code retrouve donc ses repères.

La contrepartie : Laravel propose plusieurs manières de faire la même chose, et cette souplesse se paie sur un projet long si aucune convention n’est fixée au départ. Nous en posons donc quelques-unes par écrit avant la première ligne — où vivent les règles métier, comment les requêtes sont validées, ce qui a droit d’accéder à la base.

Quand nous ne le recommandons pas : un site éditorial, où un CMS est plus direct ; et un domaine très riche en règles, où la structure imposée par Symfony tient mieux sur cinq ans.

Oui après audit du code, des dépendances, des tests, des environnements et de la base de données, avec un plan de reprise progressif.

L’audit prend de deux à cinq jours et regarde six points : la version de Laravel et de PHP et leur fenêtre de support, l’état des dépendances et celles qui sont abandonnées, l’existence de tests automatisés — leur absence n’est pas rédhibitoire mais change tout le rythme de reprise —, la façon dont les secrets sont stockés, la reproductibilité de l’environnement depuis le dépôt, et la présence d’une procédure de restauration testée.

Le premier lot d’une reprise est presque toujours le même, et il n’ajoute aucune fonction : rendre l’environnement reproductible, mettre la base sous migrations si elle ne l’est pas, et écrire les quelques tests qui couvrent les parcours critiques. Rien d’autre n’est sûr avant.

Deux situations nous font refuser : un code non fourni ou incomplet, et une production sans environnement de test possible — la première correction se ferait sur les données de vos clients.

Par le contrôle des requêtes, le chargement anticipé des relations, l’indexation, la pagination et la mise en cache des données coûteuses.

La cause la plus fréquente de lenteur sur une application Laravel a un nom : la requête en boucle. Une liste de cent lignes qui charge, pour chaque ligne, la relation associée exécute cent une requêtes au lieu de deux. Le symptôme est une page qui fonctionne parfaitement en développement sur dix enregistrements et s’écroule en production sur dix mille.

Nous instrumentons donc le nombre de requêtes par page dès le développement, avec un seuil d’alerte. C’est une mesure gratuite qui attrape le problème avant la recette plutôt qu’après la mise en ligne.

Viennent ensuite les index, qui manquent presque toujours sur les colonnes de filtrage et de tri ajoutées après la conception initiale ; la pagination, imposée sur toute liste susceptible de grandir ; et le cache, réservé aux calculs réellement coûteux avec une règle d’invalidation écrite — un cache sans règle d’invalidation produit des données fausses, ce qui est pire que lent.

Pour tout traitement long ou dépendant d’un service externe : envoi de courriels, génération de documents, imports, appels d’interface, notifications.

Le critère est simple : si l’utilisateur n’a pas besoin du résultat dans la seconde, le traitement part en file. Cela change deux choses. La page répond immédiatement, ce qui évite les délais d’attente et les doubles soumissions. Et le traitement devient réessayable : un service externe indisponible n’est plus une erreur affichée à l’utilisateur mais une tâche qui repart plus tard.

Trois précautions accompagnent toute file. L’idempotence : rejouer une tâche ne doit pas produire deux fois l’effet, ce qui suppose une clé d’unicité. Une limite de tentatives avec un intervalle croissant, sinon une tâche en échec permanent sature le système. Et une file d’échec surveillée avec un destinataire nommé — une file qui grossit sans que personne ne regarde est le scénario le plus courant.

Nous exposons aussi l’état des files dans l’administration, pour que vos équipes voient ce qui attend sans nous appeler.

Oui. Les interfaces sont conçues avec des contrats clairs, une authentification adaptée, des versions, de la documentation et des tests automatisés.

Trois décisions se prennent avant d’écrire : le mode d’authentification, la stratégie de version, et la forme des erreurs. Le mode dépend du consommateur — jetons pour une application mobile, clés pour un partenaire, session pour un front sur le même domaine. La version se met dans l’adresse dès la première livraison, parce que l’ajouter ensuite casse les clients existants. Et la forme des erreurs doit être uniforme, avec un code stable et un message lisible : une interface qui renvoie tantôt du texte, tantôt un objet, est impossible à consommer proprement.

S’y ajoutent la limitation de débit par consommateur, la pagination obligatoire sur toute collection, et la documentation générée depuis le code plutôt que rédigée à côté — une documentation manuelle se désynchronise en quelques semaines.

Les tests couvrent les cas d’erreur autant que les cas nominaux : un point d’entrée appelé sans droit doit répondre le bon code, et c’est ce qui se vérifie le moins.

Par la validation des entrées, le contrôle des autorisations côté serveur, la gestion des secrets hors du code, la journalisation et des dépendances à jour.

Le contrôle des autorisations est vérifié à chaque requête, dans les politiques, et pas seulement en masquant un élément d’interface. Un écran caché n’est pas une protection : l’adresse reste appelable, et c’est par là que passent la plupart des fuites sur les applications métier. Nous testons explicitement cela en recette, en appelant chaque point d’entrée avec un compte qui ne devrait pas y avoir accès.

La validation se fait à l’entrée et de manière exhaustive : un champ non déclaré est refusé plutôt qu’ignoré, ce qui ferme l’assignation de masse — un attaquant qui ajoute un paramètre pour se donner un rôle.

Les secrets vivent dans l’environnement, jamais dans le dépôt, avec une procédure de rotation écrite. Et les dépendances sont suivies : un audit automatisé à chaque intégration signale les paquets à failles connues, ce qui coûte quelques minutes de configuration une fois.

Par des tests de fonctionnalités sur les parcours critiques, des tests unitaires sur les règles métier et une exécution automatisée à chaque modification.

Nous ne visons pas un taux de couverture, qui est un mauvais objectif : on l’atteint en testant ce qui est facile. Nous visons la couverture des chemins qui coûtent cher s’ils cassent — l’authentification, les droits, le calcul qui produit un montant, l’échange avec votre système de gestion, et le parcours qui déclenche un paiement ou un engagement.

Les règles métier se testent unitairement, isolées de la base et du réseau, parce que ce sont elles qui changent et qu’on doit pouvoir les vérifier en quelques secondes. Les parcours se testent de bout en bout, plus lentement, sur une base de test reconstruite à chaque exécution.

L’exécution est automatique à chaque proposition de modification, et une modification qui casse un test ne part pas en production. C’est cette automatisation, plus que les tests eux-mêmes, qui protège dans le temps : des tests qu’on lance à la main ne sont plus lancés au bout de trois mois.

Oui. Les montées de version, les refontes de modules et les améliorations se planifient par étapes, avec des tests et des mises en production progressives.

La méthode consiste à ne jamais avoir deux chantiers ouverts sur le même code. On monte d’abord les versions de PHP et du cadriciel, une marche à la fois, avec les tests comme filet — c’est mécanique et cela ne change aucune fonction. On refond ensuite les modules un par un, en commençant par celui qui bloque le plus d’évolutions.

Deux techniques permettent de livrer sans interruption. Les migrations de base compatibles dans les deux sens : on ajoute une colonne avant de s’en servir, on la remplit, puis on bascule la lecture, et on ne supprime l’ancienne que plus tard. Et les interrupteurs de fonctionnalité, qui permettent de déployer du code inactif et de l’activer pour une partie des utilisateurs.

Ce que nous refusons : la réécriture complète en parallèle du maintien de l’ancien. Deux systèmes à faire évoluer en même temps, c’est le double du travail et un basculement qui n’arrive jamais.