Reprendre un site web créé par une autre agence sans tout refaire

Changer d’agence web ne devrait pas obliger une organisation à jeter un site qui fonctionne. Une nouvelle équipe peut souvent reprendre l’environnement existant, corriger un problème précis et poursuivre son évolution sans repartir de zéro.

La difficulté n’est pas de découvrir qui a choisi la couleur des boutons. Il faut surtout comprendre où se trouvent les accès, comment le site est construit et ce qui pourrait casser lorsqu’on le modifie.

Une reprise réussie commence donc par une courte enquête technique. Elle mène ensuite à l’une de trois décisions : intervenir directement, stabiliser certaines parties avant d’avancer ou planifier une refonte lorsque la fondation ne répond plus au besoin.

Peut-on vraiment changer d’agence sans refaire le site?

Oui. Les sites WordPress, les boutiques en ligne et les plateformes développées sur mesure peuvent généralement être confiés à une autre équipe. Le changement est particulièrement simple lorsque l’organisation possède ses comptes, son code et sa documentation.

Même sans documentation parfaite, le site public, l’administration, l’hébergement et les fichiers donnent beaucoup d’information. Une équipe expérimentée peut identifier les technologies utilisées, dresser la liste des dépendances et reproduire l’environnement dans lequel le site fonctionne.

Le risque augmente lorsque le fournisseur précédent contrôle seul le domaine, l’hébergement ou le dépôt de code. Il augmente aussi lorsque des modifications ont été faites directement en production sans historique. Ces situations ne rendent pas nécessairement la reprise impossible, mais elles obligent à sécuriser l’existant avant d’ajouter quoi que ce soit.

Commencer par reprendre le contrôle des accès

Avant de demander une nouvelle fonctionnalité, vérifiez à qui appartiennent les comptes importants. L’organisation devrait pouvoir administrer ou transférer elle-même les éléments suivants :

• le nom de domaine et ses paramètres DNS;
• l’hébergement et le réseau de diffusion de contenu;
• le CMS et les comptes administrateurs;
• le dépôt contenant le code source;
• la base de données et les sauvegardes;
• les outils analytiques et Google Search Console;
• les formulaires, courriels transactionnels et services externes;
• les licences de thèmes, d’extensions ou de polices.

Un fournisseur peut gérer ces comptes au quotidien, mais l’entreprise ne devrait pas perdre son site parce qu’une relation d’affaires se termine. Les accès personnels doivent également être remplacés par des comptes d’organisation lorsque la plateforme le permet.

La récupération des accès révèle souvent des zones oubliées. Un formulaire peut dépendre du compte courriel d’un ancien employé. Une extension payante peut être enregistrée au nom du développeur. Le domaine peut être renouvelé avec une carte expirée. Ces détails sont invisibles jusqu’au jour où ils bloquent une mise à jour.

Sauvegarder avant de modifier

La première sauvegarde n’est pas une formalité. Elle doit comprendre les fichiers, la base de données et la configuration nécessaire pour remettre le site en ligne. Il faut ensuite confirmer qu’elle peut réellement être restaurée.

Une copie qui existe seulement sur le même serveur protège mal contre une panne ou une erreur de manipulation. Pour une intervention risquée, la nouvelle équipe devrait aussi disposer d’un environnement de test séparé du site public.

Cette précaution permet d’essayer une mise à jour, une nouvelle intégration ou un correctif sans transformer les visiteurs en testeurs. Elle crée également un point de retour clair si le changement produit un effet inattendu.

Auditer seulement ce qui influence le mandat

Une reprise ne nécessite pas toujours un audit de cinquante pages. L’analyse doit être proportionnelle au changement demandé.

Pour corriger un formulaire, il faut comprendre son module, sa destination, ses validations, ses notifications et son suivi analytique. Pour ajouter une section, il faut vérifier le système de composants, les styles, l’administration et le comportement mobile. Pour améliorer la vitesse, il faut mesurer ce qui ralentit réellement la page avant de remplacer des outils au hasard.

Un audit initial couvre généralement quatre dimensions :

1. La technologie. CMS, framework, thème, extensions, versions et méthode de déploiement.
2. La santé technique. Erreurs, sécurité, sauvegardes, performance et dépendances abandonnées.
3. Le contenu et le référencement. URL, titres, indexation, redirections, données structurées et pages qui attirent déjà des visites.
4. Les opérations. Personnes responsables, fréquence des changements, intégrations et processus de publication.

Le livrable utile n’est pas une longue liste de défauts. C’est une recommandation qui distingue ce qui doit être corrigé immédiatement, ce qui peut attendre et ce qui fonctionne déjà très bien.

Une intervention ciblée peut être suffisante

Un site n’a pas besoin d’avoir été créé par DevActif pour que notre équipe puisse y contribuer. Nous avons notamment effectué des modifications ciblées sur le site de COMM Climat, une communauté de pratique qui contribue à améliorer les communications climatiques au Québec.

Le mandat ne consistait pas à revendiquer la conception du site ni à remplacer sa fondation. Il s’agissait d’intervenir dans un environnement existant pour répondre à des besoins précis. Cette distinction est importante : une collaboration technique peut être utile même lorsqu’elle ne devient pas une grande refonte ou une réalisation complète dans un portfolio.

Ce type de mandat convient lorsqu’une organisation veut ajouter une fonction, corriger une interface, améliorer un parcours ou résoudre un irritant sans engager immédiatement un chantier complet.

Corriger, stabiliser ou reconstruire?

Après l’analyse, trois chemins sont possibles.

Corriger directement

La correction directe convient lorsque le problème est isolé, que la base est maintenable et qu’un environnement de test permet de vérifier le changement. L’intervention reste limitée et documentée.

Stabiliser avant d’ajouter

Parfois, la demande est simple, mais le site présente un risque immédiat : sauvegardes inexistantes, logiciel abandonné, accès partagés ou erreurs fréquentes. Quelques travaux défensifs doivent alors précéder la nouvelle fonction.

Stabiliser ne signifie pas refaire le design. Cela peut simplement vouloir dire mettre les sauvegardes en ordre, mettre à jour une dépendance critique ou reproduire le site dans un environnement contrôlé.

Planifier une refonte

Une refonte devient raisonnable lorsque chaque petite modification exige un contournement, que l’administration empêche l’équipe de publier ou que les technologies ne sont plus soutenues. Elle peut aussi être justifiée si le positionnement, l’arborescence et l’identité doivent changer en même temps.

La décision doit reposer sur le coût et le risque des prochaines années, pas sur la préférence technique de la nouvelle agence. Notre guide sur la refonte d’un site web sans perdre son référencement explique les précautions supplémentaires lorsque les URL ou les contenus doivent être migrés.

Protéger le référencement et la mesure

Une petite modification peut avoir un grand effet si elle touche une page importante. Avant de changer une URL, un titre, un menu ou un modèle, il faut vérifier ce que la page reçoit déjà comme trafic et comme liens.

Les redirections doivent être préparées avant de retirer une adresse. Les canoniques, le sitemap et les directives d’indexation doivent rester cohérents. Les formulaires et événements analytiques doivent aussi être testés après la mise en ligne : une page plus jolie qui ne mesure plus les demandes constitue une régression.

Pour une intervention vraiment ciblée, le meilleur résultat est souvent invisible. Le visiteur voit la nouvelle fonction ou la correction, tandis que les URL, les données et les parcours qui fonctionnaient continuent de fonctionner.

Demander une trace des changements

Une bonne reprise doit rendre la prochaine reprise plus facile. Après l’intervention, l’organisation devrait recevoir une trace simple de ce qui a changé, de la manière de le déployer et des dépendances ajoutées.

Le code devrait être conservé dans un dépôt accessible. Les mots de passe ne devraient pas être enfouis dans un document ou une conversation. Les décisions inhabituelles méritent une courte explication pour éviter qu’une prochaine équipe les interprète comme des erreurs.

Cette documentation n’a pas besoin de devenir un manuel gigantesque. Quelques notes à jour, une liste des services et une procédure de déploiement valent davantage qu’un document exhaustif qui ne sera jamais maintenu.

Comment préparer une demande de reprise

Pour obtenir une réponse utile d’une nouvelle agence, présentez le résultat recherché plutôt qu’une solution technique déjà choisie. Indiquez ce qui ne fonctionne pas, qui utilise le site, les contraintes de date et les accès que vous possédez.

Ajoutez si possible des captures d’écran, les messages d’erreur et les étapes permettant de reproduire le problème. Précisez également si le fournisseur actuel est encore disponible. Une transition collaborative réduit le temps d’enquête, mais son absence n’empêche pas toujours d’avancer.

Une première rencontre devrait permettre de répondre à trois questions :

• avons-nous assez d’accès pour intervenir sans danger;
• quelle analyse faut-il faire avant de chiffrer;
• la demande peut-elle être isolée ou révèle-t-elle un problème plus large?

Reprendre sans dénigrer ce qui existe

Un site contient toujours des décisions prises dans un contexte précis : budget, échéance, équipe et technologies disponibles au moment de sa création. Une nouvelle agence peut proposer une meilleure voie aujourd’hui sans prétendre que tout le travail précédent était mauvais.

Cette posture produit généralement de meilleures décisions. On conserve ce qui fonctionne, on corrige ce qui freine l’organisation et on réserve la reconstruction aux situations où elle apporte une valeur réelle.

DevActif peut reprendre et faire évoluer un site web existant, qu’il soit développé avec WordPress ou avec une technologie sur mesure. La première étape consiste à comprendre l’environnement et le besoin; la refonte n’est qu’une option parmi d’autres.