Dans une équipe de cinq développeurs qui utilisent Claude Code au quotidien, il suffit qu'un seul bascule sur Opus 5.5 pour un refacto de trois heures pour que la facture API du mois double. Personne n'a rien fait de mal. Chacun a choisi son modèle dans /model, comme le CLI le propose. Sauf que sans règle, chacun choisit selon sa journée, son humeur, sa lecture du dernier changelog. Pour ceux qui découvrent l'outil, notre guide complet pour apprendre Claude pose les bases avant d'attaquer ce type de verrouillage.
Depuis la version 2.1.283 de Claude Code, publiée le 25 septembre 2026, deux réglages gérés au niveau organisation règlent ce problème : availableModelsMatch et deniedModels. Voici comment les combiner, où les placer, et comment vérifier qu'ils tiennent.
Pourquoi verrouiller les modèles Claude Code en équipe
Trois cas typiques justifient un verrouillage dur, tous vérifiables en regardant sa facture ou le code livré.
Premier cas : le contrôle des coûts. Claude Opus 5.5 est à 4 $ le million de tokens en entrée et 20 $ en sortie. Claude Sonnet 5 est à 2 $ et 10 $. Sur une session agentique longue qui manipule plusieurs milliers de fichiers, l'écart cumulé n'est pas de 2x, il est bien plus élevé une fois compté le raisonnement de fond et les allers-retours. Un dev qui met Opus par défaut sur du CRUD banal, c'est un budget mensuel qui dérape sans que personne ne le voie avant la fin du mois.
Deuxième cas : la cohérence des sorties. Deux devs sur le même repo, l'un en Sonnet 5, l'autre en Haiku 4.5, produisent du code de qualité différente sur la même consigne. Les revues de code deviennent inégales, le style diverge, les patterns aussi. Fixer un modèle unique par projet règle ça.
Troisième cas : la conformité interne. Un modèle marqué comme déprécié (Sonnet 4.6, par exemple, remplacé comme Sonnet courant depuis le 30 juin 2026), un modèle non validé par la sécurité, ou un modèle dont la fenêtre de contexte pose un problème RGPD sur certains dossiers : l'équipe doit pouvoir en interdire l'usage sans compter sur la discipline individuelle.
Les deux paramètres clés : availableModelsMatch et deniedModels
availableModelsMatch travaille avec la liste availableModels déjà présente dans les settings de Claude Code. Sa valeur par défaut autorise implicitement les versions ultérieures d'un modèle listé. Quand on lui passe la valeur "exact", chaque entrée de availableModels n'autorise que la version qu'elle nomme précisément. Une nouvelle version du même modèle qui sortirait la semaine suivante resterait bloquée tant qu'elle n'est pas explicitement ajoutée.
C'est le comportement voulu quand on veut piloter les mises à jour manuellement, pas les subir un lundi matin après un release d'Anthropic.
deniedModels fait l'inverse : une liste noire explicite qui bloque les modèles nommés, même si availableModels les autoriserait par ailleurs. Utile pour interdire une famille entière (typiquement claude-opus-*) sans avoir à énumérer les versions de Sonnet et Haiku qu'on veut garder.
Les deux réglages sont complémentaires. Une organisation peut définir availableModels par pattern large, puis exclure ponctuellement une version précise via deniedModels. La liste noire l'emporte sur la liste blanche en cas de conflit.
Ces champs vivent dans le settings.json de Claude Code. Le format attendu est celui-ci :
{
"availableModels": [
"claude-sonnet-5",
"claude-haiku-4-5"
],
"availableModelsMatch": "exact",
"deniedModels": [
"claude-opus-5",
"claude-opus-5-5"
]
}Où placer la config selon le niveau de verrouillage voulu
Claude Code lit trois emplacements de settings, avec un ordre de priorité clair.
Les settings utilisateur (~/.claude/settings.json) sont propres à chaque poste. Un dev peut y mettre ce qu'il veut. C'est le niveau le plus faible, à ne pas utiliser pour imposer une politique d'équipe puisque chacun peut le modifier.
Les settings projet (.claude/settings.json, committés à la racine du repo) s'appliquent à quiconque ouvre ce projet avec Claude Code. C'est le bon compromis pour la plupart des équipes : versionné dans git, revu comme n'importe quel autre fichier de config, tracé par git blame. Un dev qui veut le contourner doit modifier le fichier committé, ce qui laisse une trace dans l'historique du repo.
Les settings managed, poussés au niveau organisation (paramètres gérés côté serveur, MDM, registre, managed-settings.json selon la plateforme), s'imposent à tous et ne peuvent pas être modifiés par l'utilisateur. C'est le seul niveau qui tient vraiment quand on veut un verrouillage strict, typiquement pour des raisons de conformité ou de contrôle budgétaire imposé par la direction.
La priorité descend du plus fort au plus faible : managed écrase project, qui écrase user. Une deniedModels définie en managed ne peut pas être annulée par une availableModels en project.
Pour une équipe de cinq à dix devs sans contrainte réglementaire forte, un .claude/settings.json versionné suffit. Pour une équipe qui déploie sur un secteur régulé ou qui veut protéger un budget IA agressif, il faut passer par le managed.
Exemple de config pour une équipe de 5 devs
Le cas courant : autoriser uniquement Sonnet 5 (le modèle par défaut recommandé) et Haiku 4.5 (pour les tâches légères, moins chères), refuser explicitement toute la famille Opus. Placé dans .claude/settings.json à la racine du repo :
{
"availableModels": [
"claude-sonnet-5",
"claude-haiku-4-5"
],
"availableModelsMatch": "exact",
"deniedModels": [
"claude-opus-5",
"claude-opus-5-5",
"claude-fable-5",
"claude-fable-5-1"
]
}Trois choses à noter. La valeur "exact" sur availableModelsMatch garantit qu'un futur claude-sonnet-5-1 qui sortirait dans quelques semaines ne sera pas utilisable tant que quelqu'un n'a pas ajouté la ligne. La liste noire couvre aussi Fable, pour éviter qu'un dev curieux ne tente claude-fable-5-1 à 10 $ le million de tokens en entrée. Le fichier est committé : toute modification passe par une pull request.
Variante pour une équipe qui garde un projet R&D où Opus est autorisé : on met la config restrictive ci-dessus dans les repos de production, et dans le repo R&D on met un .claude/settings.json plus permissif qui autorise claude-opus-5-5. Chaque dev ouvre le repo concerné, Claude Code lit la config locale, et le comportement s'adapte automatiquement.
Cette logique de séparer par projet vaut aussi pour d'autres réglages Claude Code : hooks, permissions Bash, serveurs MCP autorisés. C'est cohérent avec la configuration complète de Claude Code pour une équipe qu'on met en place quand on industrialise l'usage.
Vérifier que le verrouillage fonctionne
Trois vérifications suffisent après déploiement.
Un : ouvrir un terminal dans le repo, lancer claude, taper /model. La liste affichée doit correspondre exactement à availableModels, sans les entrées bloquées par deniedModels. Si Opus apparaît encore alors qu'il est en liste noire, la config n'est pas prise en compte (mauvais emplacement, mauvais nom de fichier, syntaxe JSON invalide).
Deux : tenter de forcer un modèle interdit via l'argument CLI (claude --model claude-opus-5-5). Claude Code doit refuser avec un message explicite. C'est le vrai test, parce qu'un utilisateur motivé cherchera à contourner /model.
Trois : si la config est managed, refaire les deux tests précédents avec un compte non-admin, sur un poste où l'utilisateur n'a pas les droits de modifier la config gérée. Le comportement doit être identique.
Côté traçabilité, un rapide cat .claude/settings.json confirme ce qui est effectivement versionné, et git log .claude/settings.json montre qui a modifié la politique et quand. Si la politique change tous les quinze jours sans explication, il y a un problème de gouvernance à régler avant celui du verrouillage technique.
Cas limites et pièges courants
Le premier piège : un modèle listé dans availableModels qui devient déprécié et disparaît du catalogue Anthropic. Sonnet 4.6 est passé de "Sonnet courant" à obsolète le 30 juin 2026. Une allowlist qui le mentionne encore ne casse pas Claude Code, mais elle pointe sur du vide. Prévoir une revue mensuelle des settings.json versionnés, en même temps qu'on regarde la facture API.
Le deuxième : un nouveau modèle Claude qui sort et que personne dans l'équipe ne peut utiliser tant que la config n'est pas mise à jour. C'est exactement le comportement voulu quand on a mis availableModelsMatch: "exact", mais ça peut frustrer un dev qui a lu le changelog du matin et veut tester. Bien communiquer cette règle en interne : les mises à jour de modèle sont pilotées, pas subies.
Le troisième : les alias comme claude-sonnet-latest (s'il en existe un pour le modèle concerné). Les autoriser fait sauter tout le principe du verrouillage, puisqu'ils basculent automatiquement vers la dernière version. Les traiter comme des modèles à part entière, à interdire via deniedModels si on veut vraiment contrôler les mises à jour.
Le quatrième : les sous-agents lancés par Claude Code (délégation à un agent, workflows, Managed Agents) héritent normalement de la config de la session parente pour ce qui est du choix de modèle. Mais si un sous-agent tourne dans un contexte hébergé côté Anthropic (Managed Agents), les règles de permission côté Claude Managed Agents s'appliquent en plus. Vérifier ce point si l'équipe combine Claude Code local et agents hébergés.
Intégrer ce verrouillage dans votre setup Claude global
Le verrouillage des modèles est une brique, pas un système complet. Elle vit à côté de trois autres qui méritent la même rigueur.
Les hooks (PreToolUse, PostToolUse) permettent d'auditer ou de bloquer certains appels d'outils. Utile pour logger qui utilise quoi. Les permissions d'outils (allow, ask, deny sur Bash, Read, Write) définissent ce que Claude Code peut faire une fois qu'il a choisi son modèle. Les serveurs MCP autorisés au niveau organisation suivent la même logique de gouvernance que deniedModels : limiter quels connecteurs externes toute l'équipe peut utiliser.
Côté Claude.ai (donc hors CLI), la logique est différente mais complémentaire. Un dirigeant qui veut cadrer l'usage global de Claude par son équipe peut aussi s'intéresser à comment cadrer l'usage de Claude côté Projects et Artifacts, qui touche le web plutôt que le terminal.
Pour une équipe qui construit une politique complète, la démarche est : verrouiller les modèles (cet article), verrouiller les serveurs MCP, cadrer les permissions Bash, versionner tout ça dans le repo. Pour aller plus loin sur le pilotage quotidien de Claude Code et intégrer ces règles dans un flux de travail durable, la formation Maîtriser Claude au quotidien couvre le setup, les prompts et l'automatisation en cinq semaines de cohorte.