Changer de prestataire PrestaShop : reprendre sa boutique sans rien casser

Le jour où vous annoncez à votre prestataire que vous partez, vous avez moins de moyens de pression. Il n’est pas forcément de mauvaise foi, il a juste moins de raisons de se presser. Si le nom de domaine, les modules payants ou le compte PayPal sont encore à son nom ce jour-là, la reprise de votre boutique dépend de sa bonne volonté.

Changer de prestataire PrestaShop se passe bien quand on suit un ordre précis : relire, mettre à son nom, récupérer, tester, et seulement ensuite prévenir. Si vous hésitez encore à partir, commencez par notre guide pour choisir une agence PrestaShop. Ce guide-ci part d’une décision prise. Il donne la méthode compte par compte, de la 1.6 à la 9, avec les menus exacts et une checklist à imprimer.

Dans quel ordre changer de prestataire PrestaShop

Sept étapes. Les quatre premières se font sans annoncer votre départ.

Étape	Prestataire prévenu ?
1. Relire le contrat : préavis, réversibilité, propriété du code, données.	Non
2. Mettre à votre nom le domaine, l’hébergement, les comptes de paiement, Google, Cloudflare, les modules.	Non : c’est une demande de routine
3. Récupérer vos accès et une sauvegarde complète.	Non
4. Restaurer la sauvegarde sur une copie et faire l’inventaire.	Non
5. Prévenir, fixer la date de fin et le déroulé de la passation.	Oui
6. Basculer vers le nouvel hébergeur, si l’hébergement change.	Oui
7. Fermer ses accès et changer les mots de passe.	Oui, après la bascule validée

Vous pourriez demander la même chose en restant client : un prestataire sérieux s’exécute sans discuter. S’il résiste, notez-le. Vous gardez le même hébergeur et changez seulement de mainteneur ? Sautez l’étape 6.

Ce que contient une passation propre

À l’étape 5, demandez par écrit, avec une date de remise :

• la liste des accès et des comptes (où ils se trouvent, à quel nom), sans aucun mot de passe ;
• une sauvegarde complète et datée, fichiers et base du même moment ;
• les sources de tout ce qui a été développé pour vous, et le dépôt Git s’il existe ;
• une page « ce qu’il faut savoir » : versions, modules et licences, surcharges, tâches planifiées, flux vers l’ERP ou les marketplaces, problèmes connus, modules à ne pas mettre à jour ;
• le transfert des achats Marketplace et la date de fin de sa mission ;
• une confirmation écrite qu’il a supprimé ses copies de vos données clients, une fois la passation terminée.

Réglez ce qui est dû avant de réclamer : une facture en souffrance est souvent la raison invoquée pour retenir des fichiers, et beaucoup de contrats ne cèdent le code qu’après paiement complet. Quand tout est remis et vérifié, faites signer un court état de ce qui a été rendu, avec la date. Gardez-le avec le contrat.

Les deux messages à envoyer

Étapes 2 et 3, sans parler de départ :
« Bonjour [prénom],
Nous mettons à jour la liste des comptes de la boutique. Pourriez-vous :
– passer à notre nom [domaine, hébergement, comptes listés] ;
– créer un compte employé SuperAdmin pour [votre e-mail]. Inutile de nous envoyer le mot de passe, nous passerons par « Mot de passe oublié » ;
– créer un utilisateur SFTP à notre nom ;
– nous envoyer une sauvegarde complète et datée (fichiers et base) ?
Merci de nous dire quand c’est fait.
Cordialement, [nom, société] »

Étape 5, le préavis :
« Bonjour [prénom],
Nous mettons fin à notre contrat au [date], comme le prévoit [l’article ou la clause]. Pour la passation, pouvez-vous nous remettre d’ici le [date] : [la liste ci-dessus] ?
Merci pour le travail fait ensemble.
Cordialement, [nom, société] »

Envoyez le second comme le prévoit le contrat, en recommandé s’il le demande.

Contrat : réversibilité et propriété du code

Relisez le contrat, les conditions générales et les devis signés, avant de prévenir. Regardez surtout :

• La réversibilité : ce que le prestataire rend en fin de contrat (fichiers, base, accès, documentation), sous quel format, dans quel délai, avec quelle aide et à quel prix. Notez aussi le préavis et la forme de la résiliation.
• La propriété du code : les développements faits pour vous (module, thème, surcharges) vous sont-ils cédés, ou seulement prêtés sous licence ? Et les modules « maison » que l’agence installe chez tous ses clients ?
• Les données : un prestataire qui accède à vos fichiers clients les traite pour votre compte. Le RGPD (article 28) impose que le contrat prévoie, en fin de mission, leur suppression ou leur renvoi, selon votre choix.

