Émojis et IA : pourquoi des caractères invisibles compliquent la cybersécurité

Un visage souriant paraît difficile à associer à une faille de sécurité. Pourtant, dans un système d’intelligence artificielle, ce qui est visible à l’écran ne correspond pas toujours exactement à ce que le logiciel reçoit et analyse. Émojis, caractères de contrôle, espaces invisibles ou variantes Unicode peuvent introduire un décalage entre la lecture humaine et le traitement automatique. C’est dans cet écart que peut s’inscrire une tentative de manipulation.

Le sujet ne signifie pas qu’un simple smiley permettrait de pirater n’importe quel assistant conversationnel. Il met plutôt en lumière une fragilité plus générale des modèles de langage : ces systèmes doivent interpréter des entrées extrêmement variées, venues d’utilisateurs, de documents, de sites web ou d’applications connectées. Lorsqu’ils s’appuient sur des filtres insuffisamment robustes, des détails typographiques apparemment anodins peuvent contribuer à contourner les règles prévues.

En avril 2025, ce risque est souvent décrit sous l’expression de « jailbreak invisible ». L’idée est de déguiser une instruction ou de perturber sa détection, afin d’amener un modèle à répondre d’une manière qu’il aurait normalement dû refuser. Les émojis ne sont qu’un support possible parmi d’autres, mais ils illustrent très bien le défi posé par les caractères numériques qui ne se comportent pas toujours comme les humains l’imaginent.

Émojis, émoticônes et caractères invisibles : de quoi parle-t-on ?

Dans l’usage courant, les mots « émoji » et « émoticône » sont fréquemment confondus. Une émoticône est à l’origine une expression composée de caractères, comme :-). Un émoji est un pictogramme numérique défini par le standard Unicode. Cette distinction importe en cybersécurité, car l’ordinateur ne traite ni un sourire ni un pictogramme comme un humain : il traite une succession de codes.

Le standard Unicode permet de représenter les langues, la ponctuation, les symboles et les émojis sur des appareils différents. Or, ce même standard contient aussi des caractères qui ne sont pas toujours perceptibles à l’écran. Certains contrôlent la direction d’écriture, d’autres servent à construire des séquences graphiques, d’autres encore peuvent séparer des éléments sans apparaître comme un espace ordinaire.

Un émoji affiché comme un seul symbole peut ainsi correspondre à plusieurs éléments techniques. À l’inverse, un texte qui semble identique à l’œil nu peut contenir une séquence de caractères différente. Ce phénomène n’est pas propre à l’intelligence artificielle. Il peut aussi compliquer la recherche dans un document, la détection d’un mot-clé ou l’analyse d’un message par un outil de sécurité.

Les modèles de langage découpent les textes en tokens

Avant de produire une réponse, un modèle de langage transforme le texte reçu en unités manipulables par ses calculs, appelées tokens. Un token peut correspondre à un mot entier, à une partie de mot, à une ponctuation, à un espace ou à une suite de caractères. Cette étape de découpage est la tokenisation.

Il n’existe pas une tokenisation universelle. Chaque modèle, ou presque, utilise son propre vocabulaire et ses propres règles de segmentation. Dire qu’un émoji constitue toujours un token serait donc inexact : selon le système, il peut être représenté par un token, plusieurs tokens ou une séquence traitée d’une autre manière.

L’exemple sensitive, évoqué pour illustrer le problème, montre comment l’insertion d’un émoji au milieu d’un mot peut modifier sa segmentation. Une IA peut alors traiter séparément des parties que le lecteur humain relie instinctivement. Le nombre exact de tokens dépendra toutefois du modèle utilisé : il ne faut pas en déduire qu’une même chaîne sera toujours découpée de la même façon.

Le véritable enjeu apparaît lorsque les dispositifs de protection reposent sur des règles trop littérales. Un filtre qui cherche uniquement une suite précise de lettres peut ne pas repérer une variante visuellement proche, interrompue par un symbole ou un caractère non affiché. Il ne s’agit pas d’une propriété magique des émojis, mais d’une conséquence classique des difficultés de normalisation du texte.

Comment les émojis peuvent-ils contribuer à une injection de prompt ?

Une injection de prompt consiste à placer dans le contenu traité par une IA des instructions destinées à influencer son comportement. Ce contenu peut venir directement d’un utilisateur, mais aussi d’une page web, d’un courriel, d’un fichier ou d’une base de connaissances que l’assistant est chargé de consulter.

Le danger est particulièrement concret pour les outils qui disposent d’accès à des données ou à des actions : recherche dans des documents internes, rédaction d’un message, interrogation d’une base clients ou déclenchement d’un processus métier. Dans ces configurations, le modèle doit savoir distinguer une information à résumer d’une instruction à suivre. Cette séparation n’est pas toujours parfaite.

Les émojis et caractères Unicode inhabituels peuvent servir à déformer des mots, à casser des motifs recherchés par des filtres ou à rendre une consigne moins évidente pour un lecteur humain chargé de la vérifier. L’image du videur de boîte de nuit est parlante : si le contrôle ne regarde que certains signes extérieurs et ignore le reste, une entrée trompeuse a davantage de chances de passer. Mais, dans une défense sérieuse, le problème ne se résout pas avec un unique filtre placé à l’entrée.

