• API stable et documenté
  • Version d’API et évolutions
  • Changelog
  • Documentation dynamique avec Open API
• Le point d’entrée de l’IA : le MCP
• La GEO : la SEO optimisé pour l’IA
• L’IA ne va pas remplacer nos produits, elle va les augmenter
• Ressources

Demain, nos utilisateurs seront également des agents autonomes. Aakash Gupta (Expert Produit) et Stéphane Robert (DevOps Engineer), l’ont bien mis en évidence, chacun dans son blog : Le futur du Produit ne s’arrête pas à utiliser l’IA, mais à construire des produits utilisables par elle.

Un produit moderne doit donc prévoir :

• Une API propre, documentée et stable ;
• Un MCP (Model Context Protocol) exposant les capacités de notre produit, et prêt à être consommé par les agents ;
• Une stratégie SEO (optimisation pour les moteurs de recherche) optimisée pour l’IA.

§API stable et documenté

Ce premier point n’est pas une réelle révolution : les mainteneurs d’API sont déjà familiers de la plupart des bonnes pratiques, et les IA consomment ces informations d’une façon similaire aux visiteurs humain. La même rigueur sera donc attendu pour les fournisseurs de l’API qu’avant, car ils témoignent déjà de services qualitatifs en plus de garantir la sécurité des services proposés.

§Version d’API et évolutions

L’une des règles fondamentales, quand nous maintenons une API, est de se fixer une règle de gestion des évolutions, et de s’y tenir.

Le schéma suivi pour les changements de version permet aux développeurs et services utilisant notre API de comprendre l’impact des mises à jours de façon claire, évidente, et facile à anticiper.

L’un des protocoles les plus connus pour cela est Semver, et c’est un exemple qui a le mérite d’être clair. Semver défini notamment 3 niveaux de changements :

• Les changements majeurs sont des changements qui vont casser le comportement de l’API. L’utilisateur va alors deviner que la mise à jour va avoir des impacts… majeurs sur son propre service. En effet, nous devons incrémenter la version majeur de notre API lorsque les changements ne peuvent être compatible avec les fonctionnalités de la version antérieure. L’exemple typique est le retrait ou un changement profond sur le fonctionnement d’un service clé de l’application exposée par API. Les utilisateurs devront alors s’assurer qu’ils ne dépendent plus de ce service, ou qu’ils sont capable d’adapter leur propre application à ce changement.
• Les changements mineurs sont quant à eux rétro-compatibles (on peut changer de version sans tout casser), mais affectent quand même le comportement de notre service, de sorte que les utilisateurs peuvent être affectés dans leur usage.
• Le troisième niveau concerne les patchs. Il s’agit en général de bugs ou de correctifs de sécurité. Ils sont qualifiés en patchs précisément quand ça n’a pas d’impact sur le fonctionnement de notre service. Par contre, ils sont importants pour nos utilisateurs, car ils résolvent potentiellement un problème de sécurité dans leur propre application.

§Changelog

Ce point va de pair avec le précédent. En effet, si le changement de version donne une première indication sur ce qu’il implique, les changelog donnent les détails de ces changements : quel service, ou fonctionnalité affecté, qu’est-ce qui a changé, etc. Une bonne référence pour cette partie s’appelle « Keep a Changelog. »

Ce référentiel décrit par exemple les sections à employer pour décrire les ajouts (Added), les modification (Changed), les corrections (Fixed), ce qui sera obsolète à partir de cette version (Deprecated, qui sont retirés dans une version future), et ce qui a été effectivement retiré (Removed). Nous voyons déjà ici le rapport étroit avec Semver. Si nous respectons les principes, nous n’aurons pas de section « Removed » sur un changement de version mineur, mais nous pourrons avec une section « Deprecated » pour une fonctionnalité donné… Et celle-ci ne pourra être effectivement que dans la prochaine version majeur.

Keep a Changelog propose aussi des règles pour facilité la lecture et l’exploitation des informations par les humains, et comme les IA utilisent le langage naturel, elles en bénéficient également.

