Maintenir un module sur mesure dans le temps
Un module sur mesure n’est pas un objet fini. La plateforme change de version, PHP retire des fonctions, une API tierce modifie son format de réponse : le module n’a pas bougé, mais son environnement, lui, ne l’a pas attendu.
Ce qui bouge sous un module, même quand personne n’y touche
Trois couches évoluent indépendamment de vous. La plateforme d’abord : un changement de version majeure peut retirer un point d’accroche, renommer une méthode ou remplacer tout un pan de l’administration. PHP ensuite : chaque version supprime des fonctions dépréciées, et un module écrit il y a quelques années peut cesser de fonctionner à la première mise à jour du serveur, souvent décidée par l’hébergeur et pas par vous. Les services extérieurs enfin : un transporteur, une passerelle de paiement ou un logiciel de gestion peuvent faire évoluer leur interface, avec un préavis dont personne ne vous informe si vous n’êtes pas inscrit à leurs annonces techniques.
Un module qui ne fait que de l’affichage tient longtemps. Un module qui parle à un système extérieur est celui qui demande le plus d’attention, parce que la panne viendra d’ailleurs que de son code.
Ce que je fais concrètement en maintenance
-
Suivre les versions
Vérifier avant chaque montée de version de la plateforme ou de PHP que le module reste compatible, et l’adapter si ce n’est pas le cas.
-
Surveiller les échanges extérieurs
Journaliser les appels aux services tiers, pour que la panne soit visible le jour où elle arrive plutôt qu’une semaine après.
-
Corriger les cas non prévus
Un module rencontre en production des situations que la recette n’avait pas imaginées. Ces corrections font partie de la vie normale d’un développement.
-
Garder le code reprenable
Sources à jour, dépendances identifiées, procédure d’installation écrite : de quoi confier le module à quelqu’un d’autre à tout moment.
Ce que la maintenance ne couvre pas
Je distingue nettement trois choses, parce que les confondre est la première source de désaccord. La correction d’un défaut du module fait partie de la maintenance. L’adaptation à une évolution extérieure — nouvelle version majeure de la plateforme, nouveau format imposé par un partenaire — est un travail identifiable, que je chiffre à part quand il est significatif. L’ajout d’une fonction nouvelle est un développement, même s’il est petit, et il est traité comme tel.
Je le dis d’avance parce que le contraire ne tient pas : un forfait de maintenance qui absorberait n’importe quelle demande d’évolution serait soit surfacturé, soit tenu au détriment de ce pour quoi il existe. Annoncer la limite vaut mieux que la découvrir en cours de route.
Pages liées
-
Maintenance et infogérance
Le cadre général, au-delà du seul module : mises à jour, sauvegardes, surveillance.
-
Un module cassé par sa propre mise à jour
Quand la panne survient au moment précis d’un changement de version.
-
Préparer une mise à jour majeure
La méthode de préparation, côté boutique complète.
-
Audit du parc de modules
Pour savoir ce qui mérite d’être maintenu et ce qui mérite d’être retiré.
- 2019 développeur e-commerce depuis
- 3 plateformes : PrestaShop, WooCommerce, Shopify
- 3 langues de travail : FR, EN, TR
- 100 % des échanges directs avec le développeur
Aucun intermédiaire : la personne qui répond est celle qui intervient sur le code.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.