FORMATS STRUCTURÉS
CSV, Parquet, DuckDB et NDJSON sont les entrées prioritaires du moteur.
+Moteur / DataAuthority
INTERROGER VOS DONNÉES SANS PERDRE LEUR HISTOIRE.
DataAuthority transforme des données issues de sources dispersées en faits structurés, traçables et interrogeables. Le moteur fusionne, contrôle et décompose les données en unités de faits, tout en conservant la provenance, les transformations, la couverture et les limites nécessaires pour interpréter ses résultats.
Le moteur n’est pas en libre accès. Nous l’utilisons actuellement sur des cas sélectionnés et des jeux de données transmis sur demande.
01 / Le principe
DES DONNÉES STRUCTURÉES JUSQU’AUX FAITS INTERROGEABLES.
Un atom est un petit fait structuré auquel DataAuthority rattache son identité, son contexte et les informations nécessaires à son usage. Dans notre architecture, un atom relie une valeur à une source, une version, un contexte et aux conditions qui limitent son usage — selon les contrats disponibles pour le cas traité. C’est notre vocabulaire de travail, pas un standard officiel.
Le moteur est conçu pour travailler sur des jeux de données structurés fournis au cas par cas, qu’ils proviennent de sources publiques ou d’organisations. Les données publiques restent notre principal terrain de démonstration à ce jour.
ATOMS
Le moteur est conçu pour décomposer les résultats en unités de faits plutôt qu’en un verdict global opaque.
PROVENANCE + CONTRÔLE
Sources, versions, transformations et contrôles restent attachés au parcours de la donnée.
LIMITES
Inconnu, conflit, couverture insuffisante et conclusions interdites restent explicites.
02 / Du fichier au résultat
SOURCES, FUSION, ATOMISATION, RÈGLES, INTERROGATION.
CSVParquetDuckDBNDJSON
1 · Sources2 · Fusion3 · Atomisation4 · Règles d’interprétation5 · Preuves / provenance6 · Interrogation7 · RésultatÀ l’étape 4, les règles qui déterminent comment un fait peut être interprété portent sur les dimensions, les unités, les périodes, la provenance disponible et les contradictions explicites. À l’étape 6, le moteur retient les faits compatibles avec la question posée. Si un fait ne satisfait pas les règles requises pour une interrogation précise, il n’est pas utilisé pour cette réponse : la raison reste documentée et le fait n’est ni transformé ni présenté comme une certitude.
Ce parcours correspond à la fusion de données : réunir plusieurs sources en conservant ce qui permet d’interpréter le résultat.
03 / Ce que nous ne transformons pas
« ON NE SAIT PAS » NE DOIT PAS DEVENIR « ZÉRO ».
Quand une information est absente, le moteur doit pouvoir la laisser absente. Il ne doit pas transformer un manque de donnée en certitude, ni inventer une valeur pour remplir une case.
- Une source absente reste absente.
- Une contradiction entre sources reste visible.
- Une limite de couverture n’est pas masquée.
- Une réponse ne doit pas affirmer davantage que les données disponibles.
Ce principe est détaillé, avec les familles d’outils existantes, dans Après transformation, le résultat veut-il encore dire la même chose ?
04 / Tester le moteur
DONNEZ-NOUS UN JEU DE DONNÉES. NOUS VOUS MONTRONS CE QUE LE MOTEUR EN FAIT.
Le moteur n’est pas en libre accès. Nous l’utilisons actuellement sur des cas sélectionnés et des jeux de données transmis sur demande. Concrètement : un échantillon CSV, Parquet, DuckDB ou NDJSON, un problème concret, puis une restitution de ce que les données permettent réellement d’affirmer — et de ce qu’elles ne permettent pas d’affirmer.
Limite actuelle : les PDF et documents sont étudiés au cas par cas lorsqu’ils sont nativement textuels et vérifiables. Ils ne sont pas notre promesse principale, et l’OCR de documents arbitraires n’est pas présenté comme une capacité garantie.