OpenAI dévore l'application de couche ? a16z : les opportunités sont au-delà du « chemin pavé d'or », les entrepreneurs ont encore des chances derrière

a16z partenaires soulignent que la couche d'application de l'IA n'est pas un seul champ de bataille, les startups doivent éviter les outils horizontaux directement attaqués par les grandes entreprises de modèles, et se concentrer sur la pénétration verticale de l'industrie. Cet article est issu d'une publication sur Twitter.
(Précédent : Google investit dans la plateforme de routage IA OpenRouter, évaluée à 1,3 milliard de dollars, avec une croissance de 240 % en un an)
(Contexte supplémentaire : Sam Altman s'est entretenu avec le fondateur de a16z : OpenAI mise de manière agressive sur l'infrastructure, Sora est un outil stratégique clé)

Table des matières de cet article

Toggle

• L'anxiété se répand : les grands modèles envahissent la couche d'application ?
• Le piège du pavé jaune : la voie de l'outil horizontal est condamnée
• Opportunités dans le Pays d'Oz : la barrière de la verticalité dans les flux de travail
• Avantage en coût : routage de modèles et post-formation
• Plan de contrôle : conformité et gouvernance

C'est précisément la question que l'associé de a16z Joe Schmidt tente d'apporter dans cet article. Il utilise la métaphore du « pavé jaune » de « Le Magicien d'Oz » pour diviser les opportunités d'application de l'IA en deux catégories : d'une part, la voie principale que suivent les grandes entreprises de modèles, comme la génération de code, l'écriture, la création d'images, les agents généralistes et les assistants bureautiques horizontaux ; d'autre part, « ailleurs dans le Pays d'Oz », c'est-à-dire ces scénarios verticaux qui s'enfoncent dans les processus industriels, dépendent de flux de travail complexes, de l'accumulation de données, de la conformité, de la gouvernance et de l'intégration système.

Selon lui, la véritable opportunité pour les startups réside dans cette seconde catégorie.

De la vente à l'assurance, Joe Schmidt insiste à plusieurs reprises sur la même logique : ce que les entreprises sont réellement disposées à payer, ce n'est pas une fenêtre de chat plus intelligente, mais un système capable d'assumer la responsabilité des résultats commerciaux. Il doit comprendre l'état chaotique des données clients, gérer les approbations multiples et les cas limites, assumer la conformité et l'audit, et aussi, lors des mises à niveau du modèle, accompagner le client dans la migration, le routage et l'optimisation des coûts.

C'est aussi la conclusion centrale de cet article sur la prochaine génération de logiciels d'entreprise : les modèles fondamentaux deviendront de plus en plus puissants, mais aussi de plus en plus remplaçables ; cependant, ce qui restera irremplaçable, c'est la connaissance, les processus, la gouvernance et la mémoire opérationnelle accumulés autour de secteurs spécifiques et de flux de travail précis. Les opportunités pour les entreprises d'application IA ne résident pas dans la lutte pour « le pavé jaune » avec les entreprises de modèles, mais dans l'exploration de ces zones plus complexes, plus sales, plus lentes, mais aussi plus proches de la véritable valeur commerciale.

Récemment, j'ai constamment entendu la même question de la part de fondateurs et de potentiels employés : y a-t-il encore quelque chose à faire dans la couche d'application IA ? Ou bien, OpenAI et Anthropic finiront-ils par tout tuer ?

Cette question reflète une anxiété typique liée à l'IA. Certains ont déjà conclu : si l'on ne veut pas devenir une couche inférieure permanente, la seule position à valeur à long terme, c'est soit dans un laboratoire de grands modèles, soit dans la création de robots, de technologies avancées ou dans des domaines de pointe — en théorie, faire ce que « les laboratoires ne peuvent pas toucher ». Parce que si chaque type de logiciel est destiné à être englouti, soit par Codex ou Claude qui absorberaient directement le travail correspondant, soit par un futur modèle qui le rendrait obsolète, la meilleure option semble être : fuir rapidement !

