Agence PrestaShop à Grenoble : faire monter votre boutique sur une version de PHP maintenue

Une boutique sous PHP 7.4 ne reçoit plus de correctifs de sécurité.

Changer de version touche au moteur du site, et une erreur peut tomber un jour de soldes. Voici comment choisir une agence PrestaShop à Grenoble pour faire ce passage sans casse.

• Agence PrestaShop à Grenoble : mettre votre boutique sur une version de PHP encore maintenue
• Une mise à niveau de PHP peut aussi imposer une mise à niveau de PrestaShop
• Préproduction, tests et retour arrière limitent les pannes
• Les URL et les redirections protègent le référencement pendant la migration
• Le coût dépend des corrections, du périmètre et du support
• Un cahier des charges rend la migration vérifiable et réversible
• Foire aux questions

Agence PrestaShop à Grenoble : mettre votre boutique sur une version de PHP encore maintenue

Une simple montée de version de PHP prend 1 à 3 jours sur une boutique sans fioritures. Avec un thème personnalisé, des modules anciens ou une PrestaShop 1.7, comptez plutôt 2 à 6 semaines, dont une semaine de tests.

Choisir la version cible

Pour PrestaShop 9.0, PHP 8.4 est le bon compromis : compatible, conseillé par PrestaShop et maintenu pour les correctifs de sécurité jusqu’à fin 2028. PHP 8.5 fonctionne avec les versions 9.1 et 9.2, mais pas avec la 9.0.

Posez ces trois questions à votre hébergeur :

• quelles versions de PHP sont réellement disponibles ;
• peut-on changer de version par domaine ;
• avez-vous accès aux journaux PHP.

Un serveur peut afficher « PHP 8.4 disponible » tout en gardant des extensions anciennes ou une limite mémoire trop basse pour votre boutique. Cette seule raison suffit à bloquer une migration.

Comparer les prestataires locaux

L’annuaire officiel PrestaShop recense les agences certifiées à Grenoble. D’autres acteurs locaux annoncent création, migration, maintenance et intégration de flux, notamment pour les paiements, les transporteurs, les ERP et les CRM.

Une page commerciale ne prouve pas qu’une agence a déjà fait une migration comparable à la vôtre.

Demandez-lui précisément :

• la version de départ ;
• la version d’arrivée ;
• le nombre de modules adaptés ;
• la procédure de retour arrière.

Un retour arrière sérieux ne se résume pas à « remettre l’ancienne version ». Il faut restaurer les fichiers, la base de données et les commandes passées entre la sauvegarde et l’incident, ou prévoir une synchronisation finale maîtrisée.

Décrire mon besoin →

Une mise à niveau de PHP peut aussi imposer une mise à niveau de PrestaShop

Changer de PHP modifie le moteur qui fait tourner votre boutique. Mettre à jour PrestaShop remplace le logiciel, sa structure, ses composants et parfois ses exigences serveur. Ce sont deux opérations distinctes. Elles sont souvent menées ensemble.

Délimiter l’intervention

Une boutique PrestaShop 1.7.8 peut tourner sous PHP 7.4, mais PHP 7.4 n’est plus maintenu. Passer à PHP 8.4 impose en général de mettre aussi PrestaShop à jour, d’adapter le thème et de contrôler chaque module.

Le choix de la cible dépend donc de la version PrestaShop que vous gardez ou installez.

Auditer la boutique

Un audit initial doit relever :

• La version de PrestaShop et celle de PHP
• La version de MySQL ou MariaDB
• La mémoire disponible
• Les tâches planifiées
• Le mode multiboutique
• Les connexions externes

Ces données conditionnent le devis et le calendrier.

L’agence doit aussi inventorier les modules installés, activés, désactivés et réellement utilisés. Un module présent dans le dossier modules peut encore agir sur le paiement, le tunnel de commande ou une tâche automatique. Il n’apparaît pourtant plus dans le back-office.

Traiter les composants incompatibles

Un module abandonné présente deux risques. Il peut provoquer une erreur sous la nouvelle version de PHP. Il peut aussi bloquer les évolutions futures de PrestaShop. Un autre module couvre parfois déjà la même fonction, avec moins de code et moins de dépendances.

Le devis doit séparer quatre lignes :

• Le changement de PHP
• La mise à niveau de PrestaShop
• L’adaptation du thème
• Le traitement des modules

Un forfait global de 1 500 € HT^* peut suffire pour une boutique de 100 produits avec thème standard. Il devient insuffisant avec 20 modules et un tunnel de commande sur mesure.

Décrire mon besoin →

Préproduction, tests et retour arrière limitent les pannes

Une préproduction, c’est une copie de travail isolée de votre boutique. Elle reprend les fichiers, la base de données, le thème, les modules et les réglages serveur. Les versions de PHP et de base de données doivent coller au plus près de la production.

Vos données clients doivent être anonymisées avant la copie. Protégez l’accès par mot de passe ou par restriction réseau. Neutralisez les courriels, les paiements et les appels aux transporteurs, ou dirigez-les vers leurs environnements de test.

