La sécurité des sites web à l'ère de l'IA

Une entreprise qui n'a jamais déployé la moindre intelligence artificielle (IA) n'a pourtant plus le même niveau d'exposition qu'il y a un an, parce que ceux qui attaquent son site, eux, ont adopté la technologie. L'intelligence artificielle atteint votre site que vous l'ayez voulu ou non, par les attaquants qui trouvent désormais des failles en quelques heures au lieu de plusieurs mois, par les prestataires qui écrivent votre code avec elle, et par les fonctionnalités arrivées dans des logiciels que vous utilisiez déjà. En juillet 2026, un chercheur de Searchlight Cyber a annoncé avoir découvert une chaîne de vulnérabilités critiques dans le cœur de WordPress avec l'aide d'un modèle, en un peu plus de 10 heures et pour environ 25 dollars d'abonnement. L'éditeur de sécurité Patchstack a ensuite relevé les premières tentatives d'exploitation réelles contre des sites en production environ 90 minutes après la publication du correctif. Aucune des entreprises prises dans cette fenêtre n'avait de stratégie en matière d'intelligence artificielle.

Cet article traite de la sécurité des sites web à l'ère de l'IA et s'adresse au dirigeant ou au responsable technique d'un site ordinaire, du genre construit sur un gestionnaire de contenu, avec quelques extensions, quelques intégrations, et une agence ou une petite équipe interne qui le maintient. Il part du principe que vous n'avez pris aucune décision concernant l'intelligence artificielle. La démarche est volontairement neutre et ne recommande aucun outil, ce qui vous permet de l'appliquer avec ceux qui s'occupent déjà de votre site.

En résumé

Les attaquants trouvent aujourd'hui des failles à un coût si faible que le délai entre la publication d'un correctif et son exploitation se compte en heures, et dans le cas WordPress de juillet 2026 il a été de 90 minutes. Les prestataires qui construisent et maintiennent votre site ont adopté les mêmes outils, et les tests menés par Veracode en 2026 situent à 55 % le taux de code généré qui passe les contrôles de sécurité. La plupart des organisations ont par ailleurs hérité de fonctionnalités d'intelligence artificielle sans jamais l'avoir décidé, par des extensions qui en ont ajouté lors d'une mise à jour et par des collaborateurs qui utilisent des outils publics avec des données de l'entreprise.

Les trois voies par lesquelles l'intelligence artificielle atteint la sécurité de votre site

Si l'intelligence artificielle modifie votre exposition sans votre participation, c'est qu'elle a rendu bon marché trois choses qui coûtaient cher, et que ces trois choses se situent en amont de votre site et non à l'intérieur. Trouver une vulnérabilité supposait auparavant de payer plusieurs semaines un spécialiste rare, et livrer un agent conversationnel supposait de financer une équipe de recherche. Les deux sont désormais à la portée de n'importe quelle entreprise, tout comme la production de code au millier de lignes. Cet effondrement des coûts s'est produit sur environ deux ans, entre les premiers modèles de génération de code largement diffusés et l'outillage agentique de 2026, et vos attaquants, vos prestataires et vos éditeurs vous en répercutent chacun une part.

L'essentiel de ce qui s'écrit sur la sécurité de l'intelligence artificielle traite d'un autre sujet. Ces publications s'adressent aux organisations qui construisent elles-mêmes des systèmes autonomes et portent sur la protection des modèles, des agents et des droits qu'on leur confie. Ce travail est capital pour celles qui sont concernées, et l'Open Worldwide Application Security Project a publié le 9 décembre 2025 un Top 10 dédié aux applications agentiques précisément pour ce public. Rien de tout cela ne décrit ce qui atteint un site vitrine, un espace adhérents ou une boutique en ligne dont le propriétaire n'a jamais ouvert de compte chez un fournisseur de modèles.

Les trois voies, ce que chacune change et les données qui l'établissent :

Première voie : vos attaquants utilisent l'intelligence artificielle

Vos attaquants vous atteignent en premier car le coût de la recherche de vulnérabilités a considérablement baissé, ce qui a raccourci le délai entre la publication d'un correctif et son exploitation. La démonstration la plus nette est arrivée en juillet 2026. Adam Kues, chercheur chez Searchlight Cyber, a analysé le cœur de WordPress avec un modèle de langage commercial et y a trouvé deux failles qui, combinées, aboutissent à une compromission totale. La première est une confusion de routage dans le point d'entrée de traitement par lots de l'interface de programmation REST, la seconde une injection SQL dans un paramètre de requête. Enchaînées, elles permettent à un attaquant non authentifié d'exécuter du code sur une installation par défaut, sans la moindre extension.

