Les corpus¶

En bref

Un corpus est un fonds documentaire que Sentral indexe : un dossier, un fichier Markdown par document. Il y en a quatre. Cette page dit ce qu'ils contiennent, sous quels droits, comment en verser un nouveau, et — le plus important — ce qu'on a le droit d'éditer et ce qui est gelé.

Les quatre corpus¶

Corpus	Contenu	Volume	État
`comptabilisation-fr`	comptabilité française : plan comptable complet (classes 1 à 7), écritures types, articles de fond, lexique, exercices	1 210 documents	complet, capturé le 2026-07-24
`colonnage-sage`	droits d'affichage des colonnes des listes Sage, et où ils vivent en SQL	59 fiches, 2 172 colonnes, 38 tables	59 fiches sur 59 validées ; 3 tables sans écran sur cette installation, trésorerie hors périmètre
`rapports-sage`	fiches « rapport comptable Sage → SQL » : ce que Sage exécute réellement, et ce qui change d'une base client à l'autre	5 fiches	les 5 sont validées sur deux bases, au centime ; le corpus reste ouvert
`kb-sage`	base d'assistance Sage France : Sage 100, Génération Experts, Paie & RH, États Comptables et Fiscaux	6 220 articles, dont 2 056 marqués « développeur »	complet, 0 échec de capture

La base d'assistance Sage n'est pas un pis-aller

Le site développeur de Sage ne publie aucune documentation de Sage 100 France : la version américaine y est, la française non. Ces 6 220 articles sont la seule documentation de ce produit qui existe. C'est pour cela qu'ils sont servis par un registre déterministe et non par la recherche en prose.

Droits et usage¶

Corpus	Origine	Ce qu'on a le droit d'en faire
`comptabilisation-fr`	un site public de comptabilité, capture faite dans le respect de son fichier d'exclusion des robots ; chaque document conserve son URL d'origine	usage interne. Ne pas republier tel quel
`kb-sage`	la base d'assistance Sage France — © Sage ; chaque document conserve son URL et son identifiant d'origine	usage interne, ne pas republier. L'accès repose sur la qualité d'éditeur de solutions Sage de SenSaaS et sur les comptes Sage de l'équipe
`colonnage-sage`	produit en interne. La moitié SQL est mesurée et rejouable ; la moitié « libellés » exigeait la machine Windows	interne
`rapports-sage`	produit en interne. Les captures brutes et les données clients n'y entrent jamais	interne

Rendre un corpus visible d'un revendeur ou d'un client est une décision à part

Si le fonds Sage devait un jour être servi à un revendeur ou à un client, ce serait une décision explicite, prise par le mécanisme de périmètres prévu dans le cadrage — pas par un oubli de configuration. Voir Règles pour les agents.

Verser un corpus : les conventions¶

Un corpus tient dans un dossier :

