90% des équipes GTM qui utilisent Claude Code s'en servent pour écrire des posts LinkedIn. Les 10% restants construisent des systèmes qui génèrent du pipeline en continu.

La différence n'est pas le modèle. Ce n'est pas non plus la stack d'outils. C'est qu'elles ont construit un repository.

Ces équipes arrivent à masteriser l'utilisation de Claude Code car leur IA connaît le contexte global, les objectifs et les processus à mettre en place dès le début de chaque conversation : ICP, Persona, Tiers, Toolstack, Process de vente interne, etc.

L'équipe n'explique pas son GTM à Claude : Claude le connaît déjà.

Aujourd'hui, j'aimerais vous montrer comment les équipes GTM de boîtes comme Linear, Slack ou Canva construisent des systèmes signal-driven pilotés par Claude Code, et pourquoi vos concurrents les plus dangereux sont déjà en train de le faire.

C’est quoi un GTM Repository ?

Le concept est simple sur le papier : un ensemble de fichiers markdown dans un repo Github qui contient tout le knowledge de votre boîte. Tout est documenté de A à Z.

Claude Code lit ces fichiers automatiquement au démarrage de chaque session dans le repo. Une fois que le contexte est là, n'importe quelle tâche (rechercher un compte, scorer une liste, construire une campagne) devient un prompt d'une ligne.

Sans repository :

  • 4h pour briefer une nouvelle campagne outbound

  • Résultat inconstant selon qui la lance

  • Votre SDR senior part, le contexte part avec lui

  • Chaque nouvelle session avec Claude recommence de zéro

Avec repository :

  • Un prompt d'une ligne

  • Output identique peu importe qui exécute

  • Le contexte vit dans le repo, pas dans les têtes

  • Chaque campagne nourrit le système pour la suivante

En quoi c'est un avantage ?

  • Vous n'avez pas besoin de prendre des heures à redonner du contexte à chaque session.

  • Toutes vos équipes donnent les mêmes inputs et Claude leur livre les mêmes formats d'outputs.

Pourquoi la plupart des équipes ne le mettent pas en place ?

Raison #1 : l'humain aime les résultats immédiats. Donc prendre des heures voire des jours à construire un repository qui n'apporte pas de résultats le temps de la création n'est pas apprécié.

Raison #2 : cela demande de connaître parfaitement le métier (Prospection, SEO, Ads, quelque domaine que ce soit). Si vous avez des connaissances de base et que vous ne savez pas les assembler correctement, votre repo produira des résultats basiques, et vous prendrez plus de temps à tout ajuster.

Sauf que si vous arrivez à contourner ces deux problématiques, les gains potentiels à aller chercher sont très importants :

  • La première fois que vous lancez une signal campaign avec du vrai contexte derrière, versus un prompt générique, l'output est visiblement meilleur.

  • Après six mois à mettre à jour votre signal library avec des données de performance, votre scoring model est calibré sur les résultats réels et devient plus performant.

  • Après un an, vous pouvez faire tourner votre repository les yeux fermés.

Ça compound, ce qui n'est pas possible avec le prompting générique. Et ça peut aller plus vite que ça.

L'architecture d’un bon repository

Un GTM repository bien construit a cinq couches.

CLAUDE.md : le cerveau

Le fichier le plus important. Claude Code le lit automatiquement au début de chaque session. C'est la couche de contexte persistant : résumé d'ICP, top signals, positionnement, équipe, priorités actuelles. Tout le reste du repo est référencé depuis ce fichier.

Le failure mode : le rendre trop long. CLAUDE.md doit être scannable en deux minutes. Tous les éléments de détail doivent être dans des context files vers lesquels il pointe.

Context : la connaissance institutionnelle

Six fichiers qui capturent votre stratégie GTM sous forme structurée.

context/profile.md : overview entreprise, produit, deal profile par segment, et customers de référence. La fondation sur laquelle tous les autres fichiers s'appuient. Quand Claude a besoin de décrire ce que vous faites dans un research brief ou une séquence, il lit ça en premier.

context/icp-definition.md : tier definitions avec critères explicites.

Pas « on cible les SaaS en Série B ». Ça, c'est une catégorie, pas une définition. Une vraie définition d'ICP inclut des détails fins et des sur-couches vous permettant de mettre en valeur des sous-ICP et d'exclure les anti-ICP.

