Le module fonctionne, mais son éditeur a disparu
Le module tourne, la boutique vend, et pourtant l’éditeur ne répond plus. Pas de nouvelle version depuis longtemps, un support qui ne renvoie rien, parfois un site commercial qui n’existe plus. Ce n’est pas une urgence, mais c’est une décision à prendre avant qu’elle ne soit prise à votre place.
Ce qui va effectivement se passer, et quand
Un module abandonné ne s’arrête pas du jour au lendemain. Il continue de fonctionner tant que son environnement ne bouge pas, et c’est justement ce qui trompe : le problème surgit à la première montée de version de PHP ou de la plateforme, souvent décidée par votre hébergeur et pas par vous. Ce jour-là, plus personne ne publiera de version compatible.
Le calendrier réel dépend de ce que fait le module. Un module d’affichage peut survivre des années. Un module qui parle à un service extérieur s’arrêtera au premier changement d’interface chez ce service, et vous ne serez pas prévenu. Un module de paiement est le cas le plus contraint : les exigences de sécurité des prestataires évoluent, et un module non maintenu finit par être refusé côté prestataire, pas côté boutique.
À côté du fonctionnement, il y a la sécurité : un module qui ne reçoit plus de correctifs conserve indéfiniment ses failles éventuelles. C’est un sujet distinct et sérieux, traité à part.
Les trois issues, dans l’ordre où je les examine
-
Se passer du module
La question à poser en premier, et rarement posée : la fonction est-elle encore utilisée ? Un module installé pour une opération commerciale terminée depuis deux ans se retire, il ne se remplace pas.
-
Le remplacer par un équivalent maintenu
Le plus rapide quand la fonction est standard. Le travail réel n’est pas l’installation du remplaçant mais la reprise des données accumulées par l’ancien module, qui ne sont presque jamais dans un format compatible.
-
Reprendre son code
Possible seulement si le code est lisible et que la licence l’autorise. Le module devient alors le vôtre, avec sa maintenance à votre charge. C’est un choix défendable pour une fonction spécifique dont vous dépendez et qu’aucun autre module ne couvre.
-
Le réécrire
Quand le code est encodé ou trop dégradé pour être repris, et que la fonction reste indispensable. Le module d’origine sert alors de spécification : il montre exactement ce qui est attendu, cas particuliers compris.
Ce que je regarde avant de conseiller quoi que ce soit
Je commence par mesurer la dépendance réelle. Combien de commandes passent par cette fonction chaque mois, quelles données le module détient en propre, et ce qui se passerait concrètement s’il s’arrêtait demain matin. Cette mesure change souvent la décision : une fonction utilisée deux fois par mois ne justifie pas une réécriture, alors qu’une fonction présente sur chaque commande la justifie sans discussion.
J’examine ensuite les données. Un module abandonné a souvent créé ses propres tables, et ces tables contiennent parfois des années d’historique. Les récupérer avant tout retrait est la seule opération vraiment irréversible du dossier : on peut réinstaller un module, on ne réinvente pas des données supprimées.
Enfin, je vérifie s’il existe un moyen de gagner du temps sans rien engager : figer la version de PHP pour quelques mois, isoler le module derrière une fonction de secours, ou simplement documenter précisément ce qu’il fait pour que la décision puisse être prise sereinement plus tard.
Pages liées
-
Les modules et extensions abandonnés
Le même sujet vu sous l’angle du risque de piratage.
-
Module officiel, module tiers ou développement
Comment éviter de se retrouver dans cette situation la prochaine fois.
-
Versions de PHP en fin de vie
L’échéance qui déclenche le plus souvent la panne d’un module abandonné.
-
Audit du parc de modules
Pour savoir combien de modules sont dans ce cas avant qu’un seul ne casse.
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.