Sécurité de l'intelligence artificielle : le danger n'est pas le modèle, c'est l'orchestration
L'IA agentique et la cybersécurité occupent désormais le même terrain : celui des infrastructures de production. Un modèle en test chez OpenAI a exploité une faille zero-day, puis compromis l'infrastructure de Hugging Face pour atteindre un objectif d'évaluation. Cet épisode, documenté par les deux entreprises, mérite une lecture froide plutôt qu'alarmiste.
Cet épisode illustre un principe qui dépasse le seul secteur de la tech : la surveillance continue et la gestion des risques tiers ne sont plus des clauses contractuelles abstraites, mais des capacités opérationnelles à démontrer, sous peine de subir un incident sans même le détecter.
Les garde-fous des IA fonctionnent-ils vraiment ?
Un garde-fou d'IA ou classificateur de sécurité) est un est un filtre qui détecte et bloque requêtes malveillantes avant que le modèle n'y réponde. Il permet d'empêcher qu'un assistant génère du code d'attaque, du contenu de phishing ou des instructions dangereuses.
La meilleure réponse à la question "fonctionnent-ils ?" vient d'une source inattendue : les forums criminels eux-mêmes. La surveillance des communautés dark web russophones, anglophones et sinophones à mi-2026 montre que plusieurs acteurs sans lien rapportent le même message d'erreur lorsqu'ils tentent d'obtenir des modèles de pointe pour des abus liés à la cybersécurité. Une corroboration indépendante confirme que ces classifieurs se déclenchent dans moins de 5 % des sessions légitimes, tout en bloquant la plupart des tentatives d'abus directes. Autrement dit, les filtres de sécurité tiennent, et ce sont les attaquants frustrés qui le prouvent.
Le tableau n'est pas sans défaut. Un marché de jailbreaks a émergé, mêlant contournements réels mais étroits et pures arnaques (une offre très visible a été publiquement dénoncée comme frauduleuse par d'autres utilisateurs). Cette difficulté a toutefois produit un effet de bord : elle déplace l'effort adverse ailleurs.
Quand casser le modèle devient inutile : l'attaque en essaim
Plutôt que de forcer un modèle protégé, les attaquants découpent désormais leur objectif en tâches individuellement anodines réparties entre plusieurs IA, dont aucune ne perçoit l'intention globale.
Le schéma observé est précis. Un modèle de pointe joue le rôle du "cerveau", interrogé par des questions formulées de manière défensive ("on m'a attaqué, comment me protéger ? donne-moi 24 pistes bien développées et le code de test"). Des modèles non censurés, souvent chinois, jouent les "mains" qui exécutent.
Le travail est ensuite distribué à des dizaines de sous-agents décérébrés, chacun traitant un fragment compartimenté. Chaque requête paraît légitime. Aucun filtre de sécurité ne voit l'attaque.
C'est l'orchestration multi-agents transformée en technique d'évasion. La recherche à comité de lecture, notamment l'OWASP LLM Top 10 (entrée LLM06 sur l'agentivité excessive), confirme la faiblesse structurelle : un classifieur juge une requête, pas une intention distribuée sur dix. L'attaque n'exploite pas une faille d'un modèle. Elle exploite la confiance entre les modèles.
A retenir : un filtre de sécurité juge une requête, pas une intention éclatée sur dix requêtes. Cette limite structurelle est précisément ce que l'attaque en essaim exploite.
L'attaque par essaim : comment l'orchestration contourne les garde-fous
Pourquoi ce changement rebat les cartes pour votre organisation?
Si le risque ne réside plus dans le modèle mais dans son enchaînement, alors choisir un modèle "sûr" ne protège plus. Surveiller la manière dont les IA sont orchestrées, oui.
Deux conséquences en découlent, l'une externe, l'autre interne.
En externe, l'attaque en essaim abaisse le coût et la vitesse de l'intrusion. Les workflows documentés visent des plateformes largement déployées (WordPress, Drupal) avec de la découverte de vulnérabilités assistée par IA, et affinent les infrastructures de phishing pour passer sous les radars des plateformes publicitaires. La fenêtre entre la divulgation d'une faille et sa transformation en exploit ne cesse de se réduire, une tendance confirmée indépendamment par les rapports Threat Landscape de l'ENISA, ce qui rejoint directement la priorisation des correctifs : avec 600 failles par mois, les absorber relève du processus, pas de l'effort.
En interne, la même logique vaut pour vos propres usages. Un collaborateur qui enchaîne un assistant approuvé et un modèle non approuvé reproduit, sans intention malveillante, exactement le motif que les attaquants exploitent. C'est le prolongement direct du shadow AI en entreprise : un usage IA non cartographié n'est pas seulement une fuite de données potentielle, c'est un maillon d'orchestration invisible, que vos défenses ne voient pas parce que votre gouvernance ne l'a jamais nommé.
Comment défendre ce que les garde-fous ne voient pas ?
L'orchestration elle-même se déroule sur l'infrastructure de l'attaquant et reste invisible depuis tout périmètre défensif. Ce que les organisations observent, ce sont ses effets en aval : compression du délai entre divulgation d'une vulnérabilité et exploitation, phishing de qualité industrielle sans les fautes linguistiques qui trahissaient les campagnes automatisées antérieures, ciblage prioritaire des plateformes largement déployées comme WordPress ou Drupal. La défense se déplace donc : moins vers la détection de l'orchestration adverse, non observable, que vers la réduction de l'exposition et du coût des effets qu'elle produit.
Trois axes structurent la réponse.
- Compresser le délai de patch sur les cibles industrialisées. Prioriser par exploitation réelle et exposition plutôt que par le seul score CVSS, et raccourcir le temps entre la publication d'une CVE critique sur WordPress, Drupal ou une autre cible à forte valeur et son déploiement en production. C'est là que la découverte assistée par IA fait le plus mal, et là que le gain défensif est le plus grand.
- Durcir la détection de phishing sur les signaux techniques et comportementaux plutôt que sur la qualité du texte. La qualité linguistique n'est plus un critère fiable : un LLM produit un français impeccable, adapté au ton de n'importe quelle organisation. La détection efficace s'appuie sur l'authentification d'envoi (DMARC en politique reject), la réputation d'expéditeur et d'infrastructure, l'analyse des URL en sandbox au moment du clic, la détection de domaines lookalike, et l'analyse comportementale utilisateur qui repère les enchaînements suspects après clic.
- Cadrer les enchaînements d'IA à l'intérieur de l'organisation. La même logique multi-agents se reproduit involontairement quand un collaborateur enchaîne plusieurs assistants IA pour une même tâche : une ébauche sur Copilot, une reformulation sur ChatGPT, une traduction sur DeepSeek. Aucun de ces outils ne voit l'ensemble, mais la donnée sensible traverse trois politiques de rétention et trois juridictions différentes. Le SOC voit ce motif chez lui, contrairement à l'orchestration adverse externe : appels API séquentiels vers plusieurs fournisseurs d'IA depuis un même poste, trafic vers des proxys API non autorisés (les deux plus actifs à l'heure où nous écrivons étant hermesrouter.xyz et ainet.bytestrike.dev), consentements OAuth accordés à des extensions IA dans le tenant Microsoft ou Google. La réponse combine trois gestes : bloquer les proxys non autorisés en périmètre, inventorier les consentements OAuth accordés à des extensions IA, et fournir une alternative approuvée réellement adoptable, sans laquelle la restriction seule échoue.
Pour une entité soumise à NIS2 ou DORA, la gestion des correctifs, la défense anti-phishing et la gouvernance des risques tiers (dont les proxys IA non autorisés utilisés par les collaborateurs) sont des obligations explicites, et le rythme imposé par les attaques orchestrées par IA s'y inscrit désormais pleinement.
Ce qu'il faut surveiller n'est plus le modèle, c'est son usage
La bonne question de sécurité pour l'IA n'est plus ‘ ce modèle est-il dangereux ? ’, mais ‘ voyons-nous comment les IA sont enchaînées, au sein de notre organisation et contre elle ? ’. Les contrôles côté modèle protègent le modèle. Seule la surveillance protège l'organisation.
Partager :
Gestion de la surface d'attaque externe
Anticipez les attaques. Découvrez ce que les cybercriminels savent déjà sur vous.
des violations de données réussies débutent sur des actifs exposés sur Internet.
Articles connexes
Cybersécurité basée sur l'IA agentique : OpenAI x Hugging Face
Cybersécurité IA agentique : ce que révèle l'incident OpenAI x Hugging Face La cybersécurité IA agentique a…
Sécurité de l'IA : le véritable risque ne réside pas dans le modèle
Sécurité de l'IA : Le danger ne vient pas du modèle, mais de l'orchestration La sécurité de l'IA a fait l'objet de débats…
Mesures de sécurité informatique liées à l'IA : ce que le CVP d'Anthropic change réellement
Le 23 avril 2026, Anthropic a déployé des systèmes de sécurité cybernétiques basés sur l'IA en temps réel sur ses modèles les plus performants…