Hébergement, domaine et accès : checklist avant reprise de site

La reprise d’un site internet existant ne commence pas par une modification de design ou une nouvelle page. Elle commence par une question plus simple : l’entreprise possède-t-elle réellement les accès et les éléments nécessaires pour administrer, sauvegarder et déplacer son site ?

Le nom de domaine, l’hébergement, la base de données et les emails peuvent être répartis entre plusieurs fournisseurs. Le CMS peut rester accessible alors que personne ne connaît le compte du serveur, tandis que les formulaires ou les statistiques dépendent encore d’identifiants appartenant à l’ancien prestataire.

Une reprise engagée sans inventaire crée rapidement des surprises. Le nouveau site fonctionne sur son environnement de test, puis la messagerie s’interrompt après un changement DNS, une extension payante cesse de recevoir ses mises à jour ou une partie des demandes continue d’arriver dans un compte inaccessible.

Cette checklist doit donc être utilisée comme un cadre de vérification, et non comme une succession mécanique d’actions. Avant toute reprise ou refonte de site internet, elle permet de comprendre ce qui existe, ce qui appartient à l’entreprise et ce qui doit être sécurisé avant la transition.

Lorsqu’un nouveau prestataire intervient sur un site existant, il hérite d’une architecture, de comptes et de choix techniques qu’il n’a pas créés. Même un site vitrine apparemment simple peut dépendre d’un hébergement, d’une base, d’un service d’envoi d’emails, d’un outil de formulaires et de plusieurs comptes Google.

Sans inventaire, le nouvel intervenant travaille avec une vision incomplète. Il peut modifier une page dans WordPress sans savoir comment restaurer le site si la mise à jour échoue, ou préparer une migration sans connaître les services reliés au domaine.

La récupération des accès permet aussi de distinguer l’administration éditoriale de la maîtrise technique. Disposer d’un compte WordPress ne signifie pas que l’entreprise peut déplacer le site, renouveler son domaine ou récupérer sa base de données.

Cette préparation protège enfin la continuité commerciale. Les formulaires, adresses email et outils de mesure doivent rester fonctionnels pendant la reprise, même lorsque l’hébergement ou le prestataire change.

Le nom de domaine constitue l’adresse publique du site et l’un de ses actifs les plus sensibles. Sa perte ou son expiration peut rendre le site inaccessible, interrompre les emails et compliquer la récupération de plusieurs comptes professionnels.

Il faut commencer par identifier le registrar, c’est-à-dire le fournisseur auprès duquel le domaine est enregistré. Celui-ci peut être différent de l’hébergeur, même lorsque l’ancien prestataire regroupait toutes les prestations sur une seule facture.

Le compte doit permettre de vérifier le titulaire déclaré, l’adresse de contact, le renouvellement automatique et le moyen de paiement. L’entreprise doit idéalement apparaître comme propriétaire du domaine et conserver un accès administrateur indépendant de celui du prestataire.

Les DNS doivent être sauvegardés avant toute modification. Ils indiquent notamment où se trouvent le site, les emails et certains services de validation ou de sécurité. Une simple capture ne suffit pas toujours : il est préférable de conserver la liste complète des enregistrements avec leurs valeurs.

Vérifications essentielles sur le domaine

Le domaine doit être actif, renouvelé et non bloqué par un litige ou une procédure en cours. L’adresse utilisée pour récupérer le compte doit être accessible à l’entreprise, sans dépendre d’une boîte gérée par l’ancien prestataire.

Il faut également vérifier si le domaine est verrouillé contre les transferts et si un code d’autorisation peut être obtenu. Ce code n’est nécessaire que si l’entreprise souhaite changer de registrar ; il ne sert pas à modifier l’hébergement du site.

Le transfert du domaine et la migration du site peuvent donc être réalisés séparément. Cette distinction réduit les risques en évitant de modifier plusieurs éléments critiques au même moment.

L’hébergement contient les ressources nécessaires au fonctionnement du site. Selon le projet, il peut s’agir d’un hébergement mutualisé, d’un serveur privé, d’une plateforme propriétaire ou d’un service spécialisé dans WordPress.

Le compte doit donner accès aux fichiers, aux bases de données, aux certificats et aux sauvegardes. Il doit également permettre de consulter les versions utilisées, l’espace disponible et les éventuelles tâches planifiées.

