Formation Claude Code : se former et former ses équipes

Les équipes qui adoptent Claude Code traversent souvent la même séquence : deux jours d'enthousiasme, une semaine de résultats inégaux, puis un plateau. Ce plateau a une cause matérielle. Personne n'a écrit les règles du dépôt, personne n'a branché de contrôle automatique, et chaque développeur négocie seul avec l'agent en obtenant un résultat différent de son voisin.

Une formation Claude Code utile passe donc peu de temps sur la rédaction de prompts, et beaucoup sur deux sujets : la configuration que toute l'équipe partage dans git, et le moyen donné à l'agent de prouver que son travail tient. Ce qui suit détaille le parcours individuel des deux premières semaines, les fichiers à écrire pour une équipe, le format collectif qui fonctionne, le budget réel et les indicateurs qui disent si la montée en compétence a servi.

Ce qu'une formation Claude Code doit transmettre en priorité

Une formation Claude Code doit d'abord apprendre à donner à l'agent un contrôle qu'il peut exécuter lui-même, puis à lire la preuve qu'il rend. La formulation des demandes vient après, et elle s'apprend vite. Deux mesures publiques expliquent cet ordre de priorité.

Une expérience contrôlée menée par METR, dont les résultats sont parus en juillet 2025, a mesuré l'effet des assistants de code sur des développeurs chevronnés. Seize contributeurs open source ont traité 246 tâches réelles dans des dépôts qu'ils connaissaient depuis cinq ans en moyenne, chaque tâche étant tirée au sort pour autoriser ou interdire l'IA. Résultat : 19 % de temps en plus quand l'IA était autorisée, alors qu'ils avaient prévu 24 % de gain avant l'étude et qu'ils estimaient encore avoir gagné 20 % après l'avoir terminée (Becker, Rush, Barnes et Rein, arXiv:2507.09089).

Les outils ont changé depuis : l'étude portait sur des sessions menées entre février et juin 2025, avec Cursor Pro et les modèles Claude 3.5 et 3.7 Sonnet. L'écart qui reste valable, c'est celui entre le ressenti et la mesure. Une équipe peut être persuadée d'accélérer pendant qu'elle ralentit, et aucune formation ne corrige cet aveuglement si elle ne fournit pas d'instrument.

L'enquête Stack Overflow 2025 pointe le même endroit. 84 % des répondants utilisent ou prévoient d'utiliser des outils d'IA et 51 % des développeurs professionnels s'en servent chaque jour, sur 33 662 réponses à cette section. Sur les 31 476 personnes interrogées ensuite à propos de leurs frustrations, 66 % désignent en tête « les solutions presque justes, mais pas tout à fait » et 45 % trouvent que déboguer du code produit par l'IA prend plus de temps (résultats publics de l'enquête). Une formation qui s'arrête aux prompts laisse les participants exactement devant ce mur.

La compétence à transmettre tient en une phrase, et les bonnes pratiques publiées par Anthropic la formulent mieux que n'importe quel formateur : donnez à Claude un contrôle qu'il peut exécuter lui-même. Une suite de tests, un code de sortie de build, un linter, une capture d'écran comparée à une maquette. Sans ce signal, « ça a l'air fini » devient le seul critère d'arrêt et c'est le développeur qui sert de boucle de vérification, à chaque erreur, après coup. Si vous hésitez encore entre plusieurs assistants avant de lancer un plan de formation, le comparatif entre Claude Code, Cursor et GitHub Copilot traite ce choix en amont.

Le parcours des deux premières semaines devant son terminal

Le parcours tient en trois paliers. Un premier jour passé à interroger le dépôt sans produire une ligne de code. Deux jours pour installer la séquence explorer, planifier, implémenter, commiter. Une deuxième semaine consacrée aux sous-agents et à la relecture du diff par un second contexte. L'installation, elle, se règle en une commande.

Sur macOS, Linux ou WSL, curl -fsSL https://claude.ai/install.sh | bash pose le binaire, qui se met ensuite à jour tout seul en arrière-plan. Homebrew (brew install --cask claude-code) et WinGet (winget install Anthropic.ClaudeCode) existent aussi, sans mise à jour automatique, comme le précise la page d'installation officielle. On lance claude dans un projet, on s'authentifie, et la session démarre.

