574 626 octets : pourquoi notre llms-full.txt partage la même source que notre interface

Si vous suivez l'évolution des moteurs de recherche et des agents autonomes, vous avez probablement vu émerger le standard informel initié par Jeremy Howard : le fichier llms.txt (et son pendant exhaustif, llms-full.txt). L'objectif est simple : fournir aux modèles de langage une version textuelle, épurée et structurée d'un site web, sans le bruit habituel du DOM, des scripts de tracking ou des styles CSS.

Sur ce site, notre fichier llms-full.txt pèse exactement 574 626 octets. Ce demi-mégaoctet rassemble l'intégralité de nos projets, notes techniques, retours d'expérience et compétences. Mais la métrique la plus intéressante n'est pas son poids : c'est la façon dont il est construit. Il provient exactement du même tableau de données qui génère les pages HTML affichées dans votre navigateur.

Le problème de la duplication de contenu

Lorsqu'on souhaite exposer ses contenus aux agents conversationnels, le premier réflexe est souvent d'écrire un script de scraping interne, ou pire, de maintenir un document Markdown à la main en parallèle de son code frontend. Cette approche est vouée à l'échec :

• Désynchronisation immédiate : modifier une description de projet sur l'interface implique d'y penser dans le fichier texte.
• Bruit HTML persistant : un scraper interne capture souvent des balises inutiles, des modales ou des textes d'interface sans valeur sémantique.
• Coût de maintenance : chaque refonte visuelle risque de casser l'export texte.

Une source unique de vérité (SSOT)

Pour éviter ces écueils, l'architecture repose sur un principe fondamental de l'ingénierie logicielle : la source unique de vérité (Single Source of Truth). Toutes les entités du site (projets, parcours, études de cas) sont modélisées sous forme de tableaux d'objets fortement typés en TypeScript.

Au moment du build statique :

• Le moteur de rendu lit ces données pour composer les composants d'interface, optimiser les images et assembler le HTML/CSS.
• Un script dédié parcourt ces mêmes tableaux pour les sérialiser dans un format Markdown ultra-concis.

Le résultat ? Si je corrige une faute de frappe, ajoute un tag technologique ou publie un nouveau cas client dans mes données, la page web et le fichier pour LLM se mettent à jour instantanément, lors de la même compilation.

Que représentent 574 626 octets pour un modèle ?

Environ 560 kilo-octets de texte brut représentent approximativement 120 000 à 140 000 tokens selon le tokenizer employé. À l'ère des contextes de 128k à 1M de tokens (comme Claude 3.5 Sonnet ou Gemini 1.5), notre portfolio complet peut être ingéré en un seul appel de contexte par un agent de recrutement, un bot d'analyse de code ou un agrégateur spécialisé.

En éliminant les balises <div> imbriquées, les classes CSS utilitaires et les métadonnées superflues, chaque octet transmis sert directement à la sémantique. Le modèle n'a pas besoin de deviner ce qui relève de la navigation ou du contenu réel : la structure de données originelle lui est directement transmise sous une forme qu'il comprend nativement.

Penser l'accessibilité pour les machines

Nous avons passé deux décennies à concevoir le web pour les yeux humains, puis pour les robots d'indexation traditionnels via les balises meta et les microdonnées schema.org. L'arrivée des LLMs ne remplace pas ce travail, mais ajoute un nouvel utilisateur à l'équation : l'agent intelligent à la recherche d'une synthèse factuelle.

La leçon ici est encourageante pour les développeurs : un modèle de données propre et découplé de la vue permet d'adresser ces nouveaux usages en quelques lignes de script, sans alourdir son architecture.