Pendant deux décennies, le schéma de distribution dominant pour l'infrastructure de développement a été à peu près le même : installer le SDK, faire atterrir votre produit dans une équipe et l'étendre à partir de là. Le goulot d'étranglement a toujours été la bande passante desdéveloppeurs - convaincreun développeur d'ajouter une dépendance, de configurer les informations d'identification et d'instrumenter le premier appel d'API.

Les outils de codage de l'IA, tels que Cursor et Claude Code, éliminent ce goulot d'étranglement. Quatre pour cent de tous les commentaires publics sur GitHub sont aujourd'hui rédigés par l'IA, et ce chiffre augmente rapidement. Pour les entreprises d'infrastructure de développement, cela signifie qu'il faut adapter votre produit aux agents de codage de l'IA, non pas comme un avantage, mais comme une nécessité concurrentielle.

L'ancien modèle de distribution

Les meilleures entreprises d'outils de développement ont toujours compris que la distribution n'est pas un problème de vente, mais un problème de friction. Réduisez les frictions lors de l'installation et l'adoption suivra. Pensez à l'intégration en sept lignes de Stripe, au démarrage rapide par copier-coller de Twilio ou à l'installation de l'agent en une seule commande de Datadog. L'ensemble du cahier des charges de PLG a été optimisé autour de la même idée : Rendez les cinq premières minutes magiques et le bouche-à-oreille fera le reste.

Mais PLG n'a jamais résolu le deuxième problème de distribution : l'expansion à l'intérieur de l'organisation. L'installation du SDK est la première étape. L'instrumentation correcte de chaque service, de chaque fonctionnalité et de chaque équipe est le travail continu et peu glorieux qui détermine si un outil délivre la valeur promise ou s'il reste à 20% pour l'éternité.

Je (Sudhee) ai vécu ce problème de première main. En tant que chef de produit chez Segment, nos deux défis les plus difficiles à relever étaient étonnamment simples : (i) obtenir le temps et la bande passante des développeurs pour installer analytics.js et instrumenter les événements, et (ii) s'assurer que leur mise en œuvre était réellement efficace (par exemple, savoir quels événements suivre, suivre la bonne syntaxe de l'API) afin que les clients obtiennent une réelle valeur du produit en aval.

La première était purement un problème de bande passante pour les développeurs. Les responsables de projets et les spécialistes du marketing ont dû mendier, emprunter et voler du temps d'ingénierie pour mettre en œuvre le segment. Nous avons résolu ce problème en rendant analytics.js très simple à installer. Le second était un problème de meilleures pratiques, et nous l'avons attaqué de front. Nous avons créé Protocoles, un produit de plan de suivi qui applique la discipline "planifier d'abord, suivre efficacement ensuite". Nous avons même créé Typewriter, un plugin de sécurité de type qui complète automatiquement le code des événements afin que les développeurs n'aient pas à mémoriser le schéma. Il s'agissait d'innovations significatives, et elles ont fonctionné. Mais ils ont nécessité la construction de gammes entières de produits, la création d'équipes d'ingénieurs spécialisés et la poursuite d'investissements soutenus, simplement pour combler le fossé entre "puits installé" et "puits instrumenté".

C'est là tout le problème : Même une entreprise comme Segment, qui a fait de la résolution de ce problème une priorité stratégique, a dû investir énormément pour y parvenir. D'après nos observations, la plupart des fabricants d'outils de développement ne le font jamais. Leurs outils se contentent d'une couverture partielle, non pas parce qu'ils manquent de capacités, mais parce que les humains manquent de cohérence. En tant que tels, ils ne sont jamais à la hauteur de leur valeur potentielle.

Ce qui change avec le développement agentique

Les agents de codage IA tels que Claude Code, Cursor, Codex, etc. deviennent rapidement l'interface principale par laquelle les développeurs écrivent et modifient le code. Il ne s'agit pas d'un changement marginal. Lorsque le flux de travail par défaut d'un développeur est "décrire ce que je veux, examiner le code", l'agent d'intelligence artificielle devient un intermédiaire puissant entre l'intention du développeur et la base de code.

