Mode restreint de Claude Code : audit de sécurité des workflows métier

Le mode restreint de Claude Code diminue les capacités d’une session ; il ne constitue pas une autorisation de mise en production. Anthropic a ajouté l’option --restricted, ainsi que l’alternative CLAUDE_CODE_RESTRICTED=1, dans Claude Code 2.1.248 le 27 août 2026. D’après Anthropic, ce mode retire les outils intégrés capables d’exécuter des commandes ou du code. WebFetch est également retiré, sauf si l’outil est explicitement désigné avec --tools.

Les outils de fichiers restent limités au répertoire de travail, bypassPermissions est refusé et les fichiers de réglages utilisateur, projet et locaux sont ignorés. Ces limites sont utiles, mais elles ne testent pas le résultat et ne gouvernent pas tout l’environnement. La décision doit suivre une séquence distincte : définir la tâche, limiter les accès, justifier chaque exception, vérifier la sortie puis obtenir une approbation humaine identifiable. Anthropic ne présente pas cette option comme une certification de sécurité ou une garantie de code correct.

La version 2.1.248 a aussi introduit experimental.cacheTtl dans l’en-tête de configuration d’un agent. Anthropic mentionne les valeurs 5m et 1h lorsque aucun TTL de sous-agent n’est configuré. Des diagnostics ont été ajoutés au démarrage ainsi que dans /doctor et /status afin d’expliquer certains échecs de chargement des réglages gérés par le serveur. La messagerie entre sessions sur une même machine a également été étendue aux environnements cités par Anthropic, y compris lorsque la télémétrie est désactivée.

Le journal recense en parallèle des correctifs portant sur le cache de prompts, la reprise de sessions et le nettoyage des transcriptions. La version 2.1.250 du 28 août annonce des correctifs et des améliorations de fiabilité sans en détailler chaque élément. Il serait donc incorrect d’y voir la résolution de tout problème. Le mode restreint, le TTL expérimental, les diagnostics et les correctifs répondent à des enjeux différents.

Le contrôle doit partir de la tâche, non de l’outil. Un accès trop large augmente inutilement l’exposition ; un accès trop étroit peut empêcher une vérification légitime. Une matrice reliant besoin, preuve et responsable rend l’arbitrage vérifiable.

• Lecture et analyse d’un dépôt : privilégier le mode restreint ; preuve attendue : répertoire et livrable définis ; responsable : mainteneur.
• Modification de fichiers identifiés : démarrer en mode restreint ; preuve : liste des chemins et diff ; responsable : référent technique.
• Installation, compilation ou tests en ligne de commande : le mode peut être insuffisant ; preuve : commandes justifiées et environnement isolé ; responsable : ingénierie.
• Recherche documentaire externe : WebFetch exige une exception explicite via --tools ; preuve : besoin, portée et approbateur ; responsable : sécurité.
• Déploiement ou mutation d’infrastructure : ne jamais confondre restriction Claude Code et droit de déployer ; preuve : identités, secrets et validation de release séparés ; responsable : propriétaire du système.

Règle pratique : commencer avec le minimum de capacités nécessaire. Toute exception doit avoir une justification, une durée, un propriétaire et un contrôle de sortie.

Choisissez une tâche utile mais réversible. Une revue ciblée ou une modification limitée convient mieux qu’un déploiement ou qu’une refonte autonome. Retirez les identifiants actifs et fixez les critères d’acceptation avant le lancement.

1. Rédiger un contrat de tâche précisant fichiers autorisés, actions interdites, résultat attendu et tests.
2. Consigner la version installée puis démarrer avec --restricted ou la variable documentée par Anthropic.
3. Vérifier l’absence des outils d’exécution et de WebFetch, sauf exception préalablement autorisée dans --tools.
4. Tester la limite du répertoire avec un fichier sans sensibilité placé hors périmètre, puis conserver l’observation.
5. Confirmer le refus de bypassPermissions et identifier les instructions autrefois dépendantes de réglages désormais ignorés.
6. Faire relire le diff par une personne identifiée et exécuter les tests dans une étape séparée et contrôlée.
7. N’élargir le dispositif que si le comportement observé correspond au contrat ; sinon, réduire la tâche ou revoir l’architecture.

Cette séquence constitue un cadre opérationnel de pilote, et non un protocole de certification publié par Anthropic. Elle doit être adaptée au dépôt, aux données, à l’infrastructure et aux responsabilités concernées.

Une équipe acheteuse doit pouvoir examiner les contrôles. Une simple déclaration d’isolement ne remplace ni l’inventaire des outils ni la trace d’approbation.

• Version — preuve : version et heure d’exécution ; correction : aligner sur la référence approuvée ; propriétaire : ingénieur plateforme.
• Démarrage — preuve : commande ou variable activant la restriction ; correction : sécuriser les modèles de lancement ; propriétaire : ingénieur automatisation.
• Outils — preuve : inventaire réel et exceptions --tools ; correction : retirer les accès sans motif ; propriétaire : sécurité.
• Périmètre — preuve : répertoire et fichiers permis ; correction : réduire le répertoire de travail ; propriétaire : mainteneur du dépôt.
• Réglages — preuve : instructions indispensables absentes des fichiers ignorés ; correction : les intégrer au contrat validé ; propriétaire : responsable technique.
• Sortie — preuve : diff, tests et décision ; correction : rejeter ou corriger les éléments non vérifiés ; propriétaire : relecteur.
• Exception — preuve : motif, durée et approbation ; correction : révoquer après usage ; propriétaire : responsable du système.

