Mettre à niveau une ancienne application Laravel ne consiste pas à remplacer un numéro dans composer.json. Le framework, PHP, les bibliothèques, la base de données et les traitements en arrière-plan forment un ensemble. La préparation doit démontrer qu’une combinaison cible peut faire fonctionner vos parcours réels, puis qu’elle peut être déployée et exploitée. Voici une méthode de travail pour construire cette démonstration sans confondre migration technique et refonte du produit.
1. Établir l’état de départ réellement déployé
Commencez par identifier le commit en production et les versions exécutées, pas seulement celles annoncées dans le dépôt. Comparez PHP côté serveur web, ligne de commande et workers : ils peuvent utiliser des exécutables ou des configurations différents. Relevez les extensions, le moteur de base de données, le cache, le stockage et les services externes. Conservez cet inventaire avec la procédure de démarrage et de déploiement.
Repérez aussi les différences entre le dépôt et le serveur : modification manuelle, fichier non versionné, tâche cron ajoutée hors procédure. Ces écarts peuvent rendre une installation neuve incomplète. Si le prestataire a disparu ou que les accès manquent, traitez d’abord la récupération du projet PHP et de ses accès. Une migration ne corrige pas une propriété des comptes mal définie.
2. Choisir une cible compatible, pas seulement récente
Construisez une matrice courte : composant, version actuelle, contrainte de compatibilité, cible envisagée et blocage connu. Incluez les bibliothèques métier importantes : paiement, PDF, authentification, recherche ou échanges avec l’ERP. Une dépendance qui ne suit plus les versions récentes peut peser davantage dans la décision que le framework lui-même. Vérifiez son maintien, les alternatives et le coût d’adaptation.
Consultez le guide officiel de mise à niveau Laravel correspondant à chaque transition et les guides de migration PHP concernés. Ils identifient des changements incompatibles que les tests devront couvrir. Pour une application éloignée de la cible, évaluez des paliers vérifiables. Cela ne signifie pas déployer chaque palier en production : certains servent uniquement à isoler un ensemble de changements en environnement de test.
Ce que Composer permet de vérifier
Dans une copie de travail contrôlée, la documentation Composer fournit plusieurs diagnostics : validate contrôle la configuration ; prohibits aide à repérer ce qui bloque une version cible ; audit signale notamment les avis de sécurité connus. check-platform-reqs compare les exigences des paquets installés à la plateforme réelle, même si config.platform simule une autre version. Aucun de ces contrôles ne valide à lui seul le fonctionnement métier.
3. Reproduire l’application sans reproduire ses effets externes
Avant de modifier les dépendances, vérifiez qu’une installation propre de l’état actuel fonctionne à partir du dépôt et du fichier de verrouillage. C’est votre point de comparaison. L’environnement de test doit ensuite isoler les envois d’e-mails, les paiements, les webhooks sortants, le stockage et les tâches planifiées. Un simple changement de domaine ne suffit pas si une clé de production reste présente.
Utilisez des données fictives ou une copie minimisée et protégée. Conservez les relations utiles à la recette sans diffuser inutilement des données personnelles. Préparez des comptes avec des rôles différents. Si un service partenaire propose un bac à sable, vérifiez ses écarts avec la production ; sinon, définissez une simulation contrôlée et documentez ce qu’elle ne prouve pas.
4. Écrire une recette qui détecte une vraie régression
Une page qui s’affiche n’est pas une preuve suffisante. Pour chaque parcours critique, précisez les données de départ, le rôle utilisé, l’action et le résultat observable. Exemple fictif : valider une commande doit produire le bon total, empêcher une validation non autorisée et créer une seule demande de synchronisation. Le cas d’erreur et la relance comptent autant que le scénario réussi.
- Authentification, réinitialisation du mot de passe et permissions.
- Calculs, arrondis, dates, fuseaux horaires et changements de statut.
- Imports, exports, documents et fichiers joints.
- Tâches différées, erreurs d’API, doublons et reprises après interruption.
- Temps de réponse et consommation de ressources sur un volume représentatif.
Automatisez les contrôles répétables et faites valider les résultats métier par les personnes compétentes. Gardez les observations avant et après chaque palier : erreurs, requêtes lentes, tâches échouées et totaux attendus. Un test déjà défaillant avant migration doit être identifié comme tel, sans devenir une excuse pour ignorer une nouvelle anomalie.
5. Préparer les données et le retour arrière ensemble
Distinguez la migration du framework d’une migration du schéma ou des données. Si le déploiement modifie la base, mesurez le temps d’exécution, les verrouillages possibles et la compatibilité avec l’ancien code. Une évolution additive peut parfois permettre une transition en plusieurs passages ; elle doit être étudiée pour le moteur et les volumes concernés, pas présumée sans risque.
Revenir au commit précédent ne remet pas automatiquement les données dans leur état antérieur. Définissez les conditions d’arrêt, la procédure de restauration et le traitement des écritures reçues après la bascule. Une restauration peut faire perdre ces écritures si aucune méthode de rapprochement n’est prévue. Répétez la procédure sur une copie avant de fixer la fenêtre de mise en production.
6. Déployer une version, puis observer le système complet
Le plan de bascule liste les actions, leurs responsables et les vérifications attendues : configuration, dépendances verrouillées, éventuelles migrations, caches et processus persistants. La documentation de déploiement Laravel rappelle que les services persistants doivent reprendre le nouveau code. La commande adaptée dépend de la version et des composants ; copiez une procédure validée pour votre application, pas une commande trouvée pour une autre génération.
Après la bascule, contrôlez un parcours représentatif, les journaux, les files d’attente et les intégrations. Certaines erreurs n’apparaissent qu’au prochain traitement planifié ou à un événement rare. Prévoyez qui consulte ces signaux et comment un écart déclenche une décision. Une application accessible ne suffit pas à déclarer la migration terminée.
Les livrables à obtenir avant de donner le feu vert
- Un état initial reproductible et une cible dont les incompatibilités ont été examinées.
- Une recette avec résultats, réserves explicites et validation métier.
- Un plan de déploiement et de restauration répété, incluant les nouvelles écritures.
- Des responsables identifiés pour la bascule, l’observation et les suites de maintenance.
Cette préparation rend le chiffrage plus fiable : on distingue les blocages établis des inconnues restantes. Si la question porte encore sur la pertinence de conserver l’existant, commencez par notre guide d’audit et de reprise Laravel. Pour définir un accompagnement, consultez notre service de reprise et maintenance Laravel ou présentez-nous le contexte de l’application, sans transmettre de secrets dans le formulaire.
