Changer de prestataire web : quels accès récupérer avant la transition ?

Le changement de prestataire web paraît parfois simple : transmettre le site, désigner un nouvel interlocuteur et fixer une date de reprise. La difficulté apparaît lorsque personne ne sait précisément qui contrôle le nom de domaine, où arrivent les messages du formulaire ou quel compte paie l’hébergement.

Au fil des années, un site peut avoir changé de serveur, ajouté un outil de mesure, relié une messagerie ou reçu une nouvelle version. Le dirigeant voit un seul site ; la transition porte en réalité sur plusieurs services liés.

Avant de parler de migration, il faut donc établir ce que l’entreprise utilise, qui peut l’administrer et comment chaque accès peut être repris. Le but n’est pas de collecter une liste de mots de passe. Il est de vérifier que l’entreprise pourra continuer à décider, payer, renouveler, exporter et corriger après le départ du prestataire.

Commencer par les services, pas par les mots de passe

Un identifiant ne suffit pas à décrire un service. Un compte peut consulter les statistiques sans pouvoir ajouter un utilisateur. Une personne peut modifier le site sans avoir accès à son hébergement. Une facture peut être payée par l’entreprise alors que le contrat reste rattaché à une adresse créée par le prestataire.

L’inventaire doit donc préciser, pour chaque élément :

• son rôle dans le fonctionnement du site ;
• le titulaire du compte ou du contrat ;
• les personnes qui disposent d’un droit d’administration ;
• l’adresse utilisée pour la récupération de compte ;
• le mode de facturation et la prochaine échéance connue ;
• la possibilité d’exporter les données ou la configuration utiles ;
• l’action nécessaire avant la transition.

Cette grille transforme une demande vague — « envoyez-nous tous les accès » — en vérifications que l’ancien et le nouveau prestataire peuvent traiter sans ambiguïté. Elle fait aussi apparaître les services dont personne ne se souvient, mais qui restent nécessaires au parcours client.

Vérifier d’abord le nom de domaine et sa zone DNS

Le nom de domaine est l’adresse publique du site, mais il peut aussi orienter les e-mails et certains sous-domaines. La première vérification consiste à identifier le compte depuis lequel il est renouvelé, le contact capable de récupérer ce compte et la personne autorisée à modifier sa configuration.

Il faut ensuite distinguer le domaine de sa zone DNS. Les deux peuvent être gérés au même endroit ou par des services différents. Le futur prestataire n’a pas toujours besoin de transférer immédiatement le domaine. Il doit en revanche savoir où les enregistrements sont administrés, disposer d’une copie de la configuration existante et comprendre quelles fonctions en dépendent.

Une modification trop rapide peut affecter autre chose que le site. La messagerie, un espace de réservation, une page de paiement ou un outil métier peuvent utiliser le même domaine. Avant toute intervention, chaque entrée doit être reliée à un usage identifié. Ce travail relève naturellement d’un audit stratégique de l’écosystème numérique lorsque les responsabilités et les comptes se sont accumulés sans documentation commune.

Localiser le site, son code et ses sauvegardes

« Avoir accès au site » peut désigner plusieurs choses. L’interface d’administration permet de modifier des contenus. L’hébergement donne accès aux fichiers, aux bases de données et à certaines configurations. Le dépôt de code contient la version développée. Le système de déploiement transmet cette version vers le serveur. Ces éléments ne sont pas toujours réunis chez le même fournisseur.

Pour chacun, l’entreprise doit savoir ce qui constitue la version de référence. Une copie téléchargée du site n’est pas forcément suffisante si les changements récents se trouvent ailleurs. Une sauvegarde n’est utile que si son contenu, sa date et sa procédure de restauration sont compris. Un accès à un dépôt ne garantit pas que le code qui s’y trouve correspond à la version en ligne.

Le contrôle peut partir d’une modification récente connue : une page ajoutée, un formulaire corrigé ou un réglage changé. Le nouveau prestataire vérifie où cette modification apparaît et remonte jusqu’à sa source. Cette méthode évite de reprendre un ancien environnement en pensant disposer du site actif.

Recenser les services qui entourent le site

Un site commercial transmet rarement toutes ses demandes par lui-même. Il peut appeler un service d’envoi d’e-mails, enregistrer les formulaires dans un outil, mesurer les visites, afficher un moteur de réservation ou transmettre des contacts à un logiciel métier.

L’inventaire doit donc suivre un parcours réel. Lorsqu’un visiteur envoie une demande, où la donnée arrive-t-elle ? Quelle adresse reçoit la notification ? Un antispam, une automatisation ou un outil de suivi intervient-il ? Qui voit un échec ? La même démarche s’applique à une réservation, un téléchargement ou une demande de rappel.