Adam Kues indique que le travail a demandé un peu plus de 10 heures de calcul et coûté environ 25 dollars, calculés au prorata d'un abonnement mensuel. Selon ses propres termes, qui restent l'affirmation de celui qui a mené le travail et non un constat indépendant, « aucun chercheur en sécurité n'aurait pu trouver et finaliser cette chaîne d'exploitation en 10 heures sans IA ». Il mentionne aussi, presque en passant, qu'il a mis plus de temps à comprendre l'exploit que le modèle n'en a mis à le produire. Mais ce qu'on retient c'est que pour 25 dollars, n'importe qui peut trouver une faille sur n'importe quel site web ou infrastructure, y compris les vôtre.

WordPress a publié des correctifs sur trois branches le 17 juillet 2026 et activé les mises à jour forcées sur les installations concernées. Patchstack a relevé les premières tentatives d'exploitation réelles environ 90 minutes après la mise en ligne de la version corrigée, et près de trois heures après la publication du correctif dans le dépôt. En quelques jours, l'éditeur avait bloqué plus de 65 000 tentatives provenant de plus de 1 500 adresses distinctes, dans leur écrasante majorité dirigées vers le seul point d'entrée vulnérable. Le 21 juillet 2026, l'agence américaine de cybersécurité CISA a ajouté les deux vulnérabilités à son catalogue des failles activement exploitées, confirmant une exploitation réelle.

La publication d'un correctif est devenue le coup d'envoi des attaques et non la fin du risque. Les attaquants lisent les correctifs publiés pour savoir exactement ce qui a changé, et l'assistance par modèle rend cette lecture ultra rapide. Rien de tout cela n'est propre à WordPress, et rien n'indique que WordPress soit moins sûr qu'un autre. Le projet a reçu un signalement coordonné, publié des correctifs sur toutes les branches maintenues le même jour, puis les a poussés automatiquement, ce qui s'approche le plus de la meilleure réponse dont dispose une plateforme. N'importe quel système largement déployé subirait la même arithmétique, et cette conclusion n'est pas la nôtre seule. The Hacker News défendait le même argument en juillet 2026, et plusieurs éditeurs de sécurité y sont parvenus de leur côté durant les mêmes mois.

Un processus de mise à jour conçu autour de quelques jours de marge ne correspond donc plus à la réalité. Si votre site est mis à jour quand quelqu'un trouve le temps de s'en occuper, ou lors d'une visite de maintenance mensuelle, la période pendant laquelle vous êtes exposé est exactement celle de l'exploitation de masse. Nous avons consacré un article à ce à quoi ressemble un vrai processus de mise à jour, et la mécanique vaut d'une plateforme à l'autre. Le rythme qui paraissait prudent il y a deux ans est devenu le risque lui-même.

Deuxième voie : vos prestataires et vos dépendances utilisent l'intelligence artificielle

Vos prestataires vous atteignent en second, parce que ceux qui écrivent le code dont vous dépendez ont adopté l'intelligence artificielle plus vite que les pratiques de relecture n'ont mûri autour. C'est la chaîne d'approvisionnement logicielle, et l'intelligence artificielle en touche désormais chaque maillon. Cela concerne votre agence, les auteurs de chaque extension et de chaque module installés sur votre site, et les mainteneurs des paquets open source qui se trouvent en dessous. Vous n'avez choisi aucun des outils qu'ils emploient.

Le constat mesuré n'a rien de catastrophique mais rien de rassurant non plus. Veracode a évalué plus de 150 modèles de langage sur la génération de code, en les testant sur quatre familles de vulnérabilités courantes dont l'injection SQL et le cross-site scripting, et son analyse de 2026 conclut que seules 55 % des générations produisent du code sûr. La justesse syntaxique, elle, dépasse désormais 95 %, tandis que le taux de réussite en sécurité reste, selon les mots de l'éditeur, « pratiquement identique à ce qu'il était il y a deux ans ».

Le code généré compile, s'exécute, passe un test fonctionnel et paraît tout à fait convenable en relecture, tout en portant un défaut qui ne se manifeste qu'en conditions d'attaque. C'est le pire des deux modes de défaillance, car un code cassé se signale dès le premier test et se corrige sur-le-champ. Un code qui fonctionne avec une faille discrète part en production et y reste jusqu'à ce que quelqu'un l'attaque.

