Skip to main content
Une responsable d’entreprise supervise le transfert organisé d’un site web, de ses données, accès et services connectés entre un ancien et un nouveau prestataire, avec une copie testée avant la mise en production.

Le kit de réversibilité numérique avant de changer de prestataire web

Changer de prestataire web peut sembler simple tant que le site reste accessible. La difficulté apparaît lorsque l’entreprise doit récupérer un compte, restaurer une sauvegarde, modifier un réglage DNS ou faire fonctionner un formulaire sans l’aide de l’ancien intervenant.

La réversibilité consiste à préparer cette reprise avant qu’elle ne devienne urgente. Elle concerne les accès, le nom de domaine, l’hébergement, le site, les données, les outils connectés, la documentation et l’organisation de la transition. Une clause contractuelle peut cadrer les responsabilités, mais elle ne remplace ni l’inventaire ni les tests.

Cette checklist vous aide à organiser la reprise en trois temps : avant le changement, pendant la transition et après la bascule.

1. Définir précisément ce qui doit être repris

Commencez par décrire le périmètre de la reprise. « Le site » ne désigne pas uniquement ses pages visibles. Il peut dépendre de comptes, de bases de données, de services d’envoi d’e-mails, de règles DNS ou d’outils de mesure.

Le périmètre minimal à inventorier

  • Nom de domaine et DNS : registrar, contacts du compte, zone DNS, sous-domaines et éventuels enregistrements liés à la messagerie ou à des services externes.
  • Hébergement : fournisseur, serveur ou offre utilisée, environnement de production, espaces de préproduction et accès techniques.
  • Site : fichiers, code source lorsqu’il est spécifique, thème, extensions, médias, contenus, formulaires et réglages.
  • CMS : version, extensions ou modules, comptes administrateurs, configuration et éventuelles personnalisations.
  • Données : base de données, fichiers importés, contenus éditoriaux, commandes ou demandes reçues selon le type de site.
  • Messagerie : boîtes liées au domaine, service SMTP, routage et paramètres nécessaires à l’envoi des messages du site.
  • Services tiers : analytics, Search Console, CDN, outils publicitaires, paiement, CRM, réservation, automatisations et solutions de consentement.
  • Éléments SEO et fonctionnels : URLs, redirections, réglages d’indexation, balises gérées par le CMS, formulaires, suivi des conversions et parcours importants.
  • Licences et droits d’utilisation : thèmes, extensions, polices, images, composants ou services sous abonnement. Leur transfert dépend du contrat, de la licence et du titulaire du compte.

Pour chaque élément, indiquez le propriétaire du compte, le prestataire qui l’administre, le responsable interne, la méthode de récupération et la preuve disponible. Si vous ne savez pas qui peut agir ou où se trouve une sauvegarde, le risque n’est pas encore maîtrisé.

2. Avant le changement : sécuriser les accès et les responsabilités

Vérifier que l’entreprise possède réellement les comptes

Un compte utilisé par votre entreprise n’est pas nécessairement un compte dont elle maîtrise la récupération. Vérifiez que les comptes essentiels sont ouverts avec une adresse professionnelle contrôlée par l’entreprise, et non avec l’adresse personnelle d’un ancien salarié ou celle du prestataire.

Contrôlez également les moyens de récupération : adresse secondaire, numéro de téléphone, application d’authentification et codes de secours lorsque le service en propose. Ces éléments varient selon le fournisseur. Ne désactivez pas un dispositif de sécurité sans avoir préparé son remplacement.

Checklist des accès indispensables