Le premier jour ne devrait pas servir à produire du code. Il sert à interroger le dépôt : comment fonctionne le logging, comment on ajoute un endpoint, pourquoi cette fonction appelle celle-ci plutôt qu'une autre. Un nouvel arrivant gagne des jours d'onboarding par cette seule pratique, et l'équipe apprend à repérer quand l'agent invente une réponse plausible sur son propre code.

Les deux jours suivants installent la séquence explorer, planifier, implémenter, commiter. Le mode plan s'active avec Shift+Tab jusqu'à voir ⏸ plan mode on, ou au lancement avec claude --permission-mode plan : l'agent lit et répond sans rien modifier. On lui fait produire un plan, on le relit, on l'ouvre au besoin dans son éditeur avec Ctrl+G, puis on sort du mode plan pour l'exécution. La documentation le dit elle-même : pour une correction dont on pourrait décrire le diff en une phrase, planifier coûte plus cher que ça ne rapporte.

Trois réflexes de session valent plus que n'importe quelle astuce de formulation. /init génère un premier CLAUDE.md à partir du projet, /context confirme qu'il est bien chargé. /clear repart d'un contexte vide entre deux tâches sans rapport, parce que la documentation le rappelle sans détour, la performance d'un modèle se dégrade à mesure que sa fenêtre de contexte se remplit. Et après deux corrections infructueuses sur le même point, la bonne manœuvre consiste à effacer le contexte puis à réécrire une demande précise, plutôt qu'à corriger une troisième fois dans une conversation encombrée d'approches ratées.

La deuxième semaine ouvre deux mécanismes qui changent la qualité du résultat. Les sous-agents explorent dans leur propre fenêtre de contexte et ne rapportent qu'un résumé, ce qui garde la conversation principale propre pendant une investigation qui lit cinquante fichiers. La revue adverse, ensuite : un second contexte relit le diff sans connaître le raisonnement qui l'a produit, et rend ses manques. La réserve est dans la documentation officielle aussi, et elle est saine : un relecteur à qui l'on demande de trouver des trous en trouvera toujours, donc il faut lui demander de signaler ce qui touche à la correction du code, pas ses préférences de style. Enfin, /rewind, ou Esc deux fois quand le champ de saisie est vide, restaure la conversation et les fichiers à un point antérieur. La limite est documentée et mérite d'être dite en formation : seules les éditions passées par les outils de modification de fichiers sont capturées, pas celles faites par une commande shell.

Les quatre fichiers qui font qu'une équipe travaille pareil

Quatre objets versionnés alignent une équipe : le fichier d'instructions CLAUDE.md, les skills, les hooks et les sous-agents personnalisés. Un développeur formé seul repart avec ses habitudes, une équipe repart avec ces quatre fichiers, et c'est la partie du travail qui survit au départ de la personne la plus motivée.

Le premier est le CLAUDE.md, lu au début de chaque conversation. Trois portées cohabitent : ./CLAUDE.md ou ./.claude/CLAUDE.md pour le projet, partagé par git ; ~/.claude/CLAUDE.md pour les préférences personnelles ; et une version pilotée par l'organisation, déployée par MDM ou Ansible dans /etc/claude-code/CLAUDE.md sous Linux. La documentation vise moins de 200 lignes par fichier : au-delà, les instructions se diluent et l'agent en ignore une partie. Les imports @chemin/vers/fichier permettent de découper, avec une profondeur maximale de quatre niveaux, mais chaque fichier importé entre quand même dans la fenêtre de contexte au lancement.

Le contenu qui mérite d'y figurer est celui que l'agent ne peut pas déduire du code. Sur un de nos monorepos, une règle tient en une ligne : toujours git -C <chemin>, jamais un cd suivi d'une commande git. Elle vient d'un incident précis, un cd dans un dossier de dépôts imbriqués qui avait fait indexer les fichiers du dépôt parent, avec des noms identiques et aucun message d'erreur pour le signaler. Ce genre de règle ne s'invente pas en atelier : elle s'écrit le jour où quelqu'un se fait avoir, et c'est pour cette raison que le fichier se relit en revue de code comme le reste du dépôt. La méthode que j'applique au quotidien détaille ce que nous y mettons et ce que nous en avons retiré.

Les skills forment le deuxième objet. Un dossier .claude/skills/<nom>/SKILL.md, un en-tête avec un nom et une description, et le contenu se charge à la demande au lieu d'occuper le contexte de chaque conversation. C'est là que vont les procédures rares et longues : convention d'API, recette de déploiement, checklist de revue. Pour les workflows à effet de bord, l'option disable-model-invocation: true réserve le déclenchement à un appel manuel.

