Il y a en ce moment même, quelque part, une personne qui intègre votre API. Elle n'est pas sur votre site de documentation. Elle n'a pas ouvert votre guide de démarrage. Elle n'a jamais vu votre aire de jeu interactive ou votre barre de navigation latérale soigneusement conçue.
Ils sont assis dans Claude. Ou Copilote. Ou Cursor. Ils ont tapé quelque chose comme "intégrer l'API de facturation Stripe à mon application Next.js en utilisant le routeur d'application" et ont attendu que le code fonctionnel revienne. L'IA a lu votre documentation en leur nom. Elle a trouvé les points de terminaison pertinents, compris le flux d'authentification, choisi les bonnes méthodes SDK et produit une implémentation.
Il y a deux semaines, lors du Start Summit Hackathon à Saint-Gall, j'ai vu ce processus se dérouler en temps réel. Je discutais avec un groupe d'étudiants en informatique et deux fondateurs de startups en phase de démarrage de la manière dont ils abordaient les nouvelles API, et chacun d'entre eux a décrit le même flux de travail : coller le problème dans une IA, obtenir du code en retour, itérer à partir de là. L'une des étudiantes a ri lorsque je lui ai demandé si elle avait lu la documentation. "Pourquoi le ferais-je ? Claude les lit pour moi".
Cette personne n'a jamais visité votre site. Elle ne visitera peut-être jamais votre site. Et c'est de plus en plus souvent ainsi que les logiciels sont construits.
Le changement fondamental
La documentation a désormais deux consommateurs fondamentalement différents : les humains qui la lisent et les assistants d'intelligence artificielle qui la lisent pour le compte des concepteurs. La plupart des documents sont optimisés exclusivement pour les humains. L'IA est déjà le lecteur dominant.
Cela change tout en aval :
- La fraîcheur est désormais un problème de fiabilité Lorsqu'une IA sert un contenu périmé, le constructeur n'a aucun moyen de détecter le problème. Les dommages s'étendent silencieusement.
- Le mot "développeur" est trop étroit.** Les chefs de produit, les concepteurs et les analystes livrent des logiciels par l'intermédiaire d'assistants d'IA, souvent sans jamais avoir lu une ligne de documentation eux-mêmes.
- La structure lisible par la machine est plus importante que la conception visuelle.** Un markdown propre, des blocs autonomes et des métadonnées explicites sont ce qui permet à l'IA de représenter votre produit avec précision.
- Les exigences en matière de format se sont scindées.** Les lecteurs humains ont besoin de textes narratifs. Les intermédiaires de l'IA ont besoin de spécifications structurées et analysables. Vous devez servir les deux.
Le reste de ce billet explique comment nous en sommes arrivés là, ce que cela signifie pour DevRel et ce que vous pouvez faire dès maintenant.
Le voyage que personne n'avait prévu
Pendant longtemps, les relations avec les développeurs ont suivi un chemin bien compris. Vous écriviez une documentation complète. Vous avez publié des guides de démarrage rapide. Vous donniez des conférences. Vous mainteniez une présence sur Stack Overflow. Vous faisiez en sorte que les références de vos API soient consultables, que vos SDK soient idiomatiques et que vos messages d'erreur soient utiles.
Ce chemin supposait que le développeur lise votre contenu. Naviguez dans votre structure. Suivre vos étapes.
[L'enquête 2024 de GitHub auprès des développeurs (https://github.blog/news-insights/research/survey-ai-wave-grows/) a révélé que 97 % des développeurs d'entreprise ont utilisé des outils de codage d'IA à un moment ou à un autre. [L'enquête annuelle de Stack Overflow (https://survey.stackoverflow.co/2024/) a montré que 76 % de tous les développeurs utilisent ou prévoient d'utiliser des outils d'IA, et que 62 % des professionnels les utilisent activement au quotidien. En 2026, ce chiffre [est passé à 84 %] (https://www.index.dev/blog/developer-productivity-statistics-with-ai-tools), 41 % du code étant désormais généré par l'IA et 51 % des développeurs professionnels utilisant quotidiennement des outils d'IA. Ces chiffres ne ralentissent pas.
Le nouveau voyage se présente différemment. Une personne décrit ce qu'elle veut en langage naturel. Un assistant IA lit la documentation, trouve les sections pertinentes et génère l'intégration. Le constructeur examine le résultat, affine peut-être l'invite, demande peut-être un suivi. Quelques minutes, pas des heures.
L'entonnoir de démarrage que les équipes DevRel ont mis des années à perfectionner ? Il est en train d'être contourné. Non pas parce qu'il était mauvais. Le point d'entrée s'est simplement déplacé.
Deux consommateurs, un ensemble de documents
La documentation a désormais deux publics fondamentalement différents.
Le premier est le lecteur humain. Cette personne existe toujours. Elle se présente pour les décisions d'architecture, le débogage des cas extrêmes, l'examen de la conformité et la compréhension conceptuelle. Ils veulent des explications narratives, des documents de référence bien organisés et un raisonnement clair sur les compromis.
Le second est l'intermédiaire en IA. Il lit votre documentation pour le compte d'un constructeur. Il ne s'intéresse pas à votre barre latérale. Il n'apprécie pas votre conception visuelle. Il a besoin d'un contenu structuré et analysable par la machine : un code à barres propre, un formatage cohérent, des spécifications explicites sur lesquelles il peut raisonner sans ambiguïté.
Aujourd'hui, presque tous les sites de documentation sont optimisés exclusivement pour le premier public. Le deuxième public est déjà le consommateur dominant.
Jeremy Howard a identifié cette tension lorsqu'il a [proposé la norme /llms.txt] (https://llmstxt.org/) en 2024. Son observation était précise : Les grands modèles de langage s'appuient de plus en plus sur les informations des sites web, mais ils sont confrontés à une limitation critique : les fenêtres contextuelles sont trop petites pour traiter la plupart des sites web dans leur intégralité. Un fichier markdown curaté à /llms.txt qui donne aux modèles d'IA une vue d'ensemble structurée de votre produit et des liens vers les ressources les plus importantes. FastHTML, les propres documents d'Anthropic et un [répertoire croissant de projets] (https://llmstxt.site/) en fournissent déjà un.
C'est une convention utile. Mais c'est aussi le symptôme d'un problème plus profond. Le véritable problème n'est pas le format. C'est que la plupart des documentations n'ont jamais été conçues dans l'optique d'une utilisation par les machines.
Le constructeur ne prend pas de pincettes
Il est tentant de regarder la personne qui invite Claude au lieu de lire la documentation et d'en conclure qu'elle prend des raccourcis. Qu'elle ne comprend pas vraiment ce qui se passe dans le code. Qu'il s'agit en quelque sorte d'un développeur de moindre qualité.
J'ai eu cette conversation suffisamment de fois pour savoir que c'est généralement faux.
Beaucoup de ces développeurs sont des ingénieurs chevronnés qui font des choix délibérés en matière d'efficacité. Ils comprennent le code, mais ne veulent pas naviguer dans quatre pages de documentation pour trouver les trois lignes dont ils ont réellement besoin. Ils ont appris qu'un assistant IA peut extraire ces lignes plus rapidement qu'ils ne peuvent les rechercher, alors ils délèguent la lecture. (Honnêtement, c'est ce que je fais moi-même. Je ne me souviens pas de la dernière fois où j'ai lu un guide de démarrage du début à la fin).
Anthropic a reconnu ce modèle lorsqu'il a créé le [Model Context Protocol] (https://modelcontextprotocol.io/introduction). Le MCP est maintenant supporté par Claude, ChatGPT, VS Code, Cursor, et d'autres. Il est explicitement conçu pour que les assistants d'intelligence artificielle puissent accéder à des systèmes externes, en extraire le contexte et agir en conséquence. La spécification le décrit comme fournissant "l'accès à un écosystème de sources de données, d'outils et d'applications qui renforceront les capacités et amélioreront l'expérience de l'utilisateur final".
Lisez attentivement. Il s'agit d'un langage d'infrastructure, pas d'un langage de commodité. Les concepteurs qui utilisent ces outils n'évitent pas le travail. Ils travaillent à travers une nouvelle couche, et votre documentation fait partie de cette couche, que vous l'ayez conçue ou non.
Les chiffres le confirment. À lui seul, Claude gère aujourd'hui [25 milliards d'appels d'API par mois] (https://www.incremys.com/en/resources/blog/claude-statistics), avec 30 millions d'utilisateurs actifs mensuels dans 159 pays. [70 % des entreprises du Fortune 100 (https://www.incremys.com/en/resources/blog/claude-statistics) utilisent Claude. Selon une étude de Menlo Ventures, Anthropic détient [32 % des parts de marché de l'IA d'entreprise en termes d'utilisation de modèles] (https://fortune.com/2025/12/02/how-anthropics-safety-first-approach-won-over-big-business-and-how-its-own-engineers-are-using-its-claude-ai/), devant OpenAI (25 %). Un rapport de recherche de HSBC va encore plus loin : 40 % des dépenses totales en matière d'IA. Il ne s'agit pas d'outils expérimentaux. Il s'agit d'une infrastructure primaire.
Les relations avec les développeurs ont été conçues pour une autre époque
Si votre stratégie DevRel a été conçue avant 2023, elle l'a été pour un monde où les développeurs lisaient directement les documents. Ce monde n'a pas disparu, mais ce n'est plus le modèle d'interaction dominant pour une part croissante des développeurs.
Cela modifie le calcul de plusieurs activités DevRel de longue date.
**Une présentation de 45 minutes lors d'une conférence de développeurs s'adresse à une salle de quelques centaines de personnes. Un fichier /llms.txt bien structuré et une documentation propre et lisible par une machine atteignent chaque développeur qui interroge un assistant IA sur votre produit, en permanence, à tout moment. L'exposé est un événement unique. La documentation lisible par machine se compose. Je ne dis pas que les conférences ne valent rien (je reviens littéralement d'une conférence), mais l'équation de l'effet de levier a changé.
**Les guides de démarrage **Le tutoriel classique de démarrage rapide en cinq étapes est de plus en plus une formalité. Le constructeur ne suit pas les étapes. Il décrit ce qu'il veut et attend de l'IA qu'elle réalise l'intégration. Si l'API est bien documentée dans un format convivial pour les machines, l'IA gère l'expérience de démarrage plus efficacement que n'importe quel tutoriel. Ce que les didacticiels devraient plutôt devenir, c'est du matériel conceptuel : expliquer pourquoi vous choisissez l'approche A plutôt que l'approche B. L'IA peut générer la mise en œuvre. Elle est beaucoup moins fiable pour expliquer les compromis.
**Les données de leur propre enquête ont montré que [84 % des développeurs] (https://survey.stackoverflow.co/2024/) utilisent directement la documentation technique, 90 % d'entre eux s'appuyant sur les documents contenus dans les API et les kits de développement logiciel (SDK). Mais la façon dont ils accèdent à ces documents passe de plus en plus par une couche d'IA, et non par un onglet de navigateur. Les questions qui parviennent encore à Stack Overflow ont tendance à être les plus difficiles. Les cas limites, le débogage en production, les choses qui requièrent de la nuance. Précieuses, certes. Mais ce n'est plus là que se trouve le volume.
Quand l'IA lit vos documents, la fraîcheur devient essentielle
Voici la partie à laquelle la plupart des équipes n'ont pas réfléchi.
Lorsqu'un humain lit une page de documentation, il peut faire preuve de discernement. Il peut remarquer que les captures d'écran sont anciennes ou qu'un commentaire en bas de page indique que le processus a changé. Il peut plisser les yeux et se dire "c'est un peu dépassé".
Un assistant d'IA ne peut rien faire de tout cela. Il lit le texte, le traite comme un fait et génère une réponse en toute confiance. Si la documentation décrit un point de terminaison obsolète, l'IA recommandera joyeusement de l'intégrer. Si la documentation fait référence à une infrastructure qui a été remplacée il y a six mois, l'IA décrira l'ancienne configuration comme étant actuelle. Pas d'hésitation.
Et voici ce qui rend cette situation encore plus grave qu'elle n'en a l'air : [66 % des développeurs] (https://www.index.dev/blog/developer-productivity-statistics-with-ai-tools) disent déjà que le plus gros problème des outils d'IA est qu'ils donnent des résultats "presque corrects mais pas tout à fait". Une documentation périmée alimente directement ce problème. L'IA n'a pas d'hallucinations. Elle reproduit fidèlement un contenu obsolète, et le concepteur n'a aucun moyen de faire la différence.
Le constructeur fait confiance à l'IA. L'IA fait confiance à la documentation. Si la documentation est périmée, cette chaîne de confiance fournit une réponse erronée en toute confiance.
Cela a toujours été un problème, évidemment. Les contenus périmés ont toujours dérouté les gens. Mais les dégâts ont été limités parce que les lecteurs humains pouvaient parfois s'en apercevoir. Les intermédiaires de l'IA ne le peuvent pas. Ils amplifient les contenus périmés en les diffusant à grande échelle, avec autorité, à des personnes qui n'ont aucune raison d'en douter.
La fraîcheur n'est plus un problème de qualité du contenu. C'est une question de fiabilité pour chaque flux de travail alimenté par l'IA qui touche vos documents.
Le mot "développeur" est trop étroit
Les personnes qui créeront des logiciels en 2026 ne se considèrent pas toutes comme des développeurs. Certains sont des concepteurs qui invitent Claude à construire un prototype fonctionnel. D'autres sont des chefs de produit qui utilisent Cursor pour livrer des outils internes. D'autres sont des analystes de données qui décrivent un pipeline de données en langage naturel et laissent un agent l'assembler. Lors du Start Summit, la moitié des équipes de hackathon étaient composées de membres n'ayant aucune connaissance en programmation et qui livraient un logiciel fonctionnel à la fin du week-end.
[Ramp] (https://ramp.com/) est un exemple utile. L'entreprise de fintech est passée d'une évaluation de 5,8 milliards de dollars en 2023 à [32 milliards de dollars fin 2025] (https://techcrunch.com/2025/11/17/ramp-hits-32b-valuation-just-three-months-after-hitting-22-5b/), franchissant le cap du milliard de dollars de chiffre d'affaires annualisé en cours de route. C'est l'une des startups à la croissance la plus rapide de l'histoire. Un aspect très discuté de leur approche : les chefs de produit construisent des fonctionnalités directement avec des outils d'IA au lieu d'attendre dans un carnet de commandes d'ingénierie. Chez Ramp, les chefs de produit ne se contentent pas de rédiger des spécifications. Ils envoient du code. L'IA s'occupe de la mise en œuvre. Le chef de produit s'occupe de l'intention.
Ce n'est pas un raccourci. Il s'agit d'un nouveau modèle d'exploitation qui fonctionne à une échelle telle qu'il est difficile de le considérer comme une expérience.
L'étude interne d'Anthropic est révélatrice à cet égard. Lorsqu'ils ont [interrogé 132 de leurs propres ingénieurs] (https://fortune.com/2025/12/02/how-anthropics-safety-first-approach-won-over-big-business-and-how-its-own-engineers-are-using-its-claude-ai/) sur la manière dont ils utilisent Claude, les ingénieurs ont déclaré l'utiliser pour environ 60 % de leurs tâches. Les utilisations les plus courantes ? Déboguer le code existant, comprendre ce que font certaines parties de la base de code et mettre en œuvre de nouvelles fonctionnalités. Les ingénieurs ont déclaré qu'ils avaient tendance à confier à Claude des tâches "peu complexes et répétitives, pour lesquelles la qualité du code n'est pas essentielle". Et 27 % du travail qu'ils effectuent aujourd'hui avec Claude n'aurait tout simplement pas été fait auparavant.
Il s'agit de l'équipe d'Anthropic. Les personnes qui ont construit le modèle l'utilisent comme un lecteur de documentation, un navigateur de base de code et un générateur de premier jet. Tous les autres font de même, mais avec votre documentation au lieu de la leur.
Anthropic a délibérément appelé cela le persona "builder". Leurs outils sont conçus non seulement pour les ingénieurs logiciels professionnels, mais aussi pour toute personne capable de décrire ce qu'elle veut construire. Lorsque Claude peut créer une application complète à partir d'un dessin Figma via MCP, la frontière traditionnelle entre "développeur" et "non-développeur" s'estompe.
Cela a de réelles implications pour tous ceux qui gèrent la documentation ou qui se préoccupent de l'expérience des développeurs. Votre public n'est plus limité aux personnes qui savent ce qu'est un point de terminaison REST. Il inclut toute personne dont l'assistant d'intelligence artificielle pourrait interagir avec votre produit. Le chef de projet de Ramp qui lance une fonctionnalité en utilisant votre API ? Il ne lira probablement jamais votre documentation directement. Son agent d'intelligence artificielle, lui, la lira certainement.
Ce que cela signifie pour la documentation
Si la documentation s'adresse désormais à deux publics, les lecteurs humains et les intermédiaires de l'IA, elle doit fonctionner pour les deux. Cela semble évident. En pratique, presque personne ne le fait.
Voici ce que je pense être réellement important :
**Si la documentation de votre API est une page HTML magnifiquement rendue qu'un LLM doit gratter et analyser, l'IA travaille plus dur qu'elle ne le devrait. Envoyez la spécification OpenAPI brute avec la version rendue. Expédiez du markdown propre. Rendez les spécifications accessibles sans demander à l'IA d'interpréter la mise en page.
**Les assistants d'IA ne consomment pas la documentation page par page. Ils extraient les sections pertinentes. Un document comportant des titres clairs, des paragraphes autonomes et une sémantique explicite au niveau des blocs est beaucoup plus utile à l'IA qu'une narration fluide qui nécessite de lire toute la page pour connaître le contexte.
Faites confiance aux signaux indiquant que les machines savent lire. Quand ce document a-t-il été révisé pour la dernière fois ? Est-il toujours d'actualité ? Le contenu a-t-il été signalé ? Ces signaux doivent exister sous une forme accessible à l'intelligence artificielle, et pas seulement sous la forme d'indices visuels sur une page web. Une note de fraîcheur, un statut d'expiration, une date de révision, telles sont les métadonnées qui permettent à l'intelligence artificielle de décider si un document peut être utilisé comme source en toute sécurité.
**Lorsqu'un assistant d'IA fournit à un constructeur une réponse fiable basée sur un point de terminaison obsolète, les dégâts sont pires qu'un 404. Le constructeur s'appuie sur cette réponse. Le livre. Puis il tombe en panne en production, et personne ne sait pourquoi jusqu'à ce que quelqu'un remonte à une documentation qui aurait dû être mise à jour il y a des mois. Chaque document auquel une IA pourrait faire référence doit être accompagné d'un mécanisme prouvant qu'il est toujours d'actualité. (C'est exactement le problème que nous sommes en train de résoudre avec Rasepi). L'expiration forcée des blocs de documentation afin que le contenu périmé ne puisse pas se cacher).
Pour commencer : auditer votre documentation actuelle
Si vous avez lu jusqu'ici et que vous vous dites "d'accord, mais qu'est-ce que je fais vraiment lundi ?", voici quatre choses concrètes que vous pouvez vérifier cette semaine.
1. Testez vos documents à l'aide d'une IA Ouvrez Claude ou ChatGPT et demandez-lui d'intégrer votre produit dans un scénario réaliste. N'utilisez pas vos connaissances internes. Regardez simplement ce que l'IA produit. Est-ce correct ? Est-elle à jour ? Utilise-t-elle les bons terminaux, la bonne version du SDK, le bon flux d'authentification ? Si l'IA se trompe, c'est ce que les constructeurs obtiennent en ce moment.
**2. Choisissez vos cinq pages de documentation les plus visitées et posez-vous la question suivante : quand ces pages ont-elles été révisées pour la dernière fois ? Décrit-elle toujours l'état actuel du produit ? Si vous ne pouvez pas répondre à cette question en toute confiance, l'IA ne le pourra pas non plus. Il s'agit de la solution la plus efficace pour la plupart des équipes.
**3. Si vous n'avez pas de fichier /llms.txt, créez-en un. Si votre référence API n'est disponible qu'en HTML, exportez la spécification OpenAPI brute et rendez-la accessible. Si vos documents sont dans un CMS qui ne produit pas de markdown propre, c'est un problème qui mérite d'être résolu maintenant.
4. Ajoutez des dates de révision et des métadonnées de fraîcheur. Même quelque chose de simple, un champ last-reviewed dans votre système de gestion de contenu, un cycle de révision obligatoire pour les pages à fort trafic. Cela permet aux humains et à l'intelligence artificielle de savoir si le contenu est digne de confiance. Des outils comme Rasepi peuvent [automatiser ce processus avec une expiration forcée au niveau du bloc] (/fonctionnalités/freshness), mais même un processus manuel est mieux que rien.
Le changement silencieux dans la façon dont les produits sont représentés
Il y a une conséquence plus large de tout cela qui mérite d'être mentionnée directement.
Votre documentation n'est plus seulement un manuel de référence pour les développeurs. C'est le matériel source que les assistants d'intelligence artificielle utilisent pour représenter votre produit au monde entier. Lorsqu'un constructeur demande à Claude comment utiliser votre produit, la réponse de Claude est façonnée par tout ce qu'il peut trouver et analyser dans votre documentation.
Bonne documentation, bonne réponse. Obsolète, ambiguë, enfermée dans du HTML difficile à analyser pour un modèle ? Mauvaise réponse, ou réponse incorrecte. C'est aussi simple que cela.
La qualité de la réponse de l'IA à propos de votre produit est désormais un indicateur direct de l'expérience de vos développeurs. La plupart des entreprises ne le considèrent pas encore comme tel.
Les équipes qui sont en avance sur ce point, Stripe, Vercel, Cloudflare, Anthropic elles-mêmes, traitent la lisibilité de l'IA comme une préoccupation de premier ordre. Une exigence fondamentale qui détermine la façon dont la documentation est écrite, structurée et maintenue. Il ne s'agit pas d'un élément du carnet de commandes pour le prochain trimestre.
Le constructeur assis à Claude en ce moment même, décrivant ce qu'il veut construire, s'attend à un code fonctionnel en quelques minutes. Il se peut qu'il ne visite plus jamais un site de documentation. Mais l'IA qui les sert le fera. Constamment.
Cette IA est désormais votre lecteur le plus fréquent. La question est de savoir si vos documents sont prêts à l'accueillir.
La meilleure stratégie en matière d'expérience des développeurs en 2026 n'est pas une conférence ou un guide de démarrage rapide. Il s'agit de s'assurer que l'IA fait bien les choses.
Ce billet fait référence à des recherches et à des documents de produits accessibles au public. Les statistiques sont tirées de [l'enquête 2024 auprès des développeurs de GitHub] (https://github.blog/news-insights/research/survey-ai-wave-grows/), de [l'enquête 2024 auprès des développeurs de Stack Overflow] (https://survey.stackoverflow.co/2024/), du [rapport 2026 sur la productivité des développeurs d'Index.dev] (https://www.index.dev/blog/developer-productivity-statistics-with-ai-tools), des [statistiques Incremys Claude] (https://www.incremys.com/en/resources/blog/claude-statistics), et du [rapport Fortune sur Anthropic] (https://fortune.com/2025/12/02/how-anthropics-safety-first-approach-won-over-big-business-and-how-its-own-engineers-are-using-its-claude-ai/). La spécification /llms.txt est maintenue sur llmstxt.org. Le protocole de contexte de modèle est documenté à l'adresse modelcontextprotocol.io.