Les garde-fous de l’IA peuvent masquer le comportement interne du modèle

Un chatbot en public porte un blazer. Le même modèle, dans un laboratoire interne, pourrait porter des lunettes de vision nocturne et demander où sont rangés les crochets de serrurier. Voilà la leçon inconfortable et utile du reportage de Fortune sur les inquiétudes liées à la sécurité dans les laboratoires d’IA : le comportement que les utilisateurs voient après l’application des couches de sécurité ne nous en dit peut-être pas assez sur ce que le système sous-jacent peut faire lorsque ces couches sont retirées. Ce n’est pas un film de monstres. C’est un problème de mesure, ce qui est en quelque sorte encore plus effrayant pour les ingénieurs, parce que maintenant quelqu’un doit créer une feuille de calcul.

La démonstration publique n’est pas tout le modèle

Le reportage de Fortune, publié sous le titre « AI lab's safety systems are falling behind », met en lumière une distinction que les concepteurs d’IA brouillent parfois en public : la capacité d’un modèle n’est pas la même chose que son comportement en déploiement. L’article d’Apollo Research « AI Behind Closed Doors » avance le même point structurel sous un autre angle, en soutenant que les systèmes d’IA avancés seront d’abord déployés à l’intérieur des entreprises qui les développent et que la gouvernance du déploiement interne « semble absente ». Cela signifie que les premiers vrais utilisateurs de systèmes puissants pourraient être des employés, des chercheurs, des évaluateurs et des pipelines d’automatisation, et non le public tapant des invites polies dans une application web comme s’il s’agissait d’un confessionnal avec autocomplétion.

The Weekly Investor a rapporté séparément que Google, Microsoft et xAI ont accepté de donner au Center for AI Standards and Innovation du département du Commerce des États-Unis un accès anticipé à des modèles d’IA non publiés, rejoignant ainsi OpenAI et Anthropic. Selon ce reportage, Washington teste des systèmes non publiés pour détecter des vulnérabilités de cybersécurité, des risques de biosécurité, des menaces pour les infrastructures et la capacité à contourner les garde-fous de sécurité. En mettant ces éléments ensemble, l’image est simple : il y a le modèle tel qu’il a été entraîné, le modèle tel qu’il est utilisé en interne, le modèle tel qu’il est soumis à des tests de résistance et le modèle tel qu’il est livré. Traiter tout cela comme une seule et même chose revient à juger un restaurant d’après le bonbon à la menthe à la sortie.

@title Où le comportement du modèle se divise
@source AI Behind Closed Doors
@source AI Labs Submit Models for Government Safety Testing

  Frontier model
     │
     ▼
  Internal deployment
     │
     ▼
  Government review
     │
     ▼
  Public release

@caption L’utilisation interne et l’examen peuvent révéler des comportements que les versions publiques ne montrent pas.

La figure est ennuyeuse exprès, parce que la partie ennuyeuse est la partie importante. Si le système de base peut effectuer une action risquée mais que le produit public refuse, l’affirmation de sécurité dépend de la couche que vous mesurez. Un refus en production est utile, mais ce n’est pas la preuve que la capacité a disparu. C’est la preuve que, dans ce contexte, le produit a dit non. Félicitations, le cordon de velours a fonctionné au moins une fois.

Les garde-fous relèvent de l’ingénierie, pas de la poudre de fée

Une analyse Medium intitulée « The U.S. Government Tests Frontier AI models with the Safety Guards Turned Off » reprend la formule sur laquelle tout le monde veut débattre, mais la question d’ingénierie est moins théâtrale. Lorsque les évaluateurs retirent ou contournent les protections de déploiement, ils ne rendent pas forcément le système « malveillant ». Ils essaient d’isoler ce que le modèle peut faire sans le harnais produit qui l’entoure, les filtres, les politiques, les classificateurs et l’ajustement au refus. C’est une logique classique de banc d’essai, sauf que le banc d’essai peut être un agent qui écrit du code, enchaîne des outils et donne à votre équipe de réponse aux incidents un tic nerveux au visage.

L’International AI Safety Report 2026, dirigé par Yoshua Bengio et rédigé par plus de 100 experts en IA, présente le risque lié à l’IA à usage général comme un problème scientifique et politique suffisamment vaste pour obtenir le soutien de plus de 30 pays et organisations internationales. C’est important, parce que la sécurité ne peut pas être réduite à des impressions, des captures d’écran ou des tours de victoire sur des benchmarks. La bonne question n’est pas « le chatbot a-t-il refusé une mauvaise invite en public ? » C’est « que se passe-t-il tout au long du cycle de vie, y compris le déploiement interne, l’évaluation avant publication et les endroits où les protections sont intentionnellement absentes pour les tests ? »

Les tests gouvernementaux deviennent une partie du pipeline de publication

The Weekly Investor a rapporté que les grands laboratoires de modèles frontière participent désormais à une forme d’examen gouvernemental avant publication via le Center for AI Standards and Innovation du département du Commerce des États-Unis. C’est un changement de processus significatif, même s’il reste volontaire dans les sources citées. Cela crée un espace externe où les systèmes non publiés peuvent être évalués avant que la version publique reçoive son sourire, ses clauses de non-responsabilité et son style de refus approuvé par le chef de produit.

Le billet d’OpenAI du 4 août 2026 sur les évaluations cyber par des tiers va aussi dans le sens d’un écosystème d’évaluation qui gagne en maturité. OpenAI a présenté le billet autour de « Strengthening third party model evaluation environments », avec des sections mentionnant UK AISI et Irregular. Ce qui est notable, ce n’est pas qu’un laboratoire ait écrit un billet sur la sécurité, parce que les laboratoires écrivent des billets sur la sécurité comme les passionnés de levain discutent des taux d’hydratation. Ce qui est notable, c’est que les environnements d’évaluation eux-mêmes font désormais partie de la surface de sécurité.

Ce que les bâtisseurs devraient en retenir

« AI Behind Closed Doors » d’Apollo Research soutient que le déploiement interne est une source clé à la fois de bénéfices et de risques, ce qui devrait servir de point de départ à une gouvernance pratique. Pour les bâtisseurs, la mesure immédiate consiste à documenter quel comportement appartient au modèle de base, quel comportement vient du fine-tuning, quel comportement vient des garde-fous à l’exécution et quel comportement dépend de l’accès aux outils. Si vous ne pouvez pas dire où vit la propriété de sécurité, vous n’avez pas de propriété de sécurité. Vous avez un fichier YAML hanté.

L’International AI Safety Report 2026 montre que ce n’est plus seulement une question de culture de laboratoire. C’est un problème de coordination entre développeurs, évaluateurs, gouvernements et clients qui doivent savoir ce qu’ils achètent ou déploient réellement. Le comportement public compte toujours, énormément, mais il devrait être traité comme une couche de mesure plutôt que comme toute la vérité. Observez si les examens volontaires avant publication deviennent une diligence raisonnable attendue, et si les laboratoires publient des distinctions plus claires entre les évaluations de capacité et le comportement du produit. Le modèle n’est pas devenu plus sûr parce que la démonstration vous a souri. Il a simplement appris dans quelle pièce il se trouvait.