Accès ou compte Contrôle à effectuer Preuve attendue
Registrar du nom de domaine Identifier le titulaire du compte, le contact administratif et les moyens de récupération. Nom du compte, adresse contrôlée par l’entreprise et procédure de récupération testée ou documentée.
Hébergement Vérifier l’accès au compte client et, si nécessaire, aux accès techniques du serveur. Connexion réalisée par une personne de l’entreprise et offre ou environnement identifié.
DNS Identifier où la zone DNS est administrée et qui peut la modifier. Export ou copie lisible de la zone, avec la date de collecte et l’emplacement du compte.
Administration du CMS Vérifier qu’au moins un compte administrateur contrôlé par l’entreprise existe. Connexion testée et liste des comptes administrateurs conservée.
FTP ou SFTP Identifier les accès aux fichiers et leurs droits, lorsque ce mode d’accès est utilisé. Accès testé ou confirmation documentée qu’un autre mode d’accès est prévu.
Base de données Identifier le moteur, le compte technique et le mode d’accès autorisé. Export exploitable ou procédure d’export validée, sans exposer les mots de passe dans un document partagé.
Analytics et Search Console Vérifier la propriété ou les droits d’administration et la continuité de l’historique. Compte de l’entreprise présent dans les utilisateurs ou propriétaires du service.
Messagerie et SMTP Identifier les comptes et le service utilisés par le site pour envoyer des messages. Message de test reçu et configuration recensée.
CDN, paiement, publicité et outils externes Recenser les comptes, les propriétaires, les clés utilisées et les dépendances. Liste des services, responsable de chaque compte et test du parcours concerné.

Ne demandez pas que des mots de passe soient copiés dans un fichier non protégé. Préférez la création de comptes nominatifs, l’usage d’un gestionnaire de mots de passe adapté et la rotation des secrets lorsque cela est nécessaire.

Pour la partie consacrée au domaine, vous pouvez compléter cette démarche avec le contenu Récupérer son nom de domaine. Ici, le domaine doit rester traité comme un élément du plan global : il est lié au DNS, à la messagerie, aux certificats et parfois à plusieurs services externes.

3. Récupérer un périmètre technique exploitable

Une archive de fichiers ne suffit pas toujours à reconstruire un site. Demandez une livraison qui permette à un autre intervenant de comprendre, tester et exploiter l’environnement.

Les éléments à demander

  • une copie des fichiers du site et, lorsque cela s’applique, du code source spécifique ;
  • un export de la base de données accompagné de son périmètre et de sa date ;
  • les médias et fichiers importés qui ne sont pas inclus dans l’export principal ;
  • la liste des versions du CMS, du langage, du serveur, du thème et des extensions ;
  • la liste des extensions, thèmes ou composants sous licence, avec leur titulaire et leurs conditions de renouvellement ;
  • la configuration utile : tâches planifiées, variables d’environnement, redirections, certificats, règles du serveur, réglages DNS et connexions aux services tiers ;
  • la liste des environnements existants : production, recette, développement ou sauvegarde ;
  • les procédures connues pour déployer, restaurer, modifier les DNS et renouveler les éléments qui arrivent à échéance.

Les informations sensibles ne doivent pas être transmises en clair dans un document ordinaire. La livraison peut décrire où elles sont stockées et comment les remplacer, puis prévoir un échange sécurisé séparé.

Identifier les dépendances oubliées

Demandez ce qui se passe lorsqu’un utilisateur remplit un formulaire, reçoit un e-mail, paie une commande ou demande un rendez-vous. Cette approche par parcours fait souvent apparaître des services absents de l’inventaire initial.

  • Le formulaire envoie-t-il les données vers une adresse, un SMTP, un CRM ou un outil d’automatisation ?
  • Le paiement dépend-il d’un compte distinct du site ?
  • Les images, vidéos ou fichiers sont-ils stockés sur un autre service ?
  • Le suivi des conversions repose-t-il sur une balise, un gestionnaire de tags ou une plateforme publicitaire ?
  • Le domaine sert-il aussi à la messagerie, à un extranet ou à des sous-domaines ?
  • Un CDN, un pare-feu applicatif ou un service de consentement modifie-t-il le fonctionnement ou l’accès au site ?

Pour chaque dépendance, conservez le nom du service, son objectif, le compte propriétaire, la personne responsable, la donnée échangée et le test permettant de vérifier son fonctionnement.

4. Sauvegarder ne suffit pas : tester la restauration

Une sauvegarde utile est une sauvegarde dont le périmètre est connu et dont la restauration a été vérifiée. La présence d’un fichier d’archive ne prouve pas qu’il permet de remettre le site en service.

