Maintenance Laravel pour agences : méthode, outils et contrats

Maintenance Laravel pour agences : méthode, outils et contrats

Laravel ne fournit aucun tableau de bord de mise à jour et aucun mécanisme automatisé pour ses dépendances : la maintenance d'une application sur ce framework repose entièrement sur une procédure définie par votre équipe. Maintenir une application Laravel en production, c'est surveiller Composer, les queues, les jobs planifiés et la version de PHP — autant de composants qui n'ont pas d'équivalent dans l'interface d'un CMS.

Ce guide s'adresse aux agences qui veulent proposer une prestation de TMA Laravel structurée et rentable — pas seulement du dépannage ponctuel. Vous y trouverez la checklist opérationnelle, les outils de supervision adaptés à cette stack, et les éléments clés d'un contrat de maintenance adapté.

1. Ce qui distingue Laravel d'un CMS en maintenance
2. Checklist de maintenance Laravel mensuelle et trimestrielle
3. Superviser une application Laravel en production
4. Structurer son contrat TMA Laravel

Ce qui distingue Laravel d'un CMS en maintenance

Avec WordPress ou PrestaShop, la maintenance est en grande partie visible dans l'interface d'administration : les extensions en attente de mise à jour, les alertes de sécurité, l'état des sauvegardes. Laravel n'a rien de tel. L'application est un assemblage de composants qui interagissent sans interface unifiée, et chacun peut tomber en panne sans que la page d'accueil ne retourne une erreur HTTP.

Les cinq points qui distinguent la maintenance Laravel d'une maintenance CMS :

• Dépendances Composer : des dizaines de packages tiers, chacun avec son calendrier de correctifs. Une mise à jour patch peut corriger une faille de sécurité ; une mise à jour mineure peut introduire une interface incompatible avec votre code applicatif.
• Queues et workers : les traitements asynchrones — envois d'e-mails, notifications, imports en arrière-plan — tournent dans des processus séparés du serveur web. Un worker arrêté ne produit aucune erreur HTTP : la queue s'accumule en silence pendant que l'utilisateur croit que ses actions sont traitées.
• Scheduler Laravel : toutes les tâches planifiées dépendent d'une seule entrée cron (* * * * * php artisan schedule:run). Si ce cron disparaît, aucun travail planifié ne s'exécute — sans alarme.
• Clé d'application (APP_KEY) : elle chiffre les sessions, les cookies et certaines données stockées. Sa rotation exige un déploiement coordonné pour ne pas invalider les sessions actives en cours.
• Couplage PHP / Laravel : chaque version de Laravel requiert une version minimale de PHP, définie dans la politique de support officielle de Laravel. Un saut de PHP 8.1 à 8.3 se prépare en staging, pas directement en production.

Ces spécificités font de Laravel un candidat naturel pour un contrat de TMA : votre client comprend que son application métier a besoin d'un suivi structuré, différent d'un abonnement de maintenance WordPress standard.

Checklist de maintenance Laravel mensuelle et trimestrielle

La valeur d'une prestation de maintenance tient autant à la régularité de son exécution qu'à sa technicité. Voici les vérifications à formaliser ou automatiser selon la fréquence.

Actions mensuelles

1. Audit de sécurité Composer — exécuter composer audit pour détecter les packages ayant des avis de sécurité publiés sur Packagist. La documentation officielle de Composer décrit les options de format utiles, notamment --format json, pour automatiser la remontée des résultats dans un rapport client.
2. Mise à jour des dépendances patches — appliquer les montées en version patch après une sauvegarde complète et un passage des tests automatisés ou, à défaut, du parcours critique sur l'environnement de staging.
3. Revue des logs applicatifs — parcourir storage/logs/laravel.log à la recherche d'exceptions récurrentes, de timeouts base de données, de tentatives d'accès à des ressources manquantes. Les erreurs de niveau critical méritent une prise en charge immédiate.
4. Vérification des jobs échoués — la commande php artisan queue:failed liste les jobs ayant atteint leur limite de tentatives. Identifier la cause, corriger si possible, puis purger avec php artisan queue:flush.
5. Validation des sauvegardes — confirmer que la dernière sauvegarde de la base de données et des fichiers s'est terminée sans erreur. Une sauvegarde non testée n'a pas de valeur opérationnelle.

La commande composer audit liste chaque avis de sécurité avec la version concernée et la correction disponible.

Actions trimestrielles

1. Montées de version mineures — évaluer les nouvelles versions mineures des dépendances Composer. Lire les changelogs, identifier les changements d'interface, tester sur staging avant de déployer. Sans environnement de staging à jour, cette opération est trop risquée à réaliser directement en production.
2. Compatibilité PHP / Laravel — vérifier la version de PHP requise par la version de Laravel installée et sa date de fin de support actif. Planifier la migration avant l'expiration du support, pas après.
3. Audit des dépendances JavaScript — si le projet embarque un pipeline Vite, npm audit ou yarn audit remonte les failles connues côté front. Les vulnérabilités JavaScript peuvent exposer des données saisies par les utilisateurs.
4. Revue du fichier .env — identifier les clés API expirées, les services désactivés, les URL qui ont changé de domaine. Un fichier .env périmé est une source fréquente d'incidents silencieux.
5. Mesure des Core Web Vitals — un score Lighthouse en baisse peut signaler une régression introduite par une mise à jour de dépendance front ou un changement de configuration serveur non anticipé.

