PrestaShop 8 ou 9 : vers quelle version migrer en 2026 ?

Vous voulez migrer votre PrestaShop, et depuis deux semaines vous lisez des comparatifs. Tous vous alignent le même tableau 8 contre 9, tous concluent par un « ça dépend » qui ne vous avance à rien. On va faire l’inverse.

Je vais être direct, parce que sur cette question la plupart des agences vous conseillent de jouer petit bras : « passez d’abord en 8, vous verrez pour la 9 plus tard ». Nous, non. Notre métier, c’est de vous emmener aussi loin que votre boutique le permet, et c’est presque toujours plus loin qu’on vous l’a dit.

Parce que le vrai sujet, ce n’est pas « 8 ou 9 ». Ce sont deux questions que personne ne pose clairement : est-ce que votre parc de modules est prêt, et combien de migrations vous êtes prêt à payer. Répondez à ces deux-là, et la version se choisit toute seule. Et puisqu’on va parler d’argent, autant le faire franchement, avec des chiffres que vous ne trouverez nulle part ailleurs : ce qu’une montée de version coûte vraiment, et surtout ce que vous ne payez pas.

Un mot pour poser l’enjeu. Si vous êtes encore en 1.7, cette branche ne reçoit plus le moindre correctif de sécurité depuis fin 2024. Sa dernière version, la 1.7.8.11, date de mars 2024. Depuis, plus rien. Chaque mois, vous tournez sur un socle que plus personne ne répare. Ce n’est pas un détail, c’est le point de départ.

Dans cet article, je ne vais pas vous noyer. On répond aux deux vraies questions, chiffres à l’appui, on parle prix sans langue de bois, et à la fin vous saurez exactement vers quelle version aller dans VOTRE cas. Pas « ça dépend ». Une réponse.

8 ou 9, la comparaison que tout le monde vous montre (et pourquoi elle ne décide rien)

Commençons par ce que vous êtes venu chercher, parce que ce serait malhonnête de l’esquiver. Voici le comparatif entre les deux versions stables du moment, la 8.2 et la 9.1.

Critère	PrestaShop 8.2	PrestaShop 9.1
Socle technique	Symfony 4.4	Symfony 6.4 LTS
PHP	7.4 à 8.1	8.2 à 8.5
Thème par défaut	Classic	Hummingbird 2.0
Interface d’administration	historique	refondue, nouvelle API (OAuth)
Performance	référence	+20 à 30 %
Écosystème de modules	complet, éprouvé	en croissance
Support sécurité	jusqu’à début 2027 au moins	version stable courante

Voilà. Vous l’avez, ce tableau. Maintenant, regardez-le bien, parce qu’il a un défaut fatal : il compare des fonctionnalités, pas votre situation. Il vous dit ce que la 9 fait de mieux, il ne vous dit pas si VOUS pouvez y aller. Et c’est ça, la seule chose qui compte.

Et d’ailleurs, oubliez le conseil « visez la 9.0 »

Petite mise au point au passage, parce que je vois encore ce conseil partout. Début 2026, tout le monde répétait : « allez en 9.0, mais évitez la 9.1, il n’y a pas assez de modules ». C’était vrai il y a six mois. Ça ne l’est plus. La 9.1 est devenue la version stable par défaut, celle que PrestaShop installe et fait vivre. La 9.0, elle, est devenue une simple marche que l’on quitte.

Autrement dit, viser la 9.0 aujourd’hui, c’est vous condamner à une mini-migration 9.0 vers 9.1 quelques mois plus tard. Pour rien. La vraie question de 2026, ce n’est pas 9.0 contre 9.1. C’est 8.2 contre 9.1. Et pour y répondre, deux questions suffisent. On y va.

Un dernier élément de contexte, parce qu’il devrait peser dans votre décision. PrestaShop vient d’inverser quatre années de déclin : la plateforme compte de nouveau environ 165 000 boutiques actives en 2026. Ce rebond, elle le doit largement à la 9, qui a réglé la dette technique qui faisait fuir les marchands, et aux hausses de prix de Shopify qui ramènent des e-commerçants européens vers l’open source. Migrer vers la 9, ce n’est donc pas rattraper un retard. C’est vous aligner sur l’élan actuel de la plateforme, celle qui pèse déjà près de 19 % de son parc mondial en France. Vous n’allez pas vers le passé, vous allez vers là où ça bouge.

