Reprise d'application Laravel : par où commencer

Votre application Laravel fonctionne encore, mais plus personne ne la fait évoluer. Le prestataire a disparu, le développeur interne est parti, ou l'agence ne répond plus. Chaque demande de modification devient un pari, et chaque mise à jour du serveur une source d'inquiétude. Une reprise d'application Laravel est pourtant un exercice classique, et elle ne doit pas commencer par une réécriture.

L'ordre qui fonctionne est toujours le même : récupérer les accès, faire un état des lieux honnête, stabiliser ce qui est fragile, et seulement ensuite faire évoluer l'application. Sauter une étape, c'est risquer de casser ce qui marche encore, ou de payer deux fois le même travail.

Cet article s'adresse aux dirigeants qui ont une application métier ou un produit développé avec Laravel et qui se demandent par où commencer. Laravel est un framework PHP, c'est-à-dire une boîte à outils sur laquelle l'application est construite. Pas besoin d'être technique pour suivre cet article : l'objectif est que vous sachiez quoi demander, quoi vérifier, et à quel moment.

Reprise d'une application Laravel : pourquoi ne pas attendre

Une application qui « tourne » n'est pas forcément une application en bonne santé. Le code ne s'use pas, mais tout ce qui l'entoure change : le langage PHP, le framework Laravel, les bibliothèques utilisées, le système du serveur. Chacun a une durée de support limitée. Au-delà, les failles découvertes ne sont plus corrigées.

Côté Laravel, la politique de support officielle est simple : chaque version majeure reçoit des corrections de bugs pendant 18 mois et des correctifs de sécurité pendant 2 ans. Concrètement, à fin septembre 2026 :

Laravel 10 ne reçoit plus de correctifs de sécurité depuis le 4 février 2025, et Laravel 11 depuis le 12 mars 2026 ;
Laravel 12 ne reçoit plus que des correctifs de sécurité, jusqu'au 24 février 2027 ;
Laravel 13, sorti le 17 mars 2026, est la version pleinement maintenue.

Côté PHP, le site officiel indique que les versions 8.1 et antérieures ne sont plus supportées. PHP 8.2 ne recevra plus de correctifs de sécurité après le 31 décembre 2026.

Si votre application tourne sur l'une de ces versions, elle n'est pas en panne. Mais une faille découverte demain ne sera plus corrigée, et plus l'écart avec les versions actuelles se creuse, plus la remise à niveau sera longue. Attendre ne fait pas baisser la facture, au contraire.

Récupérer les accès avant tout le reste

C'est l'étape la moins technique et la plus importante. Sans les accès, personne ne peut rien faire, quel que soit son niveau. Voici ce que vous devez avoir, idéalement au nom de votre entreprise :

Le code source, dans un dépôt Git (GitHub, GitLab, Bitbucket…), avec son historique. L'historique montre comment l'application a évolué : c'est une documentation précieuse.
L'hébergement : le compte chez l'hébergeur et l'accès au serveur.
Le nom de domaine et sa configuration DNS, c'est-à-dire le réglage qui fait pointer votre adresse web vers le bon serveur.
La base de données et ses sauvegardes éventuelles.
Les services tiers : envoi d'emails, paiement, stockage de fichiers, cartographie, API diverses. Chacun a son compte, souvent créé par le prestataire avec sa propre adresse email.
Le fichier de configuration de production (dans Laravel, le fichier .env), qui contient les mots de passe et les clés de ces services.

Si le prestataire est injoignable, tout n'est pas perdu. Si vous avez accès au serveur, le code et la configuration s'y trouvent forcément, puisque l'application tourne. Les comptes de services tiers peuvent en général être récupérés auprès de chaque fournisseur, en prouvant que vous en êtes le titulaire. Relisez aussi votre contrat pour savoir à qui appartient le code : c'est une question à clarifier tôt, avec un juriste si besoin.

Profitez de cette étape pour changer les mots de passe et révoquer les accès des anciens intervenants. Ce n'est pas de la défiance, c'est de l'hygiène.

Faire l'état des lieux : versions, tests, dépendances

Une fois les accès en main, le développeur qui reprend doit vous remettre un état des lieux compréhensible. Pas un rapport de cinquante pages : une liste de risques classés par priorité, avec pour chacun ce que coûte l'inaction. Il y examine notamment :