Le contrôle en quatre étapes

  1. Décrire la sauvegarde : notez sa date, les fichiers inclus, la base couverte, les éventuels éléments exclus et l’emplacement de stockage.
  2. Conserver une copie indépendante : assurez-vous qu’elle reste accessible à l’entreprise et qu’elle ne dépend pas uniquement d’un compte géré par l’ancien prestataire.
  3. Restaurer sur un environnement de test : utilisez un environnement séparé de la production et évitez d’exposer des données sensibles sans précaution adaptée.
  4. Vérifier le résultat : ouvrez le site, connectez-vous au CMS, consultez des contenus, testez un formulaire et contrôlez la cohérence des données.

Le livrable attendu est un compte rendu de restauration : sauvegarde utilisée, environnement cible, date du test, opérations réalisées, anomalies rencontrées et décision de validation. Les étapes exactes dépendent du CMS, de l’hébergeur et de l’architecture ; elles doivent être testées dans le contexte réel.

La sauvegarde ne remplace pas les mises à jour et les contrôles de sécurité. Avant la bascule, identifiez les versions obsolètes, les comptes inutiles et les extensions non nécessaires, sans lancer de modification risquée directement en production. Pour approfondir ce point sans refaire un guide général de maintenance, consultez Mettre à jour son CMS pour éviter les piratages ?.

5. Préserver le fonctionnement, le SEO et les données

Avant le transfert, établissez une liste de référence du site actuel. Elle servira à comparer la situation avant et après la bascule.

Les contrôles à documenter

  • URLs : pages importantes, URLs de fichiers, sous-domaines et règles de redirection connues.
  • Indexation : réglages importants du CMS, fichier robots lorsqu’il est utilisé, sitemap et balises gérées par la configuration du site.
  • Formulaires : réception, adresse de destination, message de confirmation, pièces jointes et connexion éventuelle à un outil tiers.
  • E-mails transactionnels : adresse d’envoi, délivrabilité observée, modèles et événements qui déclenchent l’envoi.
  • Parcours critiques : achat, demande de devis, inscription, réservation, téléchargement ou prise de contact selon l’activité.
  • Suivi : visites, événements, conversions et attribution lorsqu’ils sont utilisés par l’équipe marketing.
  • Contenus : pages, médias, comptes utilisateurs, données métier et éléments qui doivent rester inchangés.

Ne supposez pas qu’un changement d’hébergement préservera automatiquement ces éléments. Un réglage peut être stocké dans le CMS, le serveur, le DNS ou un outil tiers. La preuve attendue est une fiche de référence datée, accompagnée de captures ou de résultats de test lorsque cela facilite la comparaison.

6. Organiser la transition et la bascule

La transition doit avoir un responsable côté entreprise, même si plusieurs prestataires interviennent. Ce responsable ne réalise pas nécessairement les opérations techniques ; il s’assure que les actions sont attribuées, vérifiées et documentées.

Ordre recommandé des opérations

  1. Inventaire : recenser actifs, comptes, données, services, versions et responsabilités.
  2. Sécurisation : créer ou vérifier les comptes de l’entreprise, les moyens de récupération et les accès nominatifs.
  3. Export : récupérer fichiers, base, médias, configurations, documentation et sauvegardes.
  4. Environnement de recette : installer ou restaurer une copie et vérifier les parcours critiques.
  5. Préparation de la bascule : définir la date, les personnes disponibles, les changements prévus et le plan de retour arrière.
  6. Transfert ou mise en production : appliquer les opérations validées en limitant les changements simultanés non documentés.
  7. Tests : comparer le site avec la fiche de référence et corriger les écarts bloquants.
  8. Surveillance : suivre les accès, les formulaires, les e-mails, les erreurs, le trafic et les conversions pendant une période définie par les parties.

Prévoir un retour arrière

Le retour arrière ne doit pas être une formule générale. Décrivez le déclencheur, la personne qui décide, la sauvegarde de référence, les étapes techniques, les opérations DNS éventuelles et le moyen de confirmer que l’ancien environnement reste disponible.

Ne supprimez pas immédiatement l’ancien environnement ou les anciens accès. Leur conservation temporaire peut faciliter une comparaison ou un retour, mais sa durée, son coût et les conditions de maintien doivent être convenus. La décision finale doit être documentée.

