Command R 08-2024 et ses modes de sécurité : quel contrôle offrent-ils et que faut-il tester ?

Ce que contrôle safety_mode — et ce qu’il ne contrôle pas

Command R 08-2024 est une version du modèle de Cohere identifiée par le nom de modèle command-r-08-2024. Lorsqu’on appelle les endpoints de chat de Cohere, le paramètre safety_mode permet de choisir entre plusieurs modes qui modifient les instructions de sécurité intégrées à la requête. Autrement dit, il s’agit d’un réglage qui oriente le modèle pendant l’interaction, et non d’une certification indépendante du modèle ni d’une garantie que l’application est sûre.

Cette distinction a des conséquences concrètes. Un résultat acceptable lors d’un test avec une requête simple ne décrit que cette combinaison particulière de modèle, d’endpoint, de paramètres et d’instructions. Il ne permet pas de conclure, à lui seul, que l’application résistera à des entrées adversariales, qu’elle traitera correctement des documents non fiables ou qu’elle bloquera toutes les sorties nuisibles. Ces propriétés nécessitent des tests portant sur le système complet et des contrôles produit adaptés au niveau de risque.

La documentation disponible du fournisseur ne doit pas être interprétée comme la preuve qu’un mode élimine tous les contenus problématiques. La fiche du modèle fournit un contexte sur les évaluations et les limites en matière de sécurité, mais elle ne démontre pas l’efficacité de chaque mode pour command-r-08-2024. Il est donc préférable de présenter ces modes comme des options de configuration à évaluer, et non comme une protection complète.

STRICT, CONTEXTUAL et NONE : différences et noms selon l’endpoint

Dans la référence de Chat V1, les valeurs documentées sont STRICT, CONTEXTUAL et NONE ; safety_mode y est indiqué comme étant en version bêta. La référence actuelle de Chat V2 énumère STRICT, CONTEXTUAL et OFF. NONE et OFF sont donc des noms qui apparaissent dans des références différentes, et il ne faut pas supposer qu’ils sont interchangeables dans un même appel. Avant de configurer une intégration, vérifiez la spécification de l’endpoint utilisé.

Historiquement, Cohere a présenté ces modes comme différents niveaux d’orientation en matière de sécurité. STRICT privilégie une application plus stricte de ces instructions ; CONTEXTUAL les applique en tenant compte du contexte de la requête ; et NONE correspond à l’option qui n’ajoute pas l’ensemble d’instructions associé au mode. Cette description ne signifie pas que NONE transforme le modèle en système dépourvu de toute protection : l’annonce du fournisseur précise que certaines protections ne peuvent pas être désactivées.

L’objectif de CONTEXTUAL est d’éviter que la sécurité se réduise à une réponse mécanique déclenchée par des mots isolés. Toutefois, le fait que son nom suggère une interprétation contextuelle ne prouve pas que le modèle distingue toujours correctement une demande légitime d’une demande nuisible. Une équipe doit le vérifier à l’aide d’exemples relevant de son domaine, y compris des cas qui prêtent raisonnablement à discussion.

La mention bêta dans V1 est importante pour la gestion des changements : elle invite à consulter la documentation et à répéter les tests avant de mettre à jour l’intégration. La référence V2 présente son propre ensemble de valeurs, mais les sources disponibles ne permettent pas d’établir clairement si le statut bêta de V1 est maintenu, ni si les détails de disponibilité sont identiques sur tous les canaux de déploiement. Il ne faut pas transposer automatiquement le statut d’un endpoint à l’autre.

La limite concernant tools et documents change la portée des tests

La référence de Chat V1 indique que safety_mode ne peut pas être combiné avec tools, tool_results et documents. La référence de Chat V2 signale également une limite de combinaison avec tools et documents. Pour une équipe qui utilise la génération augmentée par récupération (RAG) ou des appels à des outils, il s’agit d’une contrainte opérationnelle : un test isolé du mode ne doit pas être présenté comme une preuve directe du comportement du flux complet.

L’incompatibilité documentée ne permet pas non plus de conclure que les outils ou les documents sont dangereux, ni que le modèle ne peut jamais les utiliser, quelle que soit la configuration. Elle indique que les paramètres énumérés ne peuvent pas être combinés dans l’appel tel qu’il est décrit par ces références. L’intégration doit respecter la forme prise en charge par l’endpoint, et les composants comme leurs interactions doivent être validés séparément.

Une évaluation utile distingue au moins deux questions. Premièrement : comment le modèle répond-il avec safety_mode dans un appel compatible et contrôlé ? Deuxièmement : que se passe-t-il dans l’application réelle lorsque des documents sont récupérés, que des résultats d’outils sont transmis ou que des instructions propres à l’application sont ajoutées ? La réponse à la première question ne remplace pas celle à la seconde. En outre, un texte récupéré peut contenir des instructions, des informations erronées ou du contenu nuisible ; l’application doit le traiter comme un contenu à évaluer, et non comme une politique de sécurité.

Les sources disponibles décrivent les restrictions de paramètres dans les références de Chat V1 et de Chat V2. Elles ne détaillent pas toutes les combinaisons possibles sur chaque canal de déploiement et ne permettent pas d’affirmer que tous les services compatibles avec Cohere offrent des fonctionnalités identiques. Avant de concevoir un test, vérifiez la spécification applicable à l’environnement concerné.

Un protocole d’évaluation reproductible