La préproduction doit utiliser la version PHP cible. Elle doit aussi avoir les mêmes extensions, une mémoire comparable et un moteur de base de données compatible. Tester PHP 8.4 sur un ordinateur local ne valide pas un serveur de production configuré autrement.

Une sauvegarde complète couvre les fichiers, les images et la base de données. PrestaShop recommande de les conserver séparément. Ne laissez jamais une copie accessible publiquement à la racine du site.

La recette doit couvrir les parcours qui font gagner ou perdre de l’argent :

• compte, connexion et récupération de mot de passe
• recherche, filtres, déclinaisons et ajout au panier
• frais de port, taxes, promotions et transporteurs
• paiement accepté, paiement refusé et retour depuis la banque
• commandes, factures, avoirs et remboursements, avec décrémentation des stocks et synchronisation avec l’ERP
• courriels de confirmation, préparation et expédition
• affichage mobile, langues et devises si la boutique les utilise

Le retour arrière doit reposer sur un déclencheur mesurable :

• paiement impossible
• commande non créée
• stock incohérent
• erreur serveur répétée
• hausse des erreurs 500

Prévoyez au moins deux heures de surveillance active après la bascule. Ensuite, comptez 24 à 72 heures de suivi renforcé, selon votre trafic.

Les URL et les redirections protègent le référencement pendant la migration

Le référencement dépend aussi des URL, des balises canoniques, des liens internes, du sitemap et des réponses du serveur. Tous ces éléments doivent rester cohérents après la migration. Si l’un d’eux casse, Google le voit vite.

Cartographier les changements d’URL

Avant toute modification, exportez les adresses de vos produits, catégories, pages CMS, fabricants et contenus éditoriaux. Ajoutez le code de réponse, le trafic organique et les liens entrants de chaque page, si vous les avez. Ce relevé est votre filet de sécurité.

Associez ensuite chaque ancienne adresse à sa destination. Une ancienne fiche produit doit renvoyer vers la fiche équivalente, pas vers la page d’accueil. Une redirection vers l’accueil fait perdre le lien et la visite.

Si le produit disparaît, la destination dépend du cas :

• une catégorie proche ;
• un produit de remplacement ;
• une réponse 404 propre.

Vérifier le site après bascule

Contrôlez les URL des produits, catégories, pages CMS, recherche, panier et compte client. Vérifiez aussi les adresses avec et sans barre finale, les versions HTTP et HTTPS, les paramètres de tri et les URL multilingues. Chaque variante doit pointer au bon endroit.

Cherchez les erreurs 404, les liens internes cassés et les balises canoniques. PrestaShop fournit une variable canonique pour les pages et une variable dédiée au sitemap dans ses thèmes. Un thème personnalisé peut pourtant les modifier ou les supprimer sans prévenir.

Suivre le référencement

Générez un sitemap propre, soumettez-le dans Google Search Console et surveillez les pages indexées, les erreurs d’exploration et les URL exclues. Gardez ce suivi plusieurs semaines. Les effets d’une migration ne se voient pas seulement dans les premières 24 heures.

Aucune agence ne peut garantir le maintien exact de vos positions après un changement de version, de thème ou d’URL. En revanche, vous pouvez exiger un plan de redirections, un relevé avant migration, un contrôle après bascule et un délai d’intervention. Ce sont des engagements concrets, que vous pouvez vérifier.

Une position garantie sur Google, en revanche, n’existe pas.

Décrire mon besoin →

Le coût dépend des corrections, du périmètre et du support

Pour une intervention limitée au changement de PHP, comptez environ 300 à 1 200 € HT^* pour une boutique de moins de 500 produits. Le thème doit être standard, les modules maintenus et l’accès serveur disponible. Ce prix ne couvre pas une mise à niveau majeure de PrestaShop.

Pour une migration complète vers PrestaShop 8 ou 9, les tarifs publiés vont d’environ 1 800 à 10 000 € HT^*. Les boutiques complexes, multiboutiques ou connectées à un ERP dépassent cette fourchette.

Établir un budget comparable

Le prix grimpe avec le nombre de modules, le volume d’images et l’historique de commandes. Il monte aussi avec les règles de prix, les langues, les boutiques, les connexions API et la reprise des URL. Les modules sur mesure restent la principale source d’incertitude.

Une maintenance technique coûte souvent entre 129 et 350 € HT^* par mois pour une PME. Le prix dépend des heures incluses, des sauvegardes, du monitoring et du délai d’intervention. Une agence généraliste peut dépasser 500 € HT^* par mois avec un support étendu.

Comparer les devis

Ajoutez à chaque devis :

• les licences de modules
• le renouvellement du thème
• l’hébergement de la préproduction
• les extensions PHP manquantes
• les éventuels frais liés à la banque ou aux transporteurs

Une licence annuelle oubliée peut transformer un devis de 4 000 €^* en budget récurrent.

Demandez aussi le mode de facturation. Un acompte de 30 à 50 %, un paiement à la validation de la préproduction et un solde après mise en ligne sont plus lisibles qu’une régie sans plafond. Toute heure supplémentaire doit recevoir votre accord écrit.