J'admets que je suis presque aussi un hyper-optimiste de l'IA, et je pense qu'ils ont raison à moitié. Les laboratoires de grands modèles entrent effectivement dans de vastes zones de la couche d'application. Mais « couche d'application » n'est pas une opportunité homogène. La vraie clé de la décision est : suis-je en train de suivre « le pavé jaune » ou suis-je ailleurs dans le Pays d'Oz ?

Note : « le pavé jaune » est la voie principale menant à la Cité d'Émeraude du Magicien dans « Le Magicien d'Oz ».

Ce qu'on appelle « le pavé jaune », c'est la voie que suivent et dans laquelle investissent massivement les laboratoires de grands modèles. La génération de code, l'écriture, la création d'images — ces problèmes sont naturellement adaptés à l'expérimentation en laboratoire, car leur qualité s'améliore avec la capacité brute du modèle : chaque dollar investi dans le pré-entraînement et le post-entraînement améliore directement le produit.

Mais dans « ailleurs dans le Pays d'Oz », il existe des problèmes plus complexes, souvent plus verticaux. Il ne s'agit pas simplement de fournir un outil horizontal à un utilisateur d'entreprise, qui pourrait le connecter à des outils standards et résoudre le problème par une simple opération informatique. La valeur ici provient davantage de l'infrastructure autour du modèle : ces cadres permettent que les sorties soient crédibles, conformes, intégrées dans les processus métier. La capacité brute du modèle reste importante, mais elle n'est plus tout.

Nous en faisons l'expérience en temps réel. OpenAI et Anthropic reconnaissent en fait qu'elles ne peuvent pas tout résoudre avec un assistant IA universel. Elles ont annoncé des investissements massifs dans des projets de déploiement en coentreprise, autour de la configuration et de la personnalisation de modèles pour l'entreprise. Si elles pensaient que la prochaine version du modèle résoudrait tout, elles n'investiraient pas des milliards dans ces projets.

L'anxiété se répand : les grands modèles envahissent la couche d'application ?

Donc, si vous voulez gagner de l'argent avec des applications IA, ne suivez pas le pavé jaune, mais construisez ailleurs dans le Pays d'Oz. Voici quelques expériences que nous et certains fondateurs de notre portefeuille ont tirées de la pratique.

Si vous créez une entreprise, le pavé jaune est la voie la plus visible, mais aussi la plus risquée. Prenez un modèle performant, connectez-le à des intégrations existantes comme Google Drive, Slack, Salesforce, Notion, GitHub, puis construisez une couche d'orchestration intelligente. Cela ressemble à de la magie.

Le problème, c'est que c'est précisément ce que font les laboratoires de grands modèles via Cowork et Codex. Il est évident qu'ils possèdent des modèles, ce qui leur donne une meilleure rentabilité, un contrôle accru, et la capacité d'imposer des prix à tous les acteurs en aval. Mais plus important encore, ils contrôlent aussi l'architecture qui détermine quels problèmes le produit doit résoudre. Jusqu'à présent, ils ont adopté très consciemment le mode « modèle + appel d'outil », qui est exactement celui dont ont besoin ces tâches horizontales à faible étape. Même si une startup parvient à dépasser Codex ou Claude Code, le laboratoire de modèles reste doté d'une large capacité de distribution et de la marque la plus forte dans le domaine de l'IA.

Si vous êtes une startup d'application IA, utilisant la même approche : intégration aux mêmes connecteurs, sans sous-intelligence ou configuration, sans canal de distribution, alors vous êtes probablement sur une voie vers l'impasse.

Mais, pour une startup, la situation n'est pas totalement pessimiste. En dehors du pavé jaune, il existe encore d'énormes opportunités. Ces startups peuvent y avoir des clients et résoudre des problèmes complexes.