Ces vérifications forment le contenu du rapport de maintenance mensuel que vous livrez à votre client comme preuve de prestation — et comme argument de renouvellement.

Superviser une application Laravel en production

La supervision d'une application Laravel couvre quatre niveaux distincts. Confondre disponibilité HTTP et santé globale de l'application est l'erreur classique des équipes habituées à maintenir des CMS.

Disponibilité HTTP et logs applicatifs

Une sonde HTTP toutes les 5 minutes sur l'URL principale détecte les indisponibilités et les erreurs 5xx. C'est la couche minimale, mais elle ne suffit pas : une page peut répondre 200 pendant que les e-mails transactionnels ne partent plus depuis des heures ou que la synchronisation de données s'est interrompue.

Pour les logs, configurez des alertes sur les niveaux critical et error dans le channel de log Laravel. Si le projet utilise un service comme Sentry ou Flare, préférez des alertes par seuil — par exemple, plus de 10 erreurs en une heure — plutôt que par événement unitaire, pour éviter la saturation des notifications pendant les pics de charge.

Queues et jobs planifiés

Le monitoring des jobs échoués doit être automatisé : une vérification quotidienne du nombre d'entrées dans la table failed_jobs, avec une alerte si ce nombre dépasse un seuil défini. Pour le scheduler, un heartbeat est la méthode la plus fiable : une tâche planifiée émet un signal vers un service de monitoring externe à chaque exécution, et l'absence de signal dans le délai attendu déclenche une alerte.

Sécurité et dépendances Composer

Sentinelo applique 10 contrôles de sécurité aux applications Composer (dont Laravel), exécutés chaque semaine et à la demande, en croisant les avis Composer Audit. Pour les applications Laravel, les mises à jour détectées sont signalées à votre équipe — elles ne sont jamais appliquées automatiquement. C'est votre équipe qui décide de les déployer après validation. Cette distinction est à formaliser explicitement dans votre contrat.

Pour la gestion d'un parc de plusieurs dizaines d'applications, l'article superviser 50 sites clients sans se noyer détaille comment structurer les alertes sans créer de bruit inutile.

Structurer son contrat TMA Laravel

Un contrat de TMA Laravel ne ressemble pas à un abonnement de maintenance WordPress. Il couvre une application sur mesure avec un périmètre technique précis, un SLA adapté à un usage métier et une tarification qui reflète la complexité de la stack.

Périmètre et exclusions

Définissez précisément ce qui est inclus dans votre forfait :

• Monitoring HTTP continu et alertes (heures ouvrées ou 24/7 selon le niveau de service).
• Audits de sécurité Composer mensuels et remontée des CVE.
• Application des mises à jour patches, après sauvegarde et validation sur staging.
• Revue mensuelle des logs et des jobs échoués.
• Rapport mensuel : disponibilité, dépendances auditées, incidents traités.
• Quota d'heures d'intervention corrective incluses par mois.

Et ce qui n'est pas couvert :

• Développement de nouvelles fonctionnalités.
• Migration vers une version majeure de Laravel (devisée séparément).
• Refonte de l'architecture ou changement de moteur de base de données.
• Application des mises à jour mineures et majeures sans recette préalable.

Cette liste d'exclusions protège votre marge. Un client qui confond maintenance et évolution appellera en urgence pour des développements hors périmètre.

SLA et niveaux de priorité

Pour une application métier — commandes, facturation, accès client — les incidents bloquants demandent une réactivité différente d'un site vitrine. Formalisez les niveaux dans votre contrat :

Priorité	Définition	Premier contact	Résolution cible
Critique	Application inaccessible ou données corrompues	1 h	4 h (jours ouvrés)
Haute	Fonctionnalité principale dégradée	4 h	1 jour ouvré
Standard	Anomalie non bloquante	24 h	5 jours ouvrés

Précisez dans le contrat que ces délais s'entendent en heures ouvrées (9 h–18 h CET, jours ouvrés) sauf mention explicite d'astreinte, qui justifie un supplément tarifaire.

Livrables et tarification

Un rapport mensuel PDF — liste des dépendances auditées, incidents traités, métriques de disponibilité — est la preuve de prestation que vous livrez à chaque renouvellement. C'est aussi l'outil qui justifie votre valeur ajoutée face à un client qui ne perçoit pas la maintenance au quotidien.

Pour construire votre grille tarifaire, l'article tarifer la maintenance web détaille les méthodes de calcul de marge selon la complexité de la stack et le niveau de SLA proposé.

Audit préalable et reprise

Avant de signer un contrat TMA Laravel, auditez l'état réel de l'application : version de Laravel installée, version de PHP, état des dépendances Composer, présence de tests automatisés, qualité des sauvegardes existantes. Une application sur une version de Laravel en fin de support avec PHP 7.x demandera un effort de remise à niveau à tarifer séparément — pas à absorber silencieusement dans le forfait mensuel.

Le guide TMA web pour agences aborde les aspects organisationnels : comment structurer vos équipes, gérer les accès et maintenir la traçabilité des interventions sur un parc multi-stack.

Si vous maintenez déjà des applications Symfony, les similitudes avec Laravel sont nombreuses : Composer, scheduler, queues, versions PHP couplées au framework. L'article maintenance Symfony pour agences vous donnera des repères pour construire une offre cohérente sur les deux stacks.

Pour approfondir la supervision quotidienne avant de structurer un contrat, l'article maintenir une application Laravel en production détaille les métriques à suivre au jour le jour.