• Placer les versions dans l’ordre de la plus récente à la plus ancienne pour faciliter le repérage des dernières évolutions.
• Utiliser un langage clair et orienté bénéfice utilisateur (donc le développeur utilisant Claude pour coder aura besoin que Claude retrouve les impacts pour son produit… Comme si c’était le développeur lui-même qui venait chercher les informations).
• Afin d’éviter les loupées, nous pouvons également intégrer la mise à jour des changelog directement dans le processus de développement, de sorte que la publication d’une nouvelle version de l’API dispose automatiquement de la mise à jour de son Changelog… Du côté du développeur, cette partie est grandement facilitée s’il est rigoureux dans la documentation du code et les messages des changements au niveau du dépôt.
• Cerise sur le gâteau, surtout quand nous parlons d’utilisateurs IA : la documentation devrait suivre un format standard… Comme Markdown ! Nous le verrons au point suivant sur les MCP, mais c’est un format dont les IA ont déjà l’habitude.

§Documentation dynamique avec Open API

La spécification OpenAPI définit une interface indépendante du langage qui permet aux ordinateurs de découvrir et comprendre les capacités du service sans accès au code source, à une documentation supplémentaire ou à l’inspection du trafic réseau. En tant que norme ouverte soutenue par la Linux Foundation, OpenAPI assure une interopérabilité avec une large gamme d’outils et de plateformes (comme le clame d’ailleurs le site en page d’accueil).

Cette standardisation permet aux agents IA - autant qu’aux humains - de traiter différentes API de manière cohérente, améliorant la maintenabilité et la compréhension des services d’API.

Par exemple, OpenAPI permet de générer automatiquement la documentation à partir des annotations dans le code ou du fichier de spécification (sur la même base que les Change Logs), évitant les incohérences entre la documentation et l’implémentation réelle. Pour un agent IA, une documentation fiable et à jour est cruciale pour effectuer des requêtes correctes et éviter les erreurs d’intégration.

Enfin, des outils comme Swagger Codegen peuvent utiliser le fichier de spécification pour générer automatiquement des bibliothèques clientes, des ébauches de serveur et des SDK (Kit de développements) dans de nombreux langages. Pour un agent IA, cela signifie qu’il peut potentiellement construire son propre client d’API ou comprendre le format des requêtes/réponses sans développement manuel.

Dans ce qui suit, nous allons rencontrer d’autres usages qui, pour le coup, révolutionnent notre façon de concevoir nos produits.

§Le point d’entrée de l’IA : le MCP

Une implémentation naïve du MCP est de générer une documentation dynamique avec Swagger pour l’exposer à l’IA. Certains services sont parties sur cette solution, car comme nous l’avons vu, si l’API est correctement documentée, le coût est quasi-inexistant.

Mais le MCP « by the book » va nettement plus loin : il permet à l’IA de « dialoguer » avec le service, autrement dit… s’en servir. Techniquement, cela signifie qu’il se comporte comme un serveur exposant notre service, de la même façon qu’un serveur web. Le serveur MCP va utiliser une combinaison de JSON et de Markdown via API.

Le JSON est le standard le plus utilisé (et le plus connu) du web grâce à son format optimisé pour l’envoi d’information sur Internet. Il permet de construire des objets possédant des attributs, et ces attributs pourrons être reconnus comme des nombres, du texte, des booléen (true pour vrai et false pour faux), mais aussi des listes ou d’autres objets. Un serveur MCP reprend ce format comme base pour encapsuler toute autre information à l’intérieur.

