Utopia : un graphe de connaissances bitemporel dans un binaire Rust et un Postgres

Le problème visé : conserver le cheminement, pas seulement l'état courant

Un magasin vectoriel classique répond à une question sur l'état présent d'un corpus. Utopia part d'un autre constat : quand une décision est réexaminée plus tard, la question n'est pas seulement ce que l'organisation sait aujourd'hui, mais ce qu'elle croyait à une date donnée et sur quels éléments. Le README formule l'objectif ainsi : là où les bases vectorielles et les graphes de connaissances cherchent à établir correctement la connaissance présente, Utopia veut enregistrer tout le parcours d'une compréhension qui change. Le public visé est donc l'entreprise qui doit produire une piste d'audit de conformité sur du matériel qu'elle contrôle, et dont les agents ont besoin d'un noyau décisionnel fiable. Le texte de présentation demande explicitement à ne pas être lu comme une déclinaison open source de Palantir, et revendique une construction partant de la gouvernance des connaissances vers la décision. C'est une prétention large pour un dépôt qui n'a pas encore atteint sa version 1.0.

Deux axes temporels et une ontologie qui sert de socle

Le mécanisme central est le graphe bitemporel. L'extraction transforme les documents en entités et en faits, en suivant une ontologie que l'utilisateur peut modifier. Chaque fait porte la période où il était vrai et sa provenance. Corriger un fait ne l'écrase pas : l'ancienne version est close et la nouvelle y est reliée, ce qui laisse deux chronologies distinctes, celle du monde et celle des croyances du système. C'est cette séparation qui permet de demander à l'agent les faits d'une entité à une date donnée, ou ce qui a changé sur une période. Autour de ce noyau, le README décrit une résolution d'entités en trois étapes (nom ou alias exact, similarité d'embeddings, puis arbitrage par un modèle sur les paires douteuses), chaque fusion étant réversible. Les cas incertains partent dans une file de revue : extractions à faible confiance, doublons suspectés, conflits de cardinalité. La dérive logique est traitée à part : les axiomes de l'ontologie se compilent en règles (transitivité, symétrie, inverses, hiérarchie de relations) appliquées par chaînage avant. La dérivation est désactivée par défaut, et le README donne la raison sans détour : un axiome erroné dérive des faits erronés. Un fait dérivé est marqué comme tel, porte validité et confiance comme les autres, et affiche ce dont il provient. En cas de contradiction avec un fait asserté, ce dernier l'emporte. Ce choix est cohérent, mais il place toute la charge de la qualité sur la relecture des axiomes, et rien dans le matériel fourni ne décrit un outil de validation des axiomes.

Ce qui tourne réellement : un binaire, Postgres, une table comme file de tâches

L'argument d'exploitation est minimaliste et vérifiable dans le README : un binaire Rust et un Postgres. La recherche plein texte est embarquée dans le binaire via Tantivy, les vecteurs vont dans pgvector, et la file de tâches est une table. Il n'y a donc pas de courtier de messages ni de moteur de recherche séparé à maintenir. La recherche combine plein texte et vecteurs par fusion RRF. Les réponses arrivent en flux avec des citations qui ouvrent le passage d'origine. N'importe quel point de terminaison compatible OpenAI fonctionne, et le README cite DeepSeek, Qwen, GLM, Ollama et vLLM, ce qui rend le déploiement hors ligne possible. L'ingestion couvre PDF, DOCX, PPTX, XLSX, XLS, ODS, CSV, TSV, Markdown, HTML et texte brut, avec détection des encodages anciens. Des connecteurs synchronisent pages web, RSS, GitHub, Jira, Notion, WebDAV et compartiments compatibles S3 selon un calendrier. Le reste passe par l'API. L'interface web réunit console système, navigateur de graphe et atelier d'ontologie. Le projet se présente comme un produit et non comme une bibliothèque. C'est une distinction importante : il n'existe pas, d'après le matériel fourni, de crate à importer dans une application existante.

Démarrage : conteneur, packs d'ontologie et point de terminaison de modèle

Le dépôt publie une image sur GHCR sous l'identifiant deeplethe/utopia, et le README renvoie à une section Quick start pour la mise en route. Le matériel fourni ne détaille pas les commandes exactes de cette section, donc je ne les inventerai pas ici. Ce que la documentation permet d'affirmer, c'est la forme du déploiement : un conteneur, un PostgreSQL avec l'extension pgvector, et un point de terminaison compatible OpenAI à renseigner. Le choix se fait aussi à la création d'une base de connaissances, au moment de sélectionner les packs d'ontologie. Cinq sont embarqués dans le binaire : schema.org, W3C Org, PROV-O, FOAF et IOF Core. Une base neuve n'a pas de vocabulaire propre, elle part de ces packs. Les termes hors packs sont comptés au fil de leur apparition, et confirmer les plus fréquents les fait entrer dans l'ontologie. Ce comptage est le seul mécanisme de démarrage à froid décrit, et il suppose que le corpus soit suffisamment volumineux pour que les termes fréquents soient aussi les termes utiles. Sur un petit corpus métier, l'atelier d'ontologie demandera probablement une saisie manuelle.

Version rc, branche dev et absence de contrat de compatibilité

La limite la plus concrète n'est pas technique. Les trois versions publiées sont v0.1.0-rc3, v0.1.0-rc4 et v0.1.0-rc5, étalées sur douze jours début septembre 2026, et la branche par défaut est dev. Le rythme de publication de correctifs en quelques jours indique un travail actif, mais aussi une surface qui bouge. Rien dans le matériel fourni ne décrit de politique de compatibilité entre versions candidates, ni de procédure de migration de schéma. Or le système repose sur PostgreSQL avec pgvector et sur une table faisant office de file de tâches : une montée de version touche donc l'état persistant, pas seulement le binaire. À cela s'ajoute l'absence de page d'accueil de projet autre que le site officiel utopia.bi, et un README tronqué dans le matériel dont je dispose, ce qui laisse la partie sur le raisonnement et la dérivation sans fin vérifiable. Le projet est également très large : ingestion multi-format, connecteurs, recherche hybride, agent, MCP, ontologie, résolution d'entités, dérivation. Pour une équipe, cela signifie plusieurs domaines à maîtriser avant de pouvoir juger la qualité du résultat.

Face à un graphe de connaissances temporel classique

L'alternative la plus proche conceptuellement n'est pas un magasin vectoriel, mais un graphe de connaissances avec horodatage, du type de ceux que l'on construit sur une base de graphes et une couche applicative. La différence d'approche tient à l'endroit où vit la temporalité. Dans une pile assemblée à la main, les dates de validité sont des propriétés que l'application doit écrire, interroger et fermer correctement ; le bitemporel est une convention d'équipe. Chez Utopia, il est dans la couche de base : corriger un fait clôt l'ancienne version et lie la nouvelle, et le système distingue le moment où un fait était vrai de celui où il a été cru. L'agent peut alors interroger un état à une date ou une différence sur une période sans que l'application appelante ait à reconstruire cette logique. Le revers est le même que pour tout cadre intégré : on hérite du modèle de données du projet, de son ontologie et de son interface, y compris lorsque l'on voudrait seulement une partie du tout. Un graphe monté soi-même coûte plus cher en développement et ne fournit ni file de revue, ni résolution d'entités en trois étapes, ni recherche hybride fusionnée par RRF. C'est un arbitrage entre contrôle et travail d'intégration, pas une supériorité dans l'absolu.

Licence, maintenance et coût de montée de version

Le projet est publié sous Apache-2.0, ce qui autorise l'usage commercial, la modification et la redistribution, avec les obligations habituelles de conservation des mentions de licence et d'état des modifications. Je ne donne pas de conseil juridique : pour un déploiement en entreprise, la clause de brevets et les obligations de notice méritent une lecture par votre service compétent. Sur la maintenance, le matériel disponible montre des publications rapprochées et une branche dev par défaut, ce qui suggère un développement mené sur cette branche plutôt que sur une branche stable. Le coût d'exploitation décrit est faible (un binaire, un Postgres, une table comme file), mais le coût de mise à jour ne l'est pas forcément : sans procédure de migration documentée dans ce que j'ai pu lire, chaque passage de rc demande de vérifier soi-même l'état du schéma avant de remplacer le binaire. La question à poser avant de s'engager n'est donc pas celle du nombre de fonctionnalités, mais celle du contrat de stabilité que l'éditeur acceptera de tenir une fois la 1.0 atteinte.

Conclusion éditoriale

Utopia vise les équipes qui doivent reconstituer l'historique d'une décision et qui acceptent d'exploiter elles-mêmes un binaire, un PostgreSQL et une file de tâches réduite à une table. Passez votre chemin si vous cherchez une bibliothèque à intégrer, un service hébergé ou une API stable : le projet est en v0.1.0-rc5, la branche par défaut est dev, et les notes de version ne disent rien de la compatibilité entre rc. Avant de vous engager, vérifiez trois points dans le dépôt : si les migrations SQL couvrent la montée rc4 vers rc5, si les cinq packs d'ontologie embarqués suffisent à votre vocabulaire métier, et si la dérivation par chaînage avant reste désactivée tant que vos axiomes n'ont pas été relus.

Sources officielles

1. deeplethe/utopia on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases