La mise à jour que vous
repoussez depuis deux ans.
Personne ne repousse une mise à jour par négligence. On la repousse parce que la dernière a cassé le tunnel d'achat un vendredi soir, et que plus le temps passe, plus l'écart à combler grandit. Au bout de deux ans, ce n'est plus une mise à jour : c'est une migration. Ce qui décide du coût, ce n'est pas votre nombre de produits — c'est le nombre de surcharges et de modules abandonnés par leur auteur.
Il faut distinguer deux choses qu'on appelle du même nom. La mise à jour courante, d'abord : un correctif de sécurité, une version mineure. Elle se joue en une heure sur une boutique saine, et le seul vrai risque est de la passer directement en production sans l'avoir rejouée ailleurs.
Lire la suite
La montée de version majeure ensuite — 1.6 ou 1.7 vers la 8 — qui est un chantier de plusieurs semaines et n'a rien à voir. Ce qui coûte, dans une montée majeure, ce sont les couches accumulées. Chaque surcharge posée dans override/ doit être relue, parce que le cœur qu'elle modifiait a changé.
Chaque modification faite dans le thème parent au lieu d'un thème enfant est perdue et doit être refaite proprement. Et chaque module tiers doit être vérifié : compatible, à racheter dans une version récente, ou abandonné par son auteur — auquel cas il faut décider entre le remplacer, le reprendre, ou s'en passer. C'est cet inventaire, pas le catalogue, qui donne la durée.
La méthode ne varie pas. On monte une copie complète de la boutique sur un environnement séparé, on y joue la montée, on recense tout ce qui casse, on corrige, et on recommence jusqu'à ce que le parcours d'achat passe de bout en bout — y compris les cas particuliers de taxe, de livraison et de code promo, qui sont précisément ceux que personne ne pense à tester. Puis on rejoue le tout une dernière fois avec les données de la veille, et on bascule. La boutique en production n'est jamais le terrain d'essai, et la sauvegarde est restaurée pour de vrai avant qu'on touche à quoi que ce soit.
Ce que vous obtenez.
Comment on procède.
Inventaire
Surcharges, thème, modules et leur état de maintenance. C'est ce relevé qui chiffre le chantier, et il est déductible s'il est mené dans le cadre d'un audit.
Environnement de recette
Copie complète de la boutique — fichiers, base, médias — sur un domaine séparé, non indexable, où l'on peut casser sans conséquence.
Montée et corrections
On joue la montée, on recense ce qui casse, on corrige, on recommence. Les modules abandonnés sont remplacés ou repris, décision par décision avec vous.
Recette du parcours d'achat
Commande testée de bout en bout sur les cas réels de votre boutique : taxes, transporteurs, codes promo, comptes clients, emails transactionnels.
Bascule
Import différentiel de la veille, bascule, vérification d'un paiement réel. L'ancienne version reste accessible en secours.
Surveillance
Suivi des erreurs, des commandes et de l'indexation. Les correctifs de cette période sont compris.
Quelques exemples.
1.6 vers 8, 4 200 références
Boutique bloquée depuis quatre ans sur une 1.6 et un PHP 7.0. 23 surcharges relues, 9 modules remplacés, 2 repris. Sept semaines, aucune coupure, URL inchangées.
Thème parent modifié
Toutes les personnalisations avaient été faites dans le thème parent, donc perdues à chaque tentative de mise à jour depuis trois ans. Refaites en thème enfant : la montée suivante a pris deux jours.
Questions fréquentes
Pages liées.
Prêt pour votre projet ?
Devis gratuit sous 48h. Réponse sous 24h. Aucun engagement.
Certification délivrée par l'éditeur du CMS