Maintenance Symfony industrialisée : dépendances, PHP et mises à jour

Maintenance Symfony industrialisée : dépendances, PHP et mises à jour

Sur une application Symfony, il n'existe pas de bouton « tout mettre à jour ». Une mise à jour met en jeu composer update, des migrations de base de données, un cache:clear, puis un déploiement. L'opération est rarement atomique, souvent impossible directement en production où le dossier vendor/ n'est pas inscriptible, et toujours soumise au pipeline du projet. La maintenance Symfony industrialisée consiste donc à préparer ces mises à jour en amont : savoir ce qui doit être corrigé, pourquoi, et dans quel ordre, avant d'y toucher.

Industrialiser, ici, ne signifie pas tout automatiser. Cela revient à remplacer les interventions au cas par cas par un cycle régulier et mesuré : audit des dépendances, suivi de la version de PHP, sauvegardes vérifiées et liste de priorités tenue à jour. Ce guide décrit chaque brique de ce cycle et précise qui agit, à quel moment.

Auditer les dépendances à chaque scan

Le socle d'une application Symfony, c'est son fichier composer.lock : la liste figée des paquets installés et de leurs versions exactes. C'est là que se logent la plupart des failles connues, pas dans votre code métier. La commande composer audit compare ces versions aux avis de sécurité publiés et signale chaque paquet concerné, avec la version qui corrige lorsque l'avis la donne.

Sur Sentinelo, l'agent installé dans l'application exécute composer audit à chaque passage et croise le résultat avec la base Composer Audit. Une faille publiée sur un paquet du projet remonte au scan suivant, classée par gravité, dans la liste « À corriger » du site. L'intérêt d'un scan récurrent plutôt que ponctuel : une dépendance saine aujourd'hui peut devenir vulnérable demain, sans qu'une seule ligne de votre code ait changé.

Surveiller la version de PHP

Une application Symfony s'exécute sur une version précise de PHP, et chaque version a une date de fin de support. Passé cette date, plus aucun correctif de sécurité n'est publié : la dette devient invisible tant que rien ne casse. Le scan relève la version de PHP qui fait tourner l'application ; une version qui ne reçoit plus de correctifs fait baisser la note et apparaît comme un point à corriger.

Le suivi de PHP se lit en parallèle de celui de Symfony. D'après la documentation officielle de Symfony, le framework publie une version mineure tous les six mois et une version majeure tous les deux ans ; les versions de support à long terme (LTS) bénéficient de trois ans de correctifs. Chaque version de Symfony impose un PHP minimal : planifier la montée de PHP et celle du framework ensemble évite de se retrouver coincé entre une dépendance qui exige un PHP récent et un serveur resté en arrière.

Les dix contrôles du scan Symfony

Sur les applications bâties sur Composer — Symfony, Sylius, Laravel — le scan de sécurité note dix contrôles. On y retrouve notamment le mode debug laissé actif en production, l'exposition de fichiers sensibles, le listage des répertoires, les fichiers de configuration accessibles, les en-têtes de sécurité, la validité du certificat, les permissions des fichiers, la présence de fichiers suspects et la version de PHP. Un contrôle qui n'a pas de sens pour une application donnée est retiré du barème, jamais compté comme réussi : la note reflète ce qui est réellement mesuré.

Ce scan s'exécute chaque semaine et à la demande. Il ne remplace pas une revue de code, mais il cadre le périmètre : avant de parler de nouvelles fonctionnalités, une maintenance industrialisée s'assure que ces points ne dérivent pas. Le détail des contrôles par technologie figure sur la page sécurité de la plateforme.

Qui applique les mises à jour

C'est là qu'une maintenance Symfony se distingue d'une maintenance WordPress. Sur WordPress ou WooCommerce, les mises à jour peuvent s'appliquer automatiquement après une sauvegarde récente, avec retour arrière si le site cesse de répondre. Sur Symfony, Sylius et Laravel, elles sont détectées et signalées, jamais appliquées automatiquement.

