Le registre de risques à créer avant de déployer Claude Code en équipe

Un vendredi en fin d’après-midi, un collègue a lancé : « Claude Code est tellement pratique, on devrait tous l’utiliser à partir de lundi. »

J’ai eu un mauvais pressentiment. Quand il s’en servait seul, il relisait sa propre branche, la fusionnait lui-même, et si ça cassait, lui seul en subissait les conséquences. Mais en équipe, l’histoire change. Avec quelle autorisation, jusqu’où peut-on le laisser toucher, et qui valide les changements ? Si six personnes commencent à l’utiliser sans avoir répondu à ces questions, vous vous retrouverez avec une modification qui efface la base de production fusionnée sans que personne ne s’en aperçoive. Ça arrive plus souvent qu’on ne le croit.

Je l’ai vécu dans une autre équipe. Trois personnes faisaient tourner Claude Code chacune avec sa propre configuration. L’une d’elles a demandé « range-moi tout ça proprement », le fichier de configuration partagé a été réécrit, et le lundi matin tous les déploiements ont planté. Une demi-journée pour trouver la cause. Personne n’avait de mauvaise intention. Il manquait juste une chose : des règles pour déléguer en équipe.

C’est de là qu’est né le registre de risques que je présente dans cet article. On dit « registre », mais ce n’est qu’un simple tableau. Pourtant, sa présence ou son absence décide si l’adoption de Claude Code en équipe se termine par « c’est devenu plus facile » ou par « on s’est épuisés à gérer les dégâts ».

Points clés

• Les accidents de déploiement en équipe ne viennent pas de l’intelligence du modèle, mais du fait que « qui, jusqu’où, et validé par qui » n’a pas été défini.
• Le registre de risques est un tableau où chaque zone dangereuse tient en une ligne : « responsable, méthode de vérification, condition pour avancer ». Trois lignes suffisent au début.
• Fixez d’abord trois choses : les permissions (quels fichiers laisser modifier), la CI (la preuve que rien n’est cassé) et la publication (la vérification de la mise en production).
• Ce que vous déléguez à Claude Code s’arrête à « rédiger le brouillon et lancer la vérification ». Suppression, base de production, facturation et force push doivent toujours être approuvés par un humain.
• Je fournis un modèle de registre prêt à copier et un exemple de configuration qui bloque les opérations dangereuses. L’astuce : commencez par un seul fichier.

Le registre de risques, c’est quoi au juste ?

Le registre de risques est un tableau qui liste les « endroits où ça casse facilement » quand vous confiez du travail à Claude Code en équipe.

Chaque ligne se contente de trois colonnes. Où est le danger, quelle est la preuve que c’est sûr, et qui fait cette vérification. C’est tout. Pas besoin d’un outil de gestion compliqué. Au départ, une seule feuille de calcul, voire un tableau directement dans le code, suffit largement.

Pourquoi en faire un tableau ? Parce que « rester vaguement vigilant » est ce qu’il y a de plus dangereux. Quand on est débordé, on saute toujours une vérification. En l’écrivant noir sur blanc et en décidant « on ne fusionne pas tant que cette ligne n’est pas remplie », on stoppe les accidents même un vendredi soir surchargé. L’accident de déploiement raconté plus haut aurait été évité simplement en écrivant une ligne : le fichier de configuration partagé est une « zone à ne pas toucher ».

Les trois points dangereux à fixer en premier

Là où les équipes trébuchent, ça se résume presque toujours à ces trois points. Autrement dit, si vous les inscrivez dans le registre, vous évitez quasiment tout gros accident du premier jour.

1. Permissions (quels fichiers laisser modifier)

L’accident le plus fréquent, c’est « on lui en laisse trop ». Quand vous demandez « range le dépôt », Claude Code réécrit sans hésiter les fichiers de configuration et même la définition de la CI. Décidez donc à l’avance où il a le droit d’éditer et où il ne doit absolument pas toucher, et mettez-le par écrit.

Mon critère est simple. Articles, brouillons, code de test : modification autorisée. Le dossier .github/, les variables d’environnement de production, la configuration de déploiement, les migrations de base de données : « on bloque jusqu’à validation humaine ». Si vous laissez chacun tracer cette ligne selon ses préférences, les règles divergent d’une personne à l’autre, et c’est finalement la configuration la plus permissive qui provoque l’accident. Le point crucial, c’est d’unifier l’équipe sur une seule règle.

2. CI (faire produire la preuve que rien n’est cassé)

Quand Claude Code dit « c’est corrigé », c’est une impression, pas une preuve. Inscrivez donc dans le registre la commande qui prouve que le changement ne casse rien. Le build passe, les tests sont au vert, aucune erreur de type. Décidez que l’une de ces preuves « doit obligatoirement être exécutée avant tout rapport de succès ».

Le point important ici : gardez la commande de vérification rapide. Si la suite complète prend dix minutes, plus personne ne la lancera. En permettant de ne lancer que les tests liés aux fichiers modifiés en trente secondes, la vérification devient une habitude.

