Résumé

  • L'affirmation technique durable de Palantir n'est pas que ses modèles sont intrinsèquement meilleurs que ceux des autres. C'est qu'une ontologie peut relier les données, la logique, les autorisations et les actions de manière suffisamment étroite pour que les organisations sensibles transforment des faits opérationnels désordonnés en décisions reproductibles.
  • Les preuves confirment un véritable point d'inflexion commercial: Palantir a annoncé un chiffre d'affaires de 1,633 milliard de dollars au T1 2026, une croissance de 85 % en glissement annuel et une expansion commerciale rapide aux États-Unis. Ces chiffres sont des résultats financiers du fournisseur, et non la preuve que chaque déploiement a couvert ses coûts de nettoyage des données, d'audit et d'adoption.
  • La limite du produit est importante. Palantir fournit Foundry, Gotham, AIP, des outils d'ontologie, des applications de workflow et des services déployés sur site; les clients restent propriétaires des données, des choix stratégiques, de l'autorité légale, du risque d'approvisionnement, des procédures opérationnelles et de nombreux modèles ou systèmes connectés.
  • La question non résolue est celle de la maintenance. Palantir gagne si ses clients peuvent maintenir à jour les ontologies, les contrôles d'accès, les journaux d'actions, les évaluations et les approbations humaines à mesure que les organisations, les modèles et les workflows évoluent. Il perd de la valeur lorsque les déploiements deviennent gourmands en services, politiquement contraints, difficiles à quitter, ou incapables de prouver que des décisions plus rapides étaient de meilleures décisions.

La promesse opérationnelle est une action gouvernée, pas une réponse plus intelligente

L'histoire de produit la plus importante de Palantir n'est pas celle d'un chatbot. Un chatbot peut répondre à une question tout en laissant l'organisation incapable d'agir. Un hôpital peut demander quelles salles d'opération seront disponibles la semaine prochaine, un fabricant peut demander quelle pénurie de pièces arrêtera une chaîne de montage, un état-major militaire peut demander quelles ressources peuvent être déplacées sans créer de nouvelle vulnérabilité, et une banque peut demander quelle revue client nécessite une escalade. Dans chaque cas, la partie coûteuse n'est pas seulement le classement des options. La partie coûteuse est de savoir quelles données font autorité, quelles personnes sont autorisées à les voir, quelles hypothèses sont actuelles, quel système en aval sera touché, et quel enregistrement subsistera lorsque la décision sera examinée ultérieurement.

C'est pourquoi la question assignée à Palantir devrait commencer par l'ontologie. Dans l'aperçu de l'architecture AIPde Palantir, l'ontologie est décrite comme la couche qui intègre les données, la logique, l'action et la sécurité en une représentation unifiée de la prise de décision d'entreprise. La même page d'architecture met l'accent sur l'observabilité des workflows pilotés par l'IA, y compris la surveillance des flux de données alimentant l'ontologie, la journalisation des actions entreprises par les utilisateurs humains ou les agents IA, le traçage des exécutions de workflows enchaînés et le suivi de l'utilisation des ressources. L'affirmation pratique est que l'IA opérationnelle doit se situer à l'intérieur d'un modèle opérationnel gouverné, et non à côté.

Cette distinction est facile à perdre dans le marché actuel de l'IA. Les fournisseurs de modèles peuvent améliorer le raisonnement, les fenêtres de contexte, les entrées multimodales et l'utilisation d'outils sans résoudre le problème d'autorité interne du client. Les fournisseurs cloud peuvent offrir des entrepôts de données solides, la recherche vectorielle, l'orchestration de workflows et des services d'hébergement de modèles sans garantir qu'une action opérationnelle particulière soit autorisée dans le langage de l'entreprise. Les intégrateurs de systèmes peuvent assembler des flux de données et des applications, mais le résultat peut devenir un projet local plutôt qu'une couche institutionnelle réutilisable. Le pari de Palantir est que de nombreuses grandes organisations souhaitent une couche normative qui cartographie leur monde en objets, relations, applications et actions, puis maintient cette carte suffisamment proche des opérations réelles pour être utile.

L'argument est convaincant lorsque le travail est répété, coûteux et à fort enjeu. Un simple tableau de bord peut montrer les expéditions en retard. Il ne peut pas, à lui seul, décider qui peut modifier la priorité d'une expédition, si une pièce de rechange est approuvée, si une promesse contractuelle rend un client plus urgent qu'un autre, ou pourquoi un responsable a contourné une recommandation automatisée. Le modèle d'ontologie et d'action de Palantir est conçu pour ce terrain plus lourd. C'est aussi là que réside le risque de l'entreprise, car plus une plateforme prétend encoder le sens et l'autorité, plus les dérives de l'ontologie, les autorisations périmées et les mauvaises correspondances de sources peuvent causer de dégâts.

Ce que Palantir est, et ce qu'il n'est pas

