TMA Sylius : reprendre la maintenance d'une boutique sans mauvaise surprise

TMA Sylius : reprendre la maintenance d'une boutique sans mauvaise surprise

Reprendre la maintenance d'une boutique Sylius que vous n'avez pas développée, c'est souvent découvrir un composer.lock figé depuis des mois, des workers Messenger arrêtés et des bundles custom dont personne ne sait s'ils ont des tests. Avant de signer un contrat de TMA Sylius, une due diligence technique évite de porter le passif d'une autre agence. Ce guide couvre les spécificités de Sylius qui compliquent la maintenance, le périmètre d'un contrat adapté, les SLA par type d'incident, et une checklist de 12 points à exécuter lors de toute reprise.

• Ce qui complique la maintenance d'une boutique Sylius
• Périmètre d'une TMA Sylius
• SLA recommandés par type d'incident
• Checklist de due diligence avant reprise
• Supervision et sauvegardes : ce que Sentinelo couvre

Ce qui complique la maintenance d'une boutique Sylius

Architecture DDD, Symfony et API Platform

Sylius est construit sur Symfony avec une architecture orientée Domain-Driven Design. Chaque entité métier — produit, commande, stock — est découpée en couches domain, application et infrastructure séparées. Cette rigueur facilite les tests, mais elle multiplie les points d'extension : un bundle custom qui surcharge un StateResolver ou remplace une Factory peut casser silencieusement lors d'une mise à jour mineure si l'interface ciblée n'est pas couverte par la BC promise.

Beaucoup de boutiques ajoutent API Platform pour exposer le catalogue ou les commandes à un front découplé. Chaque entité exposée dépend alors d'annotations de sérialisation et de filtres de collection qui changent de comportement entre les versions. Avant toute mise à jour, vérifiez que les contrats d'API sont couverts par des tests automatisés.

Cycle de versions et BC breaks

Sylius suit le versioning sémantique. Seules les versions majeures autorisent des ruptures de compatibilité ascendante. Les versions mineures (par exemple 1.12 → 1.13) introduisent des fonctionnalités sans casser le code existant, mais elles nécessitent d'exécuter les migrations de base de données. Les versions patch (1.x.y) se limitent à un nettoyage du cache Symfony. C'est la BC promise officielle de Sylius, qui étend celle de Symfony.

Le code marqué @internal ou @experimental, ainsi que les interfaces de modèles et de repositories, sont explicitement exclus de cette promesse. Or, beaucoup de bundles custom surclassent exactement ces points — c'est la source la plus fréquente de régressions lors d'une montée de version Sylius.

Workers Symfony Messenger : le point aveugle le plus courant

Sylius utilise Symfony Messenger pour traiter les événements asynchrones : confirmation de commande par email, mise à jour des stocks, synchronisation ERP. Ces workers tournent en processus de fond via Supervisor ou un service systemd. Sur une reprise de TMA, il n'est pas rare de trouver des workers arrêtés depuis des semaines : la boutique semble fonctionner normalement en façade, mais les emails ne partent pas et les stocks ne se synchronisent pas. Surveiller la profondeur de la queue et l'âge du message le plus ancien est indispensable en supervision de production.

Périmètre d'une TMA Sylius

Surveillance

La supervision d'une boutique Sylius dépasse le simple ping HTTP. En plus de la disponibilité du front, le périmètre de surveillance doit couvrir :

• l'état des workers Messenger (processus vivant et profondeur de la queue),
• l'intégrité des commandes récentes (aucune commande bloquée dans un état intermédiaire depuis plus de 24 heures),
• la validité du certificat SSL et les temps de réponse de l'API Platform si elle alimente un front découplé.

La supervision Sentinelo surveille la disponibilité HTTP avec double confirmation de panne avant alerte, et enregistre les temps de réponse pour détecter une dégradation progressive avant qu'elle affecte les conversions.

Mises à jour de bundles et dépendances Composer

Les mises à jour d'une boutique Sylius suivent un ordre précis : d'abord le core Sylius, ensuite les bundles tiers (SyliusMailerBundle, SyliusResourceBundle, Payum, etc.), enfin les bundles custom s'ils ont des dépendances sur les précédents. Chaque mise à jour doit être précédée d'une sauvegarde et suivie d'un passage de la suite de tests. Sans tests automatisés, un smoke test manuel sur les parcours critiques (ajout au panier, paiement, confirmation de commande) est le minimum.

Pour une montée de version mineure avec migrations, la procédure est :

1. Sauvegarde complète de la base de données.
2. Mise à jour des dépendances : composer update sylius/sylius --with-all-dependencies
3. Exécution des migrations : php bin/console doctrine:migrations:migrate --no-interaction
4. Nettoyage du cache : php bin/console cache:clear --env=prod
5. Vérification des logs Symfony en post-déploiement.

L'article sur la maintenance Symfony industrialisée détaille la stratégie de gestion des dépendances Composer dans ce contexte.

Sauvegardes