7. Formaliser les engagements sans confondre contrat et exécution

Le contrat ou le plan de réversibilité peut préciser le périmètre, les formats de livraison, les responsabilités, les délais convenus entre les parties, l’assistance de transition, les coûts éventuels et les critères de validation. Les conséquences juridiques dépendent notamment du contrat, des données concernées et du contexte ; faites vérifier les clauses applicables lorsque l’enjeu le justifie.

Une clause seule ne garantit pas qu’un transfert sera réalisable. Pour être opérationnelle, elle doit être reliée à des éléments vérifiables :

  • un inventaire maintenu à jour ;
  • des comptes contrôlés par l’entreprise ;
  • des formats d’export identifiés ;
  • une procédure de restauration testée ;
  • un responsable nommé pour chaque étape ;
  • un calendrier et des conditions de validation ;
  • une assistance prévue en cas de difficulté ;
  • une procédure de révocation et de remplacement des accès.

Les droits sur le code, les contenus, les licences, les thèmes, les extensions et les comptes tiers doivent également être vérifiés dans les documents applicables. Ne les présumez pas acquis simplement parce que l’entreprise a financé la création du site.

8. Après la bascule : valider puis révoquer

Checklist de validation

Zone Test Preuve attendue
Accès Se connecter au registrar, à l’hébergement, au CMS et aux outils essentiels avec les comptes de l’entreprise. Liste des accès validés, date du test et anomalies ouvertes.
Site public Ouvrir les pages principales sur les appareils ou navigateurs utiles à l’activité. Compte rendu de recette et liste des corrections.
Formulaires Envoyer une demande et vérifier sa réception, son traitement et les éventuelles notifications. Message de test identifié et résultat observé.
E-mails Tester les messages envoyés par le site et vérifier les adresses de destination. Copies ou identifiants des tests, sans conserver inutilement de données personnelles.
Parcours métier Tester achat, réservation, inscription, devis ou téléchargement selon le site. Scénarios exécutés et validation du responsable métier.
SEO Contrôler les URLs importantes, redirections, indexation configurée et suivi. Comparaison avec l’état de référence et signalement des écarts.
Sauvegardes Vérifier que les nouvelles sauvegardes sont planifiées et accessibles. Configuration documentée et, si possible, nouveau test de restauration planifié.
Sécurité Contrôler les comptes administrateurs, les accès temporaires, les versions et les secrets à remplacer. Liste des comptes conservés, supprimés ou modifiés.

Révoquer les anciens accès au bon moment

Une fois la validation obtenue et le besoin d’assistance clarifié, supprimez les comptes inutiles, retirez les droits excessifs et remplacez les mots de passe ou clés qui ont été partagés pendant la transition. Vérifiez aussi les accès aux outils tiers, aux boîtes e-mail, au serveur, au DNS et au gestionnaire de mots de passe.

Conservez une trace de ce qui a été révoqué, par qui et à quelle date. Si un ancien prestataire doit encore intervenir pendant une période de support, donnez-lui un accès limité, nominatif et temporaire lorsque le service le permet.

La checklist synthétique à remettre au responsable de la transition

  • Avant : périmètre inventorié, comptes de l’entreprise vérifiés, accès de récupération contrôlés, fichiers et données exportés, dépendances recensées, versions documentées, sauvegarde restaurée sur un environnement de test et responsabilités attribuées.
  • Pendant : environnement de recette validé, date et ordre de bascule confirmés, plan de retour arrière disponible, personne décisionnaire identifiée et preuves de chaque contrôle conservées.
  • Après : site et parcours critiques testés, e-mails et formulaires vérifiés, URLs et suivi comparés, sauvegardes opérationnelles, nouveaux accès validés et anciens accès révoqués.

Si l’entreprise ne peut pas produire ces preuves, elle ne dispose pas encore d’une réversibilité réellement testée. Un accompagnement peut alors porter sur l’inventaire, la récupération des comptes, la documentation, la restauration de sauvegarde, la préparation de recette ou la sécurisation de la bascule. Le périmètre doit être défini selon la technologie utilisée, les services connectés et les responsabilités de chaque partie.

Cette page est générée par le template Breakdance