Votre parc de modules est-il prêt ?

Si une migration vers la 9 déraille, c’est presque toujours à cause d’un module. Ce n’est pas une impression, c’est un chiffre : en 2026, environ 60 % des problèmes constatés après une migration vers PrestaShop 9 sont des incompatibilités de modules. Votre thème, votre serveur, vos données, tout ça se gère. Le point qui casse, c’est le parc de modules. On commence donc par lui.

Pourquoi certains modules cassent et d’autres non

La 9 a modernisé le cœur de PrestaShop en profondeur, et cette modernisation a un prix : tout ce qui s’accrochait à l’ancienne mécanique doit être adapté. Quatre choses ont changé et cassent des modules : le passage à Symfony 6.4 (les contrôleurs d’administration ont été réécrits), l’exigence de PHP 8.2 minimum (le vieux code PHP 7 déclenche des erreurs), le passage de Smarty à Twig dans le back-office, et la suppression de certains anciens points d’accroche.

Traduit en clair : tous vos modules ne courent pas le même risque. Voici comment je les classe.

Un module d’affichage tout simple sur votre page d’accueil passera sans broncher. Votre module de paiement, celui qui touche à l’administration et à une API sécurisée, c’est le premier suspect. Vous voyez déjà où votre boutique se situe.

Comment savoir, concrètement, si un module donné passera ? Trois réflexes. Sur la marketplace officielle, la fiche du module indique les versions compatibles : cherchez la mention « PrestaShop 9 ». Si le module vient d’un éditeur, écrivez-lui et demandez sa feuille de route pour la 9, une réponse floue est déjà une réponse. Et pour un module sur mesure, seul un développeur tranche en regardant le code : surcharge-t-il un contrôleur d’administration, utilise-t-il du vieux PHP 7, s’accroche-t-il à un point d’accroche supprimé ? Ces trois vérifications suffisent à classer la grande majorité de votre parc.

Et si un module ne suit pas ? Ce n’est pas la fin du monde, c’est une décision. Soit il existe une alternative compatible, et on bascule dessus. Soit le module est stratégique et sans équivalent, et il faut le faire adapter, ce qui a un coût et un délai qu’il vaut mieux connaître avant la migration plutôt que découvrir en plein chantier. C’est tout l’intérêt de noter son parc en amont : on ne se lance jamais à l’aveugle.

Le score de compatibilité de votre parc, notre méthode

Tout le monde vous dit « auditez vos modules ». Personne ne vous dit comment. Voici la méthode qu’on applique chez nous, ramenée à un score sur 100 que vous pouvez estimer vous-même. Pour chaque module actif, quatre questions :

1. Est-il critique ? Bloquant (paiement, transport, sécurité, connecteur ERP : sans lui, vous ne vendez plus), important (marketing, SEO, relation client : ça dégrade sans casser), ou cosmétique (affichage, remplaçable en cinq minutes) ?
2. Quel est son risque technique ? Voir le tableau ci-dessus.
3. Existe-t-il une version compatible PrestaShop 9 ?
4. Sinon, existe-t-il une alternative crédible ?

Un module bloquant, à risque élevé, sans version 9 ni alternative, c’est un point noir majeur : il plombe le score. Un cosmétique remplaçable sans version 9, on s’en moque, on le change. Ce que votre score vous dit :

Une migration, ou deux ?

Voici l’angle que personne ne vous donne, et c’est peut-être le plus important de tout l’article. Quand vous choisissez votre version cible, vous ne choisissez pas seulement une version. Vous choisissez combien de chantiers vous allez payer.

Suivez le raisonnement. Vous êtes en 1.7. On vous conseille « prudemment » de passer en 8. D’accord. Mais dans deux ans, la 8 aura vieilli à son tour, et vous devrez migrer de 8 vers 9. Deux migrations. Deux périodes de test. Deux fois le risque. Deux fois la facture. À l’inverse, si votre parc le permet, on fait le trajet en une seule fois : de 1.7 jusqu’à la 9, dans un seul chantier, la 8.2 n’étant qu’une marche technique au milieu du parcours. Un test. Une bascule. Un risque.