Un cahier des charges rend la migration vérifiable et réversible

Pour une boutique standard, votre document de cadrage tient en 5 à 10 pages. Il doit permettre à quelqu’un d’autre de comprendre la cible et les limites du projet. Il doit aussi dire comment revenir en arrière, sans dépendre de l’historique oral.

Formaliser les livrables

Exigez un audit écrit. Il doit inclure les prérequis d’hébergement de la version cible.

Ajoutez l’inventaire des personnalisations :

• thème
• thème enfant
• modules maison
• overrides
• tâches cron
• connecteurs
• flux produits
• règles commerciales

Pour chaque élément, indiquez le responsable, la décision prise et le test attendu.

Chaque module doit recevoir une décision documentée. « Compatible » doit vouloir dire testé sur votre version cible, avec votre thème et votre tunnel de commande. Une simple mention sur une fiche commerciale ne suffit pas.

Encadrer le devis

Le contrat précise les tâches incluses et exclues. Il indique le nombre de produits, de clients et de commandes repris, les langues, les boutiques, les redirections et le nombre de cycles de correction.

Indiquez qui intervient sur l’hébergement :

• changement de PHP
• extensions
• cache
• tâches cron
• accès SSH
• restauration

Une agence peut adapter PrestaShop sans avoir les droits nécessaires sur le serveur.

Fixez les critères de réception. Par exemple : une commande de test payée, un remboursement contrôlé, une page d’accueil accessible. Le solde se paie après cette validation, pas après le simple transfert des fichiers.

Organiser le pilotage

Nommez un référent côté boutique et un référent côté agence. Prévoyez :

• un point hebdomadaire
• un compte rendu court
• une liste des anomalies
• une date de validation de la préproduction

Exigez enfin la documentation des changements :

• version de PHP
• modules mis à jour
• fichiers modifiés
• règles serveur
• tâches planifiées
• procédure de restauration

Sans cette restitution, votre prochaine mise à jour dépendra entièrement de la mémoire du prestataire.

Références utilisées

Avant de signer, exigez un audit écrit, une décision documentée pour chaque module et une procédure de retour arrière. Le solde ne se paie qu’après une commande de test payée et validée en préproduction.

Votre checklist avant de confier la migration PHP de votre boutique

Cochez les points à vérifier avec votre agence PrestaShop à Grenoble.

• Connaissez-vous la version de PHP et de PrestaShop que vous utilisez aujourd’hui ?

  Sans ces deux versions, impossible de savoir si votre boutique est encore maintenue ni quelle cible choisir.

• Votre hébergeur permet-il de changer de version de PHP, et par domaine ?

  Un serveur peut afficher une version disponible tout en gardant des extensions anciennes ou une mémoire trop basse.

• L’agence a-t-elle déjà réalisé une migration comparable à la vôtre ?

  Une page commerciale ne prouve pas l’expérience. Demandez un cas proche du vôtre.

• Le devis sépare-t-il le changement de PHP, la mise à niveau de PrestaShop, le thème et les modules ?

  Un forfait global peut cacher des modules abandonnés qui font grimper la facture.

• Une procédure de retour arrière est-elle prévue, avec restauration des fichiers, de la base et des commandes ?

  « Remettre l’ancienne version » ne suffit pas si des commandes ont été passées entre-temps.

• Une préproduction avec des données anonymisées est-elle prévue pour tester la migration ?

  Elle doit utiliser la version PHP cible et des extensions identiques à celles de la production.

• Les redirections des anciennes URL sont-elles prévues vers les pages équivalentes ?

  Rediriger tout vers l’accueil fait perdre le lien et la visite.

• Le solde est-il prévu après une commande de test payée et validée en préproduction ?

  Le paiement final ne doit pas dépendre du simple transfert des fichiers.

Points cochés : sur 8. Rien n'est envoyé ni enregistré : la liste reste dans votre navigateur.

Décrire mon besoin →

Foire aux questions

Quel est le meilleur site de vente en ligne gratuit ?

Il n’existe pas de meilleur choix pour toutes les entreprises. PrestaShop Open Source se télécharge gratuitement, mais l’hébergement, le nom de domaine, les modules et les interventions techniques restent à financer.

Une boutique PrestaShop peut-elle fonctionner avec un hébergement mutualisé ?

Oui, à condition que l’hébergement propose une version de PHP compatible, une base MySQL ou MariaDB adaptée, les extensions nécessaires et une mémoire suffisante. Ce choix convient surtout aux petits catalogues et aux trafics réguliers, pas à une boutique exposée à de forts pics de commandes.

Faut-il conserver les anciennes sauvegardes après la migration ?

Oui. Gardez au moins une sauvegarde complète prise avant la migration, une copie indépendante et les journaux de l’opération. Rangez-les hors d’un emplacement accessible publiquement, puis testez leur restauration sur un environnement isolé.

* Tarifs et prix moyens constatés en décembre 2025, sur des retours d'appels d'offres provenant de freelances et d'agences. Ces chiffres ne sauraient être une référence de négociation, car les sources varient selon la taille du site et la séniorité du prestataire.