Attaques par IA : ce qui change et ce qui protège toujours

Depuis 2025, il est établi que les attaquants n'utilisent plus seulement les modèles de langage pour rédiger des e-mails de phishing extrêmement crédibles, mais qu'ils leur font aussi exécuter des attaques à prendre très au sérieux. Pour l'exploitation de sites web et de serveurs, cela change pourtant moins de choses que ne le laissent entendre bien des gros titres — sur un point, en revanche, cela change beaucoup : la vitesse.

Ce qui est établi

En novembre 2025, Anthropic, l'éditeur du modèle de langage Claude, a décrit la première campagne d'attaque documentée exécutée en majeure partie par une IA. Un groupe soutenu par un État a attaqué une trentaine d'organisations. Parmi elles, des entreprises technologiques, des établissements financiers et des administrations publiques. Selon l'analyse d'Anthropic, l'IA a accompli 80 à 90 % du travail, des humains ne prenant que ponctuellement des décisions. Dans un petit nombre de cas, l'intrusion a effectivement réussi.¹

Un peu moins d'un an plus tard, ce n'est plus un cas isolé. Le rapport d'Anthropic de septembre 2026 décrit des intrusions bouclées en quelques heures et des attaquants isolés qui visaient des dizaines de cibles en parallèle. Un cas concerne directement les sites web : un attaquant seul a développé, avec l'aide de l'IA, une attaque contre une faille jusque-là inconnue touchant la réinstallation de WordPress. Il est ainsi parvenu à créer un compte administrateur sans identifiants valides — avec succès sur au moins quatre sites. Il a en outre manipulé les sauvegardes d'une victime de sorte qu'une restauration lui aurait immédiatement rouvert l'accès au système.²

En mai 2026, le Threat Intelligence Group de Google a découvert pour la première fois une faille zero-day qui, selon son évaluation, avait été développée avec l'IA : un contournement de l'authentification à deux facteurs dans un outil open source répandu d'administration système par navigateur, destiné à une attaque de masse. Ce code d'attaque a été intercepté dès la phase de planification, avant d'être utilisé. Ce que Google décrit dans ces deux rapports, c'est une autonomie sur certaines étapes — des agents qui trouvent des failles par eux-mêmes et des logiciels malveillants qui poursuivent leur travail de façon autonome sur un appareil déjà compromis —, et non une attaque complète que plus personne ne pilote.^{3, 4}

Mais cette même capacité est aussi à la disposition des défenseurs. En 2025, Big Sleep, l'agent IA de Google, a découvert dans la base de données SQLite une faille critique qui, selon Google, n'était connue que d'attaquants. Cela n'aide toutefois que ceux qui installent ensuite effectivement le correctif.⁵

Ce qui change : la vitesse et le volume

Une attaque se compose de nombreuses petites étapes : trouver des services, identifier des versions, chercher une faille adaptée, ajuster le code d'attaque, analyser les réponses, continuer. Jusqu'ici, la plupart d'entre elles exigeaient des personnes expérimentées et du temps. Un modèle de langage en accomplit une bonne partie en quelques secondes, jour et nuit et contre de nombreuses cibles à la fois.

C'est dans le délai entre la divulgation d'une faille et son exploitation que cela se voit le plus nettement. Mandiant, la division de réponse aux incidents de Google, a mesuré ce délai à 63 jours en moyenne en 2018 et 2019, et à seulement cinq en 2023. Dans le rapport M-Trends 2026, la valeur moyenne estimée est de moins sept jours : les failles sont régulièrement exploitées avant même qu'un correctif existe. L'évolution a commencé avant l'IA, mais l'IA l'accélère.^{6, 7}

En juin 2026, l'Office fédéral allemand de la sécurité des technologies de l'information (BSI) constate qu'avec l'IA, il suffit de quelques minutes à quelques heures pour déduire d'un correctif publié à quoi doit ressembler une attaque. Sa conclusion : les organisations doivent être en mesure de passer en revue les vulnérabilités, de les évaluer et, si nécessaire, d'installer les correctifs en quelques minutes à quelques heures au plus. Quelques jours ne constitueraient pas un délai de réaction approprié.⁸