Pour le code, regardez qui l’a écrit. Les droits sur un logiciel appartiennent à celui qui l’écrit ; s’il est écrit par des salariés, les droits d’exploitation reviennent à leur employeur (Code de la propriété intellectuelle, L111-1 et L113-9). Si l’agence fait écrire votre module par ses salariés, elle les détient. Ils ne passent chez vous que par un écrit (L131-2), qui doit en principe détailler chaque droit cédé (L131-3, sur Légifrance). Le paiement seul ne vaut donc pas cession. Si rien n’est écrit, demandez une cession écrite des développements spécifiques avant de partir, ou au moins une licence sans limite de durée.

PrestaShop et ses modules natifs sont libres (licences OSL 3.0 et AFL 3.0) : personne ne peut vous les retenir. Les clauses à chercher, une par une, sont détaillées dans notre page sur les clauses d’un contrat de maintenance PrestaShop.

Ce qui doit être à votre nom avant de prévenir

« À votre nom » veut dire : un compte ouvert au nom de votre société, avec une adresse e-mail que vous contrôlez, dont vous êtes administrateur. Un accès invité sur le compte de l’agence ne suffit pas, il se retire d’un clic. Pour chaque compte, un test simple montre où vous en êtes, sans demander de mot de passe à personne.

Compte	Où il se trouve	Le test qui prouve qu’il est à vous
Nom de domaine	Chez le bureau d’enregistrement (OVHcloud, Gandi, IONOS…)	Le Whois affiche votre société ; vous vous connectez à l’espace client et voyez le domaine
Hébergement	Panel de l’hébergeur	Vous vous connectez et voyez les factures à votre nom
Cloudflare	Compte Cloudflare qui porte la zone	Vous apparaissez comme Super Administrator dans les membres
PrestaShop Checkout, PayPal, Stripe	Module de paiement et compte du prestataire de paiement	Vous vous connectez au compte et voyez les dernières ventes de la boutique
Search Console	Propriété du domaine	Vous êtes propriétaire, validé avec votre propre jeton
GA4, Google Ads, Merchant Center, Tag Manager	Compte de chaque outil	Vous êtes Administrateur et pouvez ajouter un utilisateur
Modules et thème payants	Compte PrestaShop Marketplace (ex-Addons)	Les achats apparaissent sur votre compte
Compte PrestaShop	Module PrestaShop Account de la boutique	Le compte lié est celui de votre société
Boîtes mail	Google Workspace, Microsoft 365 ou offre mail de l’hébergeur	Vous êtes administrateur et pouvez réinitialiser une boîte
Envoi des e-mails	Outil d’envoi (Brevo, Mailjet, relais SMTP) et zone DNS	Vous vous connectez à l’outil ; un e-mail test arrive signé DKIM
Transporteurs, marketplaces, ERP	Contrats et comptes de chaque service	Vous vous connectez, vous connaissez les clés d’API branchées

Pour chaque compte, regardez aussi la double authentification et l’adresse ou le téléphone de secours. S’ils sont ceux du prestataire, il garde une clé : remplacez-les par les vôtres.

Le nom de domaine, avant tout le reste

Il commande la boutique, les e-mails et les vérifications Google. Le cas du domaine déposé au nom du prestataire est assez courant pour que l’AFNIC, qui gère le .fr, le décrive dans son guide pratique du titulaire : un prestataire qui « a enregistré le nom de domaine en son nom en lieu et place de son client », par simplicité.

Le titulaire est la société ou la personne inscrite dans le Whois (sur afnic.fr pour un .fr, sur lookup.icann.org pour un .com), qui indique aussi le bureau d’enregistrement. Pour une société, son nom s’affiche ; pour une personne physique, le Whois du .fr indique par défaut « Diffusion restreinte ». Si le titulaire est le prestataire, il faut un changement de titulaire : une opération à part, qui demande l’accord des deux parties.

• En .fr : le code « auth-info » vient du bureau d’enregistrement actuel. Il doit le donner gratuitement au titulaire, et à lui seul, à tout moment. Le nouveau bureau lance le transfert : sans réaction de l’ancien, il aboutit au bout de 8 jours ; en cas d’opposition, l’opération dure 22 jours, puis se réalise. S’il faut aussi changer de titulaire, l’AFNIC recommande de faire le transfert d’abord.
• En .com : le bureau d’enregistrement a 5 jours calendaires pour fournir le code. Un transfert peut être refusé dans les 60 jours qui suivent la création du domaine ou un précédent transfert. Après un changement de titulaire, le domaine est bloqué 60 jours pour les transferts, sauf si le bureau vous propose d’y renoncer.

