Reprendre le site d'un client : ce qu'il faut vérifier avant de faire un devis

Un nouveau client s'est séparé de son précédent développeur et cherche quelqu'un pour reprendre son site. Il demande combien coûtera la maintenance mensuelle. Il est tentant de répondre avec votre tarif habituel. Le problème, c'est que vous ne savez pas encore à quoi vous vous engagez.

Un site qui a changé de mains peut arriver avec des dizaines d'extensions, dont certaines intactes depuis longtemps, un export de base de données dans un dossier public et un compte administrateur appartenant à quelqu'un dont personne ne se souvient. Si vous le chiffrez comme un site bien entretenu, vos premières semaines de maintenance sont gratuites. Et si le site est déjà compromis, il passera dès le jour de la reprise pour votre problème.

Voici une liste de contrôle en deux parties : ce que vous pouvez vérifier depuis l'extérieur avant que le client vous remette le moindre mot de passe, puis ce qu'il faut examiner dans l'administration une fois les accès obtenus. À la fin, comment transformer les constats en devis.

Obtenez d'abord l'accord du client

Regarder un site comme le ferait n'importe quel visiteur ne demande l'autorisation de personne. Lancer des outils d'analyse contre lui est différent : l'hébergeur ou le développeur précédent peut mal réagir à un trafic inattendu. Un e-mail d'une ligne du client, « J'accepte que vous vérifiiez le site avant de me faire un devis », vous couvre.

Depuis l'extérieur, sans mot de passe

Vous pouvez faire tout cela avant la première réunion. Il faut environ une demi-heure, et c'est souvent suffisant pour savoir si le devis sera standard.

Certificat et redirections. Le site fonctionne-t-il uniquement en HTTPS ? Les versions http://, avec www et sans www aboutissent-elles toutes à une seule adresse sécurisée ? Quand le certificat expire-t-il, et le serveur accepte-t-il encore les protocoles TLS 1.0 et 1.1, abandonnés ? Le contrôle de certificat SSL (en anglais) répond à tout cela en quelques secondes.

Messagerie du domaine. Les enregistrements MX, SPF, DKIM et DMARC. Pas de DMARC, ou un DMARC à p=none, c'est une ligne pour votre devis et un indice que personne n'a regardé le DNS depuis un moment. Notez aussi où est hébergée la messagerie du client, car chaque modification du DNS que vous ferez ensuite devra la respecter. Le contrôle SPF, DKIM et DMARC (en anglais) montre l'état actuel.

Plateforme et versions. Sur quoi tourne le site, avec quelle version, quelles extensions apparaissent dans le code de la page et si elles révèlent leur numéro de version. La balise meta generator et les paramètres ?ver= dans les adresses des scripts en disent long. Comparez ce que vous trouvez avec une base de vulnérabilités comme WPScan ou Patchstack.

Fichiers qui ne devraient pas être publics. backup.zip, exports .sql, wp-config.php.bak, un dossier .git, un fichier .env, phpinfo.php. Ne devinez pas les adresses à la main : un outil les vérifiera plus vite et plus complètement. Si vous trouvez quelque chose, ne le téléchargez pas. Notez l'adresse et prévenez le client immédiatement. L'article La sauvegarde oubliée sur le serveur explique pourquoi ce point ne peut pas attendre.

Formulaires. Chaque formulaire envoie-t-il ses données en HTTPS, y a-t-il une protection anti-spam, et une mention d'information sur les données personnelles à côté ? Envoyez une demande de test et demandez au client si elle est arrivée, et dans quelle boîte. Il arrive qu'un formulaire de contact envoie depuis des mois les demandes à l'adresse d'un ancien salarié.

En-têtes et sous-domaines. Ajouter les en-têtes de sécurité manquants est en général un petit travail, mais il a sa place dans le devis. Des sous-domaines oubliés comme test. ou old. peuvent être plus risqués que le site principal, parce que personne ne les met à jour.

Signes de piratage. Cherchez site:domaineduclient.fr dans Google et parcourez les résultats. Des pages en japonais, ou sur des pharmacies ou des casinos, signifient que vous commencez par un nettoyage, pas par de la maintenance.

Dans l'administration, une fois l'accès obtenu

Sauvegardes. Où elles sont, à quelle fréquence elles tournent, jusqu'à quelle date elles remontent et qui peut y accéder. Demandez si quelqu'un a déjà restauré le site à partir de l'une d'elles. Avant de modifier quoi que ce soit, faites votre propre sauvegarde complète et stockez-la hors du serveur. C'est votre assurance au cas où l'on découvrirait que quelque chose était cassé avant votre arrivée.

