Sécuriser un site internet contre les robots : ce qu’on peut vraiment automatiser

Un site en ligne reçoit rapidement des visites automatisées.

Certaines sont normales : moteurs de recherche, outils de supervision, services techniques.

D’autres cherchent des pages d’administration, testent des formulaires ou sondent des logiciels connus.

Le bon réflexe n’est donc pas de vouloir bloquer tous les robots.

Il faut surtout savoir ce qui se passe sur le site, repérer les comportements anormaux et faire remonter les alertes utiles à quelqu’un.

L’automatisation — et parfois l’IA — peut aider à faire ce travail sans passer ses journées dans les journaux du serveur.

Tous les robots ne font pas la même chose

Le mot « robot » recouvre des usages très différents.

Les robots des moteurs de recherche. Googlebot et les autres robots d’indexation parcourent les pages pour les ajouter aux moteurs de recherche. Les bloquer sans raison peut rendre le site beaucoup moins visible.

Les robots d’exploration. Certains parcourent le web pour copier du contenu, alimenter des bases de données ou analyser les sites. Ils ne cherchent pas forcément à provoquer une intrusion.

Les robots de reconnaissance. Ils testent des chemins connus pour essayer de deviner ce qui est installé : pages d’administration, extensions répandues, fichiers connus, anciennes URL. Ils cherchent surtout à savoir si une cible potentielle existe.

Les robots qui exploitent des failles. Lorsqu’une vulnérabilité devient publique, des outils automatisés peuvent ensuite tester les sites susceptibles d’utiliser la version concernée.

Les robots qui abusent des formulaires. Un formulaire mal protégé peut également être utilisé pour envoyer du spam ou provoquer un grand nombre d’envois.

Le premier travail consiste donc à distinguer les comportements, plutôt qu’à considérer tout trafic automatisé comme hostile.

Ce qu’il est utile de surveiller

La sécurité d’un site ne se résume pas à installer une extension ou un pare-feu.

Plusieurs sources permettent de comprendre ce qui se passe réellement.

Les journaux du serveur

Chaque requête reçue laisse généralement une trace :

• adresse IP ;
• URL demandée ;
• heure ;
• code de réponse ;
• navigateur déclaré.

Sur un site actif, ces journaux peuvent rapidement contenir beaucoup de lignes.

Ils deviennent intéressants lorsqu’on cherche des comportements inhabituels :

• une même adresse qui demande de nombreuses pages inexistantes ;
• des tentatives répétées vers une administration qui n’existe pas ;
• une fréquence de requêtes anormale ;
• une succession de codes d’erreur.

Une analyse automatisée peut faire ressortir ces motifs beaucoup plus facilement qu’une lecture manuelle.

Les composants installés

Un site moderne dépend souvent de bibliothèques, thèmes, modules ou extensions.

Lorsque l’une d’elles fait l’objet d’un avis de sécurité, il faut savoir si :

1. elle est réellement installée ;
2. la version utilisée est concernée ;
3. la fonctionnalité vulnérable est utilisée ;
4. une mise à jour existe.

L’automatisation est très utile pour comparer régulièrement les versions installées avec les avis publiés.

En revanche, décider de l’urgence ou de la méthode de mise à jour demande souvent une analyse humaine.

L’intégrité des fichiers

Un site peut continuer à fonctionner alors qu’un fichier inattendu a été ajouté ou modifié.

Un moyen simple de surveiller cela consiste à conserver une empreinte des fichiers publiés.

Après un déploiement ou à intervalles réguliers, le système peut comparer l’état actuel à l’état attendu.

Une différence n’est pas forcément une attaque : elle peut venir d’une mise à jour ou d’un changement volontaire.

Mais elle mérite d’être expliquée.

C’est typiquement un contrôle simple à automatiser.

Les formulaires

Le formulaire de contact mérite une surveillance particulière.

Le risque n’est pas uniquement le spam reçu.

Il faut aussi éviter qu’un mécanisme d’envoi soit utilisé de manière excessive ou détournée.

Quelques contrôles simples sont utiles :

• limiter la fréquence des envois ;
• filtrer les comportements manifestement automatisés ;
• conserver une trace des envois ;
• déclencher une alerte lorsqu’un seuil est dépassé.

