Votre site web est déjà scanné : le trafic que vous ne voyez pas

Quand vous publiez un nouveau site web, la première chose qu'il reçoit, ce ne sont pas des visiteurs humains. Ce sont des bots. Des dizaines, parfois des centaines par jour, qui arrivent en testant des routes qui n'existent pas — /wp-admin, /.env, /phpmyadmin, /admin/login.php — pour voir s'ils tombent sur quelque chose de connu.

Ce n'est pas parce que votre site est important. Ce n'est pas parce que quelqu'un vous a dans le viseur. C'est parce que tout l'internet public est balayé 24 heures sur 24, tous les jours, par des processus automatiques qui ne distinguent pas le blog d'un photographe du panneau d'administration d'une entreprise cotée. Ils cherchent la même chose chez tout le monde : une porte que quelqu'un a oublié de fermer.

La barrière pour attaquer n'a jamais été aussi basse

Il y a dix ans, attaquer un site web demandait des connaissances. Aujourd'hui, n'importe qui peut télécharger en quelques secondes une boîte à outils qui automatise le travail : nmap, nikto, sqlmap, wpscan, dirb… des listes de milliers de routes connues, des scripts pré-faits pour toutes les vulnérabilités WordPress des dix dernières années, des modèles pour la force brute.

Et avec la dernière vague de grands modèles de langage, la pièce qui manquait — l'interprétation des résultats, la décision de quoi essayer ensuite — est maintenant aussi à la portée de quelqu'un qui ne sait pas programmer. Ce qui exigeait auparavant un profil technique peut aujourd'hui être fait par n'importe qui avec un peu de curiosité et un après-midi libre.

Le résultat est direct : il y a plus d'attaquants potentiels, attaquant plus vite, sur plus de cibles. Et les cibles, pour la plupart, ne s'en rendent toujours pas compte.

Ce que cherche exactement ce trafic hostile

Si vous regardez les logs d'un serveur exposé pendant 24 heures, ce qui apparaît est assez répétitif :

• Routes WordPress — même si votre site ne l'utilise pas. /wp-login.php, /xmlrpc.php, /wp-admin/admin-ajax.php. Les bots essaient parce que c'est peu coûteux, et parce que le monde est plein de WordPress mal entretenus.
• Fichiers sensibles oubliés — .env, .git/config, backup.sql, config.bak, database.zip. Une seule trouvaille et l'attaquant obtient des identifiants, du code source ou la base de données complète.
• Panneaux d'administration par défaut — /admin, /administrator, /manager, /phpmyadmin. Si le panneau répond, la force brute suit.
• Injections à l'aveugle — des paramètres comme ?id=1' OR '1'='1 contre n'importe quel formulaire. Ils ne savent pas quel CMS vous utilisez, ils essaient des payloads génériques.
• Identification de technologies — en-têtes Server, fichiers statiques typiques, erreurs 500 révélatrices. Toute donnée sert à savoir quels exploits appliquer.

Rien de tout cela n'exige que votre site soit connu. Cela exige seulement qu'il soit en ligne.

L'asymétrie du problème

L'attaquant automatise. Il lance un script contre dix mille domaines et si l'un répond, il gagne. Le coût par tentative est pratiquement nul.

Le défenseur, en revanche, n'automatise presque jamais. Si vous gérez un site sans aide extérieure, le plus probable est que vous ne regardez même pas les logs du serveur — et si vous le faites, vous tombez sur des milliers de lignes mêlant requêtes légitimes et déchets automatisés. Distinguer le signal du bruit à la main ne passe pas à l'échelle.

C'est cela l'asymétrie : un côté opère à la vitesse de la machine, l'autre à la vitesse d'un humain qui lit du texte. Tant que ce déséquilibre se maintient, le temps joue toujours en faveur de l'attaquant.

Ce que vous pouvez faire (sans devenir sysadmin)

La solution n'est pas d'étudier la sécurité. La solution est de mettre le défenseur sur un pied d'égalité : qu'il automatise lui aussi. Qu'il reconnaisse les requêtes hostiles, bloque les user-agents connus, bannisse les IPs qui répètent des schémas d'attaque, et limite les dégâts avant qu'ils n'atteignent votre code.

Cela n'a pas besoin d'être cher. Ni complexe. Les pièces de base sont :

• Un filtre d'entrée qui rejette les requêtes manifestement malveillantes avant qu'elles ne touchent votre application.
• Un registre de trafic qui sépare humains, bots vérifiés (Google, Bing) et requêtes suspectes — dans une vue lisible en 30 secondes.
• Une liste de blocage d'IPs déjà identifiées comme hostiles, maintenue automatiquement.
• Une forme d'alerte lorsque quelque chose hors de l'ordinaire apparaît — pour ne pas avoir à entrer dans le panneau tous les jours.

Avec cela, vous avez résolu la majeure partie du problème. Le reste, ce sont les attaques ciblées, qui sont une autre conversation et, honnêtement, bien moins fréquentes que le bruit de fond continu.

Conclusion

Si votre site est en ligne, il est en train d'être scanné. Cela ne va pas changer — c'est la nouvelle normalité du web public. Ce qui peut changer, c'est ce qui se passe quand ce trafic arrive : s'il entre sans filtre jusqu'à votre code ou s'il reste à la porte.

La différence entre un site compromis et un site sécurisé n'est que rarement le talent de l'attaquant. Presque toujours, c'est de savoir si le défenseur a pris la peine de fermer la porte avant d'aller se coucher.