a16z : Les entreprises comme OpenAI ne supprimeront pas toutes les opportunités au niveau de la couche applicative — mettez de côté votre anxiété liée à l’IA.
TechFlow SélectionTechFlow Sélection
a16z : Les entreprises comme OpenAI ne supprimeront pas toutes les opportunités au niveau de la couche applicative — mettez de côté votre anxiété liée à l’IA.
OpenAI tuera-t-elle toutes les applications d’IA ? a16z : « Vous prenez la mauvaise direction. »
Dédié à des analyses Web3 approfondiesAuteur : Joe Schmidt IV
Traduction et adaptation : TechFlow
Introduction de TechFlow : Quelle est la plus grande angoisse des entrepreneurs en IA ? Que OpenAI et Anthropic ne tuent toutes les opportunités au niveau des applications. Un associé d’a16z répond à cette question avec sa « théorie du chemin de briques jaunes » : les laboratoires de grands modèles ne domineront que les tâches horizontales et mono-étapes ; les véritables opportunités résident dans les scénarios verticaux, les workflows multi-étapes et les domaines soumis à des exigences réglementaires strictes. Cet article mérite une lecture attentive, tant pour les entrepreneurs que pour les investisseurs en IA.
Récemment, j’ai été interrogé à maintes reprises par des fondateurs et de futurs employés sur une question précise : « Que reste-t-il à faire au niveau des applications IA, ou OpenAI et Anthropic vont-elles tout éliminer ? »
Cette question révèle une forme particulière d’anxiété liée à l’IA. Certains en déduisent qu’il ne reste qu’un seul refuge contre une marginalisation définitive : soit rester à l’intérieur d’un grand laboratoire, soit se tourner vers des domaines de pointe tels que la robotique ou les technologies dures — en théorie, toute activité « hors portée des laboratoires ». Si chaque logiciel devait être absorbé, soit directement par Codex ou Claude, soit rendu superflu par les modèles futurs, alors fuyez !
Écoutez-moi bien : comme presque tout le monde, je suis un maximaliste de l’IA, et je pense qu’ils ont raison… à moitié. Les laboratoires absorbent effectivement une vaste surface applicative. Mais la « couche applicative » n’est pas une opportunité homogène. Le cadre approprié consiste à se demander si vous êtes sur le « chemin de briques jaunes », ou ailleurs, dans le pays d’Oz.
Le « chemin de briques jaunes » est notre abréviation pour désigner la trajectoire suivie par les laboratoires, qui y consacrent d’importantes ressources. Ces laboratoires sont particulièrement adaptés à la résolution de problèmes tels que la génération de code, la rédaction ou la création d’images, car ces tâches s’améliorent naturellement avec l’augmentation des capacités fondamentales des modèles : chaque dollar investi dans l’entraînement préalable et l’ajustement postérieur améliore la qualité du produit. En revanche, « ailleurs dans le pays d’Oz » vivent des problèmes plus complexes, souvent verticaux, qui ne se résolvent pas aussi simplement qu’en fournissant aux utilisateurs professionnels un outil horizontal couplé à des outils standards et à l’informatique classique. La valeur provient davantage des « échafaudages » construits autour des modèles — ces échafaudages rendent les sorties fiables, conformes et exploitables dans un secteur industriel spécifique, et non pas uniquement fonctionnelles grâce aux capacités brutes du modèle sous-jacent (bien que celles-ci restent essentielles !).
Nous observons cela en temps réel, puisque OpenAI et Anthropic indiquent clairement au marché qu’ils ne peuvent pas résoudre tous les problèmes avec une intelligence artificielle généraliste. Ils annoncent ainsi de vastes coentreprises de déploiement préalable, visant à créer des entreprises entières autour de la configuration et de la personnalisation de leurs modèles pour les entreprises. Si vous pensiez vraiment qu’une simple nouvelle version de modèle suffirait à résoudre tous les problèmes, vous n’investiriez pas des milliards de dollars dans ces projets.
Ainsi, si vous souhaitez vous enrichir en construisant une application IA, évitez le chemin de briques jaunes et bâtissez plutôt ailleurs, dans le pays d’Oz. Voici ce que nous avons appris — ainsi que certains de nos fondateurs portefeuille — sur ce qui fonctionne effectivement.
Le chemin de briques jaunes
Si vous lancez une entreprise, le chemin de briques jaunes constitue le parcours le plus évident, mais aussi le plus risqué. Prenez un modèle performant, ajoutez-y quelques connecteurs prêts à l’emploi (tels que Google Drive, Slack, Salesforce, Notion ou GitHub), puis publiez une couche d’orchestration d’agents intelligents par-dessus. Magique !
Le problème est que c’est exactement ce que font déjà les laboratoires avec Cowork et Codex. Bien sûr, ils possèdent les modèles eux-mêmes, ce qui leur confère de meilleurs marges, un contrôle accru et la capacité d’imposer leur tarification à tout acteur en aval. Mais surtout, ils détiennent également le pouvoir de définir l’architecture de leur produit — c’est-à-dire les types de problèmes qu’il est conçu pour résoudre efficacement. Jusqu’à présent, ils font preuve de prudence dans leur approche combinant modèles et appel d’outils — précisément le mode requis pour les tâches horizontales à faible nombre d’étapes. Même si une startup parvenait, par quelque moyen que ce soit, à surpasser Codex ou Claude Code, les laboratoires disposent d’immenses canaux de distribution et bénéficient de la plus forte aura de marque dans le domaine de l’IA.
Si vous êtes une entreprise d’applications IA et que vous appliquez cette même recette avec les mêmes connecteurs, sans sous-agents ni configuration personnalisée, et sans canal de distribution propre, vous avancez probablement vers… nulle part.
Ailleurs dans le pays d’Oz
Il n’y a pas que désolation et fatalisme pour les startups. Hors du chemin de briques jaunes, d’immenses opportunités existent, où les startups peuvent clairement s’approprier leurs clients et résoudre des problèmes complexes.
Ces entreprises construisent des expériences d’agents intelligents, dans lesquelles les modèles sont intégrés à un réseau complexe d’outils, d’automatisations et d’intégrations (autrement dit : des logiciels), ce qui rend naturellement ces startups verticales. Elles peuvent se concentrer sur des workflows multi-étapes et impliquant plusieurs parties prenantes, en utilisant des sous-agents spécialisés selon les rôles et les tâches spécifiques à un secteur vertical — une dimension inaccessible aux plateformes horizontales d’Anthropic et d’OpenAI : collecter du contexte à travers plusieurs systèmes, puis le router vers plusieurs personnes devant approuver successivement à différentes étapes. Cela implique souvent un ou plusieurs systèmes hérités, exige généralement des résultats déterministes, rejette toute ambiguïté, et est fréquemment lié à des résultats commerciaux précieux. Les laboratoires comprennent parfaitement la valeur de ces problèmes : c’est pourquoi ils construisent leurs propres magasins de configurations externalisées, et c’est pourquoi toute une catégorie d’activités haut de gamme existe autour de l’apprentissage par renforcement.
Pourquoi « ailleurs dans le pays d’Oz » ne sera pas conquis par le sorcier
Une objection courante à cette analyse est que, jusqu’à présent, miser sur le fait que les modèles / laboratoires ne progresseraient pas s’est révélé un pari extrêmement mauvais. Il est fort probable qu’ils continuent à s’améliorer, et finissent par grignoter progressivement ces services applicatifs.
Les laboratoires s’amélioreront certes, mais je crois qu’« ailleurs dans le pays d’Oz » dispose de plusieurs moyens de se protéger au fil du temps :
Données et boucles d’apprentissage :
Beaucoup de ce que vous intégrez n’appartient à aucun jeu d’entraînement — normes sectorielles informelles, standards non documentés, savoirs tacites accumulés par les praticiens. Aucun de ces éléments n’est disponible sur le Web public. Aucune puissance de calcul d’entraînement supplémentaire ne peut remplacer l’expérience directe de ces flux de travail réels. Deux boucles d’apprentissage se superposent ici : l’une transversale aux clients — accumulation de motifs lorsque vous observez davantage de variantes d’un même problème — et l’autre interne à chaque client — raisons profondes derrière des décisions spécifiques, exceptions implicites, règles empiriques propres à l’entreprise, qui ne peuvent émerger que grâce à une interaction réelle avec le système.
Même si les données clients ne peuvent pas être partagées entre clients, les entreprises applicatives peuvent exploiter les motifs transversaux identifiés à travers les types de problèmes rencontrés, afin de concevoir les bonnes architectures pour les défis futurs. Une entreprise qui a déjà fait exécuter ses agents intelligents cent fois pour des révisions juridiques, mille fois pour des cycles de souscription d’assurance ou dix mille fois pour des campagnes SDR, a internalisé la structure même du problème d’une manière que tout nouvel entrant ne saurait reproduire — même si ce dernier lançait un agent entièrement nouveau dès son premier jour.
Un agent horizontal pourrait, en principe, construire la même infrastructure d’apprentissage. Il ne le fait pas, non seulement par manque de concentration, mais aussi pour des raisons d’expérience utilisateur : la capture de ces connaissances dépend entièrement de l’interface de flux de travail offerte à l’utilisateur, interface que les acteurs verticaux peuvent façonner précisément autour des contenus qui doivent émerger dans leur flux spécifique. Les outils horizontaux ne le peuvent pas. Des jeux d’évaluation, des sorties annotées et des taxonomies de cas limites peuvent s’accumuler en boucles de données spécifiques à un secteur, alimentant ainsi le fine-tuning, tandis que tout nouvel entrant serait incapable de générer un volume comparable sans exposition réelle en production. Cela dépend certes des droits sur les données, du volume d’exposition en production et de la structure des contrats clients, mais la reconnaissance des motifs s’accumule inévitablement.
Gestion de la variabilité et de la complexité des modèles : Les laboratoires routent déjà en interne — utilisant différentes catégories de modèles selon les requêtes, avec des agrégations sous-jacentes. Ce qu’ils ne peuvent pas faire, en revanche, c’est effectuer un routage inter-fournisseurs, évaluer les modèles concurrents pour des sous-tâches spécifiques, ou encore utiliser des modèles open source fine-tunés pour des segments très précis et optimaux. Les entreprises « ailleurs dans le pays d’Oz » choisissent, pour chaque sous-tâche, le meilleur modèle disponible sur l’ensemble du marché, et non pas seulement celui publié par leur laboratoire d’origine. Elles accomplissent aussi le travail ingrat — réévaluer les performances à chaque mise à niveau, recalibrer les prompts pour les cas limites des clients, déployer sans perturber la production — à chaque nouvelle sortie de modèle. Les laboratoires ne font pas ce travail pour leurs clients ; ils vous vendent simplement le prochain modèle et vous demandent de migrer. Les entreprises « ailleurs dans le pays d’Oz » absorbent ce travail de migration. Le client obtient ainsi l’intelligence la plus performante disponible sur le marché, accompagnée d’une continuité à chaque mise à niveau.
Optimisation des coûts : Exécuter chaque requête via Opus 4.7 est le chemin le plus rapide vers une marge brute négative. Les meilleures entreprises « ailleurs dans le pays d’Oz » pratiquent un routage inter-niveaux de modèles — les modèles de pointe traitent les tâches les plus difficiles, les modèles intermédiaires gèrent la majorité du travail, et des modèles plus petits, personnalisés ou fine-tunés, sont utilisés là où elles ont acquis des droits d’usage. Certaines entreprennent désormais un entraînement postérieur sur leurs propres modèles, optimisés pour des fragments très ciblés de travail importants pour leurs clients, offrant ainsi un service à une fraction du coût des appels API de pointe. Les laboratoires fixent leurs prix selon la ligne de base : « la quantité minimale d’intelligence fournie pour X dollars ». Les entreprises « ailleurs dans le pays d’Oz » vendent l’inverse : « le coût minimal en dollars pour atteindre le niveau d’intelligence spécifique requis par le workflow ». Cela n’est possible que si vous connaissez précisément le niveau requis pour chaque sous-tâche — or les laboratoires ne peuvent structurellement pas le savoir pour chaque secteur vertical. Cela se traduit directement par des prix plus bas et maîtrisés.
Gouvernance : Devenir le plan de contrôle utilisé par le client pour faire fonctionner l’IA dans son secteur vertical revêt une valeur considérable — c’est là que convergent les autorisations, les audits, les actions autorisées des agents et celles effectivement réalisées. Ce plan de contrôle est construit à partir de garde-fous spécifiques à chaque cas d’usage, qui diffèrent radicalement d’un secteur à l’autre et d’un type de travail à l’autre. Parce qu’elles détiennent de bout en bout les outils, les workflows et les données auxquelles les agents ont accès, elles peuvent fournir des résultats déterministes d’une manière que les outils horizontaux peinent à égaler. Elles absorbent également la complexité réglementaire pour l’acheteur final — les règles FRCP et celles des barreaux dans le domaine juridique, HIPAA dans le secteur de la santé, les régulations de la SEC et de FINRA dans la finance, ou encore les réglementations assurantielles étatiques. Les acteurs horizontaux ne peuvent pas le faire de façon crédible, sauf à devenir simultanément cent acteurs verticaux différents. Le DSI souhaite avoir un partenaire qui, contractuellement, assume la conformité des agents qu’il fournit.
Tout cela ramène à une seule chose : la concentration. Elle peut porter sur un secteur vertical (assurance, droit, comptabilité) ou sur une fonction approfondie (ventes, support client, finance). Dans les deux cas, ce travail exige une équipe totalement dédiée à un groupe de clients spécifique — ses flux de travail, ses cas limites, ses réglementations. Les laboratoires ne sont pas conçus pour cela. Ils doivent être partout, servir tout le monde — c’est précisément ainsi qu’ils ont construit le chemin de briques jaunes. Ce même compromis les empêche d’entrer « ailleurs dans le pays d’Oz » — on ne peut pas être partout à la fois, ni exceller dans une seule chose. On ne peut pas avoir les deux.
Les ventes comme exemple — conseils pratiques du PDG de 11x Technology
Comment concrètement penser ce problème ? Voici quelques conseils pratiques du PDG de 11x, Prabhav Jain.
Concentrez-vous sur les résultats
La voie tactique pour construire une entreprise résiliente face aux laboratoires commence par le résultat spécifique qui importe véritablement à vos clients. Pour nous, il s’agit d’aider les entreprises à générer davantage de pistes qualifiées. À partir de là, la réflexion devient opérationnelle. Quelles activités concrètes, menées de bout en bout, contribuent réellement à générer ces pistes ? Décomposez chaque activité en tâches. Lesquelles peuvent être automatisées par des agents, lesquelles non ? Lesquelles nécessitent des connaissances approfondies du domaine, lesquelles non ? Les laboratoires publieront aussi des workflows, mais lorsqu’un workflow comporte de nombreuses étapes, des entrées chaotiques, des états difficiles à interpréter ou des contraintes du monde réel, un simple modèle amélioré ne suffira pas à atteindre votre objectif. Le travail revient alors à l’ingénierie logicielle traditionnelle — et sur ce terrain, les laboratoires ne détiennent aucun avantage face à une startup focalisée. Par exemple, voici certaines tâches que nous traitons, certaines étant automatisées par des agents, d’autres non : prospection de prospects basée sur des signaux personnalisés, enrichissement de prospects, recherche approfondie sur les comptes, récupération de contexte depuis le CRM, rédaction de messages sur des canaux spécifiques, agents de qualification de prospects et systèmes de livraison d’e-mails. Ce ne sont pas des tâches qu’on peut accomplir d’un seul coup : elles exigent une ingénierie poussée.
L’idée clé de l’analogie avec le pays d’Oz est que, dans tout workflow réel, environ la moitié des composantes non automatisées par des agents ne bénéficie d’aucun avantage aux laboratoires. Ils ne sont pas meilleurs que vous pour écrire du logiciel déterministe sous la couche des modèles. Quant à la moitié automatisée, elle nécessite toujours que vous ajustiez, formiez et contraintiez les modèles pour obtenir précisément les résultats souhaités. Les connaissances du domaine n’existent généralement pas dans les données d’entraînement générales. Ces compétences sont construites de zéro pour un secteur vertical ou une fonction donnée, puis injectées dans le modèle au moment opportun du workflow. Lorsque notre agent qualifie une piste entrante au téléphone, je dois l’entraîner spécifiquement sur les dialogues de vente efficaces dans ce secteur et pour ce rôle précis. C’est le travail de l’entreprise applicative — et cet avantage s’accumule de façon exponentielle.
Plus important encore, ces compétences deviennent rapidement obsolètes, car les activités commerciales évoluent constamment. Votre capacité à faire évoluer continuellement ces workflows et ce contexte constitue donc votre véritable avantage concurrentiel. Par exemple, lorsque nous avons lancé notre produit de prospection par e-mail à grande échelle, les e-mails « rédigés par IA » étaient encore une nouveauté. Aujourd’hui, les destinataires distinguent nettement les e-mails rédigés par IA de ceux rédigés par des humains — et cette capacité évolue tous les quelques mois. Notre agent doit s’adapter en continu à la dynamique du marché, et c’est précisément là que se creuse notre fossé de protection. En effet, malgré l’évolution constante du marché, notre taux de réponses positives a quadruplé ces derniers mois, générant pour nos clients des centaines de millions de dollars d’opportunités commerciales.
Concentrez-vous sur les problèmes à haute complexité
Les problèmes complexes sont ceux qui libèrent réellement de la valeur commerciale. Sinon, vous risquez de ne construire qu’une mince couche d’emballage.
Décomposez n’importe quel problème commercial suffisamment complexe, et le chaos apparaît vite. Voici un exemple tiré du domaine GTM, qui semble simple : si une entreprise est déjà cliente, vous ne devriez pas contacter à nouveau les contacts de cette entreprise. En réalité, ce n’est pas aussi simple. Peut-être que votre CRM contient le nom de domaine de cette entreprise. Et dans le cas d’une société possédant des dizaines de filiales ? Et si le CRM contient le nom de domaine de la maison mère ? Et si un champ obsolète dans Salesforce conduit à envoyer un e-mail froid au CRO d’un client existant ? Les données du monde réel sont chaotiques. Même les humains peinent à les traiter. Les modèles ne franchissent pas miraculeusement ce seuil. Ordonner ce chaos exige des agents intelligents spécifiquement conçus pour la forme particulière du problème, et non pas un copilote généraliste pointé vers le CRM. En effet, selon les données dont nous disposons, nous avons réalisé que notre propre qualité et fraîcheur de données dépassaient largement celles de nos clients — nous adoptons donc par défaut nos propres données comme référence.
Les garde-fous ne servent pas uniquement à éviter les erreurs. C’est précisément pour cela que les clients vous paient.
Les garde-fous sont gravement sous-estimés. Même au sein d’un même produit, chaque cas d’usage exige ses propres garde-fous. Pour nous, un prospect issu des services financiers réglementés nécessite des garanties totalement différentes de celles requises pour un client SaaS du marché intermédiaire. Ces garanties imprègnent la manière dont l’agent rédige les contenus, à qui il peut s’adresser, quelles données il peut consulter, ce qu’il peut dire lors d’un appel téléphonique, et comment chaque décision est enregistrée.
Un système « taille unique » s’effondre face à cette diversité. Les garde-fous doivent être construits par cas d’usage, configurés par client et audité en continu. Ce travail incombe entièrement à l’entreprise applicative. C’est pourquoi nous employons des ingénieurs de déploiement à plein temps (FDE) et des stratèges techniques de déploiement, chargés d’ajuster chaque solution aux besoins spécifiques de chaque client. Par exemple, nous collaborons avec une institution figurant parmi le Top 1000 mondial, menant des campagnes d’appels téléphoniques consentis auprès de sa vaste clientèle de PME. Les premières itérations affichaient un faible taux de réponse — nous avons dû itérer rapidement pour apprendre à capter l’attention de ce public spécifique durant les dix premières secondes de l’appel. Le comportement des dirigeants de PME diffère radicalement de celui des acheteurs B2B de grande entreprise ou des consommateurs. Nous créons aujourd’hui, pour ce client, plus d’opportunités commerciales en une seule journée que l’ensemble de son équipe commerciale ne parvient à générer en un mois pour ce segment.
L’assurance comme exemple — conseils pratiques du PDG de FurtherAI
Les ventes constituent un exemple. L’assurance en est un autre, illustrant la même idée sous un angle différent. Voici les réflexions du PDG de FurtherAI, Aman Gour, sur la manière de construire « hors du chemin » :
Lorsque nous avons commencé à déployer l’IA dans de vraies activités d’assurance, nous entendions constamment une hypothèse précise : « Le modèle est l’intelligence, et le workflow n’est qu’un échafaudage autour de lui. »
À mesure que nous collaborons avec un nombre croissant d’assureurs, nous sommes de plus en plus convaincus que cette vision est erronée.
Dans le secteur de l’assurance, beaucoup d’intelligence réside précisément dans le workflow lui-même. Deux assureurs peuvent faire passer une demande d’assurance par un parcours apparemment identique : soumission, examen, proposition, souscription. Le parcours est la partie simple. Ce qui distingue les deux sociétés, c’est tout ce qui se passe à l’intérieur : quels risques doivent être signalés, quels signaux de sinistre sont importants, quelle règle de préférence en matière de risque prime en cas de conflit, quand une signature manuelle est requise, quels données externes doivent être sollicitées, et comment la décision finale est-elle enregistrée.
Cette logique n’existe pas dans un moteur de règles propre et rigide. Elle est dispersée dans les procédures opérationnelles standard, les validations managériales, les principes de souscription, les préférences spécifiques en matière de risque de l’entreprise, et des années d’expérience opérationnelle. Une grande partie de ces éléments n’est pas documentée sous une forme directement exploitable par un modèle.
C’est pourquoi nous ne croyons ni aux agents purement cognitifs, qui raisonnent chaque fois à partir de zéro, ni aux workflows rigides, qui s’effondrent face à la complexité du monde réel. Ce que nous construisons, c’est un workflow intelligent. Le workflow offre répétabilité, traçabilité et maîtrise des coûts. L’agent gère la variabilité et intervient pour rétablir le cours normal lorsque le chemin idéal est interrompu. L’humain reste impliqué aux moments critiques où une responsabilité décisionnelle est requise.
Dès le premier jour, cela automatise des tâches manuelles. Mais avec le temps, chaque signalement devient un signal, chaque exception un retour d’information, chaque correction manuelle révèle une lacune dans le manuel opérationnel. Au fil du temps, le workflow cesse d’être un simple script pour devenir la mémoire opérationnelle de l’assureur. C’est une dimension difficilement accessible aux laboratoires. Ils continueront à publier des modèles meilleurs, des agents généraux plus performants — et cela va bien. Mais ils ne passeront jamais assez de temps dans les workflows de production des assureurs pour comprendre pourquoi un compte a été signalé, pourquoi un risque a été refusé, ou pourquoi un souscripteur a eu raison de contourner les lignes directrices de préférence en matière de risque.
Cette compréhension ne peut naître que d’un déploiement répété, des milliers de fois, dans un environnement de production. Le workflow que vous livrez le jour un n’est pas votre fossé de protection. Ce sont les boucles créées par l’usage en production, au fil du temps, qui le deviennent.
Pour nous, c’est précisément cela, « construire hors du chemin ».
Comment savoir si vous êtes « ailleurs dans le pays d’Oz » ?
Test des outils et des étapes : Combien d’étapes ce travail nécessite-t-il ? Quelle complexité d’outils devez-vous développer pour le soutenir ? Comparez une recherche IA horizontale sur Google Drive — une étape, un outil, une tolérance élevée aux erreurs (l’utilisateur lit le résumé et peut reformuler sa demande s’il n’est pas satisfait) — avec une révision juridique multi-étapes fondée sur trois ans de précédents d’études juridiques : des dizaines d’étapes traversant plusieurs outils, une sortie devant être validée par un associé, voire défendue devant un tribunal. Les deux semblent « des agents qui accomplissent un travail », mais seul le second exige un logiciel profond, construit sur plusieurs années par une équipe fortement focalisée.
Test du système : Construisez-vous un système que le client utilise pour exécuter son travail, ou un outil placé au-dessus des systèmes existants du client ? Un système possède le workflow de bout en bout — capture des données, gouvernance, enregistrement de la réalisation — ce sont les éléments vers lesquels le client pointe lorsqu’il décrit comment le travail réel se déroule. Un outil, quant à lui, ajoute simplement de l’intelligence à un workflow déjà en place chez le client. Les scénarios d’outils génèrent certes des revenus réels, mais les laboratoires peuvent les lui ravir, car le client ne dépend pas de vous comme couche d’orchestration. Un ACV élevé est souvent un indicateur de système, car un système remplace une ressource humaine réelle et est rémunéré en conséquence — mais ce n’est pas une garantie. Demandez-vous : si un laboratoire lançait un produit censé vous concurrencer directement, le client aurait-il encore besoin de votre outil ? Si oui, vous construisez un système. Si non, vous construisez un outil — même si votre ACV est élevé.
Test du fonds spéculatif / compte de résultat : La performance des laboratoires est évaluée sur la base de benchmarks, tandis que celle d’« ailleurs dans le pays d’Oz » est jugée sur le compte de résultat du client. Vos clients se moquent de votre score sur SWE-Bench ou MMLU — ce qui les intéresse, c’est si votre agent a conclu la vente, a correctement révisé le contrat, ou a souscrit la bonne police d’assurance. Si leur attention se porte sur les résultats d’un workflow spécifique, et non sur des scores de capacités générales, alors vous êtes « ailleurs dans le pays d’Oz ». Si, en revanche, ils paient pour des capacités générales, ce que vous leur vendez est accessible via un abonnement à Claude ou à Codex. Les meilleures entreprises d’agents doivent fonctionner comme des fonds spéculatifs — remporter la victoire grâce à l’alpha généré dans le compte de résultat du client, et non grâce à des scores de benchmark.
Les deux peuvent (et le feront) gagner
Nous verrons d’importants vainqueurs à la fois « sur le chemin de briques jaunes » et « hors du chemin ». Les modèles continueront de triompher, car ils possèdent les modèles eux-mêmes, ainsi que les canaux de distribution des outils horizontaux qu’ils conçoivent.
« Ailleurs dans le pays d’Oz » peut aussi gagner, à condition de posséder le système de travail — l’interface où le travail réel de l’entreprise s’exécute, et d’où les données circulent et sont capturées. Ces entreprises détiennent la capture des données, le système d’actions du workflow et la gouvernance. À mesure que les workflows plus complexes se développent dans les secteurs verticaux, ils s’accumulent pour former une expérience centrale dont les clients dépendent. Lorsque de nouveaux modèles seront publiés, par les acteurs existants ou par de nouveaux entrants, ces entreprises deviendront la couche qui les intègre et les livre aux clients. Les modèles sous-jacents sont interchangeables ; le système de travail, lui, ne l’est pas.
Le prochain cycle du logiciel d’entreprise sera construit « hors du chemin ».
Si vous construisez cela, contactez-nous à l’adresse : jschmidt@a16z.com.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
a16z