Pour un site construit avec un CMS, les fichiers seuls ne suffisent pas. Les pages, réglages, utilisateurs et réponses de formulaires sont généralement conservés dans une base de données qui doit être sauvegardée en même temps.

Une archive complète doit pouvoir être restaurée dans un environnement séparé. Ce test révèle les fichiers manquants, les dépendances inconnues et les configurations liées à l’ancien serveur.

Examiner les fichiers et le code source

Le nouveau prestataire doit identifier le thème, les extensions et les éventuels développements spécifiques. Les modifications réalisées directement dans un thème ou une extension peuvent disparaître lors d’une mise à jour si elles n’ont pas été correctement isolées.

Pour un site développé sur mesure, il faut rechercher l’existence d’un dépôt Git. Celui-ci conserve l’historique du code et constitue généralement une base plus fiable qu’une simple copie téléchargée depuis le serveur.

Le dépôt doit appartenir à l’entreprise ou lui être transféré avec des droits administratifs. Si aucune gestion de versions n’existe, l’état récupéré sur le serveur peut être sauvegardé puis placé dans un nouveau dépôt après vérification.

Contrôler les sauvegardes

Le fait qu’une interface affiche la mention « sauvegarde quotidienne » ne garantit pas qu’une restauration complète soit possible. Il faut connaître les éléments couverts, la durée de conservation et l’emplacement réel des copies.

Une bonne sauvegarde inclut au minimum les fichiers et la base. Les contenus stockés ailleurs, comme certains médias ou formulaires externes, doivent être protégés séparément.

Le test de restauration confirme que la sauvegarde est lisible et permet d’estimer le temps nécessaire pour remettre le site en ligne. Sans ce test, l’entreprise ne dispose que d’une promesse technique difficile à vérifier.

Un compte administrateur sur WordPress ou sur un autre CMS est indispensable pour gérer les contenus, les menus et les réglages courants. Il ne remplace cependant pas l’accès à l’hébergement, nécessaire pour intervenir en cas de panne ou pour déplacer le site.

L’entreprise doit posséder son propre compte administrateur, associé à une adresse qu’elle contrôle. Les comptes partagés doivent être évités, car ils empêchent de savoir qui a réalisé une modification et compliquent la révocation des anciens accès.

Les utilisateurs existants doivent être examinés avant la reprise. Les comptes inutilisés, inconnus ou liés à d’anciens prestataires pourront être supprimés après la sécurisation du nouvel environnement.

Il faut également contrôler les rôles. Une personne chargée de publier des articles n’a pas besoin de pouvoir installer des extensions ou modifier la configuration générale du site.

Inventorier les thèmes et extensions payantes

De nombreux sites utilisent des licences pour leur thème, leur constructeur de pages, leurs formulaires, leur sécurité ou leur optimisation.

Certaines licences ont été achetées pour le client, tandis que d’autres appartiennent à l’agence et couvrent plusieurs sites. Dans ce second cas, elles peuvent cesser d’être actives lorsque la relation prend fin.

Le nouvel intervenant doit identifier ce qui reste utilisable, ce qui doit être renouvelé et ce qui devrait être remplacé. Cette vérification influence directement le coût de la maintenance et la capacité à appliquer les prochaines mises à jour.

Une extension non renouvelée peut continuer à fonctionner pendant un certain temps, mais elle devient progressivement plus difficile à maintenir. Le risque doit être expliqué avant qu’un incident ou une incompatibilité impose une intervention urgente.

Le domaine du site est souvent utilisé pour les adresses professionnelles, mais les emails peuvent être hébergés chez un fournisseur complètement différent. Le changement d’hébergement web ne doit donc pas entraîner automatiquement une migration de la messagerie.

Avant toute modification DNS, il faut identifier les enregistrements liés aux emails et vérifier qui administre les boîtes. Les paramètres de validation des envois doivent également être conservés pour éviter une dégradation de la délivrabilité.

Les formulaires du site demandent une vérification complète. Il ne suffit pas de constater qu’un message de confirmation apparaît à l’écran : il faut s’assurer que la demande arrive réellement chez le bon destinataire et qu’elle reste accessible en cas d’échec de l’email.

Certains formulaires enregistrent les réponses dans le CMS, d’autres les transmettent à une plateforme ou à un CRM. Ces destinations doivent être documentées avant la reprise afin d’éviter qu’une partie des prospects continue d’être envoyée vers un ancien compte.

