Les projets d'agents IA butent rarement sur la capacité des modèles. Ils butent sur ce qu'on leur donne : les agents ne savent ni ce qui existe dans l'organisation, ni ce qui s'est passé, ni ce qu'une action modifie. Ils n'ont pas de mémoire.
Palantir a traité une version de ce problème bien avant les LLM. Son approche mérite une lecture précise : ce qu'elle règle, et ce qu'elle laisse ouvert.
Le problème de mémoire
Un LLM n'a pas d'état. Sa fenêtre de contexte est limitée et repart de zéro à chaque session. Les solutions courantes ont chacune une limite structurelle.
La recherche vectorielle (RAG) retrouve des passages proches de la question. Elle ne garantit ni l'exhaustivité de la réponse, ni la cohérence entre les passages retrouvés ; les doublons et les contradictions s'accumulent au fil du temps.
Les fichiers de mémoire et les résumés de conversations sont du texte libre, sans schéma ni provenance. Quand deux notes se contredisent, rien ne permet de trancher.
Les graphes de connaissances maintenus à la main ont la bonne structure, mais leur coût de maintenance a toujours dépassé leur valeur d'usage. C'est le problème connu des référentiels d'entreprise.
Or décider demande plus que retrouver du texte. Il faut obtenir la liste exacte des commandes bloquées, pas les trois documents les plus proches. Il faut savoir d'où vient chaque chiffre, dater chaque fait, et conserver les désaccords entre sources. Ce sont des propriétés de bases de données, pas de modèles de langage.
Ce que Palantir a construit
Foundry se branche sur les systèmes existants et reconstruit une représentation unique de l'activité : l'ontologie. Elle contient d'abord les types d'objets (client, commande, usine, lot) et leurs relations. Dans un système, la commande s'appelle CMD-4512 ; dans un autre, 4512. L'ontologie établit qu'il s'agit du même objet.
Elle contient aussi les types d'actions, un point souvent négligé. Dans Foundry, une action déclare ses effets : approuver une commande, réaffecter un lot ou suspendre un fournisseur modifient chacun une liste précise d'objets. Cela répond à une question concrète que tout praticien rencontre. Quand un agent reçoit « j'ai traité la parcelle 12 ce matin », comment sait-il ce qu'il faut mettre à jour ? Il ne le décide pas. Il identifie le type d'événement, et le schéma détermine la propagation : l'entrée au registre, le stock décrémenté, les indicateurs recalculés, la prévision à recaler. Le modèle de langage comprend l'entrée et choisit le type ; la propagation est mécanique, donc auditable.
AIP, lancé en 2023, fait travailler les agents sur cette ontologie plutôt que sur des documents : requêtes exhaustives, écritures gouvernées, traçabilité.
La limite est le coût de construction. L'ontologie est modélisée à la main, client par client, par des ingénieurs dédiés, sur plusieurs mois. L'approche fonctionne, mais elle reste réservée aux États et aux très grands comptes.
Une mémoire à trois registres
En pratique, une mémoire exploitable par des agents combine trois registres.
Le référentiel : les entités et leurs relations, typées, identifiées, dédupliquées.
L'historique : les événements datés, reliés aux entités, avec leur issue. Un principe compte particulièrement ici : rien ne s'écrase. Un fait corrigé conserve son ancienne valeur et ses deux dates, celle de validité et celle d'enregistrement. L'état du système peut être rejoué à n'importe quelle date, et les décisions passées restent auditables.
Le contexte de travail : le sous-ensemble rappelé pour une question donnée, seule partie qui passe dans la fenêtre du modèle. Le rappel est une requête structurée, portant sur les entités concernées, leur historique récent et les épisodes comparables, pas une recherche de similarité.
S'y ajoutent quelques règles simples. Chaque fait porte sa provenance et son statut : mesuré, dérivé, simulé ou supposé. Les données manquantes sont enregistrées comme manquantes, au lieu d'être complétées par une génération. Les résumés se recalculent depuis les faits ; ils ne les remplacent pas.
Mesuré : issu d'un capteur ou d'un document source.
Dérivé : calculé depuis d'autres faits.
Simulé : produit par le modèle.
Supposé : déduit, en attente de confirmation.
Trois problèmes ouverts
La construction. Le modèle artisanal ne passe pas à l'échelle. La piste sérieuse est l'ontologie apprise : des agents d'ingestion lisent l'existant (factures, exports métier, flux capteurs, données ouvertes), en extraient les entités, réconcilient unités et identifiants, et signalent ce qui manque. Quand une entrée ne correspond à aucun type, l'agent propose une extension de schéma et l'humain la valide. Le schéma se mutualise bien : d'une organisation à l'autre d'un même métier, l'essentiel est déjà écrit.
La prédiction. Une ontologie décrit l'état courant. Décider demande d'anticiper, donc une couche prédictive au-dessus de la mémoire : des modèles mécanistes là où la science existe, des composants appris ailleurs, recalés en continu par assimilation de données, la technique qui a transformé la prévision météo. Avec une règle de partage stricte : les agents ne calculent pas les chiffres. Ils orchestrent des calculs spécialisés et vérifiables, et raisonnent sur leurs résultats.
La confiance dans le temps. Un modèle synchronisé se dégrade sans prévenir : changement de régime, usure, capteur défaillant. L'assimilation compense ces écarts sans les signaler, et l'utilisateur fait d'autant plus confiance au système qu'il fonctionne depuis longtemps. Il faut donc surveiller l'écart entre prédictions et réel, distinguer la dérive lente, qui s'absorbe, de la rupture, qui déclenche une alarme et un diagnostic, et de la panne capteur, qui est une fausse alarme à isoler. Il faut ensuite réparer de façon ciblée, puis éteindre l'alarme une fois le modèle recalé, sans quoi elle finit ignorée.
En résumé
L'ensemble forme une pile cohérente : une mémoire gouvernée, typée, datée, sourcée ; un schéma qui route les mises à jour ; des calculs auditables ; une surveillance calibrée ; des agents sous validation humaine. Une ontologie maintenue et utilisée en continu, c'est la définition d'un jumeau numérique, appris plutôt que construit.