Changer de prestataire web : récupérer les accès, les fichiers et les dépendances avant la passation

Le nouveau prestataire dispose du compte administrateur du site. La passation semble terminée. Puis il faut renouveler le domaine, modifier un enregistrement de messagerie ou corriger un développement spécifique : le compte utile appartient encore à l’ancienne agence, le fichier source manque ou la licence s’arrête avec le contrat.

La réversibilité d’un site se prépare en regardant tout ce qui permet de le faire fonctionner, de le modifier et de le restaurer. Une sauvegarde du contenu est indispensable, mais elle ne remplace ni la maîtrise des comptes ni la compréhension des services externes. La bonne passation se démontre par des opérations réussies, pas uniquement par un dossier remis.

Définir le périmètre avant de toucher aux comptes

Commencez par nommer ce qui change : maintenance, hébergement, conception, référencement, gestion des campagnes ou ensemble de ces activités. Changer d’intervenant ne nécessite pas toujours de déplacer immédiatement tous les services. Un transfert progressif peut limiter les risques si ses responsabilités sont explicites.

Relisez le contrat, les annexes et les factures. Ils renseignent les prestations comprises, les échéances, les modalités de sortie et les droits sur certains éléments. Ne supposez pas que tout ce qui apparaît sur le site peut être transmis et réutilisé sans condition : photographies, polices, composants et développements peuvent relever de licences différentes.

Construisez une carte courte des dépendances : domaine, DNS, hébergement, CMS, base de données, messagerie, formulaires, paiement, statistiques, outils d’envoi et services connectés. Pour chaque ligne, identifiez le titulaire du compte, le payeur, le contact de récupération et la date de renouvellement.

Cette carte révèle les faux raccourcis. L’agence peut gérer le DNS sans héberger le site. La messagerie peut être portée par un autre fournisseur. Un formulaire peut envoyer les demandes vers un service externe dont personne ne connaît le propriétaire. Retirer un seul compte trop tôt peut interrompre plusieurs fonctions.

L’ANSSI rappelle l’intérêt d’examiner les conditions de réversibilité et la sécurité lors d’une migration externalisée. Pour une PME, cela signifie surtout préciser ce qui sera remis, dans quel format, à quelle date et avec quelle assistance. Les zones floues doivent devenir des questions concrètes avant le jour du changement.

Reprendre la maîtrise du domaine et des comptes essentiels

Le nom de domaine mérite une vérification distincte. Qui est titulaire ? Quelle adresse reçoit les avis de renouvellement ? Qui peut débloquer un transfert ou modifier les serveurs DNS ? Une entreprise peut payer chaque année un domaine sans disposer elle-même des moyens de le gérer.

Pour les extensions gérées par l’Afnic, le Whois apporte des informations techniques et administratives utiles, avec les limites de diffusion applicables. Un transfert de bureau d’enregistrement utilise notamment un code d’autorisation fourni dans le processus prévu. Vérifiez la procédure exacte avec les acteurs concernés plutôt que de transmettre tous les mots de passe par courrier électronique.

Le transfert du domaine et la migration du site sont deux opérations différentes. Il est souvent possible de changer le gestionnaire du domaine en conservant les réglages qui font fonctionner le site et les e-mails. À l’inverse, une modification maladroite des DNS peut perturber les deux alors que les fichiers du site n’ont pas bougé.

Prévoyez des comptes nominatifs pour les intervenants, des droits adaptés et une authentification renforcée lorsqu’elle est disponible. L’entreprise doit conserver un moyen de récupération maîtrisé. L’adresse personnelle d’un ancien chef de projet ne doit pas rester l’unique porte de secours.

Le nouveau prestataire peut être invité avec ses propres droits pendant une période de transition. Les accès de l’ancien seront retirés au moment convenu, une fois les vérifications faites. Ne confondez pas cette coexistence limitée avec un partage permanent de comptes administrateurs communs.

Demander les éléments qui permettent une reconstruction

Pour un site classique reposant sur un CMS, demandez les fichiers nécessaires, les médias, la base de données et les éléments de configuration. Sur un projet développé spécifiquement, ajoutez les fichiers sources, le dépôt de code pertinent, les instructions de construction et les versions des dépendances.

La remise doit expliquer ce qu’un technicien compétent devrait faire pour reconstruire le site sur un environnement neuf. Les variables de configuration et secrets se transmettent par un moyen sécurisé ; la documentation peut en décrire le rôle sans afficher leur valeur en clair dans un document diffusé largement.

Une exportation des articles du CMS ne contient pas nécessairement les réglages du serveur, les tâches planifiées, le traitement des formulaires ou la personnalisation du thème. Demandez une liste des éléments exclus et de ceux qui doivent être recréés. Une limite connue est plus facile à traiter qu’un manque découvert en production.

