Déployer : les hooks comme points d'approbation

Objectifs

À l’issue de cette leçon, vous serez capable de :

• Traduire les validations humaines obligatoires de votre processus en hooks qui autorisent, demandent ou bloquent
• Rendre les contrôles non négociables impossibles à désactiver grâce aux réglages gérés

Ce qui change

Les validations humaines — accord du comité de changement, autorisation de mise en production, modification de chemins protégés — ne disparaissent pas avec l’IA. Elles changent de forme : un hook est un script qui s’exécute avant que Claude n’agisse, et qui peut autoriser, demander (mettre l’action en pause jusqu’à la confirmation de la personne qui pilote la session) ou bloquer. Quand l’approbateur est quelqu’un d’autre, comme un responsable des mises en production, le hook vérifie que son approbation est enregistrée, et bloque tant qu’elle n’existe pas.

Les hooks ne sont pas propres au déploiement : ils s’exécutent partout où Claude agit. Ils peuvent bloquer pendant la construction la modification des migrations ou de l’infrastructure sans ticket de changement, ou empêcher l’agent de toucher aux tests pendant un correctif (leçon 8).

Pour démarrer

• Prérequis : aucun.
• Infrastructure : la liste écrite des approbations qu’exige le processus de changement.

Mise en œuvre

1. La direction de l’ingénierie, avec la gestion des changements et la conformité, liste les points de validation humaine qui doivent subsister.
2. L’ingénieur plateforme exprime chacun sous forme de hook PreToolUse, qui s’exécute avant l’action.
3. Les hooks d’équipe vont dans .claude/settings.json, versionné ; les hooks non négociables vont dans les réglages gérés (managed settings) de l’organisation, détenus par l’équipe plateforme ou l’informatique, que les ingénieurs ne peuvent pas désactiver.
4. Un blocage s’explique : quand un hook arrête une action, la raison et le chemin vers l’approbation apparaissent dans la sortie de Claude.

Exemple : une mise en production à trois niveaux

Supposons que le déploiement soit exposé à Claude par des serveurs MCP, un par environnement, offrant chacun un outil release (leçon 12). Un hook PreToolUse dont le filtre cible ces outils renvoie sa décision au format JSON prévu par Claude Code :

#!/bin/bash
# .claude/hooks/porte-mise-en-production.sh — dev : autoriser ; préproduction : demander ; production : ticket approuvé, sinon refuser.
entree=$(cat)
outil=$(jq -r '.tool_name' <<<"$entree")
ticket=$(jq -r '.tool_input.ticket // empty' <<<"$entree")

decider() {  # decider <allow|ask|deny> <raison>
  jq -n --arg d "$1" --arg r "$2" '{hookSpecificOutput: {hookEventName: "PreToolUse", permissionDecision: $d, permissionDecisionReason: $r}}'
  exit 0
}

case "$outil" in
  mcp__deploy-dev__release)     decider allow "Le développement ne demande pas d'approbation." ;;
  mcp__deploy-staging__release) decider ask "Mise en préproduction : approuvez seulement si vous êtes responsable de cette version." ;;
  mcp__deploy-prod__release)
    [[ "$ticket" =~ ^CHG-[0-9]+$ ]] && ticket_approuve "$ticket" && decider allow "Ticket $ticket approuvé."
    decider deny "La production exige un ticket de changement approuvé : ouvrez-en un, faites-le approuver par le responsable des mises en production, puis relancez avec son numéro." ;;
esac

ticket_approuve désigne l’outil de votre système de gestion des changements. Le contrôle suppose que l’agent n’a aucun moyen d’écrire dans les enregistrements qu’il lit. La raison d’un deny est montrée à Claude, qui peut transmettre le chemin vers l’approbation ; celle d’un ask est montrée à la personne.

Les réglages gérés d’une entreprise réglementée

Déployés par l’équipe plateforme (gestion des terminaux ou console d’administration), les réglages gérés s’imposent à tous. Quelques clés, documentées dans la référence des réglages de Claude Code :

• permissions.deny tient les secrets hors du contexte de l’agent et bloque les sorties réseau par les outils ; permissions.allow pré-autorise la boucle de travail sûre, pour éviter la fatigue des confirmations ;
• permissions.disableBypassPermissionsMode empêche quiconque d’entrer dans le mode qui contourne les permissions, et allowManagedPermissionRulesOnly interdit aux fichiers de projet ou d’utilisateur d’élargir les règles ;
• le bac à sable (sandbox) isole au niveau du système d’exploitation, y compris le réseau, ce que les permissions d’outils ne couvrent pas : un refus de WebFetch n’empêche pas une commande shell de joindre Internet ; failIfUnavailable empêche Claude Code de démarrer si le bac à sable ne peut pas s’initialiser ;
• allowManagedHooksOnly n’exécute que les hooks définis dans les réglages gérés : pour qu’une porte d’approbation reste en vigueur sous ce réglage, elle doit elle-même y être définie ;
• allowManagedMcpServersOnly réserve aux réglages gérés la liste des serveurs MCP autorisés.

Gouvernance et mesure

Les hooks sont les points d’approbation : la condition est appliquée à chaque fois, pour tout le monde, et chaque décision est tracée avec son horodatage. La porte définit aussi ce qui vaut approbation : un ticket approuvé, ou l’accord du responsable des mises en production.

• Indicateur avancé : la part des actions protégées qui passent par un hook, et le délai d’obtention d’une approbation.
• Indicateur retardé : les changements arrivés en production sans l’approbation requise, qui doivent être nuls.

À vous de jouer

Cartographier vos portes. Listez les validations humaines de votre processus de changement. Pour chacune, décidez où elle vit : un hook d’équipe dans .claude/settings.json, un hook non négociable dans les réglages gérés, ou une validation qui reste hors de l’agent. Dans un dépôt de test, écrivez un hook PreToolUse qui renvoie allow, ask ou deny selon l’outil, et vérifiez que chaque refus explique le chemin vers l’approbation.

Sources officielles : Hooks as approval gates (Claude Academy) · The AI-native SDLC playbook — Stage 5: Deploy · Hooks reference · Settings reference · Sandboxing · Managed MCP

Points clés à retenir

• Un hook PreToolUse autorise, demande ou bloque avant que Claude n’agisse, et explique ses refus
• Les validations humaines obligatoires deviennent des hooks ; les non négociables vivent dans les réglages gérés
• Le bac à sable complète les permissions au niveau du système, réseau compris
• La porte définit ce qui vaut approbation, et trace chaque décision