Ces entreprises construisent des expériences d'orchestration : les modèles sont intégrés dans des outils complexes, automatisés et connectés — autrement dit, du logiciel. Cela rend leur approche naturellement verticale. Elles peuvent se concentrer sur des flux de travail à plusieurs étapes, impliquant plusieurs parties, en concevant des sous-intelligences pour différents rôles et scénarios verticaux, pour traiter des problèmes que les plateformes horizontales d'Anthropic ou d'OpenAI ne peuvent pas atteindre : collecte de contexte inter-systèmes, routage de tâches vers plusieurs approbateurs à différentes étapes.

Ce type de travail implique souvent des systèmes hérités, nécessite des résultats déterministes, car l'incertitude est inacceptable, et peut même être lié directement à un résultat commercial clé. Les laboratoires de grands modèles savent bien que ces problèmes ont une grande valeur : c'est pourquoi ils construisent leurs propres équipes de configuration externalisées, et pourquoi un groupe de sociétés de services de renforcement de l'apprentissage pour grands comptes apparaît.

Une objection à cette vision est : jusqu'à présent, miser sur les modèles ou les laboratoires n'a pas été une bonne affaire, car ils ne cessent de progresser, et finiront par engloutir le marché que ces applications servent.

Les grands laboratoires continueront à progresser. Mais je pense que, dans le long terme, les entreprises ailleurs dans le Pays d'Oz ont plusieurs stratégies défensives.

Beaucoup de choses que vous internalisez dans votre activité ne figurent dans aucun corpus d'entraînement : les pratiques informelles de l'industrie, les standards non documentés, le savoir tribal dans la tête des praticiens. Tout cela n'est pas accessible sur Internet. Peu importe la puissance de calcul d'entraînement, cela ne remplacera jamais le travail dans ces flux de travail où ces connaissances résident.

Deux mécanismes de boucle de rétroaction se superposent : l'une est la boucle inter-clients, où plus vous voyez de variantes d'un même problème, plus votre modèle s'améliore par effet de levier ; l'autre est la boucle intra-clients, où la compréhension des raisons derrière chaque décision, les exceptions non explicitées, les règles empiriques propres à l'entreprise, ne se révèlent que lors de véritables interactions avec le système.

Le piège du pavé jaune : la voie de l'outil horizontal est condamnée

Même si les données client ne peuvent pas être partagées entre clients, une entreprise d'application peut utiliser la reconnaissance de modèles pour différents types de problèmes, et s'en servir pour guider la conception future des flux. Si une entreprise a déjà laissé son assistant traiter 100 fois des modifications de lignes rouges juridiques, 1 000 cycles d'évaluation d'assurance, ou 10 000 activités de prospection SDR, sa compréhension des formes de problème ne peut pas être simplement copiée par un nouveau venu qui lance un nouvel assistant.

Théoriquement, un assistant horizontal pourrait aussi construire une infrastructure d'apprentissage équivalente. Mais il ne le fait pas, pour deux raisons principales : un manque de focus, et surtout, une expérience utilisateur inadéquate. La capture de cette connaissance dépend entièrement de l'interface de flux de travail que vous offrez à l'utilisateur. Les acteurs verticaux peuvent concevoir ces interfaces autour des informations réellement nécessaires pour leur flux, ce que les outils horizontaux ne peuvent pas faire. Les ensembles d'évaluation, la labellisation des sorties, les systèmes de classification des cas limites — tout cela peut former un cercle de données vertical, et soutenir la fine-tuning. Si un nouveau venu ne dispose pas d'un environnement de production équivalent, il lui sera difficile de générer ce cercle. La faisabilité dépend des droits sur les données, de l'accumulation d'utilisation en production, et de la structure contractuelle avec le client, mais la reconnaissance de modèles continue de s'améliorer.

Les laboratoires de grands modèles ont déjà mis en place des routages : appeler différents modèles selon la requête, utiliser l'intégration de modèles en bas niveau. Mais ils ne peuvent pas faire de routage inter-fournisseurs, ni évaluer la meilleure alternative pour une sous-tâche spécifique, ni utiliser un micro-modèle open source parfaitement adapté dans un segment précis.

Les entreprises dans le Pays d'Oz, quant à elles, choisiront le modèle le plus approprié pour chaque sous-tâche dans tout le marché, plutôt que d'utiliser un modèle unique d'un laboratoire. Elles assumeront aussi des tâches que personne d'autre ne veut faire : réévaluer à chaque nouvelle sortie de modèle, recalibrer prompts pour les cas limites clients, déployer sans perturber la production. Les laboratoires de grands modèles ne feront pas cela pour leurs clients. Ils vendent le nouveau modèle, puis disent : « migrez ». Les entreprises dans le Pays d'Oz absorbent ces coûts de migration. Le client bénéficie ainsi de la meilleure capacité d'intelligence du marché, avec une continuité à chaque mise à jour.

Fournir chaque requête à Opus 4.7, c'est la voie la plus rapide vers une marge négative. Les meilleures entreprises dans le Pays d'Oz routent entre modèles à différents niveaux : les tâches les plus difficiles vers les modèles de pointe, la majorité vers des modèles intermédiaires, et dans les segments éprouvés, vers des modèles plus petits ou fine-tunés.

Certaines de ces entreprises ont déjà commencé à faire leur propre post-formation, optimisant les modèles pour les tâches spécifiques qui comptent vraiment pour leurs clients, à un coût bien inférieur à celui des API de pointe. Les laboratoires de grands modèles proposent un « prix plancher » : X dollars pour le niveau minimum d'intelligence. Les entreprises dans le Pays d'Oz proposent l'inverse : le coût le plus bas pour le niveau d'intelligence nécessaire dans un flux de travail spécifique. Cela ne peut fonctionner que si vous savez précisément ce dont chaque sous-tâche a besoin. Or, les laboratoires de grands modèles ne peuvent pas, structurellement, comprendre chaque tâche dans chaque secteur vertical. À terme, cela se traduit par des prix plus faibles et plus contrôlables pour les résultats.

Devenir le plan de contrôle IA d'un client dans un secteur vertical a une valeur considérable. Ce plan de contrôle rassemble les droits, l'audit, ce que l'assistant est autorisé à faire, et ce que l'assistant a réellement fait.

Ce plan de contrôle repose sur des garde-fous spécifiques à chaque cas d'usage, qui varient selon l'industrie et le poste. Parce que ces entreprises ont des outils, des flux de travail et des données avec lesquelles l'assistant interagit en bout de chaîne, elles peuvent fournir des résultats déterministes que les acteurs horizontaux ne peuvent pas atteindre. Elles prennent aussi en charge la complexité réglementaire : règles fédérales américaines en matière de litiges civils, règles professionnelles des avocats, HIPAA dans la santé, SEC et FINRA dans la finance, régulations d'assurance au niveau des États, etc. Si un acteur horizontal ne se spécialise pas dans une centaine d'industries verticales, il ne pourra pas faire cela de manière crédible. Le CIO a besoin d'un partenaire capable d'assumer la conformité dans le contrat.

Tout cela revient finalement à une seule chose : la concentration.

Cette concentration peut viser une industrie verticale, comme l'assurance, le droit ou la comptabilité ; ou une fonction métier suffisamment approfondie, comme la vente, le service client ou la finance. Dans tous les cas, cela nécessite une équipe qui reste longtemps dans le même segment de clientèle, pour comprendre ses flux, ses cas limites et ses exigences réglementaires. Les laboratoires de grands modèles ne sont pas conçus pour cela. Ils doivent servir tout le monde, couvrir tout, ce qui explique leur construction initiale du pavé jaune. Ce compromis, cependant, limite leur capacité à pénétrer d'autres zones dans le Pays d'Oz : on peut être omniprésent, ou exceller dans un domaine, mais pas les deux en même temps.

Comment comprendre cela en pratique ? Voici quelques conseils opérationnels donnés par le CEO Prabhav Jain, de 11x.

Opportunités dans le Pays d'Oz : la barrière de la verticalité dans les flux de travail

Construire une entreprise capable de résister à l'impact des laboratoires de grands modèles consiste à partir des résultats concrets que les clients veulent vraiment. Pour nous, c'est aider les entreprises à générer plus de prospects et de pipelines de vente.

À partir de là, la question devient très précise : quelles activités voulons-nous maîtriser de bout en bout, et qui peuvent réellement faire croître le pipeline ? Décomposer chaque activité en tâches. Quelles tâches conviennent à l'assistant, lesquelles non ? Quelles nécessitent une compréhension approfondie du domaine, lesquelles non ? Les laboratoires de grands modèles proposeront aussi des flux de travail, mais quand une étape est complexe, avec des entrées chaotiques, un état difficile à expliquer, ou des contraintes du monde réel, un simple meilleur modèle ne suffit pas. La tâche revient alors à l'ingénierie logicielle traditionnelle, où les laboratoires de grands modèles n'ont pas d'avantage face à une application spécialisée.

Par exemple, nos tâches incluent : la prospection basée sur des signaux personnalisés, la complétion d'informations prospects, la recherche approfondie sur les comptes, l'extraction de contexte depuis le CRM, la rédaction d'informations pour différents canaux, l'évaluation de la qualification des prospects par l'assistant, et le système d'envoi d'emails. Certaines sont des tâches d'assistant, d'autres non. Ces tâches ne se résolvent pas par une seule invite, mais nécessitent une ingénierie approfondie.

L'intuition clé dans cette analogie du Pays d'Oz : dans tout flux de travail réel, environ la moitié des tâches ne sont pas assistantes, et cette moitié ne donne pas d'avantage en laboratoire. Leur capacité à écrire du logiciel déterministe n'est pas supérieure à la vôtre. L'autre moitié, assistante, exige aussi que vous vous concentriez sur le résultat souhaité, en ajustant, entraînant et contraignant le modèle.

La connaissance du domaine n'est souvent pas dans les données d'entraînement générales. Elle doit être construite de bas en haut à partir de l'industrie verticale ou de fonctions spécifiques, et alimentée au bon moment dans le flux de travail. Par exemple, quand notre assistant juge si un contact entrant est qualifié, il doit être entraîné pour comprendre : pour une industrie spécifique, un profil utilisateur donné, ce qui constitue une bonne conversation de vente. C'est le travail de l'entreprise d'application, et cette capacité s'accumule par effet de levier.

Plus important encore, ces capacités deviennent obsolètes, car l'entreprise elle-même évolue. Par conséquent, faire évoluer en continu les flux de travail et le contexte devient un avantage concurrentiel. Par exemple, quand nous avons lancé un produit d'emailing à grande échelle, « les emails écrits par IA » venaient tout juste d'apparaître. Aujourd'hui, on peut distinguer très finement ceux écrits par IA de ceux écrits par des humains, et cette capacité de jugement évolue tous les quelques mois. Notre assistant doit s'adapter en permanence aux dynamiques du marché, et la barrière se construit ici. En réalité, malgré cette dynamique, notre taux de réponse positif a quadruplé ces derniers mois, générant des centaines de millions de dollars de pipeline pour nos clients.

Les problèmes complexes sont là où la valeur commerciale se libère vraiment. Sinon, on se retrouve à faire une fine couche d'emballage.

Décomposer un problème commercial suffisamment complexe révèle rapidement le chaos. Voici un exemple simple dans le domaine GTM : si une entreprise est déjà cliente, vous ne devriez pas contacter un contact spécifique dans cette entreprise. Mais ce n'est pas si simple.