Cet intermédiaire est programmable.

Avec des agents tels que Cursor et Claude Code, le premier défi lié à la bande passante des développeurs disparaît effectivement. L'IA écrit le code ; "nous ne pouvons pas obtenir de cycles d'ingénierie" n'est plus une excuse valable . La véritable impasse est donc de savoir si vous pouvez enseigner à l'agent ce que sait le meilleur ingénieur en solutions de votre entreprise. Peut-il comprendre suffisamment bien le secteur d'activité, le PCI, les objectifs et les résultats de votre client pour utiliser correctement le SDK dans l'ensemble de l'application ?

Si c'est le cas, vous disposez d'un ingénieur en solutions 10x pour chaque compte client, un ingénieur qui travaille sur chaque RP, qui ne part jamais en vacances et qui n'oublie jamais la convention de dénomination.

Les compétences des agents rendent cela possible. Il s'agit de petits paquets de contexte installables qui enseignent à un agent de codage IA le fonctionnement de votre outil, les modèles à suivre et les erreurs à éviter. Une seule commande, et chaque interaction de l'agent avec une base de code est porteuse d'une connaissance approfondie de votre SDK.

Il s'agit d'une surface de distribution fondamentalement différente de tout ce qui existait auparavant.

Pourquoi cela se complique-t-il au sein des organisations ?

La valeur de nombreux produits d'infrastructure augmente avec leur couverture, et celle-ci a toujours été limitée par la mémoire et la discipline des développeurs, et non par leurs capacités techniques. Les compétences brisent la porte.

Envisagez des outils d'observabilité. OpenTelemetry est utilisé à des taux élevés dans les métriques, les journaux et les traces. Mais la valeur d'OTel s'échelonne en fonction de la couverture : Plus votre pile est instrumentée, plus vos traces sont cohérentes, plus votre débogage est utile. La couverture exige que chaque développeur, pour chaque nouveau service, pour chaque nouveau point de terminaison, se souvienne d'ajouter des portées, de propager le contexte, d'attacher les bons attributs et de configurer le bon exportateur. Ce n'est pas un problème technique. Il s'agit d'un problème de mémoire humaine.

Une compétence OTel bien conçue modifie la situation par défaut. L'agent sait que chaque fois qu'un nouveau gestionnaire HTTP est écrit, il doit l'instrumenter. Chaque fois qu'un appel à la base de données est ajouté, enveloppez-le. Chaque fois qu'une limite de service est franchie, propagez le contexte. Le développeur n'a pas à s'en souvenir. L'agent le fait.

L'enjeu va au-delà des mesures d'adoption. Pour les nombreux produits d'infrastructure de développement dont le prix dépend de l'utilisation, comme le volume de l'étendue, les événements suivis, les utilisateurs actifs mensuels et les exécutions de flux de travail, l'étendue de la couverture est directement liée aux recettes. Un compte avec 20% d'instruments génère environ 20% de sa facturation potentielle. Les compétences comblent ce fossé sans un seul nouveau logo. Chaque RP que l'agent met en œuvre est une augmentation de l'ARR qui nécessitait auparavant une action commerciale pour être débloquée.

La même logique s'applique à toutes les catégories :

Analyse des produits (Pendo*, Segment, Amplitude*). L'installation est triviale. La valeur vient de l'étiquetage de chaque interaction significative de l'utilisateur avec les bons noms d'événements, les propriétés et le contexte de l'utilisateur ; c'est une tâche d'instrumentation sans fin répartie entre tous les développeurs frontaux. Une compétence qui comprend la taxonomie des événements de l'organisation transforme une couverture sporadique en une couverture complète. L'étiquetage sporadique maintient les clients dans un niveau d'événement inférieur ; les compétences permettent d'augmenter automatiquement les ventes.

Drapeaux de fonctionnalités (LaunchDarkly, Statsig). Chaque nouvelle fonctionnalité devrait être enveloppée dans un drapeau. Dans la pratique, un tiers d'entre eux le sont, car cela ajoute des frictions. Une compétence qui applique la règle "nouvelle fonctionnalité = drapeau par défaut" et qui connaît les conventions de dénomination de l'organisation ne se contente pas d'améliorer l'adoption, elle modifie le comportement de l'ingénierie à la marge, en faisant de la bonne chose la chose la plus facile.

