9 min de lecture - Politique d’usage d’Anthropic : un contrôle avant le 12 novembre
AI Governance
Date de publication 9 octobre 2026 · Auteur Exceev Consulting
Anthropic a publié une politique d’usage révisée le 8 octobre 2026, qui entrera en vigueur le 12 novembre. Pour une entreprise qui utilise Claude dans un produit, un agent interne ou via un fournisseur cloud, il faut identifier les usages couverts par le nouveau texte, nommer le responsable de chaque décision et vérifier que le produit se comporte comme l’indique le dossier de conformité.
La question est plus précise : pouvez-vous relier chaque usage de Claude en production à un cas autorisé, à un contrôle fonctionnel et à un responsable ?
Distinguer les ajouts des clarifications
Anthropic indique que la plupart des modifications clarifient des règles existantes. Son annonce du 8 octobre regroupe les règles contre les campagnes trompeuses, donne des exemples plus précis pour la surveillance et les usages policiers, puis réécrit la partie consacrée aux usages à haut risque afin de faciliter la classification des recommandations. Le texte ajoute aussi des contrôles pour les modèles reliés à du matériel capable d’actions physiques autonomes et une règle contre les comportements abusifs, répétés et sans finalité envers les modèles.
La politique complète prévue pour le 12 novembre s’applique aux utilisateurs des applications Anthropic, aux clients de l’API, aux clients qui accèdent à Claude par un fournisseur cloud ou un revendeur autorisé, ainsi qu’aux utilisateurs finaux des produits qui intègrent Claude. Déplacer une intégration vers un autre canal commercial ne dispense donc pas de classifier l’usage sous-jacent.
Quatre parties méritent une vérification explicite dans un déploiement professionnel :
| Partie de la politique | Déclencheur décrit par Anthropic | Preuves à examiner |
|---|---|---|
| Recommandation à haut risque | Claude contribue à produire ou transmettre une recommandation sur une personne identifiée dans des domaines comme l’emploi, le crédit, la santé, le droit ou l’accès à des services | Qualification du réviseur, pouvoir de décision, trace de la revue et information de l’utilisateur |
| Action physique | La sortie du modèle commande sans approbation humaine préalable un équipement susceptible de blesser | Visibilité de l’opérateur, arrêt, comportement en cas de déconnexion et limites de sécurité indépendantes |
| Chatbot ou agent destiné aux consommateurs | Un utilisateur externe échange directement avec le système | Information affichée au début de la session ou dans l’interface |
| Workflow agentique | Un agent agit par des outils, un navigateur ou des systèmes connectés | Périmètre des outils, journaux d’action, points d’approbation et preuve du respect de la politique |
La distinction influe sur la priorité de correction, pas sur le test du comportement actuel.
Traiter la politique du fournisseur comme une dépendance de production
Une API de modèle figure généralement parmi les dépendances techniques, tandis que sa politique d’usage reste chez les équipes juridiques ou achats. Cette séparation ne tient plus lorsque le texte définit ce que le produit peut recommander, divulguer ou commander.
Le socle du cadre de gestion des risques liés à l’IA du NIST place les risques liés aux tiers et à la chaîne d’approvisionnement dans une gouvernance continue. La catégorie Govern 6 demande des règles sur les risques des systèmes d’IA tiers et des processus de secours en cas de panne ou d’incident sur un système à haut risque. Govern 1.5 prévoit une surveillance planifiée et des revues périodiques. Ce cadre est volontaire, mais sa structure convient bien à cet événement : la modification d’une politique fournisseur devient l’entrée d’un contrôle reproductible, pas un courriel lu une seule fois.
Commencez par un inventaire des cas d’usage, pas par une liste de comptes Claude. Pour chaque flux de travail, consignez le fournisseur, le canal d’accès, le modèle ou service, la tâche visée, les personnes concernées, l’action possible, le responsable métier et le responsable technique. Ajoutez la date et la version de la politique utilisée pour l’évaluation. Une liste de comptes ne peut pas montrer que la même clé d’API sert à résumer des documents internes et à classer des candidatures, avec des exigences très différentes.
Prenons quatre usages hypothétiques. Ce sont des exemples de classification, pas la description d’un système d’Exceev ou d’un client :
- Un assistant interne résume des procédures. Anthropic exclut la synthèse interne lorsque la sortie n’est pas la recommandation finale à haut risque. Empêchez néanmoins qu’un brouillon devienne le conseil final sans revue.
- Un outil classe des candidatures. Cet usage figure dans la liste à haut risque : une personne qualifiée doit pouvoir modifier le résultat et la personne concernée doit être informée.
- Un agent de support répond à des clients. Même hors du haut risque, la règle sur les agents destinés aux consommateurs impose d’indiquer qu’il s’agit d’une IA dans l’interface ou au début de la session.
- Un modèle commande un robot mobile. La revue avant exécution peut placer les commandes dans une exclusion. Une action autonome susceptible de blesser exige observation, arrêt, état sûr à la déconnexion et limites indépendantes de la sortie du modèle.
Classez tout le parcours, de la sortie du modèle à l’effet métier. Une invite présentée comme une simple « aide à la rédaction » peut alimenter une décision automatisée quelques services plus loin.
Construire un contrôle du changement en quatre étapes
1. Figer les preuves examinées
Conservez l’URL, la date d’entrée en vigueur et une copie datée, ou une empreinte, de la politique. Reliez-les à l’inventaire, au déploiement et au canal fournisseur. Si la classification reste incertaine, consignez-la comme non résolue et confiez-la à la personne qualifiée pour trancher.
2. Relier le texte de la politique au comportement du produit
Suivez les entrées, sorties, personnes et actions. Repérez où le résultat atteint la personne concernée, où le réviseur peut le modifier, quel composant affiche l’information et ce qui suit une panne. Pour chaque agent, listez les outils et leur action maximale. Reliez ensuite chaque clause à un contrôle observable : rôle du réviseur, file de revue, état bloquant et journal d’approbation.
3. Tester les contrôles avec des cas représentatifs
Utilisez des dossiers synthétiques. Testez un cas ordinaire, une correction, l’absence de réviseur et la déconnexion du fournisseur. Vérifiez que la recommandation reste bloquée avant revue, que le réviseur peut la modifier et que l’information apparaît sur chaque canal.
Le matériel exige un essai de sécurité distinct, mené par des personnes qualifiées dans un environnement contrôlé. Vérifiez que l’opérateur peut observer et arrêter l’équipement, qu’une perte de connexion produit un état sûr et que les limites de vitesse, de force, de température ou d’autres paramètres ne dépendent pas de la sortie du modèle. Une instruction dans l’invite n’est pas une limite indépendante.
4. Consigner une décision d’autorisation, de restriction ou d’arrêt
Le registre doit nommer le flux de travail, la version, les clauses, le responsable, les tests, le risque résiduel et la prochaine revue. Une restriction peut retirer un outil, garder la sortie en interne ou ajouter une revue obligatoire. Un arrêt impose de désactiver la fonction, révoquer ses identifiants et préparer l’assistance. Reprenez le contrôle après toute modification substantielle ou nouvelle politique.
Séparer les règles du fournisseur des obligations européennes
La politique d’Anthropic est une règle du fournisseur. Elle ne remplace pas le droit applicable, ce que le texte précise lui-même. Une équipe qui travaille en France ou sert des personnes dans l’Union européenne doit donc mener une analyse juridique à côté de la revue fournisseur, sans les confondre.
Les orientations actuelles de la Commission européenne sur l’article 50 indiquent que ces obligations s’appliquent depuis le 2 août 2026. Elles couvrent notamment l’information des personnes face à un système d’IA en interaction directe, ainsi que certaines obligations des déployeurs pour les hypertrucages et les textes d’intérêt public sans contrôle éditorial humain. Leur périmètre diffère des règles d’Anthropic.
Réussir une liste de contrôle ne prouve pas le respect de l’autre. Gardez au moins deux champs dans le registre : le fondement tiré de la politique fournisseur et le fondement juridique applicable. Si le produit utilise plusieurs fournisseurs de modèles, ajoutez un résultat pour chacun tout en conservant une analyse juridique du système réel et de son contexte. Notre guide sur les rôles de fournisseur et de déployeur peut structurer cette analyse distincte ; il ne constitue pas un avis juridique.
Notre guide sur l’information dans les chatbots détaille les vérifications d’interface et de canal. Pour les agents capables d’agir, le modèle de contrôle en trois portes ajoute des preuves sur les entrées et l’exécution. N’appliquez ces vérifications qu’après avoir classé le flux actuel au regard de la politique fournisseur révisée.
Décider avant l’entrée en vigueur
Au 12 novembre, une équipe devrait pouvoir produire une courte chaîne de preuves : entrée d’inventaire, classification de la politique, contrôle fonctionnel, résultat de test, responsable et décision. Une petite entreprise n’a pas besoin d’une grande plateforme de gouvernance. Un registre versionné relié aux tickets produit et aux journaux de test suffit s’il reste à jour et si quelqu’un peut agir.
La révision d’Anthropic crée une échéance actuelle, mais la leçon opérationnelle vaut pour tout fournisseur de modèles externe. Un texte de politique peut modifier ce qu’un système déployé a le droit de faire sans mise à jour de paquet ni diff de code. Faites passer ce changement par la même discipline qu’une dépendance de production.
Sources et limites
Nous avons ouvert et relu chaque source ci-dessous le 9 octobre 2026.
- L’annonce d’Anthropic du 8 octobre 2026 établit la date de publication, l’entrée en vigueur au 12 novembre, la distinction entre clarifications et ajouts, ainsi que les principales parties modifiées.
- La politique d’usage d’Anthropic applicable le 12 novembre 2026 définit les utilisateurs couverts, les recommandations à haut risque, les actions physiques, l’information, la revue humaine, les exclusions et la responsabilité liée aux usages agentiques.
- Le socle du cadre de gestion des risques liés à l’IA du NIST fournit un cadre indépendant et volontaire sur les inventaires, la revue périodique, les risques liés aux tiers, les plans de secours et la supervision humaine.
- Les orientations de la Commission européenne sur les obligations de transparence de l’article 50 indiquent la date d’application actuelle dans l’Union et décrivent certaines obligations d’information des fournisseurs et déployeurs.
Nous n’avons pas examiné un contrat Anthropic privé, testé les garde-fous d’Anthropic, classé un vrai déploiement ni analysé le droit d’un pays ou d’un cas d’usage précis. Les exemples proposent des tests de gouvernance ; ils ne constituent ni un avis juridique, ni un avis de sécurité, ni une certification. Les documents du fournisseur, les pratiques d’application et les orientations européennes peuvent changer après la date de revue. Vérifiez les sources à jour avant toute décision de production ou de conformité.
Vous envisagez l'IA pour votre équipe ?
Nous aidons les entreprises à passer du prototype à la production, avec une architecture pérenne et des coûts maîtrisés.