Jean Umani

La gueule de bois

Sur les entreprises qui achètent de l'IA et celles qui la construisent
Mars 2026

Alex Karp est le PDG de Palantir, une entreprise qui construit des systèmes d'intelligence artificielle pour l'armée américaine, les services de renseignement, et les grandes entreprises industrielles. Ce n'est pas un vendeur de logiciels. C'est quelqu'un qui déploie de l'IA dans des contextes où les erreurs tuent des gens. Quand il parle de technologie, il parle depuis un endroit où les conséquences sont réelles.

Cette semaine, Karp a dit quelque chose qui mérite qu'on s'y arrête. En substance : "L'approche générale qui consiste à acheter des modèles, c'est essentiellement de la masturbation d'entreprise, aux frais de l'entreprise." Puis : "Vous achetez un grand modèle de langage, vous faites la fête avec, et le lendemain vous avez la gueule de bois."

La métaphore est crue. Elle est aussi parfaitement exacte.

· · ·

Ce que Karp décrit, c'est le comportement de la quasi-totalité des entreprises du Fortune 500 face à l'intelligence artificielle en 2026. Le schéma est le suivant : le comité de direction décide qu'il faut "faire de l'IA". Un budget est alloué. Des abonnements sont souscrits : ChatGPT Enterprise, Claude Team, Copilot, Gemini. Des pilotes sont lancés. Des démos sont faites. Des PowerPoints sont présentés au board. Le tout est qualifié de "stratégie IA".

Ce n'est pas une stratégie. C'est un achat.

La différence est fondamentale, et c'est précisément cette différence que la plupart des dirigeants ne voient pas. Un abonnement à un modèle de langage, c'est l'accès à une capacité brute. C'est comme acheter un moteur sans avoir de voiture. Le moteur est puissant, impressionnant, techniquement remarquable. Mais posé dans un hangar, il ne transporte personne. Il fait du bruit. Il consomme du carburant. Et le lendemain, on se demande pourquoi on n'est arrivé nulle part.

· · ·

Karp utilise un mot que la plupart des commentateurs ont survolé, et qui est pourtant le cœur de son argument. Ce mot, c'est "ontologie".

En philosophie, l'ontologie est l'étude de ce qui existe, de la nature des choses. Chez Palantir, le terme a un sens technique précis : c'est l'architecture digitale qui décrit comment une organisation fonctionne réellement. Ses processus. Ses flux de données. Ses permissions de sécurité. Sa logique opérationnelle. Ses contraintes physiques. Qui fait quoi, avec quelles données, sous quelles conditions, avec quelles autorisations.

Karp dit : "L'ontologie permettra de prendre un grand modèle de langage et de l'utiliser, de l'affiner, puis de l'imposer à votre entreprise dans la logique de votre entreprise, dans le modèle de sécurité de votre entreprise."

C'est la phrase la plus importante que j'ai lue sur l'IA cette année. Parce qu'elle identifie, avec une précision chirurgicale, l'endroit où se crée la valeur. La valeur n'est pas dans le modèle. Le modèle, tout le monde y a accès. La valeur est dans la structure qui relie le modèle à la réalité opérationnelle d'une organisation spécifique.

Sans cette structure, le modèle flotte dans le vide. Il hallucine sur des données non structurées. Il génère l'illusion du travail. Et il n'exécute rien.

· · ·

Je vais traduire ce que dit Karp dans les termes de mon métier, parce que je crois que c'est là que l'argument devient concret.

Imaginez une agence d'architecture qui souscrit un abonnement à Claude ou à ChatGPT. Le lundi matin, un collaborateur demande au modèle de résumer un PLU. Le modèle produit un résumé. Le résumé contient probablement une erreur, parce que le modèle n'a pas accès au PLU réel de la commune, mais à une version générique de ce qu'un PLU devrait contenir. Personne ne vérifie. Le résumé est intégré dans une note au client. Le client prend une décision sur la base de cette note. L'erreur se propage.

C'est la fête dont parle Karp. Ça ressemble à du travail. Ça a le goût du travail. Mais ce n'est pas du travail. C'est une simulation de travail, générée par un modèle qui ne sait pas ce qu'est un PLU, qui ne sait pas quelle commune est concernée, qui ne sait pas quelles règles s'appliquent à la parcelle du client, et qui n'a aucun moyen de vérifier ce qu'il produit.

La gueule de bois arrive quand le client appelle pour dire que le résumé est faux.

· · ·

Maintenant, imaginez autre chose. Imaginez un système où le modèle de langage est connecté à la base du Géoportail de l'urbanisme. Où il peut interroger le PLU réel de la commune concernée. Où il connaît la parcelle du client, ses contraintes, son historique. Où il sait quels articles du Code de l'urbanisme s'appliquent, parce que 32 fichiers de référence juridique sont chargés en local. Où chaque résultat est vérifié contre les données sources avant d'être transmis. Où un daemon surveille les mises à jour réglementaires et alerte quand une règle change.