Et surtout : vérifier régulièrement que les messages légitimes arrivent encore.

Un formulaire qui affiche « message envoyé » alors qu’aucun mail n’arrive est une panne particulièrement discrète.

La disponibilité ne suffit pas

Un contrôle qui vérifie uniquement que le serveur répond peut donner un faux sentiment de sécurité.

Une page modifiée ou remplacée peut parfaitement répondre avec un code HTTP normal.

Il est donc possible de vérifier aussi le contenu attendu :

• le titre du site ;
• une adresse ;
• un élément important ;
• une portion de texte stable.

Ainsi, le contrôle ne vérifie pas seulement que le serveur répond.

Il vérifie qu’il répond avec le bon contenu.

Et l’IA dans tout ça ?

L’IA peut être utile pour trier et interpréter des informations qui seraient longues à relire manuellement.

Par exemple :

• résumer une série de logs ;
• regrouper des erreurs similaires ;
• expliquer un avis de vulnérabilité ;
• repérer certaines anomalies dans du code ;
• produire un premier diagnostic à partir de plusieurs signaux.

Mais elle ne « sécurise » pas un site toute seule.

Elle aide surtout à réduire le volume d’informations à lire.

Ce que l’IA peut bien faire

Elle est efficace pour repérer des motifs connus :

• données non validées ;
• sorties non échappées ;
• secrets oubliés dans le code ;
• permissions trop larges ;
• répétitions anormales dans les journaux ;
• changements inhabituels.

Elle peut également aider à classer une alerte par niveau de priorité.

Ce qu’elle fait moins bien

Les défauts de logique restent beaucoup plus difficiles.

Un système peut être techniquement correct et pourtant mal conçu :

• une autorisation vérifiée au mauvais moment ;
• un utilisateur autorisé à faire une action qu’il ne devrait pas pouvoir faire ;
• un changement légitime interprété comme suspect ;
• un pic de trafic normal pris pour une attaque.

Ce type de décision nécessite de comprendre le fonctionnement du métier et le contexte.

Automatiser les contrôles, pas les décisions importantes

C’est la distinction la plus utile.

Ce qui s’automatise très bien :

• tester que le site répond ;
• vérifier un contenu attendu ;
• surveiller les erreurs ;
• comparer l’intégrité des fichiers ;
• contrôler les versions de dépendances ;
• détecter des pics inhabituels ;
• conserver des journaux ;
• envoyer une alerte.

Ce qui doit rester humain :

• décider de bloquer une source ;
• évaluer si une mise à jour est urgente ;
• déterminer si un changement est légitime ;
• interpréter une alerte ambiguë ;
• restaurer un site après incident ;
• arbitrer entre sécurité, disponibilité et fonctionnement métier.

Une automatisation sert à faire remonter le problème plus vite.

Elle ne remplace pas la personne qui doit décider quoi faire ensuite.

Le plus important : que quelqu’un reçoive l’alerte

Un contrôle parfait qui produit un rapport que personne ne lit ne protège pas grand-chose.

Il faut donc réfléchir dès le départ à la chaîne complète : détection → alerte → destinataire → action.

Selon le site, cela peut être :

• un email ;
• une notification ;
• un ticket ;
• une alerte sur téléphone.

Le bon niveau dépend surtout de l’impact d’une panne ou d’une intrusion.

Tous les sites n’ont pas besoin de la même surveillance

Un petit site vitrine et une boutique en ligne n’ont pas les mêmes enjeux.

Type de site	Ce qu’il faut au minimum surveiller
Site vitrine	disponibilité, sauvegardes, formulaire
Site avec formulaires importants	+ traces des envois, seuils et alertes
Boutique en ligne	+ commandes, paiements, intégrité et dépendances
Site avec comptes clients	+ accès, journaux et anomalies d’authentification

Plus les conséquences d’une panne sont importantes, plus la surveillance doit être réactive.

Ce n’est pas la taille du site qui décide du niveau de contrôle.

C’est ce qu’il se passe lorsqu’il ne fonctionne plus.

Les faux positifs sont aussi un problème

Un système qui alerte trop souvent finit généralement par être ignoré.

Si chaque jour produit dix messages « urgents » qui ne nécessitent aucune action, le jour où un vrai problème apparaît, il risque de passer au milieu du bruit.

