Reprendre un projet Laravel existant : par où commencer

La plupart des reprises d'application Laravel commencent de la pire façon : on clone le dépôt, on ouvre routes/web.php, et on se met à lire. Au bout de deux heures, on connaît trois contrôleurs sur quarante et on n'a toujours aucune idée de ce qui tourne en production.

Je fais l'inverse. Avant d'ouvrir un fichier, je fais parler l'application : sa configuration, sa base, ses routes, ses tâches planifiées, ses dépendances. Une application Laravel sait décrire une bonne partie d'elle-même, et c'est gratuit. Voici l'ordre dans lequel je procède quand je récupère un projet dont personne ne sait plus rien, et ce que je décide à la fin.

Ne commencez pas par lire le code

Lire le code en premier a un défaut : vous lisez ce que le développeur précédent a écrit, pas ce que l'application fait aujourd'hui. Entre les deux, il y a des variables d'environnement, des paquets, des migrations passées à la main, des tâches planifiées sur le serveur, parfois une colonne ajoutée directement en base un soir de production.

Le premier objectif n'est pas de comprendre le code. C'est de répondre à quatre questions :

• qu'est-ce qui tourne, et sur quelles versions ;
• à quoi l'application est-elle reliée (base, cache, files d'attente, services tiers) ;
• qu'est-ce qui s'exécute tout seul, sans que personne ne clique ;
• qu'est-ce qui est déjà cassé ou périmé.

Le code vient après, et il se lit beaucoup plus vite une fois ces quatre réponses en main.

Reprendre un projet Laravel : faites d'abord parler l'application

Toutes les commandes ci-dessous existent dans Laravel 13, je les ai vérifiées sur la version 13.27. Les plus anciennes sont disponibles depuis Laravel 9, ce qui couvre l'essentiel des applications qu'on me confie.

Le point de départ, c'est la carte d'identité : versions de PHP et de Laravel, environnement, pilotes de cache, de session et de file d'attente, mode debug.

php artisan about

Si quelque chose vous surprend ici, notez-le, c'est déjà un résultat. Un APP_DEBUG à true en production ou un pilote de session en file sur deux serveurs derrière un répartiteur de charge, ce sont des trouvailles de la première minute.

Ensuite, la base. Je veux sa taille, ses tables et le volume réel des données, parce qu'une table de dix millions de lignes change toutes les décisions qui suivent :

php artisan db:show --counts
php artisan db:table nom_de_la_table
php artisan migrate:status

migrate:status est celle que je regarde le plus attentivement. Des migrations présentes dans le dépôt mais jamais exécutées, ou l'inverse, vous apprennent en une ligne que la base de production ne correspond pas au code. C'est fréquent, et il vaut mieux le découvrir maintenant que pendant un déploiement.

Les modèles racontent le reste du schéma, relations et observateurs compris :

php artisan model:show User

Puis ce qui s'exécute sans intervention humaine, c'est-à-dire ce qui peut casser la nuit :

php artisan schedule:list
php artisan queue:failed

Une file d'attente avec quatre mille jobs échoués accumulés depuis huit mois est un diagnostic à elle seule : personne ne surveillait l'application. Enfin, les routes et la configuration réellement chargée :

php artisan route:list --except-vendor
php artisan config:show database

Mesurer la dette avant de la commenter

Une fois la carte en main, la question suivante est financière autant que technique : combien coûte le simple fait de rester à jour. Deux commandes suffisent à cadrer la discussion.

composer audit
composer outdated --direct

La première liste les failles de sécurité connues dans les dépendances installées. La seconde montre les paquets que vous avez demandés vous-même et qui ont pris du retard, sans noyer la sortie sous leurs propres dépendances.

Reste le plus important, la version du framework. Laravel suit une règle simple, publiée dans ses notes de version : chaque version reçoit des corrections de bugs pendant 18 mois et des correctifs de sécurité pendant deux ans. Au 31 octobre 2026, cela donne :

• Laravel 13, sortie le 17 mars 2026, tourne sur PHP 8.3 à 8.5 : c'est la version courante.
• Laravel 12 ne reçoit plus de corrections de bugs depuis août 2026, et ses correctifs de sécurité s'arrêtent en février 2027.
• Laravel 11 et toutes les versions antérieures ne reçoivent plus rien du tout.

Autrement dit, si l'application que vous reprenez est en Laravel 11 ou en dessous, toute faille découverte à partir de maintenant restera ouverte chez vous. La même logique vaut pour PHP lui-même, et j'ai détaillé ce que ça coûte concrètement dans mon article sur les failles PHP de 2026.

Les trois choses à sécuriser avant de toucher au code

J'ai fait assez de montées de version sur des applications en production, avec de vrais utilisateurs dedans, pour ne plus déroger à ça. Avant la première modification, trois points doivent être réglés.