Les hooks sont le troisième, et le plus sous-utilisé en équipe. La documentation pose la distinction qui compte : les instructions d'un CLAUDE.md sont du contexte, pas de la configuration appliquée, et pour bloquer une action quoi qu'il arrive il faut un hook PreToolUse. Un hook lance un script à un moment précis, indépendamment de ce que l'agent décide. Formater après chaque édition, refuser l'écriture dans un dossier de migrations, ou bloquer la fin d'un tour tant qu'un contrôle échoue avec un hook Stop, que Claude Code outrepasse après huit blocages consécutifs (documentation des bonnes pratiques, section sur les portes déterministes). Quand une règle de CLAUDE.md est contournée deux fois, sa place est dans un hook.

Les sous-agents personnalisés ferment la liste : un fichier par agent dans .claude/agents/, avec son nom, sa description, ses outils autorisés et son modèle. Un relecteur sécurité qui n'a droit qu'à la lecture et à la recherche vaut mieux qu'une consigne polie dans un fichier d'instructions.

Former une équipe : le format qui tient, celui qui s'évapore

La démonstration magistrale de deux heures devant toute l'équipe ne laisse rien. Chacun repart avec l'impression d'avoir compris, personne n'a configuré son dépôt, et trois semaines plus tard deux développeurs sur huit utilisent l'outil sérieusement. Le format qui produit des effets mesurables ressemble davantage à un chantier qu'à un cours.

Une demi-journée d'atelier sur le dépôt réel de l'équipe, d'abord. On y écrit le CLAUDE.md ensemble, on pose deux hooks, on transforme une procédure existante en skill, on définit un sous-agent de relecture. Le livrable de la séance est un commit, pas un support de présentation. Deux semaines de pratique ensuite, sur de vrais tickets, avec pour consigne de noter ce qui a échoué. Puis une séance de reprise où chacun montre une session ratée, ce qui est le seul moment où les vraies difficultés remontent.

Un référent doit tenir le fichier d'instructions et relire les hooks, comme on tient une configuration de CI. Sans propriétaire, le CLAUDE.md gonfle, se contredit, et l'équipe conclut que l'outil obéit mal. Commencer par un groupe pilote de trois ou quatre personnes permet de stabiliser cette configuration avant de la présenter aux autres, qui héritent alors d'un dépôt déjà réglé.

Une dernière chose sur le choix des terrains de démonstration. La mesure de METR porte précisément sur des développeurs chevronnés qui travaillent dans des dépôts pratiqués depuis cinq ans en moyenne, et c'est là qu'elle constate un ralentissement de 19 % (arXiv:2507.09089). L'étude ne compare pas cette population à des profils moins expérimentés, donc elle ne dit rien de ce que gagnent les autres. Notre lecture, tirée de nos missions et non de l'étude, tient en une ligne. Les gains les plus francs se voient sur le code qu'on ne connaît pas, les tests manquants, les migrations répétitives, les corrections de lint et l'exploration d'un dépôt hérité, plutôt que sur le module qu'un développeur écrit de mémoire. Cadrer l'atelier sur ces terrains évite la démonstration ratée devant l'équipe entière. La sécurité se traite dans la même séance, avec les listes d'autorisation de commandes, le bac à sable qui restreint l'accès au disque et au réseau, et les réglages imposés par l'organisation quand le contexte l'exige.

Le budget réel d'une montée en compétence

Les licences sont la partie visible et la moins chère. Voici la grille relevée sur la page officielle des tarifs.

Source : claude.com/pricing, consultée le 21 septembre 2026. L'offre Enterprise se facture au siège plus l'usage aux tarifs de l'API, ce qui suppose un suivi de consommation que les équipes sous-estiment au moment de signer.

Le poste que personne ne budgète se trouve ailleurs. Un développeur équipé produit plus de diff, donc la charge de relecture humaine augmente à proportion. Une équipe qui met déjà trois jours à relire une pull request n'a pas un problème d'outillage, elle a un goulot que l'IA va élargir. Deuxième poste : la configuration initiale, qui représente une demi-journée par dépôt pour le CLAUDE.md, les hooks et les premiers skills, plus quelques heures de réglage les semaines suivantes. Troisième poste : le temps d'atelier et de reprise, autour d'une journée par développeur sur un mois, réparti en séances courtes.