Cette cartographie n’a pas besoin de décrire toute l’architecture technique. Elle doit rendre lisible la chaîne entre l’action du client et le résultat attendu par l’équipe. Elle complète la méthode utilisée pour repérer les doubles saisies entre les logiciels d’une PME : ici, l’objectif n’est pas encore d’optimiser le flux, mais d’éviter qu’un maillon reste chez l’ancien prestataire sans que personne ne le sache.

Séparer la propriété, l’administration et l’intervention

L’entreprise n’a pas besoin de réaliser elle-même toutes les opérations techniques. Elle doit en revanche pouvoir nommer un administrateur, retirer un accès et choisir un autre intervenant sans perdre le service.

Une organisation saine distingue trois rôles. Le titulaire engage l’abonnement ou contrôle la ressource. L’administrateur gère les droits et les paramètres importants. L’intervenant dispose seulement des permissions nécessaires à sa mission. Selon les outils, une même personne peut cumuler ces rôles, mais la distinction doit rester compréhensible.

Les comptes rattachés uniquement à une adresse personnelle posent un problème de continuité. Avant la transition, il est préférable de créer ou confirmer une adresse contrôlée par l’entreprise pour la récupération, puis d’ajouter les utilisateurs nommément lorsque le service le permet. Le changement de prestataire ne doit pas remplacer une dépendance individuelle par une autre.

Tester les accès au lieu de les archiver

Un tableau rempli n’est pas une preuve de reprise. Chaque accès important doit être testé avant la date de bascule. Le test consiste à se connecter, vérifier le niveau de droit, confirmer le moyen de récupération et localiser la facture ou l’abonnement correspondant.

Pour les ressources critiques, le nouveau prestataire peut aussi vérifier qu’un export ou une sauvegarde exploitable est disponible, sans modifier la production. Toute impossibilité doit être notée avec une action et un responsable : invitation à accepter, adresse à remplacer, double authentification à réinitialiser ou justificatif à retrouver.

Les secrets ne doivent pas circuler dans un document partagé sans contrôle. Lorsqu’un mot de passe doit réellement être transmis, le canal, les personnes autorisées et son renouvellement après la reprise doivent être prévus. Dans de nombreux cas, ajouter un nouvel utilisateur puis retirer l’ancien est plus clair que partager un compte unique.

Préparer l’ordre de la transition

Tous les accès ne se reprennent pas au même moment. Le nouveau prestataire peut examiner le site, le code et les dépendances avant de modifier le domaine. Les droits de lecture peuvent être accordés tôt. Les changements de configuration et la révocation des anciens comptes interviennent seulement lorsque les vérifications sont terminées.

Un ordre de passage simple peut comprendre :

1. inventorier les services et leurs propriétaires ;
2. créer les accès nominatifs nécessaires ;
3. tester les droits, sauvegardes et procédures de récupération ;
4. documenter les dépendances visibles sur un parcours client ;
5. préparer la bascule et une possibilité de retour ;
6. contrôler le site, les formulaires et les e-mails après le changement ;
7. retirer ou réduire les anciens accès une fois la reprise confirmée.

Cette transition peut révéler une question plus large : faut-il seulement changer d’intervenant, ou le socle technique lui-même n’est-il plus adapté ? L’article sur le choix entre remplacer un logiciel métier et connecter les outils existants aide à séparer le problème de prestataire du problème d’outil. Les deux décisions peuvent être liées, mais elles ne doivent pas être confondues dans l’urgence.

Ce que l’entreprise doit conserver après la reprise

À la fin du changement, l’entreprise doit posséder un inventaire court qu’elle sait relire. Il contient les services actifs, leurs titulaires, les administrateurs, les échéances, les moyens de récupération et les dépendances principales. Les procédures détaillées peuvent rester chez le prestataire, mais les points qui conditionnent la continuité ne doivent pas disparaître avec lui.

Ce document doit évoluer lorsqu’un service est ajouté, remplacé ou supprimé. Une revue ponctuelle, notamment avant un renouvellement important ou une refonte, évite de reconstruire tout l’historique lors de la prochaine transition.

Changer de prestataire web devient alors une opération préparée plutôt qu’une recherche d’accès menée sous pression. Le nouveau partenaire sait ce qu’il reprend, l’ancien sait ce qu’il doit transmettre et le dirigeant conserve une vue sur les ressources qui engagent son entreprise. La qualité de la transition se mesure moins au nombre de mots de passe reçus qu’à la capacité de vérifier chaque service et de continuer à le piloter.