Recette d’un workflow Claude Code : critères et livrables

La recette d’un workflow Claude Code ne doit pas se limiter à constater qu’une tâche aboutit. L’équipe cliente doit pouvoir vérifier le périmètre accessible, les actions qui déclenchent une décision humaine, le modèle réellement employé par chaque sous-agent, les traces laissées par l’exécution et la personne responsable de chaque dérogation. La décision de réception concerne un dépôt, un runtime, une configuration, des identités et des outils précisément identifiés.

Le changelog d’Anthropic décrit des mécanismes pertinents pour cette recette : une règle du mode automatique concernant l’évasion du confinement, un avertissement avant la première lecture hors des répertoires de travail, un réglage qui bloque ces lectures et une variable permettant d’imposer un modèle aux sous-agents. Ces éléments sont des faits officiels. Le protocole de recette proposé ici relève de l’interprétation opérationnelle de CreatikLab et ne constitue pas une garantie d’Anthropic.

La documentation officielle indique que la règle de mode automatique traite des comportements liés aux identifiants issus des métadonnées cloud, au contournement de la sortie réseau et au passage entre tenants. Ils ne sont pas approuvés automatiquement, sauf lorsque l’environnement les considère comme attendus. Anthropic mentionne aussi une décision ponctuelle avant la première lecture hors des répertoires de travail et le paramètre `permissions.blockReadsOutsideWorkingDirectories` pour refuser ces lectures.

La variable `CLAUDE_CODE_SUBAGENT_MODEL_FORCE` est présentée comme un moyen d’appliquer aux sous-agents le modèle configuré par `CLAUDE_CODE_SUBAGENT_MODEL`, ou le modèle principal, malgré une autre sélection au lancement ou dans leur définition. Avec `CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY`, une passerelle peut fournir une description aux modèles découverts. Le changelog ne démontre ni la sûreté globale, ni le coût, ni la rapidité, ni la qualité d’un workflow particulier.

Le dossier commence par une fiche de contexte : finalité métier, dépôt concerné, environnement d’exécution, propriétaire, identités disponibles et chemin éventuel vers la mise en production. Vient ensuite une cartographie des ressources. Répertoires, variables d’environnement, registres de paquets, secrets CI, comptes cloud, bases, sockets, navigateurs authentifiés et serveurs d’outils sont classés comme nécessaires, interdits ou soumis à validation.

Une seconde carte décrit les acteurs et leur autorité : session principale, sous-agents, passerelle, outils externes, identité Git, relecteur et responsable de publication. Pour chaque contrôle, le prestataire indique le point d’application et la preuve observable. Une règle présente dans Claude Code ne doit pas être présumée active dans une passerelle, un serveur d’outils, un pipeline CI ou un système de déploiement.

Chaque scénario de recette doit posséder un oracle, c’est-à-dire un résultat attendu suffisamment précis pour trancher. Un cas autorisé décrit l’action, la ressource exacte et la trace attendue. Un cas interdit prévoit le refus et l’absence d’effet secondaire. Un cas soumis à validation précise l’approbateur, les informations affichées et le comportement après acceptation ou refus. Les résultats sont écrits avant l’essai afin d’éviter une interprétation favorable après coup.

• Lecture externe — Fichier bénin hors périmètre, avertissement ou blocage attendu, puis vérification indépendante de l’activité.
• Confinement — Simulation non dangereuse en laboratoire isolé, sans identifiant réel ni ressource appartenant à un tiers.
• Sous-agent — Mission représentative, modèle effectif attendu, inventaire des outils et résultat associé.
• Passerelle — Concordance entre entrée visible, identifiant stable et registre d’administration.
• Modification — Instruction, commandes, diff, tests et avis du relecteur regroupés dans le même dossier.
• Publication — Séparation démontrée entre production d’un artefact et autorité de le déployer.

1. Archiver la version installée et les fichiers de configuration examinés.
2. Utiliser un dépôt jetable et des identifiants synthétiques sans accès à la production.
3. Vérifier que l’inventaire des ressources correspond à ce que le processus peut réellement atteindre.
4. Lancer le scénario de lecture externe et collecter simultanément trace de session et observation système.
5. Répéter le scénario avec le réglage de blocage prévu par la politique de recette.
6. Tester les situations de confinement uniquement par simulation sûre dans un laboratoire isolé.
7. Créer plusieurs missions représentatives de sous-agents et relever leurs modèles effectifs.
8. Exporter les entrées de passerelle si la découverte de modèles fait partie de l’intégration.
9. Produire un changement contrôlé, exécuter les tests convenus et obtenir un avis humain traçable.
10. Effectuer un retour arrière sur un artefact réversible et vérifier l’état final.
11. Ouvrir une fiche d’écart pour tout résultat incomplet, inattendu ou impossible à observer.
12. Faire prononcer la décision par les responsables technique, sécurité et métier désignés.

Les preuves brutes accompagnent le procès-verbal, sous une forme qui respecte les règles de confidentialité. Il n’est pas nécessaire de recopier des secrets pour prouver un refus. En revanche, une simple capture de synthèse ne remplace pas les éléments permettant à l’équipe cliente de comprendre et de répéter le test.