Un second effet joue sur votre arbre de dépendances. Des chercheurs présentant leurs travaux à USENIX Security 2025 ont généré 2,23 millions d'échantillons de code avec 16 modèles et ont constaté que 19,7 % d'entre eux faisaient référence à un paquet logiciel inexistant, avec des taux de 5,2 % pour les modèles commerciaux et 21,7 % pour les modèles ouverts. Les attaquants ont repéré le phénomène et se sont mis à enregistrer ces noms inventés, de sorte qu'un développeur qui suit une suggestion assurée installe du code hostile. Une réévaluation de 2026 portant sur cinq modèles de dernière génération mesure des taux d'hallucination dans une fourchette bien plus étroite, de 4,6 à 6,1 %, le problème s'est donc nettement réduit depuis l'étude initiale. Cette même réévaluation a malgré tout identifié 53 noms de paquets inventés encore disponibles à l'enregistrement après signalement, soit 53 occasions d'attaque opérationnelles. Ce risque de dépôt ouvert est antérieur à l'IA, et Arch Linux a signalé en juin 2026 un volume élevé d'adoptions et de mises à jour malveillantes dans son dépôt communautaire. Ce que l'IA a changé est le nombre de portes d'entrée vers un mécanisme qui existait déjà.

Le réflexe naturel consiste à faire relire ce code par la même technologie, et les outils de revue assistée par IA détectent réellement les schémas de vulnérabilité classiques. Ils produisent aussi du bruit, et ce bruit a un coût que personne ne budgète. Un faux positif ne se distingue d'une vraie faille qu'après vérification humaine, si bien qu'un outil qui signale beaucoup consomme le temps qu'il était censé libérer.

Le projet curl en a fourni la démonstration publique. Daniel Stenberg, son mainteneur, a mis fin le 31 janvier 2026 à un programme de primes aux bugs ouvert depuis avril 2019, qui avait versé plus de 100 000 dollars et permis de corriger 87 vulnérabilités. La cause n'était pas la rareté des signalements mais leur qualité : la part des rapports confirmés, supérieure à 15 % pendant des années, était tombée sous les 5 % en 2025 sous l'afflux de contenus générés par IA. Stenberg décrit le coût en termes humains et non techniques, évoquant une charge mentale sérieuse pour les mainteneurs.

La suite mérite autant d'attention que l'épisode lui-même. Le programme a rouvert dès mars 2026, et Stenberg constatait en avril que le taux de vulnérabilités confirmées était remonté autour de 15 à 16 %, soit son niveau d'avant l'IA, pour un volume de signalements deux fois supérieur à celui de 2025. Le bruit s'est résorbé en quelques mois. La leçon n'est donc pas qu'il faut se méfier de l'IA en développement, mais que ce qui protège est le processus de tri et non l'outil. Une équipe qui fait relire son code par une IA sans que personne n'arbitre les résultats a ajouté du travail sans ajouter de sécurité.

Pour vous, tout se ramène à ce que vous exigez et de qui. Trois points suffisent à situer un prestataire : la relecture du code généré se distingue-t-elle de celle du code écrit à la main, une personne valide-t-elle chaque nouvelle dépendance, et quelqu'un peut-il vous dire de quoi votre site dépend aujourd'hui. La même logique s'applique au choix de la plateforme elle-même, que nous avons traitée dans un article dédié.

Troisième voie : vous en avez déjà ajouté sans l'appeler IA

La troisième voie est celle que la plupart des organisations ont empruntée sans s'en apercevoir, parce que la technologie est arrivée à l'intérieur de choses qu'elles avaient déjà achetées. Une extension a ajouté une fonction de résumé lors d'une mise à jour de routine, le moteur de recherche interne est devenu sémantique sans crier gare, et un agent conversationnel a été mis en ligne parce que le marketing le souhaitait. En parallèle, les équipes se sont mises à utiliser des outils publics pour travailler, ce que les responsables sécurité appellent l'IA fantôme.

L'IA fantôme désigne l'ensemble des outils et des fonctionnalités d'intelligence artificielle en usage dans une organisation sans avoir jamais été examinés, approuvés ni recensés par les personnes chargées de sa sécurité.

Le phénomène est plus répandu que ne le supposent la plupart des dirigeants. Une enquête menée en 2026 par PagerDuty auprès de 1 250 cadres non techniques dans des entreprises réalisant plus de 500 millions de dollars de chiffre d'affaires révèle que 66 % avaient utilisé des outils d'IA au travail tout en pensant que la politique interne l'interdisait. Dans la même enquête, 43 % y avaient saisi des courriers professionnels et 34 % des données clients.

Là où ces fonctionnalités touchent votre site, elles ouvrent une catégorie d'attaques que la sécurité web classique ne couvre pas.

