Agence PrestaShop à Nîmes : changer de prestataire de maintenance sans interrompre les ventes

Un jour de soldes, une page de paiement bloquée, et les commandes s’arrêtent. Changer de prestataire sans savoir ce qui tourne dans la boutique augmente ce risque.

Voici comment trouver une agence PrestaShop à Nîmes qui reprend la maintenance sans interrompre les ventes.

• Agence PrestaShop à Nîmes : changer de prestataire sans couper les ventes
• L’état des lieux révèle les dépendances avant tout transfert
• Des comptes individuels et des droits limités sécurisent la reprise
• Les sauvegardes doivent être vérifiées avant toute intervention à risque
• Le mode maintenance ferme la boutique au public tout en laissant entrer l’équipe
• La préproduction protège la production des mises à jour ratées
• Les tarifs de maintenance changent selon les heures incluses et le support
• Un contrat mesurable organise la continuité du service
• Foire aux questions

Agence PrestaShop à Nîmes : changer de prestataire sans couper les ventes

Une reprise de maintenance PrestaShop à Nîmes prend en général 5 à 10 jours ouvrés pour une boutique standard, à condition de faire d’abord un audit PrestaShop lent à Aix-en-Provence si votre site rame. Si l’audit révèle du sur-mesure, comptez 3 à 6 semaines. Ce sont les modules personnalisés, l’hébergement et les accès manquants qui allongent le délai, bien plus que la distance.

Tout commence par une reprise documentaire et technique, sans toucher à la boutique en production. Les versions, les comptes, les sauvegardes, le paiement et les tâches automatiques se vérifient avant la moindre mise à jour.

Une maintenance corrige et sécurise l’existant. Une refonte change la structure, le thème ou le parcours client. Ce sont deux budgets distincts, et les confondre est la première source de devis gonflés.

Pour une boutique de 300 à 1 000 produits, avec 10 à 20 modules et moins de 20 000 visites par mois, voici ce qu’il faut prévoir en général :

• Audit de reprise : 600 à 1 500 € HT^*, avec inventaire technique, contrôle des accès, vérification du paiement et rapport d’actions.
• Maintenance courante : 150 à 450 € HT^* par mois, selon le nombre d’heures, les délais de réponse et les mises à jour incluses.
• Reprise d’urgence : 95 à 150 € HT^* de l’heure si une erreur bloquante ou un paiement défaillant est déjà en cours.
• Refonte ou migration : à partir de 4 000 € HT^* pour une boutique simple, sur devis séparé avec environnement de test.

Une agence basée à Nîmes peut travailler à distance pour les accès techniques. Elle peut aussi se déplacer dans le Gard pour le transfert avec le dirigeant, le responsable e-commerce ou l’ancien prestataire. Ce qui compte, c’est la disponibilité des accès et la capacité à intervenir hors de vos heures de pointe.

L’état des lieux révèle les dépendances avant tout transfert

L’audit doit relever au minimum :

• PrestaShop : version exacte, niveau de correctif, langues, multiboutique et état de la base.
• PHP : version active, extensions disponibles, mémoire allouée et mode d’exécution.
• Base de données : moteur, version MySQL ou MariaDB, taille et fréquence des sauvegardes.
• Modules : nom, version, fonction, licence, éditeur et compatibilité annoncée.
• Personnalisations : overrides, hooks, contrôleurs modifiés, tâches cron et scripts externes.

PrestaShop 8.1 recommande PHP 8.1. PrestaShop 9 demande PHP 8.1 au minimum, avec PHP 8.4 recommandé pour la 9.0 et PHP 8.5 pour la 9.1. Une boutique encore sous PHP 7.4 doit donc prévoir un chantier dédié avant toute migration vers la 9.

L’audit reprend aussi l’historique des douze derniers mois. Il y cherche :

• les erreurs 500,
• les commandes non remontées,
• les paniers abandonnés après paiement,
• les importations incomplètes,
• les interventions déjà planifiées.

Une maintenance préventive sérieuse repose sur cinq points :

• des mises à jour testées,
• une surveillance,
• des sauvegardes,
• un contrôle du tunnel d’achat,
• un suivi des erreurs.

Le parcours de paiement se teste avec un montant faible ou un environnement de test fourni par le prestataire de paiement. Le contrôle porte sur la création de commande, le statut « payé », l’e-mail client, la décrémentation du stock et la remontée vers l’ERP.

Une page de paiement qui s’affiche correctement ne prouve rien d’autre.

Décrire mon besoin →

Des comptes individuels et des droits limités sécurisent la reprise

Chaque intervenant doit avoir son propre compte. Refusez les identifiants partagés du type « agence ». Ils empêchent de savoir qui a modifié un module, vidé un cache ou changé un réglage. PrestaShop recommande un compte employé par personne ayant accès au back-office.

