Retour d'expérience 6 min de lecture

Changer de prestataire web sans tout casser (et sans drame)

Changer de prestataire web n'est ni un drame ni une trahison. La checklist des accès à récupérer, la méthode sans coupure, et le plan B quand l'ancien ne répond plus.

Changer de prestataire web sans tout casser (et sans drame)

C'est le sujet dont personne ne parle au premier rendez-vous, et que tout le monde vit un jour. Une agence qui ferme, une relation qui s'use, un site qui plafonne : changer de prestataire web n'est ni un drame ni une trahison. C'est une opération technique, avec une méthode, et elle se passe bien quand on la mène dans l'ordre.

En résumé : on ne coupe rien tant que le nouveau ne tourne pas. Récupérez vos accès pendant que la relation est bonne : domaine, hébergement, code source, base de données, emails, statistiques. Et si vous n'avez plus rien, le domaine se récupère par la voie officielle, le reste se reconstruit.

Les signaux qu'il est temps de partir

Rester par habitude coûte parfois plus cher que partir. Les signaux qui reviennent dans les reprises qu'on mène :

  • Les délais s'allongent. Une modification mineure prend des semaines, quand elle n'est pas oubliée.
  • Chaque demande devient un devis. Vous n'osez plus rien demander, donc le site n'évolue plus.
  • Plus de mises à jour techniques. Versions à l'abandon, failles connues non corrigées : le site vieillit en silence.
  • Vous n'avez aucun accès. Ni au code, ni à l'hébergement, ni au domaine. Tout passe par une seule personne.
  • « C'est impossible » revient trop souvent. Quand l'outil dicte ce que votre activité a le droit de faire, c'est l'outil qui a un problème.

Aucun de ces signaux ne fait de vous un mauvais client, ni forcément de l'autre un mauvais prestataire : les besoins évoluent. L'important est de préparer la suite avant que la situation se dégrade.

D'abord, vos droits

Si votre contrat prévoit que le code vous appartient, tout est simple : vous demandez une copie complète (code, base de données, fichiers), et c'est non négociable. On a détaillé ailleurs à qui appartient le code que vous avez payé ; chez nous, c'est écrit au contrat, mais ce n'est pas la norme partout.

Si rien n'est écrit, c'est plus flou juridiquement. Un point reste pourtant toujours récupérable : le nom de domaine. Déposé au nom de votre entreprise, il vous suit, peu importe l'humeur de l'ancien prestataire. Au nom de l'agence ? On y revient plus bas.

Le conseil qui vaut de l'or : demandez vos copies et vos accès pendant que la relation est bonne. Pas le jour du préavis. Notre vérification en dix minutes de ce que vous possédez vraiment vous dit exactement où vous en êtes.

La checklist de ce qu'il faut récupérer

Voici ce qu'un repreneur vous demandera. Chaque ligne manquante se contourne, chaque ligne présente fait gagner du temps.

  • Le nom de domaine. L'accès au compte registrar (OVH, Gandi, Ionos...) et surtout le nom du titulaire : votre entreprise, pas l'agence. La gestion de la zone DNS va avec.
  • L'hébergement. L'accès au compte ou au serveur. A minima, savoir chez qui le site est hébergé et qui paie la facture.
  • Le code source. Une copie complète, idéalement le dépôt Git : son historique raconte la vie du projet et fait gagner des heures au repreneur.
  • La base de données et les fichiers. Un export complet et récent, plus les images et documents uploadés. C'est là que vivent vos clients, vos commandes, vos contenus : la partie irremplaçable.
  • Les emails. Si vos adresses sont liées à l'hébergement du site, une bascule mal préparée les coupe. À traiter en premier, pas en dernier.
  • Les statistiques. Google Analytics, Search Console : votre compte doit en être propriétaire, pas simple invité, sinon des années de données partent avec le compte de l'agence.
  • Les licences et services tiers. Thème ou extensions payants, passerelle de paiement, emails transactionnels : listez les comptes et à qui ils sont rattachés.

