Formation Claude Code : le développement assisté par agents IA

Formation

Claude Code sur votre dépôt : conventions, permissions, plan, tests, automatisation et maîtrise des coûts

Durée

Deux jours de sept heures qui alternent démonstration sur un dépôt et tâche réelle livrée par chaque participant

Formats

Intra pour une équipe de 12 développeurs au plus, ou individuel ; en présentiel ou à distance, terminal et éditeur ouverts

Tarif

Une journée à partir de 1 980 € HT pour toute l'équipe, quel que soit l'effectif ; préparation sur votre dépôt en plus, au devis

Financement

Masteria certifié Qualiopi ; prise en charge à solliciter auprès de l'OPCO dont dépend votre entreprise

Prérequis

Terminal, Git et au moins un langage maîtrisés ; compte Claude Pro, Max, Team ou Enterprise, ou clé d'API

CLAUDE.md, les règles de chemin et les compétences portent ce que l'agent doit savoir

CLAUDE.md est un fichier Markdown que Claude Code charge au début de chaque séance. Celui du projet, à la racine ou dans le dossier .claude, se versionne avec le code ; CLAUDE.local.md garde vos préférences personnelles hors de Git ; ~/.claude/CLAUDE.md vaut pour tous vos projets, et la DSI peut déployer un fichier géré sur tous les postes. La commande /init en rédige une première version d'après le dépôt. Un dépôt qui ne contient qu'un AGENTS.md, le fichier lu par d'autres agents de code, est pris en charge tel quel.

Anthropic conseille de rester sous 200 lignes : un fichier plus long consomme du contexte et fait baisser le respect des consignes. Gardez les commandes que Claude ne peut pas deviner, les règles de style qui s'écartent des usages du langage, les conventions de branches et de pull requests (les demandes de fusion d'une branche), les pièges de l'environnement. Ajoutez une ligne quand Claude commet deux fois la même erreur. Les consignes propres à une partie du code vont dans .claude/rules/, avec un champ paths qui ne les charge qu'au contact des fichiers concernés.

Une procédure en plusieurs étapes trouve mieux sa place dans une compétence : un sous-dossier de .claude/skills/ contenant un fichier SKILL.md, appelé par /nom ou chargé quand la demande correspond, et dont le corps n'entre dans le contexte qu'à l'usage. Pour une action à effets de bord, un déploiement par exemple, le champ disable-model-invocation réserve le déclenchement à un humain. Un plugin réunit en une unité installée par /plugin des compétences, des sous-agents et des hooks, décrits plus bas, ainsi que des serveurs MCP (le protocole ouvert qui relie l'agent à vos outils) ; ce qu'il exécute, il l'exécute avec vos droits.

Le mode de permission règle ce que Claude fait sans vous demander

Six modes existent. En mode Manuel, de valeur technique default, Claude n'agit sans demander que pour lire. Le mode acceptEdits valide en plus les modifications de fichiers et les commandes de fichiers courantes dans le répertoire de travail. Le mode plan interdit toute modification tant que vous n'avez pas approuvé un plan. Le mode auto confie l'examen de chaque action à un second modèle, le classifieur, qui bloque ce qui paraît risqué. Le mode dontAsk n'exécute que les outils préapprouvés et refuse tout le reste, ce qui convient à l'intégration continue. Le mode bypassPermissions supprime les contrôles et ne se conçoit que dans un conteneur ou une machine virtuelle isolés. Pendant la séance, Maj+Tab fait passer d'un mode à l'autre.

À partir de la version 2.1.283, le mode auto est le mode de départ des séances interactives dans le terminal et dans VS Code. Par défaut, son classifieur bloque notamment le téléchargement suivi de l'exécution de code, les déploiements et migrations de production, les push forcés, l'envoi de données sensibles vers l'extérieur et la fusion d'une pull request qu'aucun humain n'a approuvée. Anthropic l'écrit sans détour : ce mode réduit les demandes de permission sans garantir la sécurité. Un administrateur peut le retirer à toute l'équipe par le paramètre géré permissions.disableAutoMode.