SDK d'authentification (Auth0, Descope). Chaque nouvelle route, point d'arrivée de l'API ou flux d'utilisateurs doit faire l'objet d'une vérification d'identité, d'une validation correcte des jetons, d'une gestion des sessions et d'une logique de déconnexion. Dans la pratique, les développeurs prennent des raccourcis sous la pression de la vitesse. Une compétence qui impose que "chaque nouveau point de terminaison valide l'identité avant d'être exécuté" et qui connaît les modèles de SDK préférés de l'organisation transforme l'authentification d'une étape dont les développeurs se souviennent de manière incohérente en une valeur par défaut qui s'applique partout.

SDK d'autorisation (Styra*, Permit.io, Oso). La logique d'autorisation est l'un des modèles les plus incohérents dans une base de code. Une compétence qui comprend le modèle d'autorisation de l'organisation et qui câble automatiquement l'autorisation à chaque nouveau point de terminaison améliore à la fois la posture de sécurité et l'adoption du SDK.

Sécurité des applications en cours d'exécution (Contrast Security*, Arcjet). Les outils RASP sont confrontés au même piège de la couverture partielle, avec des conséquences plus asymétriques. Un point d'instrumentation manqué n'est pas une lacune dans les rapports, mais une surface d'attaque non protégée. Une compétence qui applique par défaut des crochets de protection à chaque nouvelle route transforme le RASP d'un périmètre partiel en un véritable tissu d'exécution. La sécurité est une catégorie où la réponse "le développeur a oublié" est inacceptable.

Gestion des secrets (HashiCorp Vault, Hush*). Chaque nouvelle chaîne de connexion à une base de données, clé d'API ou identifiant représente un moment où un développeur pourrait la coder en dur au lieu de la puiser dans le magasin de secrets de l'organisation. Une compétence qui intercepte ces moments en signalant os.environ['STRIPE_KEY'] et en le remplaçant par hush.get('stripe_key'). renforce l'hygiène au point exact de défaillance. Le mode de défaillance est invisible lors de l'examen du code : un secret codé en dur ressemble à du code normal. L'agent saisit ce qu'un réviseur humain ne verrait pas.

Cadres de test (Playwright, Testcontainers, Cypress*). Les outils de test ne sont pas difficiles à installer, mais il est difficile de les maintenir à jour. La couverture dérive non pas parce que les développeurs n'accordent pas d'importance aux tests, mais parce que l'écriture de ces derniers est la première chose que l'on réduit sous la pression de la vitesse. Une compétence qui génère des tests cohérents avec le cadre de travail à côté de chaque nouvelle fonction ou composant change la sortie par défaut de l'agent de "voici votre fonction" à "voici votre fonction et ses tests".

Moteurs de flux de travail durables (Orkes*, DBOS, Temporal). Ces outils ont des courbes d'apprentissage abruptes, comme les API à opinion, les exigences subtiles de correction autour du déterminisme, les modèles spécifiques pour les tentatives et les échecs. Une compétence qui encode tout ce contexte garantit que le dixième développeur qui touche à la couche de flux de travail utilise les mêmes modèles que le premier.

La preuve est déjà faite

Pensez à ce qui s'est passé avec Neon, l'entreprise Postgres sans serveur. Neon a beaucoup investi dans la distribution d'agents natifs en publiant sur GitHub des règles d'IA, des plugins Claude Code, des intégrations Cursor et une bibliothèque complète de compétences d'agents. Résultat : plus de 80% des bases de données approvisionnées sur Neon ont été créées par des agents d'intelligence artificielle, et non par des humains. Cette statistique était si frappante qu'elle est devenue une pièce maîtresse de la justification de Databricks*pour l'acquisition de Neon pour 1 milliard de dollars en 2025. Neon ne s'est pas contenté de créer une base de données ; il s'est intégré dans le flux de travail par défaut de l'agent et cet avantage en termes de distribution s'est avéré digne d'une sortie d'un milliard de dollars.