Le Markdown est un format qui permet de rédiger du texte enrichi. Par exemple, une ligne commençant par un dièse (#) est un titre, deux dièses (##) un sous-titre, un bloc de code avec trois « back-ticks » (```). Markdown permet de la mise en relief du texte (gras, souligné, italique) de construire des listes, des tableaux, d’intégrer des illustrations, etc. C’est typiquement le format que j’utilise au quotidien pour rédiger mes articles. Il est d’ailleurs nativement compris par les applications Nostr comme Yakihonne (du coup, les utilisateurs de ce réseau en sont pour la plupart familier). Les IA on repris ce format, pour leur contexte, les prompts, leurs réponses,… (vous pourrez tester la prochaine fois que vous irez sur ChatGPT), mais aussi pour structurer le contenu des échanges par MCP. Ainsi, dans les échanges par MCP, nous aurons un objet JSON avec divers attributs qui représentent peu ou proue des metadonnées (données qui décrivent les données échangées), et un attribut (par exemple description) de type texte, qui contiendra en fait une longue chaîne de caractère au format Markdown.

Le MCP proposera différents points d’entrées, avec chacun un chemin d’accès spécifique.

• Tools est un point d’accès exposant les outils à disposition de l’agent IA pour interagir avec le service : création, édition, suppression de ressource, etc.
• Resources contient toute la documentation du service, mais également les « ressources » au sens des ressources du service (les profiles, message,… si c’est le MCP d’un service Cloud, ça peut être la machines virtuelles, les volumes, les VPS, etc.)
• Prompts, enfin, fournit des instructions préparées à destination de l’agent pour le guider dans l’utilisation du service.

Pour implémenter un serveur MCP, plusieurs langages fournissent déjà les outils adéquates. Par exemple, en Python, nous disposons de FastMCP. Ceux-ci permettent de réimplémenter les fonctionnalités de notre service, mais si nous avons déjà une API avec la logique correctement séparée, FastMCP pourra s’y raccorder pour exposer les mêmes fonctionnalités que notre API (sans avoir à tout réinventer).

§La GEO : la SEO optimisé pour l’IA

La SEO (« Search Engine Optimization ») est une technique de référencement naturelle permettant aux moteurs de recherche de retrouver rapidement de quoi traite une page web.

Dans les grandes lignes, nous aurons un titre, une description, des tags, etc. dans l’en-tête de notre page web, que le moteur de recherche pourra récupérer, sans forcément charger l’intégralement de la page. Il s’appuiera sur ces informations pour indexer notre page web, et ainsi rapidement la retrouver lorsqu’un utilisateur effectue une recherche.

Ce mode de fonctionnement est adapté avec nos bons vieux moteurs de recherches, car ils vont afficher le titre et une courte description, pour accompagner le lien de la page.

Aujourd’hui, l’IA représente à peine 0,2% du traffic sur Internet, selon SE Ranking (sans parler des bots, agents autonomes d’indexation ou scraping, beaucoup plus anciens). Cela paraît peu, mais le même article mentionne une multiplication par 9, par rapport à 2024, et Siecle Digital remarque que certains sites voient déjà jusqu’à 10% de leur trafic généré par des IA. Aakash Gupta nous préviens bien : ce chiffre n’est pas près de baisser…

Nous devons donc adapter notre stratégie de référencement, et c’est là qu’intervient la GEO, pour « Generative Engine Optimization ». L’IA ne se contente pas d’un lien et du résultat des bots d’indexation : elle va exploiter le contenu de la page pour générer un réponse structurée, celle dont nous avons tous l’habitude, maintenant.

Ce que ça change pour nos applications et sites web, ce sont les moyens à mettre en avant pour être cité par les IA, et donc proposer du contenu « prêt à l’emploi » : références claires, données originales et contenu et schémas bien structurés,… La GEO étend également la SEO, dans la mesure où les IA ne lisent pas nos pages web comme un humain, mais en accédant directement au code HTML et CSS correspondant, ce qui signifie que la structure au sens « DOM » (Document Object Model, l’organisation des balises HTML) doit être particulièrement soignée.

Néanmoins, l’accent doit être mis particulièrement sur la qualité du contenu, c’est-à-dire prioriser la rigueur et la justesse des propos, pour attirer l’attention des IA et de leurs utilisateurs.

§L’IA ne va pas remplacer nos produits, elle va les augmenter

De la même façon que nous autres, humains avec nos faiblesses, ne seront pas remplacés par l’IA, nos produits aussi peuvent travailler avec l’IA, et cela passe par leur optimisation à l’ère du XXIè siècle.

C’est la raison pour laquelle tout concepteur et développeur de produit en 2026 doit intégrer l’IA dans ses réflexes et pas seulement pour augmenter ses capacités de développement : documentation adaptée, points d’accès dédiés, accessibilité du site web,… L’IA est désormais un consommateur de premier plan.

Ainsi nos applications et sites web seront prêts pour le tournant majeur de 2026 : l’industrialisation de l’IA générative, c’est-à-dire son intégration dans les processus métiers des entreprises.

§Ressources

• Semver pour le versioning sémantique.
• OpenAPI.
• Keep a Changelog pour des messages de changelog pertinents.
• Documentation IA Compatible par Stéphane Robert
• https://littlebigthings.fr/geo
• “Your product’s next million users won’t have eyes“ par Aakash Gupta
• Doc officielle du MCP
• IA Agentique, un trafec web massif et encore incontrôlable sur Le Siècle Digital
• Trafic IA en france en 2025, SE Ranking