La limite de l'entreprise est importante car Palantir est souvent discuté comme s'il était synonyme des missions que ses clients exécutent. C'est trop large. Palantir vend et prend en charge des plateformes logicielles et des services de déploiement: Foundry pour l'intégration et les applications de données d'entreprise, Gotham pour les flux de travail de défense et de renseignement, AIP pour les flux de travail habilités par l'IA, et un ensemble plus large d'outils d'ontologie, d'action, d'évaluation, de création d'applications et d'intégration. Il fournit également une main-d'œuvre d'ingénierie déployée sur site et de mise en œuvre. Il n'est pas automatiquement propriétaire des données sous-jacentes des clients, de la base juridique d'un programme gouvernemental, des fournisseurs de modèles connectés à AIP, de l'infrastructure cloud sous chaque déploiement, ni de la décision opérationnelle qu'un client prend à l'intérieur du système.

La plateforme de données fédérée du NHS illustre cette limite. L'explication du contratdu NHS England indique qu'un consortium dirigé par Palantir a obtenu le contrat en novembre 2023, avec un financement pour jusqu'à 240 organisations du NHS sur une période possible de sept ans. Elle précise également que Palantir est un sous-traitant au sens de la législation sur la protection des données, que les organisations utilisatrices du NHS contrôlent l'accès à leurs propres instances de la plateforme, que la plateforme applique des contrôles d'accès basés sur les rôles et les finalités, et que les données personnelles dans la FDP et l'environnement technologique de protection de la vie privée sont stockées et traitées dans des centres de données au Royaume-Uni. L'explication ajoute en outre que Palantir ne peut pas commercialiser les données du NHS ni les utiliser pour développer de nouveaux produits fournisseurs, comme entraîner un modèle d'IA sur les données du NHS.

Ces déclarations contractuelles ne déterminent pas si le NHS devrait continuer à utiliser Palantir. Elles clarifient le cadre analytique. Si le système aide les patients à avancer plus rapidement dans les soins, Palantir peut affirmer que son logiciel a contribué à un meilleur flux de travail opérationnel. Si le système fait face à la méfiance du public, à des avantages contestés, à une mauvaise qualité des données ou à une décision politique de ne pas prolonger le contrat, l'environnement et les choix de gouvernance du client font partie du résultat. La même séparation s'applique dans les déploiements de défense et commerciaux. Le produit de Palantir peut rendre un flux de travail techniquement possible, mais le client fournit toujours l'autorité, la doctrine, la gouvernance des données, le comportement du personnel et la tolérance institutionnelle pour le résultat.

Cette limite joue dans les deux sens. Elle empêche les affirmations exagérées selon lesquelles Palantir aurait résolu un problème de service public ou militaire entier simplement en installant un logiciel. Elle empêche également de rejeter trop facilement l'entreprise comme un simple fournisseur de tableaux de bord. Le logiciel est conçu pour opérer à proximité du point où des données fragmentées deviennent une action autorisée. C'est une surface de produit plus lourde de conséquences que l'analyse ordinaire, et elle exige une norme de preuve plus stricte.

L'ontologie est un levier économique et une charge de maintenance

L'ontologie de Palantir est précieuse parce qu'elle peut transformer une intégration locale difficile en une couche opérationnelle réutilisable. Dans l'aperçu des types d'action de Foundry, une action est une transaction qui modifie les propriétés d'un objet, les liens ou les effets secondaires associés selon une logique définie par l'utilisateur. L'exemple est simple, mais le principe est large: un utilisateur autorisé devrait pouvoir effectuer une action métier en termes d'objectif métier plutôt qu'en éditant des lignes et des champs déconnectés. La documentation de Palantir indique que l'ontologie mappe les concepts aux données réelles d'une organisation et peut capturer les décisions des utilisateurs sous forme de modifications qui refluent vers les applications destinées aux utilisateurs.

C'est le levier. Si une compagnie aérienne, un hôpital, une usine ou un commandement militaire peut définir un vocabulaire d'objets communs et exposer des actions gouvernées par-dessus, les applications deviennent plus faciles à réutiliser. Un planificateur de maintenance, un responsable des opérations, un analyste et un examinateur de conformité peuvent travailler à partir de la même représentation structurée au lieu de réconcilier des feuilles de calcul, des tickets et des tableaux de bord locaux. De nouvelles capacités d'IA peuvent être attachées à la même couche de contexte. C'est pourquoi l'ontologie est au cœur de l'argumentaire commercial de Palantir: la plateforme n'est pas seulement un lieu de stockage des données, mais un lieu d'encodage du sens institutionnel.

C'est aussi la charge. Le sens change. Les départements se réorganisent. Les chaînes d'approvisionnement évoluent. Les parcours cliniques changent. La doctrine militaire évolue. Les régulateurs modifient les attentes en matière de reporting. Un modèle qui était utile dans un flux de travail devient peu fiable dans un autre. Un champ qui pouvait être exposé en toute sécurité à une équipe devient sensible après une fusion ou un changement de politique. Si l'ontologie ne change pas avec l'institution, les utilisateurs la contourneront. Si elle change sans discipline, les utilisateurs cesseront de lui faire confiance. Palantir doit donc gagner le long jeu de la maintenance, et pas seulement la démonstration initiale.

Le mode de défaillance n'est pas spectaculaire. Il peut s'agir d'une correspondance obsolète d'un système source. Il peut s'agir d'une propriété qui semble précise mais qui est renseignée différemment par deux sites. Il peut s'agir d'une autorisation qui reflète la structure d'équipe de l'année précédente. Il peut s'agir d'une action de workflow dont l'effet secondaire n'est plus accepté par un système externe. Il peut s'agir d'un assistant IA récupérant des objets techniquement pertinents mais opérationnellement obsolètes. Des mois plus tard, l'organisation peut encore avoir une plateforme impressionnante et une réponse faible à la question centrale: pourquoi cette action était-elle légitime?

Les autorisations ne sont pas une enveloppe

La gestion des autorisations est l'un des endroits où la documentation publique de Palantir montre pourquoi le produit est plus qu'une simple interface de modèle. L'aperçu des autorisations d'objetssépare les ressources de l'ontologie, telles que les types d'objets, les types de liens et les types d'actions, des données elles-mêmes, ce qui signifie que la couche de définition des ressources et les instances d'objets réelles posent des questions de sécurité différentes. La documentation sur lesautorisations d'ontologieindique que les ressources d'ontologie sont gérées par le biais de projets, et qu'un utilisateur peut avoir l'autorisation de voir un type d'objet sans nécessairement avoir l'autorisation de voir les données d'objet sous-jacentes. La même page note que la visualisation d'objets réels nécessite également l'accès aux données via la configuration de sécurité de l'objet.

La page sur lagestion de la sécurité des objetsva plus loin, en décrivant les politiques de sécurité des objets et des propriétés qui peuvent définir des autorisations de visualisation sur les instances d'objets et les propriétés individuelles, y compris des contrôles au niveau des lignes, des colonnes et des cellules. Elle avertit également que certaines valeurs de propriétés peuvent faire référence à des ressources extérieures à l'ontologie, telles que des médias stockés dans un ensemble de médias, et que les autorisations sur ces ressources externes doivent être configurées séparément. Cette mise en garde est importante. Elle montre le genre de cas limite qui peut ruiner une histoire de gouvernance propre: un utilisateur peut être bloqué d'une propriété mais toujours capable de récupérer un actif référencé si la ressource sous-jacente est moins restrictive.

C'est là que la force du produit de Palantir et la charge du client se rencontrent. Les contrôles granulaires ne sont utiles que si l'organisation sait ce qui doit être protégé, maintient les groupes d'identité à jour, comprend où le lignage des données modifie l'accès et audite les exceptions. Palantir peut fournir la machinerie. Il ne peut pas, à lui seul, décider quelle infirmière, analyste, ingénieur, entrepreneur, commandant, auditeur ou application devrait être autorisé à voir chaque élément de données dans chaque circonstance. Cette décision appartient au client et doit être maintenue à mesure que l'organisation évolue.

La même chose s'applique à la couche d'application. La documentation sur lesautorisations Workshopde Palantir indique que l'autorisation d'ouvrir ou de modifier un module est distincte de l'autorisation d'accéder aux données, aux actions ou aux fonctions à l'intérieur de ce module. Sa documentation sur lesautorisations des types d'actionindique que l'application d'une action dépend des types d'objets et de liens en cours d'édition, de la capacité de l'utilisateur à voir les ressources et les sources de données modifiées, et de tout critère de soumission. Ces détails sont importants parce que les opérations réelles échouent rarement à une seule couche. Un workflow peut sembler disponible alors que l'action sous-jacente ne l'est pas; un utilisateur peut modifier un module sans pouvoir voir les données nécessaires pour l'utiliser; une personne peut être autorisée à voir un enregistrement mais pas à effectuer l'action qui le modifie.

La traçabilité doit survivre au travail normal

La documentation d'audit publique de Palantir est inhabituellement explicite sur le compromis pratique dans les systèmes d'audit. L'aperçu des journaux d'auditdécrit les journaux d'audit comme un enregistrement complet des actions dans Foundry, mais aussi comme un enregistrement distillé où une verbosité excessive peut rendre les journaux plus difficiles à raisonner. Il indique que les journaux d'audit répondent à qui a effectué une action, quelle action a eu lieu, quand elle s'est produite et où elle s'est produite, tout en avertissant que les journaux d'audit peuvent contenir des informations sensibles et peuvent devoir être analysés dans le propre système de surveillance de la sécurité d'un client.