Il vaut mieux un dispositif plus simple dont les alertes sont réellement utiles.

L’objectif n’est pas de tout détecter.

C’est de faire en sorte que chaque alerte mérite d’être ouverte.

Ce que la surveillance ne remplace jamais

Les sauvegardes. Détecter qu’un site a été modifié ne permet pas de le restaurer. Il faut donc conserver des sauvegardes séparées du système qu’elles protègent. Et surtout, vérifier au moins une fois qu’elles peuvent réellement être restaurées. Une sauvegarde jamais testée reste une promesse.

Les mises à jour. Surveiller un site obsolète ne le rend pas sûr. Les versions du CMS, des extensions et des dépendances doivent continuer à être maintenues.

La relecture humaine. Une automatisation peut signaler un changement. Elle ne sait pas toujours si ce changement est normal.

La surveillance ne remplace donc pas la maintenance.

Elle permet surtout de savoir plus vite quand il faut intervenir.

L’IA peut aussi produire du mauvais code

C’est un point important.

Un outil capable d’aider à relire du code peut aussi produire du code imparfait.

Une fonction générée automatiquement doit être relue, testée et soumise aux mêmes contrôles que du code écrit autrement.

Le fait qu’un morceau de code ait été produit rapidement ne le rend ni sûr ni correct.

Que faire si quelque chose semble anormal ?

La priorité est de préserver les informations utiles avant de tout modifier.

Dans la mesure du possible :

1. conserver les journaux disponibles ;
2. noter l’heure à laquelle le problème a été découvert ;
3. sauvegarder l’état actuel ;
4. vérifier les modifications récentes ;
5. isoler ou désactiver ce qui est manifestement compromis ;
6. restaurer depuis une sauvegarde saine si nécessaire ;
7. comprendre la cause avant de remettre le site dans le même état qu’avant.

Sur un incident sérieux, il vaut mieux éviter de « nettoyer au hasard », car certaines traces utiles peuvent disparaître.

Questions fréquentes

Un petit site est-il vraiment concerné ?

Oui, parce que beaucoup de scans sont automatisés et ne ciblent pas spécialement une entreprise.

Cela ne signifie pas qu’un petit site subit la même pression qu’une grande plateforme.

Cela signifie simplement que sa faible audience ne suffit pas à le rendre invisible aux outils automatisés.

Faut-il bloquer tous les robots ?

Non.

Certains sont nécessaires au fonctionnement normal du web, notamment les robots des moteurs de recherche.

Le filtrage doit se faire selon le comportement et le besoin réel.

L’IA peut-elle sécuriser le site seule ?

Non.

Elle peut analyser, trier et signaler.

Les décisions importantes restent humaines.

À quelle fréquence faut-il surveiller ?

Il n’existe pas une fréquence unique pour tous les contrôles.

Certains tests sont simples à exécuter souvent, comme la disponibilité.

D’autres peuvent être effectués quotidiennement, hebdomadairement ou lorsqu’une nouvelle vulnérabilité est publiée.

La fréquence doit surtout dépendre du risque et de l’impact d’une panne.

Que faire après une intrusion ?

Préserver les journaux et les sauvegardes avant de modifier massivement le système, puis identifier l’origine de l’incident et corriger la cause.

Si le site traite des données sensibles ou si l’incident est important, il peut être nécessaire de faire intervenir un spécialiste.

Ce qu’il faut retenir

Sécuriser un site ne consiste pas à installer un outil une fois pour toutes.

Il faut surtout :

• maintenir le logiciel à jour ;
• conserver des sauvegardes fiables ;
• surveiller les fonctions importantes ;
• repérer les anomalies ;
• et s’assurer qu’une alerte arrive réellement à quelqu’un.

L’automatisation est excellente pour les contrôles répétitifs.

L’IA peut aider à lire et trier les informations.

Mais les décisions importantes restent humaines.

Bleupixel conçoit, maintient et surveille des sites internet depuis Buis-les-Baronnies, en Drôme et dans le Vaucluse.

Si vous avez déjà un site et que vous ne savez pas exactement ce qui est sauvegardé, surveillé ou vérifié, c’est probablement le meilleur point de départ.