Les agents lisent déjà 80 % du trafic vers la documentation de 20 000 entreprises — en janvier, c'était l'inverse

Le titre « Les agents d'IA lisent 80 % d'internet » relève presque du clickbait. Il est imprécis, mais l'histoire est plus intéressante qu'il n'y paraît. Elle raconte que la documentation pour développeurs a changé de lecteur principal.

Ce qui a réellement été mesuré

Le chiffre ne concerne pas tout le web. Il porte sur le trafic des sites de documentation officielle destinée aux développeurs, qui appartiennent à environ 20 000 entreprises, dont Anthropic, Microsoft et Amazon. Aujourd'hui, environ 80 % de ce trafic provient d'agents. En janvier, le rapport était inversé : les humains dominaient.

En dix mois, la majorité des lecteurs de la documentation est passée de l'humain au programme. C'est cette dynamique qu'il faut retenir, plutôt que le chiffre rond du titre. Précisons que nous relayons les chiffres d'après un article sur Substack et l'analyse d'Andreï Sebrant. La manière dont les auteurs distinguent les agents des humains n'apparaît pas dans ce résumé. Ceux qui citeront ces données devraient consulter la source primaire et examiner la méthodologie.

Pourquoi précisément la documentation

La documentation est un contenu presque idéal pour un agent. Elle a un objectif clair : trouver comment appeler une méthode d'API, quels paramètres accepte une fonction, ce que signifie telle erreur. Auparavant, le développeur ouvrait la page et la lisait. Désormais, il confie la tâche à un assistant de code, qui se rend lui-même sur le site, récupère les passages utiles et écrit le code.

L'humain, lui, lit la documentation moins souvent et de façon indirecte, via la réponse de l'agent. C'est notre interprétation, mais elle explique bien pourquoi les compteurs de visites ont changé si brutalement. Une seule requête d'un développeur peut générer plusieurs appels de l'agent vers différentes pages ; le basculement du trafic paraît donc plus dramatique que celui du nombre réel d'utilisateurs.

Que faire

Si vous êtes responsable de la documentation ou d'un produit doté d'une API, plusieurs mesures pratiques en découlent.

• Séparez les analyses. Regardez quelle part des accès à votre documentation provient d'agents. Si vous comptez toutes les visites comme humaines, vos métriques vous induisent en erreur.
• Écrivez pour la machine comme pour un premier lecteur. Des titres clairs, des exemples de code complets que l'on peut copier et exécuter, des versions d'API explicites, une description compréhensible des erreurs. L'agent ne devine pas selon le contexte : il prend ce qui est écrit.
• Ne cachez pas l'essentiel. Une information clé placée dans des onglets, des images ou une interface rendue uniquement par des scripts risque de ne jamais atteindre l'agent.
• Envisagez des formats lisibles par machine. Par exemple, des versions de pages en balisage simple ou le fichier llms.txt proposé par la communauté, qui liste les contenus importants. Ce n'est pas un standard mais une convention, et tout le monde ne la prend pas en charge, mais le coût de mise en œuvre est faible.
• Mesurez le succès autrement. Les pages vues indiquent mal si la documentation a aidé. Il est plus utile de regarder si l'agent a mené à bien sa tâche avec votre API dès la première tentative.

Les humains ont toujours besoin de documentation, mais d'une autre : concepts, aperçus d'architecture, apprentissage à partir de zéro. La couche de référence devient de plus en plus une interface pour agents.

Limites

Premièrement, il s'agit d'un échantillon de sites de documentation, pas de tout internet. Les blogs, les actualités et les forums se lisent différemment, et l'on ne peut pas leur appliquer les 80 %. Deuxièmement, c'est une part des visites, pas une part des lecteurs. Un agent peut effectuer des dizaines de requêtes là où un humain n'ouvrirait qu'une page. Troisièmement, comme indiqué, les détails de la méthodologie sont inconnus d'après le résumé.

En conclusion : même avec ces réserves, la tendance est évidente. Si votre produit est utilisé par des développeurs, une part significative de la première prise de contact est aujourd'hui assurée non par un humain. Il faut tester la documentation comme vous testez une interface : un nouveau lecteur, cette fois logiciel, saura-t-il s'y retrouver ?