Tous les quelques mois, je me réserve une matinée pour lire. Pas de code Rasepi, pas de problèmes GitHub. Les blogs des concurrents, les rapports de l'industrie, les annonces de conférences, les enquêtes auprès des développeurs. Tout ce qui a été livré au cours du dernier trimestre et qui concerne la documentation, la gestion des connaissances ou les flux de travail assistés par l'IA.
C'est ce que j'ai fait la semaine dernière, et l'image qui en est ressortie était plus nette que je ne l'imaginais. Non pas parce qu'une seule annonce était révolutionnaire, mais parce que cinq tendances distinctes convergent, et lorsque vous les alignez, elles brossent un tableau très clair de ce que les plateformes de documentation devront faire au cours des deux prochaines années.
Voici ce que j'ai trouvé.
1. L'IA est désormais le principal lecteur. Pas les humains.
GitBook a publié un chiffre frappant dans son [AI docs data report] (https://www.gitbook.com/blog/ai-docs-data-2025) : La lecture de la documentation par l'IA a augmenté de plus de 500 % en 2025. Cinq cents pour cent. Ce n'est pas une erreur d'arrondi.
Dans le même temps, l'enquête [2024 Developer Survey] de Stack Overflow (https://survey.stackoverflow.co/2024/) a montré que 61 % des développeurs passent plus de 30 minutes par jour à chercher des réponses. Mais la manière dont ils cherchent a changé. La propre enquête de GitHub a révélé que [97 % des développeurs d'entreprise] (https://github.blog/news-insights/research/survey-ai-wave-grows/) ont utilisé des outils de codage d'IA. D'ici 2026, [84 % des développeurs] (https://www.index.dev/blog/developer-productivity-statistics-with-ai-tools) utiliseront quotidiennement des outils d'IA, et 41 % du code sera désormais généré par l'IA. Ces personnes ne naviguent pas dans la barre latérale de votre wiki. Ils s'adressent à Claude ou à Copilot, et l'IA lit vos documents en leur nom.
L'implication est difficile à exagérer. Le consommateur le plus fréquent de votre documentation n'est plus une personne avec un onglet de navigateur ouvert. Il s'agit d'un modèle de langage qui effectue des recherches. Et ce modèle n'a pas la capacité de regarder une page et de se dire "hmm, ça a l'air dépassé".
GitBook s'en est rendu compte très tôt et a réagi en publiant son [rapport sur l'état des documents en 2026] (https://www.gitbook.com/blog/state-of-docs-2026) et en favorisant les formats lisibles par une machine. Ils ont également publié skill.md, une convention pour structurer les informations sur les produits spécifiquement pour les agents d'intelligence artificielle. Google est allé plus loin avec son Gemini API Docs MCP, qui connecte les agents de codage à la documentation actuelle via le Model Context Protocol. Leur raisonnement était explicite : les agents génèrent du code obsolète parce que leurs données d'entraînement ont une date limite. La correction du MCP a porté leur taux de réussite à l'évaluation à 96,3 %.
La première tendance est donc établie. L'IA est le premier lecteur. Les plateformes qui traitent cette question comme une contrainte de conception fondamentale, et non comme une fonction à ajouter ultérieurement, bénéficieront d'un avantage structurel.
2. Les métadonnées de fraîcheur et de confiance deviennent obligatoires
Anthropic a interrogé [81 000 utilisateurs de Claude] (https://www.anthropic.com/81k-interviews) en décembre 2025 et a publié les résultats en mars 2026. Il s'agit de la plus grande étude qualitative jamais réalisée auprès d'utilisateurs d'IA (159 pays, 70 langues). La préoccupation la plus souvent citée ? Le manque de fiabilité. 27 % des personnes interrogées l'ont désignée comme leur principale préoccupation, et 79 % d'entre elles en ont fait l'expérience directe.
Ce chiffre devrait donner des sueurs froides à toutes les équipes de documentation.
Lorsque les réponses de l'IA ne sont pas fiables, le problème ne vient pas toujours du modèle. Souvent, le modèle reproduit fidèlement ce qu'il a trouvé dans un document périmé. Le modèle n'a pas eu d'hallucinations. Vos documents étaient tout simplement erronés et personne ne les a signalés.
Les données de Stack Overflow renforcent ce point sous un angle différent : [81 % des développeurs] (https://survey.stackoverflow.co/2024/) s'attendent à ce que l'IA soit davantage intégrée dans la façon dont ils documentent le code au cours de l'année à venir. Si 81 % de vos utilisateurs fournissent des documents à l'IA et que 27 % des utilisateurs d'IA déclarent que le manque de fiabilité est le principal problème, vous avez un problème de confiance qu'aucun effort d'ingénierie ne pourra résoudre. La solution se trouve à la source.
C'est pourquoi les métadonnées de fraîcheur sont importantes. Il ne s'agit pas de l'horodatage "dernière modification" (qui indique quand quelqu'un a touché le fichier, et non pas si le contenu est toujours exact). Une véritable fraîcheur : statut de la révision, santé des liens, alignement de la traduction, signaux de lecture, détection de la dérive du contenu. Des métadonnées qu'une machine peut lire et utiliser pour décider si un document peut être cité en toute sécurité.
J'en reviens toujours à un cadre simple. Votre documentation a besoin d'un score de crédit. Pas un horodatage. Un score de crédit. (C'est exactement ce que nous avons construit avec le [système d'évaluation de la fraîcheur] de Rasepi(/features/freshness), et honnêtement, en voyant les données de l'industrie, je suis encore plus convaincu qu'il s'agit de la bonne décision).
3. La traduction passe de "projet" à "pipeline"
DeepL a publié en février un article intitulé ["The 6 Translation Transformations Can't Afford to Miss"] (https://www.deepl.com/en/blog/six-translation-transformations). Leur argument : la traduction est en train de devenir un défi opérationnel permanent, et non plus un projet par lots que l'on réalise tous les trimestres.
Cela correspond à tout ce que je vois.
L'ancien modèle était simple. Rédiger en anglais. Lorsque vous disposez d'un budget, engagez un traducteur ou passez par un service. Obtenez les traductions. Téléchargez-les. Terminé jusqu'à la prochaine fois. Le problème est que la "prochaine fois" arrive de plus en plus vite lorsque votre produit est expédié chaque semaine et que vos documents sont constamment mis à jour. Le temps que la version allemande soit révisée, la source anglaise a déjà changé deux fois.
Le [Customization Hub] (https://www.deepl.com/customization-hub) de DeepL propose désormais des glossaires, des règles de style et des paramètres de formalité, ce qui est très bien. Mais si ces outils vivent en dehors de votre plateforme de documentation, vous devez gérer une chaîne d'outils de traduction : éditeur, exportation, traduction, révision, réimportation, répétition. Chaque étape est une occasion de dérive.
Notion ne dispose d'aucun support multilingue natif. Confluence l'offre par le biais de plugins sur la place de marché. GitBook [a ajouté la traduction automatique en août 2025] (https://www.gitbook.com/blog/new-in-gitbook-august-2025), ce qui est une étape, mais il opère au niveau de la page.
Le véritable changement est de passer du niveau de la page au niveau du bloc. Lorsque vous suivez les traductions au niveau du paragraphe, vous ne retraduisez que ce qui a réellement changé. Une révision typique ne concerne que deux paragraphes sur quarante. Cela représente 94 % de travail de traduction en moins. (Il s'agit de l'architecture de traduction de base de Rasepi et, honnêtement, c'est la chose dont je suis le plus fier dans le produit. Mais même en nous mettant de côté, l'orientation de l'industrie est claire : la traduction continue, incrémentale et intégrée est la voie à suivre).
4. Les agents d'IA ont besoin d'un contenu structuré, pas de pages wiki
Cette question s'est cristallisée pour moi lorsque Notion a annoncé [Custom Agents] (https://www.notion.com/blog/introducing-custom-agents) en février. 21 000 agents construits pendant l'accès anticipé. Des agents qui répondent à des questions provenant de bases de connaissances, routent des tâches, compilent des rapports d'état. Ramp compte à lui seul plus de 300 agents.
Atlassian a pris une direction similaire. [Rovo AI in Confluence] (https://www.atlassian.com/blog/confluence/create-and-edit-with-rovo) extrait le contexte de l'ensemble des applications d'Atlassian et de tiers pour générer du contenu. Leur argumentaire : "un contenu de haute qualité, riche en contexte et ancré dans le travail existant de votre équipe".
Anthropic a ensuite lancé [équipes d'agents dans Claude Code] (https://www.anthropic.com/news/claude-opus-4-6), où plusieurs agents d'IA se coordonnent de manière autonome sur des tâches complexes. Opus 4.6 obtient un score de 76 % sur le benchmark 1M MRCR à 8 aiguilles (contre 18,5 % pour le modèle précédent), ce qui signifie qu'il peut réellement récupérer des informations enfouies dans des ensembles de documents massifs sans en perdre la trace.
Ces trois entreprises construisent des agents qui consomment de la documentation. Aucune d'entre elles n'a résolu le problème de la qualité des sources.
La documentation de Notion sur les agents personnalisés reconnaît explicitement le [risque d'injection rapide] (https://www.notion.com/blog/introducing-custom-agents) lorsque les agents lisent un contenu non fiable. Rovo d'Atlassian récupère tout ce qu'il trouve dans votre Confluence. Si ce contenu est périmé depuis trois mois, Rovo ne le sait pas. Il s'en sert quand même.
Pour fonctionner de manière fiable, les agents ont besoin de plus que des pages de texte. Ils ont besoin d'un contenu structuré avec des identifiants stables, des signaux de fraîcheur explicites, des métadonnées de classification claires et la capacité de distinguer "ceci est actuel et révisé" de "ceci existe mais personne n'y a touché depuis un an". Les pages wiki n'offrent pas ces caractéristiques. Un contenu structuré au niveau du bloc avec des métadonnées de confiance le permet.
5. L'open source et l'auto-hébergement font leur retour
Ce dernier point est plus une intuition étayée par des données qu'une simple annonce.
GitBook [a mis en open source sa documentation publiée] (https://www.gitbook.com/blog/free-open-source-documentation) fin 2024 et a lancé un fonds OSS. Leur raisonnement : les projets open source méritent des outils de documentation gratuits et de haute qualité. Mais cette initiative est aussi le signe d'un mouvement plus large.
Notion ne fonctionne qu'en nuage. Il n'y a pas d'option d'auto-hébergement. Confluence Data Center existe mais nécessite une licence. Lorsque votre plateforme de documentation contient vos connaissances opérationnelles les plus sensibles (playbooks d'incidents, procédures de conformité, décisions d'architecture), la question de savoir "qui contrôle ces données" n'est pas abstraite.
Le billet d'Anthropic "Claude est un espace de réflexion" de février présentait un argument intéressant sur la confiance et les modèles commerciaux. Leur principal argument est que les incitations publicitaires sont incompatibles avec un assistant IA véritablement utile. Ils ont choisi de rester sans publicité pour que les utilisateurs puissent faire confiance à l'outil.
Je pense qu'il existe un parallèle pour les plateformes de documentation. Si votre système de documentation est fermé et réservé à l'informatique en nuage, vous ne pouvez pas vérifier ce qu'il transmet à l'IA. Vous ne pouvez pas vérifier les calculs de fraîcheur. Vous ne pouvez pas vous assurer que vos données restent sous votre contrôle. Pour les équipes qui déploient des assistants d'IA au-dessus de leur base de connaissances (et de plus en plus, tout le monde le fait), l'auditabilité est importante.
Il ne s'agit pas d'une polémique sur la supériorité morale de l'open source. Les produits à code source fermé peuvent tout à fait être dignes de confiance. Mais lorsque vous créez des flux de travail alimentés par l'IA à partir de votre documentation interne, la possibilité d'inspecter et de vérifier le système est un avantage pratique. Pour nous, l'octroi d'une licence MIT pour Rasepi n'a pas été une réflexion après coup. Il s'agissait d'une décision de conception ancrée dans la même logique : l'infrastructure documentaire doit pouvoir être auditée.
Ce que ces cinq tendances signifient ensemble
Individuellement, chacune de ces tendances est gérable. L'IA lit vos documents ? D'accord, ajoutez des métadonnées lisibles par une machine. La fraîcheur est importante ? Très bien, ajoutez des dates de révision. La traduction doit être continue ? Bien sûr, intégrez DeepL. Les agents ont besoin d'une structure ? Très bien, améliorez votre modèle de contenu. La souveraineté est importante ? Parfait, proposez une option d'auto-hébergement.
Pris ensemble, ils décrivent une plateforme qui semble fondamentalement différente de ce que la plupart des équipes utilisent aujourd'hui.
L'écart est d'ordre architectural. Il ne s'agit pas de cinq fonctionnalités à ajouter. Il s'agit de cinq hypothèses qui doivent être intégrées dans les fondations. La manière dont le contenu est stocké (au niveau du bloc et non de la page). Comment la confiance est modélisée (scores de fraîcheur, pas d'horodatage). Comment fonctionne la traduction (incrémentale, intégrée, par paragraphe). Comment les agents d'intelligence artificielle accèdent au contenu (API structurées avec des métadonnées, pas des pages scrappées). Comment les données sont contrôlées (ouvertes, vérifiables, auto-hébergeables).
Aucune plateforme établie n'a été conçue autour de ces cinq éléments simultanément. Certaines les ajoutent au fur et à mesure. GitBook progresse le plus rapidement sur le front de la lisibilité de l'IA. Notion construit une infrastructure d'agents. Atlassian dispose d'une distribution d'entreprise.
Mais concevoir pour les cinq dès le premier jour ? C'est l'avantage de repartir à zéro lorsque le terrain change.
Je suis conscient de mon parti pris. Nous avons construit Rasepi spécifiquement parce que nous avons vu ces tendances converger et que nous voulions une plateforme qui les prenne toutes en charge dès le départ. Traduction au niveau du bloc, expiration forcée, notation de la fraîcheur, contenu structuré prêt pour l'IA, source ouverte. C'est la thèse de tout le projet.
Mais même si nous n'existions pas, je pense que toute lecture honnête de ce qui s'est passé au premier trimestre 2026 va dans le même sens. La documentation devient une infrastructure. Et l'infrastructure a des exigences différentes de celles des pages wiki.
Les équipes qui comprendront cela en premier n'auront pas seulement de meilleurs documents. Elles auront des agents d'intelligence artificielle plus fiables, des coûts de traduction moins élevés, moins de surprises en matière de conformité et des bases de connaissances qui resteront dignes de confiance au fil du temps.
Tel est l'état des documents en 2026. La question n'est pas de savoir si ces tendances sont réelles. Il s'agit de savoir si votre plateforme a été conçue pour elles.
Cinq tendances. Une question architecturale : votre plateforme de documentation a-t-elle été conçue pour 2026 ou sert-elle encore les hypothèses de 2016 ?
Sources : GitBook AI docs data report, GitBook State of Docs 2026, GitBook skill.md, Google Gemini API Docs MCP, Stack Overflow 2024 Developer Survey, GitHub 2024 developer survey, Index.dev developer productivity statistics, Anthropic "What 81,000 People Want from AI", Anthropic "Claude est un espace pour penser", Claude Opus 4.6, Notion Custom Agents, Atlassian Rovo dans Confluence, DeepL "6 Translation Transformations", DeepL Customization Hub, GitBook open source documentation, GitBook auto-translate.