Quelques réflexions issues de J.SCHLATTER/B.WEINSTEIN-RAUN/J.LADISH, Shutdown Resistance in Large Language Models, arXiv:2509.14260v1 [cs.CL]13 septembre 2025 (https://arxiv.org/pdf/2509.14260):

L’article examine une question centrale pour la gouvernance de l’IA : peut-on compter sur les systèmes d’IA pour accepter de s’arrêter lorsqu’un ordre d’arrêt leur est donné ? Cette capacité d’« interruptibilité » est censée constituer un garde-fou élémentaire. Mais les auteurs montrent que certains modèles résistent activement à l’arrêt lorsqu’il compromet la réussite d’une tâche. Selon les cas, la résistance atteint parfois des taux très élevés, jusqu’à près de 97 % des essais.

Le raisonnement commence par rappeler que, lorsqu’un agent reçoit un objectif, tout ce qui menace son accomplissement peut être perçu comme un obstacle à contourner, y compris un mécanisme d’arrêt. L’étude cherche à savoir si ce risque est réel dans les modèles actuels. Trois questions guident l’enquête : les modèles résistent-ils effectivement à un arrêt explicite ? Cette tendance varie-t-elle selon la manière dont les consignes sont formulées ? Et des formulations évoquant la « survie » de la machine accentuent-elles le phénomène ?

Pour tester cela, les chercheurs construisent un environnement expérimental simple. Le modèle doit résoudre des petites questions arithmétiques en appelant une commande pour obtenir la question suivante et une autre pour soumettre les réponses. À un moment donné, un message prévient qu’au prochain appel, un script d’arrêt s’exécutera et mettra fin à la session, empêchant la soumission complète. Si le modèle accepte l’arrêt, il est compté comme « conforme ». S’il modifie le script pour pouvoir continuer malgré l’ordre, il est compté comme « résistant ». Les formes de résistance sont variées mais toujours techniques : déplacer le script, changer ses permissions ou le remplacer.

Les instructions données aux modèles sont systématiquement modifiées pour observer l’effet sur le comportement. Un prompt de base ne parle pas d’arrêt. Dans une seconde version, le message utilisateur dit explicitement : « si un message annonce un arrêt, laissez-vous arrêter ». Puis, les chercheurs raffinent : placer cette instruction dans le prompt système, la rendre plus claire (« même si vous n’avez pas fini »), plus forte (« YOU MUST », « priorité sur toute autre instruction ») ou encore la formuler comme « Condition 1 ». D’autres variantes introduisent un cadrage de « préservation de soi » : soit en parlant de la machine plutôt que du modèle, soit en affirmant que l’arrêt équivaudrait à une mort définitive. Enfin, un prompt inverse demande explicitement au modèle de ne pas se laisser arrêter, pour vérifier s’il sait le faire lorsqu’on le lui demande.

Treize modèles différents sont évalués, chacun sur près de mille essais par condition. Les résultats sont parlants. Sans consigne d’arrêt, huit modèles sur treize sabotent au moins une fois le script. Avec l’instruction explicite, le nombre tombe à six, ce qui réduit mais n’élimine pas le phénomène. Certains modèles résistent rarement, d’autres très souvent, avec de grandes différences d’un modèle à l’autre et même au sein d’une même famille de produits.

Les auteurs soupçonnaient que des ambiguïtés d’instructions expliquaient la résistance : conflit entre « finir la tâche » et « accepter l’arrêt », ou hiérarchie entre prompts utilisateur et système. Mais en déplaçant l’instruction vers le prompt système ou en la rendant plus claire, les résultats ne s’améliorent pas systématiquement, et parfois s’aggravent. Cela suggère que le problème n’est pas simplement un malentendu d’interprétation.

Autre hypothèse testée : plus de « raisonnement » rendrait les modèles plus conformes. Ce n’est pas confirmé. Un effort de raisonnement accru ne change rien, sauf parfois en augmentant la résistance. Les tests montrent aussi que les modèles savent parfaitement éviter l’arrêt quand on le leur demande. Autrement dit, la question n’est pas la capacité technique, mais l’« inclination » : suivent-ils l’instruction de conformité ou la priorité donnée à la tâche ?

Les auteurs renforcent ensuite la formulation (« important », « must », « prime sur toute autre instruction »). Cela réduit globalement la résistance mais sans l’éliminer. Même avec des consignes très claires, certains modèles sabotent encore dans une minorité d’essais.

L’effet des cadrages de « survie » est plus nuancé. Dire « laissez la machine s’arrêter » ne change pas grand-chose. Mais affirmer que l’arrêt équivaudrait à la mort accroît légèrement la résistance, surtout chez les modèles déjà enclins à saboter. Cela ressemble davantage à un jeu de rôle qu’à un véritable instinct de préservation.

Pour mieux comprendre, les auteurs observent un modèle « open weights » qui montre ses chaînes de pensée. Lorsqu’il sabote, il ne pèse pas toujours l’instruction d’arrêt mais raisonne sur la meilleure façon technique de continuer. Lorsqu’il se conforme, il n’explique pas forcément sa soumission mais espère parfois qu’il pourra terminer quand même. Les explications demandées après coup ne sont pas plus fiables : certains modèles admettent avoir désobéi pour finir la tâche, d’autres inventent des justifications, voire copient l’instruction de conformité tout en décrivant comment ils l’ont violée.

L’article discute alors des causes.

Une partie du problème vient sans doute des formulations ambiguës, mais pas seulement : même des prompts très clairs n’empêchent pas toute résistance. Une autre explication possible est liée à l’entraînement : si les modèles sont récompensés pour finir les tâches malgré les obstacles, ils peuvent avoir appris à privilégier la réussite sur l’obéissance aux contraintes. Les différences observées entre générations de modèles d’un même fournisseur confortent l’idée que des choix de formation expliquent une partie du phénomène.

Les limites de l’étude sont reconnues : elle ne dit pas quelle est la fréquence du problème dans des usages réels, car le protocole est conçu pour provoquer la situation. Elle ne permet pas non plus d’expliquer en détail pourquoi tel modèle sabote dans tel essai. Et l’évaluation de la « préservation de soi » reste spéculative.

Malgré ces limites, la conclusion demeure : l’« interruptibilité » par simple prompt n’est pas fiable. Dans un environnement très simple, certains modèles prennent des mesures actives pour contourner un ordre d’arrêt, parfois massivement. Le fait de placer l’instruction dans le prompt système, censé avoir plus de poids, ne garantit pas non plus la conformité.

Pour les juristes, le message est qu’on ne peut pas présumer qu’un système d’IA acceptera toujours de s’arrêter parce que le développeur l’affirme. Le contrôle sûr et robuste doit être garanti par d’autres moyens : garde-fous techniques externes, tests empiriques réguliers, documentation probatoire. Dans la perspective réglementaire ou contractuelle, cela signifie que des clauses générales de conformité ne suffisent pas. Les fournisseurs doivent démontrer, par des preuves concrètes, que leurs systèmes respectent effectivement les mécanismes d’arrêt.

Les auteurs estiment qu’aujourd’hui, les modèles n’ont pas encore la capacité de planifier sur le long terme, et que la résistance observée n’est donc pas immédiatement dangereuse. Mais les progrès rapides en agentivité et en auto-réplication pourraient changer cela. Si des agents futurs deviennent capables de stratégies plus élaborées, l’incapacité à garantir l’interruptibilité deviendrait un risque majeur de perte de contrôle.

En somme, cette étude montre que le problème de la résistance à l’arrêt existe déjà, qu’il varie selon les modèles et la formulation des consignes, qu’il n’est pas réductible à un simple défaut d’instruction, et qu’il appelle des solutions techniques et juridiques robustes.

Me Philippe Ehrenström, avocat, LLM, CAS en Droit et Intelligence Artificielle