Et méfiez-vous d’une idée reçue tenace : il n’existe aucun outil qui convertit automatiquement, et sans casse, une boutique 8 en boutique 9. Chaque migration se prépare, se teste et se vérifie à la main. C’est justement ce qui rend le doublon coûteux. Deux migrations, ce n’est pas seulement deux fois le travail technique, c’est deux fois la période de test complète, sur chaque parcours, chaque paiement, chaque transporteur. Ce temps de vérification, invisible sur un devis, est le vrai coût caché de la prudence par étapes.

Ce que ça donne sur trois ans

Scénario	Chantiers	Sur 3 ans	Risque
Rester en 1.7	0 planifié	0 € de projet, mais une migration forcée plus tard, et plus chère	Élevé (failles, blocage PHP)
Prudent : 8 maintenant, 9 dans 2 ans	2	Deux projets séparés, deux fois la facture	Deux tests, deux bascules
Direct : 1.7 vers 8.2 vers 9 en un chantier	1	Un seul projet	Un test, une bascule

L’enseignement saute aux yeux : si votre parc est prêt, le chantier unique jusqu’à la 9 coûte moins cher au total que deux migrations séparées. La prudence par défaut, celle qu’on vous conseille partout, vous fait payer deux fois. Ce n’est pas prudent, c’est cher. Les prix exacts, on les voit juste après.

Et pendant ce temps, l’attente vous coûte aussi

Il y a un coût qu’on oublie toujours : celui de ne rien faire. Rester sur une vieille version, ce n’est pas gratuit, c’est un coût différé, et il monte.

Si vous attendez	Prix du projet	Compétences disponibles	Coût d’un incident
Aujourd’hui	référence	correctes	migration planifiée, dès 490 €
Dans 12 mois	en hausse	en baisse	failles non corrigées qui s’accumulent
Dans 24 mois	nettement plus élevé	rares et chères	migration en catastrophe : 5 000 à 15 000 € plus les pertes

Le prix de votre migration augmente chaque mois où vous attendez : les modules abandonnés à remplacer se multiplient, les développeurs capables de travailler sur une vieille stack se raréfient et se paient plus cher. Et le pire scénario, c’est l’incident. Une boutique piratée sur une version non patchée, ça se répare entre 5 000 et 15 000 €, sans compter le chiffre d’affaires perdu pendant la panne. À comparer avec une migration planifiée qui, on va le voir tout de suite, démarre bien plus bas.

Ce qu’une migration coûte vraiment chez nous (et ce que vous ne payez pas)

Parlons argent, sans détour. Quand vous cherchez « prix migration PrestaShop », vous tombez sur des fourchettes qui donnent le vertige : 3 000 à 20 000 €. Et là, vous refermez l’onglet, vous vous dites que ce n’est pas le moment, et vous repartez pour un an sur votre vieille version.

Le problème, c’est que ce chiffre est trompeur. Il existe, mais il ne s’applique qu’à un seul cas : la reconstruction complète, ou la boutique tellement personnalisée qu’il faut tout reprendre. Pour tout le reste, la réalité est très différente. Voici nos prix, en clair.

Notre tarif de référence, pour être transparent : 630 € la journée, 360 € la demi-journée.

Ce qui fait grimper la facture au-delà de la mini-migration, ce n’est jamais la version en elle-même, c’est ce qu’il y a autour : l’audit du parc, le remplacement des modules bloquants, l’adaptation d’un thème très personnalisé, la reprise de développements sur mesure. Une migration projet, c’est ce travail-là, pas le simple fait de cliquer sur « mettre à jour ». Pour situer le marché : un freelance expérimenté facture 400 à 700 € la journée, une agence souvent le double, frais de structure compris. À 630 €, on se place au niveau du bon freelance, avec la coordination d’une agence en plus.

Ce que personne ne vous dit sur les montées de version