Regardez aussi la date d’expiration. Si le domaine expire pendant la passation, la boutique et les e-mails sont coupés.

Cloudflare, si la boutique passe par lui

Avec Cloudflare, vos enregistrements DNS sont gérés chez Cloudflare, plus chez le bureau d’enregistrement. Si la zone est sur le compte de l’agence, vous avez deux voies. Soit vous vous faites inviter avec le rôle Super Administrator, le seul qui gère les membres. Soit vous déplacez la zone vers votre compte.

Le déplacement ne reprend rien d’office. Exportez les enregistrements DNS avant, retirez le DNSSEC, notez vos réglages (SSL, pare-feu, cache) pour les refaire : les certificats ne suivent pas. Tant que la zone n’est pas active sur le nouveau compte, le trafic n’est plus filtré et l’adresse IP du serveur est visible.

Le paiement : ne changez pas de compte en pleine passation

PrestaShop Checkout relie deux comptes : un compte PrestaShop et un compte PayPal. Dès que l’un des deux est déconnecté, les moyens de paiement sont désactivés jusqu’à ce que les deux soient reconnectés. Les commandes passées avant le changement se remboursent ensuite depuis l’ancien compte PayPal. PrestaShop déconseille donc de changer de compte une fois les ventes lancées (article d’aide PrestaShop).

• Compte au nom de votre société, identifiant tenu par le prestataire : reprenez l’identifiant (adresse e-mail et mot de passe changés par vous). Rien à reconnecter.
• Compte PayPal du prestataire : il ne se cède pas sans l’accord écrit de PayPal. Ouvrez un compte au nom de votre société, branchez-le à une heure creuse, et gardez l’ancien accessible le temps des remboursements.
• Stripe : le propriétaire d’un compte peut en transférer la propriété à un utilisateur Administrateur ou Super Administrateur. Faites-vous ajouter, puis demandez le transfert.
• Compte PrestaShop : la boutique est liée à un compte PrestaShop, celui qu’utilisent Checkout et les services de l’éditeur. PrestaShop prévoit de délier une boutique de son compte, par exemple quand elle change de propriétaire. Sans accès au compte lié, un formulaire permet de le demander, après vérification de votre identité.

Les comptes Google

Search Console distingue le propriétaire validé, qui a posé un jeton sur le site (fichier HTML, balise, enregistrement DNS), et le propriétaire délégué, ajouté par un autre. Validez votre propre propriété, de préférence par un enregistrement DNS que vous gérez. Puis retirez l’ancien propriétaire et supprimez ses jetons : tant qu’ils restent, il peut se revalider (aide Search Console). Avant de supprimer un jeton, vérifiez qu’il ne sert pas aussi à Merchant Center.

Dans GA4, il vous faut le rôle Administrateur sur le compte et la propriété. Dans Google Ads, le niveau d’accès Administrateur ; si votre compte est rattaché au compte administrateur de l’agence et que celui-ci en a la propriété, ses administrateurs gèrent vos accès à votre place. Une fois votre accès confirmé, dissociez-le. Dans Merchant Center, l’accès Admin. Dans Tag Manager, Administrateur du compte et Publication sur le conteneur, qui porte les balises de suivi et de conversion.

Les modules payants et le compte Addons

Cas fréquent : modules et thème achetés sur le compte Marketplace (ex-Addons) de l’agence. La plateforme a prévu le cas : un achat se transfère vers un autre compte PrestaShop, sans limite de nombre. Le destinataire récupère le téléchargement, la documentation, le support et la gestion du Business Care.

Un piège : seul le compte acheteur peut faire changer l’URL de boutique liée à la licence. Si votre domaine a changé, faites corriger l’URL avant le transfert. Une licence couvre une seule boutique de production (les installations de test sont permises). Le prix comprend 12 mois de Business Care, c’est-à-dire les mises à jour et le support du développeur ; au-delà, le module tourne toujours, mais les mises à jour passent par le renouvellement.

L’envoi des e-mails

Les e-mails de commande partent du serveur ou d’un service d’envoi. Si ce service est le compte du prestataire, il vous faut le vôtre, et une nouvelle authentification du domaine : chez Brevo, un code de vérification, une clé DKIM et un enregistrement DMARC dans la zone DNS. L’enregistrement SPF doit lister tous les expéditeurs du domaine, et il n’en faut qu’un.