Ce n'est pas une limite technique, c'est un choix. Appliquer composer update à la place du pipeline du projet — sans rejouer les tests, sans passer par la préproduction, sans contrôler les migrations — serait plus dangereux que de ne rien faire. L'agent surveille, sauvegarde la base et les fichiers, scanne, et la plateforme restitue la liste des actions, du plus grave au moins grave. L'application, elle, reste du ressort d'un humain.

• Pour un client final sur l'offre Sur mesure, c'est un ingénieur Sentinelo qui applique la mise à jour, sur les heures d'intervention incluses dans le forfait — quatre heures par mois.
• Pour une agence, l'offre fournit l'outillage et la liste priorisée ; ce sont les développeurs de l'agence qui interviennent, avec leurs propres méthodes de déploiement.

Cette répartition écarte le pire scénario : une mise à jour appliquée à l'aveugle sur un serveur de production un vendredi soir. La décision d'appliquer reste documentée, priorisée et tracée dans les rapports mensuels.

Sauvegarder et restaurer avant d'y toucher

Aucune mise à jour Symfony ne devrait partir sans une sauvegarde récente et vérifiée. L'agent réalise une sauvegarde nocturne de la base de données et des fichiers, chiffrée avant transfert avec une clé propre au site, accompagnée d'une empreinte SHA-256 et d'une vérification après stockage. Si une mise à jour tourne mal, la restauration est lancée par l'équipe Sentinelo à partir de n'importe quelle archive conservée — et non par un bouton côté client.

La logique de rétention, et la différence entre une sauvegarde et un vrai plan de reprise, sont détaillées dans notre guide sur la stratégie de sauvegarde GFS. Pour une application métier, c'est cette sauvegarde qui transforme une mise à jour risquée en opération réversible.

Une mise à jour Symfony, étape par étape

Une fois la liste des correctifs connue, l'application suit toujours le même chemin :

1. Lire les notes de version et le guide de migration des paquets concernés avant toute commande.
2. Reproduire la mise à jour en préproduction : composer update ciblé, migrations de base, vidage du cache.
3. Rejouer la suite de tests et vérifier les points sensibles — authentification, paiement, tâches planifiées.
4. Déployer en production via le pipeline du projet, jamais en modifiant vendor/ à la main.
5. Contrôler la supervision juste après : code HTTP, temps de réponse, erreurs applicatives.

Si un écart apparaît à l'étape de vérification, on revient à la version précédente à partir de la sauvegarde plutôt que de corriger à chaud en production. C'est cette réversibilité qui autorise à mettre à jour sans tout bloquer.

Sylius et Laravel : le même agent Composer

Sylius est bâti sur Symfony, et Laravel repose lui aussi sur Composer. Le même agent les couvre, avec le même périmètre et la même règle sur les mises à jour : détecter, signaler, laisser un humain appliquer. Ces trois technologies sont proposées sur demande, et l'agent s'installe comme un paquet Composer dans l'application.

Si vous gérez une boutique Sylius, le raisonnement sur les modules et le tunnel de commande rejoint celui décrit dans notre article sur la maintenance d'une boutique Sylius. Pour une application Laravel, la logique de surveillance est identique : voir maintenir une application Laravel en production.

Mettre en place une maintenance Symfony industrialisée

Industrialiser la maintenance d'une application Symfony tient en quelques gestes répétés sans exception : auditer les dépendances à chaque cycle, suivre la version de PHP et celle du framework, scanner les points de sécurité, sauvegarder avant toute intervention, et tenir une liste de priorités qui dit quoi faire et dans quel ordre. L'automatisation s'arrête là où commence le risque : la mise à jour elle-même reste pilotée par un ingénieur.

Pour une agence qui gère un parc d'applications PHP, cette discipline se délègue : la supervision, le scan et les sauvegardes sont outillés, la montée de version reste entre vos mains. Voir comment Sentinelo gère les mises à jour détectées et signalées, ou comment l'offre agence s'articule autour d'un parc multi-stack.