Peut-être que votre CRM a le domaine de cette entreprise. Que faire si cette entreprise a plusieurs filiales ? Si le CRM ne mentionne que la société mère ? Si un champ obsolète dans Salesforce vous conduit à envoyer un email froid au directeur des revenus d’un client existant ? La réalité est chaotique. Même les humains ont du mal à gérer cela, et un modèle ne peut pas passer cette barrière. Pour instaurer de l'ordre dans ce chaos, il faut concevoir un assistant spécifique à la forme du problème, plutôt que de simplement pointer vers le CRM. En fait, d’après nos données, la qualité et la fraîcheur de nos données dépassent celles de nos clients, donc par défaut, nous utilisons nos propres données comme ancrage.

Les garde-fous sont sous-estimés. Même à l’intérieur d’un même produit, chaque cas d’usage nécessite ses propres garde-fous. Pour nous, un prospect dans un secteur réglementé comme la finance, avec des garanties spécifiques, est très différent d’un client SaaS de taille moyenne. Ces garanties se traduisent par des règles, des obligations, des données accessibles, et des décisions enregistrées.

Un système « universel » échouera face à ces différences. Les garde-fous doivent être construits par cas d’usage, configurés par client, et régulièrement audités, ce qui revient entièrement à l’application. C’est pourquoi nous avons besoin d’ingénieurs déployés en front pour ajuster chaque client.

Avantage en coût : routage de modèles et post-formation

Par exemple, nous avons collaboré avec une grande institution du Fortune 1000, pour des appels sortants avec leur vaste clientèle SMB, avec consentement. Au début, le taux de réponse était faible. Nous avons dû itérer rapidement pour apprendre à faire réagir ces prospects en moins de 10 secondes. Le comportement des PME est très différent de celui des grands acheteurs B2B ou des consommateurs. Aujourd’hui, le nombre d’opportunités de vente générées en une journée dépasse ce que leur équipe commerciale peut produire en un mois dans ce segment.

La vente n’est qu’un exemple. L’assurance en est un autre, illustrant la même idée sous un angle différent. Voici la compréhension d'Aman Gour, CEO de FurtherAI, sur la « construction hors du pavé jaune ».

Quand nous avons commencé à déployer l’IA dans l’opération d’assurance réelle, une hypothèse revenait sans cesse : le modèle est l’intelligence, le flux de travail n’est qu’un cadre autour du modèle.

Mais, en collaborant avec plus d’assurances, nous sommes de plus en plus convaincus que c’est tout le contraire.

Dans l’assurance, beaucoup d’intelligence est déjà dans le flux de travail. Deux compagnies peuvent faire passer un même document par un processus : soumission, vérification, devis, souscription. Le chemin est simple. La vraie différence entre deux assureurs, c’est tout ce qui se passe à l’intérieur : quels risques doivent être escaladés, quels signaux de perte sont clés, quand privilégier la décision humaine, quelles données externes consulter, comment enregistrer la décision finale.

Ces logiques ne résident pas dans un moteur de règles propre. Elles sont dispersées dans les processus opérationnels, la vérification managériale, la philosophie de l’évaluation, les préférences spécifiques de chaque assureur, et l’expérience accumulée. Beaucoup ne sont pas écrites dans un format que le modèle peut lire directement.

C’est pourquoi nous ne croyons pas à une intelligence pure qui raisonne à chaque étape, ni à un flux rigide qui s’effondre face à la complexité. Au contraire, nous construisons des flux d’intelligence. Le flux apporte répétabilité, auditabilité et maîtrise des coûts ; l’intelligence gère la variabilité, et reprend le processus si le chemin idéal est interrompu ; l’humain reste impliqué dans les décisions de jugement et de responsabilité.

Au début, ce système automatise le travail manuel. Mais, avec le temps, chaque mise à jour devient un signal, chaque exception un retour d’information, chaque correction humaine une indication sur ce qui manque dans le manuel. À terme, le flux ne sera plus seulement une suite d’instructions, mais la mémoire opérationnelle de l’assureur.

