Accepter une version de Claude Code : auditer les différences et les autorisations

Claude Code 2.1.260 apporte un support de revue concret : Anthropic a ajouté un panneau placé à côté de la conversation en plein écran pour afficher les modifications non validées pendant l’édition. La version corrige également plusieurs problèmes précis touchant les règles d’accès, le bac à sable Bash, les certificats et certains sous-agents isolés par worktree. Ces évolutions ne prouvent toutefois ni la justesse fonctionnelle ni la sécurité d’une livraison.

Il faut donc considérer le panneau comme une couche d’observation. L’acceptation reste un acte humain appuyé par des éléments reproductibles. Dans le cadre CreatikLab, une modification assistée par IA doit être reliée à un besoin autorisé, un diff indépendant, des tests pertinents, un plan de retour arrière et un approbateur identifiable.

Anthropic date Claude Code 2.1.260 du 3 septembre 2026. Les notes indiquent que le panneau de différences montre les changements non validés en plein écran et se commande avec `/diff`. Elles signalent aussi l’ajout de causes probables aux défauts de cache de prompt dans `/cost` et la ligne d’état, l’arrivée de `/reload-plugins` dans les sessions headless et des formes textuelles de `/advisor`.

La même version corrige des comportements liés aux chemins contenant des parenthèses, aux motifs de règles impossibles à compiler, à certaines substitutions cachées dans des commandes zsh, aux certificats racine d’entreprise et à la configuration Git sous macOS. Anthropic ne présente pas ces correctifs comme une garantie générale de sécurité, de performance ou de conformité métier. Aucun processus universel de mise en production n’est spécifié.

Une revue efficace ne donne pas le même poids à tous les fichiers. La méthode CreatikLab classe d’abord la modification selon sa conséquence possible : contenu et interface, logique applicative, intégration ou données, puis frontières sensibles telles que l’authentification, l’autorisation, le paiement et l’infrastructure. Cette classification relève de la gouvernance du projet, pas d’une fonction annoncée par Anthropic.

Le niveau le plus sensible rencontré détermine les contrôles. Une retouche de texte peut demander une vérification visuelle et fonctionnelle limitée. Une règle d’accès exige des essais autorisés et interdits, un second regard et une procédure de restauration. Cette règle empêche qu’un petit diff soit approuvé trop vite alors qu’il modifie une frontière critique.

La matrice suivante transforme une revue informelle en décision traçable. Chaque ligne doit contenir une preuve observable avant de pouvoir être clôturée.

• Périmètre — Preuve : objectif, état du dépôt et liste des fichiers. Action : justifier chaque changement. Propriétaire : ingénieur chargé de l’implémentation.
• Comportement — Preuve : tests reproductibles et contrôle manuel du parcours. Action : vérifier le succès attendu et les échecs utiles. Propriétaire : QA ou second ingénieur.
• Autorisations — Preuve : règles effectives et tentatives permises ou bloquées. Action : démontrer qu’un chemin protégé reste inaccessible. Propriétaire : sécurité ou plateforme.
• Isolation — Preuve : branche, worktree, session et commit. Action : rechercher les chevauchements entre travaux parallèles. Propriétaire : responsable technique.
• Publication — Preuve : diff revu, risques ouverts, retour arrière et accord. Action : accepter, corriger ou refuser. Propriétaire : approbateur nommé.

Anthropic précise que des chemins contenant des parenthèses pouvaient entraîner l’abandon ou l’ignorance de règles Edit, Write ou Read par le bac à sable Bash, laissant potentiellement accessibles en écriture des dossiers prévus en lecture seule. Un motif non compilable, tel qu’un crochet non fermé, pouvait aussi faire échouer toutes les modifications. Après correction, une telle règle de refus protège le chemin littéral qu’elle décrit.

CreatikLab recommande un jeu de régression ciblé couvrant une lecture permise, une écriture permise, une écriture interdite, un chemin de test avec parenthèses et une règle volontairement incorrecte dans un environnement sans danger. Anthropic n’impose pas cette procédure. Pour chaque essai, consignez la règle, la commande, le résultat attendu et le résultat observé. N’exécutez pas d’opération destructive sur la production. La réussite ne vaut que pour les cas réellement testés.