Ce cadrage est utile. Une plateforme qui enregistre tout sans aider les enquêteurs à raisonner à ce sujet peut encore échouer à un audit. La page sur lescatégories de journaux d'auditde Palantir décrit des catégories qui permettent aux analystes d'interroger des actions de haut niveau telles que le chargement de données, l'exportation ou les tentatives d'authentification sans suivre chaque nom d'événement spécifique au service. Cette abstraction est précieuse parce que les noms de service changent et que de nouvelles fonctionnalités apparaissent. C'est aussi un rappel que la traçabilité est un objectif de conception, pas un sous-produit naturel de l'utilisation de l'IA.

La journalisation des actions est plus proche du cœur opérationnel du produit. La documentation sur lejournal d'actionindique que les types d'objets du journal d'action modélisent les soumissions en tant qu'objets d'ontologie afin qu'ils puissent être analysés et affichés dans les outils conscients des objets. Une action soumise peut produire un objet journal lié à tous les objets modifiés et peut stocker des métadonnées telles que les identifiants de l'action, la version du type d'action, l'horodatage, l'ID utilisateur, les objets modifiés et les valeurs des paramètres. La page cadre explicitement la chronologie autour des questions « qu'est-ce qui a changé, par qui et quand? »

Ces mécanismes sont exactement ce dont une organisation réglementée a besoin si une action doit être contestée ultérieurement. Pourtant, la partie difficile n'est pas l'existence d'une fonction de journalisation. La partie difficile est de s'assurer que l'action elle-même était bien définie, que le contexte pertinent a été stocké, que les bons utilisateurs étaient tenus d'approuver, que les données sources étaient à jour, que le système en aval a reçu le changement prévu, et que la piste d'audit reste interprétable après que le type d'action a été révisé. Un enregistrement d'audit qui dit que le mauvais utilisateur autorisé a pris une action mal spécifiée n'est pas un contrôle réussi. C'est un enregistrement propre d'un processus faible.

AIP déplace le point de défaillance de la prédiction au contrôle des changements

AIP donne à Palantir un moyen d'attacher de grands modèles de langage et d'autres capacités d'IA à la couche d'ontologie et d'application. L'aperçu d'AIPindique qu'AIP fournit des pistes d'audit, des explications et des évaluations pour les décisions des modèles, la disponibilité des fonctionnalités étant soumise à des différences entre les clients. La documentation surl'éthique et la gouvernance de l'IAmet l'accent sur le support décisionnel basé sur l'ontologie, les flux de travail de supervision humaine, les processus d'approbation, les boucles de rétroaction, les points de contrôle et les mécanismes de repli. L'aperçu des évaluations AIPprésente les évaluations comme un environnement de test pour les fonctions AIP Logic, les fonctions chatbot et les fonctions codées par du code, conçu pour gérer la nature non déterministe des LLM en comparant les sorties à des cas de test et à des versions antérieures.

C'est la bonne direction pour l'IA opérationnelle. La réponse d'un modèle n'est pas assez stable pour qu'on lui fasse confiance simplement parce qu'elle semblait plausible. Si le modèle doit recommander des actions, produire des brouillons, trier le travail ou appeler des outils, l'organisation a besoin de cas de test, de fonctions d'évaluation, de vérifications de variance, de comparaisons de versions, de points d'approbation et d'un comportement de retour en arrière. La documentation de Palantir reconnaît que les flux de travail d'IA en production nécessitent ces contrôles.

Mais l'existence des évaluations AIP ne prouve pas que le flux de travail de production d'un client est fiable. Une suite d'évaluation ne vaut que ce que valent ses cas de test et ses seuils d'échec. Une étape d'approbation humaine n'est aussi solide que l'expertise, le temps et les incitations du réviseur. Une boucle de rétroaction peut améliorer un flux de travail ou verrouiller un comportement local biaisé. Un mécanisme de repli peut préserver la capacité d'action humaine ou devenir une échappatoire rarement utilisée. Palantir peut fournir un environnement où ces contrôles sont plus faciles à construire; l'organisation doit encore choisir et maintenir les contrôles qui correspondent aux conséquences de l'action.

Le même risque apparaît dans la récupération et les connexions à des outils externes. La documentation sur lecontexte de récupérationde Palantir indique que les chatbots AIP peuvent inclure un contexte basé sur l'ontologie, des documents et des fonctions, exécuté de manière déterministe à chaque nouveau message de l'utilisateur. Son annonce de documentation de mai 2026 pourOntology MCPindique que les agents IA externes peuvent se connecter en tant que clients MCP pour lire les types d'objets, exécuter des types d'actions prédéfinies et exécuter des fonctions de requête dans le cadre des autorisations configurées. Ces capacités pourraient rendre les agents IA plus utiles sur le plan opérationnel. Elles élargissent également la surface de contrôle. Si un agent externe peut voir les types d'objets et exécuter des actions prédéfinies, la portée des autorisations, les descriptions des outils, les exigences d'approbation et la surveillance font partie de l'histoire de la fiabilité du produit.

En d'autres termes, AIP n'élimine pas le problème de l'ontologie. Cela augmente le gain à le résoudre et augmente le coût de se tromper.