Une boutique Sylius stocke ses données dans trois endroits : la base de données relationnelle (commandes, catalogue, clients), les assets médias (images produits, souvent sur S3 ou un stockage objet équivalent), et la configuration applicative (fichiers .env, secrets d'API). Un plan de sauvegarde complet couvre ces trois composants et teste régulièrement la procédure de restauration. Les sauvegardes Sentinelo appliquent une rétention de 7 quotidiennes, 4 hebdomadaires et 12 mensuelles, avec chiffrement avant transfert.

SLA recommandés par type d'incident Sylius

La priorité d'un incident e-commerce se détermine par son impact direct sur le chiffre d'affaires et la confiance client :

Priorité	Exemple d'incident	Objectif premier contact	Objectif résolution
P1	Paiement KO, boutique inaccessible	1 heure	4 heures
P2	Catalogue inaccessible, workers arrêtés	4 heures	8 heures
P3	Anomalie cosmétique, lenteur isolée	Jour ouvré suivant	5 jours ouvrés

Ces objectifs sont à adapter à la taille de la boutique et au secteur. Une boutique B2B avec des cycles de commande nocturnes a des exigences différentes d'un site retail grand public. L'article sur la tierce maintenance applicative pour agences web revient sur le cadrage contractuel des niveaux de service.

Checklist de due diligence avant de reprendre une TMA Sylius

C'est le moment le moins documenté en français, et pourtant le plus déterminant. Ces 12 points sont à vérifier avant de signer un contrat de maintenance sur une boutique Sylius existante — qu'elle soit en production depuis six mois ou six ans.

1. Lire le composer.lock : identifiez la version exacte de Sylius installée, les bundles custom présents et la date de la dernière mise à jour des dépendances.
2. Comparer avec la version courante de Sylius : calculez le retard (nombre de mineures manquées, migrations en attente) et évaluez l'effort de rattrapage avant de vous engager sur un tarif.
3. Recenser les BC breaks accumulés : lisez les fichiers CHANGELOG et UPGRADE.md de chaque version sautée pour identifier les modifications d'API qui touchent les bundles custom.
4. Auditer les bundles custom : sont-ils dans un dépôt privé avec un accès garanti ? Ont-ils des tests unitaires ou fonctionnels ? Existe-t-il une documentation d'intent expliquant pourquoi chaque bundle a été créé ?
5. Vérifier l'état des workers Messenger : la commande php bin/console messenger:stats donne l'état instantané des queues. Des messages âgés de plusieurs heures signalent un worker arrêté qui n'a jamais déclenché d'alerte HTTP visible.
6. Analyser la profondeur des queues AMQP : une queue qui grossit sans être consommée peut provoquer une saturation mémoire ou des timeouts d'API lors d'une reprise brutale après un arrêt.
7. Contrôler l'intégrité des commandes récentes : cherchez les commandes bloquées dans un état intermédiaire (new, payment_selected, awaiting_shipping) depuis plus de 24 heures. Elles révèlent souvent un problème de worker ou de webhook de paiement.
8. Vérifier la dernière sauvegarde exécutée : sa date, sa taille, et surtout — la procédure de restauration est-elle documentée et a-t-elle déjà été testée ? Une sauvegarde non testée n'est pas une sauvegarde.
9. Inventorier les tests automatisés : couverture Behat sur les workflows commande, tests unitaires sur les services critiques — et la proportion du code custom effectivement couverte.
10. Identifier les migrations Doctrine non exécutées : php bin/console doctrine:migrations:status indique si le schéma en base est en retard sur le code déployé.
11. Cartographier les intégrations tierces : ERP, PIM, WMS, prestataire de paiement, transporteurs. Chaque intégration est un point de défaillance indépendant, avec ses propres credentials et son propre niveau de SLA.
12. Obtenir les accès complets dès le premier jour : SSH au serveur, tokens d'authentification Composer pour les paquets privés, accès au dépôt git, identifiants des services cloud. Un accès manquant au moment d'un incident bloquant coûte du temps et de la relation client.

Sur une boutique avec de nombreux bundles custom ou des intégrations ERP complexes, ajoutez un audit de performance (analyse des requêtes lentes, profiling Symfony) et un contrôle des logs d'erreur des 30 derniers jours.

Supervision et sauvegardes : ce que Sentinelo couvre pour les boutiques Sylius

Sentinelo prend en charge les boutiques Sylius dans l'offre Sur mesure, disponible sur demande. La supervision HTTP vérifie la disponibilité avec une double confirmation de panne avant de déclencher une alerte. Les applications Composer font l'objet de 10 contrôles de sécurité hebdomadaires, croisés avec Composer Audit et l'analyse de réputation Sucuri. Les mises à jour Sylius et Symfony sont détectées et signalées automatiquement — elles ne sont jamais appliquées sans intervention humaine. Sur l'offre agence, c'est votre équipe qui intervient ; sur l'offre client final, un ingénieur Sentinelo applique la mise à jour.

Les sauvegardes nocturnes couvrent la base de données et les fichiers, avec chiffrement avant transfert et vérification SHA-256 de l'intégrité. La restauration se fait sur demande, à partir de n'importe quelle archive dans la rétention de 24 mois.

Pour structurer votre contrat de TMA Sylius en vous appuyant sur cet outillage, consultez la page maintenance Sylius Sentinelo.