Mise à jour Laravel · déploiement automatique · maintenance
Mettez à jour votre application Laravel sans casser la production
Votre application tourne encore sur Laravel 7 ou 8, avec un vieux PHP, sur un serveur que personne n'ose toucher, et chaque mise en ligne passe par un envoi de fichiers en FTP ? Je la passe sur une version supportée de Laravel et de PHP, par petites étapes testées, je mets en place un déploiement automatique, et je peux assurer la maintenance ensuite.
"require": { "php": "^8.3", "laravel/framework": "^13.0" }
Chemin de mise à jour
- 7 → 8PHP 7.3 · tests · staging
- 8 → 9PHP 8.0 · tests · staging
- 9 → 10PHP 8.1 · tests · staging
- 10 → 11PHP 8.2 · tests · staging
- 11 → 12PHP 8.2 · tests · staging
- 12 → 13PHP 8.3 · tests · staging
- 2 ans
- de correctifs de sécurité par version de Laravel. Ensuite, plus rien.
- 7 → 10
- L'ancien panneau d'administration d'Odigix, mis à jour sur trois versions majeures
- 10 → 13
- L'application Laravel principale d'Odigix, sur la dernière version
Ça vous parle ?
Personne ne repousse les mises à jour exprès. L'application marche, chaque nouvelle version ajoute une raison d'attendre, et après quelques années l'écart paraît trop grand pour être rattrapé.
- Le composer.json demande encore Laravel 7 ou 8, voire 5.x.
- L'hébergement tourne sous PHP 7.4, et personne ne veut savoir ce qui casse sur une version plus récente.
- Mettre en ligne, c'est envoyer les fichiers par FTP ou par le gestionnaire de fichiers du cPanel.
- Le développeur qui a construit l'application n'est plus là, et personne ne sait la réinstaller.
- Il n'y a pas de tests, ou ils ne sont jamais lancés avant une mise en ligne.
- composer update est interdit depuis des années : un paquet obsolète bloque le suivant.
- Le paiement en ligne ou l'API du livreur a changé, et l'adapter sur un vieux code fait peur.
- Le système d'exploitation du serveur n'est plus supporté lui non plus.
Où en est votre version
Laravel corrige les bugs de chaque version majeure pendant 18 mois et les failles de sécurité pendant deux ans. PHP supporte chaque branche deux ans, puis deux ans de correctifs de sécurité seulement. Au-delà, une faille découverte demain reste ouverte dans votre version, et les paquets dont vous dépendez l'abandonnent aussi.
Laravel
- 5.5 LTSFin de viePlus aucun correctif depuis août 2020
- 5.8Fin de viePlus aucun correctif depuis févr. 2020
- 6 LTSFin de viePlus aucun correctif depuis sept. 2022
- 7Fin de viePlus aucun correctif depuis mars 2021
- 8Fin de viePlus aucun correctif depuis janv. 2023
- 9Fin de viePlus aucun correctif depuis févr. 2024
- 10Fin de viePlus aucun correctif depuis févr. 2025
- 11Fin de viePlus aucun correctif depuis mars 2026
- 12Sécurité seuleCorrectifs de sécurité jusqu'en févr. 2027
- 13SupportéeCorrectifs de sécurité jusqu'en mars 2028
PHP
- 7.2Fin de viePlus aucun correctif depuis nov. 2020
- 7.3Fin de viePlus aucun correctif depuis déc. 2021
- 7.4Fin de viePlus aucun correctif depuis nov. 2022
- 8.0Fin de viePlus aucun correctif depuis nov. 2023
- 8.1Fin de viePlus aucun correctif depuis déc. 2025
- 8.2Sécurité seuleCorrectifs de sécurité jusqu'en déc. 2026
- 8.3Sécurité seuleCorrectifs de sécurité jusqu'en déc. 2027
- 8.4SupportéeCorrectifs de sécurité jusqu'en déc. 2028
- 8.5SupportéeCorrectifs de sécurité jusqu'en déc. 2029
Ce que vous risquez sur une version non supportée
Rien d'hypothétique ici. Chacune de ces failles a touché des applications sur un Laravel ou un PHP ancien ou mal configuré, et trois sur quatre figurent dans le catalogue de la CISA des vulnérabilités exploitées.
- CVE-2018-15133Exploitée activement
Une APP_KEY divulguée transforme un cookie en exécution de code
Les anciennes versions de Laravel déchiffraient puis désérialisaient le cookie X-XSRF-TOKEN : quiconque possédait la clé de l'application pouvait exécuter du code sur le serveur. En janvier 2024, la CISA et le FBI l'ont citée dans leur alerte sur Androxgh0st, un botnet qui cherche les fichiers .env de Laravel exposés pour voler des identifiants.
Concerne Laravel jusqu'à 5.5.40 et 5.6.x jusqu'à 5.6.29.
cisa.gov - CVE-2021-3129Exploitée activement
Le mode debug laissé actif en production
Ignition, la page d'erreur livrée avec Laravel 6 à 8, permettait à un visiteur non authentifié d'écrire et d'exécuter du code sur le serveur quand APP_DEBUG était activé. Elle figure dans le catalogue de la CISA des vulnérabilités exploitées.
Concerne Ignition avant 2.5.2 avec le mode debug activé.
nvd.nist.gov - CVE-2024-4577Utilisée par des rançongiciels
Une faille PHP que les anciennes versions n'ont jamais corrigée
Une faille critique (CVSS 9,8) d'injection d'arguments dans PHP-CGI sous Windows. Les correctifs sont sortis pour PHP 8.1, 8.2 et 8.3 en juin 2024. PHP 8.0, 7 et 5 étaient déjà en fin de vie : ils n'en ont jamais reçu. La seule vraie correction était de mettre à jour.
Concerne PHP-CGI sous Windows : 8.1 avant 8.1.29, 8.2 avant 8.2.20, 8.3 avant 8.3.8, et toutes les versions en fin de vie.
devco.re - CVE-2024-52301
Le correctif existe, encore faut-il pouvoir l'installer
Avec l'option register_argc_argv de PHP activée, une URL piégée pouvait changer l'environnement dans lequel Laravel démarre. Laravel a corrigé toutes les branches jusqu'à la 6, mais un correctif ne sert que si composer update passe proprement sur votre projet, et c'est exactement ce qui bloque sur un vieux code.
Concerne Laravel avant 6.20.45, 7.30.7, 8.83.28, 9.52.17, 10.48.23 et 11.31.0.
github.com
Comment se passe la mise à jour
Une mise à jour tourne mal quand elle se fait d'un seul coup, sans tests, directement en production. Cette méthode évite les trois.
- 01
Un premier échange gratuit
Sur WhatsApp ou en appel : ce que fait l'application, où elle est hébergée, comment elle est mise en ligne, et ce qui vous inquiète. Si je ne suis pas la bonne personne, je vous le dis tout de suite.
RésultatUn premier avis honnête, et la liste de ce qu'il me faut pour chiffrer.
- 02
Une lecture du code, sans rien modifier
Je passe en revue le composer.json et le fichier lock, les versions de PHP et du serveur, les paquets abandonnés, le code qui touche aux entrailles du framework, les tests, et la façon dont les mises en ligne se font aujourd'hui.
RésultatUn plan écrit (versions cibles, étapes, paquets à remplacer, risques) et un devis à prix fixe.
- 03
Un filet de sécurité avant tout changement
L'application tourne sur un serveur de test à partir d'une installation propre. J'ajoute des tests sur ce qui vous fait gagner de l'argent (inscription, connexion, commande, paiement, tâches planifiées) pour que l'on soit d'accord sur ce que « ça marche toujours » veut dire.
RésultatUn serveur de test et des tests qui restent à vous, quoi qu'il arrive.
- 04
Une version majeure à la fois
Laravel 7 → 8 → 9 → 10, pas un grand saut. Chaque étape est une pull request séparée : framework, version de PHP, paquets et fonctions obsolètes, tests au vert, puis mise sur le serveur de test pour que vous vérifiiez. Les agents de code font une grande partie de la réécriture mécanique ; je relis chaque changement avant de l'intégrer.
RésultatDes étapes petites et vérifiables, et une application qui fonctionne à chacune d'elles.
- 05
Un déploiement automatique à la place du FTP
GitHub Actions lance les tests à chaque modification et déploie sur votre serveur : nouveau dossier de version, dépendances, migrations et caches, puis bascule par lien symbolique. Vos clients ne voient jamais un site à moitié envoyé, et revenir en arrière revient à repointer le lien vers la version précédente. Si l'hébergement actuel ne permet pas un PHP supporté, je prépare un VPS et j'y déménage l'application.
RésultatDes mises en ligne en quelques minutes, réversibles, qui ne dépendent plus d'un seul ordinateur.
- 06
Mise en production avec un plan de retour
La bascule se fait à une heure creuse de votre choix, après une sauvegarde vérifiée de la base de données et un retour arrière répété à l'avance. Je surveille les erreurs et les files d'attente de près les jours suivants.
RésultatVotre application sur une version supportée de Laravel et de PHP, en production.
- 07
Passation, ou maintenance continue
Vous recevez une documentation (installation, déploiement, retour arrière) pour que n'importe quel développeur puisse reprendre le projet. Ou je reste : mises à jour mensuelles des dépendances et de sécurité, veille sur les failles de vos versions, et la prochaine mise à jour majeure dès sa sortie.
RésultatUn projet que n'importe qui peut maintenir, ou quelqu'un qui le maintient déjà.
Ce dont j'ai besoin, et à quel moment
Les accès suivent l'avancement : lecture seule pour le devis, puis seulement ce qu'une étape exige.
- Code source
- Un accès en lecture pour le devis. Ensuite, un compte collaborateur : je travaille sur des branches et des pull requests, jamais directement sur la branche principale. Si le code n'est que sur le serveur, je le mets d'abord sur GitHub, dans un dépôt à votre nom.
- Lecture du code
- Configuration
- La liste des noms de variables du fichier .env, sans les valeurs. Les vrais secrets restent sur les serveurs, jamais sur WhatsApp ni dans le dépôt.
- Lecture du code
- Copie des données
- Une copie anonymisée de la base, ou un utilisateur en lecture seule, pour tester les migrations sur des données réalistes.
- Avant la mise à jour
- Serveur de test
- Un petit serveur de test : le vôtre, ou un que je prépare sur votre compte d'hébergement.
- Filet de sécurité
- Serveur de production
- Un utilisateur SSH dédié avec ma clé, pour le déploiement et la mise en production, pas votre mot de passe root ni celui du cPanel. Supprimé à la passation si je n'assure pas la maintenance.
- Déploiement et mise en ligne
- Services tiers
- Seulement ceux que la mise à jour touche (paiement, e-mail, livreur), avec des clés de test ou un accès en lecture quand c'est possible.
- Si nécessaire
- Quelqu'un qui connaît l'application
- Une heure ou deux pour lister ce qui ne doit jamais casser, puis une vérification sur le serveur de test avant chaque mise en ligne.
- Tout au long du projet
Comment les accès sont gérés
- Des comptes à mon nom, pour que chaque action soit traçable et que vous puissiez la retirer.
- Des clés SSH, pas de mots de passe partagés. Les secrets passent par un gestionnaire de mots de passe, jamais par message.
- Rien d'irréversible en production sans votre accord : aucune suppression de données, aucun déploiement en dehors du créneau prévu.
- Un accord de confidentialité avant de voir le code, si vous le souhaitez.
Mises à jour réalisées
La même méthode, sur de vrais projets.
- 7→10Administration d'OdigixL'ancien panneau d'administration Laravel de la plateforme, mis à jour sur trois versions majeures.
- 10→13Application principale d'OdigixLe backend Laravel derrière odigix.com et ses plus de 30 000 inscrits, passé sur la dernière version.
- 6–7→SupportéeProjets clientsDes applications clientes de l'époque Laravel 6 et 7, passées sur des versions supportées. Les noms des clients restent confidentiels.
Questions fréquentes
Combien de temps prend une mise à jour ?
Cela dépend du retard de l'application, du nombre de paquets à remplacer et de l'existence de tests. Le plan écrit, remis après la lecture du code, vous donne les étapes et un calendrier avant tout engagement.
Peut-on continuer à ajouter des fonctionnalités pendant la mise à jour ?
Oui. La mise à jour avance sur ses propres branches, une version majeure à la fois, et je la synchronise avec vos changements au fur et à mesure.
Combien ça coûte ?
Un prix fixe, donné après l'échange gratuit et la lecture du code, pas un tarif horaire. Il dépend de l'écart à rattraper, c'est pourquoi il n'est pas affiché ici.
Mon application est sur un hébergement mutualisé (cPanel). C'est possible ?
Oui pour la mise à jour du code, si l'hébergeur propose une version de PHP supportée. Pour un déploiement automatique fiable, je recommande souvent un petit VPS, et je m'occupe du déménagement.
Le paiement en ligne est intégré (SlickPay, OneClick). Est-ce que ça risque de casser ?
C'est précisément ce que les tests du filet de sécurité couvrent en premier. J'intègre SlickPay et OneClick en production sur Odigix depuis 2023 : je sais où ces intégrations cassent.
Assurez-vous la maintenance ensuite ?
Si vous le souhaitez : mises à jour mensuelles des dépendances et de sécurité, veille sur les failles des versions que vous utilisez, et la prochaine mise à jour majeure dès sa sortie, tant que l'écart est petit. La maintenance fait l'objet d'un devis par projet.
Vous avez un projet similaire ?
Expliquez-moi où vous en êtes et ce qui vous bloque. Réponse rapide sur WhatsApp, devis gratuit.