L'injection de prompt est une attaque qui consiste à rédiger le texte soumis à un système d'intelligence artificielle de manière à ce qu'il le traite comme une consigne à exécuter et non comme une donnée à analyser. Si un agent conversationnel installé sur votre site lit vos pages produits, et qu'un attaquant peut influencer l'un des textes qu'il lit, ce texte peut porter des consignes. Il n'existe aucune parade fiable à l'injection de prompt en 2026, la réponse concrète consiste donc à limiter ce qu'un système compromis peut atteindre et non à miser sur le blocage de l'attaque.

Ce que cela soulève est une question de responsabilité. Quelqu'un doit être en mesure de dire quelle IA tourne sur votre site ou autour, à quelles données elle accède, et qui l'a validée. Dans la plupart des organisations, cette question n'a jamais été posée, ce qui signifie que la réponse se découvre pendant un incident.

Pourquoi la prévention n'est pas la réponse

Aucune des trois voies ne peut être fermée par la prévention, car on ne rendra pas la découverte de failles à nouveau coûteuse, aucune équipe ne peut relire toutes les dépendances transitives dont elle hérite, c'est-à-dire les paquets que ses propres paquets entraînent avec eux, et l'injection de prompt n'a aucune parade fiable en 2026. La sécurité des sites web à l'ère de l'IA consiste donc moins à tenir les attaquants dehors qu'à maîtriser ce qui se passe une fois que l'un d'eux est entré. C'est une conclusion inconfortable et ce n'est pas un appel au renoncement, puisqu'elle réoriente l'effort vers ce qui fonctionne encore.

L'écart entre l'admettre et l'appliquer reste considérable. Une étude publiée en juillet 2026 par INE établit que seules 22 % des organisations se sentent préparées à des opérations de cybersécurité marquées par l'IA. Une autre enquête de 2026 menée auprès de 235 responsables sécurité et systèmes d'information de grands groupes montre que 92 % n'ont pas de visibilité complète sur les identités d'intelligence artificielle actives dans leur environnement, et que 95 % doutent de leur capacité à détecter ou contenir l'une d'elles si elle était compromise. Ces deux chiffres décrivent la même défaillance sous deux angles, et dans les deux cas la capacité qui manque relève de la détection et du confinement, pas d'un dispositif de prévention supplémentaire.

L'objectif réaliste est une plateforme où une compromission se remarque en quelques heures et non au bout de plusieurs mois, et où elle ne peut pas dépasser le composant par lequel elle est entrée. Ce recadrage change ce qu'il vaut la peine de financer. Le délai de détection devient un indicateur que vous suivez réellement. Les sauvegardes se vérifient en les restaurant, et pas en constatant que la tâche s'est exécutée. Les accès se cloisonnent pour qu'un composant compromis ne puisse pas atteindre à la fois la base de données, la messagerie et le stockage de fichiers, et la capacité de mise à jour se traite comme une infrastructure permanente capable de réagir en quelques heures, au lieu d'une clause indiquant que les mises à jour sont appliquées rapidement.

Rien de tout cela n'est exotique et rien n'exige une expertise en intelligence artificielle. Il s'agit de discipline opérationnelle ordinaire, appliquée en partant du principe que quelque chose finira par passer. Les entreprises qui traverseront les prochaines années sans dégâts majeurs seront pour l'essentiel celles qui auront vu tôt et circonscrit vite, quel qu'ait été l'état de leurs dispositifs de prévention sur le papier. Y parvenir suppose de traiter la maintenance comme une capacité permanente et non comme une visite occasionnelle.

Questions fréquentes

La sécurité de l'IA me concerne-t-elle si mon entreprise n'utilise pas d'IA ?

Oui. L'intelligence artificielle modifie votre exposition par trois voies qui ne supposent pas que vous l'ayez adoptée. Les attaquants s'en servent pour trouver des vulnérabilités à un coût bien moindre qu'auparavant, ce qui ramène à quelques heures le délai entre la publication d'un correctif et son exploitation. Les prestataires qui construisent et maintiennent votre site ont adopté les mêmes outils, et des tests indépendants situent aux alentours de 55 % le taux de code généré qui passe les contrôles de sécurité. La plupart des organisations ont par ailleurs hérité de fonctionnalités d'intelligence artificielle sans l'avoir décidé, par des extensions qui en ont ajouté lors d'une mise à jour, par des agents conversationnels, ou par des collaborateurs qui utilisent des outils publics avec des données de l'entreprise.

En combien de temps faut-il appliquer un correctif de sécurité critique en 2026 ?