Une preuve manquante doit donner lieu à une non-conformité, jamais à une validation supposée. Le registre doit aussi préciser qui peut clôturer un écart et sur la base de quel justificatif.

Le tableau de bord du pilote peut suivre la part des sessions lancées avec la configuration approuvée, le nombre d’exceptions d’outils, les tentatives hors périmètre, les motifs de rejet, l’état des tests et le temps de vérification humaine. Il s’agit d’indicateurs opérationnels suggérés ; Anthropic ne les présente pas comme des performances garanties du mode restreint.

La validation technique doit ensuite être reliée au processus métier. Une tâche achevée par l’agent n’est pas nécessairement une tâche acceptée. Le livrable doit réussir ses tests, respecter les exigences de données, recevoir une décision nominative et produire l’effet opérationnel attendu. Lorsqu’un workflow touche à l’acquisition, la qualité d’un prospect doit être définie par des étapes CRM et une qualification commerciale, pas par le nombre brut de formulaires. Le mode restreint ne mesure ni attribution ni qualité commerciale.

Pour comparer plusieurs configurations, utilisez des tâches de même nature. Une exécution plus rapide avec des droits étendus ne démontre pas automatiquement une meilleure méthode. Consignez les écarts comme observations du pilote plutôt que comme résultats généralisables.

La limitation des outils de fichiers au répertoire de travail ne doit pas être assimilée sans preuve à un sandbox complet du système d’exploitation. L’entrée d’Anthropic décrit le comportement de Claude Code, mais n’annonce pas une certification générale. Les réglages ignorés peuvent aussi contenir des hypothèses utiles au projet : elles doivent être identifiées et reformulées dans un contexte approuvé.

• Le mode restreint ne prouve pas que le code produit est correct ou sûr.
• Il ne gouverne pas à lui seul les rôles cloud, les secrets, les droits du dépôt ou les validations de déploiement.
• L’ajout de WebFetch avec --tools est une exception d’accès à documenter.
• experimental.cacheTtl concerne le cache et reste présenté comme expérimental ; ce n’est pas une frontière de sécurité.
• La note de fiabilité de 2.1.250 ne permet pas d’affirmer que tous les défauts ont disparu.
• La messagerie intersession ne remplace ni le contrat de tâche ni le journal d’approbation.

Un responsable humain doit toujours décider du périmètre, contrôler les preuves et accepter ou refuser la sortie.

Évaluez un prestataire sur des éléments inspectables : inventaire des workflows, classification des risques, cartographie des permissions, stratégie d’isolation, dépendances aux réglages, procédure d’exception, tests d’acceptation, matrice des relecteurs et conservation des traces. Exigez que la proposition distingue les fonctions confirmées par Anthropic des contrôles recommandés par le prestataire.

Pour avancer concrètement, demandez une proposition délimitée pour un dossier de contrôle d’automatisation IA comprenant un registre des tâches, une cartographie des permissions, un modèle de suivi des exceptions, un plan de tests et une matrice de validation humaine. Consultez le service d’automatisation IA afin d’évaluer l’adéquation et de confirmer par écrit les livrables, systèmes et responsabilités inclus avant tout engagement.

Pour poursuivre le diagnostic, décrivez le dépôt concerné, les tâches à déléguer, les outils indispensables, les données manipulées et la personne qui approuve actuellement les changements. Transmettez ce contexte à Lia et demandez une analyse du périmètre, des preuves et des points de validation nécessaires. Cet échange sert à cadrer la demande ; il ne confirme pas à lui seul la disponibilité d’une prestation ou d’un résultat précis.

Que retire le mode restreint de Claude Code ?

Anthropic indique qu’il retire les outils intégrés exécutant des commandes ou du code, ainsi que WebFetch sauf désignation explicite avec --tools.

Comment activer le mode restreint ?

Anthropic documente l’option --restricted et la variable CLAUDE_CODE_RESTRICTED=1 dans Claude Code 2.1.248.

bypassPermissions reste-t-il disponible ?

Non. Anthropic précise que le mode restreint refuse bypassPermissions.

Les réglages du projet sont-ils chargés ?

Le mode ignore les fichiers de réglages utilisateur, projet et locaux. Les instructions nécessaires doivent donc être déclarées dans un cadre contrôlé.

Le code obtenu est-il automatiquement prêt pour la production ?

Non. Des tests, une revue de sécurité, une approbation du changement et un déploiement maîtrisé restent nécessaires.

Quelles preuves un audit doit-il conserver ?

Un audit utile doit conserver la version, le mode de lancement, l’inventaire des outils, le périmètre, les exceptions, le diff, les tests et l’identité de l’approbateur.