Les preuves clients montrent pourquoi le dénominateur est important

Les preuves clients publiques sont suffisamment solides pour montrer la demande, mais pas assez pour déterminer le retour sur investissement de chaque déploiement. L'annonce de juillet 2025 de l'accord de service d'entreprisede l'US Army indique que l'armée a consolidé 75 contrats, y compris 15 contrats principaux et 60 contrats connexes, en un seul accord d'une valeur maximale potentielle de 10 milliards de dollars sur une période pouvant aller jusqu'à 10 ans. La même annonce précise que ce montant est une valeur maximale potentielle, et non une obligation ou un engagement spécifique. Cette réserve n'est pas une note de bas de page. Elle est essentielle pour évaluer l'économie de Palantir. Un plafond élevé montre une voie d'approvisionnement et une confiance institutionnelle, mais la valeur réalisée dépend des commandes, de l'adoption, de l'exécution du contrat et du coût de la mise en œuvre.

Les preuves du Maven Smart System vont dans le même sens. L'annonce de contratdu Département de la Défense de mai 2024 indique que Palantir USG a reçu un contrat à prix fixe ferme de 480 millions de dollars pour le prototype Maven Smart System, les lieux de travail et le financement étant déterminés par commande. Breaking Defense a rapporté que le nouveau contrat visait à étendre l'accès à Maven de centaines d'utilisateurs à des milliers, et a cité Palantir décrivant la nécessité d'intégrer les systèmes de données et de nouvelles capacités d'IA. La phrase la plus révélatrice de ce rapport n'est pas l'expansion du nombre d'utilisateurs. C'est la description du travail fastidieux sous-jacent: obtenir l'accès aux ensembles de données, nettoyer les erreurs et les artefacts, reformater les données et construire des flux de données durables. C'est le dénominateur. Plus la mission est précieuse, plus le travail préparatoire sur les données devient coûteux.

DefenseScoop a rapporté plus tard que les dirigeants du Pentagone ont augmenté le plafond du contrat Maven de 795 millions de dollars pour le porter à près de 1,3 milliard de dollars jusqu'en 2029, citant une demande croissante des commandements combattants, tout en notant des questions sans réponse sur les plans de déploiement et l'expansion du nombre d'utilisateurs. Pour Palantir, c'est une preuve commercialement attrayante de la demande de défense. Pour les évaluateurs, c'est aussi un rappel que la croissance de la capacité de licence et des plafonds contractuels ne divulgue pas la qualité opérationnelle de chaque flux de travail, la doctrine entourant les décisions assistées par l'IA, ou la charge de formation des utilisateurs.

Le secteur de la santé est encore plus sensible parce que la confiance du public fait partie du système opérationnel. L'explication du NHS England présente la FDP comme une plateforme gouvernée avec un contrôle d'accès local, un traitement au Royaume-Uni et des mécanismes de révision des contrats. Le Guardian, dans un rapport de juillet 2026 sur l'examen parlementaire, a décrit des appels transpartisans à abandonner le contrat NHS avec Palantir, citant la méfiance du public et médicale, des avantages contestés, des préoccupations en matière de confidentialité et la disponibilité d'alternatives. Palantir et les responsables britanniques ont cité des avantages opérationnels, notamment des opérations supplémentaires et une réduction des retards, tandis que les critiques ont remis en question les preuves et l'adéquation institutionnelle. Les faits ne se réduisent pas à « le logiciel fonctionne » ou « le logiciel échoue ». Ils montrent que la proposition de valeur de Palantir est indissociable de la légitimité, de la gouvernance des données et de la capacité du client à prouver les avantages de manière crédible.

La courbe financière est réelle, mais pas la même chose que la preuve de résultats reproductibles

La croissance de Palantir donne à l'entreprise la possibilité de faire valoir que le marché valide son modèle opérationnel. Dans soncommuniqué de presse sur les résultats du T1 2026, Palantir a annoncé un chiffre d'affaires de 1,633 milliard de dollars, en hausse de 85 % en glissement annuel et de 16 % par rapport au trimestre précédent. Le chiffre d'affaires aux États-Unis a augmenté de 104 % en glissement annuel pour atteindre 1,282 milliard de dollars. Le chiffre d'affaires commercial aux États-Unis a augmenté de 133 % en glissement annuel pour atteindre 595 millions de dollars, et le chiffre d'affaires gouvernemental aux États-Unis a augmenté de 84 % en glissement annuel pour atteindre 687 millions de dollars. L'entreprise a également déclaré avoir conclu 206 transactions d'au moins 1 million de dollars, 72 transactions d'au moins 5 millions de dollars et 47 transactions d'au moins 10 millions de dollars.