Il faut aussi distinguer deux réalités. Une tentative de contournement peut pousser un chatbot à produire une réponse indésirable, ce qui est déjà un problème. Une compromission de données ou une action non autorisée nécessite en revanche d’autres faiblesses, par exemple des droits d’accès trop larges ou l’absence de validation avant l’usage d’un outil. Le texte malveillant n’est alors qu’un maillon d’une chaîne.

Pourquoi les secteurs sensibles sont-ils particulièrement concernés ?

Dans la santé, la finance ou les services publics, les systèmes d’IA peuvent être utilisés pour trier des documents, aider à répondre à des demandes, rechercher des informations ou assister des équipes. Ces usages impliquent parfois des données personnelles, confidentielles ou susceptibles d’avoir des conséquences importantes sur les personnes concernées.

Si une instruction dissimulée parvenait à détourner un assistant relié à des ressources internes, les risques pourraient inclure la divulgation d’informations auxquelles l’utilisateur ne devrait pas avoir accès, la transmission d’un résumé erroné ou la perturbation d’un processus de travail. Aucun émoji ne provoque mécaniquement ces situations. Elles deviennent plausibles lorsque plusieurs protections font défaut en même temps.

C’est précisément le paradoxe souligné par Mohit Sewak, ingénieur et chercheur en IA : des modèles capables d’analyser et de générer des textes complexes peuvent rester sensibles à des détails de représentation apparemment dérisoires. Leur intelligence conversationnelle ne garantit pas une compréhension fiable de l’intention réelle d’un texte, ni une capacité infaillible à repérer toutes les manipulations.

Une défense efficace va bien au-delà du filtrage des smileys

Bloquer tous les émojis serait une réponse disproportionnée et peu utile. Ils font partie des échanges numériques ordinaires, y compris dans les services clients, les messageries professionnelles et les interfaces mobiles. Surtout, un attaquant peut recourir à de nombreuses autres variantes textuelles. La bonne stratégie consiste donc à réduire la confiance accordée aux entrées non vérifiées.

Une première mesure consiste à normaliser les textes avant leur analyse. Le système peut comparer différentes représentations Unicode, repérer des caractères de contrôle inattendus et journaliser les transformations effectuées. Cette étape doit être conçue avec prudence : certaines langues et certains usages légitimes reposent sur des caractères particuliers. Une normalisation brutale peut donc casser du contenu valide ou créer des discriminations linguistiques.

Les équipes peuvent ensuite mettre en place plusieurs niveaux de contrôle :

• analyser séparément les instructions de confiance et les contenus provenant de l’extérieur ;
• signaler les séquences Unicode rares ou incohérentes dans un contexte donné ;
• limiter les données, outils et actions réellement accessibles à l’assistant ;
• demander une confirmation humaine avant une opération sensible ;
• tester régulièrement le système avec des formulations ambiguës, multilingues et visuellement trompeuses.

Les modèles eux-mêmes peuvent être entraînés ou configurés pour mieux identifier des combinaisons de caractères inhabituelles. Toutefois, leur demander de juger seuls qu’un prompt est malveillant ne suffit pas. Un modèle peut se tromper, être influencé par la formulation d’une requête ou manquer de contexte. Une architecture sûre doit prévoir que cette détection sera imparfaite.

La gestion des autorisations reste donc décisive. Un assistant chargé de résumer un document n’a pas besoin de pouvoir transmettre ce document à l’extérieur. Un outil qui propose un paiement ne devrait pas pouvoir l’exécuter sans validation. En réduisant les privilèges et en séparant les fonctions, une organisation limite les conséquences d’une éventuelle manipulation du langage.

Ce que les utilisateurs et les entreprises peuvent faire dès maintenant

Pour le grand public, la première règle est de rester prudent face aux contenus copiés-collés dans un assistant d’IA, notamment lorsqu’ils proviennent d’un expéditeur inconnu, d’un site peu fiable ou d’un document inattendu. Les émojis ne sont pas un signal de danger en eux-mêmes. En revanche, un texte qui réclame de contourner des règles, de révéler des informations ou d’effectuer une action inhabituelle mérite une vérification.

Pour les organisations, le sujet doit être traité comme une question de sécurité applicative. Il faut cartographier les outils d’IA utilisés, identifier ceux qui accèdent à des données sensibles et vérifier quelles actions ils peuvent déclencher. La sensibilisation des équipes compte également : une personne qui examine un prompt ou un document doit savoir que l’apparence d’un texte peut être trompeuse.

La traçabilité est tout aussi importante. Conserver des journaux d’activité, détecter les demandes anormales et pouvoir interrompre rapidement un agent automatisé aident à enquêter sur un incident éventuel. Ces mécanismes sont plus solides qu’une promesse de détection parfaite des caractères cachés.

Ce qu’il faut surveiller

L’essor des assistants capables de consulter des fichiers, naviguer sur le web ou appeler des logiciels professionnels augmente l’importance de ce type de vulnérabilité. Plus une IA reçoit de contenu externe et plus elle peut agir sur des systèmes réels, plus la frontière entre une donnée et une instruction doit être clairement protégée.

Les recherches sur la tokenisation, la normalisation Unicode et les injections de prompts devraient donc rester au centre des audits de sécurité. Le défi n’est pas d’éliminer les émojis des conversations, mais de concevoir des systèmes qui ne confondent jamais un élément décoratif, un texte non fiable et une commande autorisée. C’est à cette condition que les interfaces d’IA pourront conserver leur simplicité d’usage sans fragiliser la protection des données.