Un pattern constant chez toutes les équipes qui sur-performent qu'on a vues : elles maintiennent un ICP evolution log. À chaque fois que l'ICP change (un filtre resserré, un segment retiré parce qu'il ne convertit pas), elles notent ce qui a changé et pourquoi. Six mois de ce log valent plus que la définition actuelle.

context/signal-library.md : signals avec méthodes de détection et hooks associés.

Pas « entreprises récemment fundées ». Un vrai signal, c'est précisément défini, scoré, et associé à un hook de message.

Un funding event de 150 jours n'a pas le même impact qu'un signal de 10 jours. Le repo doit les scorer différemment, et c'est ce qui fait toute la différence entre une active list qui reflète l'urgence réelle et une liste qui se remplit silencieusement de comptes obsolètes.

Ça compte parce que la plupart des équipes ne font pas décroître leurs signaux, ce qui veut dire que leur active list se remplit silencieusement de comptes qui étaient pertinents il y a six mois et ne le sont plus. Le decay force la liste à refléter l'urgence réelle, pas l'intérêt historique.

Signal combinations. Deux signaux ensemble sont plus prédictifs qu'un seul, et sont scorés en conséquence. Une Série B + un new hire RevOps la même semaine, ce n'est pas un compte à 65 points : c'est un compte à 80 points avec un bonus de combinaison.

La signal library est aussi l'endroit où la performance est trackée. Quels signaux génèrent réellement des meetings ? Lesquels ont l'air bien en théorie mais ne produisent pas de pipeline ? Une signal library qui n'est pas mise à jour avec les résultats est un hypothesis document. Mise à jour avec des outcomes, c'est un learning system.

context/positioning.md : la source de vérité sur la façon dont vous parlez de ce que vous faites. Propositions de valeur, approche par ICP/Persona, matrice de copywriting et une section « ce qu'il ne faut pas dire » (très importante).

context/personas/ : un fichier par buyer persona. Titre, rôle dans la décision, ce sur quoi ils se mesurent, comment ils achètent, ce qui attire leur attention, ce qui est ignoré. Le sample outreach hook calibré sur chaque signal, c'est ce dans quoi Claude pioche pour construire tout premier touch.

Skills

Un skill est un fichier markdown qui dit à Claude comment exécuter une tâche GTM spécifique en utilisant votre contexte. Quelques exemples :

Signal to Sequence : à partir d'un signal et d'un segment cible, produit une campagne complète (trigger logic, audience, copy, measurement targets).

ICP Scoring : score un compte ou une liste et assigne un tier.

Weekly reporting : analyse les campagnes lancées, repère les patterns de performance, identifie les zones de friction et nourrit le repository pour qu'il s'améliore en permanence.

Workflows

Des documents qui expliquent comment l'opérationnel doit être géré dans les moindres détails. Cela permet à Claude de savoir quel workflow exécuter dans Cargo par exemple, et comment l'adapter.

workflows/enrichment.md définit la data waterfall : il permet de déclencher un ou plusieurs plays Cargo qui vont enrichir la donnée en profondeur selon les besoins.

workflows/signal-routing.md est l'arbre de décision qui tourne quand un signal se déclenche. Sans ce document, les campagnes Intent-based et les campagnes ICP/Persona Fit se marchent dessus et impactent négativement vos performances.

workflows/campaign-build.md mappe tout le process de campagne, de la définition d'audience jusqu'au launch puis à la review de mesure.

Outputs

Tout ce qui sort du repo est analysé puis archivé dans cette partie. Six mois d'outputs à côté des context files qui les ont produits, c'est une feedback loop : vous voyez comment votre OS a évolué, quelles campagnes ont marché et lesquelles non, et comment votre ICP a changé dans le temps.

Construire le vôtre

Depuis plusieurs semaines, de nombreuses entreprises nous demandent de construire leur OS de prospection sur Claude Code en créant leur repository en entier.

Donc on a lancé une offre Repository clé en main. Les étapes :

  • Kick-off : prise d'information de tous les éléments nécessaires. Accès aux différents outils, processus commercial, etc.(2 à 4 jours)

  • Phase de build : on construit votre repository sur-mesure en intégrant tout le knowledge que l'on a capté sur +80 clients accompagnés.(3 semaines)

  • Phase de déploiement : on intègre le repository au sein de quelques personnes de vos équipes pour une phase de test intensive + remontée d'informations.(1 jour)

  • Phase d'ajustement : on ajuste les derniers détails pour vous permettre de bénéficier d'un repository complet et ultra-performant.(2 semaines)

  • Maintenance continue : on le maintient à jour au fur et à mesure du temps.

Si ce type d'offre est susceptible de vous intéresser, prenez un créneau pour qu'on en discute : https://cal.com/antoineguine/appel-de-decouverte-nws

Le garder à jour

Le setup, c'est l'affaire de quelques dizaines d'heures. Le compounding se joue dans la maintenance, et c'est plus léger qu'il n'y paraît. Voici la maintenance loop la plus performante qu'on a identifiée :

  • Hebdo (5 minutes). Intégrer les changements de la semaine (nouveaux plays Cargo, changement de cibles, correction du messaging, etc.).

  • Après chaque campagne (15 minutes). Ajouter les résultats au campaign output file : reply rates, meeting rates, quels signaux ont converti, quels touches ont déclenché des réponses. C'est l'étape que la plupart des équipes skippent, et c'est pour ça que leur signal library reste un document d'hypothèse au lieu de devenir un learning system.

  • Trimestriel (1 heure). Review complète du repository pour reprendre les fichiers au complet avec les évolutions marché, les learnings, les wins et les losses.

Sans cette loop d'update constante, votre repository deviendra obsolète en l'espace de quelques mois et les résultats ne suivront plus. Les équipes qui performent le plus sont celles qui implémentent les nouveautés le plus rapidement possible dans leur OS de prospection et qui arrivent à le nourrir avec des insights spécifiques en continu.

Les équipes GTM qui prennent de l'avance en ce moment ne font pas plus d'outbound, ne dépensent pas plus en paid, n'écrivent pas de meilleures copy.

Elles ont construit un meilleur contexte.Leur AI a quelque chose avec quoi travailler. Leurs signaux sont calibrés sur des outcomes réels.

Le repository n'est pas une finalité, c'est simplement un espace d'expression qui fait la passerelle entre la connaissance humaine et l'IA.

Construisez-le une fois. Mettez-le à jour quand les choses changent. Laissez-le compounder.