La méthode sans coupure

La règle absolue : on ne coupe rien tant que le nouveau ne tourne pas. Le nouveau site se construit et se teste pendant que l'ancien fonctionne, la bascule DNS finale prend quelques heures, et des redirections soignées de chaque ancienne adresse préservent votre référencement. Vos visiteurs ne voient rien, votre boîte mail ne saute pas.

On a suivi cette méthode pour la refonte du Rugbynistère, un média qui dépasse le million de lecteurs : contenus repris, chaque ancienne URL redirigée, référencement préservé. Quand l'audience est le fonds de commerce, la coupure n'est pas une option.

Une migration qui « nécessite trois semaines de coupure », ce n'est pas une migration, c'est un aveu.

Le déroulé d'une transition type

Concrètement, voici comment se passe une reprise :

  1. L'état des lieux. On inventorie ce que vous avez (accès, copies, contrats) et ce qui manque : la checklist ci-dessus, passée au réel.
  2. L'audit de reprise. Ce qui se garde, ce qui se refait, ce que ça coûte dans les deux cas. Pour une application Laravel ou PHP, c'est le rôle d'un audit de reprise avant de s'engager.
  3. La copie et l'environnement de travail. On duplique tout sur un environnement neuf. L'ancien site continue de tourner.
  4. Les tests en parallèle. Formulaires, paiement, emails, parcours critiques : tout est vérifié sur la copie.
  5. La bascule. Changement DNS, redirections actives, surveillance rapprochée les premiers jours.
  6. Le filet de sécurité. L'ancien environnement reste sous le coude le temps de valider que tout est stable, puis on l'archive.

À aucun moment vous n'êtes sans site : c'est le critère d'une transition maîtrisée.

Quand vous n'avez plus aucun accès

Plus fréquent qu'on ne croit : l'agence ne répond plus, a fermé, ou fait le mort. Pas de panique, il y a un ordre.

Le domaine d'abord. Un relevé WHOIS dit qui en est titulaire. Si c'est votre entreprise, le registrar peut vous rendre la main sur justificatifs. Si c'est l'ancien prestataire, des procédures existent (registrar, AFNIC pour les .fr) : du dossier et de la patience, mais elles aboutissent, surtout quand votre marque est dans le nom.

L'hébergement ensuite : si vous payez la facture, l'hébergeur peut restituer l'accès au titulaire du compte. Sinon, plan C : on aspire ce qui est public (pages, textes, images) et on reconstruit sur des bases saines. Vous y perdez l'arrière-boutique, rarement l'essentiel : vos données clients existent souvent ailleurs (facturation, comptabilité, exports).

Plus de travail qu'une transition coopérative, mais un chemin balisé : on l'a déjà parcouru. Pour situer le budget d'une reconstruction, notre estimateur de projet en ligne donne un ordre de grandeur en quelques minutes.

Comment on reprend un projet

Un audit franc, d'abord. Parfois le verdict est « votre site actuel est sain, restez où vous êtes et économisez votre argent ». Oui, ça nous arrive de le dire : un client mal embarqué dans une refonte inutile est un mauvais client pour tout le monde, à commencer par lui.

Quand la reprise se justifie, on la mène comme décrit plus haut, puis on assure la suite (mises à jour, surveillance, évolutions) : c'est le cœur de notre offre de reprise et maintenance de votre application par un nouveau prestataire. Depuis 2015 et plus de vingt projets Laravel, les règles ne changent pas : le code vous appartient, un seul projet à la fois, partout en France, sur place ou à distance.

Vous vous sentez coincé chez votre prestataire actuel ? C'est précisément le signe qu'il est temps d'en parler. En toute discrétion, et sans drame : c'est une opération, pas un divorce.

Cet article vous intéresse ? Allons plus loin ensemble.

Parlons de votre reprise
À lire aussi

D'autres articles