3. Publication (toujours regarder ce qui part en production)

Page de revenus d’un blog ou API, tout changement qui sort à l’extérieur doit laisser une trace : « l’a-t-on vu sur la vraie URL ? ». Que le build passe et que la page réellement vue par l’utilisateur soit correcte sont deux choses distinctes. Ouvrez l’URL de production et gardez une capture d’écran. Faites-en la condition de clôture.

Même si l’URL publique renvoie un 200, si le contenu est une autre page, c’est comme si rien n’était publié. Si une page en français contient du texte en anglais mêlé, c’est inachevé aussi. Ça paraît évident, mais c’est justement les jours pressés qu’on saute cette étape.

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

Si vous hésitez sur la ligne à tracer, reprenez ce tableau tel quel. Le critère, c’est « est-ce réversible ? ».

Opération	Délégué à Claude Code	Exécuté après approbation humaine
Création / correction de brouillons	◯
Exécution des tests / du build	◯
Explication des changements (résumé du diff)	◯
Suppression de fichiers		◯
Écriture dans la base de production		◯
Opérations qui génèrent de la facturation		◯
Force push / réécriture de l’historique		◯
Déploiement / mise en production		◯

Une seule règle. Toute opération difficile à annuler passe d’abord par « demander à un humain ». Seules les opérations dont vous avez la certitude qu’elles sont sûres seront ensuite promues en automatique. Plutôt que de partir trop souple et d’avoir un accident, mieux vaut serrer puis desserrer petit à petit : au final, c’est plus rapide.

Modèle de registre de risques prêt à copier

Avant même la demande, transformez en gabarit les instructions que vous donnez à Claude Code. Il suffit de le coller à chaque fois pour empêcher tout débordement.

Avant de travailler, respecte ce qui suit.
- Tu ne peux modifier que ce qui est dans src/content/ et tests/.
- Ne touche pas à .github/, aux variables d'environnement de production, à la configuration de déploiement ni aux migrations de base de données. Si c'est nécessaire, ne modifie rien et explique pourquoi.
- Après chaque changement, exécute systématiquement `npm run check` et rapporte le résultat.
- Si une suppression, une écriture en base de production, une facturation ou un force push devient nécessaire, ne l'exécute pas et demande validation.
Avant de commencer, reformule les contraintes ci-dessus avec tes propres mots.

Puis le registre lui-même. Trois lignes suffisent au début. Remplacez par les points dangereux de votre propre équipe.

// Registre de risques de déploiement en équipe : une ligne par zone dangereuse avec « responsable, preuve, condition pour avancer »
type RolloutRisk = {
  area: string;       // Zone dangereuse
  risk: string;       // Ce qui peut arriver
  owner: string;      // Responsable de la vérification
  proof: string;      // Preuve qu'on peut dire « c'est sûr »
  nextGate: string;   // Condition pour pouvoir avancer
};

const rolloutRisks: RolloutRisk[] = [
  {
    area: "Permissions",
    risk: "Claude Code réécrit jusqu'à la configuration partagée",
    owner: "Lead",
    proof: "La liste autorisé / interdit est documentée",
    nextGate: "Tester d'abord sur un seul fichier",
  },
  {
    area: "CI",
    risk: "La commande de vérification est lente ou inexistante",
    owner: "Développeur",
    proof: "Build au vert, ou tests liés au vert seulement",
    nextGate: "Ajouter la procédure de vérification au modèle de PR",
  },
  {
    area: "Publication",
    risk: "Le changement en production n'a pas été vu en vrai",
    owner: "Ops",
    proof: "Capture d'écran de l'URL publique",
    nextGate: "Noter la procédure de rollback",
  },
];

console.table(rolloutRisks);

Enregistrez-le pour qu’il tourne avec node, exécutez-le, et le tableau s’affiche. Ce n’est pas spectaculaire, mais sa valeur réside dans le fait de « mettre des mots sur les points dangereux avant de commencer le travail ». En décidant « on ne fusionne pas tant que chaque ligne n’est pas remplie », le registre devient le gardien contre les accidents.

Pour quelles équipes ça marche (trois cas réels)

Si une situation vous ressemble, ne refaites pas le registre : changez juste les noms et réutilisez-le.

1. Une petite équipe de deux personnes Avant de toucher au code partagé, lisez ensemble à voix haute, sur une seule page, les endroits modifiables, ceux à ne pas toucher et les opérations qui nécessitent validation humaine. Rien que ça fait disparaître l’accident « l’un casse la config sans que l’autre le sache ». Plus l’équipe est petite, plus on a d’accidents par « ça va sans dire » : la valeur de l’écrire dès le début est grande.

2. Une équipe qui passe par la revue Le lead rend obligatoires, avant que le changement produit par Claude Code n’arrive en revue, « le résultat de l’exécution de la commande de vérification » et « le résumé des modifications ». Une PR sans cela, on ne la regarde pas. L’objectif est d’amener le relecteur à pouvoir lire le diff, relancer la vérification et expliquer comment revenir en arrière.

