Note de la rédaction : L'IA pénètre dans les entreprises, mais la vraie question n'est pas « faut-il utiliser des agents », mais plutôt de savoir si ces agents peuvent comprendre l'entreprise elle-même.
Cet article, en suivant les 100 premiers jours de l'auteur chez Ramp, aborde un problème plus fondamental : une entreprise qui tourne à plein régime ne peut pas se contenter de laisser les nouveaux arrivants lire lentement la documentation, interroger les collègues et combler le contexte par eux-mêmes, ni laisser chaque outil d'IA agir de manière isolée. Ce qui compte vraiment, c'est de construire un « cerveau de l'entreprise » en constante évolution, qui capitalise les réunions, documents, discussions Slack, retours clients et décisions produits, permettant ainsi aux nouveaux arrivants et aux agents de partir du même contexte.
Lorsque le contexte est systématisé, l'onboarding n'est plus seulement un long processus d'adaptation, et l'IA n'est plus une série d'outils isolés. La valeur de l'IA en entreprise pourrait finalement ne pas résider dans le nombre d'agents déployés, mais dans la capacité de l'entreprise à établir d'abord une base de connaissances fiable, lisible et réutilisable.
Voici l'article original :
Dans une course de relais 4×100 mètres, la victoire ne se joue souvent pas sur la totalité du parcours, mais se concentre sur une zone de transmission d'environ 20 mètres. Les coureurs doivent effectuer le passage du témoin à pleine vitesse : si le relayeur part trop tôt, le témoin tombe ; s'il part trop tard, le donneur doit ralentir, et toute l'équipe perd instantanément son avantage. Si la transmission elle-même n'est pas précise – position des mains, angle, timing, la moindre erreur à l'un de ces niveaux – le résultat peut aussi être la chute du témoin.
Une équipe peut avoir les coureurs les plus rapides de la compétition et perdre malgré tout dans ces 20 mètres. La vitesse est importante, la transmission l'est aussi. Ce qui détermine vraiment la victoire, c'est que les deux soient réunies simultanément.
Chaque transmission de poste que j'ai vue est essentiellement comme une course de relais, sauf qu'un des coureurs est encore sur les starting-blocks. Un nouveau arrive le lundi, tout recommence à zéro ; l'organisation, elle, ne ralentit pas pour autant et continue d'avancer à son rythme habituel. Le nouveau doit alors se contenter de lire la documentation, d'écouter passivement sur Slack, de poser sans cesse les mêmes questions, puis de passer trois mois à comprendre le mode de fonctionnement de l'organisation, jusqu'à ce qu'il devienne enfin « utile ».
Nous considérons généralement cet écart comme un problème de temps, comme si, avec suffisamment de temps, le nouvel arrivant finirait naturellement par suivre. Mais ce n'est pas le cas. Cet écart est soit résolu par le système, soit il persiste.
Le contexte, le véritable système de transmission de l'organisation
Cela fait environ 100 jours que j'ai rejoint Ramp. Avant cela, j'ai travaillé cinq ans chez Plaid, connaissant chaque produit, chaque histoire client, et le contexte derrière chaque décision. Je pouvais raconter ces histoires sans réfléchir. Mais en arrivant chez Ramp, je ne connaissais presque rien de tout cela.
Or, le cœur du marketing produit, c'est justement de raconter des histoires. Si vous ne connaissez pas les personnages, l'intrigue et les causes et effets d'une histoire, vous ne pouvez pas vraiment bien la raconter.
Dès le premier jour, mon objectif était de construire une organisation de marketing produit native de l'IA. Mais pour y parvenir en l'absence de contexte, je devais d'abord étendre ma propre base de connaissances – c'est-à-dire la « couche de contexte » qui soutient tout le travail.
Ramp est une entreprise réputée pour sa vitesse. Ici, il n'y a pas d'espace pour « rattraper tranquillement le trimestre prochain ». L'entreprise lance, itère et avance chaque semaine. Soit vous suivez le rythme, soit vous devenez un coût supplémentaire dans le fonctionnement de l'organisation.
Parallèlement, je vivais un autre niveau d'onboarding. Ramp est déjà rapide, mais l'IA évolue encore plus vite, et je devais apprendre simultanément une nouvelle entreprise et un nouvel environnement de travail. Je ne suis pas ingénieur, la dernière fois que j'ai ouvert un terminal remonte à un cours d'informatique à l'université. Autrement dit, je devais à la fois combler le contexte organisationnel et m'adapter à de nouvelles méthodes de travail avec l'IA, ces deux choses se superposant pour amplifier la difficulté.
Ce qui m'a finalement sorti de cette pression, ce n'est pas la réalisation d'un article spécifique, d'un lancement produit ou d'un flux de travail particulier, mais le fait de considérer le « contexte » lui-même comme un livrable. Tant que la couche de contexte est correctement construite, tout le travail ultérieur devient moins coûteux.
J'ai donc commencé à construire quelque chose de réellement évolutif : un système qui, comme un bon wiki aide un chercheur, m'aide à me mettre à niveau rapidement. À la troisième semaine, il pouvait déjà rédiger des contenus à partir de mes notes ; à la huitième semaine, il pouvait résumer des réunions auxquelles je n'avais pas assisté. L'apprentissage et la mise à niveau n'ont pas disparu, mais au fur et à mesure que le système se remplissait, leur coût a commencé à diminuer jour après jour.
La version personnelle de cette idée existe depuis un moment. L'ancien responsable de l'IA chez Tesla et cofondateur d'OpenAI, Karpathy, a écrit un article en avril décrivant ce qu'il appelle une « base de connaissances LLM personnelle » : un dossier contenant les entrées brutes, articles, transcriptions et notes personnelles ; un LLM générant un wiki à partir de ces matériaux ; et un éditeur comme Obsidian comme interface. Lorsque la matière atteint environ 100 articles, le LLM peut répondre à des questions complexes en s'appuyant sur le corpus personnel, sans avoir besoin de techniques de recherche complexes.
Son jugement était : il y a là une opportunité pour un produit vraiment excellent, et non pour un assemblage de scripts temporaires.
La version personnelle existe aujourd'hui. Mais la version entreprise, elle, n'existe pas encore. C'est précisément le problème.
En gros, voici le genre de système que j'ai construit durant mes 100 premiers jours. Ils ne sont pas encore parfaits, mais ensemble, ils constituent le « tissu conjonctif » au sein de l'organisation.
Le cœur est un coffre Obsidian, lu et écrit par Claude. Les transcriptions de réunions, documents, points de vue publics et notes personnelles que je rencontre entrent dans cette base de connaissances. Quand je demande « Qu'est-ce que Geoff et moi avons décidé à propos de la page d'accueil il y a trois semaines ? », il cherche la réponse dans ce coffre, plutôt que de s'appuyer sur la mémoire généralisée du modèle lui-même.
Pour alimenter continuellement ce coffre, Granola enregistre par défaut chaque réunion et archive les transcriptions pendant la nuit. Ainsi, une réunion manquée le lundi peut être interrogée le mercredi. Pour permettre au reste de l'entreprise de suivre, j'ai choisi de travailler ouvertement – la plupart de ce que je construis apparaît d'abord dans #team-pmm ou les canaux de projets de lancement concernés, avant d'entrer dans les documents Notion. Le processus de construction lui-même est un mécanisme de synchronisation.
Au-dessus de ce coffre, il y a une petite bibliothèque de compétences nommées, que les agents peuvent appeler à la demande. Une compétence peut générer un ordre du jour basé sur mes quatre dernières réunions avec une personne donnée ; une autre peut scanner les dynamiques produit de la semaine sur Slack et les transformer en idées d'articles. Chaque compétence fait environ 200 lignes de markdown, remplaçant un type de travail qui nécessitait auparavant une intervention manuelle.
De plus, j'ai construit une feuille de route produit dynamique basée sur la plateforme d'applications internes de Ramp. Elle lit la même couche de contexte, donc elle ne devient pas obsolète, car elle n'a jamais été un document statique dès le départ. Il y a aussi un résumé matinal qui m'est envoyé en message privé Slack chaque jour à 8h : ce qui a été lancé hier, ce qui est bloqué, ce qui nécessite ma réponse. Tout cela a été organisé pendant mon sommeil.
Pris isolément, ces éléments ne sont pas impressionnants. Mais ensemble, ils fournissent une réponse fonctionnelle : à quoi ressemblerait le wiki dont parle Karpathy s'il appartenait à une entreprise ?
Vous pouvez l'appeler wiki, graphe, couche de contexte, ou cerveau de l'entreprise. Le nom n'a pas d'importance, la fonction si. Il doit pouvoir absorber tous les signaux déjà produits par l'entreprise : réunions, discussions Slack, documents, code, transcriptions, appels clients et décisions clés, et rester à jour continuellement sans dépendre d'une maintenance manuelle. Il doit aussi être la première chose que chaque nouvel employé, chaque nouvel agent, lit avant de commencer à travailler.
Si un nouvel employé arrivait demain, que devrait-il lire le premier jour ? Si la vraie réponse est un document Notion de 2024, plus un lien Confluence qui ne fonctionne plus, c'est essentiellement lui demander de prendre le relais à l'arrêt.
Des outils ponctuels au cerveau d'entreprise, le véritable fossé de l'IA
Aujourd'hui, la principale façon dont l'IA entre dans les entreprises repose toujours sur des ingénieurs déployés sur site. Qu'il s'agisse d'OpenAI, d'Anthropic ou des grands cabinets de conseil, ils choisissent de construire des flux de travail spécifiques au-dessus des modèles.
Ce travail est réel et a de la valeur. Mais il reste à l'ère des « chatbots » de l'IA en entreprise : des outils étroits encapsulés autour de tâches spécifiques, utiles individuellement, mais non connectés à un système capable de générer des intérêts composés de manière continue.
Le véritable « cerveau d'entreprise » n'existe pas encore. L'agent de support client et l'agent d'onboarding RH ont probablement été construits à des mois d'intervalle par des équipes différentes. Ils ne savent pas ce qui a été décidé lors de la dernière réunion générale, ils ne savent pas comment l'entreprise comprend son marché, ni quel jugement le responsable des ventes a émis lors du dernier offsite de la direction. Chaque agent n'est qu'un chatbot avec des responsabilités spécifiques, mais ils ne partagent pas le même cerveau.
C'est le plus grand fossé actuel. Et en dehors des laboratoires, très peu de gens construisent des produits autour de ce problème.
Si en 2026 vous devez former une équipe ou fonder une entreprise, l'ordre des opérations est différent de celui de 2022. Écrivez d'abord le fichier de contexte, puis installez les outils. Enregistrez chaque réunion. Construisez d'abord le wiki, puis le tableau de bord. Livrez des compétences, pas des diapositives. Faites lire le wiki aux nouveaux employés le premier jour, et faites-leur contribuer dès le deuxième. Recrutez et promouvez ceux qui font fonctionner le « cerveau de l'entreprise » en continu, et réutilisez les agents qui lisent vraiment le cerveau de l'entreprise.
Le contexte n'est pas un projet secondaire. C'est l'infrastructure qui permet à tous les investissements en IA de porter réellement leurs fruits.
Je suis en train de construire une partie de cela chez Ramp : le wiki, la bibliothèque de compétences, les applications lisant la même couche de contexte, et les mécanismes organisationnels pour l'alimenter continuellement. C'est encore petit et précoce. Si vous essayez aussi de construire une version au niveau de l'entreprise ailleurs, j'aimerais échanger sur l'expérience. Plus utile qu'un cerveau digne de confiance, c'est deux cerveaux dans la même pièce.
Revenons à la course de relais. La condition réelle de la victoire n'est ni la transmission la plus propre, ni le relais le plus rapide, mais les deux se produisant simultanément dans la même zone de 20 mètres.
Le nouvel employé lit le cerveau de l'entreprise, puis commence à sprinter. Le nouvel agent lit le cerveau de l'entreprise, puis commence à travailler. Le nouveau client se connecte au cerveau de l'entreprise, puis entre en état de fonctionnement dès le premier jour.
Lorsque le terme « montée en puissance » n'a plus de sens, nous saurons que nous avons réussi.
