Auditer une application Laravel existante avant de la reprendre

Laravel a changé de manière importante d’une version majeure à l’autre. Auditer une application Laravel, c’est d’abord savoir sur quelle version elle fonctionne réellement, et non sur laquelle le fichier de dépendances prétend qu’elle fonctionne.

Étape 1 : version réelle et dépendances

1. Lire le manifeste et le verrou de dépendances pour connaître les versions déclarées et verrouillées.
2. Vérifier la version réellement chargée en production, qui peut différer du dépôt si le déploiement n’est pas reproductible.
3. Repérer les dépendances qui ne sont plus maintenues, en priorité celles qui occupent une position centrale : une dépendance critique abandonnée peut contraindre toute la trajectoire.
4. Confronter les dépendances déclarées et celles réellement utilisées. Une dépendance utilisée sans être déclarée est un risque de sécurité et de reproductibilité.

# Dépendances directes réellement installées
composer show --direct 2>/dev/null | head -40

# Dépendances obsolètes ou non maintenues
composer outdated --direct

# Version de PHP réellement utilisée en production
php -v
php -m | grep -Ei 'opcache|pdo_mysql|redis|imagick'

Étape 2 : structure du code

La structure d’un projet Laravel révèle les zones de pression. Ce que l’on cherche n’est pas le respect des conventions, mais les endroits où la logique s’est accumulée.

• Des contrôleurs volumineux regroupant validation, logique métier et accès aux données : ces fichiers sont coûteux à modifier sans risque.
• De la logique métier placée dans les vues ou dans des fonctions utilitaires globales utilisées partout.
• Des accès aux relations dentro de boucles, souvent à l’origine des ralentissements.
• Des modèles qui portent une logique implicite, via accesseurs, événements ou scopes, difficile à suivre.
• Des migrations anciennes et non réversibles, qui signalent un historique de données jamais repris.

Étape 3 : accès aux données et requêtes

C’est le cœur d’un audit Laravel, et le point qui demande le plus de méthode. L’objectif n’est pas de recompter les requêtes, mais d’identifier celles dont le comportement change avec la volumétrie.

// Accès à une relation dans une boucle : une requête par élément
foreach ($orders as $order) {
    echo $order->customer->company;
}

// Correctif : chargement anticipé explicite
$orders = Order::with('customer')->paginate(50);

// Contrôle du nombre de requêtes pendant le développement
DB::listen(function ($query) {
    Log::info('sql', ['sql' => $query->sql, 'time' => $query->time]);
});

Le point important : une requête N+1 n’est pas un bug, c’est un risque. Elle fonctionne correctement en développement sur quelques lignes, puis devient un goulot d’étranglement en production quand le volume augmente. C’est typiquement la dette qui ne se voit qu’en production, et qui explique qu’une application qui fonctionnait devienne lente sans que le framework soit en cause. Le détail de ces mesures est repris dans le guide sur les requêtes lentes.

Étape 4 : tests et capacité à corriger

La question n’est pas « y a-t-il des tests ? » mais « peut-on corriger quelque chose en sachant si autre chose a cassé ? ». Une application sans tests impose un surcoût permanent sur chaque évolution, et c’est souvent le vrai frein à la reprise.

• Identifier les parcours critiques couverts par des tests, y compris des tests manuels documentés.
• Repérer les zones à risque sans couverture : paiement, facturation, droits, calculs financiers.
• Constater si la suite de tests est exécutable et si elle passe. Une suite rouge depuis des mois n’apporte plus d’information.

Étape 5 : état de la production

Un audit qui s’arrête au code donne une image incomplète. Il faut comparer ce que le code prédit et ce que la production montre réellement.

1. Examiner les journaux d’erreur et les logs applicatifs sur plusieurs semaines.
2. Comparer les temps de réponse observés et les requêtes réellement lentes, par exemple via les logs d’accès.
3. Vérifier la configuration de production : cache, sessions, file d’attente, tâches planifiées, compilation des assets.
4. Contrôler que la base de données est sauvegardée et que la restauration a déjà été testée.
5. Vérifier que le déploiement est reproductible. Une mise en production qui ne peut pas être rejouée est un risque à chaque livraison.

# Requêtes lentes réellement observées dans les logs Nginx
awk '{print $9, $7}' /var/log/nginx/access.log | sort -k1 -n -r | head -20

# Jobs en échec ou bloqués
php artisan queue:failed
php artisan queue:monitor default:100

# Derniers logs applicatifs
ls -1t storage/logs/ | head

Ce que doit produire un audit

Un audit utile se termine par une décision argumentée, pas par une liste de remarques. Il doit permettre de répondre à trois questions :

• Qu’est-ce qui bloque maintenant ? Les points qui menacent la continuité ou l’évolution.
• Qu’est-ce qui peut attendre ? La dette de confort et les améliorations sans urgence.
• Quel est le premier chantier ? Une action concrète, bornée, avec un résultat vérifiable.

La structure générale d’une reprise, et la manière dont ces étapes s’articulent avec la documentation et la feuille de route, est détaillée dans le guide sur la reprise d’une application développée par un autre prestataire.

• Laravel
• PHP
• Audit
• Eloquent