Agentic GTM et product engineering : de 30 à 3

Avant, il fallait 30 personnes pour faire tourner un département GTM ou produit. Aujourd'hui, trois suffisent. Ce n'est pas une prévision sur l'agentic GTM et le product engineering. C'est mon quotidien.
Dans mes boîtes précédentes, j'ai construit le marketing, la vente et le produit avec de grosses équipes : recruter, onboarder, coordonner, espérer. Aujourd'hui, je fais autrement. Quelques pros plus une équipe d'agents IA qui travaillent 24 heures sur 24. J'appelle ça Get Multiplayer : comment humains et agents IA font tourner un département ensemble. Trois au lieu de trente.
Ce que tu vas en retirer :
- Pourquoi l'IA a rendu l'exécution bon marché, et où se trouve le vrai goulot maintenant.
- Comment Get Multiplayer fonctionne des deux côtés : GTM et produit.
- Trois façons concrètes de l'installer dans ta boîte.
La thèse en une phrase
Celui qui construit encore un département GTM ou produit avec 30 personnes construit cher, lent et sans système. Le levier n'est plus dans l'exécution. Il est dans le leadership et le contexte quand dix agents tournent en même temps.
Pourquoi l'exécution est-elle soudain le mauvais goulot?
Parce que l'IA a poussé le coût par exécution vers zéro. Une séquence sales, une recherche de comptes, une première pull request : des heures de travail deviennent des minutes. La question n'est plus qui fait le travail, mais qui le dirige et sur quel contexte il tourne.
Il y a deux ans, l'exécution était la partie chère. Écrire une séquence, analyser un marché, construire une landing page, relire une pull request : que des heures, que des têtes, que du salaire. L'IA a inversé ça. Un agent écrit la séquence en quelques minutes, recherche une centaine de comptes pendant la nuit, construit la première pull request pendant que tu dors.
Ça déplace le goulot. Quand dix agents tournent en même temps, la question n'est plus "qui fait le travail" mais "qui les dirige et sur quel contexte ils travaillent". Dix machines sans direction produisent des déchets dix fois plus vite. C'est garbage in, garbage out, juste plus vite et à grande échelle. Une IA générique ne connaît ni ton code, ni ton Jira, ni ton business. Elle produit de la fumée plausible. Chaque agent a besoin d'une fondation partagée : le contexte business et code de ta boîte, préparé pour les agents. J'appelle ça le Context Engine. C'est lui l'ingrédient magique, pas le modèle.
Comment construire Get Multiplayer sur le GTM et le produit?
De la même façon des deux côtés. Trois pros prennent la direction, trois à cinq agents prennent l'exécution, un Context Engine détient le savoir. Côté GTM, le résultat s'appelle Autonomous GTM, côté produit Autonomous Product Management. Une idée, deux applications.
Le schéma est le même des deux côtés de la boîte. Bon produit, pas de système qui scale avec. J'appelle cet état stuck in the middle : après le product-market fit, avant le scale. Le produit fonctionne, mais la fondation de processus et de données manque.
Côté GTM, voilà comment je le construis :
- Mesurer d'abord, pas deviner. Où est le vrai goulot? Positionnement, pipeline, canaux.
- Un système central au lieu de trois vérités. Un CRM propre, un pipeline, un positionnement en une seule phrase.
- Des agents par priorité de goulot, pas par hype. Trois à cinq agents productifs qui tournent même quand tu pars une semaine.
Côté produit, le résultat s'appelle Autonomous Product Management. Des décisions produit sur du contexte réel, avec des agents IA, au lieu de l'instinct. Aujourd'hui, le savoir est éparpillé entre Jira, les PRD, les stories et la tête des devs seniors. Un agent qui connaît ce contexte passe de singe à code à sparring partner. Il ouvre la première PR agent, construit la carte des trous de tests et montre où shipper est sûr et où ça ne l'est pas.
Les deux côtés partagent la même fondation. Côté GTM, le Context Engine vit comme un software qui fonctionne comme un Jira pour équipes GTM. Côté code et produit, il vit dans un agent qui étudie ton code.
Quelles sont les routes vers le même résultat?
L'apprendre, le faire construire. Et le software qui va avec. Tu n'as pas à prendre toutes les routes, tu dois savoir laquelle colle à ta phase. Apprendre et faire-construire sont une escalade, du faire soi-même au faire faire. Teklens tourne à côté comme software, quelle que soit ta route.
- Apprendre : gtm.science est un framework open source pour équipes GTM. Dans des cohortes live, tu installes Autonomous GTM dans ta boîte, en pratique.
- Faire construire : Pedalix construit ton département GTM et produit à l'intérieur de ta boîte, done for you. Une petite équipe plus des agents IA. Le livrable est un système qui tourne et qui reste. Voir ma façon de travailler.
- Et le software qui va avec : teklens.ai est un software qui rejoint ton équipe produit sous forme d'agents IA. Il connaît ton code, ton Jira et ton business. Il tourne à côté, quelle que soit ta route.
La différence sur le marché : une agence crée de la dépendance, un système crée de la liberté. L'agence livre vite, mais le savoir reste dehors. Quand elle part, le savoir part. Je construis un système qui reste. Je pars, le système reste.
Quelle est la preuve la plus dure que ça marche?
Des résultats concrets issus de mandats, pas des slides. Chez Emporix, j'ai accompagné plus de 100 pour cent de croissance du revenu via Pedalix; chez Xorlab, le ROI est tombé en moins de deux mois. Les données du track record sont vérifiables, pas un pitch.
Trois pros plus dix agents remplacent des équipes qui comptaient 30 personnes, parce que les agents tournent sur un Context Engine propre et qu'un humain les dirige. Applique la même logique à ton équipe produit et tu sors de l'embouteillage engineering sans recruter 20 devs de plus. C'est ça, la variable qui bouge le résultat aujourd'hui.
Ce qui reste
✅ Ce qui marche. Avec trois pros et une équipe d'agents, tu joues grand sans recruter grand. C'est la réalité d'aujourd'hui, pas un pitch.
❌ Ce qui ne marche pas. Des agents sur une fondation vide. Sans contexte et sans direction, tu obtiens des déchets plus vite, pas des résultats. Celui qui croit que l'IA fait le travail par magie sera déçu.
⚠️ Avertissement. Le goulot, ce n'est pas l'outil. Le goulot, c'est toi, si tu laisses tourner dix machines sans plan. Leadership et contexte d'abord, les agents ensuite.
Trente hier, trois aujourd'hui. La raison n'est pas que l'IA fait tout. La raison, c'est que l'exécution est devenue bon marché et que leadership plus contexte font le résultat. Si tu es à l'intersection du produit, du GTM et de l'IA et que tu veux sortir de "stuck in the middle", c'est ton levier.
Prochaine étape. Abonne-toi à la newsletter et reçois les prochaines notes d'opérateur directement dans ta boîte mail.
Questions fréquentes
À quoi ressemble l'Agentic GTM en pratique?
Une petite équipe de pros dirige pendant que trois à cinq agents IA font tourner l'exécution sur le marketing, la vente et les opérations, 24 heures sur 24. Les agents travaillent sur un Context Engine partagé : ils connaissent ton marché, ton offre et ton CRM.
Qu'est-ce que le Context Engine?
Le Context Engine, c'est le contexte business et code de ta boîte, préparé pour être lisible par des agents IA. Il rassemble positionnement, données pipeline, savoir produit et compréhension du code en un seul endroit. Sans lui, les agents produisent de la fumée plausible au lieu de travail utile.
Quand une boîte est-elle stuck in the middle?
Après le product-market fit, avant le scale. Le produit se vend, mais les processus, les données et l'équipe ne sont pas prêts pour le saut suivant. Typique entre 20 et 200 employés dans le software B2B.
L'Agentic GTM remplace-t-il les humains de l'équipe?
Non. Il remplace le volume d'exécution, pas le leadership. Les trois pros deviennent plus importants, parce qu'ils dirigent dix agents au lieu de dix commerciaux. Celui qui sait diriger gagne.
Comment je démarre avec trois au lieu de trente?
D'abord mesurer où se trouve vraiment le goulot (positionnement, pipeline, produit), ensuite construire un système central, puis mettre trois à cinq agents sur le plus gros goulot. Apprends-le via gtm.science, fais-le construire par Pedalix. Et le software qui va avec via teklens.ai.
Serial Entrepreneur, Author
Marc is a serial entrepreneur. He started his first software company at 16, and has worked at the same intersection ever since: software product management meets go-to-market. He builds the bridge: Product × GTM × AI, as one system, not three departments. Three instead of thirty.