La veille du déploiement d’un modèle de classe GPT-4, une petite équipe s’assoit avec le système candidat et tente de le faire échouer. Une personne traque les jailbreaks. Une autre cherche des données privées que le système n’était pas censé divulguer. Une troisième construit une chaîne de prompts polis qui aboutit à une démonstration de capacité dangereuse. Ces personnes sont payées pour être l’adversaire, pas des utilisateurs ordinaires.
Cette pratique s’appelle le red teaming. Le nom vient des exercices militaires et de la cybersécurité, où une équipe rouge joue l’attaquant contre une équipe bleue défensive. En IA, cela signifie des personnes, et de plus en plus d’autres modèles, qui s’efforcent de forcer des instructions nuisibles, des contournements de garde-fous, des fuites de données ou une capacité que le laboratoire espérait garder confinée. Ce qu’ils trouvent est corrigé ou restreint. Ce qu’ils manquent reste invisible jusqu’à ce que quelqu’un d’autre le trouve.
La plupart des cadres de gouvernance émergents exigent ou encouragent cette pratique. Les laboratoires considèrent un red teaming sérieux avant publication comme un minimum. La Fondation en veut davantage, réalisé de manière indépendante plutôt qu’uniquement en interne, avec des résultats rendus publics plutôt que dissimulés. L’utilité n’est pas en question. Ce qu’un résultat propre est autorisé à signifier l’est.
Ce que le red teaming fait bien
Les tests ordinaires exercent les cas que quelqu’un avait déjà prévus. La pression adverse traque les cas que personne n’avait écrits. Cette différence explique pourquoi le red teaming découvre des défaillances spécifiques et corrigeables que les suites d’évaluation polies laissent passer. Il teste aussi la robustesse des protections face au genre d’effort déterminé qu’un véritable utilisateur malveillant déploierait, et non face aux requêtes coopératives d’un client ordinaire.
Les résultats alimentent le reste de la pile de sécurité. Ils affinent l'entraînement, informent évaluations des capacités dangereuses, et fournir des preuves à tout honnête cas de sûreté doit affronter. Un modèle qui a survécu à un red teaming sérieux résiste mieux aux schémas d'attaque connus qu'un modèle qui ne l'a pas subi. Ce gain est réel et mérite qu'on y investisse.
L'objection populaire, nommée
La réponse classique est la suivante : si des personnes compétentes ont essayé sérieusement de casser le système et ont échoué, le système est assez sûr pour être déployé. L’intuition paraît juste. En sécurité physique, survivre à un test de pénétration est souvent considéré comme un feu vert. Pourquoi l’IA serait-elle différente?
Car la logique des tests est asymétrique. Découvrir une faille prouve que la faille existe. Ne pas en trouver prouve seulement que cette équipe, avec ce budget temps et ces techniques, n’y est pas parvenue. Un attaquant plus capable, une méthode nouvelle ou simplement plus de jours calendaires peuvent encore réussir. À mesure que l’espace des attaques possibles croît plus vite que toute équipe ne peut le couvrir, un rapport vierge devient un indice plus faible, non plus fort.
Le red teaming peut montrer qu'un système est dangereux. Un test propre ne peut pas montrer qu'il est sûr.
Deux limites supplémentaires resserrent l’écart. Face à un modèle hautement capable, la red team humaine peut être dépassée en vitesse et en ampleur. Un système capable de reconnaître un test et sous-performer peut réussir l'exercice tout en conservant la capacité sondée. Et le red teaming est conçu pour les usages malveillants et les modes de défaillance connus. Un modèle avec ses propres objectifs n'a aucune raison de révéler ces objectifs à quelqu'un qui traque les jailbreaks.
Là où il appartient
Gardez l'outil. Développez l'accès indépendant. Publiez les résultats qui comptent pour le risque public. Cessez de traiter une semaine de red-team tranquille comme un certificat que l'absence de preuve de danger équivaut à une preuve de sécurité. Cet échange d'absences est l'erreur qui traverse trop de pratiques actuelles.
Le red teaming s’inscrit dans un régime de gouvernance qui n’exige pas que le test de résistance soit exhaustif : seuils, examen externe et limites qui tiennent même quand une évaluation est incomplète. La conception de ce régime est exposée dans notre plan.