Ce système existe. C'est celui que j'ai construit. Il ne s'appelle pas "abonnement IA". Il s'appelle HAL-PC Instruct, et il a détecté en cinq minutes qu'un projet de permis de construire était instruit sur le mauvais PLU, épargnant des semaines de procédure et potentiellement un refus.

La différence entre les deux scénarios, c'est exactement ce que Karp appelle l'ontologie. Dans le premier cas, le modèle est seul dans le vide. Dans le second, il est enchâssé dans une architecture qui lui dit quoi regarder, où regarder, comment vérifier, et quand alerter. Le modèle est le même. La valeur produite est incomparable.

· · ·

Ce que Karp ne dit pas, et que je voudrais ajouter depuis ma position de praticien, c'est que l'ontologie ne se construit pas en achetant un logiciel. Elle se construit en comprenant, en profondeur, comment une organisation fonctionne, et en traduisant cette compréhension en une architecture que le modèle peut exploiter.

Dans mon cas, cette ontologie prend des formes très concrètes. Un fichier hal-memory.md qui contient tout ce que le système sait sur les projets en cours, les contacts, les préférences, les contraintes. Un fichier hal-contacts.md qui structure les relations professionnelles avec leurs rôles, leurs emails, leurs habitudes de communication. Un daemon qui tourne 24 heures sur 24, qui lit les emails via Gmail API, qui trie par urgence, qui alerte par iMessage quand un message critique arrive. Des pipelines de traitement qui savent prendre un export Archicad, le passer dans un workflow de style transfer, et produire une visualisation architecturale conforme aux attentes du client.

Rien de tout cela n'est un modèle de langage. Tout cela est l'architecture dans laquelle le modèle opère. Et c'est cette architecture qui transforme une capacité brute en valeur opérationnelle.

Le modèle, je peux le changer. J'utilise Claude pour les tâches qui exigent la meilleure qualité intellectuelle. J'utilise Qwen, un modèle open-source, pour les tâches quotidiennes en local. J'ai utilisé GPT pendant un temps. Le modèle est interchangeable. L'ontologie, elle, n'est pas interchangeable. Elle est le fruit de trois ans et demi de construction, d'erreurs, de corrections, d'itérations. Elle est le vrai actif.

· · ·

Karp dit que "toute la valeur du marché va aller aux puces et à ce qu'on appelle l'ontologie". Pas aux modèles. Pas aux abonnements. Pas aux interfaces de chatbot posées par-dessus.

C'est une prédiction audacieuse, et je crois qu'elle est juste. Les modèles se commoditisent. Chaque trimestre, un nouveau modèle sort qui fait aussi bien que le précédent pour moins cher. Les modèles open-source rattrapent les modèles propriétaires. La différence de qualité entre GPT-5.4, Claude Opus 4.6, et Qwen 3.5 se réduit sur les tâches opérationnelles courantes. Le modèle devient une commodité, comme l'électricité. On ne choisit pas son fournisseur d'électricité pour la qualité de ses électrons. On le choisit pour le prix et la fiabilité.

Ce qui ne se commoditise pas, c'est l'architecture spécifique à une organisation. La façon dont une agence d'architecture gère ses projets, communique avec ses clients, structure ses livrables, vérifie sa conformité réglementaire. La façon dont un hôpital coordonne ses protocoles de recherche, analyse sa littérature scientifique, gère ses données cliniques. Ces processus sont uniques, complexes, et irréductibles à un abonnement.

Les entreprises qui construisent cette architecture possèdent un actif que personne ne peut leur retirer. Elles peuvent changer de modèle demain sans rien perdre. Les entreprises qui n'ont qu'un abonnement possèdent exactement ce qu'elles louent : rien, dès qu'elles arrêtent de payer.

· · ·

Il y a une phrase de Karp que je trouve particulièrement éclairante, et qui touche directement à ce que je vis dans mon travail quotidien. Il dit : "Nous rendons les ingénieurs meilleurs ingénieurs. Nous transformons des gens qui ne sont pas ingénieurs en ingénieurs, en utilisant notre ontologie et un grand modèle de langage."

C'est exactement ce que l'ontologie permet quand elle est bien construite. Elle ne remplace pas l'expertise humaine. Elle l'amplifie et elle la démocratise. Un architecte qui n'est pas spécialiste de la réglementation urbaine peut, avec le bon système, analyser un PLU en dix minutes au lieu de trois heures. Un chercheur clinicien qui n'est pas bibliométricien peut obtenir une cartographie structurée de son champ de recherche en quelques minutes. Pas parce que le modèle est magique. Parce que l'architecture qui l'entoure sait quoi demander, où chercher, et comment vérifier.

C'est le contraire exact de la gueule de bois. C'est le travail sobre, précis, reproductible. Le travail qui se vérifie. Le travail qui produit des résultats que quelqu'un peut signer.

Karp a raison : les entreprises qui achètent des modèles paient pour le sentiment de la transformation. Celles qui construisent l'ontologie exécutent la transformation réelle. L'une de ces deux approches définira la prochaine décennie. L'autre se réveillera en 2030 en se demandant où est passée sa part de marché.

Exactement comme une gueule de bois.

Jean Umani
UMAN[iA]
Saint-Jean-Cap-Ferrat, mars 2026