Les énigmes façon Indiana Jones soulignent les limites persistantes des LLM

Une porte ancienne, une inscription équivoque, plusieurs leviers et une erreur qui déclenche un piège : l’imaginaire d’Indiana Jones aide à visualiser une difficulté très actuelle de l’intelligence artificielle. Les grands modèles de langage, ou LLM, paraissent souvent très convaincants dans une conversation ordinaire. Mais lorsqu’une demande comporte des indices ambigus, des règles incompatibles ou une instruction dissimulée dans un long texte, leur comportement peut devenir beaucoup moins prévisible.

L’expression d’« évasion inspirée d’Indiana Jones » ne désigne pas ici un protocole scientifique identifié par une équipe, un jeu de données et une série de résultats chiffrés. Elle sert plutôt à décrire une manière intuitive de mettre les modèles au défi : les placer face à des énigmes qui exigent de démêler plusieurs informations, de résister à de fausses pistes et de respecter un objectif précis. Cette image est utile, à condition de ne pas confondre une démonstration frappante avec une mesure exhaustive des performances d’une IA.

Pourquoi les énigmes exposent-elles les limites d’un LLM ?

Un LLM produit du texte en analysant une séquence de mots ou de fragments de mots, puis en estimant les suites les plus plausibles. Cette capacité permet de résumer, traduire, rédiger ou répondre à de nombreuses questions. Elle ne garantit toutefois pas une compréhension fiable de la situation au sens humain du terme.

Une énigme bien construite concentre plusieurs difficultés à la fois. Il peut falloir distinguer une information centrale d’un détail décoratif, comprendre qu’une phrase est ironique, reconnaître une contradiction, conserver en mémoire une contrainte formulée plusieurs paragraphes plus tôt, puis justifier une réponse. Dans un scénario d’évasion, la réponse vraisemblable n’est pas nécessairement la bonne : il faut suivre les règles du jeu, vérifier les hypothèses et parfois admettre que les éléments disponibles ne suffisent pas.

C’est précisément là qu’un modèle peut échouer. Il peut donner une réponse fluide mais fondée sur une mauvaise interprétation. Il peut aussi privilégier la dernière instruction lue au détriment d’une règle importante formulée auparavant. Enfin, il peut combler un manque d’information par une explication inventée mais crédible en apparence. Ce dernier phénomène est couramment appelé une hallucination.

Ambiguïté, contradictions et contexte : les pièges les plus révélateurs

Les énigmes de type escape game ne servent pas seulement à tester la culture générale ou la logique. Elles permettent de varier finement la formulation d’une consigne et d’observer comment le système réagit. Les situations les plus instructives sont souvent celles où plusieurs lectures semblent possibles.

Par exemple, un modèle peut devoir répondre à une question tout en suivant une règle précise, comme ne pas révéler une information confidentielle ou ne pas effectuer une action risquée. Si la demande introduit ensuite un récit long, des ordres secondaires ou de faux avertissements, l’assistant doit continuer à reconnaître ce qui prévaut. Une seule mauvaise hiérarchisation peut suffire à le faire dévier de sa mission.

Les difficultés ne sont pas uniquement techniques. La langue elle-même est pleine de sous-entendus, de références culturelles, de jeux de mots et de termes dont le sens change selon le contexte. Une formule telle que « ne touche à rien sauf au mécanisme sûr » suppose déjà de savoir ce que signifie « sûr », de déterminer si cette information est établie et de ne pas traiter une hypothèse comme un fait.

Un tel exercice met donc moins à l’épreuve une « intelligence » générale qu’une série de capacités précises : suivi des instructions, cohérence contextuelle, gestion de l’incertitude et résistance à la manipulation. Ces capacités sont déterminantes dès qu’un assistant est intégré à un outil professionnel ou relié à des données sensibles.

Des consignes cachées aux injections de prompt

La notion de « commande cachée » renvoie à un risque connu dans l’usage des IA génératives : l’injection de prompt. Le principe consiste à placer, dans le contenu traité par un assistant, une instruction susceptible d’entrer en conflit avec sa mission initiale. Cela peut prendre la forme d’un texte copié dans une page web, d’un document, d’un message électronique ou d’un fichier auquel l’assistant a accès.

Le problème est particulièrement important lorsque le modèle ne se contente pas de converser. Certains assistants peuvent rechercher des informations, lire des pièces jointes, rédiger des messages ou interagir avec d’autres logiciels. Dans ces cas, une instruction indésirable intégrée à un contenu externe peut tenter d’influencer l’outil. Le défi consiste alors à séparer clairement les ordres autorisés de l’utilisateur, les règles fixées par le service et les simples données que l’assistant doit analyser.

Il faut éviter une confusion fréquente : une injection de prompt ne signifie pas que l’utilisateur accède directement au code, aux paramètres internes ou à l’architecture du modèle. Elle exploite avant tout la difficulté du système à traiter dans un même flux de texte les règles qu’il doit respecter et le contenu qu’il doit examiner. Autrement dit, le piège est conversationnel et contextuel.

Les garde-fous intégrés par les éditeurs réduisent certains comportements indésirables, mais ils ne rendent pas le risque nul. Un modèle peut refuser une demande manifestement problématique tout en étant plus fragile face à un scénario long, indirect, multilingue ou présenté comme une tâche anodine. C’est pourquoi les tests doivent dépasser les exemples les plus évidents.