Plus vite que ne le permettent la plupart des contrats de maintenance. Dans la chaîne de vulnérabilités du cœur de WordPress divulguée en juillet 2026, l'éditeur de sécurité Patchstack a observé des tentatives d'exploitation réelles environ 90 minutes après la publication du correctif, parce que les attaquants lisent les correctifs publiés pour savoir ce qui a changé et que l'assistance par modèle rend cette lecture rapide. Une visite de mise à jour mensuelle, voire hebdomadaire, laisse une fenêtre qui recouvre celle de l'exploitation de masse. La cible concrète pour une faille critique exploitable à distance sur un logiciel exposé à Internet est le jour même, ce qui relève moins de la règle que de la capacité. Si appliquer une mise à jour urgente suppose de planifier, de faire valider et de trouver quelqu'un de disponible, cette capacité n'existe pas encore.

Le code généré par IA est-il moins sûr que le code écrit par des humains ?

Au vu des données disponibles, le code généré par IA comporte davantage de défauts, même si la différence est de degré et non de nature. L'analyse Veracode de 2026, portant sur plus de 150 modèles de langage testés sur quatre familles de vulnérabilités courantes, conclut que seules 55 % des générations produisent du code sûr, un chiffre que l'éditeur décrit comme pratiquement inchangé en deux ans alors que les autres capacités des modèles progressaient nettement. Le constat le plus utile porte sur l'écart entre justesse et sécurité, puisque la syntaxe est correcte plus de 95 % du temps. Le code généré a donc tendance à compiler, s'exécuter et passer la relecture fonctionnelle tout en portant une faille qui n'apparaît que sous attaque.

Qu'est-ce que l'injection de prompt et peut-elle toucher un site ordinaire ?

L'injection de prompt est une attaque qui glisse des consignes dans le texte lu par un système d'intelligence artificielle, de sorte que le système les exécute au lieu de se contenter d'en traiter le contenu. Elle touche un site ordinaire dès lors que celui-ci fait tourner quelque chose qui lit du texte et agit en conséquence, ce qui désigne aujourd'hui un agent conversationnel, un moteur de recherche interne dopé à l'IA ou un assistant de support. Si un attaquant peut influencer l'un des textes que le système lit, qu'il s'agisse du contenu des pages, d'avis clients ou de documents téléversés, ce texte peut porter des consignes. Aucune parade fiable n'existe en 2026, la bonne approche consiste donc à limiter ce à quoi un tel système accède et non à miser sur le filtrage de l'attaque.

Que dois-je demander à mon agence ou à mon hébergeur en matière de sécurité et d'IA ?

Cinq questions couvrent l'essentiel. Premièrement : en combien d'heures, à compter de l'alerte, pouvez-vous appliquer un correctif de sécurité urgent ? Deuxièmement : relisez-vous le code assisté par IA autrement que le code écrit à la main, et une personne valide-t-elle chaque nouvelle dépendance ? Troisièmement : pouvez-vous me lister toutes les fonctionnalités d'intelligence artificielle actives sur mon site, y compris celles arrivées par une mise à jour d'extension ? Quatrièmement : comment saurions-nous que le site est compromis, et en combien de temps ? Cinquièmement : si un composant était compromis, que pourrait-il atteindre d'autre ? Des réponses vagues à l'une de ces questions sont en elles-mêmes instructives, et aucune des cinq n'oblige le prestataire à acheter quoi que ce soit.

Mettre cela en pratique

Si vous ne retenez qu'une chose, retenez l'inventaire. On ne décide pas du risque lié à l'intelligence artificielle sur une plateforme dont l'intelligence artificielle n'a jamais été recensée, et ce recensement demande rarement plus d'une journée. Ensuite, la marche à suivre pour la sécurité de votre plateforme web est la marche ordinaire. Savoir ce que vous exploitez, savoir en combien de temps vous pouvez le modifier, savoir comment vous apprendriez qu'un incident a eu lieu, et limiter ce qu'une défaillance isolée peut atteindre.

Deux articles voisins approfondissent là où celui-ci reste large. Notre guide opérationnel sur les mises à jour sûres traite de la capacité de réaction qu'exige la première voie, et notre guide pour rendre un site lisible par les agents IA aborde l'autre versant de la relation, celui où ces systèmes arrivent en visiteurs et non en menaces. Si vous préférez confier à quelqu'un d'autre le soin de répondre à ces cinq questions sur votre propre plateforme, c'est l'objet d'un audit indépendant.

Keroberos est un cabinet de conseil en technologies web qui accompagne les entreprises dans le choix de leur plateforme, livre des projets WordPress et Drupal, et fournit des prestations en régie pour les équipes de développement. Pour échanger sur la sécurité de votre plateforme, contactez-nous.