Leformulaire 10-Q du T1 2026ajoute une texture utile. Le chiffre d'affaires gouvernemental était de 858 millions de dollars et le chiffre d'affaires commercial de 774 millions de dollars pour le trimestre, le chiffre d'affaires total étant en hausse de 85 % par rapport au T1 2025. Palantir a déclaré une marge brute de 87 % pour le trimestre, contre 80 % un an plus tôt, même si le coût des revenus a augmenté en partie à cause des services d'hébergement cloud de tiers. L'entreprise a également déclaré 8,0 milliards de dollars de trésorerie, d'équivalents de trésorerie et de titres du Trésor américain à court terme au 31 mars 2026, aucun solde de dette en cours et 899 millions de dollars de flux de trésorerie d'exploitation pour le trimestre.

Ce sont des états financiers solides pour une entreprise de logiciels. Ils ne répondent pas à la question de la qualité du déploiement. Une marge brute élevée peut coexister avec des coûts de mise en œuvre élevés du côté du client. Une croissance commerciale rapide aux États-Unis peut coexister avec des résultats inégaux selon les secteurs. Un grand nombre de transactions importantes peut inclure des extensions, des pilotes, des véhicules d'approvisionnement et des engagements pluriannuels avec des profils de risque différents. Les états financiers prouvent que Palantir a trouvé une demande et une monétisation à grande échelle. Ils ne prouvent pas que chaque ontologie reste précise, que chaque action reste traçable, que chaque utilisateur adopte le flux de travail ou que chaque client bat le coût total des substituts.

Le rapport annuel maintient cette distinction visible. Dans sonformulaire 10-K de 2025, Palantir a déclaré une valeur de transaction restante totale de 11,2 milliards de dollars au 31 décembre 2025, dont 6,8 milliards de dollars provenant de clients commerciaux et 4,4 milliards de dollars de clients gouvernementaux. L'entreprise a également indiqué que de nombreux contrats sont soumis à des dispositions de résiliation, y compris la résiliation pour convenance, et que les options des contrats du gouvernement fédéral américain ne peuvent être exercées plus d'un an à l'avance. Palantir a également déclaré avoir obtenu des contrats IDIQ totalisant 12,3 milliards de dollars qui ont été exclus de la valeur de transaction restante parce que le financement n'était pas déterminé ou garanti.

Ce langage est important parce que la question commerciale de Palantir n'est pas « les clients sont-ils intéressés? ». La réponse est clairement oui. La question est de savoir si des décisions opérationnelles plus rapides et des applications réutilisables dépassent les coûts d'ingénierie déployée, de nettoyage des données, de maintenance de l'ontologie, d'approvisionnement, de licence, d'examen des modèles et de changement au fil du temps. La réponse peut être oui dans de nombreux contextes à haute valeur ajoutée. Elle doit encore être méritée déploiement par déploiement.

La main-d'œuvre de services fait partie du produit, même lorsque la marge ressemble à celle d'un logiciel

Le modèle de déploiement sur site de Palantir est une force parce que les clients cibles de l'entreprise sont difficiles à servir avec un logiciel en libre-service uniquement. Les organisations sensibles ont des systèmes hérités, des définitions de données inhabituelles, des environnements classifiés ou réglementés, des parties prenantes politiques, des contraintes de sécurité et des experts du domaine qui ne parlent pas en tables de base de données. Un mouvement générique de croissance axée sur le produit ne suffit pas. Quelqu'un doit comprendre le problème opérationnel, cartographier les données, construire l'ontologie, concevoir des actions, connecter les applications, gérer les autorisations et persuader les utilisateurs de changer leurs routines.

Ce travail peut créer un fossé. Une ontologie bien construite intègre la connaissance du client d'une manière qu'il est difficile pour les concurrents de déplacer rapidement. Les applications construites par-dessus peuvent devenir réutilisables. Si les ingénieurs de Palantir aident un client à passer d'un tableau de bord ponctuel à un modèle opérationnel gouverné, le client peut s'étendre plutôt que de changer. L'expansion du chiffre d'affaires du T1 provenant des clients existants, décrite dans le 10-Q comme l'adoption de produits et services au sein des organisations, est cohérente avec ce schéma.

Cela peut aussi devenir un frein. Si chaque déploiement à haute valeur ajoutée nécessite une ingénierie sur mesure, des ateliers clients, une remédiation des données, des débats de gouvernance locaux et une maintenance continue, la plateforme peut ressembler à un logiciel dans le compte de résultat de Palantir mais être lourde en services dans le coût réel du client. Cela n'en fait pas une mauvaise affaire. Cela rend le dénominateur plus grand. Un fabricant peut économiser suffisamment grâce à moins d'arrêts de ligne pour le justifier. Un hôpital peut économiser suffisamment de capacité si les flux de travail de planification et de sortie s'améliorent réellement. Une agence de défense peut justifier le coût si la fusion de données modifie le tempo opérationnel. Mais la valeur doit être mesurée par rapport au coût total du programme, et pas seulement au prix de la licence.