Le deuxième changement concerne le choix des cibles. Lorsqu'une attaque demande moins de travail, des cibles jusqu'ici trop petites deviennent elles aussi intéressantes — c'est précisément ce glissement que décrit Anthropic. L'idée qu'un petit site web n'intéresse pas les attaquants a toujours été hasardeuse. Aujourd'hui, elle est tout simplement fausse : les attaques automatisées ne choisissent pas forcément leurs cibles selon leur importance, mais selon leur accessibilité.²

Ce qui ne change pas : pourquoi les attaques aboutissent

Ce qui frappe, c'est ce qui manque dans ces rapports : de nouvelles techniques d'attaque. Anthropic écrit explicitement qu'aucune des opérations décrites ne reposait sur une technique que les défenseurs n'auraient jamais vue. Ce sont les portes d'entrée connues — identifiants volés, équipements non mis à jour en bordure de réseau, services accessibles sans protection, code de base de données injecté (injection SQL), phishing. Mandiant arrive à la même conclusion pour 2025 : la grande majorité des intrusions réussies découle toujours d'erreurs humaines et systémiques élémentaires, et non de l'IA elle-même.^{2, 7}

Pour les sites web, un chiffre est particulièrement révélateur : selon VulnCheck, les systèmes de gestion de contenu représentaient au premier semestre 2026 un tiers de toutes les vulnérabilités que VulnCheck a nouvellement inscrites sur sa liste des failles activement exploitées. Chaque extension installée sans être nécessaire agrandit la surface d'attaque sans rien apporter.⁹

D'où le message central de cet article : contre les attaques par IA, il ne faut pas forcément un nouveau type de protection. Ce qui a toujours été efficace l'est encore. Mais nous devons aujourd'hui repenser la sécurité : sans angle mort, automatisée et surveillée avec constance.

Des couches plutôt qu'une arme miracle

Malheureusement, nous ne pouvons pas citer ici une mesure unique dont la mise en œuvre réglerait tous les problèmes et rendrait tous les systèmes sûrs. Nous misons donc sur un modèle en couches : chaque couche en intercepte une partie, et chacune part du principe que la précédente a échoué. C'est ainsi que nous exploitons les sites web et les applications que nous hébergeons pour nos clients, ainsi que les nôtres. Les sections suivantes présentent ces couches en détail.

En bordure (« edge ») : pare-feu applicatif web et CrowdSec

Chaque requête adressée à l'un de nos services web accessibles publiquement passe d'abord par un pare-feu applicatif web (Web Application Firewall, WAF) : ModSecurity avec l'OWASP Core Rule Set, un ensemble de règles maintenu en commun (par une communauté mondiale) contre les schémas d'attaque courants — code de base de données injecté, scripts étrangers, accès à des fichiers hors de la zone autorisée. Les règles reconnaissent des schémas, et non telle ou telle vulnérabilité précise. Elles arrêtent donc aussi une partie des attaques visant des vulnérabilités pour lesquelles il n'existe pas encore de correctif. Nous gagnons ainsi un temps dont nous ignorions encore que nous aurions besoin.

En parallèle, CrowdSec analyse les journaux et repère des comportements plutôt que des requêtes isolées : qui cherche systématiquement des interfaces d'administration, essaie des mots de passe à la chaîne ou sonde des serveurs à la recherche de failles connues. Ces adresses sont bloquées avant d'atteindre le site web. S'y ajoute le réseau : quiconque utilise CrowdSec partage les attaques détectées et reçoit en retour une liste de blocage maintenue en commun. Une adresse qui attaque ailleurs peut ainsi être déjà bloquée chez nous avant même d'envoyer sa première requête.

