# 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.

- Source canonique : [https://allaux.fr/modules/module-dont-l-editeur-a-disparu](https://allaux.fr/modules/module-dont-l-editeur-a-disparu)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Vérifiez d’abord si la fonction est encore utilisée : un module installé pour une opération terminée se retire, il ne se remplace pas. Sinon, ouvrez son config.xml pour lire la plage de compatibilité déclarée, et regardez si le fichier PHP principal est lisible ou encodé par ionCube. Ces deux points décident entre reprise du code, réécriture et remplacement.

## 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

1. **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.
2. **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.
3. **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.
4. **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.

## Le point qui décide de tout : le code est-il lisible

> Un module livré sous forme encodée ne peut être ni repris ni corrigé, par personne. Si son éditeur a disparu, la seule voie est le remplacement ou la réécriture. C’est une vérification à faire tout de suite, parce qu’elle élimine deux des quatre options avant même de discuter de budget.

## 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. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))
- **Module officiel, module tiers ou développement** — Comment éviter de se retrouver dans cette situation la prochaine fois. ([/modules/module-officiel-tiers-ou-developpement](/modules/module-officiel-tiers-ou-developpement))
- **Versions de PHP en fin de vie** — L’échéance qui déclenche le plus souvent la panne d’un module abandonné. ([/securite/versions-de-php-en-fin-de-vie](/securite/versions-de-php-en-fin-de-vie))
- **Audit du parc de modules** — Pour savoir combien de modules sont dans ce cas avant qu’un seul ne casse. ([/modules/audit-du-parc-de-modules](/modules/audit-du-parc-de-modules))

## FAQ

### Le module marche encore, dois-je vraiment agir maintenant ?

Pas dans l’urgence, mais avant la prochaine montée de version de PHP ou de la plateforme. Agir à froid coûte moins cher qu’agir le jour où la boutique ne prend plus de commandes.

### Puis-je continuer à utiliser un module dont l’éditeur a fermé ?

Techniquement oui, tant qu’il fonctionne. Ce qu’il faut savoir, c’est qu’aucun correctif de sécurité ne viendra, et que personne ne pourra le rendre compatible avec une version future si son code n’est pas lisible.

### Comment récupérer les données d’un module avant de le retirer ?

En identifiant les tables qu’il a créées et en les exportant avant toute désinstallation. La désinstallation d’un module bien écrit supprime justement ces tables : l’export se fait avant, jamais après.

### Un module abandonné peut-il être repris par un autre développeur ?

Oui si le code est lisible et si la licence l’autorise. C’est un travail de reprise classique : lecture, remise à niveau pour la version courante de la plateforme, puis maintenance. Sur du code encodé, ce n’est pas possible.