Le test : Paramètres avancés > E-mail (« Emails » en 1.6), bloc « Testez votre configuration e-mail », bouton « Envoyer un e-mail test » vers une adresse Gmail. Dans Gmail, « Afficher l’original » doit indiquer SPF et DKIM en « PASS ».

Récupérer ses accès techniques, et les tester

Accès	Où il se trouve	Le test, sans envoyer de mot de passe
Back-office	Adresse de la boutique suivie du dossier d’administration (admin + caractères)	Vous vous connectez avec votre propre compte SuperAdmin
Panel de l’hébergeur	Site de l’hébergeur	Connexion, factures et services visibles
SFTP ou FTP	Panel de l’hébergeur (utilisateurs FTP)	Votre propre utilisateur ; vous voyez les dossiers modules, themes, img
SSH (s’il existe)	Panel de l’hébergeur, ou serveur dédié	Votre propre clé SSH ; la connexion s’ouvre
Base de données	phpMyAdmin (ou équivalent) dans le panel	Vous exportez la base vous-même
Sauvegarde complète	Chez l’hébergeur ou le prestataire	Restaurée sur une copie, la boutique s’ouvre
Code source	Serveur, dépôt Git	Sources lisibles, non chiffrées, dépôt cloné chez vous

Créer votre compte SuperAdmin sans qu’aucun mot de passe circule

1. Le prestataire (ou un associé déjà SuperAdmin) ouvre Paramètres avancés > Équipe > Employés (Administration > Employés en 1.6) et clique sur « Ajouter un employé ».
2. Il saisit vos Prénom, Nom et Adresse e-mail, choisit le profil SuperAdmin dans « Profil de permission » (« Rôle » en 9), laisse le compte activé, et met un mot de passe provisoire qu’il ne vous envoie pas.
3. Sur la page de connexion du back-office, vous cliquez sur « Mot de passe oublié » et choisissez le vôtre (en 1.6, un nouveau mot de passe arrive par e-mail : changez-le dès la connexion).
4. Vérifiez dans Équipe > Employés que votre ligne porte bien le profil SuperAdmin.

Le profil SuperAdmin a tous les droits et ne peut pas être supprimé ; il doit toujours rester au moins un employé qui l’a. Même règle pour le nouveau prestataire : vous créez son compte, à son adresse, et il choisit son mot de passe de la même façon. Si l’e-mail de réinitialisation n’arrive pas, lisez notre guide back-office PrestaShop inaccessible.

Exporter la base vous-même

• Depuis le back-office : Paramètres avancés > Base de données > Sauvegarde BDD (Paramètres avancés > Sauvegarde BDD en 1.6), « J’ai lu l’avertissement – Créer une sauvegarde. », puis « Télécharger le fichier de sauvegarde ». Elle ne contient que la base, pas les fichiers, et laisse de côté par défaut le contenu de quelques tables de statistiques de visite.
• Depuis phpMyAdmin : la base de la boutique, onglet Exporter, format SQL, toutes les tables. C’est la voie la plus sûre pour une grosse base.

Le fichier exporté contient les données de vos clients : gardez-le chez vous, chiffré, jamais en pièce jointe. Les identifiants de la base sont dans app/config/parameters.php (1.7 à 9) ou config/settings.inc.php (1.6). Ce fichier ne circule jamais en clair, ni par e-mail ni dans un formulaire.

Une sauvegarde qui s’ouvre

Il faut tous les fichiers (images, thème, modules, dossier override, configuration) et la base entière, faits au même moment. Les fichiers, vous pouvez les prendre vous-même : téléchargement de tout le dossier de la boutique par SFTP, ou outil de sauvegarde du panel de l’hébergeur. Une archive sans la base, sans le dossier img, ou une base sans les fichiers de configuration ne remonte pas une boutique.

La clé de cookie, dans ces mêmes fichiers de configuration, doit suivre telle quelle. En 1.6, tous les mots de passe des clients et des employés en dépendent ; de la 1.7 à la 9, les anciens mots de passe clients pas encore convertis aussi (et, en 1.7 et 8, ceux des employés).

Restaurer est un travail technique : confiez-le à votre nouveau prestataire si vous n’êtes pas à l’aise. La copie se teste hors ligne ou sur une adresse protégée par mot de passe : accueil, fiche produit, panier, back-office. Avant de l’ouvrir :

