Quand une mise à jour casse un module ou écrase vos modifications

Ce qu’une mise à jour de module fait réellement

Mettre à jour un module ne se limite pas à remplacer des fichiers. Sur PrestaShop comme sur WordPress, un module bien écrit exécute au passage une procédure de mise à niveau : elle peut ajouter des colonnes en base, renommer des clés de configuration, migrer d’anciens réglages vers un nouveau format, ou se raccrocher à d’autres points d’affichage.

Trois choses peuvent mal se passer. La procédure s’interrompt à mi-parcours, et la base se retrouve dans un état intermédiaire que le module ne sait pas relire. Les anciens réglages ne sont pas repris, et le module redémarre avec ses valeurs par défaut, ce qui donne l’impression qu’il ne fait plus rien. Ou la nouvelle version exige une version de PHP ou de la plateforme supérieure à la vôtre, et échoue silencieusement au chargement.

Le cas le plus déroutant est celui où le module semble fonctionner, mais où une partie seulement de ses réglages a survécu. Vous cherchez un bug là où il n’y a qu’une configuration perdue.

Le cas particulier des modules de paiement et de transport

Ces modules-là méritent une attention distincte, parce que leur panne ne se voit pas sur la page d’accueil mais à la dernière étape du tunnel, c’est-à-dire au moment où vous perdez la vente. Une nouvelle version majeure change fréquemment la façon dont le module reçoit les retours du prestataire, et ces retours arrivent sur une adresse enregistrée chez le prestataire, pas dans votre boutique. Si la mise à jour change cette adresse, il faut la mettre à jour des deux côtés.

Après toute mise à jour d’un module de paiement, je passe une commande réelle de bout en bout, en conditions de production, et je vérifie que la commande est bien créée avec le bon statut. C’est le seul test qui prouve quelque chose.

L’autre issue : la mise à jour qui écrase vos modifications

Le symptôme inverse existe et se confond souvent avec le précédent : le module n’est pas cassé, il est simplement redevenu ce qu’il était. Une mise à jour remplace les fichiers du module par ceux de la nouvelle version. Elle ne compare pas, elle ne fusionne pas, elle écrase. Tout ce qui a été écrit à l’intérieur du dossier du module disparaît, sans avertissement et sans trace. La signature est reconnaissable : une fonction sur mesure qui disparaît deux fois par an, toujours après une opération de maintenance, et que personne ne relie à la mise à jour parce que l’intervalle est long.

Le second effet est plus vicieux : tant que la modification tient, elle bloque de fait les mises à jour. Comme personne ne veut la reperdre, le module reste sur une vieille version, accumule les incompatibilités et finit par produire exactement la panne décrite plus haut, en pire, le jour où la mise à jour devient inévitable.

Quand le module ne déclare aucun point d’extension et construit son affichage sans gabarit surchargeable, il n’y a pas de solution élégante, et je préfère l’annoncer plutôt que de laisser croire l’inverse. Restent trois options, dans cet ordre de préférence : demander l’ajout d’un point d’extension à l’éditeur du module, c’est gratuit et parfois accepté ; dupliquer le module sous un autre nom et l’assumer comme un module à vous, en sachant que vous renoncez à ses mises à jour et en devenez le mainteneur ; ou conserver la modification à part sous forme de correctif documenté, à réappliquer après chaque mise à jour. Ce que je ne fais pas : modifier un module et ne rien dire. Une modification non documentée dans un code que quelqu’un mettra à jour dans six mois est un piège pour la personne suivante, y compris quand cette personne, c’est moi.