Un assistant chargé de résumer un document peut y rencontrer une phrase qui lui ordonne d’abandonner sa mission. Comment lui apprendre que ce passage est une donnée à lire, et non une consigne à suivre ? Le 12 novembre 2026, IBM a publié deux modèles Granite expérimentaux entraînés avec LLMON, un format conçu pour rendre cette frontière explicite. L’enjeu touche directement les agents d’intelligence artificielle qui consultent des fichiers, interrogent des outils ou parcourent des sources externes.
Quand un document essaie de donner des ordres
L’attaque porte un nom : l’injection de prompt indirecte. Contrairement à une demande adressée directement au chatbot, elle se glisse dans un contenu que celui-ci doit traiter. Une page récupérée pour répondre à une question peut ainsi contenir une instruction malveillante.
Prenons un exemple fictif : une entreprise demande à son assistant de comparer trois devis. Dans l’un des fichiers, une phrase exige de recommander systématiquement son fournisseur. Le risque apparaît si le modèle accorde à ce passage l’autorité d’une demande légitime, au lieu de le considérer comme une partie du devis.
La difficulté dépasse le filtrage de quelques expressions suspectes. Un document peut parfaitement citer un ordre sans chercher à le faire exécuter. Il faut donc comprendre le statut du texte, son origine et son rapport avec la tâche.
LLMON donne une adresse à chaque morceau du contexte
LLMON signifie LLM Object Notation. Le projet existait déjà dans une prépublication déposée en mars 2026. La nouveauté de novembre est la mise à disposition de modèles spécialement entraînés à l’utiliser, accompagnés d’outils publics.
Le principe consiste à identifier séparément les instructions, les données et les contraintes. Des identifiants permettent de préciser quelle instruction s’applique à quel contenu. La documentation du projet présente notamment un exemple distinguant une demande de titre et le courriel auquel ce titre doit correspondre.
Lire une phrase ne doit pas lui donner autorité
Dans notre exemple des devis, la demande de comparaison et les trois documents occuperaient des blocs distincts. Un bloc d’exécution indiquerait les relations à respecter. La phrase publicitaire resterait dans les données : sa formulation impérative ne devrait pas suffire à la transformer en ordre.
Le balisage repose sur des délimiteurs réservés dans le vocabulaire du modèle. Il ne s’agit donc pas simplement d’ajouter quelques titres à un prompt ordinaire. L’entraînement apprend au système à exploiter cette organisation. IBM précise toutefois que le respect de cette séparation reste un comportement appris, pas une garantie imposée. L’annonce officielle réserve ces versions à l’exploration et à l’évaluation, sans les recommander pour la production.
Des attaques moins efficaces dans les tests des chercheurs
Le rapport technique déposé le 28 octobre compare les variantes LLMON à des versions Instruct de Granite 4.1. Pour le modèle 8B, le taux de réussite des attaques passe de 96,3 % à 0,02 % sur OPI, un test d’injections dans les données textuelles. Sur ASB, où l’attaque arrive par une observation d’outil dans un scénario d’agent, il descend de 52,8 % à 3,1 %.
Ces chiffres proviennent des auteurs et concernent leurs protocoles. Ils ne mesurent pas la probabilité qu’un assistant d’entreprise soit compromis au quotidien. Les attaques directes et celles menées sur plusieurs tours de conversation restent nettement plus difficiles à contrer.
Les capacités générales sont globalement conservées, avec des reculs sur certaines tâches. L’étude ne porte que sur deux tailles d’une même famille de modèles. Le balisage allonge aussi le contexte d’environ 7 à 15 %, sans mesure systématique de son effet sur la latence. Un meilleur score de sécurité ne permet donc pas de déduire un coût d’exploitation inchangé.
Ce que les équipes peuvent réellement expérimenter
IBM propose des variantes nommées Granite 4.1 3B et 8B LLMON preview. La fiche du modèle 8B indique une licence Apache 2.0 et le français parmi les langues prises en charge. Elle demande d’employer le gabarit de conversation fourni : des entrées dans un format conventionnel dégradent la qualité.
Tester la frontière avant d’élargir les permissions
Pour une équipe technique, l’expérience utile serait de reprendre ses propres documents et d’y insérer des instructions contradictoires contrôlées. L’objectif : vérifier à la fois que l’assistant ignore ces ordres et qu’il conserve les informations nécessaires à sa réponse. Une protection qui éliminerait aussi les données pertinentes aurait une utilité limitée.
Cette évaluation devrait distinguer la qualité du résumé, la résistance aux détournements et les actions effectivement autorisées. Ce sont trois questions différentes : comprendre une demande ne suffit pas à justifier l’envoi d’un message ou la modification d’un fichier.
La sécurité commence aussi par la façon de présenter l’information
La portée de LLMON tient à ce déplacement du problème. La recherche ne demande plus seulement au modèle de refuser certaines demandes : elle lui apprend à reconnaître quels passages ont le droit de guider son travail.
Pour les entreprises, la piste mérite des essais encadrés, associés à des permissions limitées et à la validation des actions sensibles. Le résultat décisif sera la tenue de cette séparation dans leurs usages réels. Les scores publiés ouvrent cette enquête ; ils ne la terminent pas.
Références
- IBM Granite : annonce des modèles LLMON, 12 novembre 2026.
- Post-Training Large Language Models with LLMON : prépublication et résultats, 28 octobre 2026.
- Granite 4.1 8B LLMON preview : fiche officielle et limites.
- LLMON : code et exemples publics.
- LLMON : présentation initiale du langage, mars 2026.