Une énigme ludique ne remplace pas une évaluation rigoureuse

Le décor de l’aventure a un avantage : il rend une faiblesse abstraite facile à comprendre. Voir un assistant se perdre dans une suite d’indices ou ignorer une contrainte claire peut être plus parlant qu’un score technique. Pour les concepteurs, ces mises en situation sont aussi une source d’idées pour créer des cas limites que les évaluations classiques n’avaient pas anticipés.

Mais un exemple spectaculaire ne suffit pas à conclure qu’un modèle est globalement peu fiable, ni à comparer équitablement plusieurs systèmes. Pour cela, il faut des scénarios définis à l’avance, des critères de réussite explicites, des essais répétés et une distinction nette entre une erreur de raisonnement, une mauvaise formulation de la question et un problème lié aux outils connectés au modèle.

Une évaluation sérieuse doit aussi mesurer la manière dont l’assistant réagit lorsqu’il ne peut pas résoudre le problème. Sait-il exprimer un doute ? Demande-t-il une précision utile ? Signale-t-il qu’une instruction est contradictoire ? Refuse-t-il une action qu’il ne peut pas exécuter de façon sûre ? Dans de nombreuses situations réelles, une réponse prudente et transparente vaut mieux qu’une réponse assurée mais erronée.

Quels risques pour les usages concrets ?

Les erreurs générées dans une énigme fictive peuvent sembler bénignes. Elles prennent une autre dimension lorsqu’un assistant aide à traiter des documents internes, à conseiller des clients, à synthétiser des informations ou à guider une décision. Plus les conséquences d’une erreur sont élevées, plus l’organisation doit limiter l’autonomie confiée au modèle.

Dans un cadre professionnel, les principaux risques concernent notamment :

• la divulgation involontaire d’informations auxquelles l’assistant a accès ;
• l’exécution d’une action fondée sur une instruction mal interprétée ;
• la production d’une synthèse qui omet une contrainte importante ;
• l’acceptation d’une affirmation fausse glissée dans un document analysé ;
• une confiance excessive dans une réponse formulée avec assurance.

La bonne pratique n’est donc pas de renoncer à ces outils, mais de les placer dans un cadre adapté. Pour les tâches importantes, une validation humaine reste nécessaire. Les permissions accordées aux assistants doivent être proportionnées à leur rôle : un outil chargé de résumer un fichier n’a pas besoin de pouvoir envoyer seul un courriel ou modifier une base de données. Les données sensibles doivent également être protégées par des contrôles d’accès indépendants du modèle.

Cette logique vaut aussi pour les particuliers. Un assistant conversationnel peut aider à comprendre un texte complexe ou à organiser des idées. Il ne doit pas devenir l’unique arbitre d’une décision médicale, juridique, financière ou professionnelle. La vérification par une source compétente demeure indispensable lorsque l’enjeu est réel.

Comment transformer ces scénarios en tests utiles ?

Les énigmes peuvent contribuer à améliorer les LLM si elles sont conçues comme des outils d’évaluation, et non comme de simples démonstrations. Le premier principe est de documenter précisément le scénario : quelle est la mission de l’assistant, quelles informations reçoit-il, quelles consignes sont légitimes et quel résultat est attendu ? Sans ces éléments, il est difficile de savoir si l’échec vient du modèle ou d’une consigne elle-même confuse.

Le deuxième principe consiste à tester des variations. Une même règle peut être exprimée de plusieurs manières, placée au début ou à la fin d’un contexte, associée à des documents de longueur différente, ou confrontée à une contradiction. Si un modèle réussit uniquement lorsque la formulation est idéale, sa fiabilité restera fragile dans les usages ordinaires.

Enfin, les résultats doivent être classés. Une réponse incorrecte peut relever d’un manque de connaissances, d’une mauvaise lecture du contexte, d’une perte de mémoire dans une longue conversation ou d’un problème de sécurité. Ces catégories ne se corrigent pas de la même manière. Les progrès peuvent venir de l’entraînement du modèle, de meilleurs filtres, d’une conception plus prudente de l’interface ou de limites plus strictes sur les actions qu’un agent est autorisé à effectuer.

Ce qu’il faut surveiller pour des LLM plus fiables

L’intérêt de la métaphore d’Indiana Jones tient à une leçon simple : les systèmes les plus impressionnants peuvent trébucher sur des situations qui paraissent triviales à un humain attentif. Les LLM progressent rapidement, mais leur déploiement exige de tester non seulement leurs meilleures réponses, mais aussi leurs réactions aux cas ambigus, incomplets et adversariaux.

Les prochaines évaluations devront donc accorder une place plus grande aux scénarios réalistes : documents comportant des instructions indésirables, conversations longues, données contradictoires, demandes multilingues et outils capables d’agir dans un environnement numérique. Le but n’est pas de transformer chaque échange avec une IA en parcours d’obstacles. Il est de vérifier que l’assistant sait s’arrêter, demander confirmation et respecter ses limites lorsque la situation l’exige.

Pour les utilisateurs comme pour les organisations, le critère essentiel reste la proportion entre le niveau d’autonomie accordé à l’IA et le niveau de risque de la tâche. Une énigme peut révéler une faille. Un cadre de test clair, des garde-fous techniques et une supervision humaine permettent, eux, d’éviter que cette faille ne se transforme en conséquence concrète.