Travailler sur une techno obsolète (Magento 1.9) sans freiner l’évolution du client

Magento 1.9 est mort depuis 2020. Plus de mises à jour de sécurité, plus de support éditeur, une doc qui sent la naphtaline. Des boutiques tournent encore dessus en 2026. Avec du vrai chiffre d’affaires, de vrais clients, et des demandes d’évolution qui n’ont rien d’obsolète, elles.

Le métier intéressant n’est pas dans le développement propre sur une stack à jour. Il est dans la capacité à faire évoluer un système qu’on ne peut plus vraiment faire évoluer, sans le casser, et sans dire au client qu’on ne peut rien faire.

Pourquoi ces sites tournent encore

Rarement par négligence. Une migration Magento 1 vers Magento 2, ou vers une autre plateforme, c’est un projet à cinq chiffres, plusieurs mois de travail, un risque réel sur le référencement et les habitudes des clients. Pour un e-commerçant dont la marge ne le permet pas, la vraie question n’est pas « faut-il migrer un jour » mais « comment continuer à vendre correctement d’ici là ».

Le développeur ne vend plus une réécriture idéale. Il livre des évolutions concrètes sur l’existant, avec les contraintes qui vont avec.

Les contraintes du terrain

Sur ce type de mission, on compose souvent avec :

• pas d’accès SSH, juste du FTP ;
• pas d’accès direct à la base de données. Connexion PDO manuelle via les identifiants de configuration, sans passer par le bootstrap applicatif, qui peut bloquer indéfiniment sur un vieux serveur ;
• une base de code truffée de contournements hérités de dix ans d’interventions successives ;
• zéro marge d’erreur. Un module mal pensé peut casser le tunnel de commande d’un site qui vend en continu.

Les scripts de diagnostic se préparent en fichiers complets prêts à déployer. Ils s’exécutent via un token de sécurité, puis se suppriment aussitôt. Rien ne reste en place plus longtemps que nécessaire. Sur une stack moderne avec CI/CD, ce réflexe n’est pas indispensable. Ici, c’est la seule barrière entre « ça marche » et « le site est down un samedi ».

Faire évoluer sans réécrire

Connaître Magento 1.9 par cœur ne suffit pas. La vraie compétence, c’est de savoir où poser un module custom pour répondre à un besoin métier précis, sans toucher au cœur du système.

Un système d’association d’accessoires à des catégories de produits. Un tableau de comparaison piloté par JSON, avec réorganisation par glisser-déposer. Un export PDF pour le showroom physique. Une relance de panier abandonné connectée à un CRM externe. Chaque brique répond à un besoin business précis, exprimé par le client, et vit à côté du noyau Magento sans jamais le modifier directement.

Cette discipline a un nom : la compatibilité ascendante permanente. Chaque ligne de code écrite doit continuer de fonctionner après la prochaine mise à jour de contenu faite par le client lui-même, sans supervision technique.

Exemple classique : une option de paiement qui se réactive toute seule à chaque sauvegarde de configuration. La vraie solution n’est pas de la désactiver une fois. C’est de construire une page d’administration dédiée qui la garde désactivée durablement, quoi qu’il se passe côté client.

Pas de place pour l’approximation

Le vieux code n’excuse rien. Les mêmes exigences s’appliquent, parfois renforcées : traçabilité des correctifs sur le SEO, le tracking analytics, la conformité des flux produits. Tests systématiques en préproduction avant toute mise en production. Documentation des contournements, pour que la prochaine intervention, la sienne ou celle d’un autre développeur, ne reparte pas de zéro.

Sur un projet neuf, on peut refactoriser large pour corriger un problème local. Pas ici. Chaque correctif doit être chirurgical : la modification la plus petite possible pour obtenir l’effet recherché, sans effet de bord sur un système qu’on ne maîtrise jamais à 100 %.

Ce que ça change avec le client

Le client n’a pas besoin d’entendre « c’est vieux, on ne peut pas ». Il a besoin d’un scope clair : ce qui est faisable rapidement, ce qui demande un chiffrage à part, ce qui doit attendre une intervention plus lourde sur l’infrastructure. Séparer les sujets applicatifs, qu’on peut traiter, des sujets serveur, qui relèvent souvent d’un autre prestataire, évite les malentendus et les attentes irréalistes.

Le jour où la migration deviendra possible, elle se fera. En attendant, le business continue de tourner. C’est exactement ce que le client attend du développeur qui s’occupe de son legacy.

Vous avez un projet e-commerce qui dépasse les capacités des solutions standard ? Parlons-en.