Migrer vers Prestashop 9 : retours de terrain

Une migration de boutique n’est pas un projet technique, c’est un projet de risque. La question n’est jamais « est-ce que ça va marcher ? » mais « qu’est-ce qui va casser, et est-ce que je le saurai avant le client ? ». Voici l’ordre dans lequel j’aborde une montée de version majeure, et ce que le terrain m’a appris.

Commencer par jeter, pas par migrer

Le premier réflexe est de vouloir tout emmener. C’est l’erreur qui coûte le plus cher. Une boutique de quelques années accumule des modules installés pour un besoin ponctuel, désactivés puis oubliés, des surcharges écrites pour contourner un bug corrigé depuis, des champs de base de données que plus rien ne lit.

Avant toute chose, je fais l’inventaire :

• quels modules sont réellement actifs et utilisés — pas seulement installés ;
• lesquels ont une version compatible avec la cible, et lesquels sont abandonnés ;
• quelles surcharges existent, et si leur raison d’être est toujours valable.

Chaque module qu’on ne migre pas, c’est un risque en moins et une dette en moins. C’est le seul moment du projet où supprimer est facile à justifier auprès du client : après la mise en ligne, plus personne ne voudra y toucher.

Ce qui casse, à peu près toujours

Les modules tiers. C’est de très loin le premier poste de problèmes. Un module non maintenu ne devient pas subitement compatible : il faut soit une version à jour, soit un remplaçant, soit reprendre le code. Décider lequel des trois, module par module, est le vrai travail de la migration.

Les surcharges et les templates. Tout ce qui a été écrit contre l’ancien thème est à reprendre. Plus la personnalisation était profonde, plus la note est salée — c’est le prix rétrospectif des raccourcis pris à l’époque.

Les hooks disparus ou renommés. Un affichage qui ne s’affiche plus, sans erreur ni log, c’est presque toujours ça. Ces bugs-là sont silencieux : ils ne cassent pas la page, ils enlèvent un bloc. D’où l’importance de comparer visuellement, écran par écran, et pas seulement de vérifier que le site répond en 200.

Ce qui se passe mieux qu’on ne le craint

La montée de version du cœur elle-même, curieusement. Le script de mise à jour fait son travail correctement dans la grande majorité des cas. Les données de commande, les clients, l’historique : ça passe. L’angoisse se porte souvent sur la base, alors que le danger est ailleurs, dans le code qu’on a ajouté autour.

Le passage à un thème moderne se passe bien aussi, à condition de le reprendre plutôt que de le tordre. Repartir du thème officiel et réintégrer proprement les spécificités donne un meilleur résultat, plus rapidement, que de vouloir porter l’ancien thème coûte que coûte.

L’ordre que je recommande

1. Audit. Inventaire des modules, des surcharges, des points de rupture. Rien n’est migré à cette étape, tout est décidé.
2. Environnement. Une préproduction identique à la production, base anonymisée. Sans ça, on ne recette rien — on espère.
3. Migration à blanc. Une première fois, en jetant le résultat. Elle sert uniquement à mesurer ce qui casse et combien de temps ça prend.
4. Reprise du thème et des développements. Le gros du travail, désormais cadré par ce qu’on a appris à l’étape précédente.
5. Recette. Par les parcours, pas par les pages : commander, payer, se connecter, retourner un produit.
6. Bascule. À une heure creuse, avec un retour arrière préparé et testé.
7. Les jours suivants. Une migration n’est pas finie le jour de la mise en ligne. Les cas rares remontent dans la semaine.

La seule règle non négociable

Un retour arrière testé. Pas « une sauvegarde existe » : un retour arrière que vous avez déjà exécuté au moins une fois, chronomètre en main, sur la préproduction. Le jour où vous en aurez besoin, vous ne serez pas en état de l’improviser.

C’est le genre de précaution qui ne sert presque jamais. C’est précisément pour ça qu’elle vaut le coup.