On a transformé du texte en usine à gaz.

Tu te souviens du web où l’essentiel de la page était le texte que tu venais lire ?

Pas de cookies, de consentement, de pop up, pop in, pop whatever.

Pas 10 Mo de JS chargés à chaque page. Pas de SPA pour un site vitrine. Pas de node_modules de 5 Go sur ta machine pour un site de 5 pages.

En entreprise, c’est pareil. On se partage des fichiers Word sur SharePoint. Une fois sur deux, tu n’as pas accès.

L’autre fois, c’est « attends, ce n’est pas la dernière version ». Ou alors tu ne peux pas éditer. Ni commenter. Ou tu n’as tout simplement pas la licence Office.

Tout ça, c’est du texte. Juste du texte. Et ça devrait être géré comme tel : en séparant le fond de la forme.

À l’ère des LLM, c’est encore plus vrai. Les LLM mangent du texte. Si tu leur donnes des fichiers binaires, la première chose qu’ils feront sera de les transformer en texte.

Quand tu gères ta documentation comme du texte, le levier est énorme. Un LLM est meilleur que toi pour relier le contexte à grande échelle. Si une page A est liée à la B sur laquelle tu travailles, il peut mettre à jour la page A sans même que tu lui demandes.

L’outil sur lequel je travaille applique exactement cette logique. Il démultiplie les capacités des équipes techniques en prenant trois inputs : le code, l’état des services utilisés (GitLab, GitHub, Kubernetes…) et la documentation existante.

Tout ça n’est que du texte. Et quand c’est géré comme tel, le levier de productivité est phénoménal. Notamment parce que tu bénéficies de boucles de rétroaction.

L’état de tes services et de ton code alimente ta documentation. Et ta documentation aide à contextualiser tes agents qui modifient l’état de tes services (idéalement via ton code).

La vraie question n’est pas technologique.

Elle est culturelle : est-ce que ton organisation considère le texte comme un actif stratégique ?

Ou juste comme un livrable à produire ?