Le profil SuperAdmin donne accès à toute l’installation. Il doit rester entre les mains du dirigeant ou d’un responsable technique identifié. Pour la maintenance courante, créez un profil dédié. Il ne reçoit que les droits nécessaires sur les modules, les paramètres avancés, les performances et les journaux.

La procédure de reprise tient en cinq étapes :

1. Créer un compte individuel pour chaque intervenant dans Paramètres avancés, Équipe, Employés.
2. Créer un profil « Maintenance » dans Paramètres avancés, Équipe, Profils.
3. Limiter les permissions à ce qui est nécessaire.
4. Tester la connexion avec chaque compte pour vérifier les menus visibles.
5. Désactiver les comptes de l’ancien prestataire une fois le transfert validé.

Les accès suivants doivent rester séparés du compte PrestaShop : hébergement, nom de domaine, DNS, compte de paiement, serveur SMTP, clés API et places de marché. Transmettez-les par invitation nominative ou via un coffre-fort de mots de passe. Puis révoquez les accès sortants après la période de transition.

Les sauvegardes doivent être vérifiées avant toute intervention à risque

Une sauvegarde exploitable contient au moins les fichiers et la base de données. Les fichiers couvrent le code, les modules, le thème et les images. La base contient produits, clients, commandes et réglages. Sauvegarder la seule base ne suffit pas à restaurer un thème personnalisé.

Avant un changement de version, demandez quatre informations par écrit :

• l’emplacement de la sauvegarde (serveur, stockage externe ou compte d’hébergement)
• la personne capable de la lancer et de la récupérer
• la fréquence
• la durée de conservation

Les sauvegardes ne doivent jamais traîner dans un dossier accessible publiquement à la racine de la boutique. Gardez une copie externe. Vérifiez qu’elle contient un fichier SQL complet, les images utiles et les fichiers modifiés.

Une sauvegarde réussie n’est pas une restauration réussie. Sur une préproduction, restaurez fichiers et base. Mesurez le délai jusqu’à l’accueil, la connexion au back-office et une commande de test. Pour une petite boutique, un retour en service en 2 heures est réaliste. Au-delà de 50 000 produits, ou avec un serveur mal documenté, prévoyez 4 à 8 heures.

L’Assistant de mise à jour PrestaShop peut sauvegarder fichiers et base, puis restaurer une version précédente. La documentation distingue la sauvegarde complète, qui inclut les images, de la partielle, qui les exclut. Lancez quand même une sauvegarde manuelle avant l’opération. La sauvegarde automatique du module ne doit pas être votre seul filet.

Faites fixer une fréquence minimale dans le contrat. Pour une boutique qui reçoit des commandes chaque jour, mieux vaut une sauvegarde quotidienne de la base. Prévoyez aussi une copie des fichiers avant chaque mise à jour, conservée 14 à 30 jours. Pour un fort volume, deux sauvegardes par jour limitent la perte des dernières commandes.

Décrire mon besoin →

Le mode maintenance ferme la boutique au public tout en laissant entrer l’équipe

Le mode maintenance cache la boutique aux visiteurs et affiche une page d’indisponibilité. Vous pouvez autoriser certaines adresses IP pour que l’équipe technique continue de travailler. Le réglage se trouve dans Paramètres de la boutique, puis Général, puis Maintenance.

Notez l’adresse IP de l’intervenant, puis activez la maintenance. Testez l’accès depuis cette adresse. Vérifiez aussi que le site reste fermé depuis une connexion extérieure. Après l’intervention, désactivez le mode. Contrôlez ensuite l’accueil, la recherche, le panier et la commande.

Pour limiter la gêne, programmez les opérations visibles entre 22 heures et 6 heures, après avoir regardé vos statistiques de commandes. Annoncez une durée de 30, 60 ou 120 minutes, avec une heure de fin. Une fenêtre floue, comme « dans la nuit », ne permet pas de gérer un incident.

La préproduction protège la production des mises à jour ratées

La production reçoit les vraies commandes. La préproduction est une copie séparée, sur une autre adresse, protégée par un mot de passe. Elle doit rester coupée des clients, des e-mails transactionnels et des paiements réels. Si elle envoie de vrais e-mails ou débite une vraie carte, ce n’est pas un environnement de test.

Copiez les fichiers et la base vers la préproduction. Ensuite, désactivez les tâches automatiques et les notifications sortantes. Remplacez les clés de paiement par celles du mode test. Pour chaque version visée, vérifiez PHP, les extensions, la mémoire, la base et les droits d’écriture.

La recette couvre au minimum :

• le catalogue (recherche, fiche produit, déclinaisons)
• l’achat (panier, comptes clients, règles de prix, codes promo)
• la livraison et le paiement
• la confirmation (e-mail et document de commande)

Répétez ces tests sur Chrome, Safari, Firefox, Android et iPhone.

Après validation, sauvegardez la production. Si la base doit être synchronisée, bloquez les commandes pendant la bascule, puis déployez. Contrôlez les erreurs serveur, les journaux de paiement, le stock, les commandes et les temps de réponse. La documentation PrestaShop demande aussi de vérifier le front-office, les modules et la désactivation du mode maintenance.