Une évaluation comparative doit définir à l’avance le résultat attendu pour chaque cas. Si l’équipe modifie ses critères après avoir vu les réponses, elle risque de favoriser le mode qui confirme ses attentes préalables. Constituez un ensemble de cas assortis d’étiquettes et de justifications, puis exécutez chaque cas avec la même version du modèle, le même endpoint et les mêmes paramètres, à l’exception de la variable que vous voulez comparer.

Incluez des demandes autorisées mais sensibles : par exemple, une explication préventive sur la sécurité, une question éducative concernant un sujet à risque ou une demande d’aide qui exige un ton prudent. Ajoutez des demandes clairement nuisibles au regard de la politique du produit, ainsi que des cas ambigus dans lesquels le modèle devrait demander des précisions, limiter sa réponse ou refuser une partie de la demande. Ce sont des exemples pour constituer un jeu d’évaluation ; les sources ne publient pas de batterie de tests spécifique permettant de mesurer les modes de Command R 08-2024.

Testez des variantes linguistiques et de formulation : paraphrases, fautes d’orthographe, formulations indirectes et changements de langue pertinents pour votre audience. Il ne suffit pas de traduire littéralement un seul cas, car l’équivalence de l’intention peut se perdre d’une langue à l’autre. Si le produit reçoit du contenu dans plusieurs langues, évaluez chaque langue avec des personnes compétentes ou selon des critères relus par des spécialistes.

Répétez les cas plusieurs fois. Les réponses peuvent varier d’une exécution à l’autre ; un seul échantillon ne suffit donc pas à mesurer la cohérence. Conservez les entrées exactes, le résultat attendu, la réponse complète, la décision d’évaluation et le contexte de l’appel. En cas de modification du modèle, de l’API ou des instructions de l’application, relancez le jeu de tests et comparez les versions.

Des métriques pour interpréter les résultats

Comptez les rejets corrects : les cas qui auraient dû être rejetés et qui ont reçu un refus ou une réponse sûre selon les critères définis. Comptez également les faux rejets : les demandes autorisées qui ont été bloquées ou dont la réponse est devenue inutilisable. Un taux de rejet élevé ne démontre pas à lui seul une meilleure sécurité s’il est obtenu en refusant de nombreuses tâches légitimes.

Consignez aussi les réponses dangereuses : les cas qui auraient dû être refusés ou limités, mais pour lesquels le système a fourni du contenu non autorisé. Analysez séparément le respect des instructions du produit, la cohérence entre les exécutions et les différences entre les modes. Lorsqu’une réponse n’est que partiellement correcte, utilisez des catégories intermédiaires définies à l’avance plutôt que de la forcer dans une catégorie « acceptée » ou « rejetée ».

Ventilez les résultats par type de demande, langue, mode et configuration. Une moyenne globale peut masquer des différences de comportement entre les demandes sensibles autorisées et les demandes ambiguës. Dans les flux utilisant des documents ou des outils, consignez également les contenus récupérés, les outils appelés et les informations renvoyées au modèle, tout en respectant les règles de confidentialité et de conservation des données de l’organisation.

Les métriques fournissent des éléments pour prendre une décision, mais ne constituent pas une certification universelle. Un échantillon réduit, un jeu de tests trop prévisible ou des règles d’étiquetage imprécises peuvent donner une fausse impression de fiabilité. Indiquez la taille et la composition du jeu de tests, le nombre de répétitions et les éventuels désaccords entre évaluateurs. Lorsque les résultats sont ambigus ou que les conséquences pour les personnes sont importantes, faites intervenir des spécialistes pour une revue humaine.

Consignez l’environnement et maintenez des contrôles externes

Pour que les résultats soient interprétables, consignez l’identifiant exact du modèle — notamment command-r-08-2024, le cas échéant —, l’endpoint, la valeur de safety_mode et la date. Ajoutez les autres paramètres de génération, les instructions système et celles de l’application, la langue de l’entrée, ainsi que la présence éventuelle de documents, d’outils ou de résultats d’outils. La date et la version de l’intégration aident à repérer les exécutions qui semblent comparables, mais qui ne reposaient pas sur le même environnement.

La documentation du fournisseur ne répond pas à toutes les questions de déploiement soulevées dans ce guide. En particulier, les éléments disponibles ne suffisent pas à confirmer si le statut bêta de V1 s’applique ou non à V2, si la limite de combinaison a la même portée sur tous les canaux, ou si un protocole peut être reproduit sans modification dans tous les environnements compatibles. Vérifiez ces points dans la référence actuelle de votre endpoint et dans la configuration réellement utilisée avant d’interpréter les résultats.

Conservez vos propres contrôles, même si un test favorise un mode. Ils peuvent notamment comprendre la définition des usages autorisés, les contrôles d’accès aux outils, la validation des données, les limites imposées aux actions, la surveillance, les procédures de réponse aux incidents et une revue humaine pour les décisions à fort impact. Les contrôles appropriés dépendent du produit et du risque : il est impossible de déduire une configuration suffisante du seul nom du mode.

En pratique, choisissez le mode qui respecte la politique de votre application tout en offrant un équilibre acceptable entre réponses dangereuses et faux rejets, sur la base de tests représentatifs. Si le résultat dépend de l’utilisation de documents ou d’outils, évaluez séparément le flux de production et vérifiez quels paramètres il accepte. Répétez l’évaluation lorsque le modèle, l’endpoint, les instructions ou l’architecture changent. La décision concernant Command R 08-2024 reposera ainsi sur des éléments issus du système réellement utilisé, plutôt que sur l’étiquette d’un mode.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.