• L’adresse : une copie ouverte sur une autre adresse que celle de la boutique redirige vers la boutique en ligne, tant que l’adresse n’est pas changée dans sa base. La méthode du fichier hosts (voir la bascule) évite ce piège.
• Les e-mails : sur la copie, choisissez « Ne jamais envoyer d’e-mails (utile en phase de test) » dans Paramètres avancés > E-mail (« Emails » en 1.6), pour ne pas écrire à de vrais clients.
• Le reste : paiements en mode test ou désactivés, tâches planifiées arrêtées, flux vers l’ERP coupés.

Si la copie s’ouvre et se parcourt, la sauvegarde est bonne.

Le code source : modules maison, surcharges (overrides), thème enfant

Récupérez ce qui a été fait pour vous et n’existe nulle part ailleurs : thème sur mesure ou thème enfant, modules développés par le prestataire, surcharges du dossier /override, scripts lancés par des tâches planifiées. Demandez les sources non chiffrées, et le dépôt Git s’il existe, avec son historique. Un module chiffré ne se lit pas : sans ses sources, personne d’autre que son auteur ne pourra le corriger.

Faire l’inventaire d’une boutique PrestaShop que vous ne connaissez pas

Sur la copie restaurée, de préférence. Tout se relève depuis le back-office ou le serveur, sans rien modifier.

À relever	Où (1.7 à 9, puis 1.6)	Pourquoi
Version, PHP, MySQL	Paramètres avancés > Informations (même chemin en 1.6)	Choisir le serveur, savoir ce qui est encore maintenu
Fichiers du cœur modifiés	Même page, « Liste des fichiers modifiés »	Une modification du cœur saute à la mise à jour
Surcharges	Même page, « Liste des surcharges », depuis la 1.7.8 ; sinon le dossier /override	Elles changent le comportement du cœur
Modules	Modules > Gestionnaire de modules ; 1.6 : Modules et Services	Repérer l’auteur, la version, ceux de l’agence
Thème	Apparence > Thème et logo ; 1.6 : Préférences > Thèmes	Acheté, sur mesure ou thème enfant
Employés	Paramètres avancés > Équipe ; 1.6 : Administration > Employés	Comptes à garder ou à désactiver
Clés webservice	Paramètres avancés > Webservice ; 1.6 : Service web	ERP, marketplaces, transporteurs branchés
Tâches planifiées	Crontab du serveur, module de tâches cron	Exports et flux qui s’arrêteraient sans message d’erreur

Les surcharges sont exclusives : deux modules ne peuvent pas surcharger proprement la même chose. L’interrupteur « Désactiver toutes les surcharges » (Paramètres avancés > Performances) sert à savoir si un bug en vient. Testez-le sur la copie, jamais en production : une règle de prix ou de livraison qui en dépend cesserait de jouer.

Changer d’hébergeur sans coupure, en gardant son nom de domaine

Le domaine reste le vôtre : on déplace la boutique, puis on fait pointer le domaine vers le nouveau serveur. Dans cet ordre :

1. Ne résiliez rien. L’ancien hébergement reste payé jusqu’à la bascule validée, et quelques jours de plus.
2. Baissez le TTL des enregistrements à changer (60 à 900 secondes), au moins deux jours avant, le temps que l’ancienne valeur expire partout.
3. Copiez fichiers et base sur le nouveau serveur, avec une version de PHP compatible avec votre PrestaShop. Fichiers de configuration intacts, clé de cookie comprise : seuls les identifiants de la base changent. Prévoyez le certificat SSL avec l’hébergeur : selon sa méthode de validation, il s’installe avant la bascule ou juste après.
4. Prévenez les services qui filtrent par adresse IP (ERP, transporteurs, banque, passerelles de paiement) : la nouvelle adresse du serveur doit être autorisée chez eux avant le jour J.
5. Testez sans toucher au DNS : une ligne dans le fichier hosts de votre ordinateur fait pointer le domaine vers le nouveau serveur, pour vous seul. Parcourez la boutique, le back-office, un compte client, le tunnel de commande.
6. Le jour J, à une heure creuse : boutique en maintenance (Paramètres de la boutique > Paramètres généraux > Maintenance, « Activer boutique » sur Non, votre adresse dans « IP de maintenance » ; Préférences > Maintenance en 1.6), puis copie finale de la base : commandes, clients et paniers arrivés depuis la première copie.
7. Basculez le DNS de la boutique, et laissez l’ancienne en maintenance : pendant la propagation, certains visiteurs arrivent encore sur l’ancien serveur, et leurs commandes s’y perdraient. Si vos boîtes mail sont ailleurs, ne touchez pas aux MX. Si vous changez de serveurs DNS, recopiez d’abord toute la zone, MX et SPF compris.
8. Videz le cache (Paramètres avancés > Performances, « Vider le cache »), puis vérifiez : une vraie commande, l’e-mail de confirmation, le paiement, le certificat SSL, le back-office, les tâches planifiées. Réactivez ensuite la boutique.
9. Gardez l’ancien serveur quelques jours. Pour revenir en arrière, il suffit de remettre l’ancien enregistrement DNS. Résiliez une fois la boutique stable.