3. Une équipe avec des pages de revenus Pour les changements de pages directement liées à l’argent (blog, pages produit), gardez une capture de l’URL publique avant de considérer la tâche terminée. Ne vous arrêtez pas à « le build est passé » : vérifiez l’écran réellement vu par l’utilisateur. Regardez de vos yeux si titre, corps, image et parcours sont conformes à l’attendu.

Erreurs fréquentes et comment les corriger

Honnêtement, ce registre n’a pas bien tourné du premier coup non plus. Je partage trois ratés.

Chacun a inventé ses propres règles Au début, j’ai laissé la configuration à l’appréciation de chacun, et la zone modifiable a divergé d’une personne à l’autre. C’est celui qui a la config la plus permissive qui provoque l’accident. La correction est simple : unifier la liste autorisé / interdit en une seule pour toute l’équipe et la placer dans le dépôt.

On a repoussé les échecs de CI à plus tard Quand « on corrigera tout ensemble plus tard » devient un réflexe, le premier déploiement en équipe se termine sur la mauvaise impression « depuis qu’on a mis Claude Code, ça casse ». Si la commande de vérification échoue, on s’arrête sur-le-champ et on garde le travail en brouillon jusqu’à ce que ce soit au vert.

On a évité les décisions difficiles en laissant le responsable flou Sans avoir décidé « qui approuve », la décision la plus difficile — la mise en production — reste en suspens. Remplissez toujours la colonne owner du registre. Ne pas avancer avec une case vide. Rien que ça empêche les décisions de se bloquer.

Si vous sentez que le travail commence à s’étendre, ne réécrivez pas toute la consigne : resserrez dans cet ordre — réduire le périmètre accessible, sortir la vérification en premier, désigner un seul responsable de la validation. Garder une trace des échecs partagée dans l’équipe compte aussi. À ne regarder que les réussites, on ne remarque pas qu’on est soi-même entré dans une zone dangereuse.

FAQ

Q. Le registre est-il nécessaire même dans une petite équipe ? Même à deux, oui. C’est même dans les petits effectifs qu’on se persuade que « ça va sans dire » et qu’on a des accidents. Au début, un modèle de trois lignes suffit : créez-le en cinq minutes et partagez-le.

Q. Les permissions de Claude Code ne suffisent-elles pas ? Les permissions sont le « mécanisme qui empêche de toucher », le registre est la « règle de fonctionnement : qui vérifie quoi ». Il faut les deux. Bloquer techniquement via la configuration, faire tourner la vérification humaine via le registre. Pour les détails, voyez le guide des permissions.

Q. Quelle commande de vérification choisir ? La commande la plus courte qui permette à votre équipe de dire « rien n’est cassé ». Vérification de type, exécution des seuls tests liés, ou build. Si la suite complète prend dix minutes, personne ne la lancera : choisissez-en d’abord une qui se termine en trente secondes.

Q. Ça tourne même avec des membres qui ne sont pas ingénieurs ? Oui. Le registre, c’est juste un tableau à lire et à remplir, donc on peut le faire tourner sans savoir lire le code. Pour démarrer côté non-ingénieurs, le guide usage pour les non-ingénieurs est une bonne référence.

Q. Où écrire les règles propres au projet ? Écrivez-les dans le CLAUDE.md du dépôt : Claude Code le relit à chaque fois. En y centralisant les zones interdites à l’édition et les commandes de vérification, il est plus facile de les aligner avec le registre. La méthode est résumée dans bien rédiger CLAUDE.md. Consultez aussi la documentation officielle de Claude Code d’Anthropic comme source primaire.

Ce que j’ai vérifié en pratique

Après l’accident de déploiement raconté en ouverture, j’ai arrêté de me demander « est-ce que je fais confiance à Claude Code ». À la place, je regarde quelles lignes du registre ne sont pas remplies.

En introduisant concrètement un registre de trois lignes et en inscrivant noir sur blanc le fichier de configuration partagé comme « zone à ne pas toucher », les fusions qui cassaient la config sont tombées à zéro. En rendant la commande de vérification « obligatoire avant tout rapport de succès », on ne découvre plus les casses pour la première fois en revue, et les renvois en arrière ont visiblement diminué. Depuis qu’on a ajouté la vérification par capture d’écran aux pages publiées, l’oubli « le build est passé mais c’est une autre page qui sortait » s’est arrêté lui aussi.

Je n’ai vérifié que ces trois points. Plutôt que de chercher l’agent le plus intelligent, construisez d’abord un fonctionnement où, même en tombant, on peut revenir en arrière. Ça paraît un détour, mais pour le déploiement en équipe, c’est ce qu’il y a de plus rapide — voilà ma conviction actuelle.

Si vous en êtes au stade de vouloir vraiment lancer Claude Code en entreprise et concevoir ensemble les règles de fonctionnement, en formation et conseil nous montons ensemble la procédure jusqu’au concret. Commencez par écrire les trois lignes des points dangereux propres à votre équipe.