Les licences doivent être examinées produit par produit. Un thème acheté pour le site, une extension comprise dans un abonnement d’agence et une bibliothèque sous licence libre ne se transmettent pas nécessairement de la même façon. Identifiez qui assure les renouvellements et ce qui arrive aux mises à jour après la sortie.

Pour les données, précisez la période et le périmètre : soumissions de formulaires, commandes, comptes clients, journaux utiles, statistiques. Ne récupérez pas automatiquement toutes les données historiques si elles ne sont plus nécessaires. La passation ne doit pas multiplier des copies sensibles sans responsable ni durée de conservation définie.

Utiliser une checklist qui engage des responsables

Une liste de fichiers n’est pas suffisante. Associez chaque élément à une personne chargée de le fournir et à une autre chargée de le vérifier. La date de réception et le résultat du contrôle rendent la progression visible.

Voici une checklist de passation à adapter au site :

• [ ] Titulaire du domaine, coordonnées de récupération et renouvellement vérifiés.
• [ ] Gestion du DNS et export des enregistrements utiles identifiés.
• [ ] Accès d’hébergement et droits du nouveau prestataire testés.
• [ ] Sauvegarde des fichiers et de la base disponible, datée et lisible.
• [ ] Sources, versions, dépendances et procédure de déploiement remis.
• [ ] Thèmes, extensions, polices et images associés à leurs conditions d’utilisation.
• [ ] Formulaires, e-mails transactionnels, paiement et services externes inventoriés.
• [ ] Procédure de restauration essayée sur un environnement distinct.
• [ ] Fenêtre de changement, retour arrière et contacts d’incident convenus.
• [ ] Retrait des anciens accès, rotation des secrets concernés et fin des copies organisés.

Une case cochée doit correspondre à une preuve raisonnable : connexion réussie, fichier ouvert, export contrôlé ou fonction testée. « L’agence a dit que c’était fait » peut être une information de suivi, pas le résultat final du contrôle.

Conservez cette liste à l’endroit où l’entreprise retrouvera son dossier de gestion du site. Les secrets eux-mêmes restent dans leur système approprié. La documentation doit permettre de savoir où chercher, sans transformer un tableau de passation en trousseau de mots de passe accessible à tous.

Faire une répétition avant la bascule

La restauration de contrôle est le moment où les absences deviennent visibles : image manquante, version incompatible, tâche nocturne oubliée ou connexion externe non autorisée. Elle doit se dérouler dans un environnement isolé, avec une attention particulière aux fonctions capables d’envoyer des messages ou d’effectuer des paiements.

Testez les parcours métier prioritaires avec des données adaptées : navigation, recherche, connexion, formulaire, commande si le site en propose, réception des notifications. Une page d’accueil visible ne prouve pas que les demandes commerciales arrivent au bon destinataire.

Vérifiez les opérations d’administration : publier un contenu, modifier une image, lancer une sauvegarde et retrouver un journal d’erreur. Le nouveau prestataire doit pouvoir assurer le quotidien, pas seulement montrer une copie du site. Demandez également où seront suivis les incidents pendant les premiers jours.

Prévoyez un retour arrière réaliste. Il faut savoir quelle version rétablir, qui décide et comment gérer les données apparues depuis la bascule. Revenir à une base ancienne après de nouvelles commandes peut faire disparaître des informations : la procédure doit traiter cet écart, pas seulement changer une adresse DNS.

Si les URL évoluent, préparez une correspondance et des contrôles dédiés. Si elles restent identiques, vérifiez malgré tout les liens, les réponses du serveur et les réglages d’indexation de l’environnement final. Un environnement de test ne doit pas devenir public par inadvertance, et une restriction temporaire ne doit pas rester en place sur le site actif.

Clore la relation sans laisser de dépendance invisible

Après validation, retirez les accès devenus inutiles et renouvelez les secrets qui ont été partagés lorsque le contexte le justifie. La CNIL recommande de supprimer les habilitations des personnes qui n’en ont plus besoin. La fermeture doit concerner tous les services recensés, pas seulement le compte du CMS.

Confirmez les abonnements repris, les prélèvements arrêtés et les responsabilités de maintenance. Un renouvellement oublié peut produire une panne plusieurs mois après une migration apparemment réussie. Vérifiez aussi à qui arrivent désormais les alertes techniques et les demandes de support.

Demandez le traitement convenu des données et copies restées chez le prestataire sortant, en tenant compte des obligations de conservation et du cadre contractuel. La fermeture opérationnelle ne signifie pas qu’il faut supprimer indistinctement tous les éléments administratifs ou toutes les preuves de prestation.

La passation est achevée lorsque l’entreprise sait qui gère chaque dépendance, peut récupérer ses accès et dispose d’un site restaurable. Ce résultat vaut davantage qu’un dossier volumineux : il permet de poursuivre l’exploitation et de préparer, plus sereinement, le changement suivant.