Claude Code en production : la checklist « à blanc » avant de déployer

Un vendredi en fin d’après-midi, j’ai demandé à Claude Code : « Cette correction d’article, mets-la en prod ». La réponse a tenu en deux mots, « C’est publié », avec une jolie coche verte. Rassuré, je suis rentré chez moi. Le lendemain matin, la page d’accueil du site était entièrement blanche.

La cause était bête. Personne n’avait ouvert la preview. Claude Code avait seulement regardé les logs de build qui passaient et conclu au « succès ». Mais la vraie page chargeait le template d’un autre article et son contenu était vide. Comme le serveur renvoyait un code HTTP 200, mécaniquement, ça ressemblait à une « publication réussie ».

Ce jour-là, j’ai compris une chose : la vitesse et la sécurité sont deux choses différentes. Quand on délègue le déploiement en bloc, tout semble se terminer en un instant. Mais si rien ne dit ce qui a été vérifié, le jour où ça tombe, on ne sait plus quoi remettre en place. Aujourd’hui, je décris la parade : avant de donner les accès production, monter un « tir à blanc » (dry run) pour réunir les preuves.

Points clés

La plupart des accidents quand on confie le déploiement à Claude Code viennent d’une vérification sautée avant de toucher la production.
Avant de donner l’accès production, on contrôle à blanc cinq points : build, diff, preview URL, responsable du rollback et zones non touchées.
Séparer « ce qu’une machine peut juger » de « ce qu’un humain doit voir de ses yeux » réduit les incidents de minuit.
Vous trouverez plus bas un modèle de prompt à copier-coller et un bout de code qui vérifie mécaniquement le résultat.
Pas besoin d’une procédure parfaite dès le départ. On teste sur une seule correction, et on ajoute à la checklist chaque endroit où l’on est tombé.

Un accident de déploiement vient d’un manque de vérification, pas d’un manque d’intelligence

Claude Code est intelligent. Mais être intelligent et savoir fonctionner sans danger en production sont deux choses distinctes.

C’est comme l’élève qui décroche un 20/20 aux examens et casse la caisse enregistreuse le premier jour de son job d’été : ce n’est pas une question de capacité, c’est une question d’échafaudage. Pour un déploiement, l’échafaudage, c’est « ce qu’on vérifie avant de toucher la production ».

Le déploiement d’un site statique échoue particulièrement en silence. Le build passe, le HTTP renvoie 200, et visuellement tout a l’air d’aller. Même si le contenu est vide, même si une autre page a pris la place, en ne regardant que le code de statut on ne s’aperçoit de rien. Il faut donc qu’un humain regarde une fois, non pas « est-ce que le code a tourné ? », mais « est-ce que la bonne page sort correctement ? ».

Les cinq étapes du tir à blanc avant de toucher la production

La procédure que j’utilise aujourd’hui tient en ceci. L’ordre compte, je les liste donc du haut vers le bas.

D’abord, faire passer le build en local. Si ça casse ici, inutile de parler production. On distingue, avant de toucher la prod, un problème de code d’un problème d’environnement.
Lire le diff. On vérifie de ses yeux qu’aucune information sensible (clés d’API, jetons) ni aucun changement lié à la facturation ne s’est glissé.
Ouvrir la preview URL. On contrôle sur l’écran réel que le titre (h1), l’URL canonique (canonical) et la destination du bouton d’inscription sont bien ceux attendus.
Désigner le responsable du rollback et la méthode de retour. En cas d’échec, qui revient à l’état précédent, et avec quelle commande. Sans l’avoir décidé à l’avance, on se fige à l’instant de l’accident.
Demander l’accès production une fois les preuves réunies. C’est seulement quand les résultats des points 1 à 4 sont là qu’on demande à Claude Code de déployer en production.

Rien qu’en respectant cet ordre, l’accident de la « page d’accueil blanche » du début ne se produit quasiment plus. Pourquoi ? Parce qu’à l’étape 3, on ouvre toujours la preview.

Ce qu’on délègue à l’IA, et ce que l’humain décide

On ne confie pas tout à l’IA, et on ne repasse pas non plus tout en manuel. On répartit les rôles. Le tableau ci-dessous, c’est ma ligne de partage sur le terrain.

Situation	Ce qu’on confie à Claude Code	La preuve que l’humain regarde
Publication d’un article	Lancer d’abord le build de `dist` et le contrôle auto de l’URL publique	Résultat du build, diff, URL
Changement d’un bouton d’inscription	Confronter en preview la destination du lien et le parcours de contact	Résultat du build, diff, URL
Correction d’un Worker	Ne pas toucher aux variables d’environnement, sortir seulement les logs du dry run	Résultat du build, diff, URL