Si vous venez chez nous, notre hébergement PrestaShop inclut la migration gratuite avec l’abonnement d’hébergement, y compris pour une boutique en 1.6 ou 1.7, sur des serveurs adaptés à sa version.

Garder le référencement pendant la bascule

• Gardez le même domaine et les mêmes adresses. Ne touchez pas aux réglages d’URL simplifiées ni au fichier .htaccess pendant le déménagement : chaque page doit répondre à la même adresse qu’avant.
• Copie de test : protégez-la par un mot de passe au niveau du serveur. Ne recopiez jamais en production un robots.txt ou une balise noindex venus de la copie.
• Une maintenance courte. En mode maintenance, PrestaShop répond avec le code 503 (service indisponible). Google ralentit alors son exploration, et retire de l’index les pages qui renvoient durablement une erreur serveur (documentation Google) : quelques dizaines de minutes, pas des jours.
• Search Console ne bouge pas : un changement d’hébergeur ne touche pas la propriété.
• Après la bascule : le plan de site se génère toujours, le certificat est valide, et les erreurs 404 ou 5xx n’augmentent pas dans Search Console dans les jours qui suivent.

Ce qu’il ne faut pas couper en premier

Coupez chaque élément en dernier, quand son remplaçant fonctionne.

À garder	Jusqu’à quand
L’ancien hébergement	Quelques jours après la bascule validée
Les accès de l’ancien prestataire	La sauvegarde restaurée, l’inventaire fait, la date de fin passée : s’il a écrit un module, c’est lui qui sait pourquoi il plante
L’ancien compte PayPal ou de paiement	Au moins 180 jours après la dernière vente encaissée : c’est le délai de remboursement PayPal, et une réclamation pour paiement non autorisé peut arriver jusqu’à 13 mois après
L’ancien outil d’envoi d’e-mails	Le nouveau authentifié et l’e-mail test reçu signé DKIM
L’ancienne zone Cloudflare et ses enregistrements	La nouvelle zone active
Les anciens jetons Search Console	Votre propriété validée
Les flux et tâches planifiées	Leur remplaçant en place sur le nouveau serveur
Le compte Marketplace de l’agence	Le transfert des achats accepté sur votre compte

Après la passation : fermer les accès de l’ancien prestataire

Dernière étape pour changer de prestataire PrestaShop : une fois la bascule validée et la date de fin passée, fermez ce qu’il pouvait ouvrir. Désactiver un employé lui coupe l’accès, même s’il était connecté ; vous le supprimerez plus tard.

• Ses comptes employés (Paramètres avancés > Équipe) et, en 8 et 9, ses sessions dans Paramètres avancés > Sécurité > Sessions employés.
• Votre mot de passe SuperAdmin, ceux du panel, du SFTP et de la base (fichier de configuration mis à jour dans la foulée).
• Ses utilisateurs FTP et les clés SSH ajoutées pour lui sur le serveur.
• Les clés webservice qu’il connaissait, régénérées après avoir prévenu les outils qui s’en servent ; de même pour les clés d’API de paiement, de transport et d’envoi d’e-mails, si elles ont circulé.
• Ses accès Cloudflare, Google (Search Console avec ses jetons, GA4, Ads, Merchant Center, Tag Manager) et au panel de l’hébergeur.
• Les tâches planifiées qui appellent ses serveurs, et ses outils de supervision installés sur la boutique.

Si l’ancien prestataire ne répond pas ou retient des accès

Commencez par une demande écrite et datée, avec la liste précise de ce que vous attendez, puis une relance, puis une lettre recommandée avec accusé de réception. En parallèle, beaucoup de choses se récupèrent sans lui :