Les versions de Laravel et de PHP, comparées aux dates de support ci-dessus.
Les dépendances, c'est-à-dire les bibliothèques externes utilisées par l'application. La commande composer audit signale celles qui ont des failles connues. Certaines bibliothèques sont abandonnées par leurs auteurs et devront être remplacées.
Les tests automatiques : existent-ils, passent-ils ? Ce sont eux qui permettent de modifier le code sans casser ce qui marche. S'il n'y en a pas, la façon de travailler change : chaque modification doit être vérifiée à la main.
Le déploiement : comment l'application est-elle mise en ligne ? Par une procédure automatisée ? Ou à la main, par copie de fichiers, selon un savoir-faire parti avec le prestataire ?
Les journaux d'erreurs : l'application produit-elle des erreurs silencieuses que personne ne voit ?
La logique métier : où sont codées les règles propres à votre activité (calculs de prix, étapes de validation, droits des utilisateurs) ? C'est le vrai capital de l'application.

Les outils d'IA comme Claude Code sont utiles à ce stade. Ils lisent un projet entier et aident à en dresser la carte bien plus vite qu'une lecture manuelle. Mais leurs conclusions doivent être vérifiées par quelqu'un qui connaît Laravel : une explication plausible n'est pas toujours une explication juste.

Stabiliser avant de faire évoluer

La tentation est forte de reprendre tout de suite la liste des fonctionnalités en attente. Résistez quelques semaines. Avant d'ajouter quoi que ce soit, il faut un filet de sécurité :

Des sauvegardes vérifiées de la base de données et des fichiers, avec au moins une restauration testée.
Une surveillance qui vous prévient quand l'application est indisponible ou quand les erreurs se multiplient.
Un déploiement automatisé, ce qu'on appelle CI/CD : chaque modification est testée, puis mise en ligne par une procédure identique, sans manipulation à la main.
Des tests sur les parcours critiques : connexion, commande, facturation, tout ce qui vous coûte cher s'il casse.
Une montée de version progressive, une version majeure de Laravel à la fois, en suivant le guide de mise à jour publié pour chacune. Sauter plusieurs versions d'un coup multiplie les causes possibles de panne.

Cette phase est peu spectaculaire : l'application a le même aspect à la fin qu'au début. Mais c'est elle qui rend les évolutions suivantes rapides et prévisibles.

Reprendre ou refaire : comment trancher

La question se pose toujours, d'autant qu'avec l'IA, refaire une application paraît plus rapide qu'avant. Quelques critères pour décider :

Les règles métier sont-elles justes ? Si l'application fait correctement ce que votre activité demande, ce savoir est dans le code. Tout refaire, c'est devoir le redécouvrir, souvent à travers les réclamations de vos clients.
Les données sont-elles bien structurées ? Une base de données saine se garde, même si le code autour change.
Le code est-il compréhensible ? Un code daté mais lisible se modernise. Un code que personne ne comprend, sans tests, avec une logique dispersée partout, peut justifier un remplacement.
Le besoin a-t-il changé ? Si l'application ne correspond plus du tout à votre activité, la question n'est plus technique.

Dans le doute, il existe une voie intermédiaire : remplacer l'application morceau par morceau, en commençant par la partie la plus fragile ou la plus utile, pendant que le reste continue de tourner. C'est plus long sur le papier, mais beaucoup moins risqué dans les faits.

Si vous n'avez plus personne pour faire ce travail, c'est le rôle de l'offre Pilote. Je reprends l'application, je la stabilise, puis je la fais évoluer avec vous, avec un budget mensuel connu à l'avance.

Questions fréquentes

Combien de temps prend une reprise d'application Laravel ?

Cela dépend de la taille de l'application, de l'état du code et surtout des accès disponibles. L'état des lieux permet de donner une estimation sérieuse. Méfiez-vous de toute durée annoncée avant.

Peut-on reprendre une application sans le code source ?

Si l'application tourne sur un serveur auquel vous avez accès, le code s'y trouve. Sans aucun accès au serveur ni au code, il ne s'agit plus d'une reprise mais d'une reconstruction.

Faut-il forcément passer à la dernière version de Laravel ?

Il faut au minimum être sur une version qui reçoit encore des correctifs de sécurité. Passer ensuite à la dernière version est une question de calendrier, pas une urgence.

Si votre application Laravel n'évolue plus et que vous ne savez pas par quel bout la prendre, parlons-en. Dites-moi ce qu'elle fait, depuis quand personne n'y a touché et quels accès vous avez encore. Je vous dirai honnêtement quelle première étape je vois, que vous travailliez avec moi ensuite ou non.