L’idée est ce partage : on confie à l’IA les tâches de lecture, de mise en ordre et de vérification mécanique, et l’humain approuve les opérations qui apportent un changement irréversible en production. Les suppressions, l’écriture dans la base de données de production, la facturation, le force push : au début, on les bascule tous sur « demander à l’humain ». On ne promeut en automatique, plus tard, que les opérations dont on a vérifié qu’elles sont sûres.

Pour ceux qui veulent affiner cette ligne de partage des permissions, le guide de configuration des permissions de Claude Code et l’audit des permissions avant déploiement sont de bonnes références.

Un modèle de prompt à copier-coller

L’astuce, c’est de ne pas tout déléguer en vrac, mais d’écrire noir sur blanc « ne mets pas encore en production ». Le modèle suivant se colle tel quel.

Transforme ce changement en « checklist de tir à blanc » avant le déploiement en production.
Renvoie les éléments suivants sous forme de tableau :
- Résultat du build (succès / échec et points clés des logs)
- Risque du diff (présence d'informations sensibles, de facturation ou de suppression)
- Preview URL
- Responsable du rollback et commande de rollback
- Zones non touchées
- Conditions de relance
N'exécute pas encore le déploiement en production. Attends que j'aie vérifié la checklist.

Ce sont les deux dernières lignes qui font tout l’effet. En écrivant « n’exécute pas encore » et « attends que j’aie vérifié », on évite que Claude Code ne « rende service » en publiant de lui-même. Cette manière d’écrire les prompts pour pencher du côté sûr est aussi détaillée dans la conception de prompts pour utilisateurs avancés.

Un script de vérification qui tourne directement

Quand on juge le résultat des contrôles par une machine plutôt que par « l’intuition humaine », on rate moins de choses. Le script suivant reçoit l’objet du résultat de tir à blanc et renvoie un booléen indiquant si l’on peut demander l’accès production. Avec Node.js, il tourne tel quel.

// Résultat du tir à blanc. On y met le contenu réel des vérifications.
const deployCheck = {
  build: "passed",              // le build local est-il passé
  diffReviewed: true,           // le diff a-t-il été relu à l'œil
  previewUrl: "https://example.pages.dev", // preview URL
  rollbackOwner: "Masa",        // responsable du rollback
  changedAreas: ["content", "cta-copy"],   // zones touchées
};

// Le gardien qui décide si l'on peut demander l'accès production
function canRequestProductionAccess(check) {
  return (
    check.build === "passed" &&          // le build passe
    check.diffReviewed &&                // le diff a été relu
    /^https:\/\//.test(check.previewUrl) && // la preview URL existe en https
    check.rollbackOwner.length > 0 &&    // le responsable du rollback est désigné
    !check.changedAreas.includes("secrets") // aucune zone sensible touchée
  );
}

const ready = canRequestProductionAccess(deployCheck);
console.log({ ready });
// Tant que les éléments « false » ne sont pas comblés, on ne demande pas le déploiement.

La valeur de ce code, c’est qu’il renvoie false à l’instant où "secrets" apparaît dans changedAreas. Quand on a touché par mégarde à des informations sensibles, jamais on n’avance jusqu’à la demande d’accès production. Même si l’humain, débordé, passe à côté, le gardien arrête le mouvement.

Trois situations où ça a vraiment payé

La première, c’est la publication d’un article. Avec un simple « publie le blog », dès que le build passe, ça file jusqu’à la publication. En glissant un tir à blanc, on ouvre d’abord l’URL publique pour vérifier que le titre et le contenu correspondent : l’accident de la page blanche du début s’arrête là.

La deuxième, c’est le remplacement d’un bouton d’inscription. Une seule faute de frappe dans la destination du lien, et tout le parcours soigneusement construit tombe sur un 404. Depuis que j’ai ajouté l’étape « appuyer réellement sur le bouton en preview pour vérifier la destination », les liens cassés sont à zéro.

La troisième, c’est la correction d’un Cloudflare Worker. Ici, supprimer une seule variable d’environnement suffit à faire tomber la prod. Au tir à blanc, on ne laisse donc pas toucher aux variables d’environnement : on se contente de sortir les logs. Les points d’attention propres aux Workers sont rassemblés dans l’article sur l’intégration de Cloudflare Workers.

Pièges fréquents et comment les corriger

Trois échecs que j’ai réellement commis, et leur correctif.

Piège 1 : lancer la commande de production avant le build. Si l’on déclenche wrangler deploy d’emblée, en cas d’échec on ne sait pas distinguer si c’est le code ou l’environnement qui est en cause. Le correctif est simple : toujours faire passer le build local en premier. Changer une seule chose dans l’ordre accélère énormément la recherche de la cause.

Piège 2 : ne pas avoir désigné de responsable du rollback. Si l’on commence à se demander « qui revient en arrière ? » seulement après l’échec, ces quelques minutes touchent les visiteurs de plein fouet. Le correctif : dès l’étape du tir à blanc, écrire noir sur blanc le responsable et la commande de rollback. Rien que noter le previousDeployId rend la reprise plus sereine.

Piège 3 : croire le code de statut sans ouvrir la preview. Un HTTP 200 dit seulement « le serveur a renvoyé quelque chose », pas « la bonne page est sortie ». Le correctif : ouvrir obligatoirement la preview URL une fois dans le navigateur et regarder de ses yeux le titre, l’URL canonique et l’image hero. C’était le seul moyen de débusquer la page blanche du début.

Garder les preuves comme une « note réutilisable la prochaine fois »

Ce que vous avez vérifié au tir à blanc, ne l’effacez pas sur le moment : résumez-le dans une note courte, et le travail suivant ira nettement plus vite.

Voici ce qu’il suffit de garder : la demande initiale, la portée que Claude Code a lue, les zones non touchées, les commandes de vérification exécutées, l’URL publique ou les captures d’écran, et les points où la décision a hésité. Pas besoin d’un long procès-verbal. Si l’on peut retracer après coup « pourquoi cette décision », l’objectif est atteint.

Ce qui marche le mieux, c’est d’écrire le « point de bascule » en une ligne. Par exemple : « la preview URL est bonne, mais le responsable du rollback n’est pas défini, donc pas encore de prod ». La prochaine fois qu’on refait le même travail, soi-même ou quelqu’un d’autre peut reproduire exactement la même vérification. Le même raisonnement s’applique à d’autres automatisations que le déploiement ; lu avec l’introduction à Claude Code pour les non-développeurs, je pense que vous saisirez mieux l’art de déléguer.

FAQ

Q. Le tir à blanc, au fond, ce n’est pas juste plus de boulot ? Au début, ça donne cette impression. Mais qu’un accident survienne une seule fois, et la reprise plus la recherche de la cause font fondre des heures. Le tir à blanc, c’est quelques minutes. Je le maintiens comme une assurance rentable.

Q. Si le build local passe, je peux ne pas regarder la preview ? Non. Même quand le build passe, des substitutions de template et des pages vides arrivent. HTTP 200 et « la bonne page » sont deux choses différentes, le coup d’œil ne se saute pas.

Q. Désigner un responsable du rollback a-t-il un sens même quand je suis seul ? Oui. Même seul, écrire à l’avance « en cas d’échec, je reviens avec cette commande » évite l’hésitation le jour de l’accident. Décider, c’est déjà la procédure.

Q. Quand Claude Code dit « C’est publié », puis-je le croire ? Regardez les preuves du tir à blanc plutôt que la réponse elle-même. On juge sur la présence du build, du diff, de la preview et du responsable du rollback. Les mots, c’est l’ambiance ; les preuves, ce sont les faits.

Q. Même pour un petit site, faut-il aller jusque-là ? Raisonnez sur « peut-on revenir en arrière » plutôt que sur la taille. Même petit, une prod qui tombe pose problème. Commencez par insérer ne serait-ce que l’unique étape « ouvrir la preview » : vous en sentirez vite l’effet.

Ce que ça a donné en conditions réelles

Après l’accident de la page blanche du début, j’ai intégré cette procédure de tir à blanc à l’exploitation de mon propre blog.

J’ai vérifié trois choses. Un : depuis que j’ai imposé la règle d’ouvrir systématiquement la preview URL, les pages vides dues à une substitution de template sont tombées à zéro. Deux : depuis que je lance le script de vérification ci-dessus avant chaque publication, un changement qui touche une zone sensible s’arrête sur ready: false et n’avance plus jusqu’à la demande d’accès production. Trois : depuis que je note à chaque fois le responsable et la commande de rollback, même dans les moments où j’ai eu chaud, je reviens à l’état précédent en quelques minutes.

Plutôt que de tout confier à une IA intelligente et de prier, construire d’abord un échafaudage où l’on ne se blesse pas en tombant. Ça paraît être un détour, mais c’est finalement le plus rapide : voilà mon ressenti d’aujourd’hui. Commencez par la seule étape « ouvrir la preview » et ajoutez un gardien à vos propres déploiements.

Si vous voulez, au niveau d’une équipe, formaliser la ligne de partage du déploiement en production et le dispositif de revue, on peut transformer ça ensemble en procédure lors d’une formation ou d’une session de conseil. Pour les standards officiels d’exploitation, référez-vous aussi à la documentation officielle de Claude Code d’Anthropic.