Ce qui bloque	Ce que vous pouvez faire
Le domaine, vous êtes titulaire	Demandez le code de transfert directement au bureau d’enregistrement : il le doit au titulaire.
Le domaine, le prestataire est titulaire	Changement de titulaire par écrit. Pour un .fr, l’AFNIC propose aussi des procédures extrajudiciaires (SYRELI, PARL Expert) qui peuvent mener à la récupération d’un nom dans les cas prévus par la loi : un avocat dira si le vôtre en relève.
L’hébergement est à votre nom	Le support de l’hébergeur peut rétablir l’accès du titulaire du contrat, sur justificatifs.
Le back-office, avec un accès à l’hébergement	« Mot de passe oublié » si votre adresse a un compte ; sinon les méthodes de notre guide mot de passe admin refusé, base exportée avant.
La boutique est sur le serveur de l’agence, sans contrat à votre nom	Si vous avez encore un compte SuperAdmin, exportez la base depuis le back-office (Sauvegarde BDD) : produits, clients et commandes y sont. Puis recommandé pour les fichiers.
Le compte PrestaShop lié à la boutique	Le formulaire de PrestaShop pour délier la boutique, avec vérification de votre identité.
Search Console	Vous contrôlez le domaine : validez-vous par un enregistrement DNS, puis retirez les autres.
PayPal, Stripe	Si le compte est au nom de votre société, adressez-vous à leur support en tant que titulaire.
Les modules Marketplace	Demandez le transfert de produit. Pour un module indispensable, le racheter sur votre compte va souvent plus vite qu’un litige.
Le code et la sauvegarde	Avec l’accès à l’hébergement, vous les prenez vous-même. Sinon : lettre recommandée, puis avocat.

Les erreurs à éviter pendant la passation

• Régénérer la clé de cookie ou réinstaller PrestaShop « pour repartir propre ». Des mots de passe deviennent faux, des réglages disparaissent. Gardez les fichiers de configuration tels quels.
• Désinstaller les modules de l’agence ou vider le dossier override sans inventaire. Une fonction dont vous ignoriez l’origine s’arrête ; testez sur la copie.
• Monter de version pendant le déménagement. Avec deux changements à la fois, une panne a deux causes possibles : faites-le une fois la boutique stable.
• Envoyer des mots de passe par e-mail, à l’ancien comme au nouveau prestataire : un compte employé par personne suffit, et vous le fermez quand vous voulez.

La checklist à imprimer

Imprimez cette section, cochez au stylo, datez chaque ligne et notez qui l’a vérifiée.

1. Avant de prévenir : contrat et comptes

• Contrat relu : préavis, réversibilité, propriété du code, données. Factures réglées.
• Domaine : titulaire, accès à l’espace client, date d’expiration.
• Hébergement : contrat, facturation et panel à votre nom.
• Cloudflare : zone sur votre compte ou rôle Super Administrator.
• PrestaShop Checkout, PayPal, Stripe : comptes de votre société.
• Search Console (votre jeton), GA4, Google Ads, Merchant Center, Tag Manager : Administrateur.
• Modules et thème payants sur votre compte Marketplace, URL de licence à jour.
• Compte PrestaShop lié à la boutique : celui de votre société.
• Boîtes mail : vous êtes administrateur.
• Outil d’envoi d’e-mails à votre nom, e-mail test signé DKIM.
• Double authentification, e-mail et téléphone de secours : les vôtres, sur chaque compte.
• Transporteurs, marketplaces, ERP : comptes et clés d’API connus.

2. Accès et sauvegarde

• Compte employé SuperAdmin à votre nom, mot de passe choisi par vous.
• Panel, SFTP, SSH : vos propres identifiants, connexion testée.
• Base exportée par vous (back-office ou phpMyAdmin).
• Sauvegarde complète datée : fichiers et base du même moment.
• Restauration testée sur une copie protégée, e-mails et paiements coupés sur la copie.
• Sources du thème, des modules maison, du dossier override ; dépôt Git.

3. Inventaire et passation

• Version de PrestaShop, PHP, MySQL.
• Fichiers du cœur modifiés, surcharges.
• Modules : auteur, version, licence.
• Employés, clés webservice, tâches planifiées.
• Page « ce qu’il faut savoir » remise par le prestataire.
• Date de fin fixée, état de ce qui a été rendu signé et daté, suppression des copies de données confirmée.

4. Bascule (si l’hébergement change)