1. Écrire le critère d’acceptation avant d’examiner la réponse de l’agent.
2. Capturer l’état du dépôt et tous les fichiers ajoutés, modifiés ou supprimés.
3. Consulter `/diff`, puis comparer son contenu au diff produit par le dépôt.
4. Écarter ou expliquer toute modification extérieure au périmètre autorisé.
5. Rechercher les secrets, identifiants, données personnelles et fichiers d’environnement.
6. Exécuter les tests automatisés adaptés puis vérifier manuellement le parcours concerné.
7. Tester les autorisations positives et négatives sur des ressources contrôlées.
8. Identifier la branche ou le worktree utilisé par chaque session parallèle.
9. Documenter les risques non résolus et les étapes de retour arrière.
10. Obtenir l’accord explicite d’une personne nommée avant la mise en production.

Cette liste est une pratique d’implémentation CreatikLab. Elle ne constitue pas une fonctionnalité revendiquée par Anthropic. Son intensité doit suivre l’impact possible de l’échec.

Le volume de code généré ne mesure pas la qualité. Pour chaque livraison, conservez le résultat demandé, les fichiers touchés, la décision de revue, les tests exécutés, le résultat des essais d’accès, les défauts découverts avant et après publication, ainsi que l’éventuel retour arrière. Des identifiants stables doivent relier tâche, session, worktree, commit, déploiement et approbateur.

Si l’application génère des prospects, mesurez séparément la valeur commerciale. Une définition de prospect qualifié peut s’appuyer sur des champs CRM convenus : coordonnées valides, besoin pertinent, marché accepté et validation commerciale. La recette technique vérifie formulaire, consentement, routage et mise à jour du statut. Le panneau de différences ne doit pas être crédité d’une hausse des prospects sans observation du parcours complet.

• Un diff visible ne détecte pas automatiquement une faille ou un besoin mal compris.
• Un correctif de l’outil ne répare pas une politique locale mal conçue.
• Une règle de refus n’est pas démontrée avant un test négatif réalisé sans danger.
• Un worktree séparé ne remplace pas la revue des dépendances et de la fusion.
• Une explication de défaut de cache ne renseigne pas sur la qualité du code.
• Une mise à niveau ne crée ni tests, ni rollback, ni approbation formelle.
• Les notes citées ne précisent ni prix, ni amélioration universelle des performances, ni certificat de conformité.

Le principal danger est la confiance excessive. Une mauvaise modification peut être parfaitement lisible. Seules des preuves indépendantes, une revue proportionnée et une responsabilité humaine permettent de l’accepter.

Pour comparer des prestataires, demandez un inventaire de configuration, un schéma des dépôts et worktrees, une matrice de risques, des tests de régression des autorisations, une répartition des responsabilités, des portes de publication, des instructions de restauration et un exemple de dossier d’acceptation. Le prestataire doit montrer comment il traite un changement hors périmètre et comment il reconstitue un incident.

Le service CreatikLab d’automatisation IA et de systèmes web sur mesure peut fournir un audit d’acceptation Claude Code, une suite de régression des autorisations et un processus de déploiement contrôlé adapté au dépôt. Si votre contexte comprend des agents parallèles, des règles sensibles ou une publication imminente, décrivez la situation à Lia et demandez une évaluation du système, des contraintes et des responsabilités réelles.

Claude Code 2.1.260 valide-t-il automatiquement le code ?

Non. Anthropic décrit un panneau affichant les changements non validés, pas un mécanisme d’approbation automatique pour la production.

Que montre le nouveau panneau de différences ?

Il affiche les modifications non validées à côté de la conversation en plein écran pendant que Claude édite. Anthropic indique qu’il se contrôle avec `/diff`.

Pourquoi refaire des tests d’autorisations après la mise à niveau ?

La version corrige des cas précis concernant les parenthèses, les motifs incorrects et le bac à sable. CreatikLab recommande des tests pour vérifier votre configuration, mais Anthropic n’impose pas de procédure particulière.

Le panneau peut-il remplacer une revue Git ?

Non. CreatikLab recommande de le comparer au statut et au diff natifs du dépôt afin de conserver une preuve indépendante.

Comment mesurer la qualité d’une livraison assistée par IA ?

Suivez les tests, décisions de revue, contrôles d’accès, défauts avant et après publication, retours arrière et liens entre tâche, session, worktree, commit et approbateur.

Quels livrables attendre d’un spécialiste Claude Code ?

Un inventaire de configuration, des tests d’autorisations, des règles d’isolation, des responsabilités, des portes de publication, un rollback et un dossier d’acceptation vérifiable.