Une boutique PrestaShop 1.7.8.11, plusieurs années d’exploitation, un dump de production de 1,17 Go. Cible : 9.1.5 sous PHP 8.3. J’ai mené cette montée de version en m’appuyant sur un agent IA de développement, et la conclusion que j’en tire n’est pas celle que j’attendais.
L’agent n’a pas fait la migration à ma place. Il a fait autre chose, de plus intéressant : il a rendu rentable l’outillage d’une opération qu’on ne réalise qu’une fois. Personne n’écrit un pipeline rejouable pour une migration unique. On lance l’assistant, on croise les doigts, et en cas d’échec on recommence depuis le début, une journée à chaque fois. Avec un agent, construire ce pipeline coûte deux jours, et chaque nouvel essai retombe à dix-neuf minutes.
Le corollaire compte autant que la thèse : l’agent affirme des choses fausses avec aplomb. L’essentiel du dispositif décrit plus bas ne sert qu’à ça, attraper ses erreurs avant qu’elles ne coûtent cher.
L’opération, en clair
Le point de départ est un dump SQL de la base de production, 1,17 Go, contenant environ 11 000 clients, 10 000 commandes, 13 000 adresses et 200 produits. Les fichiers de la boutique ne sont pas récupérés de l’existant : ils sont reconstruits depuis les archives officielles PrestaShop, ce qui élimine d’emblée toute une classe de surprises.
Tout se déroule en local, dans deux conteneurs Docker, un service web et une base. Le dump source est monté en lecture seule et son empreinte est vérifiée à chaque exécution.
Il n’y a pas de saut direct de 1.7.8.11 vers 9.1.5. La chaîne passe par un palier intermédiaire en 8.2.8, et chaque palier s’exécute avec sa propre version de PHP : 7.4 pour le premier, 8.1 pour le second, 8.3 une fois la cible atteinte. Ce détail a coûté cher, j’y reviens. Le livrable est une base au schéma 9.1.5, vérifiée, exportée en archive gzippée, accompagnée d’une checklist de mise en préproduction.
Le dispositif à mettre en place
Le harnais final compte huit étapes (preflight, restore, prepare, files, boot, upgrade, verify, export), 29 scripts shell pour environ 2 300 lignes, et une dizaine de fichiers de tests portant 84 assertions. Mais ce n’est pas le code qui fait la différence, c’est ce qui l’encadre.
Trois choses à poser avant d’écrire la première ligne
- Un dépôt git dédié à l’intervention, séparé du code de la boutique. On y versionne le harnais, la conception, le plan, les décisions prises. Jamais les données.
- Un fichier d’instructions projet, relu par l’agent à chaque session, qui ne contient que ce qui est actionnable et non évident : les pièges déjà rencontrés, les interdits, les commandes. Il grossit à chaque erreur trouvée. C’est le seul mécanisme qui empêche de payer deux fois la même erreur.
- La source en lecture seule, techniquement et pas par consigne. Le dump est monté
:rodans Docker et son empreinte est contrôlée avant et après. Une contrainte technique vaut mieux qu’une bonne intention.
Trois choses qui rendent l’itération supportable
- Des points de reprise à chaque palier, et une commande pour y revenir. Revenir à un point de reprise prend quelques secondes ; recharger le dump en prend quatre minutes. C’est cet écart qui transforme un échec en itération plutôt qu’en soirée perdue.
- Une suite de tests sur fixture réduite, sans aucune donnée réelle, et strictement isolée de l’état du pipeline : base de test distincte, répertoires de sortie distincts. Vérifiez aussi que chaque test échoue bien quand vous retirez ce qu’il teste.
- Un contrôle final indépendant du processus. Le mien installe une 9.1.5 vierge dans une base jetable, compare les deux schémas, et bloque l’export s’il manque une table du cœur. Ne vous contentez jamais de ce que le processus affirme de lui-même.
Trois règles de conduite
- Des écarts tolérés déclarés dans un fichier dédié, chacun avec sa justification et son seuil. La règle que je m’impose : un seuil se relève quand la preuve est refaite, jamais quand le rapport gêne.
- Un travail par lots validés : un lot, un commit, un critère de démonstration, puis arrêt et validation humaine. Laisser un agent enchaîner dix heures sans point de contrôle, c’est découvrir la dérive à la fin.
- Exiger la source. Quand l’agent affirme une contrainte technique, demandez le fichier et la ligne. Une réponse tirée d’une documentation en ligne vaut moins qu’une lecture du code installé.
Combien de temps ça prend réellement
| Étape | Durée |
|---|---|
| Contrôles préalables | ~10 s |
| Chargement du dump | ~4 min |
| Préparation de la base | ~10 s |
| Déballage des fichiers | ~1 min |
| Démarrage | ~5 s |
| Chaîne de mise à jour (2 paliers) | ~12 min |
| Vérification | ~1 min 30 |
| Export | ~5 s |
| Total bout en bout | ~19 min |
Dix-neuf minutes. Le poste dominant est la chaîne de mise à jour elle-même, douze minutes pour les deux paliers, sur lesquelles l’outillage n’a aucune prise.
La construction du harnais, elle, a demandé une demi-journée de conception et de plan, puis six lots de travail successifs étalés sur deux jours ouvrés, puis une demi-journée de correctifs et de remise à niveau de la documentation. Environ deux jours et demi calendaires, une quinzaine d’heures de travail effectif. Ces chiffres sont reconstitués depuis l’historique des commits : prenez-les comme un ordre de grandeur, pas comme un relevé.
Le calcul bascule au deuxième essai. Et il y a toujours un deuxième essai.
Ce que l’agent apporte
Il lit le code source, pas la documentation. Trois blocages ont été levés en allant chercher la réponse dans le code de PrestaShop lui-même : une constante interne qui plafonne la version de PHP acceptée, une méthode qui renomme un dossier pendant la mise à jour, un validateur qui exige un fichier de contrôle. Aucune de ces trois réponses n’était dans la documentation en ligne, et l’une d’elles la contredisait. C’est un travail de lecture que l’humain fait lentement et à contrecœur.
La vérification devient systématique parce qu’elle est gratuite à écrire. Comparer le schéma obtenu à celui d’une installation neuve, c’est ce qui distingue une vraie migration d’une base 1.7 dont on aurait seulement changé le numéro de version. Personne n’écrit ce contrôle à la main pour une opération unique. À côté, les compteurs métier encadrent l’ensemble : clients, commandes, adresses et produits relevés avant, contrôlés après, identiques de bout en bout. C’est la seule preuve qui parle au propriétaire de la boutique.
Deux effets secondaires que je n’attendais pas : la documentation naît avec le code au lieu d’arriver trois semaines plus tard, et les points de reprise donnent un vrai droit à l’erreur, puisqu’une chaîne qui casse au second palier se rejoue depuis le premier et non depuis le dump.
Ce qu’il affirme faux, et ce que ça coûte
Deux prémisses fausses figuraient dans le document de conception initial, toutes deux énoncées avec assurance, toutes deux corrigées seulement après avoir bloqué la chaîne.
La première : « PHP 8.1 pour toute la chaîne ». Faux. La version 1.7.8.11 plafonne à PHP 7.4, dans son propre code. Sous 8.1, le premier palier meurt après avoir téléchargé les modules. Il a fallu apparier une version de PHP à chaque palier.
La seconde : « les conteneurs n’ont pas besoin de sortie réseau, les archives sont locales ». Faux, et ça ne pouvait pas être vrai : l’assistant de mise à jour télécharge les modules depuis la marketplace, 45 modules récupérés ainsi pendant le premier palier seulement. La formule qui résume le vrai garde-fou tient en une ligne : la base ne sort pas, mais du code entre.
Trois des quatre blocages du projet venaient de suppositions non vérifiées : une version de PHP lue dans une documentation plutôt que dans le code, un nom de dossier jamais interrogé, la sémantique d’une option déduite de son nom. Le schéma se répète : l’agent est excellent pour vérifier quand on le lui demande, et spontanément confiant quand on ne le lui demande pas.
Deux autres défauts, plus insidieux. Des tests restaient verts sans leur implémentation : plusieurs assertions passaient même en supprimant le code testé, et un test qui ne peut pas échouer ne garde rien. Et les pièges d’environnement se répètent : trois fois, un test a écrasé l’état du pipeline, point de reprise remplacé par une fixture de 2 Ko, compteurs faussés, livrable effacé. Défauts silencieux, visibles seulement au moment de s’en servir. C’est l’humain qui a dû imposer la règle d’isolation, puis la réimposer.
Deux heures perdues méritent d’être racontées, parce qu’elles sont typiques. Un dossier d’administration ne pouvait pas s’appeler admin : l’assistant renomme le dossier de l’archive vers celui de la boutique, et rename(admin, admin) échoue. Une heure sur un nom de dossier. Ailleurs, un back-office renvoyait une erreur 500 juste après une connexion pourtant réussie, symptôme qui envoie chercher du côté de l’authentification alors que la cause était deux colonnes de dates laissées vides sur le compte administrateur.
Restent les arbitrages que l’agent propose et que l’humain doit trancher. Le manifeste de contrôle exigé par l’assistant, l’éditeur le publie pour les anciennes branches mais plus pour la nouvelle. Il a fallu le reconstruire depuis l’archive, et assumer ce qu’on y perd : vérifier une archive contre elle-même est tautologique, la garantie repose alors entièrement sur sa provenance. L’agent a proposé la solution ; il ne pouvait pas décider si le compromis était acceptable.
Ce que l’outillage ne couvre pas, et ne couvrira pas
L’assistant de mise à jour met à jour le schéma du cœur, jamais celui des modules. Des modules actifs peuvent donc tourner avec des tables restées à l’ère 1.7, et le tunnel de paiement est le premier concerné. Un test de commande de bout en bout, à la main, reste obligatoire. S’y ajoutent l’installation du thème et des modules compatibles avec la nouvelle version, et la remise en service du domaine réel.
Il reste aussi un coût qui ne se compresse pas : tout le SQL appliqué à la base a été relu et validé avant exécution. C’est du temps humain, et c’est le temps qui compte le plus dans cette affaire.
Ce que j’en retiens
N’achetez pas l’idée que l’agent fait la migration. Il ne la fait pas. Il vous donne les moyens de la rater proprement, plusieurs fois, jusqu’à ce qu’elle passe, et c’est exactement ce dont on a besoin sur une opération qui n’aura pas droit à l’échec en production. Ce n’est pas un petit progrès.
Mais le dispositif n’est pas un supplément de rigueur qu’on ajouterait par prudence : c’est la contrepartie exacte du gain. Retirez les points de reprise, l’isolation des tests, le contrôle indépendant et l’exigence de la source, et il ne reste qu’un collaborateur rapide, infatigable, et sûr de lui à tort. Le jour où vous cesserez de lui demander ses sources, il vous fera perdre plus de temps qu’il ne vous en aura fait gagner.