Pour la formation elle-même, nos accompagnements se font en visio, sur votre dépôt et vos tickets, avec un tarif indiqué sur la fiche correspondante plutôt qu'un catalogue figé, parce qu'un atelier sur un monorepo de quatre dépôts imbriqués n'a pas le même contenu qu'une prise en main sur une application isolée. Le plus efficace reste de planifier un appel avec Dominique pour cadrer le périmètre avant de parler prix. Notre fiche outil sur Claude Code résume de son côté les fonctionnalités et les cas d'usage que nous rencontrons en mission.

Savoir si la formation a produit quelque chose

L'effet d'une formation se lit sur quatre indicateurs de flux : le délai entre l'ouverture et la fusion d'une pull request, la part de pull requests renvoyées en correction, le nombre de tickets terminés avec une preuve jointe, et le temps consacré aux tâches que l'équipe repoussait. Une enquête de satisfaction en fin de séance mesure l'enthousiasme, pas l'effet, et les participants de l'étude METR se croyaient 20 % plus rapides en étant 19 % plus lents (arXiv:2507.09089). Le nombre de lignes écrites ne vaut pas mieux comme juge, puisqu'un agent en produit beaucoup par construction.

Ces quatre indicateurs se relèvent sans instrumentation lourde, sur la même équipe, avant et après. Le délai entre l'ouverture d'une pull request et sa fusion capte le coût de relecture autant que la vitesse d'écriture. Le taux de renvoi en correction monte dès que du code non vérifié arrive en revue, ce qui rend visible la dérive avant qu'elle ne coûte cher. La preuve jointe au ticket, sortie de tests ou capture d'écran, mesure directement l'adoption de la boucle de vérification, et c'est l'indicateur qui bouge le plus vite après un atelier réussi. Le temps consacré aux tâches repoussées depuis des mois, tests manquants et dépendances à mettre à jour, montre enfin si l'équipe a récupéré de la capacité ou seulement changé de façon de travailler.

Comparer deux équipes différentes ne prouve rien, leurs tickets n'ont pas la même difficulté. Comparer la même équipe sur deux trimestres donne une base discutable mais lisible, à condition d'écrire la mesure avant de commencer la formation. Nous avons détaillé cette question de la mesure dans un autre article, sur ce que gagnent réellement les équipes qui codent avec l'IA.

Un dernier signal, qualitatif et très fiable : le jour où un développeur ouvre une pull request qui modifie le CLAUDE.md ou ajoute un hook, sans qu'on le lui demande, la formation a pris. Il a cessé de négocier avec l'agent tâche par tâche pour régler le cadre une fois pour toutes.

Questions fréquentes

Faut-il savoir coder pour suivre une formation Claude Code ?

Oui, au moins assez pour relire un diff et comprendre ce qu'une commande va faire. L'outil écrit le code, exécute des commandes et crée des commits ; sans capacité de relecture, personne ne peut arbitrer entre une correction propre et un contournement qui masque le problème. Un profil produit ou ops en tire de la valeur pour explorer un dépôt et rédiger des spécifications, avec un développeur qui valide ce qui part en production.

Combien de temps avant qu'une équipe soit autonome ?

Comptez deux semaines pour que chacun ait une pratique quotidienne, et six à huit semaines pour que la configuration du dépôt se stabilise. Le premier palier s'atteint vite parce que l'interface est un terminal et une conversation. Le second demande d'accumuler des règles nées d'incidents réels, ce qui prend le temps que prennent les incidents. Un groupe pilote qui démarre un mois plus tôt raccourcit nettement cette phase pour les suivants.

Quel abonnement prendre pour former cinq développeurs ?

Un siège Pro par personne suffit pour démarrer, à 17 $ par mois en facturation annuelle selon la grille officielle consultée le 21 septembre 2026. Pour les développeurs qui enchaînent les sessions longues, la formule Max part de 100 $ par mois et annonce cinq à vingt fois l'usage de Pro. Pour une gestion centralisée des sièges et des réglages d'organisation, la formule Team commence à 20 $ par siège et par mois en annuel, 25 $ au mois.

Peut-on former une équipe sans changer les règles de revue ?

Non, et c'est la question qui fâche le plus souvent en atelier. Quand le volume de diff augmente, une revue humaine inchangée devient le goulot d'étranglement et annule le gain. Les équipes qui s'en sortent déplacent une partie du contrôle en amont : hooks obligatoires, tests exigés dans la pull request, relecture par un second contexte avant la relecture humaine. La revue reste humaine sur les décisions, pas sur la vérification mécanique.