Kit du champion
Un guide pratique pour les ingénieurs qui défendent Claude Code en interne : quoi partager, comment répondre aux questions et comment augmenter l'adoption dans votre équipe.
Cette page s'adresse aux ingénieurs individuels qui utilisent déjà Claude Code et qui souhaitent aider leur équipe à l'adopter. Elle couvre quoi partager, comment répondre aux questions que vous recevrez, un guide de trente jours et des réponses aux préoccupations courantes.
L'adoption d'un outil de développement se fait rarement à cause d'une annonce de déploiement. Elle se produit parce que quelqu'un dans l'équipe commence à utiliser l'outil correctement, en parle ouvertement et facilite l'adoption pour les autres. Le travail que vous faites en tant que champion a un effet disproportionné : chaque exemple que vous partagez raccourcit la courbe d'apprentissage pour les ingénieurs qui vous suivent, et chaque question que vous répondez publiquement transforme l'expérience d'une personne en quelque chose que toute l'équipe peut exploiter.
Le rôle de champion
Le rôle consiste en trois comportements qui se renforcent mutuellement.
| Comportement | À quoi cela ressemble en pratique | Pourquoi c'est important |
|---|---|---|
| Partagez ce que vous découvrez | Publiez les prompts, les captures d'écran et les petites victoires de votre propre travail dans les endroits que votre équipe lit déjà, comme un canal d'ingénierie, un fil de standup ou une description de pull request. | Les exemples tirés de votre propre codebase sont plus convaincants que n'importe quelle documentation externe, car les collègues peuvent voir exactement comment l'outil s'applique aux problèmes qu'ils partagent avec vous. |
| Soyez la personne que les gens demandent | Quand un collègue vous demande comment vous avez réalisé quelque chose, répondez avec le prompt réel que vous avez utilisé pour qu'il puisse l'appliquer directement à sa propre tâche. | Un exemple concret et exécutable supprime l'écart entre la curiosité et une première utilisation réussie, ce qui est l'endroit où la plupart des efforts d'adoption s'arrêtent. |
| Agrandissez le cercle | Établissez un petit nombre d'habitudes légères et récurrentes, comme un canal dédié ou un fil hebdomadaire, afin que l'élan continue même quand votre attention est ailleurs. | L'adoption qui dépend d'une seule personne est fragile. L'adoption qui est portée par des habitudes partagées continue à se composer d'elle-même. |
Ce que cela devrait vous coûter
Fixez des attentes avec vous-même et avec votre responsable. Les activités ci-dessous sont destinées à s'adapter à une semaine de travail normale, et le rôle devrait rester un multiplicateur de votre travail existant plutôt qu'une responsabilité de support supplémentaire.
| Activité | Temps par semaine | Conseils |
|---|---|---|
| Publier des victoires et des prompts | Environ 15 minutes | Capturez-les au moment avec une capture d'écran et une ou deux phrases ; évitez de les transformer en rédactions formelles. |
| Répondre aux questions dans un canal partagé | Environ 20 minutes | Répondez publiquement une fois, puis créez un lien vers cette réponse quand la question revient. |
| Animer un fil de démonstration hebdomadaire | Environ 5 minutes | Vous publiez le prompt d'ouverture ; l'équipe fournit le contenu. |
| Appairage ou démonstrations optionnels | 0 à 30 minutes | Réservez cela aux collègues qui sont vraiment bloqués, et offrez le lien Quickstart avant de planifier du temps. |
Partagez vos découvertes
Votre propre expérience est le contenu le plus convaincant que vos collègues rencontreront, car elle est propre à la base de code, aux workflows et aux problèmes que vous partagez tous. La documentation indique aux gens ce qui est possible ; vos publications leur montrent ce qui fonctionne réellement dans votre environnement.
Ce qui mérite d'être partagé
Les publications les plus utiles décrivent une technique qu'un collègue peut réutiliser dès le lendemain plutôt qu'un résultat déjà acquis. Les techniques se démultiplient à mesure qu'elles se diffusent dans une équipe ; ce n'est pas le cas des comptes rendus d'avancement.
Exemples de techniques réutilisables :
- « J'ai appris que la mention d'un répertoire avec @ fonctionne. En la pointant vers
@src/components/et en demandant lesquels manquaient de tests, j'en ai découvert deux que j'avais négligés. » - « Le mode plan (
Shift+Tab) présente d'abord les modifications proposées, c'est pourquoi je suis à l'aise de l'utiliser sur du code partagé. » - « J'ai configuré un hook Stop pour recevoir une notification sur mon bureau lorsqu'une longue tâche se termine. La configuration se trouve dans le fil de discussion. »
- « Exécuter
/initgénère unCLAUDE.mdà partir du dépôt, si bien que l'assistant cesse de redemander nos conventions. »
Où le partager
Publiez là où votre équipe lit déjà. L'objectif est de placer les exemples sur le chemin du travail habituel plutôt que de créer une destination.
| Emplacement | Idéal pour | Format recommandé |
|---|---|---|
Un canal #claude-code ou un canal d'ingénierie général |
Les découvertes, les prompts et les moments « aujourd'hui j'ai appris » | Une capture d'écran accompagnée d'une ou deux phrases de contexte |
| Descriptions de pull requests | Démontrer l'approche sur du code réel que les relecteurs lisent déjà | Une seule ligne telle que « Claude et moi avons fait ce refactoring ; je vous présente volontiers l'approche. » |
| Stand-ups ou comptes rendus écrits hebdomadaires | Normaliser l'utilisation auprès des responsables et des managers N+2 | Une phrase décrivant un résultat concret |
| Wiki d'équipe ou documentation interne | Les modèles durables, les skills personnalisés et les exemples de CLAUDE.md |
Une courte page, liée depuis le sujet du canal afin qu'elle reste facile à trouver |
Le format qui fonctionne
Une capture d'écran accompagnée d'une seule ligne de contexte, ou une brève description avant/après, offre généralement le bon niveau de détail. Gardez chaque publication suffisamment courte pour qu'une personne qui fait défiler la page en saisisse tout de même l'essentiel. Un long compte rendu a tendance à être mis de côté pour plus tard puis oublié, alors qu'une publication courte avec une capture d'écran a tendance à être copiée et essayée.
Les exemples de publications ci-dessous illustrent le ton et la longueur ; adaptez-les plutôt que de les copier mot pour mot.
Appris aujourd'hui que la mention d'un répertoire avec @ fonctionne. Je l'ai
pointée vers @src/components/ et j'ai demandé quels composants manquaient
de tests, et elle en a fait ressortir deux que j'avais oubliés.
J'ai configuré un hook Stop pour recevoir une notification sur mon bureau
lorsqu'une longue tâche se termine. J'ai lancé un refactoring, je me suis
absenté, et j'ai été notifié à la fin. La configuration est dans le fil.
Le mode plan est la raison pour laquelle je suis à l'aise de l'utiliser sur
du code important. Appuyez sur Shift+Tab jusqu'à voir « plan » ; il présente
les modifications qu'il propose sans modifier votre code source.
Soyez la personne à qui l'on pose des questions
Une fois que vous avez partagé quelques exemples, les questions suivront. C'est là qu'un champion est le plus utile, car une bonne réponse apportée à une personne débloque souvent plusieurs autres personnes qui suivent le même canal.
Répondez avec un prompt plutôt qu'avec une explication
Lorsqu'un collègue vous demande comment vous avez accompli quelque chose, la réponse la plus utile est le prompt que vous avez réellement utilisé. Il apprendra davantage en exécutant ce prompt sur son propre problème qu'avec n'importe quelle description que vous pourriez rédiger, et cela lui donne quelque chose sur quoi agir immédiatement.
Colleague: How did you get it to find that race condition?
Champion: I asked, "The test in @tests/scheduler.test.ts is flaky, figure
out why," and it traced two unjoined promises in the scheduler. Try the
same phrasing on your test.
Orientez vers la fonctionnalité plutôt que vers la documentation
Une réponse telle que « Essayez le mode plan, appuyez sur Shift+Tab jusqu'à ce qu'il apparaisse » est plus utile sur le moment qu'un lien vers la documentation. Si la personne a besoin d'approfondir plus tard, elle trouvera l'information par elle-même ; pour l'instant, elle a besoin de la seule chose qui la débloque.
Questions que vous entendrez probablement
| Question | Réponse suggérée | Ressource complémentaire |
|---|---|---|
| « Sur quoi devrais-je l'essayer en premier ? » | Recommandez une tâche réelle mais circonscrite, idéalement un bug ou une corvée que la personne repousse parce qu'elle est fastidieuse plutôt que difficile. | Workflows courants |
| « Comment lui faire confiance avec mon code ? » | Présentez le mode plan : appuyer sur Shift+Tab permet d'y accéder, et Claude effectue ses recherches et propose des modifications sans éditer votre code source. |
Permissions |
| « La configuration en vaut-elle la peine ? » | L'installation prend environ deux minutes, s'exécute dans le terminal et ne nécessite aucune extension d'IDE. Exécuter /init une seule fois suffit pour commencer à travailler. |
Démarrage rapide |
| « Il a produit un résultat incorrect. » | Encouragez-les à renvoyer l'échec à Claude. Coller le message d'erreur ou le test en échec est bien plus efficace que de reformuler la demande initiale. | Workflows courants |
| « Il ne comprend pas les conventions de notre base de code. » | Suggérez d'exécuter /init pour générer un fichier CLAUDE.md, puis d'y ajouter les conventions de l'équipe, les commandes de test et tous les répertoires à éviter. |
Mémoire |
| « Est-ce simplement de l'autocomplétion ? » | Proposez une brève démonstration dans laquelle Claude explique un fichier inconnu, retrace un bug à travers plusieurs services ou rédige un plan de migration. Ces tâches nécessitent un raisonnement à l'échelle du dépôt plutôt que la complétion d'une seule ligne. | Une démonstration en direct de deux minutes |
| « Qu'en est-il de la sécurité et du traitement des données ? » | Renvoyez cette question à votre administrateur. La politique de déploiement et de traitement des données de votre organisation est déjà configurée, et les champions ne doivent pas improviser cette réponse. | Sécurité · Utilisation des données |
Agrandissez le cercle
L'objectif est d'établir un petit nombre d'habitudes légères qui permettent à l'élan de continuer après que vous ayez arrêté de le conduire activement. Vous n'avez pas besoin de construire un programme ou de posséder un déploiement. Quand les questions dans le canal sont répondues par des personnes autres que vous, le rôle a fait son travail.
Modèles qui tendent à fonctionner
| Modèle | Comment l'exécuter | Effort requis |
|---|---|---|
| Un canal dédié | Créez un canal #claude-code (ou un fil récurrent dans un existant), épinglez le lien Quickstart et un exemple fort, et répondez aux questions publiquement pour que chaque réponse bénéficie à tous ceux qui regardent. |
Environ cinq minutes pour configurer, puis ambiant |
| Un fil de démonstration hebdomadaire | Chaque vendredi, publiez « Avec quoi Claude vous a-t-il aidé cette semaine ? » Aucune préparation, diapositives ou réunion ne sont requises ; les captures d'écran et les brèves descriptions suffisent. | Environ deux minutes par semaine |
| Partagez une compétence personnalisée | Publiez votre fichier .claude/skills/<name>/SKILL.md le plus utile, par exemple une compétence /ship qui exécute les tests et lint avant de valider, avec une description d'une ligne. Parce que les compétences sont du Markdown simple, les collègues peuvent les adopter immédiatement. |
Environ cinq minutes par compétence |
| Générez un guide de configuration à partir de votre propre utilisation | Exécutez /team-onboarding dans un projet dans lequel vous avez passé du temps réel. Claude analyse vos sessions récentes, commandes et serveurs MCP, puis produit un guide qu'un nouveau coéquipier peut coller comme son premier message pour rejouer votre configuration. Épinglez-le dans le canal. |
Environ deux minutes |
| Appairez-vous sur une première tâche | Offrez une seule session d'appairage de quinze minutes à quiconque commence. Un résultat réussi sur leur propre code est plus convaincant que n'importe quelle présentation. | Environ quinze minutes par personne |
| Identifiez le prochain champion | Le collègue qui vous pose le plus de questions est généralement prêt à assumer ce rôle. Transmettez-lui cette page et divisez les responsabilités du canal entre vous. | Négligeable |
Guide de trente jours
Si un plan vague est utile, la séquence ci-dessous reflète ce qui tend à fonctionner dans la plupart des équipes. Ajustez librement pour adapter à votre contexte.
1. Semaine 1 : Ensemencez le canal
Créez le canal, épinglez le Quickstart et publiez deux ou trois de vos propres exemples avec les prompts inclus.
Signal que cela fonctionne : quelques collègues réagissent ou répondent, et au moins une question est posée dans le canal.
2. Semaine 2 : Commencez le rythme
Commencez le fil de démonstration hebdomadaire, répondez à chaque question publiquement et partagez une compétence personnalisée ou un extrait CLAUDE.md.
Signal que cela fonctionne : quelqu'un d'autre que vous publie un exemple du sien.
3. Semaine 3 : Appairez et consolidez
Offrez deux ou trois courtes sessions d'appairage et consolidez les questions et réponses les plus courantes dans un message FAQ épinglé.
Signal que cela fonctionne : vous voyez une utilisation répétée, avec les mêmes collègues revenant plutôt que d'essayer une fois et d'arrêter.
4. Semaine 4 : Transmettez
Identifiez un deuxième champion et partagez un bref résumé de ce qui fonctionne et ce qui ne fonctionne pas avec votre responsable ou administrateur.
Signal que cela fonctionne : les questions dans le canal sont répondues par des personnes autres que vous.
Quand quelqu'un veut aller plus loin
Vous êtes l'introduction chaleureuse plutôt que le programme d'intégration. Quand un collègue passe de « devrais-je essayer ceci » à « comment devenir efficace avec ceci », pointez-le vers les pages Quickstart et Flux de travail courants. Elles contiennent de courtes sections couvrant les fonctionnalités qui sont véritablement utiles mais difficiles à découvrir par soi-même.
Répondez aux préoccupations courantes
Le scepticisme sain est attendu ; les ingénieurs doivent être prudents face aux outils qui touchent leur code. La réponse la plus efficace est rarement d'argumenter le cas général. Au lieu de cela, reconnaissez la préoccupation, offrez un bref reframe et proposez une démonstration concrète sur le propre code de la personne. La plupart des préoccupations sont résolues par une seule expérience réussie.
| Préoccupation | Réponse suggérée | Preuve à offrir |
|---|---|---|
| « Je suis plus rapide sans cela. » | C'est probablement vrai pour le code que la personne écrit régulièrement. Suggérez de l'essayer sur le travail qu'ils ont tendance à éviter : fichiers hérités, services inconnus ou échafaudage de test, où l'effet de levier est le plus élevé. | Chronométrez une tâche fastidieuse des deux façons et comparez. |
| « Je ne fais pas confiance à l'IA pour toucher le code de production. » | Acceptez qu'aucune modification ne devrait être fusionnée sans être lue. Suggérez le mode plan pour voir d'abord les modifications proposées, puis examinez le diff avec la même exigence que n'importe quelle pull request. | Démontrez le mode plan sur un fichier réel. |
| « Cela rendra les ingénieurs juniors plus faibles. » | Utilisé correctement, c'est un expliquant efficace. Encouragez les ingénieurs juniors à demander à Claude d'expliquer un fichier et ses sites d'appel avant de lui demander de changer quoi que ce soit. | Exécutez « Expliquez @file et où il est appelé depuis » ensemble. |
| « J'ai essayé une fois et cela a hallucié. » | C'est généralement un problème de contexte plutôt qu'un problème de modèle. @-mentionner les fichiers pertinents, exécuter /init et fournir la sortie d'erreur réelle résout généralement cela. |
Réexécutez leur prompt original avec le contexte @ approprié. |
| « Nous n'avons pas le temps d'apprendre un autre outil. » | Claude Code est une commande de terminal plutôt qu'une plateforme. S'il ne retourne pas de valeur dans la première session, il est raisonnable de le mettre de côté. | Une installation de deux minutes suivie d'un bug réel. |
Feuille de référence rapide
Les techniques ci-dessous sont celles qui déplacent le plus fiablement quelqu'un d'un premier essai à une utilisation quotidienne. Épinglez ce tableau dans un canal ou partagez-le seul.
| Technique | Comment l'appliquer |
|---|---|
| Fournissez le bon contexte | Utilisez les références @file ou @directory/, ou collez directement la sortie d'erreur ou de journal. Fournir un contexte pertinent est plus efficace qu'une formulation élaborée. |
| Examinez le plan avant la modification | Appuyez sur Shift+Tab pour entrer en mode plan. Claude effectue ses recherches et propose des modifications sans modifier votre code source. |
| Enseignez-lui votre référentiel | Exécutez /init pour générer un fichier CLAUDE.md, puis ajoutez vos conventions, commandes de test et tous les répertoires qui ne doivent pas être modifiés. Voir Memory. |
| Réutilisez un flux de travail | Enregistrez un fichier SKILL.md dans .claude/skills/<name>/ pour créer une compétence /name que toute l'équipe peut utiliser. Voir Skills. |
| Restez informé pendant les tâches longues | Configurez un hook Stop pour recevoir une notification de bureau quand une tâche longue se termine. Voir Hooks. |
| Récupérez d'un résultat incorrect | Plutôt que de reformuler la demande, collez le test échoué ou la trace de pile à Claude et demandez-lui de traiter cet échec spécifique. |
| Gardez les modifications chirurgicales | Demandez un diff, ou spécifiez « ne changez que X ». Claude respecte la portée quand la portée est énoncée. |
[!TIP]
Claude Code est mis à jour fréquemment. Vérifiez les détails spécifiques à la version par rapport à la page d'accueil de la documentation avant de distribuer ce matériel en interne.