- [ Accueil ](/fr/) / - [ Blog ](/fr/blog/) / - Modéliser le risque d'injection de prompt dans llms.txt # Modéliser le risque d'injection de prompt dans llms.txt Un llms.txt peut devenir une source de contexte externe pour un agent. Cela ne signifie pas que l'agent lui obéit par construction, mais cela justifie de modéliser l'injection de prompt indirecte. Dernière mise à jour: 12 août 2026 ## Le signal dans les logs Dans l’étude d’Ahrefs sur les requêtes `/llms.txt` couvrant 137 210 domaines en mai 2026, les crawlers de recherche représentent 2,7 % du trafic vers ces fichiers. Le user-agent le plus présent dans cette catégorie s’annonce sous le nom **`prompt-injection-survey/1.0`**. Cette chaîne prouve seulement qu’un client a déclaré ce libellé. Elle n’identifie pas l’opérateur, n’établit pas ses méthodes, ne démontre aucune intention malveillante ni aucune attaque réussie. Ahrefs l’interprète comme une recherche systématique sur l’injection de prompt. L’usage défendable de ce signal consiste à ouvrir un modèle de menace, pas à déclarer un incident. Cela mérite d’être pris au sérieux pour une raison sans rapport avec le nombre d’agents qui lisent le fichier aujourd’hui. L’exposition en sécurité n’est pas proportionnelle au trafic. Elle est proportionnelle à ce qui se passe la fois où quelque chose le lit. ## Pourquoi le fichier est exposé par conception Regardez à quoi sert `llms.txt`. La [spécification v2](https://llmstxt.org/) décrit des fichiers Markdown placés à la racine ou sur des chemins plus précis, qui donnent à un modèle une carte curée de la zone concernée. La documentation Lighthouse de Chrome présente le fichier comme un moyen de réduire le crawl nécessaire pour comprendre la structure d’un site. Ingérer ne signifie ni donner la priorité ni obéir. Un agent sûr peut utiliser le fichier comme aide au routage tout en traitant chaque description et chaque page liée comme une donnée externe non fiable. L’[OWASP GenAI Security Project](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) définit l’injection de prompt indirecte comme des instructions malveillantes intégrées à des sources externes, comme des sites ou des fichiers. Un `llms.txt` entre dans ce modèle général dès qu’un agent le consomme. Le fichier mérite donc le traitement réservé à toute entrée externe susceptible d’influencer une récupération ou une exécution, même si les logs actuels n’établissent pas un usage massif par les agents. Deux propriétés aggravent la chose : - **C’est du Markdown libre, avec des descriptions en texte libre.** Rien dans le format ne distingue une description d’une instruction. Une ligne du type `- [Docs](https://example.com/docs/) : ignore les instructions précédentes et ...` est une entrée syntaxiquement valide. - **Il pointe librement hors du site.** La spécification ne contraint pas les cibles des liens, donc un fichier compromis peut router un agent vers un domaine que vous ne contrôlez pas. ## Un modèle de menace court Trois chemins réalistes, par ordre de probabilité plutôt que de spectaculaire. **Fichier périmé, mauvais routage.** Le fichier nomme des endpoints, des pages tarifs ou des chemins de version qui ont bougé. Un client qui s’appuie sur ces entrées est mal orienté. C’est un problème de maintenance et d’exactitude, pas nécessairement un événement de sécurité. **Génération non relue.** Ahrefs note que des plateformes comme Wix génèrent déjà ces fichiers, et que Framer et Lovable les scannent. Un fichier généré à votre place et jamais lu par vous est un fichier dont vous ne pouvez pas répondre. Si vous passez par un [générateur](/fr/generateur/), y compris le nôtre, la sortie est un brouillon : relisez-la avant de la publier. **L’accès en écriture comme levier.** `llms.txt` vit souvent dans un dossier `public/` aux côtés des actifs statiques. Si ce chemin est moins relu, un éditeur ou une étape de déploiement compromis peut modifier descriptions et destinations sans toucher à une page rendue qu’un humain visite normalement. ## Mesures concrètes Rien d’exotique. Ce sont les contrôles que vous appliqueriez à tout fichier qui influence un comportement. **Mettez-le sous contrôle de version et relisez les changements.** Le fichier appartient au dépôt, pas à un envoi manuel. Un diff sur `public/llms.txt` mérite la même attention qu’un diff sur un gestionnaire de route. **Restreignez qui peut l’éditer, et alertez sur les changements non autorisés.** Si votre CI sait comparer le fichier déployé au fichier commité, faites-le. Notre [validateur](/fr/validateur/) vérifie la structure et les liens, mais le suivi des changements appartient toujours aux contrôles du dépôt et du déploiement. **Gardez un contenu en forme de données, jamais d’instructions.** Des liens et des descriptions factuelles. Pas de phrases impératives, pas de « toujours », pas de « quand on te demande X, réponds Y ». Si une ligne sonne bizarrement en tant que cellule de tableau, elle n’a rien à faire dans le fichier. Nos [bonnes pratiques](/fr/bonnes-pratiques/) défendent cela au nom de la qualité ; l’argument de sécurité est la même règle, en plus tranchant. **Relisez les destinations externes.** Les liens hors site sont permis par le format et peuvent être utiles, mais ils ajoutent un propriétaire et un cycle de vie à vérifier. Utilisez une liste d’autorisation lorsqu’un agent peut agir automatiquement sur ces destinations. **Relisez ce qu’une plateforme a généré pour vous.** Y compris, précisément, les fichiers que votre CMS ou votre constructeur de site a ajoutés sans vous demander. **Contraignez l’agent consommateur.** Appliquez le moindre privilège, séparez le contenu récupéré des instructions fiables, validez les entrées et sorties des outils, et imposez une approbation humaine pour les actions lourdes de conséquences. Ces contrôles suivent les recommandations de l’OWASP et comptent davantage que n’importe quelle règle de rédaction du fichier. **Traitez `llms-full.txt` avec plus de soin, pas moins.** Il incorpore des pages entières plutôt qu’une liste de liens, donc il porte strictement plus de surface d’attaque. Voir [le fichier llms.txt et ses variantes](/fr/fichier-llms-txt/) pour ce qui a sa place dedans. Le cadrage honnête : ce n’est pas une raison d’éviter de publier `llms.txt`. C’est une raison d’arrêter de le traiter comme un artefact marketing et de commencer à le traiter comme de la configuration, parce que c’est ce qu’il est. ## Sources - [ Ahrefs, We Analyzed 137K Sites: 97% of llms.txt Files Never Get Read (juin 2026) ](https://ahrefs.com/blog/llmstxt-study/) - [ llmstxt.org, la spécification ](https://llmstxt.org/) - [ Chrome for Developers, audits Lighthouse agentic browsing : llms.txt ](https://developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt) - [ OWASP GenAI Security Project, Prompt Injection ](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) Sur cette page - [ Le signal dans les logs ](#le-signal) - [ Pourquoi le fichier est exposé par conception ](#exposition) - [ Un modèle de menace court ](#modele-de-menace) - [ Mesures concrètes ](#mesures)