Hier après-midi, un ingénieur de notre équipe a regardé Anthropic présenter sa stack GTM interne sur la scène de SaaStr, a fait une capture de la diapositive et a posé une seule question à Zero : lesquels nous manquent ? Six heures et dix-neuf minutes plus tard, Snowflake était en production pour tous les clients de Zero. C'était la 180-et-quelques intégration livrée en un an et, de plus en plus, la personne qui écrit la suivante n'est pas du tout un ingénieur. Voici le framework, et la compétence interne qui vient par-dessus, qui rendent cela possible.
Ce que personne ne vous dit sur les plateformes d'agents
Un LLM est un cerveau dans un bocal. Seul, il peut vous écrire un poème sur votre entrepôt de données, mais il ne peut pas réellement l'ouvrir. Ce qui transforme un chatbot en agent, ce pour quoi votre équipe paie vraiment, c'est la capacité de l'agent à atteindre les outils que vous utilisez déjà et à y faire du travail.
Nous appelons cette portée la couche de connecteurs. Après un an à construire Zero, nous pensons que c'est la brique d'infrastructure la plus importante d'un produit d'agents. Nous avons donc construit la nôtre. Plus important encore, nous avons construit autour d'elle un workflow qui permet à n'importe qui dans l'équipe d'en écrire un.
Pourquoi pas MCP. Pourquoi pas Zapier.
On nous a posé les deux questions très tôt. Les deux sont bons pour ce qu'ils sont. Aucun n'était ce dont nous avions besoin.
MCP est un protocole, pas un produit. Excellent pour les auteurs d'outils qui veulent que leur service soit accessible à n'importe quel LLM. Mais les serveurs MCP, tels qu'ils sont déployés aujourd'hui, remettent au modèle une liste d'outils en lui faisant confiance pour les appeler correctement. Il n'y a pas de coffre-fort d'identifiants par organisation, pas de pare-feu sur les points de terminaison joignables, pas de journal d'audit reliant un appel à un humain qui l'a autorisé. Pour un produit où un agent peut toucher le Stripe de production d'un client et un autre rédiger un e-mail dans la Gmail de son PDG, « faire confiance au modèle » n'est pas un modèle de sécurité.
Les plateformes d'intégration à la Zapier résolvent un autre problème : elles relient des déclencheurs déterministes à des actions déterministes. Les agents ne fonctionnent pas comme ça. Un agent décide, en cours de raisonnement, que l'étape suivante est d'interroger Snowflake puis d'écrire un ticket Linear. Il lui faut un identifiant, un client HTTP à portée limitée et une piste d'audit maintenant, pas sous forme de recette pré-construite.
Nous avons donc construit la chose ennuyeuse : un registre d'intégrations où chaque entrée porte des métadonnées d'authentification, une cartographie des secrets injectés dans le sandbox, un pare-feu d'hôtes autorisés et un petit gestionnaire pour les particularités d'OAuth ou de jetons. Voilà l'infrastructure.
Mais l'infrastructure n'est pas la partie intéressante de l'histoire. La partie intéressante est ce qui s'est passé par-dessus.
La compétence qui a fait de chacun un auteur de connecteurs
Un nouveau SaaS atterrit dans notre backlog d'intégrations environ deux fois par jour. Certains viennent de demandes clients. D'autres d'un coéquipier qui remarque que Zero ne sait pas faire quelque chose dont il a besoin. D'autres encore d'une conversation commerciale où la stack d'un prospect inclut un outil que nous ne connaissons pas encore.
Si chacun devait passer par la file d'attente d'un ingénieur, nous en livrerions un par semaine. Nous en livrons un par jour.
La raison est un outil interne que nous appelons la compétence d'écriture de connecteurs. C'est une compétence Zero, de la même forme que celles que nous livrons aux clients, mais tournée vers notre propre base de code. Quand quelqu'un dans l'équipe dit « je veux ajouter le connecteur Notion », Zero l'accompagne :
- Partir du scénario utilisateur. Que veut réellement faire l'utilisateur avec cet outil ? « Interroger une base de données », « créer une page », « chercher dans tout l'espace de travail ». La compétence exige une user story concrète avant qu'un seul fichier ne soit touché. L'objectif d'un connecteur est de rendre possible une capacité de l'agent, pas d'envelopper exhaustivement une API.
- Identifier la forme d'authentification. OAuth, jeton d'API, ou les deux. La compétence sait ce que chaque forme implique : pour OAuth, l'interface de consentement et la plomberie de redirection ; pour les jetons d'API, l'injection de secrets par organisation et l'endroit où l'utilisateur obtient le jeton. L'auteur choisit la forme qui correspond à l'outil ; tout le reste en découle.
- Cartographier les points de terminaison sur le scénario. Pas « envelopper toute l'API REST ». Juste la poignée de points de terminaison qui satisfont la user story. Un connecteur avec trois points de terminaison bien choisis vaut mieux qu'un avec quarante que l'agent n'utilisera jamais.
- Générer les douze fichiers. Entrée de registre, gestionnaire, motif de pare-feu, icône de plateforme, plomberie de cartographie d'environnement, et la compétence côté agent qui apprend à Zero comment utiliser le connecteur. La compétence écrit l'échafaudage ; l'auteur écrit l'intention.
- Ouvrir les deux PR. Une sur le framework de connecteurs, une sur la bibliothèque de compétences. Les deux sont relues par un ingénieur, mais la relecture porte sur la justesse, pas sur l'apprentissage du fonctionnement du framework.
Ce qui exigeait autrefois un savoir institutionnel (quelle forme d'authentification, quels points de terminaison, quels douze fichiers dans quels deux dépôts, comment le motif de pare-feu se compose avec un sous-domaine dynamique) est désormais porté par la compétence elle-même. L'auteur apporte l'empathie utilisateur. La compétence apporte l'échafaudage.
C'est ainsi qu'une designer, un responsable BD ou une PM finit par livrer un connecteur. Ils savent ce que veut l'utilisateur. La compétence sait tout le reste.
L'étude de cas : Snowflake, hier
Hier, Anthropic a présenté sa stack GTM interne sur la scène de SaaStr : Salesforce comme système de référence, Clay pour l'enrichissement, LeanData pour le routage, Gong pour les appels, Jira pour les tickets, Intercom (Fin) pour le support, Ironclad pour les contrats, Snowflake comme entrepôt de données. [lien vers la conférence]
L'un de nos ingénieurs a fait une capture de la diapositive et l'a déposée dans Zero avec une seule question : « pour lesquels nous manque-t-il un connecteur ? »
Voici la chronologie réelle qui a suivi. Toutes les heures en PDT.
16h59. La capture arrive. Zero la compare au catalogue de connecteurs : 7 des 10 existent déjà (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). Trois manquent (Clay, LeanData, Snowflake), et Snowflake est signalé comme le plus précieux, un entrepôt de données étant le socle de la stack GTM. La réponse tombe à 17h00.
17h01. Relance : « lesquels peuvent être faits en connecteur à jeton d'API ? » Zero récupère la documentation d'authentification : Clay a une clé d'API personnelle, Snowflake a récemment livré les Programmatic Access Tokens, LeanData est uniquement OAuth et lié à Salesforce. Verdict à 17h02 : Snowflake d'abord (valeur la plus élevée, authentification la plus propre), puis Clay.
17h04. L'ingénieur dit « go ». La compétence d'écriture de connecteurs prend le relais. À 17h07, elle a écarté Clay (la seule surface publique est constituée de webhooks par table, aucun vrai connecteur à construire) et confirmé la forme de Snowflake : secret SNOWFLAKE_PAT + variable SNOWFLAKE_ACCOUNT, authentification bearer contre l'API REST Snowflake et l'API SQL v2, motif de pare-feu à sous-domaine dynamique calqué sur Zendesk.
17h35. Les deux PR sont ouvertes dans la même minute :
vm0-skills#176: la compétence côté agent. Comment écrire du SQL Snowflake, formater les résultats, réessayer en cas d'erreurs transitoires.vm0#13356: le connecteur lui-même. Entrée de registre, gestionnaire de PAT, générateur de pare-feu, icône de plateforme, plomberie de cartographie d'environnement.
18h22. PR de la compétence fusionnée.
18h42. PR du connecteur fusionnée.
18h52. La PR de release s'ouvre automatiquement.
23h18. web@v12.369.0 et le reste du train de release partent en production. Snowflake est actif pour toutes les organisations.
Six heures et dix-neuf minutes entre « capture de la stack d'Anthropic » et « Zero peut interroger votre entrepôt ». Un ingénieur. Une conversation. Zéro passage de relais à une « équipe connecteurs ».
Le débit ici ne vient pas de la rapidité de l'ingénieur. Il vient du fait que la compétence d'écriture de connecteurs a porté les parties qui exigeaient autrefois un savoir institutionnel : quelle forme d'authentification choisir, quels points de terminaison correspondent au scénario utilisateur, quels douze fichiers doivent atterrir dans quels deux dépôts, comment le motif de pare-feu se compose avec un sous-domaine dynamique. L'auteur a écrit l'intention. La compétence a écrit l'échafaudage. La production a fait le reste.
C'est ce que nous apporte le framework. Pas seulement de la vitesse (même si la vitesse est réelle), mais qui peut prendre le travail en charge. L'auteur de Snowflake se trouvait être un ingénieur. Il n'avait pas à l'être.
Pourquoi le jeton d'API est un citoyen de première classe
Une note en marge qui mérite d'être sortie, parce que c'est un choix de conception délibéré qui a surpris.
La plupart des plateformes d'agents traitent OAuth comme la seule vraie authentification et le jeton d'API comme un repli pour les outils anciens. Nous faisons l'inverse. Les jetons d'API sont des citoyens de première classe dans notre modèle de connecteurs, avec la même interface de consentement, le même coffre-fort par organisation, la même piste d'audit, la même application du pare-feu.
Il y a deux raisons.
La première : l'authentification par jeton d'API a un délai de première utilisation plus court. Snowflake a récemment livré les Programmatic Access Tokens exactement pour cette raison : des identifiants durables, à portée limitée et révocables, qui n'exigent pas de danse OAuth. Un utilisateur muni d'un PAT peut être productif dans Zero en moins d'une minute. Un flux OAuth, même propre, prend plus de temps et demande davantage à l'utilisateur.
La seconde : OAuth n'est pas toujours disponible. Certains outils d'entreprise n'en proposent tout simplement pas, ou en proposent un réservé à une offre entreprise. Traiter le jeton d'API comme un pair (et non comme un repli) nous permet de prendre correctement en charge ces outils au lieu de les laisser dans un cimetière de « bientôt disponible ».
Le connecteur Snowflake livré hier fonctionne au jeton d'API. Le connecteur Gmail qui transporte les fils d'e-mails clients fonctionne en OAuth. Les deux passent par le même framework, la même compétence, la même relecture. L'auteur choisit la forme qui correspond à l'outil, et le framework rend l'une comme l'autre peu coûteuse à construire.
Ce que 180-et-quelques intégrations débloquent vraiment
Le chiffre en lui-même n'est pas le sujet. Le sujet, c'est qu'à cette densité, l'agent cesse d'être un outil que l'on convoque et devient un environnement dans lequel on vit.
Quand Zero dispose de connecteurs vers votre CRM et votre entrepôt de données et votre boîte de support et votre outil de design et votre dépôt, il peut faire des choses qu'aucun agent mono-intégration ne peut faire. Il peut lancer une requête Snowflake, la recouper avec les tickets Linear ouverts, et publier un résumé dans le canal Slack où vit l'équipe customer success. Il peut lire un appel Gong, trouver la fonctionnalité demandée par le prospect, vérifier si elle est dans la roadmap et rédiger l'e-mail de suivi, le tout en un seul mouvement.
Chaque nouveau connecteur n'ajoute pas de la valeur linéairement. Il en ajoute de façon combinatoire. Le 180e connecteur a plus de valeur que le 1er, parce qu'il se compose avec les 179 qui l'ont précédé.
C'est le pari derrière le framework. Et le pari derrière la compétence, c'est que la vitesse de ce cumul dépend du nombre de personnes de votre équipe autorisées à alimenter la pile.
La suite
Nous travaillons à ouvrir la compétence d'écriture de connecteurs aux clients. Si vous faites tourner Zero pour votre équipe et qu'il vous faut une intégration vers un outil interne (votre système de facturation, votre entrepôt, votre panneau d'administration interne sur mesure), le workflow qui a livré Snowflake hier sera celui que vous utiliserez pour livrer le vôtre. Même échafaudage, même modèle d'authentification, même pare-feu, même piste d'audit. Auteur différent.
Si cela vous intéresse, nous serions ravis d'en parler.