Les réservations, paiements et outils de devis sont soumis à la même logique. Le nouveau prestataire doit identifier les comptes, les clés et les notifications qui permettent au site de communiquer avec ces services.

Une reprise technique ne doit pas faire perdre plusieurs années de données de trafic et de référencement. Les propriétés existantes doivent être transférées ou partagées plutôt que remplacées sans raison.

L’entreprise doit disposer d’un accès administrateur à Google Analytics, Search Console et Tag Manager lorsqu’ils sont utilisés. Les outils publicitaires, fiches établissement et plateformes de suivi SEO doivent également être intégrés à l’inventaire.

Cette récupération permet d’établir une situation de référence avant la migration. Les principales pages, leurs clics et leurs positions peuvent être comparés après le changement d’environnement.

Les balises de mesure doivent être testées sur le nouveau site. Une migration peut provoquer un double comptage lorsque l’ancien et le nouveau script fonctionnent simultanément, ou au contraire une rupture complète si une configuration n’a pas été reprise.

Les URL indexées, les redirections existantes et les métadonnées importantes doivent également être sauvegardées. L’article sur la mise en ligne d’un site web et ses vérifications couvre le lancement d’une nouvelle version ; lors d’une reprise, ces contrôles doivent être complétés par une comparaison avec l’historique du site existant.

Un inventaire révèle fréquemment des comptes inconnus ou des identifiants introuvables. Cette situation ne signifie pas que le site doit être immédiatement reconstruit.

Les factures, relevés bancaires et anciens emails permettent souvent d’identifier les fournisseurs. Le domaine et ses DNS apportent aussi des informations sur l’hébergement, la messagerie et les services utilisés.

Lorsque le compte est enregistré au nom de l’entreprise, le support peut proposer une procédure de récupération avec des justificatifs. Il faut éviter de créer un second compte ou de modifier les DNS avant d’avoir compris l’organisation actuelle.

Si l’ancien prestataire coopère, une courte passation permet de récupérer les accès et les particularités techniques. L’article consacré au fait de changer de prestataire web sans perdre son site détaille cette transition entre deux intervenants.

Lorsque le prestataire ne répond plus, l’article récupérer un site abandonné par une agence décrit les étapes de reprise.

Lorsque le prestataire ne répond plus, tout ce qui reste accessible doit être sauvegardé rapidement. Les contenus publics peuvent également être copiés afin de préserver au minimum les textes, médias et URL si l’hébergement devient indisponible.

Une reconstruction ne doit être décidée qu’après avoir vérifié les possibilités de récupération. Elle devient nécessaire lorsque le code, la base ou les droits restent définitivement inaccessibles, ou lorsque la technologie propriétaire ne permet aucun transfert exploitable.

La récupération des accès ne signifie pas que le site doit être migré à l’identique. Le nouvel intervenant doit d’abord vérifier son état afin de ne pas déplacer une base déjà compromise ou difficile à maintenir.

L’audit examine les versions du CMS, du serveur et des extensions. Il cherche les composants abandonnés, les comptes suspects, les erreurs récurrentes et les éventuels fichiers modifiés de manière inhabituelle.

Les performances et l’espace disque sont également observés. Un site lent sur son ancien hébergement peut souffrir d’une configuration insuffisante, mais aussi d’images trop lourdes, d’une base encombrée ou d’extensions inefficaces.

Le diagnostic doit distinguer les problèmes liés à l’infrastructure de ceux qui viennent du site lui-même. Déplacer un code fragile vers un serveur plus puissant peut masquer temporairement les symptômes sans résoudre la cause.

L’audit permet finalement de choisir entre trois scénarios : maintenir le site, le moderniser progressivement ou préparer une refonte. Cette décision doit être expliquée à partir des risques et des coûts, pas de la préférence technique du nouveau prestataire.

Le transfert doit être préparé dans un environnement séparé. Le nouveau prestataire restaure les fichiers et la base, adapte les configurations puis teste les fonctions principales avant de toucher au domaine.

Les pages, formulaires, emails, liens et éventuels espaces privés sont vérifiés. Le site doit également être testé sur mobile et avec son certificat HTTPS.

