Jailbreak

Une barrière apprise

Un modèle de langage est entraîné à refuser certaines demandes, par des consignes générales et un ajustement sur des exemples de refus. Le jailbreak exploite le fait que cette barrière est apprise, donc statistique, et non inscrite dans le code. En changeant le contexte, la langue, le format ou le rôle attribué à l'assistant, on déplace la prédiction vers une zone où le refus devient moins probable. La demande interdite reste la même, seule sa présentation change. C'est pourquoi les filtres qui inspectent des mots interdits attrapent mal ce type de contournement.

Le procédé ne demande pas de compétence technique particulière. Des récits fictifs, des jeux de rôle, des demandes de traduction ou des consignes présentées comme un test de sécurité suffisent parfois. La réussite est instable : elle dépend du modèle, de sa version et du contexte. Un même texte peut échouer sur un service et aboutir sur un autre. Cette variabilité rend l'évaluation difficile, car un refus observé une fois ne garantit pas que la protection tienne dans d'autres conditions.

Les formes observées

Les tentatives se répartissent en quelques familles. Les unes jouent sur le cadre narratif, en demandant une réponse fictive ou historique. D'autres exploitent la forme : encodage, langue rare, texte fragmenté, consignes empilées. D'autres encore visent le système plutôt que le modèle, en cherchant à faire exécuter une instruction cachée dans un document ou une page consultée. Cette dernière famille recoupe l'injection de prompt et concerne surtout les assistants connectés à des sources externes, dont le périmètre d'action est plus large.

Le public des tentatives est hétérogène : curieux, chercheurs, personnes qui testent les limites d'un service, acteurs malveillants. Les conséquences vont de la réponse déplacée à la fuite d'instructions internes, voire à l'exécution d'une action non souhaitée quand l'assistant dispose d'outils. Dans un cadre professionnel, le risque principal n'est pas le scandale médiatique mais l'usage détourné d'un assistant doté de droits : messagerie, fichiers, base clients. Ce risque augmente avec le nombre d'outils connectés au même agent.

Ce qu'une entreprise peut faire

Aucune protection n'élimine le risque, et il faut le dire aux dirigeants avant de déployer. En revanche, plusieurs mesures le réduisent. Limiter les droits de l'assistant au strict nécessaire, séparer les données sensibles des sources qu'il peut consulter, journaliser les échanges et tester régulièrement les refus avec des cas choisis. Les éditeurs corrigent au fil des versions, ce qui impose de suivre les mises à jour et de ne pas figer un service ancien pour des raisons de confort.

La conduite à tenir en cas de contournement réussi relève de la procédure incident. Identifier ce qui a été obtenu, si des données ont été exposées, quelles actions ont été déclenchées. La notification éventuelle à l'autorité de protection des données dépend de la nature de l'incident, pas de son retentissement. Un journal complet et un inventaire des accès rendent cette analyse possible ; sans eux, l'entreprise ne peut ni qualifier l'incident ni démontrer qu'elle l'a maîtrisé.