Cela fonctionne particulièrement bien contre l'automatisation, car l'automatisation laisse des traces. Qui envoie des milliers de requêtes en peu de temps crée un schéma — que ce soit un humain avec un script ou un modèle de langage qui se cache derrière.

Sur le serveur : uniquement le nécessaire

Les accès SSH à nos serveurs sont impossibles par mot de passe, impossibles en tant que « root » et impossibles avec n'importe quel utilisateur. Ils ne sont possibles qu'avec une clé cryptographique, et seulement pour les quelques utilisateurs définis à l'avance qui ont le droit de se connecter ; les adresses qui se sont signalées ailleurs par des attaques sont rejetées par le pare-feu avant même cette étape. Et celui-ci ne laisse par principe rien entrer : seul ce qui est réellement nécessaire est ouvert. Nous gérons les accès de manière centralisée, et quiconque n'en fait plus partie les perd sur tous les serveurs. Tout cela est déployé sous forme d'Infrastructure as Code (IaC) et configuré de manière identique sur chaque serveur, jamais à la main.

Contre l'essai systématique de mots de passe — l'une des premières tâches que l'on peut confier à une machine —, la parade n'est donc pas un meilleur mot de passe, mais l'absence de mot de passe.

Dans le conteneur : le moins de droits possible

Les applications elles-mêmes tournent chacune de manière isolée dans des conteneurs, et chacun d'eux ne dispose que des droits dont il a besoin pour fonctionner : le système de fichiers est en lecture seule, à l'exception des répertoires où des données doivent être stockées. Le conteneur ne tourne par principe jamais avec les droits root, dispose d'une limite fixe de mémoire vive et se trouve dans son propre réseau, séparé des conteneurs des autres clients. Qui exploite une faille dans l'application ne peut pas écraser le code du programme et n'a pas non plus de moyen direct de communiquer avec les conteneurs d'autres clients pour les compromettre.

Ce qui ne se trouve pas du tout dans le conteneur est tout aussi important. Les outils nécessaires à la construction, mais pas à l'exploitation, n'y ont rien à faire. En septembre 2026, le simple retrait du gestionnaire de paquets et de ses utilitaires de l'image de notre propre site web a fait disparaître 38 résultats de gravité critique ou élevée du scanner de vulnérabilités. Sans parler du fait que l'absence d'outils entrave, voire empêche, les tentatives de compromission. Car ce qui n'est pas disponible ne peut pas être exploité.

En exploitation : savoir plutôt que supposer

Un serveur n'est pas sûr parce qu'il l'était au moment de sa mise en place. Chaque nuit, un scanner (Trivy) vérifie les paquets installés sur tous les serveurs ainsi que toutes les images de conteneurs en service à la recherche de vulnérabilités connues. Les mises à jour de sécurité des serveurs s'installent automatiquement chaque jour ; si l'une d'elles reste en attente plus d'un cycle, la surveillance donne l'alerte.

C'est ainsi qu'en septembre 2026, nous avons ramené l'image de notre propre site web de 5 vulnérabilités critiques et 51 élevées à zéro — mesuré, pas estimé.

Une fenêtre de temps subsiste néanmoins : entre la publication d'une faille et la mise à jour suivante, et à plus forte raison avant cette publication. Aucun processus de mise à jour ne peut la refermer complètement. C'est précisément pour cette fenêtre qu'existent les autres couches — le WAF, qui reconnaît des schémas d'attaque sans connaître la faille, et les droits restreints, qui limitent les dégâts qu'une attaque réussie peut causer.

En cas d'incident : des sauvegardes qu'un attaquant ne peut pas supprimer

Qui a pris le contrôle d'un serveur tente souvent ensuite de supprimer ou de modifier les sauvegardes ; le cas WordPress évoqué plus haut montre à quoi cela ressemble. Nos sauvegardes sont chiffrées, stockées sur un autre serveur et écrites en mode « append-only » : un serveur sauvegardé peut ajouter de nouvelles sauvegardes, mais ne peut ni supprimer ni écraser celles qui existent. Les versions antérieures sont ainsi conservées, même si un attaquant contrôle entièrement ce serveur.

