TMA Magento — maintenance boutique e-commerce

Magento est un écosystème plus complexe que Symfony ou Laravel pur. Le système de modules (di.xml, plugins, observers, layout XML) crée des couches d'abstraction supplémentaires. Les patches Adobe sont trimestriels et nécessitent des tests de non-régression spécifiques au checkout et au catalogue. Les développeurs Magento 2 seniors sont rares sur le marché, ce qui se reflète dans les TJM. Enfin, l'infrastructure requise (Varnish, Redis, Elasticsearch) ajoute de la complexité opérationnelle. Tout cela justifie un forfait mensuel plus élevé que pour une application PHP classique.

Oui, les deux. Magento Open Source (ex-Community Edition) et Adobe Commerce (ex-Enterprise Edition) partagent le même coeur, mais Adobe Commerce ajoute des fonctionnalités B2B (devis, catalogues partagés, rôles acheteur), le staging de contenu, et des modules propriétaires. Notre équipe connaît les deux versions. Si vous êtes sur Adobe Commerce, les patches de sécurité sont les mêmes, mais certaines mises à jour spécifiques aux modules propriétaires demandent une attention supplémentaire.

C'est un cas fréquent avec Magento. Si vous avez accès au serveur (SSH ou panel hébergeur), on peut récupérer le code source et reconstituer le dépôt Git. Si le code est sur un repo que l'agence contrôle, c'est une question juridique : le code vous appartient contractuellement dans la majorité des cas. On a l'habitude de ces reprises. La première étape est un audit de reprise, chiffré sur devis, pour cartographier l'existant : version Magento, modules installés, intégrations, état du code, dette technique. Ensuite, on propose un plan de TMA adapté. Voir notre offre de reprise de projet abandonné.

Les conflits de modules sont le problème numéro un en maintenance Magento. Deux modules qui déclarent un plugin sur la même méthode, un observer qui modifie le comportement du checkout de manière incompatible avec un module de paiement — c'est le quotidien. Notre approche : on maintient une matrice de compatibilité des modules installés sur chaque projet, on teste chaque mise à jour de module isolément sur staging avant de la combiner avec les autres, et on a développé des scripts de détection automatique des conflits di.xml. Quand un conflit est détecté, on contacte l'éditeur du module ou on développe un patch de compatibilité custom.