Le changement stratégique

Les compétences changent, c'est là que se construit l'avantage concurrentiel. Aujourd'hui, les gagnants des outils de développement sont souvent ceux qui réussissent l'installation initiale, comme l'entreprise qui gagne les cinq premières minutes. Si les compétences deviennent la surface d'adoption dominante, la victoire revient à celui qui s'intègre le plus profondément et le plus correctement dans le contexte de l'agent. Cela récompense un ensemble différent de capacités : la qualité et l'exhaustivité de vos compétences, la confiance que les développeurs accordent aux recommandations de votre couche d'agents et la rapidité avec laquelle vous mettez à jour vos compétences au fur et à mesure de l'évolution de votre API.

Cela a une incidence importante sur les relations avec les développeurs et les investissements en matière de documentation. La meilleure documentation SDK a toujours été une forme de distribution : Faites en sorte qu'il soit facile de comprendre comment utiliser correctement l'outil, et l'adoption suivra. Les compétences sont de la documentation qui s'exécute. Les entreprises qui investissent aujourd'hui dans la création de compétences de haute qualité, validées par des opinions et bien entretenues, préchargent leur courbe d'adoption dans chaque flux de travail des développeurs assistés par des agents.

Les compétences servent également de canal de découverte au sein des organisations. Lorsqu'un nouveau développeur rejoint une équipe et commence à travailler avec un agent de codage IA, l'agent ne part pas de zéro, il suggère plutôt les outils et les modèles que le reste de l'organisation utilise déjà. Au lieu que le nouveau développeur cherche des alternatives, la compétence se superpose au choix existant. C'est ainsi que les outils se répandent de manière virale au sein des organisations dans un monde agentique - non pas par le biais de recommandations Slack ou de pages wiki, mais par le biais du contexte de l'agent.

Ce que cela signifie pour les constructeurs et les investisseurs

Pour les fondateurs qui mettent en place une infrastructure de développement, la compétence est désormais un artefact de produit de premier ordre, et non plus une réflexion après coup sur la documentation. La question à se poser n'est pas seulement "comment faciliter la première installation", mais "comment faciliter toutes les décisions ultérieures en matière d'instrumentation, pour chaque développeur, pour toujours ". La réponse est une compétence qui connaît votre API aussi bien que votre meilleur ingénieur en solutions.

Les investisseurs qui évaluent les sociétés de développement d'outils doivent savoir que les douves de distribution sont en train d'être reconstruites. Une entreprise avec un mouvement PLG médiocre mais une compétence exceptionnelle intégrée dans chaque contexte d'agent pour les comptes d'entreprise peut avoir un moteur d'expansion plus puissant qu'une entreprise avec un beau démarrage rapide et une présence superficielle de la couche d'agents. Les paramètres à surveiller évoluent ; la profondeur de la couverture à l'intérieur des comptes, et pas seulement le nombre de sièges, est de plus en plus un indicateur de valeur durable.

Les compétences répondent également à deux lacunes de couverture que PLG n'a jamais abordées : la mise à niveau des bases de code existantes, où les agents peuvent systématiquement refactoriser le code existant non instrumenté pour répondre aux normes actuelles sans un sprint d'ingénierie dédié, et les flux de travail DevOps, où l'infrastructure en tant que code, les pipelines CI/CD et les scripts de déploiement bénéficient de la même logique de renforcement des modèles que celle qui s'applique au code de l'application.

La première vague de PLG visait à éliminer les frictions lors de l'installation. La deuxième vague consiste à supprimer les frictions à chaque engagement, pour toujours. Les entreprises qui se préparent dès maintenant à la deuxième vague seront très bien positionnées dans trois ans. La question qui mérite d'être posée aujourd'hui, que vous soyez un fondateur qui met en place une infrastructure de développement ou un investisseur qui l'évalue, est simple : Quelle est votre stratégie en matière de compétences des agents de codage de l'IA, et quand est-elle mise en œuvre ?