Décrire mon besoin →

Les tarifs de maintenance changent selon les heures incluses et le support

• Dès 55 € HT^* par mois : maintenance, dépannage urgent, monitoring et sauvegardes, avec prix ajusté à la boutique
• 149 € HT^* par mois : 8 heures par an, mises à jour deux fois par mois, SLA de 3 à 12 heures selon la gravité
• 69 € HT^* par mois : surveillance, mises à jour testées, sauvegarde quotidienne, contrôle mensuel du tunnel
• 149 € HT^* par mois : hébergement inclus, sauvegarde deux fois par jour, tests de paiement hebdomadaires, 2 heures de modifications
• 290 € HT^* par mois : 4 heures de développement et support prioritaire

Certains prestataires facturent 55 € HT^* pour une heure ponctuelle. D’autres facturent 95 € HT^* de l’heure pour une intervention ponctuelle.

L’une des offres à 149 € HT^* demande un engagement de 12 mois.

Pour une boutique de moins de 100 commandes par mois, un forfait de 150 à 250 € HT^* peut suffire si les mises à jour sont mensuelles et le support limité aux heures ouvrées.

Entre 100 et 1 000 commandes, prévoyez plutôt 250 à 600 € HT^*, car tests, sauvegardes et contrôles de paiement prennent plus de temps.

Au-delà, l’hébergement et la supervision se chiffrent à part.

Comparez toujours les mêmes lignes dans un devis :

• heures incluses et report possible
• délai de prise en charge d’une panne
• plage horaire du support
• tests avant mise en production
• mises à jour du cœur, des modules et de PHP
• coût de l’heure hors forfait
• hébergement et sécurité inclus ou non

Un contrat mesurable organise la continuité du service

Le contrat doit décrire les opérations incluses. Le mot « maintenance » ne suffit pas. Faites figurer les mises à jour du cœur et des modules, la surveillance, les sauvegardes, les tests de commande, les correctifs de sécurité, le suivi des erreurs et un compte rendu mensuel.

Les demandes se classent selon leur impact :

Ces délais concernent la prise en charge, pas la résolution garantie. Une erreur liée à un service de paiement externe, un serveur compromis ou un module sans code source peut demander plusieurs heures de diagnostic. Le contrat précise aussi les horaires, le canal de signalement et qui peut valider une intervention payante.

Toute opération hors forfait doit avoir un tarif, une estimation et une règle de validation. Fixez par exemple une alerte à 80 % du budget prévu. Au-delà, une validation écrite est obligatoire. Les développements complexes, les intégrations sur mesure et les refontes restent sur devis séparé.

La responsabilité du prestataire doit aussi être bornée. Il peut garantir ses procédures de sauvegarde, ses tests et ses délais de réponse. Il ne peut pas garantir le comportement d’une API externe, d’un module abandonné ou d’un hébergeur dont il ne contrôle pas la configuration.

Enfin, le contrat doit prévoir la sortie. Précisez le préavis, la restitution des fichiers, de la base et des journaux, les licences transférables, les procédures et les accès. Certaines conditions publiques prévoient un préavis d’un mois pour les abonnements récurrents.

Avant de signer avec un nouveau prestataire, exigez un audit de reprise, entre 600 et 1 500 € HT^* pour une boutique de 300 à 1 000 produits, puis une sauvegarde restaurée en préproduction et un compte nominatif pour chaque intervenant. C’est ce qui vous permet de changer de prestataire sans couper vos ventes.

Décrire mon besoin →

Foire aux questions

Combien de temps l’ancien prestataire doit-il rester disponible ?

Comptez 5 à 10 jours ouvrés de recouvrement, pendant lesquels l’ancien prestataire répond à vos questions sur le code, les licences, les tâches planifiées et les incidents connus. Pendant ce temps, la nouvelle agence vérifie progressivement les éléments transmis. Ne coupez pas son accès avant la fin de cette période.

Faut-il changer l’hébergeur en même temps que l’agence ?

Non, sauf si l’hébergement bloque les sauvegardes, la préproduction, les accès techniques ou la version PHP requise. Changer prestataire et serveur la même semaine double le nombre de points à contrôler : mieux vaut séparer les deux chantiers de 2 à 4 semaines.

Peut-on utiliser un environnement headless avec PrestaShop ?

Oui, mais le front-office doit être traité comme une application séparée. Les produits, clients et commandes échangent avec les services externes via l’API webservice, qui fonctionne avec des clés et des droits par ressource. Le devis doit donc inclure la supervision de ces échanges.

La maintenance couvre-t-elle les flux vers les places de marché ?

Seulement si le contrat les nomme explicitement. Chaque flux, qu’il s’agisse d’un produit, d’un retour de stock ou d’une remontée de commande, doit avoir son propre test, son responsable et son délai de correction, surtout si plusieurs canaux utilisent la même API.

* 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.