Pourquoi l'injection de prompt n'est pas résolue
Un agent travaille en lisant : des courriels, des documents, des pages, des données de vos outils. C'est sa force, et c'est sa surface d'attaque. L'injection de prompt consiste à glisser des instructions malveillantes dans ce que l'agent lira, et sa variante indirecte ne demande même pas d'accéder à vos systèmes : il suffit de placer le texte piégé là où l'agent ira le chercher, dans un courriel reçu, une pièce jointe, une page publique.
La raison pour laquelle aucun correctif ne règle le problème est structurelle : pour un modèle de langage, les instructions et les contenus sont faits de la même matière, du texte. Filtrer parfaitement l'un sans amputer l'autre n'est pas un réglage qu'on attend, c'est une limite des systèmes actuels, documentée par les référentiels de sécurité du domaine qui la classent en tête des risques des applications à base de modèles de langage.
Source, le référentiel OWASP « Top 10 for LLM Applications » (édition 2025) classe l'injection de prompt au premier rang des risques (LLM01), pour la deuxième édition consécutive. OWASP Gen AI Security Project. Vérifié juin 2026.
La conséquence pratique pour un dirigeant tient en une phrase : la question n'est pas de savoir si votre agent peut rencontrer un contenu piégé, il le peut, mais ce qu'il a le droit de faire quand ça arrive.
Ce que cela impose à l'architecture
Puisque l'attaque ne peut pas être éliminée à la source, la sécurité d'un système agentique se joue dans sa conception, trois principes, qui sont des décisions d'architecture avant d'être des outils.
Le moindre privilège d'abord : un agent ne reçoit que les accès strictement nécessaires à son cas d'usage. Un agent qui peut tout lire et tout faire transforme la moindre injection en compromission générale ; un agent cantonné à son périmètre transforme la même injection en incident contenu. Chaque connecteur accordé est une décision qui se justifie et se documente.
Les garde-fous ensuite : les limites techniques qui traduisent la gouvernance en mécanismes, ce que l'agent ne peut pas voir, pas faire, pas dépasser, et les conditions dans lesquelles il rend la main. La différence entre une règle écrite et une règle tenue.
L'humain dans la boucle enfin : toute action irréversible ou engageante, un paiement, un envoi, une suppression, un engagement contractuel, passe par une validation humaine explicite. Ce n'est pas de la défiance envers le système, c'est le réglage du degré d'autonomie à la mesure du risque.
On notera ce que ces trois principes ont en commun : aucun ne s'achète. Ils se conçoivent, cas d'usage par cas d'usage, c'est exactement la raison pour laquelle la sécurité agentique est un sujet d'architecture et non un rayon de catalogue.
Le cadre posé par l'ANSSI
L'agence nationale de la sécurité des systèmes d'information a cadré l'IA générative tôt, et son approche converge avec ce qui précède : intégrer ces systèmes dans l'analyse de risque existante plutôt que les traiter comme une magie à part. Concrètement, pour une PME ou une ETI : cartographier les usages réels (y compris les usages individuels non déclarés), cloisonner les systèmes d'IA des systèmes critiques, contrôler les données qu'ils peuvent atteindre, et conserver la maîtrise humaine des décisions sensibles.
Références, ANSSI, « Recommandations de sécurité pour un système d'IA générative » (guide ANSSI-PA-102, 29 avril 2024), une trentaine de recommandations par phases (entraînement, intégration et déploiement, production) ; et ANSSI et BSI, « AI Coding Assistants » (4 octobre 2024). cyber.gouv.fr. Vérifié juin 2026.
Pour les organisations qui découvrent ces recommandations en ayant déjà des usages installés, le premier geste n'est pas technique : c'est une charte qui recense et encadre l'existant, le profil « Système à gouverner » de notre auto-diagnostic décrit précisément cette situation.
Ce que coûte réellement un déploiement agentique
Le dernier angle de ce dossier est économique, et presque personne ne l'occupe : un agent ne coûte pas ce que coûte sa licence. Un système agentique mal conçu consomme en boucles, l'agent qui réessaie, relit, reformule, appelle un outil de trop, et ces consommations se facturent à l'usage. La sobriété d'une architecture n'est pas une élégance : c'est une ligne de coûts.
S'y ajoutent les coûts que la conception évite ou provoque : la vérification du code et des contenus générés (voir slopsquatting : l'économie de relecture se paie en incident), la supervision humaine dimensionnée au bon niveau, et la réversibilité. Sur ce dernier point : un système dont on ne peut plus se passer sans tout casser, qu'on ne peut ni arrêter, ni remplacer, ni reprendre en main proprement, devient une charge plutôt qu'un atout ; il vous tient au lieu de vous servir. Pouvoir le débrancher sans dégât se conçoit dès le départ.
Ordres de grandeur, les coûts « cachés » d'un usage agentique (raisonnement, contexte, appels d'outils, infrastructure) sont estimés de 1,5 à 3 fois le coût des seuls tokens visibles ; des cas d'emballement budgétaire ont été rapportés dans la presse spécialisée. Sources : JDN, Next, Stenoop, 2026, confiance moyenne. Vérifié juin 2026.
La règle que nous appliquons en conception découle de tout ce dossier : chaque cas d'usage est instrumenté, en sécurité comme en coût, avant la première mise en production. Un agent dont on ne peut dire ni ce qu'il change, ni ce qu'il expose, ni ce qu'il coûte, ne méritait pas d'exister.