Rasepi Blog

Créez le produit qui fonctionne sans votre interface utilisateur

2026-05-24T00:00:00Z

Mardi dernier, j'ai dû mettre à jour trois documents dans notre base de connaissances interne. Je n'ai pas ouvert l'outil docs. J'ai ouvert Claude. Je lui ai demandé de récupérer la dernière version d'un ticket Linear, de résumer les changements, de trouver les pages concernées et de les mettre à jour. Il a fait tout cela, via MCP, pendant que je faisais mon café. L'onglet du navigateur pour le produit actuel n'a jamais été ouvert.

Cela n'a plus rien d'inhabituel. C'est ce à quoi ressemble un mardi normal aujourd'hui. Et cela devrait être tranquillement terrifiant pour quiconque construit un produit SaaS qui traite encore l'interface utilisateur comme l'événement principal.

Les chiffres indiquent que l'interface utilisateur a perdu la majorité

Commençons par quelque chose d'inconfortable. Selon le [Imperva's 2026 Bad Bot Report] (https://cpl.thalesgroup.com/about-us/newsroom/2025-imperva-bad-bot-report-ai-internet-traffic), le trafic automatisé représente désormais plus de 53 % de l'ensemble du trafic web, ce qui représente la première fois en dix ans que les humains sont minoritaires sur Internet. À l'intérieur de cette tranche automatisée, le trafic agentique de l'IA a augmenté de près de 8 000 % en 2025. L'élément qui connaît la croissance la plus rapide sur le web n'est plus une personne qui clique. C'est un agent qui effectue un travail pour le compte de quelqu'un.

Du côté des protocoles, l'histoire est encore plus nette. Le MCP [Anthropic] (https://thenewstack.io/model-context-protocol-roadmap-2026/), qui existait à peine au début de l'année 2025, est désormais en production dans 78 % des équipes d'IA d'entreprise au premier trimestre 2026, contre 31 % un an plus tôt. Le registre public des serveurs MCP est passé d'environ 1 200 serveurs au 1er trimestre 2025 à plus de 9 400 en avril 2026. En décembre 2025, Anthropic a fait don du protocole à la nouvelle [Agentic AI Foundation] (https://www.cdata.com/blog/2026-year-enterprise-ready-mcp-adoption) sous l'égide de la Fondation Linux, avec OpenAI, Google, Microsoft et AWS. C'est à ce moment-là que MCP a cessé d'être une affaire d'Anthropic et a commencé à être la couche d'intégration.

En outre, Gartner prévoit désormais que 40 % des applications d'entreprise seront livrées avec des agents d'IA spécifiques à une tâche d'ici la fin de 2026, contre moins de 5 % aujourd'hui.

Lisez ces chiffres ensemble. Le tuyau par lequel votre produit est utilisé est en train d'être reconstruit sous vos pieds, et une grande partie du nouveau trafic ne verra jamais un bouton.

La plupart des produits sont encore axés sur l'interface utilisateur sous le capot.

Je le remarque à chaque fois que je regarde un nouvel outil SaaS.

L'interface utilisateur est magnifique. L'API est une réflexion après coup. Il y a une page /docs avec douze points de terminaison sur les quarante utilisés par l'interface utilisateur. Il n'y a pas de serveur MCP. Le CLI, s'il existe, est un projet parallèle de la communauté qui est abandonné tous les six mois. Le flux d'accueil suppose que vous êtes un humain qui clique sur un assistant, parce que le produit a été conçu pour que des humains s'y connectent.

Ce modèle a fonctionné pendant quinze ans. Il commence à échouer en 2026, et il échouera encore plus chaque trimestre à partir de maintenant.

Voici ce que je continue à observer. Une équipe adopte un nouvel outil. Elle utilise l'interface utilisateur pendant les premières semaines. Puis un membre de l'équipe intègre Claude ou ChatGPT dans son flux de travail. Soudain, la question n'est plus "comment ouvrir l'interface utilisateur et mettre à jour cette chose". La question est "mon agent peut-il le faire pour moi". Si la réponse est négative, l'utilisation de cet outil commence à diminuer. Non pas parce que l'interface utilisateur s'est dégradée. Parce que le point d'entrée s'est déplacé.

Le trafic de robots ciblant les API est passé à 27 % de l'ensemble du trafic de robots en 2025, selon le même rapport d'Imperva. Ce chiffre va augmenter chaque année. Chaque flux de travail agentique est une pile d'appels d'API, et tout produit qui n'expose pas ces appels sera exclu du flux de travail.

Ce que signifie "fonctionne sans votre interface utilisateur" en réalité

Il ne s'agit pas seulement de "disposer d'une API". La plupart des produits ont une API. La plupart des API sont également mauvaises.

Le produit qui fonctionne sans son interface utilisateur passe une barre beaucoup plus difficile à franchir. Je pense qu'il existe environ quatre tests.

Toutes les actions significatives de l'interface utilisateur peuvent être appelées à partir de l'API. Aucune case "ceci ne peut être configuré que par un administrateur dans l'interface utilisateur". Si un humain peut le faire, un agent peut le faire.
Il y a un serveur MCP, et il est de première partie.** Pas un projet communautaire. Pas un wrapper que quelqu'un a construit le week-end dernier. Un serveur MCP réel, propriétaire, versionné qui expose la même surface que l'API d'une manière que les agents peuvent raisonner.
Parce que les CLIs sont la façon dont les ingénieurs écrivent des choses, et parce que les CLIs sont aussi la façon dont beaucoup de frameworks agentiques finissent par appeler des outils quand MCP n'est pas disponible.
L'authentification fonctionne pour les non-humains.** Les comptes de service, les jetons, les flux OAuth qu'un agent peut compléter pour le compte d'un utilisateur. Pas "cliquez sur ce lien magique dans votre email", parce que l'agent n'a pas de client email.

Si votre produit échoue à l'un de ces points, vous avez construit une interface utilisateur avec un backend, et non un produit. La différence sera de plus en plus importante.

Nous avons dû prendre cette décision chez Rasepi, et elle n'était pas subtile

Je vais être honnête, c'est la raison pour laquelle nous avons construit Rasepi de la façon dont nous l'avons fait, et c'était une vraie décision architecturale, pas une ligne marketing.

Lorsque nous avons esquissé le produit au début de l'année 2025, la chose évidente à construire était une autre interface utilisateur en forme de Confluence. Un joli éditeur, un joli lecteur, une barre de recherche au-dessus. Nous avons failli le faire. Ce qui nous a arrêtés, c'est de voir comment les équipes utilisaient déjà Claude, GPT et d'autres agents similaires pour lire et écrire leurs documents internes sans jamais ouvrir l'outil existant. L'interface utilisateur n'était pas le goulot d'étranglement. C'est le manque de surface programmatique qui l'était.

Rasepi a donc été conçu en privilégiant les API, l'interface utilisateur étant construite au-dessus de la même surface que celle que tout agent ou script peut atteindre. Le serveur MCP, l'API REST et le CLI partagent tous la même authentification, le même modèle de permission et la même couche de contenu. L'interface utilisateur n'est qu'un des consommateurs. Nous testons le produit en écrivant des scripts, pas en cliquant dessus.

Cela a des conséquences sur ce que nous construisons, dans le bon sens comme dans le mauvais. Chaque nouvelle fonctionnalité doit être livrée avec la parité API. Nous ne pouvons pas simplement "ajouter un bouton" et considérer que c'est fait. L'avantage est que lorsqu'un client branche Claude sur son instance Rasepi, tout fonctionne. Il n'y a pas de "ah, cette fonctionnalité est réservée à l'interface utilisateur, désolé".

Ce que cela signifie si vous construisez quelque chose en ce moment même

Quelques éléments, si je devais résumer les conclusions pratiques.

Arrêtez de mesurer l'utilisation en fonction de l'activité de l'interface utilisateur uniquement. Mesurez votre trafic API et MCP séparément, et suivez-les comme des métriques de croissance, et non comme du bruit d'exploitation. Si l'utilisation de votre tableau de bord est stable mais que votre trafic API double, ce n'est pas un problème. C'est l'avenir qui arrive comme prévu.

Construisez un serveur MCP de première partie avant que la communauté n'en construise un mauvais pour vous. Les 9 400 serveurs du registre public ne sont pas tous bons. La plupart d'entre eux présentent des fuites, sont à moitié implémentés et ne sont pas maintenus, et vos utilisateurs jugeront votre produit sur la qualité de cette intégration, que vous l'ayez écrite ou non.

Et arrêtez de considérer l'API comme la version bon marché de votre produit. Dans un an, pour de nombreux clients, elle est votre produit.

Les entreprises qui gagneront en 2026 seront celles dont les utilisateurs pourront tout faire via l'API, le CLI, le serveur MCP ou l'interface utilisateur, sans jamais avoir l'impression d'avoir choisi la mauvaise porte.

L'interface utilisateur ne disparaîtra pas. Les humains continueront à l'utiliser pour les parties du travail qui bénéficient d'une surface visuelle, et c'est très bien ainsi. Mais ce n'est plus la porte d'entrée. C'est une porte parmi d'autres, et les autres portes se développent plus rapidement que la première.

Si votre produit ne tient pas debout lorsque l'interface utilisateur est fermée, c'est ce bogue qu'il faut corriger en premier.

Laissez votre LLM penser en anglais

2026-04-27T00:00:00Z

Vous livrez un chatbot pour votre équipe allemande. L'interface utilisateur est allemande. La documentation source est en partie allemande, en partie anglaise. Les outils derrière l'assistant attendent des valeurs d'enum en anglais, des descriptions de fonctions en anglais, des noms de produits en anglais, tout en anglais.

Puis quelqu'un pose une question tout à fait normale en allemand, le modèle choisit le bon outil, passe un argument en allemand au lieu de l'anglais, et tout s'écroule tranquillement.

J'ai vu des versions de ce type suffisamment souvent pour ne plus penser qu'il s'agit d'un problème de traduction. **C'est un problème d'exécution.

Mon défaut actuel est simple : laisser les utilisateurs parler la langue qu'ils veulent, mais laisser le LLM faire son travail de recherche, de raisonnement et d'outil en anglais lorsque la fiabilité est réellement importante. Je localise ensuite la réponse en dehors de cette boucle.

Cela semble légèrement hérétique à première vue. C'est aussi, à mon avis, la chose la plus pratique que vous puissiez faire à l'heure actuelle.

La recherche commence à le dire haut et fort

Les chiffres ne sont plus subtils.

Dans le [benchmark MASSIVE-Agents] (https://aclanthology.org/2025.findings-emnlp.1099/), les chercheurs ont évalué l'appel de fonctions multilingues dans 52 langues, 47 020 échantillons et 21 modèles. Le meilleur score moyen pour l'ensemble des langues n'était que de 34,05 %. L'anglais a atteint 57,37 %. L'amharique est tombé à 6,81 %.

Il ne s'agit pas d'une petite baisse de qualité. Il s'agit d'une chute de fiabilité.

Ensuite, il y a [Lost in Execution] (https://arxiv.org/abs/2601.05366), qui se rapproche encore plus du problème des systèmes réels. L'article montre que de nombreux échecs d'appels d'outils multilingues se produisent après que le modèle a déjà compris l'intention et sélectionné l'outil correct. Le problème dominant est l'inadéquation linguistique de la valeur des paramètres. En clair, le modèle savait ce qu'il fallait faire, mais il a exprimé les bits exécutables dans la langue de l'utilisateur au lieu de la langue de l'interface, de sorte que l'appel a quand même échoué.

Et cela ne se limite pas à l'appel d'outils. Dans [Do Multilingual Language Models Think Better in English ?] (https://aclanthology.org/2024.naacl-short.46/), Etxaniz et ses collègues ont constaté que l'autotraduction en anglais l'emportait systématiquement sur l'inférence directe en langue autre que l'anglais dans le cadre de cinq tâches. Leur formulation est d'une franchise rafraîchissante : les modèles sont "incapables d'exploiter pleinement leur potentiel multilingue lorsqu'ils sont sollicités dans des langues autres que l'anglais".

Alors oui, les modèles multilingues sont impressionnants. Mais si votre barre n'est pas "sonne plutôt bien" mais plutôt "doit se comporter correctement en production", l'anglais reste remarquablement souvent la langue d'exploitation la plus sûre.

Pourquoi les RAG se cassent au même endroit

Les gens entendent généralement cet argument et pensent d'abord aux agents. Appel de fonction, sortie structurée, exécution d'API, ce genre de choses.

RAG a la même faiblesse, juste une couche plus tôt.

Si votre couche de recherche doit faire correspondre la formulation locale d'un utilisateur à un contenu rédigé dans des langues différentes, avec une terminologie incohérente, des noms de produits traduits et des étiquettes de taxonomie à moitié localisées, vous augmentez les risques de dérive du système avant même que la génération ne commence. Honnêtement, c'est de là que viennent beaucoup de plaintes du type "le modèle n'est pas fiable". Le modèle peut être bon. L'interface de contenu ne l'est pas.

Je préférerais normaliser tôt.

Traduire la question en anglais. Récupérer les données à partir d'un corpus canonique anglais. Laisser le modèle raisonner sur une couche terminologique stable. Générer une ébauche de réponse en anglais si nécessaire. Traduire ou localiser la réponse finale pour l'utilisateur.

Vous disposez ainsi d'un endroit où la dénomination reste stable :

un titre de document canonique
un vocabulaire de produit canonique
un schéma d'outil canonique
un ensemble canonique d'étiquettes de recherche

Il est toujours possible de prendre en charge toutes les langues des utilisateurs à l'extérieur. Il suffit d'arrêter de demander au chemin d'exécution principal d'être parfaitement multilingue à chaque étape.

Ce n'est pas de l'anti-localisation

Au contraire.

Une mauvaise architecture d'IA multilingue nuit généralement d'abord aux utilisateurs locaux. Ils bénéficient d'une belle interface localisée, puis le système caché centré sur l'anglais se comporte de manière incohérente et leur en fait payer le prix.

Une localisation correcte signifie qu'il faut être honnête sur les points où la langue doit fléchir et ceux où elle ne doit pas le faire.

Pour moi, la répartition est la suivante :

Localiser l'interface utilisateur, les messages-guides, le texte d'aide, l'accueil et les réponses finales.
Localiser le contenu source que les gens lisent directement lorsque ce contenu doit exister sur le marché.
Conserver les définitions des outils internes, les identifiants canoniques, les étiquettes de recherche et les pivots de raisonnement en anglais s'il s'agit de la couche la plus stable.
Ajoutez un post-traitement explicite ou une révision humaine lorsqu'un résultat localisé a un poids juridique, réglementaire ou contractuel.

Ce dernier point est plus important que les équipes ne veulent l'admettre. Si le modèle s'adresse à un être humain, la localisation est une décision liée à l'expérience utilisateur. Si le modèle s'adresse à un autre système, la langue est un contrat d'interface.

Ce n'est pas la même chose.

L'architecture à laquelle je fais le plus confiance en ce moment

C'est la version sur laquelle je miserais aujourd'hui pour les produits d'IA multilingues :

L'utilisateur demande dans sa langue.
Le système traduit ou normalise la demande en anglais.
L'extraction, le raisonnement, le classement et les appels d'outils se font par rapport aux données canoniques anglaises.
La réponse finale est localisée dans la langue de l'utilisateur.
Les résultats à haut risque font l'objet d'une étape de validation supplémentaire avant de quitter le système.

Il ne s'agit pas d'une pureté philosophique. Elle est saine d'un point de vue opérationnel.

Ce qui est bien, c'est que des recherches récentes vont dans le même sens. [Lost in Execution] (https://arxiv.org/abs/2601.05366) a constaté que la pré-traduction des requêtes des utilisateurs permettait généralement de réduire les erreurs de concordance linguistique mieux que les corrections post-hoc, même si elle ne permettait pas encore de récupérer totalement les performances au niveau anglais. Cela correspond à ce que de nombreux constructeurs soupçonnent déjà dans la pratique. Si vous attendez la fin du projet pour corriger les incohérences multilingues, vous arrivez généralement trop tard.

Et oui, il y a des exceptions. Si vous construisez pour des langues à faibles ressources, des langues spécifiques à un domaine ou des formulations culturellement dépendantes, tout traduire en anglais peut introduire une dérive. L'article susmentionné met explicitement en garde à ce sujet. N'en faites donc pas un dogme.

Mais en tant que règle par défaut pour les copilotes d'entreprise, les assistants internes, les RAG multilingues et les agents utilisant des outils, je pense que la règle tient étonnamment bien la route.

Ce que cela signifie pour Rasepi

C'est exactement la raison pour laquelle je me soucie tant de la structure canonique du contenu.

Si votre base de connaissances dispose d'une couche source propre, d'une terminologie stable et d'une localisation contrôlée, il est plus facile de faire confiance à l'IA. Si chaque version linguistique dérive indépendamment à l'intérieur du chemin d'exécution, vous demandez au modèle d'improviser là où votre système devrait être précis.

Toute l'approche de Rasepi est construite autour de la séparation nette de ces préoccupations. Conserver un noyau canonique. Localiser délibérément. Repérer les variantes existantes. Ne pas prétendre que chaque couche de la pile doit être également multilingue simplement parce que l'interface utilisateur l'est.

J'avais l'habitude de penser que la meilleure expérience multilingue en matière d'IA signifiait "tout faire dans la langue de l'utilisateur". Ce n'est plus le cas aujourd'hui. Pas pour les systèmes qui doivent retrouver le bon paragraphe, choisir le bon outil et renvoyer quelque chose de fiable.

La règle pratique est simple : les utilisateurs doivent rester locaux, mais le chemin d'exécution du LLM doit rester stable. À l'heure actuelle, cela signifie généralement l'anglais au milieu et la localisation sur les bords**.

Cela changera avec le temps. J'espère que cela changera rapidement. Mais si vous expédiez aujourd'hui et que la fiabilité importe plus que l'esthétique, je laisserais le modèle penser en anglais et votre produit parler la langue de l'utilisateur.

Claude Design et l'agence créative unipersonnelle

2026-04-18T00:00:00Z

Hier, Anthropic a [lancé Claude Design] (https://www.anthropic.com/news/claude-design-anthropic-labs), un nouveau produit de l'équipe Anthropic Labs qui vous permet de créer des designs, des prototypes, des présentations et des documents marketing en parlant à Claude. J'ai regardé l'annonce en me disant : d'accord, une personne qui s'abonne à Claude a maintenant accès à la plupart des services offerts par une petite agence de création. Concevoir. Code. Automatisation. Présentations. Cohérence de la marque. Le tout dans le même écosystème.

C'est une phrase un peu folle à écrire en 2026. Mais je ne pense pas qu'elle soit exagérée.

Ce que Claude Design fait réellement

La version courte : vous décrivez ce dont vous avez besoin, et Claude crée une première version. Ensuite, vous l'affinez par le biais de conversations, de commentaires en ligne, d'éditions directes ou de curseurs personnalisés que Claude génère pour vous. Il est alimenté par [Opus 4.7] (https://www.anthropic.com/news/claude-opus-4-7) et il est étonnamment bon pour maintenir la cohérence visuelle.

Mais la fonctionnalité qui a attiré mon attention est l'onboarding. Lors de l'installation, Claude lit votre base de code et les fichiers de conception existants pour construire un système de conception pour votre équipe. Couleurs, typographie, composants. Chaque projet suivant suit automatiquement votre marque. Vous pouvez importer des images, des documents (DOCX, PPTX, XLSX), ou le diriger directement vers votre base de code. Un outil de capture Web permet de saisir des éléments de votre site Web réel afin que les prototypes ressemblent au produit réel.

Vous avez une maquette Figma sur laquelle vous voulez itérer ? Exportez-la, déposez-la dans Claude Design et entamez une conversation sur les modifications à apporter. Ou capturez simplement votre site web existant et dites "agrandissez la section du héros et ajoutez un carrousel de témoignages". Ce genre de choses.

Les témoignages recueillis lors de l'annonce sont éloquents. Le concepteur principal de produits de Brilliant a déclaré que leurs pages les plus complexes, qui nécessitaient [plus de 20 invites pour être recréées dans d'autres outils, ne nécessitaient que 2 invites dans Claude Design] (https://www.anthropic.com/news/claude-design-anthropic-labs). Le chef de produit de Datadog a décrit le passage d'une idée brute à un prototype fonctionnel avant que quiconque ne quitte la pièce, et a déclaré que ce qui prenait une semaine de briefs, de maquettes et de cycles de révision se produit maintenant en une seule conversation.

Une semaine d'allers-retours, réduite à une seule conversation. Pensez-y une seconde.

La pile qui change tout

C'est ici que les choses deviennent intéressantes. Claude Design n'existe pas de manière isolée. Anthropic dispose aujourd'hui de trois produits qui, combinés, couvrent une quantité absurde de terrain :

Claude Code : Écrire, réviser et expédier des logiciels réels. [2,5 milliards de dollars de chiffre d'affaires] (https://www.anthropic.com/news/anthropic-raises-30-billion-series-g-funding-380-billion-post-money-valuation) en février, responsable d'environ 4 % de tous les commits publics de GitHub dans le monde.
Claude Cowork** : Automatiser le travail de la connaissance. Recherche, analyse, traitement de documents, tâches récurrentes depuis votre bureau.
Claude Design** : Créez des travaux visuels. Prototypes, présentations, documents marketing, actifs cohérents avec la marque.

Et ils se passent le relais. Lorsqu'un projet est prêt à être réalisé, Claude le regroupe dans une liasse de transfert que vous pouvez transmettre à Claude Code avec une seule instruction. De la conception à la production en un seul flux. Pas de ticket Jira. Pas de réunion de transfert. Pas de "pouvez-vous m'envoyer les spécifications dans Slack".

Je n'arrête pas de penser à la prédiction de Sam Altman datant de début 2024 sur [l'entreprise d'un milliard de dollars composée d'une seule personne] (https://every.to/napkin-math/the-one-person-billion-dollar-company). À l'époque, cette prédiction semblait ambitieuse, voire un peu hyperbolique. Les outils n'existaient pas encore. Il était possible de générer du texte et des images, certes, mais le fossé entre la génération de choses et la livraison de produits réels était énorme.

Ce fossé se réduit rapidement.

Ce que j'aurais donné pour cela il y a deux mois

Quand j'ai construit Rasepi, le site de marketing était l'une des parties les plus fastidieuses. Pas le code. Le code était très bien, Claude manie le HTML et le CSS comme un champion. Mais les décisions en matière de conception visuelle ? La disposition des héros, les cartes des pages de prix, les tableaux de comparaison des fonctionnalités ? J'ai décrit les choses avec des mots, Claude a produit quelque chose, puis j'ai passé des heures à faire des allers-retours pour essayer d'ajuster l'espacement, les couleurs, la typographie. Tout cela à l'aide d'invites textuelles. Pas de boucle de rétroaction visuelle.

Avec Claude Design, ce flux de travail devient : "voici mon site web" (capture web), "redessinez la section des prix pour mettre l'accent sur le plan d'équipe" (conversation), ajustez la couleur verte avec un curseur, approuvez, passez le relais à Claude Code pour l'implémentation. J'estime que cela m'aurait permis d'économiser un week-end entier.

(Honnêtement, je suis un peu déçu que le projet n'ait pas été lancé deux mois plus tôt).

Et l'exportation vers Canva est astucieuse. [Canva compte 220 millions d'utilisateurs actifs (https://backlinko.com/canva-users) et réalise un chiffre d'affaires annuel de 3 milliards de dollars. Anthropic n'essaie pas de remplacer Canva. Elle essaie d'être l'endroit où les idées commencent avant d'atterrir dans Canva pour être peaufinées et distribuées. Il s'agit là d'un positionnement intelligent. Vous générez la création dans Claude Design, puis vous l'exportez vers Canva où votre équipe marketing la récupère. Ou exporter en PPTX pour la présentation aux investisseurs. Ou exporter en HTML autonome pour une page d'atterrissage.

Le multiplicateur "Il suffit d'ajouter des outils".

C'est le schéma que je continue d'observer dans l'espace IA en 2026. Le modèle de base devient plus intelligent, bien sûr, mais le véritable saut de productivité vient de la connexion des outils entre eux. Claude est un générateur de texte très intelligent. Claude avec Code est un ingénieur logiciel. Claude avec Cowork est un analyste de recherche. Claude avec Design est un directeur créatif. Claude avec les trois ? C'est une petite agence.

Et les connexions ne cessent de se développer. Anthropic a indiqué qu'elle ajouterait d'autres intégrations au cours des prochaines semaines. Les serveurs MCP permettent déjà de connecter Claude à des outils et des sources de données externes. L'écosystème se construit de lui-même.

Pour les fondateurs solitaires, les indépendants et les petites équipes, cela change complètement la donne. Vous n'avez pas besoin de faire appel à un designer pour produire des présentations et des prototypes de qualité professionnelle. Vous n'avez pas besoin d'un développeur frontal distinct pour transformer les maquettes en code. Vous n'avez pas besoin d'un chef de projet pour coordonner le transfert entre la conception et l'ingénierie, car il n'y a pas de transfert. Il s'agit d'une conversation continue.

Je ne dis pas que les concepteurs sont obsolètes, loin de là. Loin de là. Brilliant et Datadog ont tous deux décrit leurs concepteurs en utilisant Claude Design. L'outil permet aux bons concepteurs d'être plus rapides et donne à tous les autres l'accès à une production visuelle compétente. Ce n'est pas la même chose que de remplacer les gens.

Ce que cela signifie pour les produits de documentation

C'est une question que je surveille de près. Chez Rasepi, nous construisons une plateforme de documentation où la qualité visuelle est importante. Les pages d'entrée doivent être belles. Les guides de démarrage rapide ont besoin de diagrammes clairs. Les documents marketing doivent être cohérents d'une langue à l'autre et d'une équipe à l'autre.

Un monde où chaque membre de l'équipe peut générer une documentation visuelle conforme à la marque, la confier au moteur de traduction et la distribuer en sept langues sans toucher à Figma, Photoshop ou InDesign ? C'est exactement le problème que nous résolvons sous un angle différent. (Et oui, c'est exactement le type de flux de travail pour lequel Rasepi a été conçu).

La partie où cela devient étrangement cher

Voici donc la chose dont personne ne parle encore. J'ai créé un tout nouveau compte Anthropic spécifiquement pour essayer Claude Design. Nouveau compte, pas d'historique, pas d'utilisation antérieure. J'ai importé un petit fichier Figma et généré un seul asset. C'est tout. Deux opérations. Et je n'avais plus de crédits.

Sur un tout nouveau compte. Avec une nouvelle allocation.

Je ne sais pas à quoi ressemble le calcul des jetons du côté d'Anthropic quand Opus 4.7 fait de la génération visuelle, mais quoi qu'il en soit, il brûle les crédits à un rythme qui fait que le pitch "agence créative unipersonnelle" semble beaucoup plus cher que prévu. Si l'importation d'une petite maquette Figma et la production d'une image consomment la totalité de votre budget, l'utilisation de cet outil comme outil de conception quotidien n'est pas encore rentable.

Pour être honnête, il s'agit d'un aperçu de recherche et les prix changeront probablement. Mais pour l'instant, il existe un écart significatif entre la promesse (remplacer votre flux de travail de conception) et la réalité (vous risquez d'être à court de crédits avant le déjeuner). Les gains de productivité sont réels. Quant à savoir si le ratio crédits/production permet une utilisation régulière, c'est une toute autre question.

La mise en garde honnête

Claude Design est en avant-première de recherche. Il présentera des aspérités. Les témoignages proviennent d'équipes de conception d'entreprises bien financées et dotées de systèmes de conception bien établis. Votre kilométrage variera, en particulier si vous partez de zéro et que vous n'avez pas de directives de marque à respecter.

Mais la trajectoire est claire. Il y a dix-huit mois, il fallait un designer, un développeur et un chef de projet pour passer du concept à la page d'atterrissage expédiée. Aujourd'hui, une personne seule disposant d'un abonnement à Claude peut réaliser une version étonnamment crédible de ce même flux de travail en un après-midi.

Nous n'en sommes pas encore à l'entreprise unipersonnelle d'un milliard de dollars. Mais l'agence de création unipersonnelle ? Je pense que nous venons d'arriver.

Une clé API, plusieurs locataires : Comment nous isolons les traductions de DeepL à travers les clients

2026-04-18T00:00:00Z

Une question revient chaque fois que j'explique l'architecture de traduction de Rasepi à un autre développeur : "Attendez, tous vos locataires partagent une clé API DeepL ? Comment faites-vous pour que leurs glossaires et leurs règles de style ne s'infiltrent pas les uns dans les autres ?"

C'est une question légitime. Et la réponse implique plus de travail de conception que vous ne l'imaginez.

Nous avons abordé le [pipeline de traduction complet] (/fr/blog/inside-the-translation-engine-glossaries-style-rules-and-smart-retranslation/) dans un article précédent, le hachage au niveau des blocs, l'orchestrateur, l'ensemble du flux allant de l'enregistrement du document à la sortie traduite. Ce billet se penche sur le problème spécifique de la multi-location. Comment prendre une API tierce qui n'a pas de concept de locataires et construire une isolation de locataire au-dessus d'elle.

Le problème : DeepL ne connaît pas vos clients

L'API de DeepL s'authentifie à l'aide d'une seule clé d'API. Tout ce qui est créé sous cette clé, glossaires, listes de règles de style, historique des traductions, appartient au même compte. Il n'y a pas de notion de "ce glossaire appartient au locataire A" du côté de DeepL.

Lorsque vous appelez GET /v2/glossaries, vous obtenez tous les glossaires de tous les locataires. Lorsque vous créez une liste de règles de style, elle vit dans le même espace de noms que les règles de style de tous les autres locataires. L'API est plate.

Pour un produit auto-hébergé où chaque client exécute sa propre instance avec sa propre clé DeepL, c'est parfait. Pour un SaaS multi-locataires où nous gérons l'infrastructure ? Vous avez besoin d'une couche d'isolation.

La base de données est la source de vérité

Notre principale décision de conception : la base de données possède tout le contenu du glossaire et la configuration des règles de style. DeepL est une cible d'exécution, rien de plus.

Chaque entité TenantGlossary et TenantStyleRuleList implémente ITenantScoped, ce qui signifie que les filtres de requête globaux d'EF Core étendent automatiquement toutes les lectures au locataire actuel. Une requête pour des glossaires dans le contexte de requête du locataire A ne renverra jamais les entrées du locataire B. Il s'agit du même modèle d'isolation que nous utilisons partout dans Rasepi, appliqué au niveau de l'ORM.

Voici ce qui est intéressant. Lorsqu'un locataire modifie un terme du glossaire, nous n'appelons pas immédiatement DeepL. Nous mettons à jour la ligne de la base de données et définissons IsDirty = true. C'est tout. Le glossaire DeepL est créé (ou recréé) paresseusement, juste avant que la prochaine traduction n'en ait besoin.

public async Task<string?> GetOrSyncDeepLGlossaryIdAsync(
    string sourceLanguage, string targetLanguage)
{
    var glossary = await _db.TenantGlossaries
        .Include(g => g.Entries)
        .FirstOrDefaultAsync(g =>
            g.SourceLanguage == sourceLanguage &&
            g.TargetLanguage == targetLanguage);

    if (glossary?.Entries.Count == 0) return null;

    if (!glossary.IsDirty && glossary.DeepLGlossaryId is not null)
        return glossary.DeepLGlossaryId;

    // Dirty: delete old, create new
    if (glossary.DeepLGlossaryId is not null)
        await _deepL.DeleteGlossaryAsync(glossary.DeepLGlossaryId);

    var entries = glossary.Entries
        .ToDictionary(e => e.SourceTerm, e => e.TargetTerm);

    var created = await _deepL.CreateGlossaryAsync(
        $"rasepi-{glossary.Id}",
        glossary.SourceLanguage,
        glossary.TargetLanguage,
        entries);

    glossary.DeepLGlossaryId = created.GlossaryId;
    glossary.IsDirty = false;
    glossary.LastSyncedAt = DateTime.UtcNow;
    await _db.SaveChangesAsync();

    return glossary.DeepLGlossaryId;
}

Le filtre de requête sur TenantGlossaries assure l'isolation. Le drapeau IsDirty assure la synchronisation paresseuse. Et la convention de nommage (rasepi-{glossary.Id}) n'est utilisée que pour le débogage dans le tableau de bord DeepL, elle n'a pas d'utilité fonctionnelle.

Pourquoi paresseux ? Parce que les glossaires DeepL v2 sont immuables. Vous ne pouvez pas les modifier. Toute modification doit être supprimée et recréée. Si une équipe importe un CSV contenant 200 termes et corrige ensuite une faute de frappe dans une entrée, nous ne voulons pas supprimer et recréer le glossaire DeepL deux fois. Il suffit de définir IsDirty les deux fois et la recréation unique se produit lors de l'exécution de la traduction suivante.

Règles de style : même modèle, API différente

Les règles de style de DeepL sont plus récentes (API v3) et mutables, ce qui est plus agréable. Vous pouvez mettre à jour les règles configurées en place avec PUT /v3/style_rules/{style_id}/configured_rules, et les instructions personnalisées peuvent être ajoutées ou supprimées individuellement.

Nous utilisons toujours le même modèle IsDirty. Un TenantStyleRuleList a un DeepLStyleId qui correspond à l'identifiant d'exécution de DeepL, plus un ConfiguredRulesJson pour les règles de formatage et une collection d'entrées TenantCustomInstruction pour les directives de traduction en texte libre.

La véritable puissance réside dans ces instructions personnalisées. Chacune d'entre elles est une directive en langage clair, d'une longueur maximale de 300 caractères, qui détermine la manière dont DeepL traduit. Exemples réels de nos locataires :

Pour un cabinet d'avocats allemand : "Utilisez toujours la forme "Sie", jamais "du"".
Traduire "deployment" par "Bereitstellung", jamais par "Deployment", pour des termes dépendant du contexte qui dépassent les simples correspondances du glossaire.
Utiliser l'orthographe de l'anglais britannique (couleur, organisation, licence) pour une entreprise britannique qui traduit entre les différentes variantes de l'anglais.
"Placez les symboles monétaires après le montant numérique" pour les conventions européennes

Chaque locataire peut avoir des instructions complètement différentes par langue cible, toutes derrière la même clé API. L'isolation vient du fait que chaque appel de traduction n'inclut que les glossary_id et style_id appartenant au locataire demandeur. Les ressources DeepL des autres locataires ne sont jamais référencées.

L'appel de traduction : tout se compose

Lorsque l'orchestrateur traduit un bloc, il assemble tous les paramètres spécifiques au locataire en une seule demande :

var glossaryId = await _glossaryService
    .GetOrSyncDeepLGlossaryIdAsync(sourceLang, targetLang);
var styleId = await _styleRuleService
    .GetOrSyncStyleIdAsync(targetLang);
var formality = langConfig.Formality ?? "default";

var options = new TranslationOptions
{
    GlossaryId = glossaryId,
    StyleId = styleId,
    Formality = formality,
    Context = documentContext,
    ModelType = styleId != null ? "quality_optimized" : null
};

Chaque paramètre ici est spécifique à un locataire. Le glossaryId a été résolu par une requête filtrée par le locataire. Le styleId a été résolu de la même manière. Le formality provient du TenantLanguageConfig, qui a également été filtré par le locataire. Même le context (paragraphes environnants envoyés pour améliorer la qualité de la traduction, non facturés) provient du document du locataire.

Une chose que je tiens à souligner : lorsque style_id est défini, DeepL utilise automatiquement leur modèle quality_optimized. Vous ne pouvez pas combiner des règles de style avec latency_optimized. Il s'agit d'une contrainte de DeepL, mais honnêtement, elle est raisonnable. Si vous investissez dans des règles de style personnalisées, vous voulez probablement obtenir la meilleure qualité possible.

Mise en cache au niveau du bloc : la base de données comme mémoire de traduction

Nous n'appelons pas DeepL pour les blocs qui n'ont pas changé. Le mécanisme de mise en cache est la table TranslationBlock elle-même.

Chaque EntryBlock source a un ContentHash, un SHA256 de son contenu sémantique (avec des attributs de métadonnées comme blockId et deleted dépouillés). Chaque TranslationBlock stocke le SourceContentHash qui était en vigueur lorsque la traduction a été effectuée. Lorsque le bloc source change, son hachage change. L'orchestrateur compare les hachages et ne met en file d'attente que les blocs qui ne correspondent pas.

L'arbre de décision pour chaque bloc ressemble à ceci :

Les hashs correspondent, la traduction existe = ignorer (mis en cache, à jour)
Le code a changé, la traduction est automatique, la traduction n'est pas verrouillée = retraduire automatiquement.
Hash modifié, édité par l'homme ou verrouillé = marquer comme périmé, ne pas écraser

Ce troisième cas est crucial. Si votre traducteur allemand a affiné manuellement un paragraphe, nous ne le supprimons pas simplement parce que la source anglaise a changé. Nous le marquons comme périmé pour qu'il sache qu'il doit être révisé, mais le texte traduit reste intact.

Résultat pratique : la modification d'un paragraphe dans un document de 30 paragraphes déclenche exactement un appel à l'API DeepL (enfin, un lot qui comprend un bloc). Les 29 autres paragraphes, toutes langues confondues, sont déjà mis en cache et ne coûtent rien.

Pourquoi ne pas utiliser une clé distincte par locataire ?

J'y ai sérieusement réfléchi. Donner à chaque locataire sa propre clé d'API DeepL, éliminer complètement le problème d'isolation.

Trois raisons pour lesquelles nous ne l'avons pas fait :

**Chaque locataire aurait besoin de son propre abonnement à DeepL ou d'un moyen de fournir des sous-comptes. DeepL n'offre pas de gestion de clés multi-locataires de manière native.
**Le partage de l'infrastructure signifie le partage des limites tarifaires et des remises sur les volumes. Notre utilisation globale nous permet d'obtenir de meilleurs prix.
**Simplicité d'exploitation : une seule clé à changer, un seul quota à surveiller, une seule intégration à maintenir.

En contrepartie, nous avons besoin de la couche d'isolation que j'ai décrite. Mais étant donné que nous avons déjà des requêtes EF Core adaptées aux locataires pour tout le reste du système, l'ajouter aux glossaires et aux règles de style était simple. Le modèle existait déjà.

Ce qui vous protège réellement

Pour résumer les garanties d'isolation :

Les entrées du glossaire sont stockées dans TenantGlossary (implémente ITenantScoped), filtrées par les filtres de requête globaux d'EF Core. DeepL Les ID de glossaire sont des références opaques qui ne sont résolues que dans le contexte du locataire.
Les règles de style et les instructions personnalisées suivent le même modèle à travers TenantStyleRuleList.
Le contenu traduit** se trouve dans TranslationBlock, délimité par sa chaîne mère Entry → Hub, qui est également délimitée par le locataire.
La garde SaveChanges met en place TenantId automatiquement sur les nouvelles entités et la lance sur les écritures inter-locataires.
Pas de IgnoreQueryFilters()** dans le code de production. Jamais.

Le principe de conception est simple : DeepL voit les identifiants de ressources. Rasepi voit des entités à l'échelle du locataire. La correspondance entre les deux ne traverse jamais les frontières des locataires car la requête qui résout la correspondance est physiquement incapable de renvoyer les données d'un autre locataire.

Si vous construisez un SaaS multi-locataires qui s'intègre à des API tierces sans prise en charge native des locataires, ce modèle fonctionne bien. Traitez l'API externe comme un moteur d'exécution sans état, conservez toute la configuration dans votre propre base de données à l'échelle du locataire, synchronisez paresseusement et ne faites jamais confiance aux listes de ressources externes pour l'isolation.

Tokens Burned est la nouvelle ligne de code

2026-04-13T00:00:00Z

Mon fil LinkedIn en est rempli depuis des semaines. Ma timeline X aussi. Des gens qui postent des captures d'écran de dépenses en jetons comme s'il s'agissait de rapports d'avancement. Des fondateurs de startups qui se vantent d'avoir dépensé 16 000 $ pour Claude Code le mois dernier et qui visent 60 000 $ le mois prochain. Les classements. Des classements. Des titres comme "Légende des jetons" et "Dieu de l'IA".

Et puis, la semaine dernière, la masse critique a été atteinte. Forbes [a parlé du mouvement "tokenmaxxing"] (https://www.forbes.com/sites/richardnieva/2026/03/31/the-ai-gods-spending-as-much-as-they-can-on-ai-tokens/) qui balaie la Silicon Valley, où les entreprises rivalisent pour savoir qui brûlera le plus de jetons d'IA. Jensen Huang a déclaré sur le podcast All-In : Cet ingénieur à 500 000 dollars, à la fin de l'année, je lui demanderai : "Combien avez-vous dépensé en jetons ?". S'il me répond "5 000 dollars", je deviendrai fou. Si cet ingénieur de 500 000 dollars n'a pas consommé au moins 250 000 dollars de jetons, je serai très inquiet.

Puis [Fortune a rapporté] (https://fortune.com/2026/04/09/meta-killed-employee-ai-token-dashboard/) qu'un employé de Meta avait créé un tableau de classement interne appelé "Claudeonomics" pour suivre la consommation de jetons par les plus de 85 000 employés de la société. Les meilleurs utilisateurs recevaient des titres. Sur une période de 30 jours, l'utilisation totale a atteint 60 000 milliards de jetons. Le meilleur utilisateur individuel a consommé en moyenne 281 milliards. Mark Zuckerberg n'est même pas entré dans le top 250. Andrew Bosworth, directeur technique de Meta, a déclaré publiquement que son meilleur ingénieur dépensait l'équivalent de son salaire en jetons, mais qu'il était "5 à 10 fois plus productif". "C'est comme si c'était de l'argent facile", a déclaré Bosworth. "Aucune limite".

Je travaille dans le secteur des logiciels depuis suffisamment longtemps pour comprendre ce qui se passe ici. Il s'agit de "lignes de code" avec un prix beaucoup plus élevé.

We've been here before

En 2003, Martin Fowler a écrit [un court article sur les raisons pour lesquelles la productivité des logiciels ne peut être mesurée] (https://martinfowler.com/bliki/CannotMeasureProductivity.html) qui devrait probablement être une lecture obligatoire pour tous les cadres techniques. Son argument sur les lignes de code était précis :

"L'une de mes plus grandes irritations concerne les études de productivité basées sur les lignes de code. Tout bon développeur sait qu'il peut coder la même chose avec d'énormes variations dans les lignes de code."

Le problème est évident une fois qu'on le dit à haute voix. La LOC mesure l'activité, pas la production. Deux développeurs peuvent créer la même fonctionnalité : l'un écrit 1 200 lignes, l'autre 80. Le plus concis a probablement construit un meilleur système. Dans le cadre d'un régime LOC, le développeur verbeux semble plus productif.

Les équipes évaluées sur la base de la LOC ont réagi de manière rationnelle. Elles ont écrit plus de lignes. Elles ont copié-collé au lieu d'abstraire. Elles ont évité le remaniement parce que la suppression de code aurait nui à leurs résultats. La mesure a influencé le comportement, mais pas dans le sens d'un meilleur logiciel. Plus de code. Des systèmes moins bons.

En 2023, McKinsey a publié un article affirmant avoir trouvé une mesure objective de la productivité des développeurs. [La réponse détaillée de Gergely Orosz et Kent Beck (https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity) a mis en évidence le même défaut : presque tous les indicateurs de McKinsey mesuraient l'effort et la production, et non les résultats. Kent Beck a raconté avoir vu les enquêtes internes de Facebook sur le sentiment des développeurs se transformer d'un retour d'information utile en une négociation entre les managers et les ingénieurs pour obtenir des scores plus élevés. C'est ce qui se passe lorsque l'on encourage une mesure indirecte. Le chiffre s'améliore. La chose dont vous vous souciez réellement ne s'améliore pas.

On aurait pu penser que nous aurions appris. Ce n'est pas le cas.

Même erreur, unité différente

La logique séduisante du tokenmaxxing est la suivante. Consommation de jetons = utilisation de l'IA. Plus d'utilisation de l'IA = les équipes utilisent l'IA. Par conséquent, une forte consommation de jetons = une forte adoption de l'IA = une bonne chose.

Cette logique est précisément aussi erronée que celle qui consiste à mesurer les lignes de code, mais avec un tableau de bord de facturation au lieu d'un graphique de validation. Et pour être juste à l'égard de l'article de Forbes, le PDG de Sendbird, John Kim, a dit exactement cela : "Nous avons déjà vu ce film". Il faisait référence à la culture LOC des années 1990 et 2000. Le véritable indicateur, a-t-il fait remarquer, est la quantité de code généré par l'IA qui entre effectivement en production. Les dépenses en jetons "servent davantage à engager la conversation". Je suis d'accord avec cela. Cela devient un problème lorsque l'amorce de conversation est promue au rang d'indicateur clé de performance.

[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 avaient déjà utilisé des outils de codage de l'IA dans le cadre de leur travail. Cependant, une adoption organisationnelle significative nécessite des politiques claires, des flux de travail et des résultats mesurables liés à des résultats commerciaux réels. Il ne s'agit pas d'une simple utilisation. Pas seulement la consommation.

Boris Cherny, l'ingénieur à l'origine de Claude Code, a [partagé publiquement] (https://x.com/bcherny/status/2004626064187031831) qu'il n'a pas ouvert d'IDE du tout pendant un mois de travail, avec Opus 4.5 rédigeant environ 200 PR. C'est impressionnant. Mais ce qui est impressionnant, ce ne sont pas les tokens que ces 200 PR ont consommés. C'est qu'il s'agissait de 200 contributions fusionnées avec un logiciel fonctionnel à l'autre bout.

La valeur est dans le résultat. Les jetons sont l'énergie qui vous a permis d'y arriver, rien de plus.

Quand la métrique devient la cible

Il existe un principe appelé la loi de Goodhart : lorsqu'une mesure devient une cible, elle cesse d'être une bonne mesure. L'histoire du développement de logiciels est essentiellement un musée de la loi de Goodhart en action.

Le suivi des jetons en tant qu'indicateur clé de performance pour l'adoption de l'IA crée exactement la même dynamique. Les équipes d'ingénieurs évaluées sur la base de la consommation de jetons consommeront plus de jetons. C'est ainsi que fonctionnent les incitations. Vous voulez paraître plus productif ? Exécutez quelques boucles agentiques supplémentaires. Laissez le modèle raisonner longuement avant de générer des résultats. Enveloppez chaque tâche dans une couche d'orchestration qui appelle quatre outils là où un seul suffirait. Les dépenses en jetons augmentent. La valeur fournie n'augmente pas.

En fait, l'histoire de Claudeonomics l'a prouvé presque immédiatement. Fortune a noté que "certains employés ont fait travailler des agents d'intelligence artificielle pendant des heures pour maximiser l'utilisation de leurs jetons". Et voilà. La loi de Goodhart exécutée en temps réel, au sein d'une entreprise censée être à la pointe de la productivité induite par l'IA. Le tableau de classement était en place depuis quelques semaines avant d'être fermé, et les employés le jouaient déjà en faisant tourner des agents en boucle. La mesure datait de trois semaines et ne mesurait déjà plus ce qu'elle était censée mesurer.

Tout développeur lisant ceci peut probablement penser à cinq façons de gonfler les mesures d'utilisation des jetons sans que cela ne profite à personne. Je ne les énumérerai pas. Mais si je peux penser à cinq d'entre elles, les ingénieurs qui sont mesurés ici le peuvent aussi.

Andrej Karpathy a décrit [le moment actuel du génie logiciel] (https://x.com/karpathy/status/2004607146781278521) comme un "tremblement de terre de magnitude 9" pour la profession. Il a raison. Mais les tremblements de terre ne se mesurent pas à l'électricité consommée. Ils sont mesurés en fonction de ce qui a été déplacé.

La version de la documentation de ce problème

Ce n'est pas seulement un problème pour les équipes d'ingénieurs. Je constate la même dynamique dans la gestion des connaissances, qui est beaucoup plus proche de nous chez Rasepi.

"Nous avons publié 400 documents ce trimestre" est un chiffre qui sonne bien dans une présentation de diapositives. Il ne dit en rien si ces documents sont exacts, si quelqu'un les a lus ou si les informations qu'ils contiennent sont toujours d'actualité six mois plus tard. Il est possible d'atteindre ce chiffre grâce à l'IA et sans aucune réflexion. Le bruit assisté par des jetons est publié à grande échelle.

La mesure honnête est plus difficile à collecter mais beaucoup plus utile : quel pourcentage de votre base de connaissances reflète réellement la manière dont vos systèmes fonctionnent aujourd'hui ? Combien de personnes sont parvenues à une réponse correcte en utilisant votre documentation ? Combien ont essayé, ont échoué et ont fini par demander à quelqu'un sur Slack à la place ?

Ces questions n'ont pas encore de jolis tableaux de bord. Elles nécessitent une véritable réflexion sur ce que vous voulez que la documentation fasse pour votre organisation. (Ce n'est pas une coïncidence si c'est exactement le problème autour duquel Rasepi est construit. Les dates d'expiration forcées existent précisément pour que les équipes aient à se demander si le contenu est toujours valide, plutôt que de le laisser se décomposer silencieusement derrière un nombre de pages élevé).

Ce qu'il faut suivre à la place

La réponse honnête à la question "Notre investissement dans l'IA est-il rentable ?" ne peut pas être lue à partir d'un tableau de bord de facturation.

Vous pouvez l'approcher en posant de meilleures questions : les temps de cycle s'améliorent-ils ? Le rapport entre les fonctionnalités livrées et les bogues signalés évolue-t-il dans la bonne direction ? Les ingénieurs déclarent-ils qu'ils consacrent plus de temps au travail de jugement et moins à la dactylographie ? Votre documentation reste-t-elle à jour au lieu de s'accumuler comme des sédiments ?

Il est plus difficile de tirer ces informations d'une API. Elles nécessitent une réflexion sur les résultats que vous attendez réellement de vos équipes, ce qui, il faut le reconnaître, est le travail le plus difficile. Mais ce sont les questions qui comptent, parce qu'elles concernent les résultats plutôt que les intrants.

Les dépenses en jetons vous indiquent la quantité de calcul que vous avez achetée. La question de savoir si ce calcul est devenu quelque chose d'utile est tout à fait distincte. Les entreprises qui ne font pas cette distinction vont construire des tableaux de bord très coûteux qui ne leur montreront presque rien.

Nous avons passé des années à optimiser la mauvaise mesure de la productivité des développeurs. Il nous reste peut-être un trimestre avant que la même erreur ne soit intégrée dans tous les rapports sur l'adoption de l'IA dans les entreprises. La fenêtre pour éviter cela est ouverte, mais elle ne le restera pas.

La fracture de l'IA divise votre équipe en deux

2026-04-10T00:00:00Z

La semaine dernière, un ami m'a appelé pour me parler d'un de ses clients, une entreprise de logistique. Un chef d'équipe avait organisé une réunion de planification au cours de laquelle deux de ses collaborateurs avaient élaboré un modèle de scénario complet à l'aide de l'IA avant même le début de la réunion. Prévisions, ventilation des risques, trois approches alternatives. Les quatre autres membres de l'équipe se sont présentés avec le même format de diapositives qu'ils utilisaient depuis deux ans. Même structure, même processus manuel, mêmes estimations de délais.

La réunion a rapidement dérapé. Le binôme assisté par l'IA ne comprenait pas pourquoi les autres n'avaient pas fait la préparation de base qui "prend cinq minutes maintenant". Les autres se sont sentis pris au piège, comme si les règles du jeu avaient changé sans que personne ne le leur dise. Le chef d'équipe a passé le reste de la journée à limiter les dégâts.

Cette histoire ne me surprend plus. J'en entends des versions depuis des mois.

L'écart est désormais mesurable

Il ne s'agit pas seulement de vibrations. Le [2025 Work Trend Index] de Microsoft (https://www.microsoft.com/en-us/worklab/work-trend-index/2025-the-year-the-frontier-firm-is-born), une enquête menée auprès de 31 000 travailleurs dans 31 pays, a révélé que 67 % des dirigeants sont familiarisés avec les agents d'IA, contre seulement 40 % des employés. Les dirigeants sont beaucoup plus susceptibles de considérer l'IA comme un accélérateur de carrière (79 % contre 67 % des employés), et ils gagnent également plus de temps grâce à elle. Près d'un tiers des dirigeants affirment que l'IA leur fait gagner plus d'une heure par jour.

Mais voici la partie qui m'a le plus marqué : lorsqu'on leur a demandé comment ils voyaient l'IA, 52 % des répondants ont déclaré qu'ils la considéraient comme un outil de commande. Donnez-lui une instruction, vous obtiendrez un résultat. Seuls 46 % la décrivent comme un partenaire de réflexion, quelque chose avec lequel vous avez des échanges.

La différence n'est pas mince. Il s'agit de deux relations fondamentalement différentes avec la même technologie. Et ces deux groupes participent aux mêmes réunions, travaillent sur les mêmes projets et sont censés aller dans la même direction.

Deux vitesses, une équipe

La conséquence pratique est que les équipes fonctionnent désormais à deux vitesses complètement différentes. Les personnes qui ont intégré l'IA dans leur travail quotidien ne se contentent pas de produire plus rapidement. Ils pensent différemment. Ils abordent les problèmes différemment. Ils arrivent en réunion avec un travail qui prenait auparavant une semaine et qui a été réalisé en un après-midi.

Et les personnes qui n'ont pas adopté l'IA (ou qui l'ont essayée une fois, l'ont trouvée décevante et sont passées à autre chose) font un travail véritablement solide. Je tiens à le préciser. Ce n'est pas qu'ils sont mauvais dans leur travail. C'est que le plafond des possibilités s'est déplacé et qu'ils travaillent sous l'ancien plafond.

Une [étude de Harvard sur l'IA générative dans les équipes] (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5188231) a révélé quelque chose de remarquable : un seul individu doté d'une IA obtient de meilleurs résultats qu'une équipe entière qui n'en est pas dotée. Mais une équipe où tout le monde utilise l'IA est plus performante que toutes les autres. L'implication est brutale. L'adoption mixte ne permet pas de trouver un juste milieu. Elle crée des frictions.

J'ai pu le constater de visu lors d'un atelier que j'ai organisé le mois dernier. Les participants qui utilisaient régulièrement l'IA terminaient les exercices en deux fois moins de temps, puis se sentaient frustrés d'attendre le reste. Les participants qui n'utilisaient pas l'IA se sentaient bousculés et, honnêtement, un peu humiliés. Personne n'a voulu ce résultat. C'est simplement arrivé parce que l'écart de vitesse est maintenant si important.

L'avantage concurrentiel dont personne ne parle

C'est ici que les conséquences se font vraiment sentir. L'enquête de McKinsey sur l'état de l'IA en 2025 (https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai) a révélé que 88 % des organisations utilisent l'IA dans au moins une fonction. C'est une bonne chose, n'est-ce pas ? Mais près des deux tiers en sont encore aux phases d'expérimentation et de pilotage. Seul un tiers d'entre elles ont commencé à étendre l'IA à l'ensemble de leurs activités. Et les entreprises qui l'ont fait, celles que McKinsey appelle "les plus performantes" ? Elles représentent environ 6 % des répondants.

Ces 6 % s'éloignent de tous les autres à une vitesse que, je pense, la plupart des gens sous-estiment.

Les entreprises les plus performantes sont trois fois plus susceptibles d'avoir fondamentalement repensé leurs flux de travail autour de l'IA. Ils sont trois fois plus susceptibles d'avoir des dirigeants qui défendent activement l'utilisation de l'IA et donnent l'exemple. Les trois quarts d'entre eux sont en train d'étendre ou ont déjà étendu l'IA à l'ensemble de leur organisation, contre un tiers pour les autres.

Les données de Microsoft racontent une histoire similaire. Les entreprises qu'ils appellent "Frontier Firms" (celles qui ont déployé l'IA à l'échelle de l'organisation et qui ont atteint un niveau de maturité avancé) font état de résultats radicalement différents. 71 % des dirigeants des entreprises pionnières affirment que leur entreprise est prospère, contre 39 % des travailleurs à l'échelle mondiale. 55 % d'entre eux déclarent pouvoir accepter plus de travail, contre 25 % au niveau mondial. Et ils ont moins peur que l'IA prenne leur travail, pas plus.

L'écart entre ces entreprises et toutes les autres ne se réduit pas. Il s'accélère.

Il s'agit d'un problème humain déguisé en problème technologique.

La tentation est grande de résoudre ce problème à l'aide d'outils. Lancer Copilot, acheter quelques licences, envoyer un courriel à toute l'entreprise sur les ressources en IA. C'est fait.

Mais le véritable défi est d'ordre culturel. C'est le chef d'équipe qui, lors de cet appel, tente de maintenir la cohésion d'un groupe dont la moitié des membres se sentent suralimentés et l'autre moitié laissée pour compte. C'est le manager qui doit expliquer à un vétéran de 20 ans que son flux de travail, celui qu'il a perfectionné pendant une décennie, n'est peut-être plus la meilleure approche. C'est l'employé junior qui utilise discrètement l'IA pour produire un travail de haut niveau et qui ne sait pas s'il doit être fier ou s'inquiéter des retombées politiques.

Microsoft a constaté que 47 % des dirigeants considèrent l'amélioration des compétences des employés existants comme l'une de leurs principales stratégies en matière de main-d'œuvre. C'est encourageant, je suppose. Mais l'amélioration des compétences ne fonctionne que si les gens veulent réellement apprendre. Or, à l'heure actuelle, une grande partie de la main-d'œuvre a décidé que l'IA n'était pas pertinente pour elle, qu'elle n'était pas fiable ou qu'elle ne valait pas la peine d'être utilisée. Certains d'entre eux peuvent avoir raison en ce qui concerne des outils spécifiques. Mais la trajectoire générale n'est pas optionnelle (je dis cela en tant que personne qui a été sceptique à l'égard de nombreux cycles d'engouement pour la technologie au fil des ans, et celui-ci semble différent).

Où cela nous mène

Je ne pense pas que le fossé disparaisse. Je pense qu'il s'élargit. Les personnes qui adoptent l'IA continueront à devenir plus rapides, à produire plus, à élever la barre de ce qu'est une "production normale". Ceux qui ne le font pas ressentiront une pression croissante, que ce soit de la part de leur direction, de leurs pairs ou simplement de la réalité ambiante, à savoir que leurs collègues font des choses qu'ils ne peuvent pas faire.

Les entreprises qui trouveront le moyen d'amener toute leur équipe à progresser, et pas seulement les enthousiastes, bénéficieront d'un véritable avantage. Et cet avantage s'accumule. Chaque mois de maîtrise organisationnelle de l'IA est un mois que vos concurrents passent à se demander s'ils doivent acheter des licences ChatGPT.

Le plus grand avantage concurrentiel à l'ère de l'IA ne sera pas le modèle que vous utiliserez. Le plus grand avantage concurrentiel à l'ère de l'IA ne sera pas le modèle que vous utiliserez, mais le fait que toute votre équipe l'utilise réellement.

L'équipe logistique dont j'ai parlé ? Mon ami m'a dit que le chef d'équipe avait réservé un atelier interne de deux jours. Pas "voici comment faire une demande". Mais plutôt "voici comment cela change la façon dont nous planifions ensemble". Les sceptiques avaient besoin de voir ce qui était possible dans le contexte de leur travail, pas dans une démo générique avec un scénario inventé. Et les enthousiastes devaient apprendre la patience. À amener les gens avec eux au lieu de courir devant eux.

C'est ce qui semble être le travail à faire en ce moment. Ne pas se contenter d'adopter l'IA. Combler le fossé. Avant qu'elle ne vous ferme la porte.

Construire vs acheter réimaginé : Ce que cela signifie réellement en 2026

2026-04-07T00:00:00Z

La semaine dernière, j'ai vu un développeur junior de notre équipe créer une application CRUD fonctionnelle avec authentification, migration de base de données et une interface utilisateur à peu près décente en 90 minutes. Avec Copilot. En partant de zéro.

Il y a cinq ans, cette même tâche aurait pris une semaine. Peut-être deux si l'on compte les configurations de déploiement et les flux OAuth. Et ce changement, cette compression du temps de construction de jours en heures, est en train de démanteler tranquillement l'une des plus vieilles questions en matière de logiciels : devons-nous construire ou acheter ?

L'ancien cadre est mort

Pendant des décennies, la question "construire ou acheter" était un calcul de coût. On évaluait le nombre de mois-développeur nécessaires à la création d'un produit, on le multipliait par le salaire, on ajoutait une marge pour la maintenance et on le comparait au prix de la licence annuelle d'un produit SaaS qui faisait à peu près la même chose. Si le SaaS était moins cher, vous l'achetiez. Si vos besoins sont suffisamment étranges, vous construisez.

Ce cadre supposait que la construction était coûteuse. Et c'était le cas. Mais [selon les données Octoverse 2025 de GitHub] (https://github.blog/ai-and-ml/generative-ai/how-ai-is-reshaping-developer-choice-and-octoverse-data-proves-it/), le développement assisté par l'IA produit désormais une augmentation de 20 à 30 % du débit. Quatre-vingt pour cent des nouveaux développeurs sur GitHub utilisent Copilot au cours de leur première semaine. Plus de 1,1 million de dépôts publics intègrent déjà les SDK LLM. La construction est devenue nettement moins chère, presque du jour au lendemain.

La question n'est donc plus vraiment "construire ou acheter". Il s'agit plutôt de savoir ce que vous payez réellement lorsque vous achetez un SaaS.

Le nouveau calcul

Voici ce que je pense que la plupart des fondateurs de SaaS (moi y compris, honnêtement) ne veulent pas entendre : si toute votre proposition de valeur est " nous vous avons évité de le construire ", vous êtes dans le pétrin. Parce que ce fossé vient de devenir beaucoup moins profond.

Lorsqu'une équipe peut prototyper un outil interne fonctionnel en une journée, la barre de ce qui justifie un abonnement mensuel s'élève considérablement. Vous ne devez pas seulement être meilleur que ce qu'ils pourraient construire. Vous devez être meilleur que ce qu'ils pourraient construire avec l'aide de l'IA.

[Gartner a prédit en avril 2026] (https://www.gartner.com/en/newsroom/press-releases/2026-04-02-gartner-expects-most-enterprises-to-abandon-assistive-ai-for-outcome-focused-workflow-by-2028) que d'ici 2028, plus de la moitié des entreprises cesseront de payer pour l'intelligence d'assistance et privilégieront les plateformes qui s'engagent à fournir des résultats en matière de flux de travail. Plus grave encore : d'ici à 2030, les éditeurs de logiciels qui superposent l'IA aux applications existantes au lieu de les repenser pour une exécution agentique devront faire face à une compression de leurs marges pouvant aller jusqu'à 80 %.

Quatre-vingts pour cent. Il ne s'agit pas d'une erreur d'arrondi.

Alors, qu'est-ce qui survit vraiment ?

J'ai beaucoup réfléchi à cette question, en partie parce que nous construisons Rasepi et que je dois être honnête avec moi-même quant à notre valeur. Et je pense que la réponse se résume à trois choses qui sont vraiment difficiles à reproduire en un week-end de codage, quelle que soit la qualité de votre assistant IA.

**N'importe qui peut créer un éditeur de texte. Construire un système de traduction qui suit les changements de contenu au niveau du paragraphe, détecte les traductions périmées grâce au hachage du contenu et gère l'adaptation structurelle entre les langues ? Cela nécessite des années de connaissances dans le domaine, intégrées dans l'architecture. L'IA peut vous aider à écrire le code plus rapidement, mais elle ne peut pas vous dire quoi construire.

Il faut toujours que quelqu'un l'exécute et l'entretienne. Ce qu'il y a de bien avec la construction : c'est amusant. La maintenance ? Pas amusant du tout. Gérer les cas limites dans les systèmes de permission multi-locataires, suivre les bizarreries des navigateurs, gérer les migrations de bases de données à travers les versions, patcher les CVE à 2 heures du matin, gérer ce bug d'exportation PDF qui n'apparaît que dans Safari. L'IA accélère la création initiale, c'est certain. Mais [l'étude Forrester d'avril 2026] (https://www.forrester.com/press-newsroom/forrester-three-years-into-genai-enterprises-are-still-chasing-its-true-transformative-value/) montre que la plupart des entreprises ne peuvent toujours pas transformer l'adoption de l'IA en impact mesurable, en partie parce que la partie la plus difficile n'a jamais été d'écrire du code. Il s'agit de faire fonctionner l'outil, de le mettre à jour et de le faire fonctionner correctement pendant des années. La construction est la partie la plus facile. C'est le temps de fonctionnement, les rotations d'astreinte et les corrections incrémentielles qui vous coûtent réellement.

**La confiance, la sécurité et la confidentialité des données sont des aspects sous-estimés. Lorsque vous construisez quelque chose vous-même, vous êtes responsable de la sécurité. Vous êtes responsable du cryptage au repos, de l'enregistrement des audits, des tests de pénétration, de la conformité au GDPR, de SOC 2 et de la prochaine réglementation dont personne n'a encore entendu parler. Un bon fournisseur de SaaS dispose d'une équipe entière dont le seul travail consiste à s'assurer que vos données ne se retrouvent pas à un endroit où elles ne devraient pas être. Pour la plupart des entreprises, ce n'est pas un coût qu'elles veulent supporter en interne. Et honnêtement, la plupart des outils internes que j'ai vus n'ont même pas de contrôles d'accès appropriés, sans parler d'une piste d'audit de sécurité.

La solution intermédiaire composable

Ce qui est intéressant, c'est que, de plus en plus, la réponse n'est pas "construire" ou "acheter". Il s'agit de composer. Choisissez les outils SaaS qui font bien les choses difficiles, exposent de bonnes API et vous permettent de construire autour d'eux.

C'est pourquoi les architectures de plugins sont si importantes en ce moment (et oui, c'est exactement ce dans quoi nous avons investi avec le système de plugins de Rasepi). Les produits SaaS qui prospéreront sont ceux qui disent : "Nous nous occupons du noyau dur, spécifique à un domaine, et vous personnalisez tout le reste. Vous personnalisez tout le reste". Et non pas "voici notre monolithe, à prendre ou à laisser".

[Le rapport d'avril 2026 de Forrester (https://www.forrester.com/press-newsroom/forrester-three-years-into-genai-enterprises-are-still-chasing-its-true-transformative-value/) a révélé que la plupart des entreprises ont encore du mal à transformer l'adoption de l'IA en un impact commercial mesurable. Les entreprises qui adoptent massivement l'IA sont 47 % plus susceptibles de travailler avec des partenaires consultants pour préparer leurs données et leurs systèmes. Le message est clair : la capacité de construction brute n'est pas le goulot d'étranglement. C'est le fait de savoir quoi construire et d'avoir l'infrastructure nécessaire pour le faire qui constitue la véritable contrainte.

Ce que cela signifie pour SaaS

Si vous dirigez une entreprise SaaS en 2026, je pense qu'il y a quelques vérités gênantes :

Votre argumentaire "nous allons vous faire gagner du temps" est plus faible que jamais.** Le gain de temps était l'argument de vente classique du SaaS. Mais lorsque l'IA comprime le temps de construction de 20 à 30 %, le chiffre du "temps gagné" dans votre feuille de calcul du retour sur investissement diminue proportionnellement. Vous avez besoin d'une histoire différente.
Les caractéristiques sont des enjeux de table, les résultats sont le produit.** Personne ne se soucie de savoir si vous avez 47 intégrations. Ce qui compte pour eux, c'est que leur documentation reste à jour, que leurs traductions soient exactes et que leur équipe utilise réellement l'outil. Le langage de Gartner sur le "flux de travail axé sur les résultats" n'est pas seulement un jargon d'analyste. C'est la direction que prend le marché.
L'instinct de fermer sa plateforme et de rendre le changement difficile est compréhensible. Mais Gartner a explicitement averti que "les fournisseurs de SaaS traditionnels qui tentent de fermer les systèmes d'enregistrement risquent d'être contournés par les couches d'orchestration auxquelles les entreprises font davantage confiance". Ouch.

La version honnête

Je vais vous dire franchement ce que je pense de cette question. Construire ou acheter n'a jamais été une question de technologie. Il s'agissait toujours d'une question de confiance. Est-ce que je fais confiance à ce fournisseur pour comprendre mon problème suffisamment en profondeur pour que sa solution soit meilleure que celle que je pourrais bricoler ?

En 2026, la notion de "bricolage" a été considérablement améliorée. La barre de confiance s'est donc également élevée.

Pour nous, à Rasepi, cela signifie que nous ne pouvons pas nous contenter d'être un outil de documentation qui prend en charge les traductions. Nous devons être tellement bons dans les problèmes difficiles, le suivi des traductions au niveau des blocs, l'application de la fraîcheur du contenu, la complexité multi-tenant, que la construction d'un remplaçant serait vraiment pénible, même avec les meilleurs outils d'IA au monde.

C'est la nouvelle question "construire ou acheter". Il ne s'agit pas de savoir si l'on peut le construire, mais s'il faut dépenser de l'énergie pour le construire alors que quelqu'un d'autre a déjà résolu les problèmes les plus ardus.

La question n'a jamais vraiment porté sur le coût. Il s'agissait de savoir où l'on voulait consacrer son attention. Et dans un monde où la construction est bon marché, l'attention est la seule ressource rare qui reste.

Trois semaines, une application : Ce que l'IA peut construire pour vous et ce qu'elle ne peut absolument pas faire

2026-04-05T00:00:00Z

Il y a trois semaines, j'avais un backend .NET avec peut-être 40 % des services connectés, un frontend Vue à moitié terminé et un plan vague. Aujourd'hui, Rasepi dispose d'un moteur de traduction au niveau du bloc avec gestion de glossaire et règles de style, d'un système de notation de la fraîcheur avec modèles d'expiration et flux de travail de révision, d'une recherche sémantique alimentée par l'IA avec RAG, d'un SDK de plugin complet avec action guards et event pipelines, d'une édition collaborative en temps réel, d'un site web marketing complet avec pages de tarification, d'un portail de documentation pour les développeurs, d'un blog avec 14 articles, de traductions automatisées en 7 langues et d'un formulaire de liste d'attente qui envoie réellement des courriels.

Je n'ai pas fait cela tout seul. J'ai fait tourner Claude dans VS Code tous les soirs pendant des heures et parfois même toute la journée, et cela a été une véritable transformation pour les parties qu'il pouvait aider. Mais il y a un gouffre entre "construire une application" et "avoir quelque chose que vous pourriez réellement vendre à un autre être humain", et ce gouffre est rempli de tonnes de pages d'installation, de configuration manuelle, de paramètres de délivrabilité des courriels et d'enregistrements DNS. Claude ne peut pas encore communiquer avec tous ces services.

Les gens parlent rarement de cette partie.

Est-ce que j'aurais pu faire ça sans l'IA ?

J'ai plus de 30 ans d'expérience dans la création de logiciels. Aurais-je pu construire tout cela sans Claude ? Probablement. Mais pas en trois semaines. Loin s'en faut. L'IA a accéléré tout ce qui implique de taper du code dans des fichiers, et c'est une partie importante de tout projet.

Mais il y a une chose que les gens oublient lorsqu'ils parlent de "vibrocodage" et de construction d'applications entières avec l'IA : il faut toujours savoir ce que l'on fait : **Claude peut vous indiquer toutes les étapes nécessaires pour déployer un Cloudflare Worker avec une base de données D1. Il peut vous guider dans la configuration d'OpenIddict. Il peut expliquer les enregistrements DNS et la configuration de SPF. Le problème est que ses connaissances sont souvent obsolètes. Les plateformes mettent à jour leurs tableaux de bord, déplacent les paramètres, suppriment des fonctionnalités, renomment des choses. Et Claude ne le sait pas.

Je n'ai même pas utilisé qu'une seule IA. ChatGPT en savait parfois plus sur des services spécifiques, en particulier lorsque les données de formation de Claude avaient quelques mois de retard sur la documentation d'une plateforme particulière. Certains jours, j'avais les deux IA ouvertes côte à côte, croisant leurs suggestions avec ce que je voyais réellement dans le tableau de bord.

Et puis il y a Codex. J'ai souvent utilisé le Codex d'OpenAI pour analyser la base de code de l'extérieur. Non pas pour écrire du code, mais pour le réviser. Le fait qu'un autre agent examine le code que Claude a écrit permet de déceler des choses auxquelles Claude lui-même n'a pas accès. C'est comme avoir une deuxième paire d'yeux sur une demande de retrait, sauf que les deux réviseurs sont des IA et qu'aucun d'entre eux ne s'offusque. J'ai pointé Codex sur une couche de service et j'ai demandé " qu'est-ce qui ne va pas avec ça ? " et il a trouvé des problèmes que Claude avait introduits avec confiance il y a trois sessions. Les différents modèles ont des angles morts différents, et les confronter les uns aux autres permet d'obtenir de meilleurs résultats que de faire confiance à un seul d'entre eux.

Mais le point le plus important est le suivant : pour avoir une application vendable, vous devez absolument savoir comment fonctionne l'hébergement. Comment fonctionnent les domaines. Comment fonctionnent les certificats de signature de code. Comment fonctionnent les bases de données. Comment fonctionne la délivrabilité des courriels. Comment les flux OAuth2 fonctionnent réellement, et pas seulement le code qui les met en œuvre. Pouvez-vous créer une application sans ces connaissances ? Bien sûr, mais cela vous mènera-t-il quelque part ? Probablement pas. Vous aurez quelque chose qui tourne sur localhost et qui n'impressionne personne en dehors de votre propre machine.

Les 80 % qui ressemblent à de la magie

Laissez-moi être clair sur ce qui a fonctionné, parce que cela a vraiment bien fonctionné. Pour créer des interfaces de service, implémenter des contrôleurs CRUD, écrire des configurations EF Core et construire des composants Vue, Claude est absurdement rapide.

Voici un exemple. Lorsque j'ai eu besoin d'ajouter un système de gestion de glossaire, j'ai décrit les besoins : glossaires adaptés aux locataires, importation/exportation CSV, CRUD pour les termes individuels, et un mécanisme de synchronisation avec l'API de glossaire de DeepL. Claude a produit les modèles d'entité, les interfaces de service et les interfaces de service pour le système de gestion de glossaire. Claude a produit les modèles d'entités, l'interface et l'implémentation du service, le contrôleur avec les attributs d'autorisation appropriés et le magasin Pinia. Le tout en 20 minutes environ. Il m'aurait fallu plus d'une journée pour écrire tout cela à la main.

Le moteur de traduction était similaire. L'architecture au niveau du bloc avec le hachage du contenu SHA256, la détection de la staleness, l'orchestrateur qui coordonne entre les services. Claude a compris le modèle après l'avoir expliqué une fois et l'avoir reproduit de manière cohérente sur des dizaines de fichiers. Le système de notation de la fraîcheur, les flux de travail de révision, le pipeline de notification d'expiration. Service après service, connecté et fonctionnel.

Pour le site de marketing, Claude a construit des pages HTML entières à partir de descriptions. "Une page de prix avec un niveau gratuit, un niveau équipe et un niveau entreprise. Fond sombre. Utiliser l'accent vert." Et il a juste... produit une page. Y compris les points de rupture réactifs et les états de survol.

C'est la partie magique. C'est réel.

Apprivoiser la machine

Mais ce n'est pas comme si j'avais simplement tapé "construisez-moi une application" et que j'étais parti. Travailler avec Claude est une compétence à part entière, et j'ai passé les premiers jours à mal le faire.

Le résultat initial est toujours... bon. Techniquement correct, raisonnablement structuré, mais générique. Claude écrit du code comme il écrit de la prose : compétent, prévisible et profondément moyen. Laissé à lui-même, il produira la même structure de contrôleur que tous les tutoriels de frameworks. Le même modèle de service. La même disposition des composants. Cela fonctionne, mais ce n'est pas le vôtre.

Vous commencez donc à l'entraîner. Pas de manière formelle, pas avec des réglages fins, mais par la répétition et la correction. "Non, je veux que l'interface de service soit séparée de l'implémentation. "Utilisez toujours ce modèle d'attribut d'autorisation." "Le contexte du locataire provient de l'intergiciel, pas du corps de la requête." Tour après tour après tour. Certains jours, j'avais l'impression d'être en train de programmer en binôme avec un junior très enthousiaste qui n'arrêtait pas d'oublier ce que nous avions décidé hier.

Et puis, il y a eu un déclic. Après suffisamment de corrections, après suffisamment d'exemples dans la base de code pour qu'il puisse les lire, Claude commence à faire les choses correctement du premier coup. Il comprend vos conventions de nommage. Il sait où vous placez vos DTO. Il suit votre modèle de gestion des erreurs sans qu'on le lui demande. Cette transition de "gênant" à "productif" a pris environ quatre ou cinq jours de travail régulier.

Il en a été de même pour les articles de blog. La voix d'écriture par défaut de Claude est immédiatement reconnaissable. Ce style poli, légèrement distant, parfaitement structuré, qui se lit comme tous les billets de blog générés par l'IA que vous avez déjà vus. J'ai construit un guide de style à plusieurs reprises, en lui donnant des exemples de ma façon d'écrire, en lui faisant remarquer chaque " il est bon de le noter " et chaque tiret em (sérieusement, l'addiction au tiret em est réelle). Finalement, j'ai créé tout un fichier de compétences, un ensemble d'instructions que Claude charge avant d'écrire quoi que ce soit pour le blog Rasepi.

Ce billet, pour mémoire, c'est Claude. Avec mes commentaires, mes corrections, ma direction. J'ai décrit ce que je voulais dire, je l'ai dirigé vers le guide de style, puis j'ai passé du temps à faire des allers-retours jusqu'à ce que la voix me semble correcte. C'est le véritable flux de travail. Ce n'est pas "l'IA l'écrit" ni "je l'écris". C'est une conversation qui produit quelque chose qu'aucun de nous n'aurait écrit seul.

J'ai également élaboré des instructions personnalisées pour la base de code elle-même. Un fichier d'instructions pour le copilote qui explique l'architecture, le système de traduction, les règles d'isolation des locataires, les conventions de codage. Claude le lit au début de chaque session, et la différence se fait jour et nuit. Sans ce fichier, Claude devine. Avec, Claude sait.

Le fait est que les gains de productivité sont réels, mais ils ne sont pas gratuits. Vous investissez du temps au départ pour apprendre à l'IA comment vous travaillez, et cet investissement est rentabilisé au fil des semaines. Si vous sautez cette étape, vous passerez plus de temps à corriger les résultats de Claude que vous n'en auriez passé à écrire le code vous-même.

Quand la machine vous combat

Je ne veux pas brosser un tableau trop rose de la situation. Pour chaque session où Claude a réussi à implémenter un service complexe en 20 minutes, il y a eu une autre session où il m'a mis au pied du mur.

La pire habitude est de réintroduire des bogues qui ont été corrigés il y a plusieurs jours. Vous passez une soirée à traquer une condition de course dans le hub SignalR, vous la corrigez et vous passez à autre chose. Trois jours plus tard, Claude modifie un fichier voisin et réintroduit discrètement l'ancien modèle brisé. Ce n'est pas malintentionné, évidemment. Il ne s'en souvient tout simplement pas. Chaque session recommence, et si la correction n'était pas évidente à partir du code seul, Claude reviendra volontiers au modèle que ses données d'apprentissage préfèrent. J'ai appris à écrire des commentaires très explicites au-dessus des corrections délicates. Pas pour les futurs développeurs. Pour les futurs Claude.

Ensuite, il y a le cercle. Vous demandez à Claude de corriger un test défaillant. Il modifie quelque chose. Le test échoue toujours. Il change autre chose. Le test échoue encore. Il annule la première modification et essaie une troisième chose. Il combine ensuite la première et la troisième modification. Puis il revient à la deuxième approche, mais avec une légère variation. Trente minutes plus tard, vous l'avez vu essayer neuf permutations de la même idée erronée et pas une seule fois il ne s'est arrêté pour reconsidérer si l'ensemble de l'approche était erronée. J'ai eu des sessions où j'ai finalement dit "arrêtez, laissez-moi regarder ça" et j'ai trouvé le vrai problème en deux minutes environ. Il s'agissait d'une correction d'une seule ligne. Claude avait passé une demi-heure à réarranger les chaises longues.

Et la confiance. Claude ne dit jamais "Je ne suis pas sûr de ça". Il présente chaque suggestion avec la même autorité calme, qu'il s'agisse d'une solution parfaite ou d'une absurdité totale. Après un certain temps, vous développez un instinct pour savoir quand il devine, mais au début, j'ai perdu beaucoup de temps à mettre en œuvre des suggestions qui semblaient raisonnables et qui se sont avérées être des méthodes d'API hallucinées ou des modèles de configuration obsolètes.

C'est exactement la raison pour laquelle j'ai commencé à utiliser le Codex pour examiner les résultats de Claude. Et c'est pourquoi l'argument de l'expérience est si important. Un développeur débutant ne verrait pas ces régressions. Il ne reconnaîtrait pas les cercles. Il se fierait à l'hallucination confiante. Trente ans de connaissance de ce à quoi ressemble un code correct, c'est la différence entre l'IA en tant que multiplicateur de productivité et l'IA en tant que moyen très rapide de créer de la dette technique.

Ensuite, il faut réellement déployer la chose

C'est ici que l'histoire change.

Vous avez une application qui fonctionne sur localhost. Magnifique. Maintenant, mettez-la sur Internet. Faites en sorte qu'elle envoie des courriels. Laissez les gens s'inscrire. Accepter des paiements éventuellement. Protégez-le des robots. Donnez-lui un nom de domaine qui se résout correctement.

Claude ne peut pas vous aider pour tout cela. Pas vraiment.

Je ne veux pas dire qu'il produit de mauvaises suggestions. Je veux dire qu'il ne peut fondamentalement pas interagir avec les systèmes que vous devez configurer. Et c'est à la configuration que vous consacrez votre temps, pas à l'écriture de code.

Cloudflare : Une étude de cas pour "se débrouiller tout seul"

Le site de marketing de Rasepi fonctionne sur des pages Cloudflare. L'API de la liste d'attente est un Cloudflare Worker avec une base de données D1. Cela semble simple jusqu'à ce que vous ayez à le mettre en place.

Claude n'a jamais vu votre tableau de bord Cloudflare. Il peut vous dire "ajouter un enregistrement CNAME" mais il ne peut pas vous dire lequel des 14 onglets contient les paramètres DNS pour votre domaine particulier. Les liaisons de base de données D1 nécessitent un identifiant de base de données spécifique dans votre wrangler.toml. Les secrets d'environnement passent par wrangler secret put. CORS doit correspondre à vos origines réelles déployées, et non à localhost. Turnstile a besoin de clés provenant d'une autre section du tableau de bord.

J'ai passé presque une journée entière à faire en sorte que le Worker vérifie correctement les tokens Turnstile, accepte les soumissions de formulaire, les stocke dans D1, et envoie des emails de confirmation. Claude m'a aidé à écrire le code du Worker lui-même. Mais le déploiement, la configuration du wrangler, la gestion des secrets, le débogage de la propagation DNS ? Tout cela, c'est moi qui l'ai fait.

OAuth2 : Le labyrinthe de la configuration

L'authentification est le meilleur exemple du fossé qui sépare le "code" du "produit".

Claude peut tout à fait vous écrire une intégration OAuth2. Il connaît la spécification OIDC, il peut produire un middleware, il comprend les revendications JWT. Pour notre environnement de développement, j'ai un DevAuthHandler qui frappe des jetons avec des revendications tenant_id et sub à partir d'un simple modèle de chaîne de caractères. Claude a écrit cela en quelques minutes.

Mais l'authentification de production signifie OpenIddict, et OpenIddict signifie comprendre les revendications sub, les revendications tenant_id, les URL de rappel, les origines JavaScript, les URI de déconnexion, et toutes les autres manigances qui viennent avec une vraie configuration d'identité. Et ce, avant même d'aborder les fournisseurs externes.

Parce que vos utilisateurs veulent se connecter à Google, Microsoft ou GitHub. Et Claude ne peut se connecter à aucune de ces consoles de développement pour vous. Il ne peut pas :

Créer une application OAuth dans la Google Cloud Console et générer un identifiant et un secret client.
Enregistrer une application dans le portail Microsoft Entra et configurer les URI de redirection.
Configurer une application OAuth GitHub et récupérer les informations d'identification.
Configurez les URL de rappel de chaque fournisseur pour chaque environnement que vous exécutez.
Configurer les champs d'application, les écrans de consentement et les points de terminaison des jetons corrects.

Chaque fournisseur a son propre portail de développement, sa propre terminologie et son propre processus de génération d'informations d'identification. Google parle d'"écran de consentement". Microsoft parle d'"enregistrement d'applications". GitHub parle d'"OAuth Apps" (à ne pas confondre avec les "GitHub Apps", qui sont tout à fait différents). Et chacun d'entre eux vous oblige à copier manuellement un identifiant client et un secret dans votre configuration.

Claude peut écrire la configuration du serveur OpenIddict, le middleware du fournisseur externe, la logique de transformation des demandes. Mais la génération des identifiants, la navigation sur le portail, la configuration des URL spécifiques à l'environnement ? Tout cela, c'est vous qui le faites, dans un navigateur, en cliquant sur des tableaux de bord.

Email : Il ne s'agit jamais simplement d'"envoyer un courriel"

Le code pour envoyer un email via l'API Resend est d'environ 15 lignes. Claude l'a écrit sans problème. Mais faire en sorte que les courriels arrivent réellement dans la boîte de réception de quelqu'un ? Cela nécessite un domaine d'envoi vérifié, des enregistrements DNS pour SPF, DKIM et DMARC, d'attendre la propagation, puis de tester la délivrabilité parce que Gmail et Outlook ont leurs propres opinions sur la fiabilité de votre domaine.

Et concevoir un modèle d'e-mail qui ne soit pas horrible dans tous les clients de messagerie. Outlook sur Windows utilise toujours le moteur de rendu Word en 2026. Laissez-vous convaincre.

La liste complète des choses que j'ai faites sans l'IA

En repensant à mes trois semaines de travail, j'ai commencé à faire un décompte mental approximatif de ce que Claude a construit et de ce que j'ai configuré à la main. La liste "à la main" est plus longue que je ne le pensais :

Infrastructure Cloud:

Installation du projet Cloudflare Pages et configuration du domaine personnalisé
Déploiement de Cloudflare Worker et provisionnement de la base de données D1
Enregistrements DNS pour le site marketing, l'API et l'envoi d'emails
Configuration des certificats SSL/TLS (la plupart du temps automatique, mais le débogage quand ce n'est pas le cas est pénible)
Configuration du pipeline de construction pour le blog (Eleventy + traduction + génération d'images OG)

Authentication & Sécurité:

Enregistrement des applications OAuth de Google, Microsoft et GitHub et génération des informations d'identification
Configuration d'OpenIddict avec des revendications correctes, des URL de rappel, des origines JS et des URI de déconnexion.
Configuration de la protection des robots Turnstile (clés de site, clés secrètes, configuration du tableau de bord)
Configuration de la politique CORS entre le frontend, l'API et les origines Worker

Email:

Configuration du compte de renvoi et de la clé API
Enregistrements DNS SPF, DKIM, DMARC
Tests de délivrabilité des courriels et dépannage
Tests de modèles sur les clients de messagerie

Intégrations tierces:

DeepL Gestion des comptes et des clés API
Configuration de Google Analytics avec intégration du consentement aux cookies

Hébergement Azure:

Installation et configuration d'Azure App Service pour le backend .NET
Provisionnement de la base de données Azure SQL, règles de pare-feu et chaînes de connexion
Configuration d'Azure Cache for Redis et configuration des connexions
Provisionnement des ressources Azure OpenAI pour les embeddings et RAG

**Déploiement

Configuration Docker pour le backend .NET
Gestion des variables d'environnement pour trois cibles de déploiement différentes
Chaînes de connexion à la base de données pour différents environnements

Et honnêtement, j'oublie probablement quelques éléments. Chaque service tiers a son propre tableau de bord, son propre modèle d'authentification, sa propre qualité de documentation (qui varie énormément) et ses propres particularités.

Pourquoi cela est plus important qu'on ne le pense

Voici la dimension qui se perd dans toutes les conversations sur le développement assisté par l'IA : Les outils d'IA n'ont aucun contexte sur votre infrastructure.

Votre base de code se trouve dans des fichiers qu'une IA peut lire. Votre configuration Cloudflare ne l'est pas. Les paramètres de votre application Google OAuth ne le sont pas. Vos enregistrements DNS ne le sont pas. Le statut de vérification de votre domaine Resend ne l'est pas. Toute la surface opérationnelle d'un produit réel est invisible pour les outils d'IA, et cette surface est énorme.

L'écriture du code est la partie la plus facile du génie logiciel, et elle devient de plus en plus facile. Ce qui est difficile, c'est ce que l'on fait avec ce code. L'exploiter, le comprendre lorsque quelque chose se casse à deux heures du matin, l'étendre lorsque les besoins changent et le gérer tout au long de son cycle de vie. L'IA permet d'accélérer la partie facile. Elle ne fait rien pour la partie difficile.

Le site marketing mérite sa propre section

J'ai construit l'ensemble du site marketing de Rasepi en quatre jours environ. Page d'accueil, page de prix, formulaires d'inscription et de contact avec protection contre les robots, politique de confidentialité, quatre pages d'approfondissement des fonctionnalités. Claude a fait probablement 70% du HTML/CSS.

Mais ensuite, j'ai eu besoin que le site existe réellement sur l'internet. Le blog fonctionne sur Eleventy avec un pipeline de construction en 8 étapes : traduction des posts via DeepL, construction du site, traduction des pages HTML statiques, copie des actifs partagés, génération des images OG à partir des SVG, génération des versions audio, gestion des manifestes audio, production d'un plan du site multilingue. Claude a participé à l'écriture de certains éléments de ce pipeline, mais il a fallu une journée entière d'essais et d'erreurs pour que tout fonctionne ensemble avec les bons chemins d'accès aux fichiers et les bons paramètres de déploiement des pages Cloudflare.

Et le site de documentation pour les développeurs ? Il s'agit d'un projet Cloudflare Pages distinct avec son propre domaine, sa propre configuration de construction et ses propres déclencheurs de déploiement. Un autre tableau de bord, un autre ensemble de variables d'environnement, une autre série de DNS.

Le modèle que je continue à voir

Pour une fonctionnalité donnée, Claude s'occupe d'environ 80% du travail en volume. Lignes de code, fichiers créés, problèmes résolus. Mais les 20% restants sont du travail de configuration entièrement manuel : cliquer sur des tableaux de bord web, copier des clés entre les services, déboguer des problèmes d'intégration qui n'apparaissent que dans des environnements déployés.

Et ces 20 % prennent au moins autant de temps que les 80 % restants. Parfois plus.

Mais voici ce qui a changé par rapport à la façon dont le développement en solo fonctionnait auparavant : dans le passé, vous écriviez du code ou vous faisiez de la configuration. Jamais les deux. Si vous passiez une journée à configurer les webhooks Stripe et à tester les flux de paiement dans leur tableau de bord, c'était une journée où vous n'écriviez aucun code d'application. Votre projet n'avançait pas sur un front pendant que vous travailliez sur l'autre.

Avec Claude, ce n'est plus vrai. Tandis que j'étais plongé dans le tableau de bord de Stripe à comprendre les points de terminaison des webhooks et les types d'événements, Claude construisait la prochaine interface de service. Pendant que je cliquais pour la troisième fois sur la configuration de l'écran de consentement OAuth de Google parce que je m'étais trompé dans les champs d'application, Claude écrivait des composants Vue. J'avais la tête dans la configuration, mais la base de code ne cessait de croître. C'est vraiment nouveau. Un développeur solo peut désormais agir sur deux fronts à la fois, et c'est peut-être la plus grande différence pratique que l'IA apporte aux petites équipes.

Cela dit, lorsque vous écrivez du code avec l'aide de l'IA, vous êtes dans une boucle de rétroaction étroite. Vous écrivez, vous testez, vous corrigez, vous itérez. Lorsque vous essayez de comprendre pourquoi votre Cloudflare Worker ne renvoie des erreurs CORS qu'en production, vous regardez les captures d'écran du tableau de bord, lisez les messages des forums de la communauté et essayez des changements de configuration aléatoires en espérant que l'un d'entre eux fonctionne.

Ce qu'il faut changer

Je ne pense pas qu'il s'agisse d'une limitation permanente. La pièce manquante est évidente : les outils d'IA doivent pouvoir interagir avec les API et les tableaux de bord de services tiers. Il ne s'agit pas seulement d'écrire du code qui les appelle, mais de les configurer.

Cela commence à se faire. Des serveurs MCP (Model Context Protocol) pour différents services apparaissent. Anthropic considère clairement l'utilisation des outils comme un concept de premier ordre. Mais nous sommes encore loin du point où je pourrais dire "configurer mon Cloudflare Worker avec une base de données D1, configurer le domaine personnalisé, et ajouter la protection Turnstile" et que cela se produise réellement.

En attendant, l'histoire honnête de la construction d'un produit avec l'IA est la suivante : **L'IA est un accélérateur incroyable pour l'écriture du code de l'application. L'autre moitié est constituée de l'infrastructure, des intégrations tierces, des pipelines de déploiement, de la délivrabilité des courriels, de la configuration des domaines et de la mise en place de la sécurité. Et pour tout cela, vous êtes seul.

(C'est d'ailleurs l'une des raisons pour lesquelles nous concevons Rasepi comme une plateforme hébergée et non comme un simple code open-source). Faire fonctionner un logiciel de documentation n'est pas si difficile. Le faire fonctionner de manière fiable, avec l'authentification, le courrier électronique et l'hébergement adéquats ? C'est ça le produit).

Si vous êtes sur le point d'essayer ceci

Quelques conseils pratiques que j'ai appris et qui pourraient vous faire gagner du temps :

Commencez par l'infrastructure, pas le code.** Configurez d'abord votre hébergement, votre fournisseur d'authentification, votre service de messagerie et vos domaines personnalisés. Faites en sorte qu'un "hello world" soit déployé en production avant d'écrire une seule ligne de code d'application réelle. Le nombre de problèmes qui ne font surface que dans des environnements déployés est déprimant.
Vous aurez des clés d'API, des identifiants de clients, des URL de rappel, des identifiants de base de données et des clés secrètes dispersés dans 8 tableaux de bord différents. J'utilise un fichier local crypté. Vous pouvez utiliser 1Password ou autre. Il suffit d'avoir un seul endroit.
Si Claude vous aide à créer la fonctionnalité en 2 heures, prévoyez 2 heures supplémentaires au minimum pour la déployer, configurer les intégrations et la tester en production.
Il y a eu des journées entières où je n'ai pratiquement pas écrit de code mais où j'ai fait des progrès décisifs : enregistrement d'applications OAuth chez trois fournisseurs, configuration du courrier électronique, débogage du DNS. Ces journées semblent moins productives, mais elles ne le sont pas.
Utilisez plusieurs agents les uns contre les autres.** N'utilisez pas qu'une seule IA. Demandez à Claude d'écrire le code, puis pointez Codex ou ChatGPT dessus et demandez-lui ce qui ne va pas. Différents modèles détectent différentes choses. Cela semble redondant, mais c'est ce qui se rapproche le plus d'une revue de code que vous obtiendrez en tant que développeur solo.

Trois semaines, c'est toujours très rapide pour ce que j'ai construit. Je ne me plains pas de Claude. Il a permis à un seul développeur de construire quelque chose qui aurait normalement pris à une petite équipe la majeure partie d'une année. Mais l'histoire racontée dans le cycle de l'engouement pour l'IA (demander, coder, livrer, terminé) ne comprend pas toute la partie centrale où l'on rend les choses réelles.

L'application est la partie facile. La rendre réelle, c'est le travail.

Arrêtez de licencier parce que l'IA existe

2026-04-04T00:00:00Z

Une de mes amies gère le contenu d'une entreprise SaaS de taille moyenne. L'année dernière, son équipe comptait huit personnes. Des rédacteurs, des éditeurs, un spécialiste de la localisation, quelqu'un qui s'occupait de la base de connaissances. Une bonne équipe, un bon travail. Puis le PDG a assisté à une conférence, est revenu très enthousiaste au sujet de l'IA et, en l'espace de trois mois, l'équipe s'est réduite à trois personnes. Son raisonnement ? Avec les outils d'IA, trois personnes peuvent produire ce que huit personnes produisaient auparavant.

Et techniquement, c'est vrai. Les trois personnes restantes produisent à peu près le même volume. Articles de blog, documents d'aide, mises à jour de produits, communications internes. Les chiffres semblent corrects sur un tableau de bord.

Mais mon amie n'a pas dormi correctement depuis des mois. Elle alterne entre la rédaction, l'édition, l'ingénierie des messages, l'assurance qualité des résultats de l'IA, la gestion des traductions et tout le travail stratégique qui était auparavant partagé par l'ensemble de l'équipe. Ses deux collègues restants sont dans le même bateau. L'un d'eux cherche déjà un autre emploi.

L'entreprise a économisé cinq salaires. Elle perd aussi peu à peu les trois personnes qui savent réellement comment les choses fonctionnent.

Le calcul qui semble correct mais qui ne l'est pas

Voici le discours qui fait le tour des conseils d'administration depuis que le ChatGPT s'est généralisé : une personne dotée d'une IA peut désormais faire le travail de dix personnes. Et si c'est le cas, pourquoi en garder dix ?

C'est un argument convaincant. Simple. Propre. Il tient sur une diapositive.

Il est aussi dangereusement incomplet.

Oui, l'IA peut comprimer les tâches. Selon le [Microsoft's 2024 Work Trend Index] (https://www.microsoft.com/en-us/worklab/work-trend-index/ai-at-work-is-here-now-comes-the-hard-part), 90 % des utilisateurs d'IA au travail affirment que ces outils leur permettent de gagner du temps. Les plus grands utilisateurs de Microsoft Teams ont résumé huit heures de réunions à l'aide de Copilot en un seul mois. Cela représente une journée de travail complète récupérée rien qu'en résumant les réunions. Et 85 % affirment que l'IA les aide à se concentrer sur leur travail le plus important.

Ces chiffres sont réels. Les gains de productivité ne sont pas imaginaires.

Mais voici ce dont les partisans du "licenciement de neuf personnes" ne parlent jamais : la personne qui reste ne se contente pas d'absorber la production. Elle absorbe la charge cognitive, le contexte, la prise de décision, la coordination, l'assurance qualité et chaque parcelle du savoir institutionnel qui a pris la porte avec ces neuf anciens collègues.

La charge mentale n'est pas une feuille de calcul

Il existe un concept en psychologie appelé théorie de la charge cognitive. Il décrit la quantité totale d'effort mental utilisé dans la mémoire de travail à un moment donné. Chaque fois que vous demandez à une personne de faire le travail de réflexion que cinq personnes se partageaient auparavant, vous n'économisez pas l'effort. Vous le concentrez.

Je pense souvent à cela lorsque les gens me disent que l'IA rend les travailleurs "10 fois plus productifs". Productifs pour quoi faire ? Produire plus de mots ? Expédier plus de billets ? Produire plus de diapositives ? Bien sûr, mais la partie la plus difficile du travail de connaissance n'a jamais été la production. C'est la réflexion. Décider de ce qu'il faut produire. Comprendre le contexte. Faire preuve de discernement. Savoir quand quelque chose ne va pas, même si cela semble correct à première vue.

L'IA ne fait pas cela à votre place. L'IA vous donne un premier projet, et vous devez maintenant être suffisamment intelligent pour l'évaluer, suffisamment expérimenté pour repérer les erreurs subtiles, et suffisamment présent pour remarquer que le résultat est erroné en toute confiance. (Si vous avez déjà vu quelqu'un envoyer un document interne généré par l'IA sans l'avoir lu, vous savez exactement ce que je veux dire).

Le rapport [2025 State of the Global Workplace] (https://www.gallup.com/workplace/659279/global-engagement-falls-second-time-2009.aspx) de Gallup a révélé que l'engagement des employés au niveau mondial était tombé à 21 % en 2024, contre 23 % l'année précédente. Cette baisse a coûté à l'économie mondiale une perte de productivité estimée à 438 milliards de dollars. L'engagement des cadres a chuté encore plus fortement, passant de 30 % à 27 %. Les femmes managers ont connu une baisse de sept points. Les managers de moins de 35 ans ont perdu cinq points.

Ce sont ces personnes qui sont censées mener l'adoption de l'IA. Et ils sont en train de s'épuiser.

L'argument de l'amplification

Permettez-moi de vous proposer une autre façon de voir les choses.

Si une personne dotée d'une IA peut faire le travail de dix personnes, alors dix personnes dotées d'une IA peuvent faire le travail de cent personnes.

Relisez cette phrase. Car c'est la partie dont presque personne ne parle, et c'est la partie qui devrait empêcher tout PDG de dormir. Non pas parce que c'est effrayant, mais parce qu'il s'agit d'une opportunité énorme que la plupart des entreprises sont en train de gâcher.

Les entreprises qui licencient la moitié de leur personnel parce que "l'IA peut s'en charger" ne sont pas efficaces. Elles manquent de vision. Elles optimisent leurs effectifs en fonction d'un chiffre trimestriel, tandis que leurs concurrents découvrent ce qui se passe lorsque l'on donne des outils puissants à une équipe complète de personnes motivées et expérimentées.

J'ai assisté à ce phénomène lors d'un événement organisé à Zurich le mois dernier à l'intention des jeunes entreprises. Deux entreprises dans le même espace. A peu près la même taille, le même marché. La société A avait réduit son équipe de contenu de douze à quatre personnes. L'entreprise B avait gardé les douze et leur avait donné des outils d'IA ainsi qu'une formation. Devinez laquelle des deux entreprises produisait du contenu multilingue en six langues, expérimentait de nouveaux formats et envoyait chaque semaine des mises à jour de produits dans sa base de connaissances ? (Ce n'était pas l'entreprise A.)

Ce qui se passe réellement lorsque l'on réduit

Laissez-moi vous expliquer ce qui se passe en pratique lorsque vous remplacez une équipe de dix personnes par un ou deux super-travailleurs "améliorés par l'IA".

La première semaine, on se sent bien. Les personnes restantes sont pleines d'énergie. Ils disposent de nouveaux outils. Ils produisent beaucoup. La direction est ravie. Les chiffres du tableau de bord sont incroyables par rapport aux effectifs.

**La seule personne responsable de la documentation découvre que le contenu généré par l'IA a besoin d'un examen approfondi. Pas une révision légère. Un examen approfondi. Parce que l'IA ne connaît pas les nuances de votre produit, le contexte de vos clients ou les trois choses que vous avez modifiées la semaine dernière et qui invalident la moitié de ce qui a été écrit. Le travail de révision absorbe à lui seul le temps qui a été "économisé" en générant du contenu plus rapidement.

Le quatrième mois, les lacunes en matière de connaissances institutionnelles apparaissent. Vous souvenez-vous de ces huit personnes que vous avez licenciées ? Ils ne se contentaient pas de rédiger du contenu. Ils entretenaient des relations avec les chefs de produit. Ils connaissaient les points douloureux des clients grâce à des années de suivi des tickets d'assistance. Ils savaient quels sujets de documentation suscitaient le plus de questions. Ces connaissances ont disparu. L'IA ne l'a certainement pas.

**Parce que les personnes restantes sont débordées, que la qualité a baissé et que quelqu'un a enfin remarqué que la base de connaissances n'avait pas été correctement mise à jour depuis des semaines. Mais les sous-traitants n'ont pas non plus de contexte, et vous payez donc plus cher l'heure pour des résultats moins bons.

Je n'invente rien. J'ai vu ce schéma se répéter dans trois entreprises différentes au cours de la seule année dernière.

Les données indiquent qu'il faut garder ses employés (et les former)

Le [rapport sur l'avenir de l'emploi 2025 du Forum économique mondial] (https://www.weforum.org/publications/the-future-of-jobs-report-2025/digest/) a interrogé plus de 1 000 employeurs mondiaux sur leurs projets en matière de main-d'œuvre. Les chiffres révèlent une histoire intéressante. Oui, 40 % des employeurs prévoient de réduire leur personnel lorsque l'IA automatise les tâches. Mais 85 % prévoient d'améliorer les compétences de leur main-d'œuvre existante. Et 70 % prévoient d'embaucher des personnes dotées de nouvelles compétences, et non moins de personnes.

Le rapport prévoit une croissance nette de 78 millions d'emplois d'ici à 2030. Ce chiffre tient compte des 92 millions de postes déplacés. Le monde n'évolue pas vers une diminution du nombre de travailleurs. Il évolue vers des travailleurs différemment qualifiés.

Et voici l'élément qui devrait faire réfléchir tous les chefs d'entreprise qui veulent réduire leurs effectifs : 64 % des employeurs considèrent le soutien à la santé et au bien-être des employés comme une stratégie clé pour la disponibilité des talents. Pas "réduire les coûts". Pas "tout automatiser". **Parce que les entreprises qui brûlent leurs employés ne peuvent pas embaucher les bons plus tard.

Par ailleurs, une [étude du BCG et de la Harvard Business School] (https://www.bcg.com/publications/2023/how-people-create-and-destroy-value-with-gen-ai) a révélé que lorsque des équipes utilisaient l'IA pour des tâches créatives, environ 90 % d'entre elles amélioraient leurs performances, la qualité de leur production augmentant de 40 % par rapport aux groupes de contrôle. Mais l'étude a également révélé un élément qui devrait mettre tous les dirigeants mal à l'aise : la diversité des idées au sein des groupes assistés par l'IA a chuté de 41 %.

Réfléchissez à ce que cela signifie. Vous licenciez sept personnes de votre équipe de dix personnes. Les trois personnes qui restent utilisent l'IA pour produire le même volume. Mais l'éventail des idées, des perspectives et des approches se réduit de près de moitié. Votre production semble productive mais devient progressivement homogène. Personne ne s'en aperçoit jusqu'à ce qu'un concurrent produise quelque chose de vraiment créatif et que vous ne compreniez pas pourquoi votre équipe n'en fait pas autant.

La charge mentale que personne ne budgétise

L'enquête de Microsoft a révélé que 68 % des personnes ont du mal à supporter le rythme et le volume de travail, et que 46 % d'entre elles se sentent épuisées. Et c'était la situation avant que vous ne leur disiez qu'ils font maintenant le travail de leurs trois anciens coéquipiers.

Voici un élément qui n'apparaît pas dans les tableaux de bord de la productivité : le coût cognitif lié au fait d'être la dernière ligne de défense. Lorsque vous êtes la seule personne à examiner les résultats de l'IA, vous n'avez pas la possibilité d'avoir un jour de repos. Lorsque vous êtes le seul propriétaire de la base de connaissances, toutes les questions d'assistance atterrissent sur votre bureau. Lorsqu'il n'y a personne à qui soumettre des idées parce que l'équipe a été "redimensionnée", chaque décision est la vôtre.

Si j'ai construit Rasepi, c'est en partie parce que j'ai vu ce problème de près. Lorsque les équipes de documentation se réduisent, les connaissances ne se réduisent pas avec elles. La quantité de contenu qui doit exister, rester à jour et être précis dans toutes les langues ne diminue pas simplement parce qu'il y a moins de personnes pour le maintenir. Au contraire, elle augmente (c'est exactement le problème que nous sommes en train de résoudre avec Rasepi, avec des fonctionnalités telles que les dates d'expiration forcées et les traductions en bloc qui rendent les petites équipes réellement plus efficaces et non plus débordées).

Mais même les meilleurs outils ne permettent pas de remédier à une décision de recrutement fondamentalement erronée. On ne peut pas automatiser le besoin de jugement humain, de contexte et d'attention. On ne peut que rendre ces humains plus efficaces.

Ce que font les entreprises intelligentes

Ce qui est le plus impressionnant dans les données de Microsoft, c'est de voir à quoi ressemblent les "utilisateurs de l'IA". Il s'agit de personnes qui utilisent l'IA plusieurs fois par jour et gagnent plus de 30 minutes. Ils sont 68 % plus susceptibles d'expérimenter différentes manières d'utiliser l'IA. Ils ne se contentent pas de produire davantage. Ils redéfinissent la façon dont le travail se déroule.

Et voici le clou du spectacle : ils existent au sein des organisations qui investissent en eux. Les utilisateurs de l'IA sont 61 % plus susceptibles d'entendre leur PDG parler de l'importance de l'IA au travail. Ils sont 53 % plus susceptibles d'être encouragés par leur direction à repenser l'ensemble de leur fonction. Ils reçoivent une formation sur mesure, et pas seulement un identifiant ChatGPT.

En d'autres termes, les travailleurs de l'IA les plus productifs ne sont pas des survivants isolés d'un licenciement. Ils sont membres d'équipes soutenues et investies.

Permettez-moi d'opposer cela à ce que je vois dans les entreprises qui ont choisi la voie de la "réduction des effectifs". Les employés restants ne sont pas des utilisateurs chevronnés. Ce sont des généralistes débordés qui tentent désespérément de faire tourner les choses. Ils n'ont pas le temps d'expérimenter l'IA parce qu'ils sont trop occupés à l'utiliser pour survivre. Il n'est pas possible de repenser la fonction parce que la fonction, c'est juste... eux, seuls, qui font tout.

Le problème de la connaissance dont personne ne parle

Il y a encore une chose. Et je n'entends personne en parler, ce qui est étrange car cela devrait être évident.

Lorsque vous licenciez des travailleurs expérimentés, les connaissances partent avec eux. Il ne reste pas dans le bâtiment. Il n'est pas dans le wiki. Il n'est pas dans l'IA. Elle se trouve dans la tête des personnes qui ont élaboré les processus, qui ont compris les cas limites et qui savaient quels clients s'intéressaient à quels détails.

Vous savez ce qui se passe lorsque vous disposez d'excellents outils d'IA et d'aucune connaissance institutionnelle ? Vous obtenez des informations parfaitement formatées, délivrées avec confiance, mais complètement erronées. À l'échelle.

Le mois dernier, j'ai parlé à une responsable de la documentation d'une entreprise de fintech (elle n'a pas voulu être nommée, ce qui vous dit quelque chose). Après avoir réduit leur équipe de six à deux, ils ont commencé à s'appuyer fortement sur l'IA pour mettre à jour les documents destinés aux développeurs. En l'espace de quatre mois, ils ont constaté un pic dans les tickets d'assistance. Les documents avaient l'air bien. En apparence, ils étaient bien rédigés et à jour. Mais elles contenaient des erreurs subtiles que seule une personne ayant une connaissance approfondie du produit aurait pu déceler. Une description des paramètres de l'API qui était techniquement correcte mais pratiquement trompeuse. Un guide de migration qui omettait une étape que tous les membres de l'ancienne équipe connaissaient. Des petites choses que l'IA ne peut pas savoir parce que l'IA n'assiste pas à vos réunions, ne lit pas vos fils Slack, n'entend pas le "oh, ce document est encore faux" frustré de l'ingénieur support à la machine à café.

La vraie question

Voici donc ce qui, à mon avis, devrait faire l'objet de la conversation.

Pas : "Combien de personnes pouvons-nous supprimer maintenant que nous avons l'IA ?".

Mais : _"Qu'est-ce qui devient possible lorsque nous donnons l'IA à tous ceux que nous avons déjà ?".

Votre équipe de documentation de dix personnes dotée d'outils d'IA ne devient pas redondante. Elle devient une équipe capable de maintenir le contenu en douze langues au lieu de deux. Elle peut maintenir chaque élément de contenu à jour grâce à des contrôles de fraîcheur automatisés. Elle peut expérimenter de nouveaux formats, effectuer des tests A/B sur le contenu de l'aide, créer des guides interactifs, tout en ayant le temps de réfléchir stratégiquement à ce dont les clients ont réellement besoin.

Avec l'IA, votre équipe marketing de dix personnes ne se transforme pas en cinq personnes effectuant le même travail avec plus de stress. Elle devient dix personnes qui peuvent personnaliser les campagnes à une échelle auparavant impossible, tester des variations plus créatives, répondre plus rapidement aux changements du marché et disposer encore de la bande passante cognitive nécessaire pour trouver des idées vraiment originales que l'IA n'aurait jamais générées.

Ce n'est pas un coût. Il s'agit d'un investissement dont le rendement s'accroît.

Où cela aboutira-t-il ?

Les entreprises qui gagneront les cinq prochaines années ne seront pas celles qui auront coupé le plus de têtes. Elles seront celles qui auront trouvé le moyen de rendre leurs équipes existantes véritablement plus compétentes.

La question n'est pas de savoir si une personne peut faire le travail de dix. La question est de savoir ce qui se passe lorsque les dix personnes peuvent faire le travail de cent.

Si vous êtes un dirigeant et que vous lisez ceci, j'aimerais vous demander une chose. Avant d'approuver le prochain cycle de "restructuration basée sur l'IA", parlez aux personnes qui sont restées après le dernier cycle. Demandez-leur comment ils s'en sortent. Demandez-leur ce qu'ils ont cessé de faire par manque de temps. Demandez-leur ce qui passe à travers les mailles du filet.

Imaginez ensuite ce qu'ils pourraient accomplir si, au lieu de porter la charge seuls, ils disposaient d'une équipe complète et des meilleurs outils disponibles.

Ce n'est pas un fantasme. Pour les entreprises qui sont prêtes à investir dans leur personnel au lieu de le remplacer, ce sont les douze prochains mois qui s'annoncent.

Les lecteurs et les rédacteurs sont dans des modes mentaux différents. Pourquoi tous les outils leur proposent-ils la même interface utilisateur ?

2026-04-03T00:00:00Z

Ouvrez Confluence maintenant et trouvez un document que vous devez lire. Que voyez-vous ?

Une barre d'outils. Des boutons d'édition. Des boîtes de commentaires. Des liens vers l'historique de la page. Une barre latérale pleine de navigation dont vous n'avez pas besoin. Des fils d'Ariane. Des champs de métadonnées. Des indicateurs de permission. Une interface de création complète autour du texte que vous êtes venu lire.

Pensez maintenant à ce que vous vouliez vraiment : la réponse à une question, les trois prochaines étapes d'un processus ou une politique que vous devez consulter avant une réunion qui aura lieu dans dix minutes.

Vous êtes venu pour consommer. L'interface suppose que vous êtes venu pour créer.

C'est le cas par défaut dans presque toutes les plateformes de documentation. Confluence, Notion, SharePoint, GitBook, Nuclino, Slite. Elles présentent toutes le même environnement aux lecteurs et aux rédacteurs. La page est la page. Tout le monde a la même vue, à quelques boutons de permission près.

Cela semble normal parce que nous n'avons jamais rien eu d'autre. Mais il s'agit d'une décision de conception, pas d'une loi de la nature. Et ce n'est pas la bonne.

La même interface pour lire et écrire crée une surcharge cognitive](/fr/blog/img/readers-writers-ui.svg)

La lecture et l'écriture ne sont pas la même tâche cognitive

Il ne s'agit pas d'une préférence en matière d'interface utilisateur. Il s'agit d'une différence fondamentale dans le fonctionnement du cerveau.

Lorsque vous écrivez, vous êtes en mode génératif. Vous construisez, organisez, décidez ce qu'il faut inclure et ce qu'il faut laisser de côté. Vous avez besoin d'outils : options de formatage, contrôles de structure, intégration de médias, champs de métadonnées, historique des versions, fonctions de collaboration. L'interface doit vous offrir puissance et flexibilité.

Lorsque vous lisez, vous êtes en mode réceptif. Vous scrutez, filtrez, extrayez ce qui est pertinent et essayez de passer à autre chose. Vous avez besoin de clarté : typographie claire, mise en page ciblée, distractions minimales. L'interface doit s'effacer.

La psychologie cognitive dispose d'un cadre clair à cet égard. La [Théorie de la charge cognitive] (https://www.instructionaldesign.org/theories/cognitive-load/), élaborée par John Sweller à la fin des années 1980, établit une distinction entre la charge intrinsèque (la difficulté de la matière elle-même), la charge pertinente (l'effort d'apprentissage et d'intégration) et la charge étrangère (tout ce que l'environnement ajoute et qui n'est pas utile). Chaque barre d'outils, barre latérale et bouton d'édition visible par un lecteur est une charge étrangère. Ils ne l'aident pas à comprendre le contenu. Ils sont en concurrence active pour attirer l'attention.

Les recherches menées par [Mayer et Moreno (2003)] (https://doi.org/10.1207/S15326985EP3801_6) sur l'apprentissage multimédia ont démontré que la réduction des éléments superflus améliore à la fois la compréhension et la rétention. Leur principe de cohérence est direct : Une interface de documentation qui présente des contrôles de création aux lecteurs viole ce principe à chaque chargement de page.

**Le lecteur n'a pas besoin de voir les outils du rédacteur. Les montrer quand même n'est pas neutre. C'est activement nuisible à la compréhension.

Comment les plateformes actuelles gèrent ce problème (la plupart du temps, elles ne le font pas)

Voyons ce qui existe.

Confluence a un mode lecture et un mode édition, mais le mode lecture est toujours entouré par la navigation, les métadonnées et l'arborescence de la plateforme. La barre d'outils d'édition disparaît lorsque vous n'éditez pas, mais le cadre mental "ceci est une page wiki éditable" ne disparaît jamais complètement. Chaque lecteur voit le bouton "Modifier". La page chuchote : vous pouvez changer ceci.

Notion est pire à cet égard. Sa philosophie de base est que tout est toujours modifiable. Cliquez n'importe où et vous êtes en train de taper. C'est génial pour les écrivains. C'est terrible pour les lecteurs qui veulent juste absorber le contenu sans l'angoisse de modifier accidentellement quelque chose. La propre [galerie de modèles] de Notion (https://www.notion.com/templates) le montre : chaque modèle est un espace de travail, pas une publication.

SharePoint prend techniquement en charge différentes mises en page pour la visualisation et l'édition, mais l'expérience globale reste celle d'un intranet d'entreprise. Les lecteurs ont l'impression d'être dans un outil d'entreprise, et non de lire un document optimisé pour la compréhension.

GitBook se rapproche le plus d'une expérience de lecture d'abord, avec sa sortie propre de type documentation. Mais même dans ce cas, l'expérience de lecture repose sur l'hypothèse que le lecteur est un développeur qui consulte des documents techniques. Il n'est pas conçu pour le consommateur de connaissances générales.

Aucune de ces plateformes ne considère la lecture comme une activité fondamentalement différente de l'écriture. Elles la considèrent comme une activité d'écriture avec la barre d'outils cachée.

Le coût d'une interface unique

Il ne s'agit pas seulement d'un problème esthétique. Il a des conséquences mesurables.

La surcharge d'informations réduit la compréhension

Une [étude publiée dans le Journal of Consumer Research] (https://doi.org/10.1086/209336) a montré que la surcharge d'informations entraîne une baisse de la qualité des décisions, l'effet augmentant à mesure que le rapport entre les informations non pertinentes et les informations pertinentes s'accroît. Une page de documentation comportant des commandes de création, des arbres de navigation et des champs de métadonnées visibles augmente ce ratio pour chaque lecteur qui n'est pas là pour écrire.

Le changement de contexte a un coût réel

Lorsqu'un signal d'interface indique "vous pouvez modifier ceci", il active un cadre cognitif différent de celui de "lire ceci". [Les recherches de Gloria Mark à UC Irvine (https://www.ics.uci.edu/~gmark/) sur l'attention et le multitâche ont montré qu'il faut en moyenne 23 minutes et 15 secondes pour se reconcentrer complètement après un changement de contexte. Un lecteur qui envisage momentanément de modifier son texte (même pour corriger une faute de frappe) est sorti du mode lecture. Il ne s'agit pas d'une hypothèse. Quiconque a utilisé Notion connaît l'expérience de cliquer pour sélectionner du texte et de commencer accidentellement à taper.

Les lecteurs et les rédacteurs ont des besoins différents pour un même contenu

Un rédacteur a besoin de voir la structure, les marqueurs de formatage, les types de blocs, les métadonnées et les signaux de collaboration. Il a besoin de toute la machinerie.

Un lecteur a besoin d'un texte propre, d'une hiérarchie claire et du chemin le plus rapide vers l'information qu'il recherche. Il a besoin du contenu, pas de la machinerie.

Servir les deux à partir de la même interface signifie que ni l'un ni l'autre ne bénéficie d'une expérience optimisée pour ce qu'ils font réellement.

Et puis il y a le troisième public : L'IA

C'est là que les choses se compliquent et que les plateformes existantes ne sont pas du tout préparées.

En 2026, la documentation a trois consommateurs distincts, et non deux :

Les rédacteurs qui créent et maintiennent le contenu
Les lecteurs qui consomment le contenu visuellement
Les systèmes d'IA qui récupèrent, analysent et synthétisent le contenu de manière programmatique.

Chacun de ces publics a besoin d'une interface fondamentalement différente pour accéder au même contenu sous-jacent.

Les rédacteurs ont besoin d'outils d'édition riches, de fonctions de collaboration et de contrôles structurels. Les lecteurs ont besoin d'une présentation claire et ciblée, avec un minimum de distractions. L'IA a besoin d'une sortie structurée, analysable par la machine, avec des métadonnées explicites : signaux de fraîcheur, étiquettes de classification, adressage au niveau du bloc et balisage sémantique propre.

Comme nous l'avons expliqué dans [Builders, Not Developers] (/blog/builders-not-developers-how-claude-changed-devrel/), les intermédiaires de l'IA sont déjà le principal consommateur de documentation pour une part croissante des travailleurs du savoir. [L'enquête menée par GitHub auprès des développeurs en 2024 (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 de l'IA. En 2026, [84 % des développeurs utilisent régulièrement des outils d'IA] (https://www.index.dev/blog/developer-productivity-statistics-with-ai-tools), et 41 % de l'ensemble du code sera généré par l'IA.

Ces systèmes d'IA ne se soucient pas de votre barre latérale ou de votre barre d'outils. Ils ont besoin de données propres. Et une plateforme qui confond la vue du lecteur avec la vue du rédacteur confond également la surface consommable par l'IA avec la surface de rédaction humaine. Il s'agit de trois incompatibilités dans une seule interface.

Trois publics, trois besoins différents](/fr/blog/img/lecteurs-écrivains-trois-audiences.svg)

Comment Rasepi sépare les expériences

Rasepi repose sur le principe que la création de contenu et la consommation de contenu sont des activités différentes qui méritent des interfaces différentes.

L'environnement du rédacteur

Lorsque vous écrivez dans Rasepi, vous disposez d'un environnement de rédaction complet. Édition de texte riche avec TipTap, contrôles au niveau des blocs, indicateurs d'état des traductions, gestion des échéances, outils de collaboration, vues de la structure du contenu et tout ce dont un rédacteur a besoin pour créer et maintenir une documentation de haute qualité.

Le rédacteur voit les machines parce qu'il en a besoin.

L'environnement du lecteur

Lorsque quelqu'un consomme un document Rasepi, il voit une expérience de lecture propre et ciblée. Pas de chrome d'édition. Pas de barre d'outils. Pas de signaux "vous pourriez modifier ceci". Juste le contenu, présenté dans une mise en page optimisée pour la compréhension et le balayage.

Le lecteur ne voit pas le bouton d'édition parce qu'il n'est pas là pour éditer. Il est là pour apprendre quelque chose, suivre un processus ou trouver une réponse. L'interface respecte cette intention.

La surface de l'IA

Pour les consommateurs d'IA, Rasepi expose le contenu par le biais d'API structurées avec des métadonnées complètes. Chaque bloc comporte son score de fraîcheur, l'état de la traduction, le hachage du contenu et les étiquettes de classification. Les systèmes d'IA peuvent interroger le contenu au niveau des blocs, filtrer par fraîcheur, exclure les documents périmés ou provisoires et récupérer exactement les données structurées dont ils ont besoin.

Il n'est pas nécessaire de gratter une page wiki et d'espérer le meilleur. L'IA dispose d'une interface conçue à cet effet, tout comme le lecteur et le rédacteur.

Une couche de contenu, trois interfaces

Ce qui est important, c'est que nous ne maintenons pas trois copies du contenu. Il ne s'agit pas du problème des cinq copies de l'intégration dont nous avons parlé dans [Stop Maintaining Five Copies of the Same Document] (/blog/stop-maintaining-five-copies-of-the-same-document/).

Il s'agit d'une couche de contenu, stockée sous forme de blocs structurés, servie par trois vues différentes optimisées pour trois publics différents.

Le rédacteur édite les blocs. Le lecteur voit un contenu assemblé et stylisé. L'IA interroge des données structurées avec des métadonnées. Mêmes blocs. Même source de vérité. Couche de présentation différente pour chaque consommateur.

Cela n'est possible que grâce à l'architecture au niveau des blocs. Chaque élément de contenu est une unité adressable individuellement avec ses propres métadonnées. Vous pouvez présenter ces blocs différemment en fonction de la personne qui les demande :

| Le contenu peut être présenté différemment en fonction de la personne qui le demande : - Audience - Besoins - Obtention - Besoins - Obtention |----------|-------|------| | Les blocs peuvent être présentés différemment en fonction de la personne qui les sollicite : - Audience - Besoins - Gains - || Rédacteur - Formatage, structure, collaboration, métadonnées | Lecteur** - Texte propre, hiérarchie claire, balayage rapide - Vue de lecture focalisée, pas de chrome pour l'édition. | L'interface de programmation (API) au niveau des blocs avec des métadonnées complètes.

Pourquoi cela est plus important qu'il n'y paraît

En lisant ces lignes, vous vous dites peut-être : "Ce n'est que de l'interface utilisateur. Différentes vues de la même chose. Quelle importance cela peut-il avoir ?"

Il s'avère que c'est très important.

La confiance des lecteurs

Les gens font confiance à un contenu qui a l'air publié. Lorsqu'une page ressemble à un wiki que tout le monde peut modifier, les lecteurs l'ignorent inconsciemment. Lorsque le même contenu est présenté dans un format propre, digne d'une publication, il a plus d'autorité. Ce n'est pas irrationnel. C'est le signe que quelqu'un a pris la présentation au sérieux, ce qui implique qu'il a également pris le contenu au sérieux.

Le groupe Nielsen Norman a étudié cette question de manière approfondie. Ses [recherches sur la crédibilité du contenu] (https://www.nngroup.com/articles/trust-signals-content/) montrent que la qualité de la conception et la présentation sont parmi les signaux les plus forts sur lesquels les utilisateurs s'appuient pour évaluer la crédibilité du contenu. Une vue éditoriale encombrée sape activement la crédibilité du contenu qu'elle affiche.

Productivité des rédacteurs

Les rédacteurs qui travaillent dans un environnement de création dédié n'ont pas à se demander s'ils sont en train de lire ou d'écrire. Les outils sont là parce qu'ils sont censés être là, et non parce que l'interface n'a pas su décider qui la regardait.

Fiabilité de l'IA

Lorsque les systèmes d'IA disposent d'une surface conçue à cet effet avec des métadonnées structurées, ils peuvent prendre de meilleures décisions sur ce qu'il convient d'extraire et sur ce qu'il convient d'exclure. Ils peuvent vérifier les scores de fraîcheur avant d'inclure un bloc dans une réponse. Ils peuvent respecter les étiquettes de classification. Ils peuvent filtrer en fonction de la langue, du statut ou du public. Rien de tout cela n'est possible lorsque l'IA récupère la même page HTML que celle qui a été conçue pour les lecteurs humains.

Le changement de modèle mental

L'hypothèse fondamentale de la plupart des plateformes de documentation est la suivante : la page est l'unité, et tout le monde interagit avec la page.

L'hypothèse de Rasepi est différente : Le bloc est l'unité, et différents publics interagissent avec les blocs par le biais de surfaces spécifiques.

Cela semble être une petite distinction architecturale. Ce n'est pas le cas. C'est la différence entre un outil qui montre accidentellement du contenu à des systèmes d'intelligence artificielle et un outil qui les sert délibérément. Entre un environnement d'écriture qui se trouve être lisible et une expérience de lecture conçue à partir de zéro. Entre une interface satisfaisante et trois excellentes.

La documentation n'est plus seulement écrite et lue. Elle est écrite, lue, interrogée, traduite, notée, classée et servie à des systèmes d'intelligence artificielle à grande échelle. Une seule interface ne peut pas optimiser tout cela, et c'est en prétendant le contraire que nous nous sommes retrouvés avec des wikis que personne ne veut lire et des assistants d'intelligence artificielle qui tirent des réponses de pages qui n'ont jamais été conçues pour être consommées par des machines.

Les lecteurs et les écrivains sont dans des modes mentaux différents. L'IA est dans un mode complètement différent. L'interface doit en tenir compte.

L'état des documents en 2026 : cinq tendances qui définiront la prochaine ère

2026-04-03T00:00:00Z

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.

Des bâtisseurs, pas des développeurs : Comment Claude a changé le destinataire de vos documents

2026-04-02T00:00:00Z

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.

Comment fonctionnent les traductions Rasepi et pourquoi elles ressemblent à votre équipe

2026-03-31T00:00:00Z

Si vous avez déjà passé un document par Google Translate, ou honnêtement n'importe quel outil de traduction, vous connaissez le résultat. Techniquement correct. Le ton est faux. Votre produit est soudain appelé différemment. La terminologie interne de votre équipe disparaît. Un "vous" formel là où votre entreprise utilise l'informel, ou l'inverse.

Le résultat est traduit, mais il ne vous ressemble pas.

C'est pour résoudre ce problème que j'ai conçu le système de traduction de Rasepi. Il ne s'agit pas de traduire de la documentation (tous les outils peuvent le faire maintenant), mais de la traduire de manière à ce qu'elle ressemble à ce que notre équipe a écrit.

La réponse est oui. Et il n'est pas nécessaire d'avoir une équipe de traducteurs professionnels pour y parvenir.

Seul ce qui a été modifié est traduit

La plupart des plateformes de documentation traduisent des pages entières. Si vous modifiez une phrase, tout le document est retraduit. Chaque langue, chaque paragraphe, qu'il ait été modifié ou non.

Rasepi fonctionne différemment. Il suit chaque paragraphe individuellement. Lorsque vous modifiez une section d'un document de 20 sections, seule cette section est retraduite. Les 19 autres, toutes langues confondues, restent inchangées.

Cela signifie deux choses :

**Nous parlons d'une réduction de 94 % pour des modifications typiques. La plupart des mises à jour concernent une ou deux sections, et non la page entière.
Les traductions que vous avez déjà révisées restent stables. Si votre équipe allemande a approuvé une traduction la semaine dernière, l'édition d'un paragraphe sans rapport en anglais n'affectera pas le texte qu'elle a approuvé.

Le système sait ce qui a changé, car chaque paragraphe possède une identité unique et une empreinte de contenu. Lorsque l'empreinte change, le paragraphe en question est signalé comme devant être retraduit. Il n'y a rien d'autre.

Votre glossaire, votre terminologie

C'est ici que les choses deviennent intéressantes.

Chaque entreprise a son propre vocabulaire. "Sprint Review" peut rester "Sprint Review" dans votre documentation allemande parce que votre équipe de Berlin utilise le terme anglais. Ou il peut devenir "Sprint-Überprüfung" parce que votre équipe de Munich préfère la version allemande. "Base de connaissances" peut être "Wissensdatenbank" ou "Knowledge Base" ou quelque chose d'entièrement différent que votre équipe a inventé en interne.

Rasepi vous permet de créer un glossaire pour chaque langue. Il s'agit essentiellement d'une liste de termes et de leurs traductions approuvées. Lorsqu'un paragraphe est traduit, le système vérifie d'abord votre glossaire. Chaque terme de votre liste est traduit exactement comme vous l'avez défini. À chaque fois. Dans tous les documents.

Vous pouvez gérer votre glossaire directement dans Rasepi :

Ajouter des termes un par un** au fur et à mesure que vous remarquez des incohérences
Importer un CSV** si vous disposez déjà d'une liste terminologique provenant d'un autre système.
Exporter votre glossaire** pour le partager avec des traducteurs externes ou d'autres outils.

Le glossaire fonctionne par paire de langues. Votre glossaire anglais-allemand est distinct de votre glossaire anglais-français. Ceci est important car le même terme anglais peut nécessiter un traitement différent dans différentes langues. Par exemple, "Sprint Review" peut rester en anglais en allemand mais être traduit en japonais.

Lorsque vous mettez à jour votre glossaire, la modification prend effet la prochaine fois qu'un paragraphe est traduit dans cette langue. Il n'est pas nécessaire de tout retraduire manuellement. Le prochain cycle d'édition naturel s'en charge.

Règles de style : faire sonner les traductions comme si vous les aviez écrites

Les glossaires traitent les mots individuellement. Mais une traduction peut utiliser tous les termes corrects et donner l'impression d'être incomplète. Mauvais ton. Des dates au mauvais format. Des nombres avec le mauvais séparateur. Symboles monétaires au mauvais endroit.

C'est à cela que servent les règles de style.

Pour chaque langue, vous pouvez définir un ensemble de règles qui contrôlent la mise en forme des traductions :

Conventions de formatage

Il s'agit des détails qui font qu'un document semble natif plutôt que "manifestement traduit de l'anglais" :

Format de la date et de l'heure : horloge de 24 heures pour l'allemand, AM/PM pour l'anglais, etc.
Format des nombres : virgule comme séparateur décimal en allemand (3,14 au lieu de 3,14), point pour les milliers.
Règles de ponctuation : formatage des diplômes universitaires, styles de guillemets et autres conventions régionales.

Vous choisissez les conventions qui correspondent aux normes de votre entreprise. Rasepi les applique à toutes les traductions dans cette langue, dans tous les documents.

Instructions personnalisées

C'est ici que les choses deviennent vraiment puissantes. Les instructions personnalisées sont des directives en langage clair qui indiquent au moteur de traduction comment traiter votre contenu. Vous les écrivez dans des phrases normales et le moteur les suit.

Quelques exemples :

"Utilisez un ton amical et diplomatique " pour une entreprise qui souhaite une documentation accessible.
"Utilisez toujours la forme formelle "Sie", jamais "du"" pour une communication professionnelle en allemand
Utilisez l'orthographe de l'anglais britannique : colour, organisation, licence* lorsque votre public anglophone est basé au Royaume-Uni.
"Mettez des symboles monétaires après le montant numérique " pour respecter les conventions européennes
"Lorsque vous décrivez les points de terminaison de l'API, utilisez l'humeur impérative " pour les documents techniques qui doivent être directs.

Vous pouvez ajouter jusqu'à 200 instructions personnalisées par langue. Elles s'ajoutent à votre glossaire et à vos règles de formatage, et le moteur de traduction les prend en compte à chaque traduction.

Formalité

L'allemand utilise "du" et "Sie". Le français utilise "tu" et "vous". Le japonais a plusieurs niveaux de politesse. Même les langues qui n'ont pas de pronoms formels/informels évidents présentent des différences de tonalité qui ont de l'importance.

Rasepi vous permet de définir le niveau de formalité pour chaque langue. Une fois configuré, chaque paragraphe traduit correspond à ce ton. Si votre entreprise s'adresse à ses lecteurs de manière formelle en français ("vous") mais informelle en allemand ("du"), c'est exactement ce que fera chaque traduction.

Tout fonctionne ensemble

Voici ce qui importe : les termes du glossaire, les conventions de formatage, les instructions personnalisées et les paramètres de formalité s'appliquent tous à chaque traduction en même temps. Vous ne choisissez pas l'un ou l'autre. Vous les définissez tous une seule fois, et chaque paragraphe traduit est soumis au même ensemble de règles.

Vous obtenez ainsi des traductions qui se lisent comme si un membre de votre équipe locale les avait écrites. Et non comme si une machine avait traduit chaque phrase sans rien savoir de votre entreprise.

Chaque langue peut avoir son propre contenu

C'est la fonction qui surprend le plus les gens.

Dans Rasepi, un document traduit n'est pas une copie verrouillée de l'original. Chaque version linguistique peut avoir un contenu qui n'existe que dans cette langue.

**Pourquoi cela est-il important ?

Parce que les besoins varient d'un marché à l'autre :

Votre documentation allemande peut avoir besoin d'une section de conformité DSGVO (GDPR) qui ne s'applique pas à la version américaine
Votre équipe japonaise peut avoir besoin d'une note sur l'outillage local que personne d'autre n'utilise.
Votre bureau brésilien peut avoir besoin d'un contexte sur les réglementations fiscales régionales.

Dans la plupart des outils de traduction, l'ajout de contenu à une version linguistique signifie qu'il sera écrasé la prochaine fois que quelqu'un retraduira à partir de l'anglais. Les équipes s'en rendent compte rapidement et cessent d'ajouter du contenu local. Elles créent des documents fantômes dans Notion ou Slack ou ailleurs, et vous avez maintenant deux systèmes auxquels personne ne fait entièrement confiance.

Dans Rasepi, le contenu unique est marqué comme appartenant à cette langue. Il n'est jamais écrasé par une nouvelle traduction. Il n'est jamais supprimé lorsque la source anglaise change. Il cohabite avec le contenu traduit et fait partie intégrante du document.

Il en va de même pour la structure. Si vos traducteurs japonais préfèrent les listes numérotées aux puces de la version anglaise (une convention courante dans la rédaction technique japonaise), ils peuvent modifier le format. Rasepi préserve ce choix dans les mises à jour futures.

Chaque version linguistique est un document de premier ordre, et non un miroir en lecture seule.

Automatique et humain : ils travaillent ensemble

Rasepi ne vous oblige pas à choisir entre la traduction automatique et la traduction humaine. Il prend en charge les deux et sait faire la différence.

Lorsqu'un paragraphe est traduit automatiquement et que la source change, Rasepi le retraduit automatiquement. Aucune intervention humaine n'est nécessaire. Le glossaire et les règles de style assurent la cohérence.

Lorsqu'un paragraphe a été édité manuellement par un traducteur humain, qui l'a peut-être réécrit pour y apporter des nuances culturelles ou ajouter un contexte que la machine n'aurait pas saisi, Rasepi respecte ce travail. Si la source change, le système signale que le paragraphe doit être révisé, mais ne remplace jamais silencieusement les modifications humaines. Le traducteur voit ce qui a changé dans la source et décide comment mettre à jour sa version.

Cela signifie que la qualité de votre traduction s'améliore au fil du temps. La traduction automatique s'occupe du gros du travail. Les traducteurs humains se concentrent sur les paragraphes qui ont besoin d'une touche humaine. Aucun des deux n'empiète sur le travail de l'autre.

Deux modes : toujours à jour ou traduire à la demande

Pour chaque langue, vous choisissez le moment où les traductions ont lieu :

Chaque fois que quelqu'un enregistre le document source, les paragraphes modifiés sont immédiatement retraduits. Ce mode est idéal pour les langues les plus importantes, où les lecteurs s'attendent à une précision de dernière minute.
Les paragraphes modifiés sont signalés mais ne sont pas traduits tant que le lecteur n'a pas ouvert le document dans cette langue. Idéal pour les langues utilisées moins fréquemment. Pas de coûts de traduction inutiles pour un contenu que personne ne lit.

Les deux modes utilisent le même glossaire, les mêmes règles de style, la même qualité. La seule différence réside dans le timing.

Ce que cela donne en pratique

Supposons que vous dirigiez une entreprise dont les équipes se trouvent à Londres, Munich, Paris et Tokyo. Votre documentation est rédigée en anglais.

Un chef de produit à Londres met à jour le guide de déploiement. Une section traite d'une nouvelle étape CI/CD.

Voici ce qui se passe :

La section modifiée est retraduite en quelques secondes. "Sprint Review" devient "Sprint-Überprüfung" parce que c'est dans votre glossaire. Formel "Sie" parce que c'est votre paramètre de formalité. Les dates au format 24 heures parce que c'est votre règle configurée. L'instruction habituelle "utiliser un ton direct et impératif" façonne la phraséologie. La section DSGVO ajoutée par l'équipe de Munich ? Elle n'a pas été modifiée.
Même section, retraduite immédiatement. Formalité "Vous". Les termes du glossaire français sont appliqués. Symboles monétaires après les chiffres, selon vos instructions. Le reste du document reste exactement tel que le bureau de Paris l'a revu la dernière fois.
La section modifiée est signalée comme périmée. Lorsque quelqu'un à Tokyo ouvre le document, il est traduit à la volée. Le formatage de la liste de numéros est préservé. Leur note d'outil locale reste en place.

Une seule modification. Trois langues mises à jour. Aucune retraduction de document complet. Terminologie et ton cohérents, respect des ajouts locaux de chaque équipe.

En parlant de qualité linguistique

Le moteur de traduction derrière tout cela est DeepL, la même technologie qui alimente la fonction Talk to Docs de Rasepi. Vous pouvez parler à votre documentation et obtenir des réponses à haute voix. DeepL Voice gère l'interaction vocale, ce qui signifie que la cohérence terminologique, les règles de style et la qualité linguistique que vous obtenez dans les traductions écrites s'appliquent également aux conversations vocales. Les termes de votre glossaire et les instructions personnalisées sonnent juste, que votre équipe soit en train de lire ou d'écouter.

Des traductions qui ressemblent à votre équipe ne sont pas un luxe. Pour les entreprises qui opèrent dans plusieurs langues, elles font la différence entre une documentation à laquelle les gens font confiance et une documentation qu'ils doivent contourner. Les glossaires, les règles de style, les instructions personnalisées, la retraduction intelligente et le contenu unique par langue rendent cela possible. Automatiquement, dès le premier jour.

Votre documentation doit ressembler à votre équipe dans toutes les langues. Pas comme une machine. Pas comme une autre entreprise. Comme vous.**

Voir la publication multilingue en action →

Dans le moteur de traduction : Glossaires, règles de style et retraduction intelligente

2026-03-31T00:00:00Z

Notre [précédent article sur l'architecture] (/fr/blog/how-plugin-guardrail-and-pipeline-systems-work/) couvrait les plugins, les action guards et le système de pipeline. Celui-ci va plus loin dans le moteur de traduction, la partie qui, selon moi, rend Rasepi fondamentalement différent de toutes les autres plateformes de documentation.

Pas le discours marketing sur la traduction de paragraphes au lieu de pages. Le code réel. Comment les glossaires sont résolus par locataire, comment les règles de style et les instructions personnalisées de DeepL façonnent chaque traduction, comment le hachage de contenu permet de détecter les documents périmés et comment l'orchestrateur décide quels blocs doivent être retraduits.

Le pipeline de traduction

Lorsqu'un utilisateur enregistre un document, le système ne se contente pas de tout retraduire. Il exécute une séquence assez spécifique :

Analyser le JSON TipTap en blocs individuels
Comparer les hachages de contenu pour détecter les blocs qui ont réellement changé
Pour les blocs modifiés, résoudre le glossaire du locataire et la liste des règles de style pour la paire de langues.
Appliquer les règles de style, les instructions personnalisées et la formalité de la configuration du locataire
Envoyer uniquement les blocs modifiés à DeepL
Mise à jour des blocs de traduction et synchronisation des hachages de contenu

Chaque étape est son propre service avec sa propre interface. C'est important car chaque étape peut être remplacée par autre chose, un autre fournisseur de traduction, un autre algorithme de hachage, une autre source de glossaire.

Résolution du glossaire : à l'échelle du locataire, synchronisé avec DeepL

Les glossaires DeepL ont une contrainte que la plupart des gens ignorent : **Il n'est pas possible de modifier un glossaire DeepL. Toute modification entraîne la suppression de l'ancien glossaire et la création d'un nouveau.

Rasepi gère cela en considérant la base de données comme la source de vérité et DeepL les glossaires comme des artefacts jetables. L'entité TenantGlossary stocke tout localement :

public class TenantGlossary : ITenantScoped
{
    public Guid Id { get; set; }
    public Guid TenantId { get; set; }
    public string Name { get; set; }
    public string SourceLanguage { get; set; }     // e.g. "en"
    public string TargetLanguage { get; set; }     // e.g. "de"
    public string? DeepLGlossaryId { get; set; }   // Runtime DeepL ID
    public DateTime? LastSyncedAt { get; set; }
    public bool IsDirty { get; set; } = true;      // Triggers re-sync
    public ICollection<TenantGlossaryEntry> Entries { get; set; }
}

Lorsqu'un utilisateur ajoute une entrée de glossaire, par exemple en faisant correspondre "Sprint Review" à "Sprint-Überprüfung" pour EN→DE, l'enregistrement de la base de données est immédiatement mis à jour et IsDirty devient true. Le glossaire DeepL n'est pas recréé immédiatement. Il est recréé paresseusement, la prochaine fois qu'une traduction en aura besoin.

Le flux de synchronisation

Avant chaque appel de traduction, le système résout le glossaire :

public async Task<string?> GetOrSyncDeepLGlossaryIdAsync(
    string sourceLanguage, string targetLanguage,
    CancellationToken ct = default)
{
    var glossary = await _db.TenantGlossaries
        .Include(g => g.Entries)
        .FirstOrDefaultAsync(g =>
            g.SourceLanguage == sourceLanguage &&
            g.TargetLanguage == targetLanguage, ct);

    if (glossary is null || glossary.Entries.Count == 0)
        return null;

    if (!glossary.IsDirty && glossary.DeepLGlossaryId is not null)
        return glossary.DeepLGlossaryId;

    // Dirty - delete old, create new
    if (glossary.DeepLGlossaryId is not null)
        await _deepL.DeleteGlossaryAsync(glossary.DeepLGlossaryId);

    var entries = glossary.Entries
        .ToDictionary(e => e.SourceTerm, e => e.TargetTerm);

    var deepLGlossary = await _deepL.CreateGlossaryAsync(
        $"rasepi-{glossary.Id}",
        glossary.SourceLanguage,
        glossary.TargetLanguage,
        entries);

    glossary.DeepLGlossaryId = deepLGlossary.GlossaryId;
    glossary.IsDirty = false;
    glossary.LastSyncedAt = DateTime.UtcNow;
    await _db.SaveChangesAsync(ct);

    return glossary.DeepLGlossaryId;
}

Trois choses méritent d'être notées ici :

Synchronisation paresseuse Nous n'appelons l'API DeepL que lorsqu'une traduction est réellement nécessaire. La modification en masse des entrées du glossaire ne déclenche pas des dizaines d'appels à l'API.
**La requête passe par les filtres de requête globaux d'EF, de sorte que TenantGlossaries est automatiquement délimité. Les entrées du glossaire du locataire A ne se retrouvent jamais dans les traductions du locataire B.
Un glossaire par paire de langues. DeepL applique cette règle de toute façon. Un glossaire EN→DE, un glossaire EN→FR, et ainsi de suite. La paire (SourceLanguage, TargetLanguage) est unique pour chaque locataire.

Entrées du glossaire

Les entrées individuelles ne sont que des correspondances de termes :

public class TenantGlossaryEntry
{
    public Guid Id { get; set; }
    public Guid GlossaryId { get; set; }
    public string SourceTerm { get; set; }   // e.g. "Sprint Review"
    public string TargetTerm { get; set; }   // e.g. "Sprint-Überprüfung"
}

L'API vous offre un CRUD complet ainsi qu'une importation/exportation CSV pour une gestion en masse :

POST   /admin/glossaries                       Create glossary
POST   /admin/glossaries/{id}/entries           Add term
PUT    /admin/glossaries/{id}/entries/{entryId}  Update term
DELETE /admin/glossaries/{id}/entries/{entryId}  Remove term
POST   /admin/glossaries/{id}/import            Import CSV
GET    /admin/glossaries/{id}/export            Export CSV
POST   /admin/glossaries/{id}/sync              Force DeepL sync

L'importation CSV est très utile pour les équipes qui migrent à partir de systèmes de mémoire de traduction existants. Exportez vos termes, nettoyez-les, importez-les dans Rasepi et la prochaine traduction utilisera automatiquement le nouveau glossaire.

Règles de style, instructions personnalisées et formalités

Les glossaires traitent la terminologie. Mais la terminologie ne représente que la moitié du travail. Une traduction peut utiliser tous les bons mots et pourtant sonner faux. Mauvais ton, mauvais format de date, mauvaises conventions de ponctuation.

L'API Règles de style (v3) de DeepL résout ce problème. Vous pouvez créer des listes de règles de style réutilisables qui combinent deux types de contrôles :

Règles configurées, conventions de formatage prédéfinies pour les dates, les heures, la ponctuation, les nombres, etc.
Instructions personnalisées, directives en texte libre qui déterminent le ton, la formulation et les conventions spécifiques au domaine.

Rasepi crée et gère ces instructions par locataire et par langue cible. L'entité TenantStyleRuleList stocke le DeepL style_id avec les règles configurées et les instructions personnalisées du locataire :

public class TenantStyleRuleList : ITenantScoped
{
    public Guid Id { get; set; }
    public Guid TenantId { get; set; }
    public string Name { get; set; }
    public string TargetLanguage { get; set; }      // e.g. "de"
    public string? DeepLStyleId { get; set; }       // Runtime DeepL style_id
    public string ConfiguredRulesJson { get; set; }  // Serialized configured rules
    public bool IsDirty { get; set; } = true;
    public DateTime? LastSyncedAt { get; set; }
    public ICollection<TenantCustomInstruction> CustomInstructions { get; set; }
}

Création de listes de règles de style

Lorsqu'un administrateur définit des règles de traduction pour l'allemand, Rasepi fait appel à l'API v3 de DeepL pour créer la liste de règles de style. Voici à quoi cela ressemble :

public async Task<string> CreateOrSyncStyleRuleListAsync(
    TenantStyleRuleList ruleList, CancellationToken ct = default)
{
    if (!ruleList.IsDirty && ruleList.DeepLStyleId is not null)
        return ruleList.DeepLStyleId;

    // DeepL style rule lists are mutable - we can update in place
    if (ruleList.DeepLStyleId is not null)
    {
        // Replace configured rules on existing list
        await _httpClient.PutAsJsonAsync(
            $"v3/style_rules/{ruleList.DeepLStyleId}/configured_rules",
            JsonSerializer.Deserialize<JsonElement>(ruleList.ConfiguredRulesJson),
            ct);

        // Sync custom instructions
        await SyncCustomInstructionsAsync(ruleList, ct);

        ruleList.IsDirty = false;
        ruleList.LastSyncedAt = DateTime.UtcNow;
        return ruleList.DeepLStyleId;
    }

    // Create new style rule list
    var payload = new
    {
        name = $"rasepi-{ruleList.TenantId}-{ruleList.TargetLanguage}",
        language = ruleList.TargetLanguage,
        configured_rules = JsonSerializer.Deserialize<JsonElement>(
            ruleList.ConfiguredRulesJson),
        custom_instructions = ruleList.CustomInstructions.Select(ci => new
        {
            label = ci.Label,
            prompt = ci.Prompt,
            source_language = ci.SourceLanguage
        })
    };

    var response = await _httpClient.PostAsJsonAsync("v3/style_rules", payload, ct);
    var result = await response.Content.ReadFromJsonAsync<StyleRuleResponse>(ct);

    ruleList.DeepLStyleId = result.StyleId;
    ruleList.IsDirty = false;
    ruleList.LastSyncedAt = DateTime.UtcNow;
    await _db.SaveChangesAsync(ct);

    return ruleList.DeepLStyleId;
}

Contrairement aux glossaires, les listes de règles de style de DeepL sont mutables. Vous pouvez remplacer les règles configurées en place par PUT /v3/style_rules/{style_id}/configured_rules, et les instructions personnalisées peuvent être ajoutées, mises à jour ou supprimées individuellement. C'est beaucoup plus convivial pour le raffinement itératif.

A quoi ressemblent les règles configurées

Les règles configurées couvrent les conventions de formatage qui varient en fonction de la langue ou des préférences de l'entreprise. Des choses comme :

{
  "dates_and_times": {
    "time_format": "use_24_hour_clock",
    "calendar_era": "use_bc_and_ad"
  },
  "punctuation": {
    "periods_in_academic_degrees": "do_not_use"
  },
  "numbers": {
    "decimal_separator": "use_comma"
  }
}

Ces règles peuvent sembler anodines, mais elles sont vite compliquées. Un document allemand qui utilise le format horaire AM/PM et des décimales séparées par des points se lit simplement comme "traduit de l'anglais" pour un lecteur allemand. Le fait de définir use_24_hour_clock et use_comma pour les séparateurs décimaux dans toutes les traductions allemandes élimine immédiatement ce problème.

Instructions personnalisées : c'est la vraie puissance

Les instructions personnalisées sont des directives en texte libre, jusqu'à 200 par liste de règles de style, chacune pouvant contenir jusqu'à 300 caractères. En gros, vous dites à DeepL comment façonner la traduction en langage clair :

public class TenantCustomInstruction
{
    public Guid Id { get; set; }
    public Guid StyleRuleListId { get; set; }
    public string Label { get; set; }              // e.g. "Tone instruction"
    public string Prompt { get; set; }             // e.g. "Use a friendly, diplomatic tone"
    public string? SourceLanguage { get; set; }    // Optional source lang filter
}

Exemples réels de nos locataires :

"Use a friendly, diplomatic tone" pour une startup qui veut des documents accessibles
"Always use 'Sie' form, never 'du'" pour un cabinet d'avocats allemand
"Translate 'deployment' as 'Bereitstellung', never 'Deployment'" pour des termes qui ont besoin d'être traités en fonction du contexte au-delà d'un simple mappage de glossaire
pour les entreprises basées au Royaume-Uni qui traduisent d'une variante anglaise à l'autre
"Put currency symbols after the numeric amount" pour correspondre aux conventions européennes

Les instructions personnalisées sont très utiles pour les conventions spécifiques à un domaine qui n'ont pas leur place dans les entrées d'un glossaire. Un glossaire associe un terme à un autre. Une instruction personnalisée peut dire "lorsque vous traduisez des documents d'API, utilisez l'humeur impérative au lieu de la voix passive". Il s'agit d'un type de contrôle complètement différent.

Formalité

Le paramètre formality de DeepL (default, more, less, prefer_more, prefer_less) est toujours disponible en tant que contrôle séparé avec les règles de style. Allemand "du" contre "Sie", français "tu" contre "vous", niveaux de politesse japonais. Ceux-ci sont définis pour chaque langue du locataire via TenantLanguageConfig :

public class TenantLanguageConfig : ITenantScoped
{
    public string LanguageCode { get; set; }
    public string DisplayName { get; set; }
    public bool IsEnabled { get; set; }
    public TranslationTrigger Trigger { get; set; }
    public string? Formality { get; set; }         // "more", "less", "prefer_more", etc.
    public string? StyleRuleListId { get; set; }   // Links to TenantStyleRuleList
    public string? TranslationProvider { get; set; }
    public int SortOrder { get; set; }
    public bool IsDefault { get; set; }
}

La formalité, les règles de style et les glossaires se complètent. Un seul appel de traduction peut contenir ces trois éléments :

var glossaryId = await GetOrSyncDeepLGlossaryIdAsync(sourceLang, targetLang, ct);
var styleId = await GetOrSyncStyleRuleListAsync(targetLang, ct);
var formality = tenantLanguageConfig.Formality ?? "default";

// Build the v2/translate request payload
var payload = new
{
    text = new[] { blockContent },
    source_lang = NormalizeLanguageCode(sourceLang),
    target_lang = NormalizeLanguageCode(targetLang),
    glossary_id = glossaryId,
    style_id = styleId,
    formality = formality,
    preserve_formatting = true,
    context = surroundingContext,  // Adjacent blocks, not billed
    model_type = "quality_optimized"
};

Deux choses méritent d'être notées ici :

**Le paramètre context ** Nous transmettons les blocs adjacents comme contexte pour améliorer la qualité de la traduction. DeepL l'utilise pour résoudre les ambiguïtés, mais ne le traduit pas et ne le facture pas. Un paragraphe sur les "cellules" se traduit différemment selon que le contexte environnant est un document de biologie ou un manuel de tableur.
**Toute demande avec style_id ou custom_instructions utilise automatiquement le modèle quality_optimized de DeepL. Il s'agit du niveau de qualité le plus élevé. Vous ne pouvez pas les combiner avec latency_optimized, et c'est une contrainte délibérée de DeepL. La personnalisation du style nécessite le modèle complet.

Pourquoi cela est plus important que vous ne le pensez

Imaginez une entreprise rédigeant des documents internes en allemand avec un "du" informel qui passe soudainement au "Sie" formel dans une section traduite. Cela semble au mieux incohérent, au pire non professionnel. La formalité permet d'y remédier. Mais la formalité seule ne permet pas de repérer un document qui utilise des horodatages AM/PM alors que votre bureau allemand utilise le format 24 heures, ou qui place le symbole de la devise avant le nombre au lieu de le placer après.

Tous ces éléments superposés (règles de style, instructions personnalisées, formalisme, glossaires) produisent des traductions qui se lisent comme si elles avaient été écrites par un membre de votre équipe. Et non comme le résultat d'une machine qui ne sait pas que votre entreprise existe.

La couche de service DeepL

Toutes les communications DeepL passent par IDeepLService. Elle englobe le SDK officiel DeepL .NET et gère les appels de l'API v3 pour les règles de style :

public interface IDeepLService
{
    // Text translation (v2)
    Task<TextResult> TranslateTextAsync(
        string text, string sourceLanguage, string targetLanguage,
        string? options = null);

    Task<TextResult[]> TranslateTextBatchAsync(
        IEnumerable<string> texts, string sourceLanguage,
        string targetLanguage, string? options = null);

    // Glossary management (v2)
    Task<GlossaryInfo> CreateGlossaryAsync(
        string name, string sourceLang, string targetLang,
        Dictionary<string, string> entries);
    Task DeleteGlossaryAsync(string glossaryId);
    Task<GlossaryInfo> GetGlossaryAsync(string glossaryId);
    Task<GlossaryInfo[]> ListGlossariesAsync();
    Task<Dictionary<string, string>> GetGlossaryEntriesAsync(
        string glossaryId);

    // Style rules (v3)
    Task<StyleRuleResponse> CreateStyleRuleListAsync(
        string name, string language,
        JsonElement configuredRules,
        IEnumerable<CustomInstructionRequest> customInstructions);
    Task ReplaceConfiguredRulesAsync(
        string styleId, JsonElement configuredRules);
    Task<CustomInstructionResponse> AddCustomInstructionAsync(
        string styleId, string label, string prompt,
        string? sourceLanguage = null);
    Task DeleteCustomInstructionAsync(
        string styleId, string instructionId);
    Task DeleteStyleRuleListAsync(string styleId);

    // Usage tracking
    Task<Usage> GetUsageAsync();
    Task<Language[]> GetSourceLanguagesAsync();
    Task<Language[]> GetTargetLanguagesAsync();
}

L'implémentation gère la normalisation du code de la langue. DeepL nécessite EN-US ou EN-GB au lieu de en, et PT-PT ou PT-BR au lieu de pt :

private static string NormalizeLanguageCode(string code)
    => code.ToLower() switch
    {
        "en" => "EN-US",
        "pt" => "PT-PT",
        _ => code.ToUpper()
    };

La traduction par lots utilise un découpage en morceaux de 50 éléments pour rester dans les limites de l'API de DeepL tout en maximisant le débit :

public async Task<TranslationBatchResult> TranslateBatchAsync(
    Dictionary<string, string> texts,
    string sourceLanguage, string targetLanguage)
{
    var translations = new Dictionary<string, string>();
    long totalChars = 0;

    foreach (var chunk in texts.Chunk(50))
    {
        var results = await _deepL.TranslateTextBatchAsync(
            chunk.Select(kv => kv.Value),
            sourceLanguage, targetLanguage);

        for (int i = 0; i < chunk.Length; i++)
        {
            translations[chunk[i].Key] = results[i].Text;
            totalChars += chunk[i].Value.Length;
        }
    }

    return new TranslationBatchResult
    {
        Translations = translations,
        BilledCharacters = totalChars
    };
}

Comme nous n'envoyons que des blocs périmés, et non des documents entiers, un lot de traduction typique pour une seule édition contient 1 à 3 blocs au lieu de plus de 40. C'est de là que vient la réduction de 94 % des coûts.

L'orchestrateur de traduction

Le TranslationOrchestrator décide de ce qu'il faut faire avec chaque bloc lorsque le document source change. Passons en revue l'arbre de décision :

public async Task OrchestrateTranslationAsync(
    Guid entryId, List<Guid> changedBlockIds,
    CancellationToken ct = default)
{
    var entry = await _db.Entries
        .FirstOrDefaultAsync(e => e.Id == entryId, ct);

    var translations = await _db.EntryTranslations
        .Where(t => t.EntryId == entryId)
        .ToListAsync(ct);

    foreach (var translation in translations)
    {
        var langConfig = await GetLanguageConfigAsync(
            translation.Language, ct);

        var translationBlocks = await _db.TranslationBlocks
            .Where(tb => changedBlockIds.Contains(tb.SourceBlockId)
                      && tb.Language == translation.Language)
            .ToListAsync(ct);

        foreach (var block in translationBlocks)
        {
            if (block.IsLocked || block.TranslatedById is not null)
            {
                // Human-edited or locked - mark stale, don't overwrite
                block.Status = TranslationStatus.Stale;
            }
            else if (langConfig.Trigger == TranslationTrigger.AlwaysTranslate)
            {
                // Machine-translated, auto mode - retranslate now
                await RetranslateBlockAsync(block, translation.Language, ct);
            }
            else
            {
                // TranslateOnFirstVisit - mark stale, translate later
                block.Status = TranslationStatus.Stale;
            }
        }
    }

    await _db.SaveChangesAsync(ct);
}

Le point clé : **Si un traducteur a modifié manuellement un bloc, par exemple en y ajoutant un contexte culturel ou en le reformulant pour plus de clarté, le système respecte ce travail. Il marque le bloc comme périmé pour que le traducteur sache que la source a changé, mais il ne remplacera pas silencieusement ses modifications.

Les blocs traduits en machine pour lesquels l'option AlwaysTranslate est activée sont retraduits immédiatement. Les blocs traduits automatiquement avec TranslateOnFirstVisit sont marqués comme périmés et traduits lorsque quelqu'un ouvre le document dans cette langue.

Déclencheurs de traduction : quand les traductions ont lieu

Chaque langue possède un TranslationTrigger qui contrôle le timing :

public enum TranslationTrigger
{
    AlwaysTranslate,         // Translate on every save
    TranslateOnFirstVisit    // Translate when first opened in that language
}

Le AlwaysTranslate est utile pour les langues prioritaires dont les traductions doivent être immédiatement à jour. Le français pour une entreprise ayant un grand bureau à Paris. L'allemand pour une entreprise dont le siège se trouve à Munich.

TranslateOnFirstVisit est utile pour les langues dont on a besoin occasionnellement, mais qui ne valent pas le coût de l'API pour qu'elles soient toujours parfaitement à jour. Lorsque quelqu'un ouvre le document dans cette langue, les blocs périmés sont traduits à la volée.

Les deux modes utilisent la même résolution de glossaire, les mêmes paramètres de formalité et le même hachage de contenu. La seule différence réside dans le timing.

Adaptation unique du contenu et de la structure

C'est ici que l'architecture porte vraiment ses fruits, au-delà de la simple traduction.

Lorsqu'un traducteur allemand ajoute une section de conformité DSGVO qui n'existe pas en anglais, il l'ajoute en tant que nouveau bloc dans la version allemande. Ce bloc n'a pas de SourceBlockId, il est signalé comme un contenu unique. Le système ne l'envoie jamais à la retraduction parce qu'il n'y a pas de source à partir de laquelle traduire. Il n'existe qu'en allemand.

Lorsqu'un traducteur japonais remplace une liste à puces par une liste numérotée (une convention courante dans la rédaction technique japonaise), l'indicateur IsStructureAdapted du bloc préserve ce contenu lors des prochains cycles de retraduction :

var translation = new TranslationBlock
{
    SourceBlockId = sourceBlockId,
    Language = targetLanguage,
    BlockType = translatedBlockType,
    SourceBlockType = sourceBlock.BlockType,
    IsStructureAdapted = translatedBlockType != sourceBlock.BlockType,
    StructureAdaptationNotes = "Numbered list preferred in JP technical docs",
    SourceContentHash = sourceBlock.ContentHash,
    Status = TranslationStatus.UpToDate,
};

L'indicateur IsNoTranslate gère le contenu qui doit être copié mot pour mot : les blocs de code, les URL, les noms de produits, les notations mathématiques. Le prestataire de services de traduction ne s'en préoccupe pas.

Mettre le tout ensemble

Examinons le flux complet. Un utilisateur à Londres édite un paragraphe dans le document source anglais, et votre bureau de Munich a réglé l'allemand sur AlwaysTranslate :

**TipTap envoie JSON à l'API.
Extraction des blocs et détection des modifications CreateBlocksFromDocumentAsync analyse le JSON, recalcule les hachages de contenu et compare les anciens et les nouveaux hachages afin d'identifier les blocs qui ont réellement changé.
Orchestrator s'exécute. Trouve le EntryTranslation allemand, vérifie le bloc allemand. Il s'agit d'une traduction automatique, non verrouillée, non éditée par l'homme, donc éligible à la retraduction.
Configuration de la traduction chargée ID du glossaire résolu via GetOrSyncDeepLGlossaryIdAsync("en", "de"), règles de style via GetOrSyncStyleRuleListAsync("de"), formalité fixée à "more" (formel "Sie"), blocs adjacents transmis en tant que contexte pour la désambiguïsation.
DeepL call. Bloc unique envoyé avec l'ID du glossaire, l'ID du style, la formalité et le contexte.
**Le contenu traduit est stocké, SourceContentHash est synchronisé, le statut est défini sur UpToDate. Un bloc traduit au lieu de plus de 40. Les 39 blocs restants ? Ils n'ont pas été modifiés.

Pendant ce temps, votre bureau de Tokyo a réglé le japonais sur TranslateOnFirstVisit. Le même éditeur marque le bloc de traduction japonais comme Stale. Lorsque quelqu'un à Tokyo ouvre le document, les étapes 5 à 9 se déroulent à la volée. L'adaptation de leur structure (liste numérotée) est préservée. Les blocs uniques restent exactement à leur place.

Je pense que le moteur de traduction est la partie de Rasepi qui apporte la valeur la plus visible. Des traductions qui utilisent votre terminologie, suivent vos conventions de formatage, obéissent à vos instructions personnalisées, correspondent à votre ton, respectent le travail de vos traducteurs et coûtent une fraction de ce que coûterait la retraduction d'un document complet. L'architecture rend tout cela automatique et se tient à l'écart lorsque les humains veulent prendre le relais.

Le même moteur DeepL qui alimente les traductions écrites alimente également Talk to Docs, notre interface de documentation conversationnelle, DeepL Voice gérant l'interaction orale. Mêmes glossaires, mêmes règles de style, même formalité, même cohérence. Que votre équipe lise la documentation ou qu'elle lui parle, la qualité linguistique est identique.

Découvrez l'API de traduction →

Ne plus conserver cinq copies du même document

2026-03-31T00:00:00Z

Ouvrez le wiki de votre entreprise et cherchez "onboarding". Combien de résultats obtenez-vous ?

Si vous êtes une entreprise internationale, je suppose qu'il n'y en a pas un seul. C'est probablement quelque chose comme ça :

Onboarding Guide (EN)
Onboarding Guide - Germany
Onboarding Guide - Japan
Onboarding LATAM (draft)
Onboarding - New (DO NOT USE OLD ONE)

Cinq documents. Tous couvrent à peu près la même chose. Tous légèrement différents. Tous maintenus par des personnes différentes selon des calendriers différents. Certains sont à jour, d'autres ont trois mois de retard, et l'un d'entre eux n'est plus connu de personne.

C'est ce qui se passe lorsque votre plateforme de documentation ne peut pas gérer correctement le contenu multilingue. Vous finissez par copier l'intégralité du document pour chaque marché, et chaque copie s'éloigne lentement des autres.

Le piège de la copie et de la localisation

Tout commence de manière assez innocente. Vous avez un excellent guide d'accueil en anglais. Le bureau de Berlin en a besoin en allemand, alors quelqu'un le copie, le traduit et y ajoute les éléments spécifiques à l'Allemagne : formation DSGVO, informations sur le Betriebsrat, inscription à l'assurance maladie locale.

Puis Tokyo en a besoin. Copier à nouveau. Traduire. Ajouter les éléments spécifiques au Japon : inscription au hanko, procédure d'obtention de la carte de transport, guide de l'étiquette au bureau.

Vient ensuite São Paulo. Même chose. Copier, traduire, ajouter du contenu local sur les exigences du CLT, les chèques-repas et les documents fiscaux.

Vous avez maintenant quatre documents. L'original anglais est régulièrement mis à jour. La version allemande a été mise à jour au cours du dernier trimestre. La version japonaise... quelqu'un pense que Tanaka-san l'a mise à jour en octobre. La version brésilienne a été créée par un contractant qui est parti, et personne n'y a touché depuis.

**Et chacune d'entre elles contient un mélange de contenu partagé (ce qui est identique partout) et de contenu local (ce qui est spécifique à ce marché). Mais la plateforme ne fait pas la différence. Ce n'est que du texte sur une page.

Ainsi, lorsque quelqu'un met à jour la section relative à la politique de sécurité dans l'original anglais, personne ne met à jour les quatre autres. Ou pire encore, quelqu'un met à jour la section allemande, mais pas la section japonaise. Vous vous retrouvez alors avec cinq documents qui disent tous des choses légèrement différentes sur la même politique de l'entreprise.

Le vrai problème : le contenu partagé et le contenu local sont mélangés

Le fait est que la plupart de ces documents sont identiques à 70-80 %. Les étapes d'intégration, la configuration des outils, les politiques de sécurité, la section sur les valeurs de l'entreprise, la liste des personnes à contacter. Tout cela est identique, que vous soyez à Berlin, à Tokyo ou à São Paulo.

Les éléments locaux représentent peut-être 20 à 30 % du document. Les exigences de conformité spécifiques, les avantages locaux, les processus régionaux, les contacts de l'équipe pour ce bureau.

Mais lorsque tout se trouve dans un seul grand document plat par langue, il n'y a aucun moyen de savoir quelles sont les parties partagées et quelles sont les parties locales. Une mise à jour du contenu partagé implique de vérifier et de mettre à jour manuellement chaque copie. Ce que personne ne fait systématiquement. C'est pourquoi vos copies dérivent.

Un document. C'est tout.

Dans Rasepi, le guide d'accueil est un seul document. Pas un par langue. Un seul.

Le contenu partagé, les 70 à 80 % qui sont les mêmes partout, est rédigé une fois en anglais et traduit automatiquement dans toutes les langues utilisées par votre équipe. Lorsque quelqu'un met à jour la section relative à la politique de sécurité en anglais, elle est retraduite en allemand, en japonais, en portugais et en français en quelques secondes. Pas de copie manuelle. Pas de "quelqu'un devrait mettre à jour les autres versions".

Le contenu local vit dans sa version linguistique respective. La section de formation de l'OGDV n'existe que dans la version allemande. Le processus hanko n'existe que dans la version japonaise. Les exigences du CLT n'existent que dans la version portugaise. Ces sections sont identifiées comme un contenu unique, elles appartiennent à cette langue et ne sont jamais écrasées par une nouvelle traduction.

Nous avons expliqué exactement comment cela fonctionne dans notre article sur [le fonctionnement des traductions Rasepi] (/en/blog/how-rasepi-translations-work-and-why-the-the-sound-like-your-team/). En bref : chaque paragraphe a sa propre identité. Les paragraphes partagés sont traduits et suivis. Les paragraphes uniques appartiennent à leur langue et rien d'autre ne les touche.

Le résultat ? Votre recherche wiki pour "onboarding" ne donne qu'un seul résultat. Juste "Onboarding". Si vous l'ouvrez en anglais, vous verrez la version anglaise avec tout le contenu partagé. Ouvrez-le en allemand, vous verrez le même contenu partagé en allemand plus les sections spécifiques à l'Allemagne. Ouvrez-la en japonais, vous voyez le même contenu partagé en japonais plus les sections spécifiques au Japon.

Un seul document. Pas cinq. Pas cinq documents qui pourrissent lentement à des vitesses différentes.

Ce que cela change réellement

Ce n'est pas seulement plus ordonné. Il modifie fondamentalement le fonctionnement de votre documentation d'un bureau à l'autre.

Les mises à jour parviennent à tout le monde

Lorsque vous mettez à jour la partie partagée du guide d'accueil, elle est mise à jour dans toutes les langues. Pas à terme, pas après que quelqu'un se soit souvenu de le faire. Automatiquement. Le paragraphe que vous avez modifié est retraduit. Tout le reste reste exactement au même endroit.

Cela signifie que votre bureau de Tokyo lit la même politique d'entreprise que votre bureau de Londres. Pas la version d'il y a six mois que personne n'a eu le temps de mettre à jour.

Les équipes locales sont propriétaires de leur contenu local

Votre équipe de Munich peut ajouter une section sur la réduction locale dans les salles de sport sans craindre qu'elle soit effacée par la prochaine mise à jour en anglais. Leur contenu unique leur appartient. Il reste dans la version allemande, sans être modifié par les changements apportés à la source anglaise.

Il en va de même pour tous les autres bureaux. Le contenu local est véritablement local. Il n'interfère pas avec le contenu partagé, et le contenu partagé n'interfère pas avec lui.

Les nouveaux embauchés reçoivent les bonnes informations

Un nouvel employé de São Paulo ouvre le guide d'intégration et y trouve tout ce dont il a besoin. Les sections partagées (outils, sécurité, valeurs) sont en portugais. Les sections spécifiques au Brésil (CLT, documents fiscaux, chèques-repas) sont juste à côté. Un seul document, tout dans leur langue, rien ne manque, rien n'est dépassé.

Ils n'ont pas besoin de savoir que trois autres bureaux ont des sections locales différentes. Ils voient simplement leur version. Propre et complet.

Le nombre de pages diminue

C'est un calcul simple. Si vous avez 50 documents clés et que vous les gérez dans 5 langues avec l'approche "copier et localiser", vous avez 250 documents. Dans Rasepi, vous en avez 50. Chacun avec des versions linguistiques qui partagent un contenu commun et maintiennent leurs propres sections locales.

250 documents à gérer contre 50. Ce sont 200 pages de frais généraux de maintenance qui disparaissent.

Il n'y a pas que l'onboarding

L'intégration est l'exemple le plus évident, car toutes les entreprises internationales sont confrontées à ce problème. Mais le même schéma se retrouve partout :

Les étapes de base sont les mêmes, mais l'équipe de Berlin utilise un serveur de stockage local et Tokyo a un processus d'approbation différent.
Documentation de conformité** Section GDPR pour l'Europe, LGPD pour le Brésil, APPI pour le Japon. Tous dans le même document, chacun n'apparaissant que là où il est pertinent.
Les avantages sociaux et les politiques de ressources humaines **La politique en matière de congé parental est différente dans chaque pays. Les valeurs de l'entreprise sont les mêmes partout.
Le produit fonctionne de la même manière partout, mais les méthodes de paiement, les heures d'ouverture de l'assistance et les réglementations régionales varient.

Chacun de ces éléments est un document que la plupart des entreprises conservent sous forme de copies distinctes pour chaque marché. Et chacun d'entre eux pourrait être un document unique avec un contenu partagé et local.

L'effet composé

C'est là que les choses se compliquent. Une entreprise qui possède 200 documents répartis sur 4 marchés ne gère pas 200 documents. Elle en gère 800. Mais elle a du personnel pour 200. Ce qui se passe en réalité, c'est que

Les versions anglaises sont à jour
Les versions allemandes sont en grande partie à jour
Les versions françaises sont en retard
Les versions japonaises sont un point d'interrogation

Cela vous semble familier ?

Rasepi gère 200 documents. Le contenu partagé est traduit automatiquement. Le contenu local est ajouté par les équipes locales. Chaque version est aussi actuelle que la version anglaise, plus les ajouts locaux effectués par l'équipe régionale.

Les coûts de traduction sont également moins élevés. Lorsque vous mettez à jour un paragraphe en anglais, seul ce paragraphe est retraduit dans toutes les langues. Pas le document entier, ni les 200 documents. Seul le paragraphe qui a été modifié l'est. Nous avons expliqué [comment cela fonctionne] (/fr/blog/how-rasepi-translations-work-and-why-the-the-sound-like-your-team/) en détail, y compris le glossaire et les règles de style qui rendent le contenu traduit naturel.

Une vérification rapide

Si vous dirigez une équipe internationale, posez-vous la question :

**Recherchez le même sujet et comptez les copies spécifiques à la langue.
**Quelle est l'actualité des versions non anglaises ? ** Vérifiez la date de dernière modification de vos documents allemands, français ou japonais. Quel est leur retard ?
**Les équipes locales ajoutent-elles du contenu à leurs versions ? ou ont-elles renoncé à le faire parce qu'il est écrasé ?
**Combien de temps dure l'onboarding dans les bureaux non anglophones ? ** Si c'est plus long, il y a de fortes chances que la documentation ne les serve pas correctement.

Si les réponses vous mettent mal à l'aise, vous n'êtes pas le seul. La plupart des entreprises ne se rendent pas compte de l'ampleur des frais généraux qu'elles ont engendrés jusqu'à ce qu'elles comptent les copies.

La documentation doit s'adapter à votre entreprise, et non se multiplier. Chaque copie que vous conservez est une copie qui peut prendre du retard, embrouiller un nouvel employé ou contredire la version que quelqu'un d'autre est en train de lire. Un document par sujet, avec un contenu partagé traduit et un contenu local à sa place, voilà comment la documentation devrait fonctionner dans une entreprise internationale.

**Votre wiki ne devrait pas avoir besoin de cinq copies du même document. Un seul suffit. Des étapes partagées traduites, des étapes locales par langue. C'est tout.

Voir la publication multilingue en action →

Le cas commercial de la localisation au niveau des blocs

2026-03-24T00:00:00Z

Il existe un modèle dans toutes les entreprises qui opèrent au-delà des frontières. La documentation anglaise est solide. La version allemande a trois mois de retard. La version japonaise a été traduite une fois, par un sous-traitant, et personne n'y a touché depuis. La version portugaise brésilienne n'existe pas encore, même si São Paulo est le bureau qui connaît la croissance la plus rapide.

Tout le monde est d'accord pour dire qu'il s'agit d'un problème. Personne n'a de bonne solution. Jusqu'à présent, la localisation a été traitée comme un projet, un effort ponctuel que l'on budgétise, que l'on exécute, puis que l'on néglige tranquillement jusqu'à la prochaine grande révision.

Cette approche ne fonctionne plus. Voici pourquoi, et ce qui, à mon avis, fonctionne réellement.

La traduction n'est pas la localisation

Mettons les choses au clair sur le plan de la terminologie. La traduction consiste à prendre un texte dans une langue et à produire un texte équivalent dans une autre. La localisation consiste à faire fonctionner les connaissances sur un marché spécifique. Ces deux notions se recoupent, mais ce n'est pas la même chose.

Un document traduit se lit correctement. Un document localisé se lit naturellement. Il tient compte du contexte culturel, des réglementations régionales, de l'outillage local et de la manière dont les gens travaillent sur ce marché.

Cette distinction est importante car la plupart des plateformes documentaires traitent la localisation comme une tâche de traduction. Vous écrivez en anglais, vous appuyez sur un bouton et vous obtenez un résultat en français. C'est fait. Sauf que ce n'est pas fait, parce que.. :

l'équipe française a un processus de déploiement différent que la documentation anglaise ne couvre pas
Les exigences allemandes en matière de conformité ajoutent une étape d'approbation supplémentaire qui n'existe pas ailleurs.
Le bureau japonais utilise un outil interne différent pour le même flux de travail.
Les lecteurs brésiliens portugais ont besoin d'un contexte sur les règles fiscales locales qui n'est pertinent nulle part ailleurs.

**Une traduction directe du document anglais est techniquement correcte dans tous ces cas, et pratiquement inutile dans tous les cas également.

Le problème de la traduction au niveau du document

La localisation traditionnelle fonctionne au niveau du document. Vous avez un document en anglais. Vous le traduisez entièrement en allemand. Lorsque la version anglaise change, vous envoyez l'ensemble du document pour qu'il soit retraduit. Cela pose trois problèmes :

1. C'est coûteux

Si votre guide d'accueil comporte 15 sections et que vous modifiez un paragraphe, vous devrez retraduire les 15 sections. Multipliez ce chiffre par 8 langues et chaque modification devient une question de budget.

2. C'est lent

Envoyer des documents complets à traduire prend du temps. Même avec une traduction automatique moderne, le cycle de révision d'un document complet est beaucoup plus long que la révision d'une seule section modifiée. Les équipes travaillant dans d'autres langues sont toujours en retard.

3. Il ne prend pas en charge le contenu unique

Il s'agit là d'un véritable fléau. Si la version allemande a besoin d'une section supplémentaire sur la conformité à la directive DSGVO, où va-t-elle aller ? Dans un système de traduction au niveau du document, tout contenu ajouté à la version allemande est écrasé la prochaine fois que quelqu'un retraduit à partir de l'anglais. L'équipe allemande apprend vite : n'ajoutez rien, car cela sera effacé.

Localisation au niveau des blocs : une architecture différente

Rasepi ne traduit pas des documents. Il traduit des blocs : des paragraphes, des titres et des sections individuels, chacun étant suivi indépendamment avec sa propre identité et son propre hachage de contenu.

Voici ce que cela signifie en pratique :

Lorsque vous modifiez un seul paragraphe en anglais, Rasepi détecte quel bloc a changé en comparant les hachages de contenu SHA256. Seul ce bloc est envoyé à la traduction via DeepL. Les 14 autres blocs du document restent inchangés. Vos coûts de traduction diminuent ainsi de 94 %.

Lorsque le traducteur allemand doit ajouter une section DSGVO, il l'ajoute en tant que nouveau bloc dans la version allemande. Ce bloc n'existe qu'en allemand. Il n'affecte pas la source anglaise. Il n'est pas écrasé lorsque l'anglais change. Il est signalé comme un contenu unique, de sorte que tout le monde sait qu'il est intentionnel.

Lorsque la version japonaise a besoin d'une structure différente, par exemple une liste numérotée au lieu de puces parce que c'est la convention dans la rédaction technique japonaise, le traducteur peut changer le type de bloc. Le système enregistre cette modification comme une "adaptation de la structure" et la conserve dans les mises à jour ultérieures.

Chaque version linguistique devient un document de premier ordre, et non une copie fantôme.

Comment ça marche, techniquement

Chaque bloc dans Rasepi a :

Un UUID qui persiste à travers toutes les éditions et traductions
Un hachage du contenu** (SHA256) qui change lorsque le texte est modifié.
un index de position** pour que les blocs restent dans le bon ordre
Un drapeau de suppression douce** pour que la suppression d'un bloc en anglais ne rompe pas l'alignement dans d'autres langues.

Lorsqu'un bloc de traduction est créé, il stocke le hachage du contenu du bloc source. À chaque enregistrement, le système compare les hachages. S'ils correspondent, la traduction est en cours. Dans le cas contraire, la traduction est marquée comme périmée et seul ce bloc spécifique doit être pris en compte.

C'est ce mécanisme qui permet de réduire les coûts de 94 %. La plupart des révisions modifient une ou deux sections. Le reste du document, toutes langues confondues, reste inchangé.

Contenu unique par langue

C'est ici que les choses se différencient véritablement des autres plateformes.

Dans Rasepi, chaque version linguistique peut contenir :

Blocs traduits. Traductions directes de la langue source, contrôlées pour éviter qu'elles ne deviennent obsolètes.
Blocs uniques : contenu qui n'existe que dans cette langue, ajouté par l'équipe locale.
Blocs adaptés à la structure : même contenu source, formatage ou type de bloc différent.

Un document unique peut ressembler à ceci d'une langue à l'autre :

| Blocs : anglais (source) | allemand | japonais | anglais (source) | anglais (source) |-------|------------------|--------|----------| | 1 | Introduction | Traduit | Traduit | Traduit | Traduit | 2 | Étapes de la mise en place | Traduit | Structure adaptée (liste numérotée) | | 3 | - | Conformité DSGVO (unique) | - | | 4 | Déploiement | Traduit | Traduit | Traduit | Traduit | 5 | - | - | Note sur l'outillage local (unique) | | 6 | Dépannage | 6 | Dépannage | Traduit | Traduit | Traduit | Traduit | Traduit

Chaque équipe reçoit exactement la documentation dont elle a besoin. Pas de compromis. Pas de solutions de contournement. Pas de limitations à taille unique.

Suivi de la fraîcheur dans toutes les langues

Chaque version linguistique suit sa propre fraîcheur de manière indépendante. La source anglaise peut obtenir un score de 94 (revue récente, tous les liens sont valides, le nombre de lecteurs est élevé). La version française peut obtenir un score de 71 (deux blocs périmés, un lien brisé spécifique au contenu français). La version japonaise peut obtenir un score de 88 (toutes les traductions sont à jour, mais le nombre de lecteurs est en baisse).

Ce suivi de la fraîcheur par langue signifie :

Vous savez exactement quelles sont les langues qui ont besoin d'attention
Les traductions périmées sont remontées à la surface automatiquement et ne sont pas découvertes par hasard.
Les outils d'intelligence artificielle peuvent tenir compte de la fraîcheur spécifique à la langue lorsqu'ils fournissent des réponses.
Les tableaux de bord montrent l'état du contenu par langue, et pas seulement par document.

L'analyse de rentabilité

Les entreprises qui opèrent dans plusieurs langues sont confrontées à une réalité simple : leur documentation est soit un atout, soit un handicap sur chaque marché qu'elles desservent.

Lorsque votre équipe de Berlin travaille à partir d'une traduction allemande qui a trois mois de retard sur la source anglaise, elle prend des décisions basées sur des informations obsolètes. Lorsque votre bureau de Tokyo ne peut pas ajouter de contexte local aux documents partagés parce que le système de traduction l'écraserait, il cesse d'utiliser le wiki et crée sa propre documentation parallèle. Lorsque l'équipe de São Paulo ne dispose d'aucun document en portugais, l'intégration prend deux fois plus de temps.

Le coût ne se limite pas aux frais de traduction. Il s'agit de :

une intégration plus lente sur les marchés non anglophones
La duplication des efforts** lorsque les équipes maintiennent une documentation parallèle dans les outils locaux
Les silos de connaissances** qui se forment lorsque le wiki officiel ne sert pas à tout le monde.
Risque de non-conformité** lorsque les exigences spécifiques à une région ne sont pas prises en compte
Perte de confiance** dans le système de documentation lui-même

La localisation au niveau des blocs résout tous ces problèmes, non pas en rendant la traduction moins coûteuse (bien que ce soit le cas), mais en faisant de chaque version linguistique un document vivant, tenu à jour et digne de confiance.

Pour commencer

Si vous dirigez aujourd'hui une équipe multilingue sur une plateforme de documentation quelconque, voici un rapide examen de conscience :

**Choisissez votre document le plus important et vérifiez-le dans chaque langue. Chaque version est-elle à jour ?
**Interrogez vos équipes non anglophones : **Font-elles confiance aux documents traduits ? Les utilisent-ils ?
**Les équipes maintiennent-elles des wikis locaux, des pages Notion ou des messages épinglés sur Slack parce que la documentation officielle ne les sert pas ?
Calculez vos dépenses de traduction. Combien payez-vous par mise à jour, et quelle part de ce montant est consacrée à la retraduction de contenus qui n'ont pas changé ?

Si vos réponses vous mettent mal à l'aise, vous n'êtes pas seul. La plupart des entreprises ne découvrent les lacunes que lorsqu'elles causent un véritable problème : une question de conformité, un déploiement raté, un nouvel employé qui a passé deux semaines à suivre des instructions obsolètes.

Les connaissances multilingues ne sont pas un luxe. Pour toute entreprise qui opère au-delà des frontières, c'est la base de l'alignement des équipes, de la prise de décision et de l'expédition. La question est de savoir si votre plateforme de documentation la traite de la même manière.

Chaque langue mérite d'être un citoyen de première classe dans votre base de connaissances. Pas une copie. Pas une ombre. Un document réel, entretenu et fiable.

C'est ce que propose Rasepi. Traduction au niveau du bloc, contenu unique par langue, suivi indépendant de la fraîcheur et réduction de 94 % des coûts de traduction. Tout est automatique. Et ce, dès le premier jour.

Voir la publication multilingue en action →

Fraîcheur du contenu, partie 2 : au-delà des dates d'expiration

2026-03-18T00:00:00Z

*Ceci est la deuxième partie de notre série sur la fraîcheur du contenu. La [première partie] (/en/blog/why-freshness-matters-more-than-ever/) explique pourquoi la fraîcheur est importante et ce qu'elle signifie réellement. Ce billet reprend là où elle s'est arrêtée : pourquoi les dates d'expiration ne suffisent pas et à quoi ressemble un contrôle continu.

Supposons que vous agissiez de manière responsable. Chaque document de votre wiki reçoit une date de révision. Six mois après la création, peut-être douze pour les documents de référence stables. Lorsque la date arrive, le propriétaire reçoit une notification : révisez-le ou il sera signalé.

C'est mieux que ce que font la plupart des entreprises. La plupart des entreprises ne font rien. Le document reste là, se décomposant lentement, et personne ne le remarque jusqu'à ce que quelqu'un suive les instructions et que quelque chose se brise.

Mais voici la vérité qui dérange : les dates d'expiration sont nécessaires et totalement insuffisantes : **J'ai vu des documents devenir dangereusement périmés quelques jours après leur dernière révision, et une date de révision ne suffit pas à les rattraper.

Ce que les dates d'expiration résolvent réellement

Les dates d'expiration résolvent le problème de la responsabilité. Elles répondent à la question "Qui est chargé de confirmer que cette information est toujours exacte, et quand ?".

C'est vraiment précieux. Sans cela, la documentation entre dans ce que nous appelons le vide de propriété, un état où tout le monde suppose que quelqu'un d'autre la maintient, donc personne ne le fait. La fixation d'une date de révision assigne à une seule personne une seule obligation à une date précise. C'est simple. Clair. Efficace.

Voici à quoi ressemblent les dates d'expiration dans la pratique :

Un document est créé avec une date de révision dans 90 jours
14 jours avant l'expiration, le propriétaire est notifié.
À la date d'expiration, le document est signalé comme étant "à réviser".
Le propriétaire l'examine, confirme qu'il est toujours exact et prolonge la date.
Ou bien il le met à jour, le réaffecte ou l'archive.

Il s'agit d'un système solide. Il permet de détecter les documents qui se dégradent lentement, ceux auxquels personne n'a pensé depuis un an. Il crée une cadence régulière d'examen. Il rend la propriété visible.

**Mais il a un angle mort de la taille d'un continent.

Ce que les dates d'expiration manquent

Entre les dates de révision, un document vit dans une boîte noire. Vous l'avez examiné le 15 janvier. La prochaine révision est prévue pour le 15 avril. Le 3 février, l'une ou l'autre de ces choses peut se produire :

Les liens se brisent silencieusement

Une URL externe à laquelle vous avez fait référence renvoie un message 404. Un lien interne pointe vers un document qui a été archivé. Un dépôt de code a été renommé et tous les liens GitHub de votre document sont maintenant morts. Votre document a toujours l'air en bon état. La date d'expiration n'est pas avant deux mois. Personne ne sait que les liens sont cassés.

Changements de contenu connexes

Vous avez rédigé un guide de déploiement qui fait référence à votre document d'architecture. En février, quelqu'un réécrit complètement le document d'architecture. Nouveaux modèles, nouvelle infrastructure, nouvelles conventions. Votre guide de déploiement fait toujours référence à l'ancienne architecture. Il n'est pas encore techniquement erroné, mais il dérive. Lorsque la date de révision arrive, l'écart peut être important.

Le lectorat tombe à zéro

Votre document était lu par 40 personnes par mois. Puis un processus a changé et plus personne n'en a besoin, mais personne ne l'a archivé non plus. Il reste dans les résultats de recherche, prend de la place, et peut parfois dérouter un nouvel employé qui ne sait pas qu'il n'est pas pertinent. La date d'expiration ne se soucie pas du lectorat. De toute façon, elle enverra un message au propriétaire à la date prévue.

Les traductions prennent du retard

La source anglaise a été mise à jour le 10 février. Les traductions française, allemande et japonaise sont maintenant périmées. Mais la date d'expiration de ces versions traduites n'est pas avant le mois de mai. Pendant trois mois, les équipes non anglophones lisent du contenu périmé sans le savoir.

Les lecteurs signalent les problèmes

Un lecteur laisse un commentaire : "L'étape 3 ne fonctionne plus, le drapeau CLI a été supprimé". Ce commentaire reste en suspens. La date d'expiration est encore dans plusieurs semaines. La prochaine personne qui lira la documentation ne verra peut-être pas le commentaire. La personne suivante ne le verra certainement pas.

L'expiration est un point de contrôle programmé. Il s'agit d'événements non programmés. C'est dans l'intervalle entre les deux que la documentation périmée fait le plus de dégâts.

Fraîcheur : surveillance continue

L'évaluation de la fraîcheur comble le vide laissé par les dates d'expiration. Au lieu de vérifier l'état de santé d'un document une fois tous les 90 jours, la fraîcheur le suit en permanence. Chaque jour, en arrière-plan, sans que personne n'ait besoin de faire quoi que ce soit.

Voici comment cela fonctionne dans Rasepi :

Chaque document reçoit en direct un score de fraîcheur de 0 à 100, calculé à partir de plusieurs signaux :

| Signal - Ce qu'il détecte - Pourquoi il est important - Ce qu'il détecte - Ce qu'il détecte - Ce qu'il est important |--------|----------------|----------------| | Les liens brisés érodent la confiance et font perdre du temps aux utilisateurs. Le statut de la relecture** | Si le document a été revu dans les délais prévus | Le contrôle de base de la responsabilité | Le statut de la relecture** | Le statut de la relecture** | Le statut de la relecture | Tendances du lectorat : si quelqu'un lit réellement ce document. Un faible lectorat suggère que le document n'est peut-être pas pertinent. | La date de la dernière modification du document par rapport au contenu connexe détecte les dérives par rapport à la base de connaissances environnante. | Les traductions périmées signifient que les équipes d'autres marchés travaillent à partir de vieilles informations. | Les traductions périmées signifient que les équipes d'autres marchés travaillent à partir d'informations périmées. | Les traductions périmées signifient que les équipes d'autres marchés travaillent à partir d'informations périmées.

Chaque signal contribue au score global. Un document peut perdre des points de fraîcheur à cause d'un lien brisé aujourd'hui, même si sa date de révision n'est pas avant plusieurs semaines. C'est là tout l'intérêt.

Comment les deux fonctionnent ensemble

L'expiration et la fraîcheur ne sont pas des approches concurrentes. Ce sont des couches complémentaires :

Les dates d'expiration sont la couche de gouvernance. Elles créent une cadence régulière d'examen humain. Quelqu'un doit examiner ce document selon un calendrier précis et confirmer qu'il est toujours exact. Cela permet d'attraper ce que l'automatisation ne peut pas faire : si le contenu est toujours correct, si les conseils sont toujours valables, si le processus qu'il décrit reflète toujours la réalité.

L'évaluation de la fraîcheur est la couche de surveillance. Elle capture tout ce qui se passe entre les dates de révision : les liens brisés, les dérives de traduction, les documents abandonnés, la dégradation contextuelle qui se produit lorsque le monde bouge et qu'un document ne bouge pas.

Ensemble, ils créent un système dans lequel :

Chaque document est révisé par un humain selon un calendrier régulier (expiration).
Entre les révisions, des signaux automatisés détectent les problèmes au fur et à mesure qu'ils surviennent (fraîcheur).
Les deux systèmes alimentent une note de confiance unique que tout le monde peut consulter.
Cette note influe sur le classement du document dans les moteurs de recherche et sur l'utilisation du document comme source par les outils d'intelligence artificielle.

L'impact de la notation

C'est ici que les choses deviennent pratiques. Dans Rasepi, le score de fraîcheur d'un document affecte directement sa visibilité :

Score 80-100: Visibilité totale. Apparaît normalement dans les résultats de recherche. Éligible en tant que source pour les réponses de l'IA. Pas de drapeaux.
Score 50-79:** Visibilité réduite. Apparaît dans les résultats de recherche avec un indicateur d'obsolescence. Les outils d'intelligence artificielle risquent de ne pas classer cette source par ordre de priorité. Le propriétaire est informé.
Score inférieur à 50:** Signalé. Reculé dans les résultats de recherche de manière significative. Exclu des réponses de l'IA. Le propriétaire reçoit une notification urgente.

Cela crée une boucle de rétroaction. Lorsque le score d'un document baisse, le propriétaire est poussé à le corriger, non pas parce qu'une date arbitraire est arrivée, mais parce que quelque chose a réellement changé. Le lien brisé, la traduction périmée, la baisse du nombre de lecteurs sont des signaux réels qui requièrent une attention immédiate, pas dans six semaines.

Un exemple pratique

Voyons un scénario :

1er mars Votre "Incident Response Playbook" obtient un score de 92. Il a été révisé il y a deux semaines, tous les liens sont valides, le nombre de lecteurs est élevé et les quatre versions linguistiques sont à jour.

**8 mars : quelqu'un restructure la page d'état de l'ingénierie. Trois URLs dans le cahier des charges redirigent maintenant. Le score de fraîcheur tombe à 78. Le propriétaire reçoit une notification : "3 liens brisés détectés".

Mars 10: Le propriétaire corrige les liens. Le score remonte à 89.

15 mars: La version anglaise est mise à jour avec un nouveau chemin d'escalade. Les traductions française et allemande sont désormais périmées (incompatibilité du hachage du contenu). Le score tombe à 74.

**17 mars : **Les traductions sont mises à jour. Le score revient à 91.

20 mars: Les données sur le lectorat montrent que la version japonaise n'a pas été consultée depuis 30 jours. Le score tombe à 86. Un signal subtil, mais suivi.

**1er avril : la date de révision prévue arrive. Le propriétaire examine le contenu, confirme qu'il est exact et prolonge l'expiration jusqu'au 1er juillet. Le score reste à 86 car le signal du lectorat est toujours présent.

À aucun moment l'équipe n'a attendu la date de révision pour détecter un problème. Le système de fraîcheur a signalé les problèmes en quelques jours. La date de révision a fourni le point de contrôle de la gouvernance. Les deux couches font leur travail.

Pourquoi "fixer une date de révision" n'est plus suffisant

Il y a cinq ans, les dates d'expiration auraient pu suffire. La documentation était lue par des personnes qui pouvaient exercer leur jugement. Si un document leur paraissait bizarre, ils se renseignaient.

Aujourd'hui, la documentation est une infrastructure. Elle alimente les outils d'IA, l'automatisation de l'intégration, les systèmes de conformité et les moteurs de recherche qui fournissent des résultats sans contexte. Ces systèmes n'exercent pas de jugement. Ils consomment le contenu tel quel et le redistribuent à l'échelle.

Un document avec des liens brisés et des traductions périmées qui a encore trois semaines avant sa date de révision peut faire beaucoup de dégâts au cours de ces trois semaines, surtout si un assistant d'IA sert en toute confiance des réponses basées sur ce document.

Les dates d'expiration constituent l'approche minimale viable de la gouvernance documentaire. L'évaluation de la fraîcheur est ce dont vous avez besoin lorsque la documentation est consommée par des systèmes qui ne peuvent pas penser par eux-mêmes.

Pour commencer

Si vous avez déjà des dates d'expiration sur vos documents (tant mieux pour vous, sérieusement, la plupart des équipes ne le font même pas), voici comment ajouter une couche de fraîcheur :

**Lancez une vérification des liens brisés dans vos 50 documents les plus importants. Leur nombre vous surprendra probablement.
**Si vous avez des documents multilingues, comparez les dates de dernière modification entre la source et les traductions. Combien d'entre elles ont plus d'un mois de retard ?
Examinez le lectorat. Quels sont les documents dont le trafic est nul ? Sont-ils encore nécessaires ou doivent-ils être archivés ?
**Si vous disposez d'un assistant d'IA interne, demandez-lui quels sont les documents qu'il utilise. Vérifiez ensuite la fraîcheur de ces documents.

Vous découvrirez probablement que vos documents techniquement non périmés présentent de nombreux problèmes que les dates de péremption ne pourront jamais détecter.

Les dates d'expiration vous indiquent si quelqu'un a vérifié un document récemment. La fraîcheur vous indique si le document est en bonne santé à l'heure actuelle. L'un est un événement du calendrier. L'autre est un signal vivant.

Vous avez besoin des deux. Mais si vous n'avez que des dates d'expiration, vous volez à l'aveuglette entre les points de contrôle.

Un document n'est pas périmé à sa date de révision. Il devient périmé dès que quelque chose change et que personne ne s'en aperçoit. La notation de la fraîcheur s'en aperçoit.

Rasepi associe des dates d'expiration obligatoires à une surveillance continue de la fraîcheur. Chaque document gagne ou perd sa cote de confiance en temps réel. Pas d'attente, pas d'angle mort, pas de surprise au moment de l'examen.

Voir comment fonctionne la notation de la fraîcheur →

*Ceci est la deuxième partie d'une série en deux parties. Si vous ne l'avez pas encore lue, commencez par Partie 1 : La mesure que votre équipe ne suit pas.

Fraîcheur du contenu, partie 1 : La mesure que votre équipe ne suit pas

2026-03-16T00:00:00Z

Toutes les équipes d'ingénieurs ont connu ce moment. Quelqu'un trouve un document sur le wiki interne, suit les instructions et quelque chose se casse. Elle envoie un message au canal : Personne ne le sait. La personne qui a rédigé le document est partie il y a huit mois. Le document indique qu'il a été édité pour la dernière fois en 2024.

C'est le problème de la fraîcheur. Et il s'aggrave.

L'ancien contrat est en train de s'effondrer

Pendant longtemps, la documentation a fait l'objet d'un contrat implicite : quelqu'un l'écrit, tout le monde lui fait confiance et, de temps en temps, quelqu'un la met à jour. Peut-être. Ce contrat fonctionnait, à peine, lorsque les documents n'étaient consultés que par des personnes capables de faire preuve de discernement. Si un guide d'installation paraissait un peu faux, un ingénieur chevronné l'adaptait à la volée.

Mais ce monde est révolu. Aujourd'hui, votre documentation n'est pas seulement lue par des humains. Elle est consommée par des outils d'IA, des chatbots internes, des systèmes d'automatisation de l'intégration et des systèmes de recherche qui traitent chaque mot comme une vérité équivalente. Un assistant d'IA ne regarde pas un document en se disant "hmm, ça a l'air un peu vieux" Il lit le texte, le traite comme un fait et le sert en toute confiance.

**Une documentation périmée associée à l'IA équivaut à des réponses erronées en toute confiance à grande échelle.

Ce que la fraîcheur signifie réellement

La fraîcheur ne se résume pas à la question de savoir "quand cette documentation a été éditée pour la dernière fois". Une documentation peut avoir été éditée hier et faire référence à une API obsolète. La véritable fraîcheur est un signal composite :

Statut de révision Quelqu'un a-t-il explicitement confirmé que ce document est toujours exact ?
Santé des liens. Les URLs contenues dans le document sont-elles toujours en cours de résolution ?
Readership. Est-ce que quelqu'un utilise réellement ce document ou a-t-il été abandonné ?
Dérive contextuelle : les documents connexes ont-ils changé alors que celui-ci est resté inchangé ?
Alignement des traductions : si ce document existe en cinq langues, sont-elles toutes à jour ?
Signaux de la communauté : des lecteurs ont-ils signalé que ce document était obsolète ?

Chacun de ces éléments vous indique quelque chose de différent. Ensemble, ils vous donnent une note de confiance : un chiffre unique qui représente le degré de confiance que vous devez accorder à un élément de contenu à l'heure actuelle.

Pourquoi c'est important maintenant, en particulier

Trois éléments ont convergé pour rendre la fraîcheur urgente :

1. L'IA consomme votre base de connaissances

Que vous ayez déployé un système RAG interne, que vous utilisiez Copilot dans votre IDE ou qu'un assistant IA réponde aux questions de votre documentation, la qualité du matériel source détermine directement la qualité du résultat. La notion d'entrée et de sortie d'ordures n'a jamais été aussi littérale.

Lorsqu'un développeur demande à votre assistant d'intelligence artificielle "comment déployer vers staging" et qu'il répond en utilisant un runbook vieux de deux ans qui fait référence à une infrastructure que vous avez migrée depuis, le coût n'est pas seulement une mauvaise réponse. Il s'agit d'une perte de confiance dans l'ensemble du système.

2. Les équipes sont plus distribuées que jamais

Une équipe à Berlin, une autre à São Paulo, une troisième à Tokyo. Tous lisent la même documentation, souvent dans des langues différentes. Lorsque la source anglaise est périmée, toutes les traductions qui en découlent le sont également, mais personne ne s'en aperçoit car les traductions sont maintenues séparément, voire pas du tout.

3. La pression de la conformité et de l'audit augmente

Les secteurs réglementés commencent à demander : "Pouvez-vous prouver que cette documentation était à jour au moment où elle a été référencée ?" Si votre réponse est "eh bien, quelqu'un l'a probablement vérifiée", elle ne tiendra pas la route.

Ce à quoi ressemble une approche axée sur la fraîcheur

L'idée de base est simple : chaque document doit continuellement gagner le droit d'être digne de confiance.

Cela signifie que :

**Chaque document a une date d'expiration lorsqu'il est créé. Il n'y a pas d'exception. Lorsque cette date arrive, le propriétaire en est informé et le document est marqué jusqu'à ce que quelqu'un le réapprouve explicitement.
**En arrière-plan, le système vérifie en permanence les liens brisés, les tendances du lectorat et les changements contextuels. Ces signaux alimentent un score en direct qui est mis à jour sans que personne n'ait à faire quoi que ce soit.
La fraîcheur influe sur la visibilité C'est le mécanisme clé. Un document ayant obtenu un score élevé apparaît en tête des résultats de recherche et peut être utilisé comme source pour les réponses de l'IA. Un document à faible score perd en revanche de l'importance dans le classement. S'il tombe en dessous d'un certain seuil, il est totalement exclu des réponses de l'IA.
**Transparence : tout le monde peut savoir pourquoi un document a obtenu un tel score. Liens brisés, révision en retard, faible nombre de lecteurs, les signaux sont visibles, et non cachés dans un rapport de backend que personne ne lit.

Le coût de l'inaction

Voici ce qui se passe lorsque vous ne suivez pas l'évolution de la fraîcheur :

Les nouveaux embauchés suivent des documents d'intégration obsolètes et passent leur première semaine dans la confusion.
Les outils d'IA fournissent de mauvaises réponses et personne ne comprend pourquoi.
Les documents de conformité deviennent silencieusement périmés et créent un risque d'audit.
Les traductions se désynchronisent et les équipes de différentes régions travaillent à partir de versions différentes de la réalité.
Les ingénieurs cessent de faire entièrement confiance au wiki et se rabattent sur les messages Slack, ce qui crée son propre silo de connaissances.

Le coût composé de la documentation périmée est énorme, mais il est invisible jusqu'à ce que quelque chose se brise.

Un point de départ pratique

Il n'est pas nécessaire de tout revoir d'un coup. Commencez par les éléments suivants :

Auditez vos 20 documents les plus lus. Quand ont-ils été révisés pour la dernière fois ? Les liens sont-ils toujours valables ? Le contenu est-il toujours exact ?
Fixez des dates de révision. Même si vous ne faites rien d'autre, le fait d'inscrire une date de révision sur chaque document crée une obligation de rendre compte.
**Si vous disposez d'un assistant d'intelligence artificielle interne, examinez les documents qu'il consulte. Ces documents sont-ils à jour ?
Faites en sorte que la fraîcheur soit visible. Placez le score à un endroit où les gens peuvent le voir, à côté du titre du document, dans les résultats de recherche, dans la barre latérale. La visibilité crée une pression en faveur du maintien.

La fraîcheur de la documentation n'est pas une fonctionnalité. Il s'agit d'un changement fondamental dans la façon dont nous pensons à la connaissance organisationnelle. Dans un monde où les outils d'IA consomment et redistribuent vos documents à grande échelle, la question n'est pas de savoir si vous pouvez vous permettre de vous soucier de la fraîcheur. Il s'agit de savoir si vous pouvez vous permettre de ne pas le faire.

Chaque document devrait avoir à prouver qu'il est toujours digne de confiance. Pas une seule fois. En permanence.**

C'est ce que nous construisons à Rasepi. Une plateforme où la fraîcheur n'est pas une réflexion après coup. C'est la base sur laquelle tout le reste est construit. L'application des révisions, l'évaluation en direct de la santé, la recherche pondérée par la fraîcheur et les réponses de l'IA qui n'utilisent que des sources dignes de confiance.

Voir comment ça marche →

Ceci est la première partie d'une série en deux parties. Dans Partie 2 : Au-delà des dates de péremption, nous verrons comment la surveillance continue de la fraîcheur comble les lacunes laissées par les dates d'examen.

Apprenez à votre IA à ignorer la documentation périmée

2026-03-12T00:00:00Z

Voici ce qui se passe lorsque vous déployez un assistant d'IA au-dessus de votre base de connaissances interne :

Un nouvel ingénieur demande : "Comment configurer l'environnement de test ?"

L'IA recherche votre documentation, trouve trois documents pertinents, synthétise une réponse et la présente avec confiance. L'ingénieur suit les instructions. Les deux premières étapes fonctionnent. La troisième étape fait référence à un outil CLI qui a été supprimé il y a six mois. L'étape quatre décrit une configuration d'infrastructure qui a été remplacée au cours d'une migration que personne n'a documentée.

L'ingénieur est bloqué. Il envoie un message au canal de l'équipe. Quelqu'un dit : "Oh, ce document est vraiment vieux". L'IA ne le savait pas. Elle ne peut pas le savoir. Elle a simplement récupéré tout ce qu'elle a trouvé et l'a présenté comme une vérité.

C'est le comportement par défaut de tous les systèmes RAG, de tous les outils de recherche IA et de tous les assistants dotés de LLM que vous avez déjà utilisés pour des documents internes. Ils récupèrent tout. Ils ne font pas de distinction. Ils ne peuvent pas faire la différence entre ce qui est frais et ce qui est périmé.

Et cela détruit la confiance dans les outils d'IA plus rapidement que ces outils ne peuvent la construire.

Pourquoi les assistants d'IA sont aveugles à la qualité

Les grands modèles de langage et les systèmes de génération augmentée de recherche (RAG) fonctionnent en trouvant du texte sémantiquement pertinent pour une requête, puis en utilisant ce texte pour générer une réponse. La correspondance de la pertinence est généralement excellente. La recherche vectorielle et l'intégration sont réellement efficaces pour trouver du contenu en rapport avec une question.

Mais la pertinence n'est pas synonyme de fiabilité.

Un document écrit en 2023 sur votre processus de déploiement Kubernetes est très pertinent pour la question "comment puis-je déployer en production ?" Il est aussi complètement erroné si vous avez migré vers une plateforme différente en 2024. L'IA voit un texte pertinent. Elle ne voit pas un document périmé depuis 18 mois, avec des liens cassés et un lectorat nul.

La plupart des systèmes d'IA n'ont qu'un seul signal de classement : la similarité sémantique avec la requête. Ils ne vérifient pas :

Quand ce document a-t-il été révisé pour la dernière fois ?
Les liens qu'il contient sont-ils toujours valables ?
Quelqu'un lit-il réellement ce document ?
Le contenu a-t-il été signalé par les lecteurs comme étant obsolète ?
S'agit-il d'un projet, d'une page archivée ou d'un document actuel ?
Si le document existe en plusieurs langues, les traductions sont-elles à jour ?

En l'absence de ces signaux, l'IA effectue une recherche par mots clés avec des étapes supplémentaires. Une correspondance de mots clés impressionnante, certes, mais fondamentalement incapable de vous dire si la réponse qu'elle vous donne est basée sur un contenu digne de confiance.

Le problème de la confiance

Cette situation ne serait pas aussi dangereuse si les outils d'IA présentaient des réponses incertaines accompagnées de mises en garde appropriées. Mais ce n'est pas le cas. Ce n'est pas ainsi que fonctionnent les LLM. Ils génèrent des textes fluides et sûrs, que la source soit actuelle ou ancienne.

Un humain lisant un article de wiki pourrait remarquer qu'il semble daté. La mise en page est ancienne. Les captures d'écran montrent une interface utilisateur qui n'existe plus. Il y a un commentaire au bas de l'article qui dit "c'est dépassé". Un être humain peut faire preuve de discernement.

Une IA ne le peut pas. Elle lit le texte, le traite comme s'il était équivalent à n'importe quel autre texte et génère une réponse qui semble faire autorité. L'utilisateur, en particulier un nouvel employé qui ne sait pas à quoi ressemble le processus actuel, n'a aucune raison d'en douter.

**Plus l'IA a l'air sûre d'elle, plus le matériel source périmé est endommagé.

Ce dont l'IA a réellement besoin

Pour qu'un assistant d'IA puisse donner des réponses fiables à partir de votre base de connaissances, il a besoin de plus que de texte et d'enchâssements. Il a besoin de métadonnées qui lui indiquent quels documents méritent d'être utilisés comme sources. Plus précisément :

1. Score de fraîcheur

Un signal numérique qui représente l'état de santé actuel d'un document. Il ne s'agit pas de savoir quand il a été édité pour la dernière fois, ce n'est qu'une donnée. Un véritable score de fraîcheur combine l'état des révisions, la santé des liens, le lectorat, l'alignement de la traduction et la dérive contextuelle en un seul chiffre.

Lorsqu'un document obtient un score supérieur à un seuil (par exemple, 70 sur 100), il peut être utilisé comme source pour les réponses de l'IA. En dessous de ce seuil, il est exclu. Il n'y a pas d'exception.

Ce mécanisme unique élimine la catégorie d'erreurs d'IA la plus dangereuse : les réponses erronées basées sur des sources périmées.

2. Statut d'expiration

Ce document est-il en cours d'examen ou a-t-il expiré sans avoir été réapprouvé ? Un document expiré doit être fortement dépriorisé ou exclu, quelle que soit la pertinence de son contenu par rapport à la requête.

Dans Rasepi, les documents périmés sont signalés et leur score de fraîcheur diminue automatiquement. Un système d'intelligence artificielle interrogeant la base de connaissances peut voir ce statut et agir en conséquence.

3. Étiquettes de classification

Tous les documents n'ont pas la même utilité. Un brouillon ne doit pas être utilisé comme source. Un document archivé ne doit pas apparaître dans les réponses de l'IA. Un document interne ne doit pas apparaître dans les requêtes d'outils externes.

Les étiquettes de classification donnent à l'IA le contexte du type de document qu'elle examine :

Publié. Actuel, approuvé, utilisable en toute sécurité
Projet** Travail en cours, ne doit pas être cité
En cours de révision** Expiration déclenchée, en attente de réapprobation
Archivé. N'est plus actif, conservé pour référence uniquement
Interne / Externe. Contrôle la portée de la visibilité

Lorsqu'un assistant IA traite une requête, il peut filtrer par classification avant même d'examiner la pertinence du contenu. Un projet de document qui correspond parfaitement à la requête ne devrait jamais être présenté comme une réponse.

4. Signaux au niveau de la langue

Si votre base de connaissances est multilingue, l'IA doit savoir si la version dont elle s'inspire est à jour. Une traduction française qui a trois mois de retard sur la source anglaise est techniquement pertinente en français, mais les informations peuvent être obsolètes.

Rasepi suit l'actualité au niveau de la langue. Chaque traduction a son propre score, basé sur le fait que les blocs sources ont changé depuis la dernière mise à jour de la traduction. Une IA interrogeant la base de connaissances française peut constater que la version française d'un document est périmée et qu'elle n'est pas non plus à jour :

revenir à la source anglaise (qui est à jour)
inclure un avertissement indiquant que la version française peut être périmée
Exclure complètement le document

5. Signaux du lecteur

Si plusieurs lecteurs ont signalé qu'un document était périmé, ce signal devrait réduire le poids du document dans les réponses de l'IA. Les signaux de qualité provenant de la foule sont bruyants, mais ils sont précieux, en particulier lorsqu'ils sont combinés à d'autres mesures de fraîcheur.

Comment cela fonctionne-t-il en pratique ?

Voyons ce qui se passe lorsqu'un assistant d'IA interroge une base de connaissances Rasepi :

Query: "Quelle est notre procédure pour gérer un incident P1 à 2 heures du matin ?"

Étape 1 : Récupération avec filtrage Le système recherche des documents sémantiquement pertinents. Avant de classer les documents, il les filtre :

les documents dont le score de fraîcheur est inférieur au seuil fixé
les documents expirés qui n'ont pas été réapprouvés
les brouillons et le contenu archivé
les documents dont la version linguistique est périmée (si la requête est dans une langue non primaire).

Étape 2 : Classement pondéré en fonction de la fraîcheur Parmi les documents restants, ceux dont le score de fraîcheur est le plus élevé sont mieux classés. Un document ayant un score de 94 est plus important qu'un document ayant un score de 72, même si le document ayant un score de 72 a une similarité sémantique légèrement plus élevée.

Étape 3 : Génération de réponses. L'IA génère une réponse à partir des sources filtrées et classées par ordre de fraîcheur. Chaque source est citée avec son score de fraîcheur visible.

Étape 4 : Avertissements d'obsolescence. Si la meilleure source disponible a un score de fraîcheur limite, l'IA inclut un avertissement : _"Note : La source principale de cette réponse a été examinée pour la dernière fois il y a 60 jours. Vous voudrez peut-être vérifier auprès de l'équipe".

Comparez cela au comportement par défaut : trouver un texte pertinent, générer une réponse fiable et espérer que tout se passe bien.

Ce qui se passe lorsque vous ne faites pas cela

Les conséquences des systèmes d'IA fonctionnant sur des bases de connaissances non filtrées sont prévisibles et coûteuses :

**Le cas d'utilisation le plus courant de l'IA pour les documents internes est l'intégration. Les nouveaux employés, par définition, ne savent pas ce qui est à jour et ce qui est périmé. Ils font confiance à l'IA. L'IA fait confiance à tout. Les documents périmés sont servis en toute confiance.

**Si votre assistant IA fournit des conseils sur les processus réglementaires en utilisant des documents périmés, le conseil pourrait non seulement être erroné, mais aussi non conforme. Le fait de dire "l'IA m'a dit de le faire" ne tient pas la route en cas d'audit.

**Chaque fois que l'IA donne une mauvaise réponse, les utilisateurs lui font de moins en moins confiance. Après trois ou quatre mauvaises expériences, ils cessent de l'utiliser. L'investissement dans l'outil d'IA n'apporte aucune valeur parce que le contenu sous-jacent n'était pas digne de confiance.

**Lorsque les utilisateurs ne font plus confiance à la base de connaissances officielle (et à l'IA qui la complète), ils créent leur propre base de connaissances : messages Slack, notes personnelles, connaissances tribales partagées lors de réunions. La fragmentation que le wiki était censé prévenir se produit de toute façon, mais différemment.

La solution se trouve à la source, pas au niveau du modèle

Il est tentant de résoudre ce problème au niveau de l'intelligence artificielle : de meilleures invites, des pipelines RAG plus sophistiqués, des modèles affinés qui peuvent en quelque sorte détecter l'obsolescence à partir du texte seul. Ce n'est pas la bonne approche.

La solution se trouve à la source. Si vos documents contiennent des métadonnées riches et précises sur leur état actuel (score de fraîcheur, statut d'expiration, classification, alignement linguistique, signaux de lecture), alors tout système d'intelligence artificielle peut utiliser ces métadonnées pour prendre de meilleures décisions. Vous n'avez pas besoin d'un modèle plus intelligent. Vous avez besoin de documents plus intelligents.

C'est ce que propose Rasepi :

Chaque document dispose d'un score de fraîcheur en direct** qui est mis à jour en permanence en fonction de la santé des liens, du lectorat, de l'état des évaluations, etc.
Chaque document a une date d'expiration** qui déclenche une révision lorsqu'il arrive.
Chaque document a une classification** (publié, brouillon, en cours de révision, archivé).
Chaque version linguistique a son propre signal de fraîcheur**, de sorte que les traductions périmées sont détectées indépendamment.
Les indicateurs de lecture et le suivi des références croisées** ajoutent des signaux de qualité supplémentaires.

Lorsqu'un système d'intelligence artificielle interroge la base de connaissances de Rasepi, toutes ces métadonnées sont disponibles. L'IA n'a pas besoin de deviner si un document est digne de confiance. Le document le lui dit.

Un point de départ pratique

Si vous disposez aujourd'hui d'un assistant d'IA fonctionnant sur votre base de connaissances, vous pouvez commencer à évaluer le problème en 30 minutes :

Posez à votre assistant d'IA 10 questions dont vous connaissez les réponses. Notez quelles réponses utilisent des sources périmées. Vous constaterez probablement qu'au moins 2 à 3 réponses sur 10 sont basées sur un contenu obsolète.
Vérifiez les documents sources. Pour chaque réponse donnée par l'IA, examinez le document source. Quand a-t-il été révisé pour la dernière fois ? Les liens sont-ils valables ? Feriez-vous confiance à ce document si vous le lisiez vous-même ?
**Trouvez votre document le plus ancien et le plus négligé qui apparaît encore dans les résultats de recherche. Posez à l'IA une question qui le ferait apparaître. L'IA l'utilise-t-elle ? Il est presque certain que oui.
**Estimez l'impact **Combien de requêtes votre assistant IA traite-t-il par jour ? Si 20 à 30 % des réponses sont basées sur du contenu périmé, quel est le coût en termes de perte de temps, de mauvaises décisions et de perte de confiance ?

La qualité des assistants d'IA dépend du contenu sur lequel ils s'appuient. À l'heure actuelle, la plupart d'entre eux traitent tous les documents de votre base de connaissances comme étant également valables. Ils récupèrent tout, le document qui a été revu hier et celui que personne n'a touché depuis deux ans, et les présentent tous avec la même confiance.

Ce n'est pas un problème de modèle. C'est un problème de qualité des données. Et la solution est simple : donnez à vos documents des métadonnées qui indiquent aux outils d'intelligence artificielle à quoi se fier.

Votre assistant d'intelligence artificielle ne devrait pas se fier à une réponse provenant d'un document que personne n'a revu depuis 18 mois. Avec les bons signaux, il ne le fera pas.**

Rasepi attribue à chaque document son propre score de confiance : fraîcheur, statut d'expiration, classification, alignement linguistique. Les outils d'IA interrogent la base de connaissances et obtiennent non seulement le contenu, mais aussi le contexte. Les sources fiables font surface. Les sources périmées ne le sont pas. C'est ainsi que devrait fonctionner la documentation alimentée par l'IA.

Voir comment Rasepi fonctionne avec les outils d'IA →

Il est plus agréable de parler aux documents que de les lire

2026-03-10T00:00:00Z

Ce n'est pas pour rien que l'on dit "parlons-en" lorsque quelque chose est complexe.

Lorsque nous essayons de comprendre une nouvelle idée, de résoudre un problème ou de rappeler un processus sous pression, la conversation semble souvent plus facile que la lecture. Ce n'est pas parce que la lecture est mauvaise. La lecture est l'un des outils les plus puissants que l'homme ait jamais développés. Mais la lecture est une compétence acquise qui se superpose à quelque chose de beaucoup plus ancien : la parole.

Nous parlons bien avant de lire.

Cela a plus d'importance qu'on ne le pense, surtout maintenant qu'une grande partie du savoir mondial se trouve dans des documents, des wikis, des PDF et de longues pages internes que personne ne veut ouvrir à moins d'y être absolument obligé.

La lecture s'apprend. La conversation est native.

Les êtres humains ont parlé pendant très longtemps avant d'écrire quoi que ce soit. Les enfants apprennent naturellement à comprendre la langue parlée. La lecture nécessite un enseignement explicite, des répétitions et des années de pratique.

Même pour les adultes très alphabétisés, la lecture reste un acte plus délibéré que l'écoute ou l'expression orale. Elle exige une concentration visuelle, une attention continue, une mémoire de travail et une interprétation de la structure de la page. Il s'agit de décoder des symboles, d'analyser des phrases, d'établir un contexte et de décider de ce qui est important.

La conversation fonctionne différemment. Lorsque l'information est transmise sous forme orale et interactive, le cerveau vit une expérience différente :

L'information semble séquentielle plutôt que visuellement envahissante
Elle fournit un retour d'information et des éclaircissements immédiats.
Il n'est pas nécessaire de parcourir et de filtrer de gros blocs de texte.
Elle reflète la façon dont les gens demandent de l'aide dans la vie réelle.

Ce dernier point est très important. Dans l'incertitude, la plupart des gens n'ont pas instinctivement envie de lire 1 500 mots. Ils veulent se demander : "Que dois-je faire ensuite ?".

Parler réduit la friction cognitive

Un document est statique. Il contient tout en même temps.

Cela semble utile, et c'est souvent le cas. Mais cela crée aussi des frictions. Une page remplie de titres, de rappels, de liens, de notes, d'exemples et de cas particuliers oblige le lecteur à décider ce qu'il doit ignorer. C'est coûteux sur le plan cognitif.

Lorsque vous vous adressez à un système d'information, vous obtenez généralement l'expérience inverse : la pertinence d'abord, le détail ensuite.

Vous posez une question. Vous obtenez une réponse. Vous posez ensuite une autre question.

Ce modèle d'interaction réduit la charge mentale de plusieurs façons importantes :

1. Il réduit l'espace du problème

Un document complet présente l'ensemble du paysage. Une conversation présente la prochaine étape utile.

Lorsque quelqu'un demande : "Comment intégrer un nouvel ingénieur ?", il ne veut généralement pas tout le manuel immédiatement. Elle veut une orientation. La conversation leur permet de commencer modestement et de ne s'étendre qu'en cas de besoin.

2. Elle préserve la mémoire de travail

La lecture exige que vous reteniez plusieurs choses dans votre tête tout en cherchant la partie pertinente. L'interaction orale ou conversationnelle externalise cet effort. Le système effectue une plus grande partie du filtrage à votre place.

3. Le système est socialement familier

Les êtres humains sont profondément adaptés à l'échange en va-et-vient. Nous posons une question. Quelqu'un répond. Nous affinons. Il clarifie. Cette boucle est l'une des plus anciennes formes d'apprentissage que nous ayons.

Même lorsque le "quelqu'un" est un système, la structure semble toujours naturelle.

La lecture n'est pas passive. C'est exactement ce qu'il faut faire.

L'une des raisons pour lesquelles il peut sembler plus facile de parler est que la lecture n'est pas aussi facile qu'on le pense. Les lecteurs habiles donnent l'impression de lire sans effort, mais le processus est très actif.

Pour bien lire, il faut

identifier la structure
déduire l'importance
résoudre les ambiguïtés
garder le contexte en mémoire
relier une section à une autre
décider quand survoler et quand ralentir

Il s'agit là d'un véritable travail cognitif.

Dans de nombreuses situations, ce travail en vaut la peine. La lecture approfondie permet d'apporter des nuances, de la précision et une compréhension à long terme. Mais dans d'autres situations, en particulier lorsqu'une personne est fatiguée, stressée, surchargée ou qu'elle essaie simplement de se débloquer, parler est souvent l'option mentalement la plus légère.

C'est particulièrement vrai sur le lieu de travail, où les gens n'abordent généralement pas la documentation dans des conditions idéales. C'est le cas :

à mi-tâche
interrompu
en train de changer de contexte
essayant de résoudre quelque chose rapidement
souvent déjà légèrement frustré

Dans cet état, l'accès à l'information par la conversation peut s'avérer bien meilleur que l'accès par la page.

Parler change la relation avec l'information

Il existe également une dimension émotionnelle.

Les documents peuvent sembler formels et distants. Ils impliquent de lire tout cela, de le comprendre correctement et de ne rien manquer d'important : Cela peut être utile en tant que matériel de référence, mais cela peut aussi créer des hésitations.

La conversation semble permissive. Vous pouvez être vague. On peut mal demander. Vous pouvez admettre votre confusion. Vous pouvez dire : "Je ne sais pas vraiment ce que je cherche, mais j'ai besoin de savoir ce qu'il en est des demandes d'accès".

C'est important parce que les gens évitent souvent la documentation, non pas parce qu'ils n'aiment pas l'information, mais parce qu'ils n'aiment pas l'effort et l'incertitude qu'implique le fait de trouver la bonne partie de l'information.

Parler réduit cette barrière.

Pourquoi c'est important maintenant

Pendant longtemps, les documents devaient être lus parce qu'il n'y avait pas d'alternative pratique. La recherche a aidé les gens à trouver des pages, mais elle n'a pas changé le modèle d'interaction. Il fallait toujours ouvrir la page, la scanner et en extraire ce dont on avait besoin.

Cette situation est en train de changer.

À mesure que les interfaces deviennent plus conversationnelles, les gens s'attendent de plus en plus à ce que l'information réponde plutôt qu'à ce qu'elle existe simplement. Ils veulent demander ce dont ils ont besoin en langage clair et recevoir une réponse adaptée à l'instant présent.

Cela ne rend pas la lecture obsolète. Elle en modifie le rôle.

La lecture devient la couche profonde. La conversation devient la couche d'accès.

Les meilleurs systèmes prendront en charge les deux :

parler lorsque vous avez besoin d'orientation ou de rapidité
lire lorsque vous avez besoin de profondeur, de vérification ou d'un contexte complet

Le risque d'une simplification excessive

Il y a une mise en garde importante : parler à l'information n'est bénéfique que si les réponses sont fiables.

Si une interface conversationnelle donne des réponses partielles, trompeuses ou trop sûres d'elles, l'expérience devient pire que la lecture parce qu'elle enlève à l'utilisateur la possibilité d'inspecter directement le matériel source.

L'avenir n'est donc pas de "remplacer tous les documents par la voix". L'avenir consiste à donner aux gens un moyen plus humain d'accéder aux documents sans perdre la profondeur et la précision qu'apporte la connaissance écrite.

Cet équilibre est important. La conversation est plus facile, mais les documents conservent la structure durable, les détails et la responsabilité dont les organisations ont besoin.

Une interface plus humaine avec la connaissance

Le point le plus profond est simple : les gens ne pensent pas naturellement en pages. Ils pensent en termes de questions, d'histoires, de fragments et de dialogues.

Nous posons des questions :

Qu'est-ce que cela signifie ?
Que dois-je faire en premier ?
Quelle est la partie importante ?
Pouvez-vous l'expliquer différemment ?
Qu'est-ce qui a changé ?

Il s'agit là de techniques de conversation, et non de techniques de lecture.

Ainsi, lorsqu'il est mentalement plus facile de parler d'une information que de la lire, ce n'est pas un signe de paresse intellectuelle. C'est généralement le signe que l'interface correspond à la manière dont le cerveau préfère aborder l'incertitude.

La lecture reste essentielle. Mais en tant que point d'entrée dans la connaissance, la conversation est souvent plus agréable parce qu'elle est plus proche de ce que nous sommes par nature.

Nous ne sommes pas d'abord des lecteurs. Nous sommes d'abord des bavards. Les systèmes de connaissance les plus intuitifs s'en souviendront.

Des plateformes de documentation conçues pour une autre époque

2026-03-08T00:00:00Z

Confluence et Notion ne sont pas de mauvais produits. Il faut le dire clairement dès le départ.

Ils ont réussi pour de bonnes raisons. Confluence est devenu la maison par défaut pour la documentation interne dans de nombreuses entreprises parce qu'il a donné aux équipes un endroit central pour écrire, organiser et partager les connaissances. Notion a conquis les gens grâce à sa flexibilité, ses expériences d'écriture plus propres et sa surface de produit plus moderne.

Les deux plateformes ont résolu des problèmes réels à l'époque pour laquelle elles ont été conçues.

Aujourd'hui, le problème est que le monde qui les entoure a changé plus rapidement que leurs fondations.

Nous ne sommes plus dans un monde où la documentation doit simplement être écrite, stockée et recherchée. Nous sommes dans un monde où l'on attend de plus en plus de la documentation qu'elle le soit :

lisible par une machine
tenir compte de l'état de fraîcheur
sûre pour l'extraction par l'IA
suffisamment structurée pour être automatisée
dynamiques dans toutes les langues et pour tous les publics
dignes de confiance en permanence, et pas seulement disponibles

C'est une autre paire de manches.

Ils ont été conçus pour un modèle de connaissance antérieur à l'IA.

Les plateformes de documentation traditionnelles ont été conçues sur la base d'une hypothèse simple : si la page existe et est consultable, le problème est en grande partie résolu.

C'était suffisant lorsque l'utilisateur principal était un humain qui ouvrait un wiki, parcourait la page et exerçait son jugement. Dans ce modèle, le rôle de la plateforme était de faciliter la rédaction et la navigation.

L'IA modifie la description du travail.

Désormais, la plateforme ne se contente plus de stocker des connaissances pour les gens. Elle produit du matériel source pour les systèmes qui récupèrent, classent, résument et répondent aux questions automatiquement.

Cela introduit de nouvelles exigences auxquelles les anciennes architectures ne donnaient pas la priorité :

Quel contenu est digne de confiance à l'heure actuelle ?
Quelles sont les pages périmées mais encore consultables ?
Quelles sections ont été modifiées récemment ?
Quelle est la version linguistique actuelle ?
Quel contenu est provisoire, archivé, spécifique à une région ou peu fiable ?
Quels sont les documents à exclure totalement des réponses de l'IA ?

Une plateforme qui n'a pas été conçue en fonction de ces questions doit les adapter. C'est toujours plus difficile que de les concevoir dès le départ.

La force de l'héritage devient un fardeau pour l'héritage

Les produits établis ont des avantages : distribution, écosystème, marque, familiarité avec les clients, intégrations et équipes qui savent comment livrer. Mais ces mêmes atouts peuvent ralentir les changements structurels.

Pourquoi ? Parce que les plateformes matures comportent des engagements.

Elles ont :

des années de décisions accumulées en matière de produits
d'énormes bases installées avec des flux de travail existants
des attentes en matière de compatibilité ascendante
des plugins et des extensions qui dépendent d'un ancien comportement
des modèles de données optimisés pour les cas d'utilisation d'hier

Lorsqu'une plateforme comme Confluence ou Notion souhaite ajouter une capacité réellement nouvelle, elle doit souvent l'adapter au système existant plutôt que de l'utiliser.

C'est là le défi de l'ancienneté : vous ne construisez pas seulement l'avenir, vous traînez le passé avec vous.

Ajouter des fonctionnalités d'IA n'est pas la même chose que devenir natif de l'IA

Un grand nombre de plateformes établies superposent désormais l'IA. Résumés. Aide à la rédaction. Amélioration de la recherche. Interfaces de questions-réponses. Confluence dispose de [Atlassian Intelligence] (https://www.atlassian.com/platform/intelligence), Notion a livré [Notion AI] (https://www.notion.com/product/ai) et GitBook a ajouté [AI-powered search] (https://docs.gitbook.com/product-tour/searching-your-content/gitbook-ai). Ces fonctionnalités sont utiles. Certaines d'entre elles sont bonnes.

Mais il y a une différence significative entre :

l'ajout de fonctions d'IA à un produit de documentation
la construction d'un produit de documentation dont l'architecture de base suppose une utilisation de l'IA dès le premier jour.

La première approche débouche souvent sur des fonctions d'assistance marginales. La deuxième approche modifie les fondations.

Une plateforme de connaissance native de l'IA pose des questions de conception différentes dès le départ :

comment les documents doivent-ils être structurés pour que les systèmes puissent raisonner sur eux en toute sécurité ?
Comment la confiance doit-elle être représentée ?
Quelles métadonnées doivent être de première classe et non optionnelles ?
Comment la visibilité des contenus périmés doit-elle se dégrader ?
comment limiter les réponses lorsque les sources sous-jacentes sont faibles ?

Il s'agit là de questions architecturales, et non de questions de fonctionnalités.

Les nouvelles plateformes ont un avantage temporaire

C'est ici que les nouvelles plateformes peuvent gagner, au moins pour un temps.

Une nouvelle plateforme a la liberté de concevoir autour des contraintes d'aujourd'hui et non des habitudes d'hier. Elle n'a pas à préserver une décennie d'hypothèses sur ce qu'est un document ou sur la manière dont un wiki devrait se comporter. Elle peut faire des choix différents dès le départ :

traiter la fraîcheur comme un concept de première classe
rendre la confiance dans les sources visible à la fois pour les humains et les machines
stocker des métadonnées plus riches sur l'état du contenu
intégrer les flux de travail multilingues dans le modèle de base au lieu de les ajouter par surcroît
décider que la recherche et l'extraction par l'IA doivent être classées en fonction de la confiance, et pas seulement de la pertinence.

Cette liberté est importante.

Dans le domaine de la technologie, les opérateurs historiques sont souvent les plus forts pendant les périodes de stabilité. Les nouveaux entrants sont souvent plus forts lorsque le modèle lui-même est en train de changer.

L'ère de l'IA est l'un de ces changements.

Pourquoi c'est particulièrement difficile pour Confluence

Confluence est puissant, mais il vient d'une vision du monde plus ancienne. Il a été construit autour de espaces d'équipe, pages, navigation hiérarchique, et d'un modèle d'entreprise riche en plugins. Ces choix étaient judicieux. Ils le sont toujours pour de nombreuses organisations.

Mais ils signifient aussi que le produit est très complexe. Les plateformes d'entreprise ont rarement la possibilité de se réinventer proprement. Elles doivent négocier avec leur propre histoire.

Cela rend la modernisation plus lente. Pas impossible. Juste plus lente.

Lorsque les exigences de l'ère de l'IA requièrent des métadonnées plus propres, une modélisation plus explicite de la confiance ou une gouvernance du contenu davantage axée sur l'opinion, un système conçu pour une flexibilité maximale grâce à des années d'extensions peut avoir du mal à évoluer de manière cohérente.

Pourquoi cela est particulièrement délicat pour Notion

Notion a un problème différent. Il semble plus récent, plus léger et plus flexible. Mais la flexibilité peut aussi jouer en sa défaveur.

La force de Notion réside dans le fait que [presque tout peut devenir une page, une base de données, une note, un document léger ou un espace de collaboration] (https://www.notion.com/product). Cette flexibilité est excellente pour les équipes. Elle l'est moins lorsque vous avez besoin de garanties solides sur la signification du contenu, sur son état et sur le fait qu'il doit être utilisé comme source fiable par un système d'intelligence artificielle.

Plus une plateforme est libre, plus il est difficile d'imposer une sémantique fiable par la suite.

Les systèmes d'intelligence artificielle ont besoin d'une structure, de métadonnées explicites et de signaux de confiance. Les espaces de travail flexibles à usage général nécessitent souvent beaucoup d'interprétation avant que leur contenu ne soit sûr pour ce type d'utilisation.

Cela ne signifie pas qu'ils sont condamnés

Ce serait une analyse paresseuse que de dire que Confluence et Notion ne peuvent pas s'adapter. Bien sûr qu'ils le peuvent.

Elles disposent d'équipes intelligentes, de ressources importantes et de fortes incitations. Ils fourniront davantage de capacités d'IA. Ils amélioreront la recherche, l'aide à la rédaction, les résumés, la gouvernance et les flux de travail structurés. Au fil du temps, ils pourraient combler une grande partie de l'écart.

Mais le timing est important.

Lorsqu'un tel changement se produit, l'avantage revient souvent à celui qui est prêt à reconstruire les hypothèses le plus rapidement. Les plates-formes plus récentes peuvent agir avec plus de cohérence parce qu'elles ne sont pas autant en train de se réadapter. Cela leur donne une marge de manœuvre.

Il ne s'agit peut-être pas d'une fenêtre permanente. Mais elle est réelle.

La prochaine phase des plates-formes de documentation

La prochaine génération d'outils de documentation sera probablement moins jugée sur sa capacité à permettre aux utilisateurs d'écrire des pages que sur sa capacité à gérer les connaissances en tant que système fiable.

Cela signifie que les gagnants feront probablement cinq choses bien :

Ils modéliseront la confiance de manière explicite.
Ils distingueront les connaissances actuelles des connaissances périmées.
Ils traiteront la recherche d'IA comme une surface de base du produit, et non comme un ajout.
Ils prendront en charge les connaissances multilingues et spécifiques à un public sans fragmentation.
Ils permettront aux équipes de mieux contrôler quelles informations sont diffusées, à qui et dans quelles conditions.

Il s'agit d'une catégorie différente du wiki classique.

Pourquoi les nouveaux départs sont importants

Il y a des moments dans les logiciels où un produit nouveau a un avantage, non pas parce que les titulaires sont incompétents, mais parce que l'histoire coûte cher.

C'est l'un de ces moments.

Une nouvelle plateforme peut décider, dès le premier jour, que les documents ne sont pas de simples pages. Ce sont des sources actives pour les humains, les agents, les systèmes de recherche et les assistants d'intelligence artificielle. Ce postulat change tout en aval.

Confluence et Notion peuvent y parvenir. Mais le chemin est plus long car elles doivent transformer des systèmes qui ont été optimisés pour une autre époque.

Cette transformation prend du temps. Entre-temps, les plateformes plus récentes ont la possibilité de définir ce à quoi devrait ressembler une infrastructure moderne de la connaissance.

Le plus grand avantage d'une nouvelle plateforme n'est pas la nouveauté. Le plus grand avantage d'une nouvelle plateforme n'est pas la nouveauté, c'est de se libérer des anciennes hypothèses au moment précis où elles cessent de fonctionner.

Il s'agit d'un article de perspective. Les affirmations concernant les produits concurrents sont basées sur la documentation et les annonces de produits publiquement disponibles en date de mars 2026. Nous avons un réel respect pour Confluence et Notion - ce sont d'excellents produits qui servent bien des millions d'équipes.

Au cœur de l'architecture Rasepi : Plugins, Action Guards et Pipelines

2026-03-06T00:00:00Z

La plupart des plateformes de documentation parlent d'"extensibilité" comme les compagnies aériennes parlent d'"espace pour les jambes". Techniquement présent, pratiquement décevant. Je voulais que l'architecture de Rasepi soit réellement extensible sans devenir imprévisible, c'est pourquoi nous avons construit trois systèmes interdépendants : plugins pour les capacités, action guards pour le contrôle, et pipelines pour l'exécution déterministe.

Ce billet explique comment chacun de ces systèmes fonctionne dans notre base de code actuelle.

Le système de plugins : modulaire par conception

Chaque plugin de Rasepi implémente IPluginModule, une interface unique qui déclare ce qu'est le plugin, les services dont il a besoin et les routes qu'il expose :

public interface IPluginModule
{
    PluginManifest Manifest { get; }
    void RegisterServices(IServiceCollection services);
    void MapRoutes(IEndpointRouteBuilder routes);
}

Le PluginManifest est une pure donnée. Il décrit le plugin sans rien exécuter :

public sealed class PluginManifest
{
    public required string Id { get; init; }
    public required string Name { get; init; }
    public required string Version { get; init; }
    public string Description { get; init; }
    public string Category { get; init; }
    public IReadOnlyDictionary<string, string> UiContributions { get; init; }
    public bool HasSettings { get; init; }
    public bool HasEndpoints { get; init; }
    public IReadOnlyList<string> Dependencies { get; init; }
}

Remarquez UiContributions. Ce dictionnaire associe les points d'extension du frontend aux noms des composants, de sorte que le frontend Vue sait à quels composants de l'interface utilisateur chaque plugin contribue (un bouton de la barre d'outils, un panneau de la barre latérale, une page de configuration).

L'enregistrement se fait sur une ligne par plugin

Au démarrage, nous enregistrons les plugins par le biais d'une API fluide :

var pluginRegistry = new PluginRegistry();

pluginRegistry
    .AddPlugin<WorkflowPluginModule>(builder.Services)
    .AddPlugin<RulesPluginModule>(builder.Services)
    .AddPlugin<RetentionPluginModule>(builder.Services)
    .AddPlugin<ClassificationPluginModule>(builder.Services);

Chaque appel instancie le module, le stocke dans le registre et appelle RegisterServices() pour connecter ses dépendances. Après la construction de l'application, une seule ligne permet de cartographier toutes les routes des plugins :

app.MapPluginRoutes(pluginRegistry);

Sous le capot, chaque plugin obtient un groupe de routes à /plugins/{pluginId}/ avec une autorisation automatiquement appliquée.

Exemple concret : le plugin Workflow

Voici à quoi ressemble un vrai plugin, le module Workflow & Approvals :

public sealed class WorkflowPluginModule : IPluginModule
{
    public const string PluginId = "workflow";

    public PluginManifest Manifest { get; } = new()
    {
        Id = PluginId,
        Name = "Workflow & Approvals",
        Version = "1.0.0",
        Description = "Adds approval workflows to entry publishing.",
        Category = "Workflow",
        HasSettings = true,
        HasEndpoints = true,
        UiContributions = new Dictionary<string, string>
        {
            ["entry.toolbar.publish"] = "WorkflowPublishButton",
            ["entry.sidebar.status"]  = "WorkflowStatusPanel",
            ["hub.admin.settings"]    = "WorkflowHubSettings",
        }
    };

    public void RegisterServices(IServiceCollection services)
    {
        services.AddScoped<IWorkflowService, WorkflowService>();
        services.AddScoped<IActionGuard, WorkflowPublishGuard>();
    }

    public void MapRoutes(IEndpointRouteBuilder routes)
    {
        WorkflowEndpoints.Map(routes);
    }
}

La plateforme principale ne fait jamais référence à WorkflowService ou WorkflowPublishGuard directement. Elle les découvre à travers le conteneur DI. C'est la clé du couplage zéro. L'application principale ne touche jamais au code des plugins.

Action guards : la couche de contrôle

Les plugins ajoutent des capacités. Les gardiens d'action décident si cette capacité, ou toute autre action de base, est autorisée à être exécutée. Ce sont des validateurs synchrones qui interceptent les opérations avant leur exécution.

L'interface est délibérément minimale :

public interface IActionGuard
{
    string PluginId { get; }
    string? ActionName { get; }  // null means guard ALL actions

    Task<ActionGuardResult> EvaluateAsync(
        ActionGuardContext context,
        IServiceProvider services,
        CancellationToken ct = default);
}

Lorsque ActionName est null, la garde s'exécute pour chaque action. Lorsqu'il est défini à quelque chose comme "Entry.Publish", il n'intercepte que cette action spécifique.

Les contrats de contexte et de résultat

Chaque gardien reçoit un contexte typé avec le nom de l'action, le locataire, l'utilisateur, l'entité et un sac de propriétés :

public sealed record ActionGuardContext(
    string ActionName,
    Guid TenantId,
    Guid UserId,
    Guid EntityId,
    IReadOnlyDictionary<string, object?> Properties)
{
    public T? Get<T>(string key) =>
        Properties.TryGetValue(key, out var v) && v is T typed
            ? typed : default;
}

Et chaque gardien renvoie un résultat prévisible : autoriser, refuser ou autoriser avec modifications :

public sealed record ActionGuardResult
{
    public bool IsAllowed { get; init; }
    public string? ReasonCode { get; init; }
    public string? Message { get; init; }
    public IReadOnlyDictionary<string, object?>? Modifications { get; init; }

    public static ActionGuardResult Allow() =>
        new() { IsAllowed = true };

    public static ActionGuardResult Deny(
        string reasonCode, string message) =>
        new() { IsAllowed = false, ReasonCode = reasonCode, Message = message };
}

Le champ Modifications est important. Un gardien peut approuver une action mais réécrire une partie du contenu (par exemple, expurger des secrets avant la publication).

Noms canoniques des actions

Nous définissons toutes les actions interceptables comme des constantes de chaîne afin qu'il n'y ait aucune ambiguïté sur ce qu'un gardien peut cibler :

public static class ActionNames
{
    public static class Entry
    {
        public const string Create  = "Entry.Create";
        public const string Save    = "Entry.Save";
        public const string Publish = "Entry.Publish";
        public const string Delete  = "Entry.Delete";
        public const string Archive = "Entry.Archive";
        public const string Renew   = "Entry.Renew";
    }

    public static class Hub
    {
        public const string Create = "Hub.Create";
        public const string Delete = "Hub.Delete";
        public const string TransferOwnership = "Hub.TransferOwnership";
    }

    public static class Translation
    {
        public const string Create  = "Translation.Create";
        public const string Publish = "Translation.Publish";
    }
}

Exemple réel : bloquer la publication sans approbation

Le plugin Workflow enregistre une garde qui intercepte Entry.Publish :

public sealed class WorkflowPublishGuard : IActionGuard
{
    public string PluginId => WorkflowPluginModule.PluginId;
    public string? ActionName => ActionNames.Entry.Publish;

    public async Task<ActionGuardResult> EvaluateAsync(
        ActionGuardContext context,
        IServiceProvider services,
        CancellationToken ct = default)
    {
        var db = services.GetRequiredService<RasepiDbContext>();
        var entry = await db.Entries
            .AsNoTracking()
            .FirstOrDefaultAsync(e => e.Id == context.EntityId, ct);

        if (entry is null)
            return ActionGuardResult.Allow();

        var workflowService = services.GetRequiredService<IWorkflowService>();
        var check = await workflowService
            .CheckPublishAllowedAsync(entry.Id, entry.HubId);

        if (check.IsAllowed)
            return ActionGuardResult.Allow();

        return ActionGuardResult.Deny(
            "workflow.approval_required",
            check.Message ?? "Approval required before publishing.");
    }
}

La plateforme principale ne sait rien des workflows d'approbation. Elle appelle simplement Entry.Publish à travers le pipeline, et le gardien le bloque si le workflow n'a pas été complété.

Le pipeline d'actions : là où tout converge

Le ActionPipeline est le chemin d'exécution unique pour toutes les opérations surveillées. Il détermine quelles gardes s'appliquent, les évalue et bloque ou exécute l'action.

CODEBLOCK_10__

La méthode EvaluateAsync fait le gros du travail :

public async Task<ActionPipelineResult> EvaluateAsync(
    string actionName,
    ActionGuardContext context,
    CancellationToken ct = default)
{
    // 1. Which plugins are enabled for this tenant?
    var enabledPlugins = await _resolver.GetEnabledPluginIdsAsync();

    // 2. Which guards match this action?
    var applicable = _guards
        .Where(g => enabledPlugins.Contains(g.PluginId))
        .Where(g => g.ActionName == null || g.ActionName == actionName)
        .ToList();

    // 3. Evaluate each guard
    var denials = new List<ActionGuardResult>();
    var modifications = new List<ActionGuardResult>();

    foreach (var guard in applicable)
    {
        try
        {
            var guardResult = await guard.EvaluateAsync(context, _services, ct);
            if (!guardResult.IsAllowed)
                denials.Add(guardResult);
            else if (guardResult.Modifications?.Count > 0)
                modifications.Add(guardResult);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Guard threw. Treating as Allow.");
        }
    }

    // 4. Any denial blocks the whole action
    if (denials.Count > 0)
        return ActionPipelineResult.Blocked(denials);

    return modifications.Count > 0
        ? ActionPipelineResult.Allowed(modifications)
        : ActionPipelineResult.Allowed();
}

Trois décisions importantes en matière de conception :

**Le TenantPluginResolver vérifie quels sont les plugins installés et activés par chaque locataire. Un garde pour un plugin désactivé ne s'exécute jamais.
Tout doit passer. Si un garde refuse, l'action est bloquée. Il s'agit d'une position de sécurité délibérée.
Guard errors fail open. Si une garde lance une exception, elle est enregistrée et traitée comme Allow(). Cela empêche un plugin défectueux de verrouiller toute la plateforme.

Résolution des plugins par locataire

Le résolveur interroge la table TenantPluginInstallations (automatiquement limitée au locataire actuel par les filtres de requête globaux EF) :

public sealed class TenantPluginResolver : ITenantPluginResolver
{
    public async Task<IReadOnlySet<string>> GetEnabledPluginIdsAsync(
        CancellationToken ct = default)
    {
        if (_cache is not null) return _cache;

        var ids = await _db.TenantPluginInstallations
            .Where(i => i.IsEnabled)
            .Select(i => i.PluginId)
            .ToListAsync(ct);

        _cache = ids.ToHashSet();
        return _cache;
    }
}

Effets secondaires liés aux événements

Les actions sont synchrones. Les effets secondaires ne le sont pas. Lorsqu'une action est terminée, le service publie un événement de domaine :

await _eventPublisher.PublishAsync(
    EventNames.Entry.Created, entry.Id, new { entry.OriginalLanguage });

Les événements sont mis en file d'attente dans un canal en mémoire et traités par un EventConsumerWorker en arrière-plan. Le travailleur achemine les événements vers plusieurs systèmes :

Suivi d'activité. Enregistre qui a fait quoi et quand.
Facturation de la traduction. Suivi des coûts par fournisseur
Les gestionnaires d'événements des plugins.** N'importe quel plugin peut s'abonner aux événements du domaine.

Les gestionnaires d'événements des plugins implémentent IPluginEventHandler :

public interface IPluginEventHandler
{
    string PluginId { get; }
    IReadOnlyList<string> SubscribedEvents { get; }

    Task HandleAsync(
        string eventName, Guid entityId,
        Guid? tenantId, Guid? userId,
        string payloadJson, IServiceProvider services,
        CancellationToken ct = default);
}

Le travailleur n'invoque que les gestionnaires dont le plugin est activé pour le locataire. Cela signifie que les effets secondaires du plugin A ne fuient jamais dans un locataire qui n'a que le plugin B d'installé.

Le moteur de traduction au niveau du bloc

C'est ici que l'architecture porte ses fruits de la manière la plus visible.

Traduction au niveau des blocs : seuls les blocs modifiés sont retraduits](/fr/blog/img/block-translation.svg)

Les plateformes traditionnelles traduisent des documents entiers. Nous traduisons des blocs individuels : paragraphes, titres, éléments de liste. Lorsqu'un utilisateur modifie un paragraphe dans un document de 50 blocs, seul ce paragraphe doit être retraduit. C'est la source de nos 94 % d'économies.

Comment les blocs sont créés à partir du JSON TipTap

Lorsqu'un utilisateur enregistre un document, l'éditeur TipTap envoie le JSON suivant :

{
  "type": "doc",
  "content": [
    {
      "type": "paragraph",
      "attrs": { "blockId": "a1b2c3d4-..." },
      "content": [{ "type": "text", "text": "Hello world" }]
    }
  ]
}

Le BlockTranslationService analyse ce JSON et crée des enregistrements EntryBlock individuels :

public async Task<List<EntryBlock>> CreateBlocksFromDocumentAsync(
    Guid entryId, string language, string contentJson,
    int version, Guid userId)
{
    var doc = JsonDocument.Parse(contentJson);
    var content = doc.RootElement.GetProperty("content");

    int position = 0;
    foreach (var node in content.EnumerateArray())
    {
        var blockType = node.GetProperty("type").GetString();
        var blockJson = JsonSerializer.Serialize(node);

        // Strip metadata attrs before hashing
        var hashInput = StripBlockMetaAttrs(blockJson);

        var block = new EntryBlock
        {
            Id = ExtractOrGenerateBlockId(node),
            EntryId = entryId,
            Language = language,
            Position = position++,
            BlockType = blockType,
            ContentJson = blockJson,
            ContentHash = CalculateContentHash(hashInput),
            IsNoTranslate = ExtractNoTranslateFlag(node),
            Version = version,
        };

        _context.EntryBlocks.Add(block);
    }

    await _context.SaveChangesAsync();
    return blocks;
}

hachage SHA256 pour la détection des données périmées

Le hachage du contenu est au cœur de la détection des blocs périmés. Nous hachons le contenu du bloc (après avoir supprimé les attributs de métadonnées tels que blockId et deleted) à l'aide de SHA256 :

private string CalculateContentHash(string content)
{
    using var sha256 = SHA256.Create();
    var hashBytes = sha256.ComputeHash(Encoding.UTF8.GetBytes(content));
    return Convert.ToHexString(hashBytes);
}

Lorsqu'un bloc source est modifié, son hachage change. Le système compare alors le SourceContentHash de chaque bloc de traduction au hachage actuel de la source, et les non-concordances sont marquées Stale :

public async Task MarkTranslationsAsStaleAsync(List<Guid> changedBlockIds)
{
    var affected = await _context.TranslationBlocks
        .Where(t => changedBlockIds.Contains(t.SourceBlockId))
        .ToListAsync();

    foreach (var translation in affected)
    {
        translation.Status = TranslationStatus.Stale;
        translation.UpdatedAt = DateTime.UtcNow;
    }

    await _context.SaveChangesAsync();
}

Adaptation de la structure

Les traducteurs peuvent modifier les types de blocs d'une langue à l'autre. Une liste à puces en anglais peut devenir une liste numérotée en allemand, une préférence culturelle. Le système en tient compte :

var translation = new TranslationBlock
{
    SourceBlockId = sourceBlockId,
    Language = targetLanguage,
    BlockType = translatedBlockType,
    SourceBlockType = sourceBlock.BlockType,
    IsStructureAdapted = translatedBlockType != sourceBlock.BlockType,
    SourceContentHash = sourceBlock.ContentHash,
    Status = TranslationStatus.UpToDate,
};

Les fournisseurs de traduction en tant que plugins

Les services de traduction externes (DeepL, Google Translate, etc.) se connectent via ITranslationProviderPlugin :

public interface ITranslationProviderPlugin : IRasepiPlugin
{
    string[] GetSupportedLanguages();

    Task<string> TranslateAsync(
        string text, string sourceLanguage, string targetLanguage);

    Task<TranslationBatchResult> TranslateBatchAsync(
        Dictionary<string, string> texts,
        string sourceLanguage, string targetLanguage);
}

La méthode batch reçoit un dictionnaire d'identifiants de blocs, les traduit tous et renvoie les traductions avec le nombre de caractères facturés. Comme nous n'envoyons que les blocs périmés, et non le document entier, les coûts restent minimes.

L'isolement des locataires : le filet de sécurité invisible

Tous les systèmes décrits ci-dessus fonctionnent dans le cadre d'une isolation stricte du locataire.

Le TenantContextMiddleware détermine le locataire à partir du JWT à chaque demande et vérifie l'appartenance :

public async Task InvokeAsync(
    HttpContext context, TenantContext tenantContext, RasepiDbContext db)
{
    var tenantIdClaim = context.User.FindFirstValue("tenant_id");
    var userIdClaim = context.User.FindFirstValue(ClaimTypes.NameIdentifier);

    // Populate scoped context
    tenantContext.TenantId = Guid.Parse(tenantIdClaim);
    tenantContext.UserId = Guid.Parse(userIdClaim);

    // Verify membership — fail closed
    var membership = await db.TenantMemberships
        .Where(m => m.TenantId == tenantContext.TenantId
                  && m.UserId == tenantContext.UserId)
        .FirstOrDefaultAsync();

    if (membership == null)
    {
        context.Response.StatusCode = 401;
        return;  // No membership = no access
    }
}

Les filtres de requête globaux d'Entity Framework garantissent que même si un développeur oublie de filtrer par locataire, la couche de base de données le fait automatiquement :

modelBuilder.Entity<Hub>()
    .HasQueryFilter(h => h.TenantId == _tenantContext.TenantId);

Le résultat : db.Hubs.ToListAsync() ne renvoie toujours que les hubs du locataire actuel. Les fuites de données nécessitent de contourner activement le filtre de requête, ce qui est interdit dans notre base de code.

L'image complète

Lorsqu'un utilisateur clique sur "Publier" pour une entrée, voici ce qui se passe :

**L'authentification valide le JWT, TenantContextMiddleware résout et vérifie le locataire.
Le contrôleur appelle le pipeline. IActionPipeline.ExecuteAsync("Entry.Publish", context, action)
Le pipeline résout les gardes. Interroge les plugins activés par le locataire et sélectionne les gardes applicables.
**La garde Workflow vérifie les approbations, la garde Retention vérifie la politique, la garde Rules valide le contenu. Tout est validé ? L'entrée est publiée.
**L'événement Entry.Published est mis en file d'attente. Un travailleur en arrière-plan enregistre l'activité, met à jour la facturation des traductions et appelle les gestionnaires d'événements du plugin.
**Les blocs périmés sont identifiés pour être retraduits.

Chaque couche fait son travail. Aucune couche n'empiète sur une autre. Telle est l'architecture.

Nous n'avons pas conçu cette solution parce que l'extensibilité est à la mode. Nous l'avons construit parce qu'une plateforme de documentation qui ne peut pas s'adapter au flux de travail de chaque équipe finira par être remplacée par une plateforme qui le peut. Et une plateforme qui s'adapte sans garde-fou finira par casser quelque chose d'important.