corpus/<nom-du-corpus>/
├── README.md          ← d'où ça vient, comment c'est produit, ses limites
└── **/*.md            ← un fichier = un document autonome

Ces conventions ne sont pas cosmétiques : elles conditionnent la qualité de l'indexation.

Un fichier Markdown = un document autonome. Une fiche de compte, une écriture, un article doivent se comprendre seuls, sans contexte extérieur. C'est ce qui permet à un passage retrouvé isolément d'être utilisable.
Un en-tête YAML en tête de fichier : source, source_url, date_capture, type_document, puis les champs propres au type. Ces champs deviennent les filtres de la recherche.
Une ligne de contexte (> …) juste après le titre principal : elle résume ce qu'est le document. Indispensable quand un extrait sort seul de la recherche.
Une structure par titres. Sentral découpe par section et préfixe chaque passage de « titre — section » : les citations deviennent exactes, et les mots du titre participent à la recherche.
Les fichiers d'index (00-*.md) sont indexés aussi : ce sont eux qui répondent aux questions d'ensemble, du type « la liste des comptes de classe 4 ».

Exemple d'en-tête :

---
source: nom-de-la-source
source_url: https://exemple.test/article/123
date_capture: 2026-09-11
type_document: article
---

Il reste ensuite à déclarer la source dans le fichier de configuration de Sentral, puis à lancer l'ingestion et le banc de coût.

Trois choses à savoir avant de verser beaucoup

Ne dupliquez pas ce qui existe déjà. Une documentation ingérée depuis son dépôt d'origine se corrige là-bas ; en recopier une version ici créerait une version périmée.

Plus de contenu n'est pas mieux. Une source n'entre que si elle répond à une question qu'on ne sait pas traiter, et elle arrive avec son budget en jetons mesuré.

La recherche en prose n'a pas de banc de mesure. Rien ne vérifie que ce que vous versez est effectivement retrouvable. Remède minimal : ajouter cinq à dix questions réelles au jeu de référence pour votre source. Sans cela, personne ne saura si elle ressort.

Ce qu'un corpus ne suffit pas à faire¶

Leçon mesurée, et valable pour tout corpus à venir : un référentiel structuré ne se cherche pas comme de la prose. Avant d'avoir sa table dédiée, la bonne fiche de compte du plan comptable sortait 16ᵉ sur 9 582 passages — les milliers d'exemples d'écritures, tous bâtis sur le même gabarit, la noyaient.

Conséquence : quand un corpus contient un référentiel (des comptes, des rapports, des tables), il lui faut en plus un registre déterministe et son outil dédié. Le corpus sert la prose, le registre sert la précision.

Les quatre étages : ce qu'on édite, ce qu'on régénère, ce qui est gelé¶

C'est la seule chose à retenir avant de corriger quoi que ce soit. Le dépôt n'est pas homogène : la même faute de frappe se corrige, se régénère ou se signale selon l'étage où elle se trouve.

Étage A — on édite librement¶

Prose, code, descriptions d'outils. Rien d'autre qu'un fichier à corriger.

tous les fichiers README.md, et les études ;
les descriptions des 25 outils MCP — c'est ce qu'un agent lit pour choisir un outil, et une description ambiguë coûte un appel inutile à chaque conversation. Probablement le meilleur rapport effort / gain du dépôt ;
le code Python du serveur, des outils et de la démonstration ;
le corpus de comptabilité (Markdown, sans statut de validation).

Étage B — on ne touche pas le fichier, on le régénère¶

Les fichiers de données produits par les extracteurs portent en tête « GÉNÉRÉ, ne pas éditer à la main » et une empreinte du document source. Une correction s'applique à la source, puis on relance l'outil qui produit le fichier. L'empreinte est là pour que la triche se voie.

Étage C — gelé : on propose, on ne corrige pas¶

Les 59 fiches de colonnage et les 5 fiches de rapports sont toutes marquées valides. Ce statut n'est pas décoratif : chaque fiche a été confrontée à l'écran de Sage ou aux totaux au centime sur deux bases — 44 confrontations sans écart, 59 marqueurs de position.

Trois conséquences qui doivent arrêter net :

un libellé Sage qui ressemble à une coquille EST la donnée. Sage écrit ce qu'il écrit ; la fiche le recopie. « Corriger » l'orthographe casse silencieusement la confrontation qui l'a validée ;
plus rien n'est re-mesurable. Le serveur Windows qui portait Sage est fermé depuis le 2026-09-08. Une erreur soupçonnée dans une fiche validée ne peut plus être vérifiée ;
une confrontation sans écart peut passer sur une fiche fausse. C'est mesuré : treize marqueurs ont réfuté cinq fiches qui n'avaient aucun écart. Donc même « ça a l'air juste » n'autorise rien.

Une passe automatique de correction sur ces 64 fiches détruirait le travail de mesure

…et aucun test ne le verrait. Une erreur soupçonnée se signale — une note dans la demande de fusion, ou un fichier de propositions — jamais par une commande de remplacement en masse.

Étage D — ce n'est pas à nous¶

Les dépôts voisins (l'agent Sage de l'entreprise, la stack collaborative) sont lus, jamais écrits. Une correction de leur catalogue se porte depuis chez eux, où la non-régression se mesure. Un cas est déjà en attente : une correction écrite et contre-testée, volontairement non appliquée.

Ce qui produit et vérifie les corpus¶

Aucun de ces outils ne tourne en continu : on les lance, ils écrivent un fichier versionné ou un rapport.

Famille	Ce qu'elle fait
extracteurs	convertissent une fois pour toutes les documents Sage figés (classeur des tables, documentation officielle de structure de 443 pages) et le fragment de contrat de l'API SenSaaS en fichiers de données versionnés et comparables
colonnage	inventorient les tables qui portent les droits d'affichage, prédisent un écran depuis une fiche, prouvent la correspondance liste ↔ ligne SQL par marqueurs injectés, puis écrivent les fiches après trois contrôles
capture et pilotage Sage	capturent le SQL réellement exécuté pendant qu'un état est produit, et pilotent l'interface avec un vocabulaire fermé de huit gestes — les captures brutes restent hors du dépôt
vérificateurs	contrôlent que tout chemin cité dans la documentation existe vraiment

Pourquoi une conversion unique plutôt qu'une lecture à chaud

Le catalogue de l'agent Sage est lu à chaud parce que son équipe l'édite : une copie divergerait. Le classeur et la documentation officielle, eux, sont des documents figés — les convertir une fois en fichiers versionnés et comparables vaut mieux que parser un binaire à chaque démarrage. Le seul risque, une source qui change sans qu'on le sache, est fermé par une empreinte inscrite dans chaque fichier produit et vérifiée par les tests.

Ce que les extracteurs écartent, ils le comptent

Un tableau de PDF ne se parse jamais à 100 %. Plutôt que de livrer des entrées douteuses, les extracteurs les rejettent et inscrivent le décompte en tête du fichier produit. Qui relit le fichier sait donc ce qui manque, et pourquoi.

Questions fréquentes¶

Peut-on republier un article de la base d'assistance Sage dans cette documentation ?

Une fiche de colonnage contient une faute : je la corrige ?

Non — étage C. Signalez-la dans la demande de fusion ou dans un fichier de propositions. Le libellé fautif peut être exactement ce que Sage affiche.

Mon clone n'a pas les dépôts voisins : est-ce grave ?

Non. L'ingestion ignore une source dont le chemin est absent, avec un avertissement, et continue. Vous obtenez une base partielle mais valide.