• TTL baissé deux jours avant ; nouvelle IP autorisée chez l’ERP, les transporteurs, la banque.
• Certificat SSL prévu avec l’hébergeur (avant ou juste après la bascule), copie testée par le fichier hosts.
• Copie de test protégée, sans noindex ni robots.txt recopié en production.
• Heure creuse, mode maintenance court, copie finale de la base.
• DNS basculé, ancienne boutique laissée en maintenance, MX et SPF vérifiés.
• Cache vidé ; commande, e-mail, paiement, SSL, tâches planifiées vérifiés ; boutique réactivée.
• Search Console surveillée les jours suivants ; ancien serveur gardé, puis résilié.

5. Après : fermer les accès

• Employés et sessions de l’ancien prestataire désactivés.
• Mots de passe changés : back-office, panel, SFTP, base.
• Utilisateurs FTP et clés SSH retirés.
• Clés webservice et d’API régénérées.
• Membres Cloudflare et utilisateurs Google retirés, anciens jetons Search Console supprimés.
• Ancien compte PayPal gardé au moins 180 jours, ancien outil d’envoi fermé une fois le nouveau validé.

Questions fréquentes sur le changement de prestataire PrestaShop

Comment récupérer son site PrestaShop auprès de son ancien prestataire ?

Pour récupérer vos accès dans l’ordre : le domaine et les comptes à votre nom, un compte SuperAdmin personnel, les accès serveur et base, une sauvegarde complète restaurée sur une copie, les sources du code spécifique. Ensuite seulement, prévenez et fixez la date de fin.

Mon prestataire ne me donne pas le code de transfert du domaine : que faire ?

En .fr, le code « auth-info » est donné par le bureau d’enregistrement, gratuitement, au titulaire. Si vous êtes titulaire, demandez-le-lui directement. Si le titulaire est le prestataire, demandez-lui par écrit de lancer le transfert, puis le changement de titulaire, qui demande son accord.

Comment donner accès au back-office sans envoyer de mot de passe ?

Créez un employé à l’adresse de la personne (Paramètres avancés > Équipe, « Ajouter un employé »), avec le profil adapté et un mot de passe provisoire que vous ne transmettez pas. Elle choisit le sien par « Mot de passe oublié » sur la page de connexion.

À qui appartient le code de ma boutique PrestaShop ?

PrestaShop et ses modules natifs sont libres. Sur la propriété du code écrit pour vous, en principe, les droits ne vous sont transférés que par un écrit qui les détaille : le paiement seul ne suffit pas. Relisez le contrat ; en cas de désaccord, consultez un avocat.

Que doit me restituer mon ancien prestataire ?

Ce que prévoit la clause de réversibilité : en général les fichiers, la base, les accès et la documentation. Le RGPD lui impose aussi de supprimer ou de vous renvoyer vos données clients en fin de mission, selon votre choix.

Peut-on changer d’hébergeur en gardant son nom de domaine et son référencement ?

Oui. On copie la boutique sur le nouveau serveur, on la teste par le fichier hosts, puis on change seulement l’enregistrement DNS. Mêmes adresses de pages, mode maintenance court, copie de test non indexée : Google ne voit qu’une courte indisponibilité.

Faut-il changer de compte PayPal ou PrestaShop Checkout en changeant de prestataire ?

Seulement s’ils ne sont pas à votre société. Changer l’un des deux comptes désactive les moyens de paiement jusqu’à la reconnexion, et les anciennes commandes se remboursent depuis l’ancien PayPal. Faites-le à une heure creuse, ou reprenez simplement l’identifiant.

Combien coûte la reprise d’une boutique PrestaShop chez CYBERIAL ?

La maintenance est à 69 € HT/mois, sans engagement, avec un audit complet offert au démarrage. La migration vers notre hébergement est gratuite avec un abonnement d’hébergement. Si quelque chose est déjà cassé, le dépannage démarre à 150 € HT, prix fixe validé avant toute intervention, et ces 150 € sont déduits si vous passez ensuite à la maintenance.

Vous préférez nous confier la reprise de votre boutique PrestaShop ?

Donnez-nous l’adresse de la boutique (celle que voient vos clients) et choisissez « Changement de prestataire ». Dites en une ligne où vous en êtes : prestataire déjà prévenu ou non (pas encore, c’est mieux), hébergeur conservé ou non. N’écrivez aucun mot de passe : nous vous dirons quel compte employé créer pour nous. La maintenance démarre par l’audit complet offert. Réponse en moins d’une heure, 7j/7, de 8 h à 22 h.

Pour aller plus vite, appelez le 09 72 03 59 17 (7j/7, de 8 h à 22 h). La maintenance à 69 € HT/mois est sans engagement : vous restez libre de partir. Les mises à jour y sont testées sur une copie, avec sauvegarde et retour arrière.