Regardez la deuxième ligne du tableau, parce que c’est là que se cache l’argument que je n’ai jamais lu ailleurs. Une montée de version majeure sur un parc propre, une 8 vers 9 par exemple, ce n’est pas un grand projet. C’est une demi-journée à une journée de travail, soit 360 à 630 €. Le catastrophisme du marché, les « 3 000 à 20 000 € », ne concerne que les reconstructions. Pas votre cas, si votre parc est sain.

Et il y a mieux. Les mises à jour mineures, celles qui font vivre votre boutique au quotidien, une 8.1 vers 8.2, la stabilisation d’une 1.7, les paliers 9.0 vers 9.1 vers 9.2 quand ils sortiront, tout ça est inclus dans notre forfait de maintenance à 69 €/mois. Vous ne les payez jamais à l’acte.

Faites le calcul sur trois ans. Une montée majeure une seule fois, disons une journée à 630 €, plus la maintenance à 69 €/mois qui absorbe tous les paliers suivants : vous êtes très loin des scénarios à plusieurs milliers d’euros que le marché agite. Et surtout, vous ne vous retrouvez plus jamais coincé cinq ans en arrière, à devoir tout reprendre en catastrophe. C’est ça, la différence entre subir ses versions et les piloter.

En pratique, sur nos montées de version 2025, la médiane tient dans la demi-journée à la journée — 300 à 600 € — dès que le parc est sain. Les fourchettes à quatre ou cinq chiffres qu’agite le marché ne concernent que les reconstructions, jamais une montée de version sur une boutique en bon état. Sur ce point, on n’a rien à cacher : nos forfaits de maintenance incluent la mise à jour continue de votre boutique, version après version.

La réponse selon votre profil

Assez de théorie. Voici, noir sur blanc, ce que je vous recommande selon votre situation. Et vous allez le voir, on penche vers la 9 dès que c’est raisonnable. Ce n’est pas de la mode, c’est de l’économie : viser la version que vous garderez le plus longtemps, c’est ne pas repayer une migration dans deux ans.

Reprenons chaque cas, parce que les nuances comptent.

Vous créez une boutique neuve en 2026 ? PrestaShop 9.1, sans une seconde d’hésitation. Démarrer aujourd’hui sur la 8, ce serait choisir volontairement une version qui vieillira avant vous. Aucun sens.

Vous êtes en 1.6 ? On y revient en détail juste après, parce que votre cas est particulier. Mais la réponse courte est déjà là : visez la 9.1. Vous allez reconstruire de toute façon, autant reconstruire sur la version d’avenir.

Vous êtes en 1.7 avec des modules courants et un parc sain ? C’est le cas le plus fréquent, et c’est là qu’on se distingue des conseils prudents. On vous emmène jusqu’à la 9.1, en un seul chantier qui passe par la 8.2. Comptez 360 à 630 € si votre parc est vraiment propre. Vous ne vous arrêtez en 8.2 que si un module bloquant vous y force, pas par principe.

Vous êtes en 1.7 avec beaucoup de développements sur mesure, ou un très gros catalogue ? Là, on ralentit. Le risque module est à son maximum, et on ne joue pas avec une boutique qui fait votre chiffre. On sécurise en 8.2, on audite le parc, on remplace ce qui doit l’être, et on vise la 9 dans un second temps, une fois le terrain déminé.

Concrètement, pour ce profil, un module sur mesure à réécrire pour la 9, c’est en général deux à cinq jours de développement chacun. Multipliez par le nombre de modules concernés et vous comprenez pourquoi, ici, on sécurise en 8.2 d’abord : on ne transforme pas une migration en refonte non budgétée.

Vous êtes déjà en 8 ? Vous avez le luxe du temps, votre version reçoit encore des correctifs. Préparez votre parc tranquillement et visez la 9.1. Et surtout, pas la 9.0 : ce serait viser une marche que vous quitteriez aussitôt.

Vous remarquez le fil conducteur : dans quatre profils sur cinq, la réponse est la 9.1. Ce n’est pas un parti pris technophile, c’est le résultat du raisonnement de tout l’article. On ne vise la 8.2 comme destination que dans un seul cas, celui où un parc lourd et sur mesure l’impose. Partout ailleurs, s’arrêter en 8 reviendrait à payer aujourd’hui pour une version que vous quitteriez demain.

