Architecture

Cette architecture existe à deux échelles. Au sein d'une mission squad, c'est la couche de contexte et les agents que nous installons dans vos dépôts, sur vos comptes : instructions de dépôt, signaux connectés, portes de qualité, accès restreints, retour arrière. À l'échelle de l'entreprise, c'est la plateforme world model décrite sur cette page. Les principes sont les mêmes des deux côtés : vous êtes propriétaire du plan de données, chaque action est auditable, et le système s'appuie sur ce qui existe déjà.

La plateforme suit un pipeline simple : les sources de données alimentent des pipelines d'ingestion, qui mettent à jour un knowledge graph temporel, qui alimente une boucle de raisonnement continue portée par des grands modèles de langage, qui déclenche des actions via une interface d'outils, qui présente les décisions et les résultats aux humains à la périphérie. Chaque étape est journalisée, auditable et réversible.

Ingestion

La plateforme se connecte aux systèmes que l'entreprise utilise déjà : Slack, Gmail, Google Drive, Notion, Linear, Jira, Salesforce, HubSpot, les ERP et d'autres. Les connecteurs sont incrémentaux, pas par lots. Quand un message part ou qu'une opportunité avance, le modèle se met à jour en quelques secondes. Nous ne demandons pas aux entreprises de migrer leurs données ni de changer leurs façons de travailler. Le world model se construit à partir des systèmes qui existent déjà.

Chaque connecteur est limité aux permissions strictement nécessaires. Les pipelines d'ingestion gèrent la déduplication, la normalisation et la résolution d'entités entre les sources. Une mention du « projet Renault » dans Slack, une fiche dans Salesforce et un fil de discussion dans Gmail sont résolus vers la même entité dans le graphe.

Stockage

La structure de données centrale est un knowledge graph temporel : des entités, des relations et des attributs, chacun avec l'historique complet de ses changements dans le temps. La couche de stockage par défaut est Postgres avec pgvector pour la recherche par embeddings. Pour les clients qui ont des exigences particulières, nous prenons en charge des bases de graphes managées en alternative. Dans tous les cas, les données vivent dans le cloud du client, sur son propre compte.

La temporalité n'est pas une option. La capacité à raisonner sur la façon dont l'organisation a évolué dans le temps est ce qui sépare un world model d'un instantané. Le graphe stocke non seulement l'état actuel de chaque entité et de chaque relation, mais toute la séquence des états, avec horodatage, provenance et liens de causalité.

Raisonnement

La boucle de raisonnement tourne en continu. Elle traite les signaux entrants au regard de tout le contexte du graphe temporel, identifie des schémas, détecte des anomalies, fait remonter des enseignements et génère des plans d'action. La boucle s'appuie sur des grands modèles de langage, accessibles via le fournisseur choisi par le client : Anthropic sur Vertex AI, Amazon Bedrock ou Azure OpenAI. Toute l'inférence passe par des endpoints privés sans rétention de données, garantie contractuellement.

La qualité du raisonnement n'est pas déterminée par les capacités générales du modèle. Elle est déterminée par la qualité du contexte. Et ce contexte vient du graphe temporel, pas d'un prompt. C'est pour cela qu'un world model produit un meilleur raisonnement qu'un assistant IA généraliste : le contexte est structuré, complet et temporel, pas improvisé et éphémère.

Les workers IA

Nous construisons des collaborateurs IA autonomes sur mesure pour chaque client. Ces workers vivent dans les messageries que l'entreprise utilise déjà : Slack, Teams, WhatsApp ou tout autre canal où le travail se fait. Ils parlent avec les humains à la périphérie, ceux qui sont au plus près du travail, en langage naturel, dans les outils que ces personnes ont déjà ouverts.

Chaque worker IA est connecté au world model. Quand un worker reçoit une information d'un humain, il met à jour le world model. Quand le world model identifie quelque chose qui demande une attention humaine, il fait passer ce signal par le bon worker jusqu'à la bonne personne. Les workers sont l'interface entre le world model et l'organisation. Ils répartissent les tâches, font remonter le contexte, collectent les mises à jour et maintiennent le modèle en phase avec la réalité.

Chaque action d'un worker passe par une interface d'outils de type MCP : appels d'API, écritures dans les systèmes en aval, envoi de messages, création de documents. Chaque appel d'outil est journalisé avec tout son contexte : ce qui l'a déclenché, le raisonnement qui l'a produit, les données auxquelles il a accédé. Un coupe-circuit est disponible à tout moment. Un bouton gèle instantanément tous les workers, sur l'ensemble du déploiement. Aucune action n'est menée sans piste d'audit complète, et chaque action peut être annulée.

Observabilité

Chaque lecture, chaque étape de raisonnement, chaque action est journalisée et exportable. La plateforme fournit une piste d'audit complète qui peut être envoyée vers le SIEM existant du client, exportée pour une revue de conformité, ou interrogée directement. Il n'y a pas de boîte noire. Le raisonnement du world model est transparent par conception.

Principes de conception

Chaque décision d'architecture suit trois principes. Premièrement, le client est propriétaire du plan de données. Nous ne détenons jamais les données du client. Deuxièmement, chaque action est auditable et réversible. Il n'y a de boîte noire nulle part dans la stack. Troisièmement, le système s'appuie sur ce qui existe déjà. Pas de migration, pas de nouvel outil à adopter, aucun changement de façon de travailler imposé. Le world model s'assemble à partir de l'infrastructure que l'entreprise fait déjà tourner.

Lire les détails de sécurité et de déploiement →
En quoi cela diffère d'un knowledge graph →