Comptes administrateurs. Passez en revue tous les utilisateurs ayant le rôle Administrateur. Les comptes de l'agence précédente, d'anciens collaborateurs ou de personnes que personne ne reconnaît doivent disparaître, avec l'accord du client. Un compte que personne ne sait expliquer est un signe possible de compromission, pas un simple encombrement.

Extensions et thème. Comptez les extensions et notez celles qui attendent une mise à jour, celles qui sont désactivées et celles qui n'ont pas eu de nouvelle version depuis longtemps. Vérifiez les licences des extensions payantes : à quel nom elles sont et si elles ont expiré. Une extension premium sans licence ne reçoit aucune mise à jour, et une copie « d'origine non officielle » peut contenir du code en plus. Regardez si le thème a été modifié directement au lieu de passer par un thème enfant, car la prochaine mise à jour effacera ces modifications. L'article Extensions WordPress obsolètes indique quoi mettre à jour en premier et quoi supprimer.

Version de PHP et environnement. L'écran Santé du site, sous Outils, affiche les versions de PHP et de la base de données ainsi que les avertissements propres à WordPress. Une ancienne version de PHP bloque souvent toutes les autres mises à jour, elle détermine donc l'ordre des travaux.

Hébergement, domaine et DNS. C'est le point qu'on laisse facilement pour plus tard et qui finit par tout bloquer. Découvrez à quel nom le domaine est enregistré et qui peut se connecter chez le bureau d'enregistrement, sur le compte de qui est l'hébergement et qui le paie, et qui peut modifier le DNS. Idéalement, tout appartient au client et vous recevez votre propre identifiant, pas celui du développeur précédent. Si le domaine est enregistré au nom de l'ancienne agence, lancez le transfert avant de planifier une migration.

Formulaires, côté interne. Où vont les envois, s'ils sont conservés dans la base de données, et pendant combien de temps. Des années d'anciennes demandes pleines de données personnelles sont une question RGPD pour le client, mentionnez-la donc dans votre rapport même si la décision ne vous appartient pas.

Transformer les constats en devis

Le client ne voit pas la différence entre un site bien entretenu et un site négligé. Dans un navigateur, ils se ressemblent. Si votre devis affiche un seul montant pour « reprise du site » et que celui d'un concurrent est plus bas, le client choisit le plus bas. Il faut montrer d'où vient la différence.

Découpez le devis en trois parties :

1. État actuel. Une courte liste de ce que vous avez trouvé, avec la date du contrôle. Trois phrases par point : ce qui ne va pas, ce que cela pourrait coûter à l'entreprise, ce qu'il faut faire. Sans jargon. Au lieu de « pas de DMARC », écrivez « n'importe qui peut envoyer des e-mails qui semblent venir de votre entreprise, y compris de fausses factures ».
2. Remise en état initiale. Les travaux ponctuels qui découlent de l'état actuel, chaque point avec son prix ou son estimation de temps. Le client voit exactement ce qu'il paie et peut fixer des priorités si le budget est serré. Marquez les points urgents, comme un export de base de données visible publiquement, comme une condition de la reprise.
3. Maintenance mensuelle. Un forfait pour maintenir le site dans l'état où vous l'avez amené.

Ajoutez une phrase sur la responsabilité : votre maintenance couvre le site à partir de la date de remise, et les problèmes listés dans l'état actuel ne deviennent les vôtres qu'une fois corrigés. Faites-la rédiger par un juriste pour votre marché, mais le principe protège les deux parties. Le client sait ce qu'il paie, et vous ne répondez pas de la négligence d'un autre.

Conservez les preuves du jour du contrôle : le rapport, les captures d'écran, la liste des comptes et des extensions. Si une infection antérieure à votre arrivée apparaît trois mois plus tard, vous pourrez le démontrer.

Un rapport que le client peut lire seul

Une liste dans un devis fonctionne mieux quand le client peut la transmettre à un associé ou à son comptable sans vous appeler pour la traduire. C'est pourquoi un rapport issu du contrôle, à votre marque, mérite d'être joint au devis.

ShieldWave couvre la moitié extérieure de cette liste. Il analyse le site sans extension ni mot de passe, et avec l'offre Enterprise le rapport porte le logo et les coordonnées de votre agence. Le client reçoit chaque problème expliqué sans jargon et un plan de correction classé par urgence. Vous recevez les constats avec les adresses, les preuves et une estimation du temps de travail pour construire le devis. L'offre Enterprise coûte 29 $ par mois pour un nombre illimité de sites, avec 7 jours d'essai. Elle ne regardera pas à votre place l'intérieur de l'administration, les sauvegardes ou la liste des accès : la seconde moitié de cette liste reste votre travail.