C'est là que la rhétorique de l'entreprise sur les logiciels « porteurs » devrait être testée. Les systèmes porteurs ne sont pas jugés par des démonstrations. Ils sont jugés par une fiabilité ennuyeuse: des transferts qui fonctionnent, des exceptions qui sont visibles, des autorisations qui se mettent à jour, des actions qui sont journalisées, des utilisateurs qui ne gardent pas de feuilles de calcul parallèles et des chemins de récupération qui sont pratiqués. La documentation de Palantir elle-même indique bon nombre de ces contrôles. Les preuves publiques montrent rarement si les clients les maintiennent bien.

La souveraineté des données est une fonctionnalité du produit seulement si toute la chaîne la respecte

Le sujet assigné inclut la souveraineté et la localité des données, et la base de clients de Palantir rend cela inévitable. Les systèmes de santé, les agences de défense et les industries critiques ne peuvent pas traiter les flux de travail d'IA comme des fonctionnalités cloud génériques. Ils doivent savoir où les données sont stockées, qui peut y accéder, quelle juridiction légale s'applique, si les fournisseurs peuvent réutiliser les données et comment les attributs sensibles se déplacent dans le système.

L'explication du contrat du NHS fournit un exemple public: stockage et traitement uniquement au Royaume-Uni pour les données personnelles dans l'environnement FDP et de technologie de protection de la vie privée, limites contractuelles sur l'utilisation des données du NHS par Palantir et contrôle local par les organisations utilisatrices du NHS. La documentation sur la sécurité des objets de Palantir fournit un exemple côté produit: politiques d'objets et de propriétés, politiques de source de données et avertissements concernant les ressources externes référencées. La documentation sur l'architecture AIP ajoute l'idée que l'intégration des données, les garanties de sécurité et de provenance doivent rester cohérentes entre les modes batch, streaming et temps réel.

Le risque est que la souveraineté puisse être réduite à une revendication d'hébergement. L'emplacement de l'hébergement est important, mais ce n'est pas toute la chaîne de contrôle. Un flux de travail peut encore exposer des données via une application mal configurée, un jeu de données dérivé, une référence média, une action permissive, une instruction de modèle, un chemin d'exportation, un outil externe ou un processus humain en dehors de la plateforme. Un client peut également se conformer aux règles de localité des données et quand même perdre la confiance du public si les gens pensent que le fournisseur ou le programme gouvernemental est inapproprié. L'avantage de Palantir sur les marchés sensibles dépend de la capacité à rendre la gouvernance lisible à la fois pour les administrateurs techniques et les parties prenantes institutionnelles.

L'annonce d'Ontology MCP de mai 2026 accentue ce point. Les agents IA externes peuvent être utiles s'ils fonctionnent via des outils limités et des actions prédéfinies. Ils peuvent également créer de nouvelles questions de gouvernance parce que la frontière entre l'application interne, l'agent externe et l'action opérationnelle devient plus complexe. La question pertinente n'est pas de savoir si MCP est moderne. C'est de savoir si l'organisation peut prouver exactement ce qu'un agent pourrait voir, ce qu'il pourrait faire, quelles approbations étaient requises, quels journaux ont été produits et quels contrôles échoueraient en position fermée.

Les substituts s'améliorent, mais ils résolvent un premier problème différent

Palantir n'est pas seulement en concurrence avec une seule entreprise. Il est en concurrence avec les équipes internes de plateformes de données, les piles d'IA cloud, les logiciels de workflow, les intégrateurs de systèmes, les entrepreneurs de défense, les plateformes d'analyse, les entrepôts de données, les lakehouses et la décision de ne rien faire. Chaque substitut part d'un postulat différent. Un fournisseur cloud peut partir de l'infrastructure et de l'accès aux modèles. Un fournisseur de lakehouse peut partir de données et d'analyses gouvernées. Un fournisseur de workflow peut partir de l'automatisation des processus métier. Un intégrateur de systèmes peut partir d'une livraison personnalisée. Une équipe interne peut partir de la connaissance institutionnelle et d'un moindre verrouillage fournisseur.

L'avantage de Palantir est l'intégration de ces préoccupations autour de l'action opérationnelle. Si le client a principalement besoin de stockage, de reporting ou d'hébergement de modèles, Palantir peut sembler lourd et coûteux. Si le client a besoin de joindre des données désordonnées à l'autorité, au flux de travail, à la journalisation des actions et à des applications spécifiques au domaine, le poids de Palantir peut devenir le point. L'entreprise est la plus forte là où les décisions sont répétées, interfonctionnelles, sensibles et suffisamment coûteuses pour que la charge de maintenance de l'ontologie soit justifiée.

La question du verrouillage suit naturellement. L'ontologie, les actions, les applications et les routines d'exploitation d'un client peuvent devenir profondément liées à Palantir. Cela peut être acceptable si la plateforme devient une couche opérationnelle durable et que l'économie du contrat reste raisonnable. Cela devient un risque si un client ne peut pas déplacer les flux de travail, l'historique d'audit, la logique métier ou les modèles de domaine sans des coûts de changement élevés. L'explication du NHS England note que le NHS est propriétaire du modèle de données canonique commandé et des produits ou composants construits, tandis que Palantir conserve les droits sur Foundry lui-même. Cette distinction est importante, mais la sortie pratique dépend de plus que du langage de la propriété intellectuelle. Elle dépend de la documentation, de l'exportation des données, de la portabilité des processus, des compétences du personnel et des remplacements disponibles.