Les règles affinent ces modes. Une règle deny bloque un outil, une commande ou la lecture d'un fichier comme .env dans tous les modes, bypassPermissions compris ; une règle allow préapprouve une commande sûre, comme le lancement de la suite de tests. La commande /sandbox active un bac à sable qui restreint les fichiers et les hôtes réseau accessibles aux commandes Bash, sous macOS, Linux et WSL2.

Le plan approuvé précède la modification, le test qui échoue précède le correctif

Anthropic recommande quatre temps : explorer, planifier, implémenter, puis valider par un commit. En mode plan, que l'on active par Maj+Tab ou par /plan, Claude lit les fichiers et rédige un plan sans toucher au code ; Ctrl+G ouvre ce plan dans votre éditeur pour le corriger avant de l'approuver. Le plan a un coût en temps : pour un changement qui se décrit en une phrase, la documentation conseille de s'en passer.

Donnez à Claude une vérification qu'il peut lancer lui-même : une suite de tests, une compilation, un linter (l'outil qui signale les fautes de style et les erreurs simples). Pour un bogue, demandez d'abord un test qui reproduit l'échec, puis le correctif. Avant un refactoring, cette restructuration du code à comportement inchangé, faites écrire des tests de caractérisation, qui figent le comportement actuel du code sans le juger. Une séance peut écrire les tests et une autre, au contexte vierge, le code qui les fait passer : Anthropic décrit ce partage des rôles pour qu'un même agent ne se donne pas raison à lui-même.

Un sous-agent est une instance de Claude dotée de son propre contexte, de ses outils et de ses instructions, déclarée dans .claude/agents/. Il explore ou relit sans encombrer la séance principale, à laquelle il ne renvoie qu'un résumé ; ses requêtes entament les mêmes limites d'usage. Un hook est une commande que Claude Code lance à un moment précis de son cycle : PreToolUse peut bloquer une action, PostToolUse lancer le formateur après chaque modification, Stop empêcher la fin du tour tant que les tests échouent. Les points de contrôle, rappelés par /rewind ou par deux appuis sur Échap, restaurent le code modifié par les outils d'édition, sans annuler les effets des commandes Bash : Git reste la sauvegarde de référence.

Hors du terminal, le mode non interactif, GitHub Actions et la revue prolongent l'agent

La commande claude -p lance une tâche sans interface et rend le résultat en texte, en JSON ou en flux JSON. Combinée à --allowedTools et au mode dontAsk, elle n'emploie que les outils listés ; --max-turns borne le nombre de tours, et --bare ignore la configuration trouvée dans le dépôt pour obtenir le même comportement sur chaque machine. Cette dernière option compte : sans elle, une exécution -p lance les hooks déclarés dans .claude/settings.json et connecte les serveurs du fichier .mcp.json, sans le moindre dialogue de confiance.

L'action GitHub claude-code-action s'installe par /install-github-app. Elle répond aux mentions @claude dans les tickets et les pull requests, ou exécute une consigne sur n'importe quel événement GitHub, y compris planifié. Par défaut, seul un utilisateur doté des droits d'écriture sur le dépôt peut la déclencher. La clé d'API ou le jeton d'abonnement se range dans les secrets GitHub, jamais dans le code ; pour une organisation, Anthropic préconise une clé d'API de la console plutôt qu'un jeton rattaché à l'abonnement d'une personne.

La revue s'organise à deux niveaux. En local, /code-review relit le diff courant, c'est-à-dire les modifications en cours, et /security-review cherche les failles dans les changements de la branche. Sur Team et Enterprise, le service Code Review, en préversion de recherche, publie sur chaque pull request des remarques classées par gravité ; il n'approuve ni ne bloque rien, se règle par CLAUDE.md ou REVIEW.md et se facture à l'usage, en dehors de l'abonnement.

