Note de la rédaction : Alors que les capacités des grands modèles continuent de progresser, la couche applicative de l'IA fait face à une anxiété répandue : si des sociétés comme OpenAI, Anthropic, etc., maîtrisent à la fois les modèles de base, les canaux de distribution et l'avantage de marque, que reste-t-il à faire aux startups dans la couche application ?
C'est précisément la question à laquelle tente de répondre Joe Schmidt, partenaire chez a16z, dans cet article. Il emprunte la métaphore de la « route de briques jaunes » du Magicien d'Oz pour classer les opportunités d'applications d'IA en deux catégories : la première est la voie principale où les sociétés de grands modèles s'engagent elles-mêmes, comme la génération de code, l'écriture, la création d'images, les agents génériques ou les assistants de bureau horizontaux. L'autre ce sont les « autres parties du pays d'Oz », c'est-à-dire les scénarios verticaux, profonds dans les processus sectoriels, dépendants de flux de travail complexes, de sédimentation des données, de gouvernance de la conformité et de capacités d'intégration système.
Pour lui, la véritable opportunité pour les startups se trouve dans cette dernière catégorie.
De la vente à l'assurance, Joe Schmidt répète la même logique : ce pour quoi les entreprises sont vraiment prêtes à payer, ce n'est pas une fenêtre de chat plus intelligente, mais un système qui assume la responsabilité des résultats métier. Il doit comprendre l'état chaotique des données clients, gérer les validations multiples et les cas limites, assumer la responsabilité de la conformité et de l'audit, et aussi, lorsque les modèles évoluent, effectuer pour le client la migration, le routage et l'optimisation des coûts.
C'est également le jugement central de cet article sur la prochaine génération de logiciels d'entreprise : les modèles de base deviendront de plus en plus puissants, mais aussi de plus en plus remplaçables ; ce qui est vraiment irremplaçable, c'est les données, les processus, les capacités de gouvernance et la mémoire opérationnelle sédimentés autour d'industries et de flux de travail spécifiques. L'opportunité pour les entreprises d'applications d'IA ne réside pas dans la lutte avec les sociétés de modèles pour la « route de briques jaunes », mais dans l'exploration de ces lieux plus complexes, plus désordonnés, plus lents, mais aussi plus proches de la véritable valeur commerciale.
Voici l'article original :
Récemment, j'entends sans cesse la même question de la part de fondateurs et de futurs employés : reste-t-il quelque chose à faire dans la couche application de l'IA ? Ou bien OpenAI et Anthropic finiront-ils par tout tuer ?
Derrière cette question se cache une anxiété typique de l'ère de l'IA. Certains en ont déjà conclu que si l'on ne veut pas être relégué définitivement à la base, les seules positions à valeur durable sont soit au sein des grands laboratoires de modèles, soit dans l'entrepreneuriat dans des domaines de pointe comme la robotique, les hard tech ou assimilés – en théorie, donc, à faire des choses que « les laboratoires ne touchent pas ». Car si chaque type de logiciel doit être avalé, soit directement par Codex ou Claude qui absorberait le travail correspondant, soit par un futur modèle le rendant obsolète, le meilleur choix semble être : fuyez !
Je l'avoue, je suis moi-même presque un maximaliste de l'IA, et je pense qu'ils ont raison à moitié. Les grands laboratoires de modèles entrent effectivement dans de vastes zones de la couche application. Mais la « couche application » n'est pas un ensemble homogène d'opportunités. Le critère de jugement vraiment important est : marchez-vous sur la « route de briques jaunes », ou ailleurs dans le pays d'Oz.
La « route de briques jaunes » est notre métaphore pour décrire le chemin que les grands laboratoires de modèles empruntent et sur lequel ils consacrent d'énormes ressources. Des problèmes comme la génération de code, l'écriture, la création d'images sont naturellement adaptés aux laboratoires parce qu'ils s'améliorent avec l'augmentation des capacités brutes des modèles : chaque dollar investi dans le pré-entraînement et le post-entraînement améliore directement la qualité du produit.
Mais ailleurs dans le pays d'Oz, existent des problèmes plus complexes, généralement plus verticaux. Ils ne se résument pas à fournir simplement un outil horizontal à un utilisateur d'entreprise, en le branchant sur des outils et capacités informatiques standards. La valeur ici provient davantage de l'échafaudage construit autour du modèle : cet échafaudage qui rend la sortie fiable, conforme et véritablement intégrée aux processus métier dans une industrie spécifique. Les capacités brutes du modèle sous-jacent restent bien sûr importantes, mais ne sont plus le tout.
Nous le voyons en temps réel. OpenAI et Anthropic reconnaissent en fait au marché : ils ne peuvent pas résoudre tous les problèmes avec un assistant IA générique unique. Ils ont annoncé investir massivement dans des projets conjoints de déploiement en première ligne, construisant des entreprises entières autour de la configuration et de la personnalisation de modèles pour les entreprises. S'ils pensaient vraiment que la prochaine version de modèle résoudrait ces problèmes, ils n'investiraient pas des milliards dans ce type de projets.
Donc, si vous voulez gagner de l'argent avec des applications d'IA, ne prenez pas la route de briques jaunes, allez construire ailleurs dans le pays d'Oz. Voici ce que nous, ainsi que certains fondateurs de notre portefeuille, avons appris en pratique.
La route de briques jaunes
Si vous fondez une entreprise, la route de briques jaunes est la voie la plus évidente, mais aussi la plus dangereuse. Prenez un modèle haute performance, connectez-le à des connecteurs prêts à l'emploi comme Google Drive, Slack, Salesforce, Notion, GitHub, et superposez une couche d'orchestration d'agents intelligents par-dessus. Ça ressemble à de la magie.
Le problème est que c'est exactement ce que les grands laboratoires de modèles font avec Coworker et Codex. Il est clair qu'ils possèdent le modèle, ce qui signifie qu'ils ont de meilleures marges, un meilleur contrôle, et peuvent aussi exercer un pouvoir de fixation des prix sur tous les acteurs en aval. Mais peut-être plus important encore, ils contrôlent également les choix d'architecture qui déterminent à quels problèmes le produit est adapté. Jusqu'à présent, ils ont très délibérément adopté un modèle « modèle + appel d'outils », qui est précisément le modèle requis pour les travaux horizontaux, à faible nombre d'étapes, sur la route de briques jaunes. Même si une startup parvenait d'une manière ou d'une autre à surpasser Codex ou Claude Code, les grands laboratoires de modèles conservent une énorme capacité de distribution, ainsi que l'aura de marque la plus forte dans le domaine de l'IA.
Si vous êtes une entreprise d'application d'IA qui joue selon le même playbook : se connecter aux mêmes connecteurs, sans sous-agents ou configuration en dessous, et sans canaux de distribution, vous êtes probablement sur une route qui ne mène nulle part.
Ailleurs dans le pays d'Oz
Pour les startups, la situation n'est pas entièrement pessimiste. En dehors de la route de briques jaunes, il existe encore d'énormes opportunités. Les startups peuvent y trouver des clients et résoudre des problèmes complexes.
Ces entreprises construisent des expériences d'agents intelligents : le modèle est tissé dans un réseau complexe d'outils, d'automatisations et d'intégrations – en d'autres termes, du logiciel. Cela rend également la plupart de ces startups naturellement verticales. Elles peuvent se concentrer sur des flux de travail multi-étapes, multi-intervenants, concevoir des sous-agents pour différents rôles et scénarios verticaux, traiter des problèmes difficiles à atteindre pour les plateformes horizontales d'Anthropic et OpenAI : collecter du contexte à travers des systèmes, puis router les tâches vers plusieurs personnes nécessitant une validation à différentes étapes.
Ce type de travail implique généralement un ou plusieurs systèmes hérités, exige souvent des résultats déterministes car l'ambiguïté est inacceptable, et est parfois directement lié à un résultat commercial important. Les grands laboratoires de modèles savent bien sûr combien ces problèmes sont précieux : c'est pourquoi ils construisent leurs propres équipes de configuration externalisées, et c'est pourquoi toute une catégorie d'entreprises de services de renforcement de l'apprentissage pour les grands clients émerge.
Pourquoi le reste du pays d'Oz ne sera pas entièrement occupé par le « Magicien »
Une objection à l'argument ci-dessus est : jusqu'à présent, parier que les modèles ou les laboratoires ne continueront pas à progresser a toujours été un très mauvais pari. Ils vont probablement continuer à s'améliorer et finir par avaler les marchés servis par ces entreprises applicatives.
Les grands laboratoires de modèles vont certainement continuer à progresser. Mais je pense que les entreprises ailleurs dans le pays d'Oz ont, à long terme, plusieurs moyens de se défendre.
Les données et l'effet boule de neige de l'apprentissage
Beaucoup de ce que vous internalisez vraiment dans une activité n'existe dans aucun ensemble d'entraînement : les conventions sectorielles non écrites, les normes non documentées, la connaissance tribale dans la tête des praticiens. Elles ne sont pas sur l'internet public. Peu importe la puissance de calcul d'entraînement investie, elle ne peut remplacer le fait de pénétrer réellement à l'intérieur des flux de travail où réside cette connaissance.
Deux effets boule de neige se superposent ici : l'un est l'effet inter-clients, c'est-à-dire que lorsque vous voyez plus de variations du même type de problème, les modèles s'amplifient de manière exponentielle ; l'autre est l'effet intra-client, c'est-à-dire que les raisons derrière des décisions spécifiques, les exceptions non dites, les règles empiriques propres à l'entreprise, n'émergent que lorsque les utilisateurs interagissent réellement avec le système.
Même si les données clients ne peuvent pas être utilisées d'un client à l'autre, l'entreprise applicative peut toujours tirer parti de la reconnaissance de modèles pour différents types de problèmes clients et l'utiliser pour guider la conception architecturale des problèmes futurs. Une entreprise qui a déjà fait traiter cent modifications de ligne rouge juridique, mille cycles de souscription d'assurance, ou dix mille activités de développement commercial SDR par ses agents, a une compréhension de la forme des problèmes qu'un nouvel arrivant ne peut pas reproduire dès le premier lancement d'un nouvel agent.
Théoriquement, un agent horizontal pourrait construire la même infrastructure d'apprentissage. Mais la raison pour laquelle il ne le fait pas, outre le manque de concentration, est principalement l'expérience utilisateur. Capturer ce type de connaissance dépend entièrement du type d'interface de flux de travail que vous offrez à l'utilisateur. Les acteurs verticaux peuvent concevoir ces interfaces autour des informations qui ont vraiment besoin d'être exposées pour un flux de travail spécifique, ce que les outils horizontaux ne peuvent pas faire. Les ensembles d'évaluation, les sorties annotées, les systèmes de classification des cas limites peuvent se combiner en un effet boule de neige de données dans un domaine vertical, soutenant ainsi le fine-tuning. Un nouvel arrivant sans une exposition en environnement de production de taille équivalente aura du mal à générer un tel effet. Sa faisabilité dépend des droits sur les données, de l'utilisation productive accumulée et de la structure contractuelle avec les clients, mais la reconnaissance de modèles elle-même continue de s'accumuler.
Gérer la volatilité et la complexité des modèles
Les grands laboratoires de modèles font déjà du routage en interne : appeler différentes catégories de modèles pour différentes requêtes, utiliser des ensembles de modèles en coulisses. Mais ce qu'ils ne peuvent pas faire, c'est du routage inter-fournisseurs, ni évaluer facilement les modèles concurrents pour une sous-tâche spécifique, ou utiliser le véritable modèle open source fine-tuné le plus adapté pour un point étroit.
Les entreprises ailleurs dans le pays d'Oz choisiront le modèle le plus approprié pour chaque sous-tâche dans tout le marché des modèles, et pas seulement le modèle publié par un laboratoire mère. Elles assumeront également les tâches que personne ne veut faire : ré-exécuter les évaluations à chaque nouvelle version de modèle, recalibrer les prompts pour les cas limites des clients, mettre en production sans casser l'environnement. Les grands laboratoires de modèles ne feront pas cela pour le client. Ils vous vendent le nouveau modèle et vous disent de migrer. Les entreprises ailleurs dans le pays d'Oz absorbent le coût de migration. Le client obtient la meilleure capacité intelligente du marché, ainsi que la continuité à travers chaque mise à niveau.
Optimisation des coûts
Envoyer chaque requête à Opus 4.7 est le moyen le plus rapide de faire virer la marge brute au négatif. Les meilleures entreprises d'Oz feront du routage entre différents niveaux de modèles : les tâches les plus difficiles aux modèles de pointe, la plupart des tâches aux modèles intermédiaires, et dans les zones où cela a été prouvé possible, utiliser des modèles personnalisés plus petits ou fine-tunés.
Certaines de ces entreprises font maintenant leur propre post-entraînement sur cette base, optimisant le modèle pour le petit segment de travail qui intéresse vraiment le client, et fournissant le service à un coût bien inférieur à un appel API de pointe. Les grands laboratoires de modèles fixent un prix « plancher » : le niveau d'intelligence minimum que vous pouvez obtenir pour X dollars. Les entreprises d'Oz vendent l'inverse : le coût en dollars le plus bas pour le niveau d'intelligence réellement nécessaire par un flux de travail spécifique. Cela n'est possible que si vous savez très précisément quel niveau d'intelligence est nécessaire pour chaque sous-tâche. Et les grands laboratoires de modèles ne peuvent structurellement pas connaître chaque tâche dans chaque secteur vertical. Finalement, cela se traduit directement par une tarification par résultat plus basse et plus contrôlable.
Gouvernance
Devenir le plan de contrôle où un client exécute l'IA dans un domaine vertical crée une valeur considérable. Ce plan de contrôle est l'endroit où convergent les autorisations, l'audit, ce que l'agent est autorisé à faire, et ce que l'agent a réellement fait.
Ce plan de contrôle est construit sur des garde-fous pour des cas d'usage spécifiques, et ces garde-fous sont complètement différents selon les secteurs et les types de postes. Parce que ces entreprises possèdent de bout en bout les outils, les flux de travail et les données auxquels l'agent a accès, elles peuvent fournir des résultats déterministres d'une manière difficile à réaliser pour les outils horizontaux. Elles absorbent également la complexité réglementaire pour l'acheteur final : les règles fédérales de procédure civile et les règles de déontologie des avocats dans le droit, HIPAA dans la santé, les règles de la SEC et de la FINRA en finance, la régulation des assurances au niveau des États, etc. Les acteurs horizontaux ne peuvent pas faire cela de manière crédible sans se transformer en cent secteurs verticaux différents. Le DSI a besoin d'un partenaire qui peut s'engager clairement dans un contrat : il assumera la responsabilité du traitement de la conformité pour les agents qu'il fournit.
Tout cela revient finalement à la même chose : la concentration.
Cette concentration peut être un secteur vertical, comme l'assurance, le droit, la comptabilité ; ou une fonction suffisamment approfondie, comme les ventes, le service client, les finances. Quelle qu'elle soit, ce travail nécessite qu'une équipe s'immerge longtemps dans le même type de clientèle, comprenne ses flux de travail, ses cas limites et ses exigences réglementaires. Les grands laboratoires de modèles ne sont pas construits pour cela. Ils doivent servir tout le monde, couvrir partout, et c'est aussi pourquoi ils ont initialement construit la route de briques jaunes. Le même compromis les empêchera d'entrer ailleurs dans le pays d'Oz : vous pouvez être partout à la fois, ou excellent dans une chose, mais pas les deux.
L'exemple des ventes : conseils pratiques du CEO technique de 11x
En pratique, comment comprendre cela ? Voici quelques conseils pratiques de Prabhav Jain, CEO de 11x.
Se concentrer sur les résultats
Un chemin tactique viable pour construire une entreprise résistante aux grands laboratoires de modèles est de partir des résultats concrets qui intéressent vraiment le client. Pour nous, ce résultat est d'aider les entreprises à générer plus de prospects et de pipeline de ventes.
À partir de là, les questions deviennent très spécifiques : quelles activités voulons-nous posséder de bout en bout et qui font réellement progresser le pipeline de ventes ? Décomposez chaque activité en tâches. Quelles tâches conviennent à un agent, lesquelles non ? Quelles tâches nécessitent des insights sectoriels complexes, lesquelles non ? Les grands laboratoires de modèles lanceront aussi des flux de travail, mais lorsqu'une étape de flux de travail comporte de nombreuses étapes, des entrées désordonnées, un état difficile à interpréter, ou des contraintes du monde réel, un simple meilleur modèle ne suffit pas. Le travail revient alors à l'ingénierie logicielle traditionnelle, et à ce niveau, les grands laboratoires de modèles n'ont pas d'avantage sur une entreprise applicative concentrée.
Par exemple, certaines des tâches que nous traitons incluent : la prospection de leads basée sur des signaux personnalisés, l'enrichissement d'informations sur les leads, la recherche approfondie sur les comptes, l'extraction de contexte du CRM, la rédaction de messages pour différents canaux, l'agent de qualification des leads, et le système de délivrabilité des e-mails. Certaines sont des tâches d'agent, d'autres non. Ces tâches ne se font pas en une seule prompt, elles nécessitent des capacités d'ingénierie approfondies.
L'idée clé de l'analogie avec le pays d'Oz est : dans tout flux de travail réel, environ la moitié des tâches ne sont pas des tâches d'agent, et cette moitié n'apporte pas d'avantage de laboratoire. Sous la couche du modèle, leur capacité à écrire du logiciel déterministe n'est pas meilleure que la vôtre. Et l'autre moitié des tâches d'agent exige toujours de vous que vous ajustiez, entraîniez et contraigniez le modèle autour du résultat réellement désiré.
La connaissance du domaine n'est souvent pas dans les données d'entraînement générales. Ces capacités doivent être construites de bas en haut à partir du secteur vertical ou de la fonction spécifique, et fournies au modèle au bon moment dans le flux de travail. Lorsque notre agent qualifie un lead entrant par téléphone, il doit être formé à comprendre ce qui constitue une bonne conversation de vente pour un secteur et un profil d'utilisateur spécifiques. C'est le travail de l'entreprise applicative, et cette capacité s'amplifie exponentiellement.
Plus important encore, ces capacités deviennent constamment obsolètes, car l'entreprise elle-même évolue. Ainsi, votre capacité à faire évoluer continuellement le flux de travail et le contexte devient elle-même un avantage concurrentiel. Par exemple, lorsque nous avons commencé le produit d'emailing sortant à grande échelle, les « e-mails écrits par l'IA » commençaient tout juste à apparaître. Aujourd'hui, les gens ont développé une sensibilité aiguë pour distinguer quels e-mails sont écrits par l'IA et lesquels ressemblent plus à des humains, et le point clé est que ce jugement change tous les quelques mois. Nos agents doivent s'ajuster constamment à la dynamique du marché, mais c'est précisément là que se construit le fossé concurrentiel. En fait, malgré cette dynamique, notre taux de réponse positive a été multiplié par 4 au cours des derniers mois et a créé des centaines de millions de dollars de pipeline de ventes pour nos clients.
S'attaquer à des problèmes de haute complexité
Les problèmes complexes sont l'endroit où la valeur commerciale se libère réellement. Sinon, vous risquez de vous retrouver avec une simple couche d'emballage mince.
Décomposez un problème commercial suffisamment complexe, et vous verrez rapidement le désordre apparaître. Voici un exemple simple en apparence du domaine GTM : si une entreprise est déjà votre cliente, vous ne devriez pas contacter un contact dans cette entreprise. Mais ce n'est pas du tout simple.
Peut-être avez-vous le domaine de cette entreprise dans votre CRM. Mais que faire des entreprises avec des dizaines de filiales ? Et si l'enregistrement dans Salesforce utilise le domaine de la société mère ? Et si un champ de correspondance obsolète dans Salesforce vous fait envoyer un e-mail de prospection froide au Chief Revenue Officer d'un client existant ? Les données du monde réel sont désordonnées. Les humains ont du mal à les gérer, et les modèles ne franchissent pas miraculeusement ce seuil. Pour créer de l'ordre dans ce chaos, il faut concevoir des agents spécialisés autour de la forme spécifique du problème, et non pas simplement pointer un assistant générique vers le CRM. En fait, basé sur nos données, nous constatons que notre qualité et notre fraîcheur des données sont déjà supérieures à celles du client lui-même, donc par défaut, nous nous ancrons sur nos propres données.
Les garde-fous ne servent pas seulement à empêcher les mauvaises choses. C'est précisément pour cela que le client paie
Les garde-fous sont gravement sous-estimés. Même au sein d'un même produit, chaque cas d'usage nécessite ses propres garde-fous. Pour nous, les garanties requises pour un lead financier réglementé sont complètement différentes de celles pour un client SaaS de taille moyenne. Et ces garanties se répercutent sur la façon dont l'agent écrit, qui il peut contacter, quelles données il peut accéder, ce qu'il peut dire au téléphone, et comment chaque décision est enregistrée.
Un système « unique pour tous » s'effondrerait face à ces différences. Les garde-fous doivent être construits par cas d'usage, configurés par client, et audités en continu, et ce travail incombe entièrement à l'entreprise applicative. C'est pourquoi nous avons besoin d'ingénieurs de déploiement sur site et de stratèges de déploiement technique pour ajuster selon les exigences de chaque client.
Par exemple, nous avons travaillé avec une institution du Fortune 1000 pour effectuer des appels sortants vocaux avec consentement à leur vaste base de clients PME. Dans les premiers essais, le taux de décroché était faible. Nous avons dû itérer rapidement, apprendre comment engager ce public spécifique dans les 10 premières secondes de l'appel. Les propriétaires de PME se comportent différemment des acheteurs B2B de grande taille ou des consommateurs. Aujourd'hui, nous créons pour eux en une journée plus d'opportunités de vente que l'ensemble de leur équipe commerciale ne pouvait en créer en un mois sur ce segment.
L'exemple de l'assurance : conseils pratiques du CEO de FurtherAI
Les ventes ne sont qu'un exemple. L'assurance en est un autre, illustrant la même chose sous un angle différent. Voici comment Aman Gour, CEO de FurtherAI, comprend la « construction hors de la route de briques jaunes ».
Lorsque nous avons commencé à déployer l'IA dans les opérations réelles d'assurance, nous entendions constamment une hypothèse : le modèle est l'intelligence, le flux de travail n'est que l'échafaudage construit autour.
Mais plus nous travaillions avec des compagnies d'assurance, plus nous étions convaincus que c'était exactement l'inverse.
Dans l'industrie de l'assurance, beaucoup d'intelligence réside déjà dans le flux de travail lui-même. Deux compagnies d'assurance peuvent faire passer une soumission par un chemin qui semble identique : soumission, examen, devis, souscription. Le chemin lui-même est facile. Ce qui distingue vraiment les deux compagnies, c'est tout ce qui est à l'intérieur du chemin : quels risques nécessitent une escalade, quels signaux de perte sont importants, quelle règle de préférence de souscription prime en cas de conflit, quand une confirmation humaine est obligatoire, quelles données externes doivent être récupérées, et comment la décision finale est enregistrée.
Cette logique n'existe pas dans un moteur de règles propre. Elle est dispersée dans les procédures opérationnelles standard, les validations des managers, la philosophie de souscription, l'appétit pour le risque spécifique à la compagnie, et des années d'expérience opérationnelle. Beaucoup de cela n'est pas écrit sous une forme directement lisible par un modèle.
C'est pourquoi nous ne croyons pas aux agents purs qui raisonnent à partir de zéro à chaque fois, ni aux flux de travail rigides qui s'effondrent face à la complexité réelle. Au lieu de cela, nous construisons des flux de travail d'agents. Le flux de travail apporte la répétabilité, l'auditabilité et le contrôle des coûts ; l'agent gère la variabilité et rétablit le processus lorsque le chemin idéal est rompu ; les humains restent dans la boucle aux endroits impliquant jugement et responsabilité.
Le premier jour, ce système automatise le travail manuel. Mais avec le temps, chaque escalade devient un signal, chaque exception un retour d'information, chaque correction humaine vous dit où le manuel d'opérations d'origine est incomplet. Avec le temps, le flux de travail ne devient plus juste un script, mais la mémoire opérationnelle de la compagnie d'assurance.
C'est précisément la partie que les grands laboratoires de modèles ont du mal à atteindre. Ils continueront à publier de meilleurs modèles et de meilleurs agents généraux, et ils devraient le faire. Mais ils ne resteront pas longtemps dans le flux de travail de production d'une compagnie d'assurance pour apprendre pourquoi tel compte a été escaladé, pourquoi tel risque a été refusé, ou pourquoi tel souscripteur a outrepassé les directives d'appétit pour le risque, et s'est avéré avoir raison.
Cette compréhension ne peut venir que de l'exécution du même flux de travail des milliers de fois en environnement de production. Le flux de travail que vous livrez le premier jour n'est pas le fossé concurrentiel. La boucle formée par l'utilisation en production au fil du temps, c'est le fossé concurrentiel.
Pour nous, c'est le sens de « construire hors de la route de briques jaunes ».
Comment savoir si vous êtes ailleurs dans le pays d'Oz, ou toujours sur la route de briques jaunes ?
Test des outils et des étapes
Combien d'étapes ce travail nécessite-t-il ? À quel point les outils que vous devez construire pour le supporter sont-ils complexes ?
Comparez une recherche par une IA horizontale dans Google Drive : c'est une opération en une étape sur un outil, avec une grande tolérance aux erreurs dans le résultat. L'utilisateur lit le résumé, et si c'est faux, il repose la question.
Maintenant, regardez une tâche de modification de ligne rouge juridique en plusieurs étapes basée sur des précédents des trois dernières années d'un cabinet d'avocats : cela peut impliquer des dizaines d'étapes, plusieurs outils, la sortie doit passer par une revue de partenaire, et pourrait même nécessiter une argumentation en cour. Les deux ressemblent à « un agent qui fait quelque chose », mais seul le second nécessite ce logiciel profond construit par une équipe concentrée pendant des années.
Test du système
Construisez-vous un système dans lequel le client exécute son travail, ou ajoutez-vous un outil sur un système que le client possède déjà ?
Un système possède le flux de travail de bout en bout : capture des données, gouvernance, enregistrement du travail effectué. Le client pointe vers ce système en décrivant comment le travail réel se produit. Un outil ajoute juste une couche d'intelligence au flux de travail que le client exécute déjà.
Les produits de type outil peuvent aussi générer de vrais revenus, mais les grands laboratoires de modèles peuvent plus facilement les reprendre, car le client ne dépend pas de vous en tant que couche d'orchestration. Un ACV élevé est souvent le signe d'un produit de type système, car le système remplace de vrais effectifs, et est donc payé en conséquence. Mais ce n'est pas une garantie absolue. Vous devez vous demander : si un grand laboratoire de modèles lance un produit qui semble directement concurrent du vôtre, le client aura-t-il encore besoin de votre outil ? Si la réponse est oui, vous construisez un système. Si la réponse est non, vous êtes un outil – même si votre ACV est élevé.
Test du fonds de couverture / du compte de résultat
La performance des grands laboratoires de modèles est jugée par des benchmarks ; la performance des entreprises ailleurs dans le pays d'Oz est jugée par le compte de résultat du client.
Le client ne se soucie pas du score de votre modèle sur SWE-Bench ou MMLU. Il se soucie de : votre agent a-t-il conclu la vente, a-t-il correctement modifié la ligne rouge du contrat, a-t-il souscrit la bonne police. Si le client se concentre sur le résultat d'un flux de travail spécifique, et non sur un score de capacité générique, vous êtes ailleurs dans le pays d'Oz. Si le client paie pour une capacité générique, alors vous vendez ce qu'il peut obtenir via un siège Claude ou Codex.
Les meilleures entreprises d'agents doivent exécuter comme un fonds de couverture : elles gagnent sur l'alpha, et l'alpha se mesure dans le compte de résultat du client, pas dans les scores de benchmark.
Les deux peuvent gagner, et gagneront
Nous verrons d'énormes gagnants à la fois sur la route de briques jaunes et en dehors. Les modèles continueront de gagner, car ils possèdent le modèle et ont la capacité de distribution conçue pour les outils horizontaux.
Ailleurs dans le pays d'Oz peut aussi gagner, à condition de posséder le système de travail : c'est-à-dire l'interface où l'entreprise exécute réellement le travail, et les données qui y circulent et sont capturées. Ces entreprises possèdent la capture de données, le système d'actions de flux de travail et la gouvernance. À mesure que les flux de travail complexes d'un domaine vertical mûrissent, ils se combinent en une expérience centrale dont le client ne peut se passer. À mesure que les acteurs existants et les nouveaux entrants publient de nouvelles générations de modèles, cette entreprise devient la couche qui intègre et livre ces modèles au client. Le modèle sous-jacent est remplaçable, mais le système de travail ne l'est pas.
La prochaine génération de logiciels d'entreprise sera construite ailleurs que sur la route de briques jaunes.
