Maintenance Laravel

Maintenance, reprise et mise à jour d'applications Laravel

Votre application Laravel tourne, mais plus personne n'ose y toucher. Je fais l'état des lieux, je reprends le code, je le remets à jour et je le maintiens, sans arrêter la production.

Vous vous reconnaissez ?

Les situations que je rencontre le plus

Une application Laravel qui n'est plus suivie ne s'arrête pas d'un coup. Elle prend du retard sur les versions, accumule des correctifs posés à la hâte, et chaque modification devient un pari.

Plus personne ne connaît le code

Le développeur ou l'agence qui a construit l'application n'est plus là.

Une version qui n'est plus suivie

Laravel ou PHP ne reçoivent plus de correctifs de sécurité.

L'hébergeur change de PHP

L'ancienne version disparaît, et l'application ne démarre pas sur la suivante.

Chaque correction en casse une autre

Faute de tests, plus rien ne se modifie sans risque.

Des pages qui ralentissent

Les temps de réponse grimpent à mesure que les données s'accumulent.

Une plateforme jamais finie

Le projet a été commencé, puis laissé à moitié fait.

Le calendrier de Laravel

Pourquoi la version de Laravel compte

Laravel corrige les bugs d'une version pendant 18 mois et ses failles de sécurité pendant deux ans. Passé ce délai, l'application continue de fonctionner, mais chaque faille découverte ensuite reste ouverte chez vous.

Version Sortie Corrections de bugs jusqu'au Correctifs de sécurité jusqu'au
Laravel 11 12 mars 2024 3 septembre 2025 12 mars 2026
Laravel 12 24 février 2025 13 août 2026 24 février 2027
Laravel 13 17 mars 2026 3e trimestre 2027 17 mars 2028

Source : politique de support de Laravel (nouvel onglet)

La méthode

Reprendre la main en quatre étapes

  1. L'état des lieux

    Avant de toucher au code, je le lis : versions et failles connues des dépendances, gestion des droits, secrets exposés, structure du code, base de données, tests existants, déploiement. Vous recevez un rapport priorisé : ce qui est urgent, ce qui peut attendre, et ce qui ne vaut pas la peine d'être corrigé.

  2. Sécuriser avant de modifier

    J'écris des tests sur les parcours critiques, ceux qui ne doivent jamais casser : la connexion, le paiement, la création d'un dossier. Ils permettent ensuite de savoir qu'une mise à jour n'a rien changé. Je mets aussi en place une surveillance des erreurs et une sauvegarde qu'on sait restaurer.

  3. Mettre à jour Laravel et PHP

    Je monte les versions une par une, en suivant le guide de mise à jour de chacune, et les tests tournent à chaque étape. Les paquets abandonnés sont remplacés par des équivalents maintenus, jusqu'à une version encore suivie.

  4. Maintenir au fil de l'eau

    Corrections et petites évolutions, mises à jour régulières avant que l'écart ne se creuse à nouveau, surveillance des erreurs et des performances, interventions sur le serveur quand il le faut.

Sur le terrain

Deux plateformes à séparer, sans interruption

Page d'accueil de JeSuisVictime

LegalTech

JeSuisVictime

Les deux plateformes d'indemnisation partageaient au départ la même base de données. Il a fallu extraire les données de l'une vers sa propre base, sans interruption de service et sous des contraintes RGPD strictes.

Page d'accueil de Prejudis

LegalTech

Prejudis

La plateforme d'origine a continué de tourner pendant toute la séparation : dossiers, messagerie interne, signature électronique et archivage des pièces.

Sur un serveur qui héberge plusieurs applications en production, une faille touchant PHP impose d'agir vite sans rien casser. J'interviens alors site par site, et je vérifie que chaque application tourne encore avant de passer à la suivante.

À la fin

Ce que vous obtenez

  • Un code à jour, sur des versions qui reçoivent encore des correctifs.
  • Des tests sur les parcours qui comptent.
  • Un déploiement reproductible et documenté.
  • Un interlocuteur qui connaît votre application.

FAQ

Questions fréquentes

Faut-il tout réécrire ?

Rarement. Une réécriture complète coûte cher, prend du temps et réintroduit des bugs que l'ancien code avait fini par corriger. Je ne la propose que si le code ne peut plus évoluer du tout, et je vous explique pourquoi.

Mon application est restée en Laravel 5 ou 6. Est-ce rattrapable ?

Oui. Plus l'écart est grand, plus la montée de version demande de temps, mais elle se fait par étapes, et l'application reste utilisable entre deux.

Travaillez-vous sur une application que vous n'avez pas développée ?

C'est même le cas le plus courant. L'état des lieux sert précisément à ça.

La suite

UNE APPLICATION
À REPRENDRE ?

Donnez-moi l'adresse de l'application et ce qui vous inquiète : je reviens vers vous sous 24 heures ouvrées.

FAIRE AUDITER VOTRE APPLICATION ⟶