Lorsqu’il reçoit des commandes, des comptes ou des demandes enregistrées dans la base, il faut tenir compte des changements intervenus après la première copie. Une synchronisation finale ou une courte période de maintenance peut être nécessaire pour éviter de perdre les dernières données.

Les DNS ne sont modifiés que lorsque le nouvel environnement fonctionne. Leur durée de cache peut être ajustée à l’avance afin de réduire le temps nécessaire à la propagation, sans garantir pour autant un changement instantané pour chaque visiteur.

L’ancien hébergement doit rester disponible pendant une courte période après la bascule. Il constitue une sécurité pour récupérer un fichier ou une configuration oubliée, mais ne doit plus devenir une source concurrente de nouvelles données.

La validation ne se limite pas à l’affichage de la page d’accueil. Les formulaires doivent être envoyés, les emails reçus, les statistiques collectées et les éventuels paiements ou réservations testés.

Les pages importantes sont comparées avec leur ancienne version afin de détecter un contenu manquant, une URL modifiée ou une ressource inaccessible.

Les certificats, redirections et paramètres d’indexation sont également contrôlés. Une directive prévue pour l’environnement de test ne doit pas rester active sur le site public.

Une fois cette validation terminée, les accès de l’ancien prestataire peuvent être supprimés. Les mots de passe partagés et les clés sensibles sont remplacés, puis les sessions actives sont révoquées lorsque les outils le permettent.

Cette étape doit inclure les services moins visibles : registrar, hébergement, CMS, dépôt, outils Google, formulaires, emailing et licences. Un compte oublié peut conserver des droits importants longtemps après la fin de la mission.

La reprise doit aboutir à une organisation dans laquelle l’entreprise maîtrise ses actifs, même si elle délègue leur administration quotidienne.

Le domaine, l’hébergement et les principaux services doivent être créés ou transférés sur des comptes appartenant à l’entreprise. Le prestataire reçoit ensuite les permissions nécessaires à son travail.

Les identifiants sont centralisés dans un gestionnaire de mots de passe sécurisé. Chaque compte peut être accompagné d’une courte indication sur son rôle, son propriétaire et son mode de facturation.

Il faut également documenter la localisation des sauvegardes, le dépôt de code et la procédure de mise en ligne. Quelques informations précises suffisent à rendre le projet beaucoup plus facile à transmettre.

Cette gouvernance évite de recréer une dépendance identique avec le nouvel intervenant. L’entreprise ne doit pas attendre un futur conflit ou une disparition pour découvrir qu’elle ne possède toujours pas ses principaux comptes.

La reprise peut être considérée comme prête lorsque le domaine et les DNS sont identifiés, que l’entreprise possède les droits administratifs et que les emails ne dépendent pas d’une configuration inconnue.

Le nouvel intervenant doit disposer d’une copie des fichiers et de la base, puis avoir confirmé qu’elle peut être restaurée dans un environnement séparé. Les versions, licences et développements spécifiques doivent être suffisamment compris pour éviter une migration à l’aveugle.

Les comptes du CMS, les formulaires et les services commerciaux doivent être testés. Les propriétés Analytics, Search Console et Tag Manager restent accessibles avec leur historique.

Un plan de bascule précise enfin la sauvegarde finale, le changement DNS, les contrôles à réaliser et la durée de conservation de l’ancien hébergement.

Cette synthèse ne remplace pas l’audit. Elle permet de vérifier que les fondations nécessaires à une reprise maîtrisée sont réunies avant de commencer les transformations visibles.

Une reprise de site internet commence par la maîtrise des actifs techniques. Domaine, DNS, hébergement, base de données, emails et services externes peuvent dépendre de fournisseurs différents et doivent être identifiés séparément.

Une sauvegarde n’est fiable que lorsqu’elle peut être restaurée. Le nouvel environnement doit être testé avant toute modification du domaine, et l’ancien hébergement doit rester disponible pendant une courte période après la bascule.

Les accès de l’ancien prestataire ne sont révoqués qu’après la validation du site, des formulaires, des emails et des outils de mesure. Les mots de passe et clés partagés sont ensuite remplacés.

Si vous devez reprendre un site existant sans savoir précisément où se trouvent son domaine, son hébergement ou ses sauvegardes, Websual peut vous accompagner sur l’audit, la récupération et la reprise technique de votre site internet, puis sur sa maintenance, sa modernisation ou sa refonte.