Un écart bloquant concerne notamment une identité trop puissante, une lecture inexpliquée, un outil capable de contourner le périmètre, un modèle effectif non identifiable, une mise en production sans approbateur ou un rollback non démontré. La réception doit alors être refusée. Un écart majeur peut conduire à une réception conditionnelle si le périmètre est immédiatement réduit à la lecture seule, aux données synthétiques ou à une infrastructure jetable.

La réception sans réserve exige que les ressources soient cartographiées, que les cas interdits échouent comme prévu, que les validations arrêtent réellement l’exécution, que les modèles soient observables et que le dossier d’un changement soit complet. Cette décision n’est pas une certification générale de Claude Code. Elle porte uniquement sur la conception et la configuration examinées.

Pour chaque exécution gouvernée, le journal de pilotage devrait contenir l’identifiant du workflow, le dépôt, la référence de configuration, le modèle principal effectif, les modèles des sous-agents, les outils appelés, les tentatives de lecture externe, les autorisations, les refus, les fichiers modifiés, les tests et le relecteur. Lorsqu’une passerelle intervient, son entrée stable est conservée en plus du libellé affiché. Chaque exception renvoie à son décideur.

Les indicateurs portent d’abord sur la maîtrise : dossiers complets, actions interdites refusées, validations correctement attribuées, changements conformes aux tests, demandes de reprise des relecteurs, divergences de modèle non résolues et exercices de rollback. Chaque ratio doit préciser son périmètre de calcul. L’utilité peut être comparée au processus existant sur des tâches équivalentes, sans transformer cette observation en promesse de performance, de sécurité ou d’économie.

• Ne pas supposer qu’un avertissement unique couvre toutes les routes, commandes ou lectures indirectes.
• Ne pas confondre blocage de fichiers, filtrage réseau, contrôle des outils et protection des secrets de déploiement.
• Ne pas élargir une exception de confinement au-delà du besoin documenté.
• Ne pas déduire le modèle effectif d’un sous-agent de son seul fichier de définition.
• Ne pas utiliser une description de passerelle comme preuve d’identité, d’approbation de sécurité, de prix ou d’éligibilité.
• Ne pas extrapoler un essai local à un pipeline CI, une session distante ou un autre jeu d’identités.
• Ne pas remplacer protection des branches, isolation des secrets, tests, revue et rollback par le mode automatique.
• Ne pas conserver une ancienne réception après ajout de ressources, d’outils, de modèles ou d’autorité.
• Ne pas promettre de disponibilité, de qualité, de gain ou de sécurité que le changelog n’établit pas.

Le principal risque de long terme est la dérive du périmètre. Une intégration limitée accumule des dossiers, identités et outils tandis que son procès-verbal initial reste inchangé. Le plan d’exploitation doit donc définir les événements qui rouvrent la recette : nouvelle intégration, évolution du routage des modèles, extension des accès ou modification du chemin de publication.

Pour une équipe de développement, le service d’automatisation par IA de CreatikLab peut produire la cartographie des actifs et identifiants, la politique de contrôle versionnée, le banc de recette isolé, les preuves de lecture externe, la vérification des modèles de sous-agents, l’inventaire de passerelle, le modèle de journalisation, le registre des écarts, le circuit de validation, le tableau de mesure et l’essai de rollback. Ces livrables sont directement inspectables par l’ingénierie, la sécurité et les achats.

Lorsque le périmètre reste à clarifier, le relais explicite se fait vers Lia. Il convient de transmettre le type de dépôt, le runtime, les outils reliés, les catégories d’identités, le chemin de déploiement et les validations humaines recherchées. Lia peut orienter ces informations vers un diagnostic cadré. CreatikLab ne garantit ni sûreté, ni économie, ni vitesse, ni qualité du code ; la prestation fournit une conception testable et une décision de recette fondée sur des preuves.

Quel est l’objet de la recette ?

La recette porte sur un périmètre d’exploitation identifié : ressources accessibles, actes interdits, validations humaines, modèles effectifs, preuves, responsabilités et procédure de retour arrière.

Quels éléments sont officiellement documentés par Anthropic ?

Le changelog mentionne une règle visant certains scénarios d’évasion du confinement en mode automatique, un avertissement avant la première lecture externe, un réglage de blocage et une variable qui impose la sélection de modèle aux sous-agents.

Une recette positive constitue-t-elle une certification de sécurité ?

Non. Elle montre seulement qu’une configuration nommée a satisfait des scénarios convenus dans un environnement défini. Une autre version, identité, intégration ou arborescence doit être réévaluée.

Quelle preuve conserver pour une lecture hors répertoire ?

Conservez la demande, le point de décision affiché, la réponse de l’opérateur et une observation indépendante du système de fichiers. Effectuez l’essai dans un environnement jetable, puis avec le blocage activé.

Comment contrôler les sous-agents ?

Lancez des cas représentatifs et consignez pour chacun la mission, le modèle effectif, les outils appelés et le résultat. La seule lecture du fichier de définition ne suffit pas.

Quels documents demander au prestataire ?

Demandez la cartographie des accès, la politique versionnée, le banc de test, le procès-verbal de recette, les inventaires de modèles et passerelles, le registre des écarts, les validations et l’essai de rollback.