Sur un abonnement, Claude Code puise dans la même enveloppe que la conversation : une fenêtre glissante de cinq heures, doublée de plafonds hebdomadaires. La commande /usage montre ce qui consomme, compétence par compétence et serveur par serveur. Le siège Premium de Team donne cinq fois l'usage du siège standard ; au-delà des limites, les crédits d'usage prennent le relais au tarif de l'API, tandis qu'une clé d'API se facture au token (le fragment de mot qui sert d'unité de compte), avec --max-budget-usd pour plafonner une exécution non interactive.

Cas pratique : retirer une bibliothèque HTTP en fin de support du module de facturation

Le module de facturation d'un éditeur SaaS appelle son prestataire de paiement à travers une bibliothèque HTTP dont la maintenance s'arrête le 31 octobre. Le module compte une quarantaine de fichiers et une couverture de tests partielle. Le tech lead attend une pull request relisible en une séance, avec des tests qui prouvent que les requêtes envoyées au prestataire n'ont pas changé.

1. Lancez /init si le dépôt n'a pas de CLAUDE.md, puis ajoutez la commande de test du module et la règle « aucun appel réseau réel dans les tests ».
2. Ajoutez une règle deny sur git push et un hook Stop qui lance la suite de tests du module avant chaque fin de tour.
3. Passez en mode plan et soumettez la consigne ci-dessous ; corrigez le plan avec Ctrl+G, puis approuvez-le en choisissant de valider les modifications une à une.
4. Faites passer le lot des tests de caractérisation sur l'ancien code avant d'autoriser la migration.
5. Confiez la relecture du diff à un sous-agent qui le confronte au plan, lancez /security-review, puis ouvrez la pull request.

Nous retirons la bibliothèque HTTP [ancienne bibliothèque] du module src/billing avant le 31 octobre, date de fin de sa maintenance. Elle sert aux appels vers notre prestataire de paiement. Remplace-la par le client HTTP déjà utilisé dans le dépôt, configuré dans src/core/http.

Commence par explorer et dresser l'inventaire : chaque fichier qui importe l'ancienne bibliothèque, chaque appel avec sa méthode, son URL, ses en-têtes, son délai d'attente et sa politique de nouvelle tentative, et les tests qui couvrent ces appels aujourd'hui.

Propose ensuite un plan en trois lots.
Lot 1 : des tests de caractérisation qui figent le comportement actuel face au prestataire (requête envoyée, erreurs 4xx et 5xx, délais dépassés), contre un serveur simulé, sans aucun appel réseau réel. Ces tests doivent passer sur le code actuel.
Lot 2 : la migration, fichier par fichier, sans changer la signature des fonctions publiques du module.
Lot 3 : la suppression de la dépendance et la mise à jour de la documentation du module.

Pour chaque lot, indique les fichiers touchés, la commande de test et le critère qui autorise le lot suivant. Signale tout comportement de l'ancienne bibliothèque sans équivalent direct (nouvelles tentatives automatiques, redirections, encodage des paramètres) au lieu de le reproduire par supposition. N'ajoute aucune dépendance sans me la proposer d'abord.

Ce que vous obtenez. Vous tenez l'inventaire des appels, un plan en trois lots corrigé avant approbation, des tests qui passent sur l'ancien code puis sur le nouveau, et une migration contrôlée lot après lot. Avant la fusion, relisez les tests de caractérisation eux-mêmes : un test réécrit pour passer avec le nouveau code ne prouve plus rien. Contrôlez aussi chaque dépendance ajoutée dans votre registre de paquets, comme le recommandent l'ANSSI et le BSI face aux paquets inventés par les assistants de code.

Les pièges à connaître

Choisissez le dépôt et trois tickets de votre backlog : les deux jours se déroulent dessus.