Une sauvegarde dont vous avez vérifié la restauration. Pas une sauvegarde qui existe : une que vous avez réellement restaurée ailleurs, une fois, pour constater qu'elle se remonte. Une sauvegarde jamais testée est une hypothèse.

Un environnement local qui ressemble à la production. Même version majeure de PHP, même moteur de base, mêmes extensions. Reprendre une application en local sur PHP 8.4 alors qu'elle tourne en 8.1 côté serveur, c'est fabriquer des bugs qui n'existent nulle part et en manquer d'autres qui existent vraiment.

Une remontée des erreurs. Tant que vous ne voyez pas les erreurs de production, vous travaillez à l'aveugle et le client reste votre seul système de surveillance. C'est souvent la première chose que je mets en place, avant même la moindre correction.

Quand il n'y a aucun test, et c'est le cas le plus courant

Les applications héritées arrivent rarement avec une suite de tests. L'erreur serait de vouloir combler ce trou avant de produire quoi que ce soit : vous passeriez des semaines à tester du code que vous allez peut-être réécrire.

Ce que je fais est plus modeste. J'identifie les parcours dont la panne se voit immédiatement, en général l'authentification, le paiement, la création de l'objet métier principal, et j'écris des tests sur ceux-là uniquement. Trois ou quatre tests de bout en bout, pas davantage. Ils ne prouvent pas que l'application est correcte, ils prouvent qu'elle n'est pas morte, et ils vous autorisent à toucher au reste sans transpirer.

Le reste de la couverture s'écrit ensuite, au fil des corrections : chaque bug corrigé repart avec le test qui l'aurait attrapé.

Travailler par petits lots, même seul

Sur une application que je connais mal, je m'interdis les grosses modifications. Je fonctionne par lots : un brief écrit qui dit ce que le lot change et ce qu'il ne change pas, une branche, une pull request, une intégration continue verte, puis la fusion. Même en travaillant seul, même sur un correctif de dix lignes.

Ça n'est pas de la cérémonie. Sur du code hérité, la pull request est le seul endroit où vous relisez votre propre travail avec un peu de recul, et où vous pouvez revenir en arrière proprement quand une modification se révèle mauvaise trois jours plus tard. C'est aussi ce qui rend l'intervention lisible pour le client : il voit la liste des lots, pas un gros commit du vendredi soir.

C'est la méthode que j'applique aussi quand je fais écrire une partie du code par une IA, avec Claude Code : le brief est écrit à l'avance, la branche est isolée, la CI doit passer, et je relis la pull request ligne à ligne avant de fusionner. L'outil accélère l'écriture, il ne remplace pas la relecture.

Ce que vous devez avoir à la fin de la reprise

• Une carte de l'application : versions, base, routes, tâches planifiées, services externes.
• Un chiffre sur la dette : failles de dépendances connues, écart de version, support encore actif ou non.
• Une sauvegarde restaurable, un environnement local fidèle, une remontée des erreurs.
• Trois ou quatre tests sur les parcours critiques.
• Un déploiement que vous avez fait au moins une fois vous-même, en entier.

Tant que le dernier point n'est pas vrai, vous n'avez pas repris l'application : vous la lisez.

Questions fréquentes

Faut-il tout réécrire ? Presque jamais. Une réécriture coûte cher, prend plus de temps que prévu et réintroduit des bugs que l'ancienne version avait déjà corrigés. Elle se justifie quand le code ne peut plus évoluer du tout, pas parce qu'il est ancien ou qu'il ne vous plaît pas.

Combien de temps prend un état des lieux ? Les commandes de cet article prennent une matinée. Ce qui prend du temps ensuite, c'est l'écart de version : passer de Laravel 9 à 13 ne se fait pas d'un bloc, mais version par version, en vérifiant l'application à chaque étape.

L'application est en Laravel 6 ou 7, est-ce récupérable ? Oui. Plus l'écart est grand, plus la montée est longue, mais elle se découpe et l'application reste utilisable entre deux étapes. Le vrai risque n'est pas l'âge du code, c'est l'absence de sauvegarde et de tests pendant qu'on y touche.

Et si le développeur précédent est injoignable ? C'est le cas le plus fréquent. C'est exactement ce que l'état des lieux remplace : vous ne reconstituez pas ses intentions, vous constatez ce que l'application fait.

Une application à reprendre

Si vous avez hérité d'une application Laravel que plus personne ne maîtrise, bloquée sur une vieille version ou simplement sans documentation, c'est le travail que je fais au quotidien : état des lieux, remise à niveau, puis maintenance. Vous pouvez voir le type de projets dont je m'occupe sur mes réalisations, et le détail de la méthode sur ma page maintenance et reprise d'applications Laravel.