Le cas de la 1.6 : ce n’est pas une migration, c’est une reconstruction

Je garde ce cas pour la fin parce qu’il mérite qu’on s’y arrête, et parce que c’est là que la plupart des conseils que vous lirez ailleurs se trompent.

Il faut distinguer deux choses qu’on appelle à tort du même nom. Passer de 1.7 à 8, c’est une mise à jour, quasi indolore : techniquement, la 8 est surtout une 1.7 renommée. Passer de 1.6 à quoi que ce soit, c’est une reconstruction. Ce n’est ni le même métier, ni le même budget.

Pourquoi ? Parce qu’entre la 1.6 et la 1.7, PrestaShop a changé d’architecture de fond en comble en 2016. Le thème doit être entièrement refait, la documentation officielle des contributeurs le dit noir sur blanc, et les modules des pages produit adaptés un par un. Vous ne mettez pas à jour une 1.6, vous reconstruisez la boutique sur des fondations neuves.

Une précision technique qui compte : on ne migre pas une 1.6 directement vers la 9. Le chemin officiel passe par des étapes intermédiaires, et de toute façon, dans une reconstruction, on repart le plus souvent d’une installation neuve de la version cible, sur laquelle on réimporte votre catalogue, vos clients et vos commandes. Raison de plus pour choisir tout de suite la bonne cible : autant réimporter vos données une fois, dans la 9.1, plutôt que de refaire l’opération deux ans plus tard.

Et c’est précisément ce qui change la recommandation. Puisque vous payez une reconstruction dans tous les cas, la logique « 8 d’abord » s’effondre pour la 1.6. Pourquoi reconstruire sur la 8, une version qui vieillira, quand reconstruire sur la 9.1 ne coûte pas plus cher et vous met sur la version d’avenir ? Si vous êtes en 1.6, visez la 9. C’est l’avis tranché que peu d’agences osent formuler, et il tient debout.

Un mot sur la réalité de votre 1.6, pour finir de vous convaincre de bouger : elle plafonne à PHP 7.1, une version elle-même en fin de vie ; elle repose sur l’architecture Smarty, sans cache moderne et structurellement lente ; ses modules ne sont plus maintenus ; et les développeurs encore à l’aise sur cette stack se comptent, et se paient cher.

Concrètement, reconstruire depuis une 1.6, c’est 5 à 10 jours de travail effectif, étalés sur un à deux mois de projet : auditer les modules, choisir un thème, monter le staging, refaire la vitrine, puis réintégrer vos données une fois le visuel validé. Comptez 3 000 à 6 000 € selon la taille, licences de modules et nouveau thème compris.

En pratique, ce que donnent nos migrations

Les chiffres du marché, c’est bien. Les nôtres, c’est mieux, parce que ce sont de vraies boutiques, migrées pour de vrais marchands.

Et un cas concret, parce qu’un exemple vaut tous les tableaux :

Comment décider sans se tromper

Pour finir, la marche à suivre, dans l’ordre.

D’abord, l’audit. Il représente 30 à 50 % du temps total d’une migration, et c’est lui qui fait la différence entre une bascule propre et une catastrophe. Comptez vos modules, notez votre parc, identifiez vos bloquants. C’est là que tout se décide.

Ensuite, le calendrier. On ne migre jamais en pleine saison. Jamais en novembre-décembre. La bonne fenêtre, c’est janvier-février, quand le trafic est calme et qu’un imprévu ne coûte pas votre mois le plus important.

Enfin, la préproduction. On teste la migration sur une copie de votre boutique, jamais en direct sur le site en ligne. Ça vous évite la seule vraie catastrophe : casser une boutique qui vend.

Trois étapes, dans cet ordre, ni plus ni moins. La plupart des migrations qui tournent mal ont sauté l’une des trois, presque toujours l’audit ou la préproduction. Prenez le temps de les faire, ou confiez-les à quelqu’un dont c’est le métier.

Et une fois que vous serez à jour, ne repartez pas pour cinq ans de retard. Notre forfait de maintenance garde votre boutique à jour version après version, les montées mineures comprises. Vous ne repayez plus jamais une migration mineure.