Un diagnostic qui commence à s'entendre

En juillet 2026, sur CNBC, Alex Karp, CEO de Palantir, a résumé sans détour ce que beaucoup de dirigeants pensent tout bas. Les grands fournisseurs de LLM facturent aux entreprises « des tokens qui ne créent aucune valeur », pendant que leurs prompts, leurs workflows et leur connaissance métier alimentent, à bas bruit, les modèles qui leur sont ensuite revendus. Karp parle d'une taxe implicite prélevée sur la richesse des entreprises, et n'hésite pas à parler de colonisation pour décrire ce rapport où l'utilisateur paie pour être capté.

Le vocabulaire est volontairement provocateur. Il exprime une inquiétude qui monte silencieusement dans les COMEX : à mesure que l'IA s'installe dans les process, la question n'est plus « est-ce que ça marche », mais « à qui laisse-t-on accès à ce qui fait la valeur de notre entreprise ».

Trois angles convergents

Sur l'économie du marché. La facturation à l'usage traduit un état de maturité où la valeur créée par tâche reste variable, non contractualisable, et souvent invérifiable. Un fournisseur qui pouvait facturer sur du résultat le ferait déjà. Ce que la facturation au token révèle, ce n'est pas un scandale, c'est un stade. Mais c'est un stade où les coûts scalent linéairement avec l'usage, sans aucune assurance de contrepartie mesurable. Un marché mûr aurait vu émerger des modèles de rémunération alternatifs, adossés à des indicateurs de valeur mesurés (taux d'automatisation, temps d'attente évité, dispatch libéré) plutôt qu'à des jetons consommés. Leur quasi-absence dans le catalogue des grands fournisseurs est en soi révélatrice.

Sur la circulation de la connaissance. Indépendamment des conditions générales du moment, qui varient d'un fournisseur à l'autre et changent régulièrement, la concentration progressive de la connaissance métier d'une entreprise chez un fournisseur unique constitue un risque stratégique en soi. Les CGV se modifient, les capacités techniques évoluent, les modes d'apprentissage aussi. Le seul actif qu'un dirigeant industriel contrôle vraiment est l'endroit où sa donnée réside.

Sur la prochaine frontière de la conformité IA en industrie. Les projets IA industriels sont aujourd'hui bien encadrés côté conformité messagerie et hébergement des données utilisateurs. Le même niveau d'exigence appliqué aux modèles eux-mêmes (leur localisation, leur politique d'entraînement, ce qui sort de l'entreprise à chaque appel) ferait progresser le débat d'un cran. C'est probablement la prochaine frontière de la conformité IA en industrie.

Les cinq exigences d'une architecture souveraine et spécialisée

Pour un industriel qui veut construire son socle IA sans se retrouver captif, cinq exigences se dégagent.

Multi-modèles par conception. L'architecture doit pouvoir appeler différents LLM selon la nature de la tâche, sa sensibilité, et son coût marginal. Un modèle cloud pour ce qui est banal et lourd à faire tourner localement, un modèle open source en local pour ce qui touche à la donnée sensible ou récurrente. Le choix se fait tâche par tâche, jamais une fois pour toutes. La dépendance à un fournisseur unique se paye tôt ou tard.

Calibrage pour les profils opérationnels. Une architecture pertinente pour l'industrie n'est pas la même que celle qui sert un cadre au bureau ou un développeur. Un chef d'exploitation, un conducteur ou un opérateur de site ne se connectera pas à une interface conversationnelle générique pour piloter son activité. Il attend un canal qu'il utilise déjà, une réponse dans son langage métier, et une action déclenchée sans détour. Ce niveau d'adéquation demande un vrai travail de calibrage : dimensionnement du modèle en face de chaque tâche, coût par interaction compatible avec un usage terrain intensif, connecteurs sur mesure vers les systèmes existants. Les assistants grand public d'IA générative, remarquables sur leur cible, ne sont pas conçus pour ce contexte.

Ontologie construite avec le client, pas imposée par un catalogue. Le savoir métier d'un opérateur de flotte, d'un exploitant de carrière ou d'un producteur industriel n'est pas générique. Il se construit avec ses équipes, ses données, ses règles, dans son langage. C'est le rôle d'ingénieurs déployés au contact du métier, pas d'un déploiement à distance ni d'un catalogue de templates prêts à l'emploi. Cette méthode a un nom dans l'écosystème, forward-deployed engineering, et elle est aujourd'hui le seul chemin crédible vers un système IA qui tient en production dans l'industrie.

Frugalité radicale dans le contexte transmis. À aucun moment l'intégralité de l'ontologie ne doit être exposée à un modèle externe. Pour chaque appel, l'architecture extrait précisément ce qui est nécessaire, et pas une ligne de plus. Cette discipline coûte du design en amont. Elle protège durablement le knowledge stratégique.

Résidence maîtrisée des données transactionnelles. Les ordres de travail, les conversations, les décisions historiques doivent résider chez l'entreprise ou chez un opérateur européen identifié, dans une juridiction connue. Un opérateur peut accepter d'utiliser un modèle américain pour reformuler du texte général. Il ne devrait jamais accepter que son historique d'interventions parte, brut, chez un fournisseur dont la politique d'usage peut changer sans préavis.

Les prérequis

Cette architecture ne s'achète pas sur étagère. Elle se construit avec un partenaire qui comprend à la fois le métier, l'ontologie, et le paysage IA au bon niveau technique. Elle relève d'un choix stratégique de dirigeant, pas d'un ticket adressé à la DSI. Elle demande plus d'effort qu'un déploiement générique en trois clics. Elle rend, en échange, un niveau de souveraineté et de résilience qu'aucune plateforme unique ne peut apporter.

Le vrai débat qui vient ne sera pas « faut-il utiliser l'IA ». Il sera « avec qui, et pour quel résultat ».