Comment parler de la sécurité de votre site avec votre développeur

Vous avez sous les yeux un rapport de sécurité, un e-mail de votre hébergeur ou un message d'un client disant que quelque chose semble étrange. Vous ne savez pas si c'est grave. Vous ne voulez pas avoir l'air de ne rien y comprendre, ni payer un travail inutile.

Il n'est pas nécessaire de s'y connaître pour avoir une bonne conversation avec votre développeur. Il faut de la structure : une demande claire, une date ferme et un moyen de vérifier que le travail a été fait. Voici comment les réunir.

Que mettre dans le premier message

Un développeur travaille plus vite quand il reçoit d'emblée trois choses.

Le constat avec les mots de la source. Recopiez exactement le nom du problème tel que l'a écrit le rapport ou l'hébergeur, sans le paraphraser. « Fichier de sauvegarde accessible publiquement » en dit beaucoup plus à un développeur que « il y a un problème avec les sauvegardes ».

L'adresse exacte. Pas « sur le site », mais l'adresse complète de la page ou du fichier, par exemple https://votredomaine.fr/backup.zip.

Les preuves. Une capture d'écran avec la date visible, le rapport complet en pièce jointe, l'e-mail transféré de votre hébergeur. Ainsi, personne n'a à deviner ce que vous avez vu.

Le message entier peut être aussi court que celui-ci :

Objet : votredomaine.fr, fichier de sauvegarde accessible publiquement

Bonjour Marc, une analyse de sécurité faite le 2 septembre a montré qu'une sauvegarde du site peut être téléchargée à l'adresse https://votredomaine.fr/backup.zip. La capture d'écran et le rapport complet sont joints. Pouvez-vous confirmer que c'est exact, et m'envoyer un devis et une date pour la correction ? Si vous pensez à une fausse alerte, expliquez-moi pourquoi en quelques phrases.

Une chose à ne pas envoyer : des mots de passe dans le corps d'un e-mail. Si votre développeur a besoin d'accéder à l'administration, créez-lui un compte séparé, facile à supprimer ensuite.

Demandez un devis et une date, pas « un petit coup d'œil »

« Jetez un œil quand vous aurez une minute » est une demande qui peut attendre des mois. Demandez plutôt quatre choses concrètes : ce qui sera fait exactement, ce que cela coûte ou combien d'heures cela prend, pour quand, et si quelque chose risque de cesser de fonctionner au passage.

Cette dernière question compte plus qu'il n'y paraît. Mettre à jour une ancienne extension peut être simple, ou entraîner avec elle des changements dans le thème. Mieux vaut le savoir avant que de découvrir un vendredi soir que le formulaire de commande est cassé.

Si vous payez votre développeur au forfait mensuel, demandez si la correction est incluse ou si elle compte comme un travail à part. Pour tout ce qui est sérieux, demandez-lui de distinguer deux choses : supprimer le symptôme et fermer la cause. Supprimer un fichier malveillant sans chercher comment il est arrivé sur le serveur est une correction qui tient environ une semaine.

Convenez de ce qui se fait cette semaine, ce mois-ci et plus tard

Tout n'est pas urgent, et vouloir tout corriger d'un coup revient généralement à ne rien faire correctement. Trois horizons fonctionnent bien.

Cette semaine : tout ce que quelqu'un pourrait exploiter tout de suite ou qui expose des données. Un fichier de sauvegarde ou de configuration que n'importe qui peut télécharger, une extension présentant une faille connue et activement exploitée, un avertissement de Google, un certificat expiré, un compte administrateur que personne ne reconnaît, un formulaire qui envoie ses données sans chiffrement.

Ce mois-ci : des mises à jour en retard sans attaque active connue, un enregistrement DMARC absent ou réglé sur p=none, des en-têtes de sécurité manquants, et d'anciens comptes appartenant à d'anciens collaborateurs ou prestataires.

Plus tard : ce qui relève le niveau mais ne fera de mal à personne s'il attend quelques semaines. Masquer les numéros de version, affiner une politique de sécurité du contenu, passer à un meilleur hébergement.

Votre développeur voit peut-être l'ordre autrement, et il vaut la peine d'entendre pourquoi. La décision finale vous revient pourtant, parce que c'est vous qui portez le risque et payez les conséquences.

Comment vérifier que la correction a été faite

« C'est fait » dans un e-mail ne suffit pas. Demandez une courte note : ce qui a été modifié, où et quand. Deux phrases suffisent, tant qu'elles sont écrites.

Certaines choses, vous pouvez les vérifier vous-même. Si le problème était un fichier de sauvegarde, son adresse doit maintenant afficher une erreur au lieu de lancer un téléchargement. S'il s'agissait du certificat, le cadenas de votre navigateur indiquera une nouvelle date d'expiration. S'il s'agissait de mises à jour, rien ne doit plus attendre dans la file de la page Extensions de WordPress.

La vérification la plus simple consiste à relancer le test qui a détecté le problème et à comparer les résultats. Si le constat a disparu du rapport, vous avez votre confirmation. Sinon, vous avez une raison précise de reprendre la conversation.

Gardez toute la correspondance dans un seul dossier. Cela aide pour la prochaine correction, et si des données fuient un jour, cela montre que vous vous êtes occupé de la sécurité, ce que le RGPD attend que vous puissiez prouver.

Ce que comprend un plan de maintenance raisonnable

Les corrections ponctuelles éteignent des incendies. Pour éviter qu'ils ne démarrent, un site demande un entretien régulier. Un périmètre mensuel raisonnable pour le site d'une petite entreprise :

• mises à jour du CMS, du thème et des extensions au moins une fois par mois, et plus tôt pour les correctifs de sécurité urgents, avec une vérification du site après chaque mise à jour,
• sauvegardes conservées hors du serveur, avec une restauration de test de temps en temps,
• surveillance de la disponibilité du site et de l'échéance du certificat,
• revue des comptes autorisés à se connecter à l'administration,
• contrôle de sécurité périodique depuis l'extérieur,
• un court récapitulatif mensuel : ce qui a été fait et ce qui demande votre décision,
• un délai de réaction et un canal de contact convenus en cas d'intrusion.

Les prix varient beaucoup, comparez donc ce qui est inclus plutôt que le seul montant mensuel. Et assurez-vous d'une chose, quel que soit le contrat : le domaine et l'hébergement doivent être enregistrés au nom de votre entreprise, et vous devez avoir votre propre compte administrateur. Si la relation prend fin, vous ne devez pas être enfermé hors de votre propre site.

Les signaux d'alerte dans les réponses

Il n'est pas nécessaire de juger le site techniquement pour repérer des réponses qui doivent vous inquiéter :

• « WordPress est sûr, il n'y a rien à faire. »
• « On ne met pas à jour parce que quelque chose pourrait casser. » C'est parfois vrai, mais la réponse est alors une copie de préproduction du site où les mises à jour sont testées d'abord, pas l'absence de mises à jour.
• « Les sauvegardes sont sur le serveur. » Si c'est le serveur même où tourne le site, une intrusion ou une panne les emporte avec lui.
• « Envoyez-moi simplement votre mot de passe. » Chacun doit avoir son propre compte.
• « C'est un faux positif », sans explication.
• « Je m'en occupe », sans date.
• La réticence à vous donner accès à votre propre hébergement, à votre domaine ou à votre administration.

Un bon développeur ne prend pas les questions personnellement, parce que des questions claires facilitent la définition du périmètre et le paiement du travail. Si les réponses sont vagues ou sur la défensive, cela vous renseigne aussi, et mieux vaut l'avoir en tête avant le prochain contrat.