Palantir : sous le capot
Ce que Foundry, Gotham, AIP et Apollo font vraiment — d'un point de vue data engineering
Palantir : ce qu’il faut vraiment comprendre quand on est data engineer
Palantir fait beaucoup parler d’elle en ce moment. Les contrats militaires, les polémiques sur la surveillance, l’action qui s’envole. Mais derrière le storytelling géopolitique, il y a une architecture logicielle réelle, avec des choix techniques qui méritent qu’on s’y attarde. Je ne vais pas prendre position sur l’impact positif ou négatif de la société, on ne va parler que des spécificité techniques de la plateforme.
L’Ontologie : le truc qu’il faut vraiment assimiler
Avant tout le reste, il y a une idée centrale. Palantir ne construit pas une base de données, ni un data warehouse, ni un catalogue. Ils construisent une ontologie — un modèle structuré du monde métier du client.
Ce que ça veut dire concrètement : au lieu de forcer un analyste à naviguer dans des tables SQL abstraites, Palantir traduit la donnée brute en objets concrets. Un avion. Un client. Un soldat. Un contrat. Ces objets ont des propriétés, des relations entre eux, et des actions possibles.
Côté architecture : l’Ontology Metadata Service (OMS) définit l’ensemble des entités — types d’objets, types de liens, types d’actions. Les object databases stockent les données indexées et assurent des requêtes rapides. La version actuelle (Object Storage V2) sépare les sous-systèmes d’indexation et de requêtage pour permettre un scaling horizontal indépendant. La V1 — nom de code Phonograph — consolidait tout dans le même bloc, ce qui créait des goulots d’étranglement prévisibles.
Quatre plateformes, une stack verticalement intégrée
Gotham — la brique souveraine
Gotham, c’est la plateforme historique. Agences de renseignement, forces de défense, services de police. Elle représente encore environ 55 % du CA.
Ce qu’elle fait techniquement : agréger des sources massives et hétérogènes — bases administratives, rapports de renseignement, données biométriques, historiques judiciaires, géolocalisation, réseaux sociaux. Tout ça converge dans un tableau de bord unifié. Le moteur IA détecte des connexions, identifie des anomalies, hiérarchise des menaces en temps réel.
Le chiffre mis en avant par Palantir : ce qui nécessitait 2 000 analystes pendant la guerre du Golfe peut se faire avec 20. On peut discuter de la métrique, mais l’ordre de grandeur illustre le positionnement.
Foundry — l’OS de la donnée d’entreprise
Foundry, c’est Gotham pour le monde civil et industriel. Airbus, Stellantis, le NHS, et côté public français : la DGSI, quelques ministères.
La stack pour un data engineer :
Pipeline Builder : construction des pipelines de transformation, avec support de moteurs externes (Databricks est en bêta depuis septembre 2025)
HyperAuto : un connecteur SAP point-and-click qui génère automatiquement les pipelines, avec support du streaming temps réel via SLT Replication Server — la donnée circule de SAP à l’Ontologie en quelques secondes
Code Workspaces : notebooks JupyterLab et RStudio intégrés, avec accès natif à l’Ontologie
Contour / Workshop : la couche applicative pour les utilisateurs métiers, sans SQL requis
Le concept clé : tout dataset peut devenir un backing dataset pour un Object Type. Le pipeline ne s’arrête pas à la livraison d’une table — il alimente un objet dans l’Ontologie qui peut déclencher des actions, alimenter des agents IA ou être consommé par des applications. C’est une façon de penser la donnée qui change pas mal de choses.
AIP — l’IA ancrée dans la réalité métier
AIP (Artificial Intelligence Platform) est lancée en 2023 et c’est aujourd’hui le principal moteur de croissance de Palantir — +137 % de revenus US au Q4 2025.
Ce qui distingue AIP d’une intégration LLM classique : le LLM n’opère pas sur des tokens, il opère sur l’Ontologie. Au lieu de générer du texte générique, il peut être instruit pour “obtenir les niveaux de stock actuels pour l’Objet X” ou “calculer le score de risque pour le Fournisseur Y”. Chaque appel est auditable.
Les outils builder :
AIP Logic : workflows agentiques selon un framework Data-Logic-Action. Les trois couches sont découplées — on peut mettre à jour les règles métier sans toucher les pipelines ni les modèles
AIP Agent Studio : construction no-code/low-code d’agents LLM ancrés dans l’Ontologie
AIP Evals : framework d’évaluation intégré — cas de test, comparaison de LLMs, analyse de variance
AI FDE (bêta novembre 2025) : opérer Foundry en langage naturel — écrire des transforms, construire l’Ontologie, gérer des repos de code
AIP est multi-LLM par design : GPT-4, Claude, Gemini, et depuis le partenariat NVIDIA les modèles Nemotron. On peut changer de fournisseur sans reconstruire le pipeline applicatif.
Apollo — le CI/CD pour les environnements impossibles
Apollo est la couche la moins visible, probablement la plus différenciante. C’est le moteur de déploiement et de gestion du cycle de vie de toute la stack.
Son rôle : permettre des mises à jour continues et sécurisées même dans des environnements air-gapped, des réseaux fermés, des infrastructures hétérogènes — sans interrompre les opérations. C’est ce qui permet à Palantir de fonctionner dans des contextes militaires tout en maintenant un cycle de release moderne. Apollo orchestre le packaging, la release et le déploiement d’ensembles complets — pipelines, Ontologie, automations, applications — à travers des environnements cibles hétérogènes.
La gouvernance, nativement intégrée
La gouvernance n’est pas une feature qu’on a rajoutée après coup — elle est dans le modèle de données lui-même. L’Ontologie n’est pas seulement sémantique, elle est active : les Action Types capturent les décisions des opérateurs, les Functions encapsulent la logique métier. Chaque modification est tracée, chaque appel LLM génère une piste d’audit. Contrôle d’accès granulaire au niveau objet (pas juste table), chiffrement, auditing natif.
C’est d’ailleurs le principal argument commercial face aux data lakes mal gouvernés, et c’est un argument qui tient.
Le lock-in, assumé et structurel
C’est là que ça devient intéressant à analyser. L’architecture Palantir est propriétaire et fermée par design — ce n’est pas un accident, c’est un choix.
Les implications concrètes : plusieurs millions annuels pour les grandes entreprises, pas d’accès direct aux modèles sémantiques, pas d’export standard de l’Ontologie vers d’autres systèmes. Et surtout : une fois qu’une organisation structure ses données et ses flux autour de Foundry, c’est très difficile de revenir en arrière. C’est structurellement plus fort que du lock-in Salesforce ou SAP, parce qu’il s’applique à la couche décisionnelle elle-même.
Il y a aussi un paradoxe qu’on ne peut pas ignorer : Palantir se présente comme “explicable by design” — audit trails, gouvernance native. Mais les modèles internes, pipelines et règles de scoring restent opaques. Des chercheurs en éthique de l’IA parlent d’”effet boîte noire gouvernée”. La gouvernance porte sur qui a fait quoi, pas sur pourquoi le modèle a décidé ça.
Des alternatives open ou semi-open existent sur la partie ontologie sémantique (Timbr, AtomicData, standards Linked Data), mais aucune n’approche la maturité opérationnelle de Foundry + AIP dans les contextes complexes.
C’est ça, Palantir vu d’en bas : une architecture cohérente, construite sur une idée forte (l’Ontologie), avec un modèle économique qui assume totalement la dépendance qu’il crée. On reviendra bientôt sur l’ontologie tant ce concept peut être essentiel quand on s’attaque aux problématiques de data-management
Très intéressant.
Comment as tu trouvé ces informations ? Sur le site de Palantir ?