C’est aussi ce que les laboratoires de grands modèles ont du mal à atteindre. Ils continueront à sortir de meilleurs modèles et intelligences générales, et c’est leur rôle. Mais ils ne resteront pas longtemps à apprendre pourquoi un compte a été escaladé, pourquoi un risque a été rejeté, ou pourquoi un souscripteur a contredit une règle. Ces connaissances ne peuvent venir que d’une exécution répétée dans un environnement de production. La première version du flux n’est pas une barrière. La boucle d’utilisation en production, qui se construit avec le temps, l’est.

Pour nous, c’est cela, « quitter le pavé jaune ».

Plan de contrôle : valeur en conformité et gouvernance

Combien d’étapes faut-il pour cela ? Quels outils faut-il construire pour le supporter ?

Comparez avec une recherche horizontale IA dans Google Drive : une étape, une opération, avec une tolérance d’erreur élevée. L’utilisateur lit le résumé, s’il se trompe, il demande une nouvelle fois.

Prenez une tâche de modification de ligne rouge légale, basée sur des précédents de trois ans d’un cabinet : cela peut impliquer des dizaines d’étapes, plusieurs outils, une validation par un associé, voire une argumentation en cour. Les deux semblent « une IA qui fait le travail », mais seul le second nécessite une infrastructure logicielle profonde, construite par une équipe dédiée pendant des années.

Vous construisez un système pour que le client exécute son travail, ou un outil pour s’ajouter à un système existant ?

Le système doit couvrir tout le flux : collecte de données, gouvernance, enregistrement des actions. Lorsqu’un client décrit son travail réel, il se réfère à ce système. L’outil n’est qu’un ajout d’intelligence à un flux existant.

Un produit d’outil peut générer de vrais revenus, mais les laboratoires de grands modèles ont plus facilement tendance à tout prendre, car le client ne dépend pas de vous comme couche d’orchestration. Un produit systémique à fort ACV est un signal, car il remplace une main-d’œuvre réelle, et peut donc faire payer. Mais ce n’est pas une garantie absolue. Vous devez vous demander : si un laboratoire de grands modèles lançait un produit concurrent direct, le client aurait-il encore besoin de votre outil ? Si oui, vous construisez un système. Si non, vous n’êtes qu’un outil — même si votre ACV est élevé.

Les performances des laboratoires de grands modèles se jugent par des benchmarks ; celles des entreprises dans le Pays d’Oz par leur bilan client.

Les clients ne se soucient pas de votre score sur SWE-Bench ou MMLU. Ils veulent que votre assistant ait conclu une vente, modifié correctement une clause contractuelle, assuré la bonne police. Si leur intérêt porte sur le résultat d’un flux spécifique, et non sur une capacité générale, vous êtes dans le Pays d’Oz. Si le client achète la capacité générale, c’est ce qu’il peut obtenir via Claude ou Codex.

Les meilleurs acteurs en intelligence sont comme des hedge funds : ils gagnent en alpha, qui se mesure dans le bilan client, pas dans les scores de benchmark.

Nous verrons de grands gagnants à la fois sur le pavé jaune et en dehors. Les modèles continueront à gagner, car ils ont à la fois la capacité de modèle et la distribution adaptée aux outils horizontaux.

Mais d’autres dans le Pays d’Oz peuvent aussi gagner, à condition d’avoir un système de travail : une interface pour l’exécution réelle, et des données qui circulent et sont capturées. Ces entreprises ont la capture de données, le flux de travail, la gouvernance. À mesure qu’un flux complexe dans un secteur vertical mûrit, elles forment une expérience client incontournable. Avec l’arrivée de nouvelles générations de modèles, ces entreprises deviennent celles qui intègrent ces modèles et les livrent aux clients. La capacité de modèle est remplaçable, mais le système de travail ne l’est pas.

La prochaine génération de logiciels d’entreprise sera construite en dehors du pavé jaune.