Ce qui devait être sur mesure, et pourquoi.
Le catalogue d'un opérateur de retraites bien-être n'entre pas dans les défauts de l'e-commerce. Une retraite n'est pas un produit — c'est un lot daté qui combine hébergement, repas et enseignement en une seule unité achetable. L'instructeur principal n'est pas l'auteur d'un produit ; c'est la raison pour laquelle un client réserve. Le vocabulaire sanskrit et les modules de philosophie de la marque ne sont pas un blog ; c'est une couche de contenu qui jouxte la vitrine et donne son contexte à la décision d'achat.
Nous avons bâti la plateforme sur PrestaShop 1.7.4 fin 2018, avec quatre modules spécifiques au domaine et un thème par défaut fortement personnalisé. Le module de lots-retraites modélisait des offres multi-dates et multi-composants avec sélection de dates et configuration des composants — rien dans l'écosystème PrestaShop ne s'en approchait. Le module d'apprentissage du sanskrit avait ses propres tables en base, ses routes front et son panneau d'administration : une surface de vocabulaire et de philosophie que l'opérateur pouvait modifier indépendamment du catalogue. Un module de revendeurs suivait les agences partenaires B2B avec des fiches de contact, de pays et de devise.
Le flux de paiement a été surchargé — 67 surcharges de classes et de contrôleurs au pic — parce que les achats de retraites ont des règles de validation différentes de celles des paniers de biens physiques. On ne peut pas acheter deux places pour une retraite sans choisir de dates. On ne peut pas laisser un champ de composant vide et passer au paiement.
De petites choses qui ont gardé la plateforme en vie.
Les années deux à six n'ont pas été spectaculaires. Changements de prestataire de paiement. Ajustements RGPD. Ajouts de transporteurs. Mises à niveau du runtime PHP intégrées tout au long de la mission. De temps à autre, de nouveaux textes, de nouveaux formats de retraite, de nouveaux partenaires B2B intégrés via le module de revendeurs. Le genre de maintenance qui ne fait pas une page projet mais qui est le vrai contenu d'une mission de sept ans.
La plupart des plateformes sur mesure ne survivent pas à cette phase. L'équipe qui les a construites est passée à autre chose. Les modules ne sont pas documentés. Les surcharges de classes sont du code mystère. Chaque montée de dépendance est un coup de dés.
La plateforme a survécu parce que ce sont les mêmes personnes qui s'en sont occupées. Quand un changement de prestataire de paiement a exigé de modifier la surcharge du paiement, c'est l'ingénieur qui avait écrit la surcharge qui a fait la modification. Quand une mise à niveau du runtime PHP a cassé deux constructeurs de modules, nous savions quels constructeurs vérifier. La connaissance institutionnelle d'une base de code a une valeur cumulative qui n'apparaît que lorsque quelque chose casse — et quelque chose finit toujours par casser.
- F · 01Type de produit lot-retraite
- Lots datés multi-composants (hébergement, repas, enseignement) modélisés dans un module PrestaShop sur mesure. Aucun équivalent prêt à l'emploi.
- F · 02Couche de contenu d'apprentissage du sanskrit
- Distincte de la vitrine et du blog : ses propres tables en base, ses routes front et son panneau d'administration pour le contenu de vocabulaire et de philosophie.
- F · 03Couche de revendeurs B2B
- Suivi des agences partenaires avec fiches de contact, de pays et de devise. Réservations acheminées via le module de revendeurs sans toucher au flux de la vitrine publique.
- F · 04Flux de paiement personnalisé
- 67 surcharges de classes et de contrôleurs au pic, modélisant des règles de validation propres aux retraites — sélection de dates, configuration des composants — que le paiement par défaut n'impose pas.
- F · 05Maintenance continue
- Sept ans de changements de prestataire de paiement, d'ajustements RGPD, de mises à jour d'expédition et de mises à niveau du runtime PHP — tous pris en charge par l'équipe qui a écrit les modules d'origine.
- F · 06Migration de version majeure en cours
- PrestaShop 1.7.4 → 1.7.8.11 achevée en production ; 1.7.8.11 → 8.2.3 en staging avancé. Chaque surcharge re-testée, chaque module doté d'une passe de compatibilité PHP 8.x. La migration est le travail qui justifie la gestion dans la durée.
La migration en cours.
La fin de vie de PrestaShop 1.7 a imposé un choix en 2025 : changer de plateforme, ou migrer. Changer de plateforme, c'est jeter sept ans de travail sur des modules spécifiques au domaine et tout recommencer sur une nouvelle stack. Nous avons plaidé pour la migration. L'opérateur a accepté.
La migration se déroule en deux étapes. La première — PrestaShop 1.7.4 → 1.7.8.11 — a été livrée plus tôt et est en production. La seconde — 1.7.8.11 → 8.2.3 — est le saut le plus difficile : PrestaShop 8 a basculé davantage de vues vers Twig et a suffisamment changé le système de surcharges pour que les 67 surcharges de classes et de contrôleurs doivent toutes être re-testées ou réusinées. Chaque module sur mesure nécessite une passe de compatibilité PHP 8.x.
Le seul mois d'octobre 2025 a produit 245 commits sur la branche de migration 8.2.3. Le travail se déroule dans un environnement de staging branché, avec des données de production miroir. Chaque flux de paiement, chaque configuration de lot-retraite, chaque route de contenu sanskrit est testée face à la nouvelle version avant l'ouverture de la fenêtre de bascule. La migration est méthodique et lente parce que la piste d'audit qu'elle laisse compte autant que le code mis à niveau.
La raison pour laquelle la migration est possible — et reste dans le budget — c'est que l'équipe qui la mène a écrit les modules d'origine. Nous n'avons pas découvert la complexité ; nous la possédions déjà.
L'argument pour garder la même équipe lors de la montée de version.
Sept ans. Une seule équipe tout du long. Une migration de version majeure actuellement en staging avancé.
La plateforme en production aujourd'hui tourne sur PrestaShop 1.7.8.11 avec le module de lots-retraites, la surface d'apprentissage du sanskrit, la couche de revendeurs B2B et le flux de paiement personnalisé intacts. La branche 8.2.3 est l'étape suivante — la migration qui résiste à être traitée comme un sprint d'une semaine, et la partie que personne ne planifie au début d'une mission sur plateforme sur mesure.
La valeur d'une longue mission sur une plateforme sur mesure n'est pas le build initial. N'importe qui peut construire la première version. La valeur, c'est le contexte accumulé : savoir quelle surcharge est porteuse, quelle hypothèse d'un module volera en éclats sous une nouvelle version du framework, de quelle classe PHP l'étape de paiement dépend d'une manière que la documentation ne mentionne pas. Ce contexte ne se transmet pas à une nouvelle équipe via un brief de migration. Il vit dans les personnes qui ont écrit le code. La migration aujourd'hui en staging est possible — et survivable — parce que la même équipe possède le code d'origine.
Ils ont écrit les modules. C'était la bonne équipe pour les migrer.