C'est aussi pourquoi un déploiement Palantir devrait être audité comme un modèle opérationnel vivant plutôt que comme une installation logicielle terminée. Le dossier de preuves renvoie à des pages d'évaluation, des pages de documentation d'action, du matériel produit AIP, des divulgations clients et des explications de contrôle du secteur public, mais ces sources décrivent principalement les mécanismes et certains résultats. Un acheteur doit encore échantillonner le travail ordinaire après la mise en service: qui a modifié un groupe d'autorisations, quel champ source a alimenté une action, quelle évaluation a couvert un flux de travail révisé, comment une recommandation rejetée a été enregistrée et si les utilisateurs de première ligne peuvent expliquer la règle qu'ils appliquent. Ces échantillons banals sont l'endroit où une plateforme d'exploitation gagne soit la confiance, soit devient opaque.

Les preuves qui changeraient le jugement

Les preuves publiques soutiennent une thèse limitée: Palantir a construit une plateforme d'exploitation sérieuse pour le travail de données à action à enjeux élevés, et les clients l'achètent à une échelle croissante. Les mêmes preuves ne prouvent pas que la plateforme passe systématiquement ses tests de maintenance les plus difficiles. Pour changer le jugement de manière décisive, les observateurs extérieurs auraient besoin de plus de preuves au niveau du déploiement.

Premièrement, ils auraient besoin de mesures avant-après liées aux dénominateurs: temps de cycle, taux d'erreur, coût de service, heures du personnel, temps de récupération, constatations d'audit, adoption par les utilisateurs et volume d'exceptions, pas seulement des anecdotes ou des décomptes d'activité brute. Deuxièmement, ils auraient besoin de preuves que les flux de travail habilités par l'IA sont évalués dans des cas limites réalistes, avec une couverture de test mise à jour après les changements de modèle, de données et de workflow. Troisièmement, ils auraient besoin de preuves que les changements d'autorisations, les changements organisationnels et les changements de systèmes sources sont rapidement reflétés dans l'ontologie et les applications en aval. Quatrièmement, ils auraient besoin d'échantillons d'audit montrant que les enregistrements d'action restent interprétables après les révisions de type d'action et les changements de système. Cinquièmement, ils auraient besoin de preuves crédibles de sortie et de portabilité, en particulier pour les déploiements du secteur public où le contrôle démocratique et la confiance du public font partie de l'exigence opérationnelle.

Une partie de ces preuves ne sera jamais publique parce que Palantir travaille dans des environnements sensibles. Cette limitation ne doit pas être utilisée pour présumer l'échec. Elle ne doit pas non plus être utilisée pour accepter les affirmations du fournisseur sans critique. Dans les marchés sensibles, l'opacité est parfois nécessaire, mais elle élève la barre pour la gouvernance indépendante, la surveillance des clients et les affirmations publiques étroites.

La lecture la plus prudente est que la technologie de Palantir est bien adaptée au problème qu'elle prétend résoudre, tandis que le coût et la fiabilité réels de chaque déploiement restent spécifiques au client. L'entreprise a des documents d'architecture solides, une base de revenus à croissance rapide, des engagements clients publics et des primitives de produit crédibles pour la traçabilité, les autorisations, les actions et les évaluations. Le risque non résolu est de savoir si ces primitives restent disciplinées après que l'équipe de déploiement initiale est partie, que l'organisation cliente change et que la couche d'IA devient plus agentique.

En résumé

Le problème difficile de Palantir n'est pas de générer une réponse. Le marché a de nombreuses façons de générer des réponses. Le problème difficile de Palantir est de maintenir une représentation opérationnelle du client véridique, autorisée et révisable longtemps après le premier flux de travail réussi. Cela signifie maintenir l'ontologie, le lignage des données, la sécurité des objets, les définitions d'action, les approbations humaines, les évaluations, les journaux d'audit et le comportement des utilisateurs à mesure que l'institution change.

Si Palantir peut le faire de manière répétée, ses produits deviennent une catégorie rare d'infrastructure d'entreprise: un logiciel qui convertit des données fragmentées en actions gouvernées pour les organisations qui ne peuvent pas se permettre une automatisation négligente. S'il ne le peut pas, la même architecture devient une source de dépendance fragile, de coût de changement élevé et d'exposition politique. Les preuves à ce jour incitent à prendre Palantir au sérieux, mais pas à accepter ses affirmations les plus fortes sur la foi. Le test approprié est de savoir si l'action peut encore être expliquée des mois plus tard, après que le modèle a changé, que les autorisations ont changé, que le flux de travail a changé et que l'institution doit encore assumer la décision.