Cela ne suffit pas à soi seul : encore faut-il savoir quelle version est saine. Pour cela, les journaux de la bordure, des serveurs et des applications sont centralisés sur un serveur dédié ; ils montrent depuis quand quelqu'un était présent. Et nous avons répété la restauration. Des sauvegardes qui ne sont jamais réellement validées dans leur intégralité relèvent davantage de l'espoir que de la sécurité.

Une protection qui frappe les mauvaises personnes

Chacune de ces couches peut aussi toucher de vrais visiteurs. En août 2026, la couche de protection en bordure a exclu de notre propre site web certains visiteurs, à chaque fois pour une journée entière. En cause, un seul fichier manquant : la petite icône de l'onglet du navigateur (favicon) faisait défaut, chaque consultation de page générait donc un message d'erreur, autrement dit renvoyait une erreur 404, et une règle prédéfinie considérait un nombre suffisant d'erreurs 404 dans un laps de temps donné comme une attaque. Cette règle a depuis été ajustée, de sorte qu'une erreur 404 occasionnelle n'entraîne plus directement le blocage d'un visiteur de bonne foi.

La même semaine, la première analyse a montré qui consulte réellement les sites web que nous exploitons. Une liste de blocage fournie d'office rejetait pratiquement toutes les requêtes de services d'IA — en une seule journée, environ 370 d'entre elles provenaient de clients qui se présentaient comme ChatGPT agissant à la demande d'une personne : pas un robot d'exploration (crawler) qui collecte des contenus, mais un service qui voulait lire l'une de ces pages pour formuler une réponse. Pour une entreprise qui veut rendre ses clients visibles dans les réponses de l'IA, c'était clairement la mauvaise protection. Depuis, nous décidons nous-mêmes, site par site, si des services d'IA peuvent lire un site : pas du tout, uniquement à la demande d'une personne, ou entièrement (crawlers compris).

Ni l'un ni l'autre ne sont des anecdotes. Une protection qui exclut de vrais visiteurs est contre-productive et finit tôt ou tard par être désactivée complètement, pour ne plus perdre de clients. Ce n'est pas le but recherché. Et bloquer systématiquement tout ce qui ressemble à une machine n'est pas une stratégie de sécurité, mais une décision contre sa propre visibilité et sa capacité à être trouvé.

Ce que vous pouvez vérifier vous-même

Les questions suivantes permettent d'évaluer si vos propres systèmes sont bien armés. Chaque question à laquelle vous ne pouvez pas répondre immédiatement, ou pas vraiment avec précision, signale un besoin d'agir.

• Qu'est-ce qui est accessible depuis l'extérieur ? Les interfaces d'administration utilisées surtout en interne, les bases de données et les autres connexions par mot de passe n'ont rien à faire en accès libre sur Internet.
• Comment détectez-vous que l'un de vos systèmes présente une faille de sécurité ?
• En combien de temps une mise à jour de sécurité arrive-t-elle réellement sur vos systèmes — et comment savez-vous qu'elle a bien été appliquée ?
• Y a-t-il, devant l'application, un dispositif qui reconnaît les schémas d'attaque et intervient avant que l'application elle-même ne soit atteinte ?
• Avec quels droits l'application tourne-t-elle, et en a-t-elle vraiment besoin ?
• Existe-t-il une sauvegarde que même une personne disposant de tous les droits sur le serveur ne peut pas supprimer ? À quand remonte la dernière restauration à partir de celle-ci ?
• Qui est alerté lorsque quelque chose d'anormal se produit — et qui décide de la suite ?

L'IA a rendu les attaques plus rapides et moins chères, pas imparables. Ce qui protège contre elles reste ce qui protégeait avant. Encore faut-il le mettre en œuvre et le surveiller sans angle mort.