Pourquoi la couche applicative n'est pas morte
La question que je ne cesse d'entendre de la part des fondateurs et des futurs employés : reste-t-il une couche applicative d'IA à construire, ou OpenAI et Anthropic vont-ils tout tuer ?
Il y a une forme particulière de psychose liée à l'IA derrière cette question. Certains en ont conclu que les seuls endroits durables pour éviter la classe inférieure permanente sont à l'intérieur d'un grand laboratoire ou à la frontière, en construisant dans la robotique, la hardtech, ou similaire – théoriquement tout ce que « les laboratoires ne peuvent pas toucher ». Si chaque logiciel est sur le point d'être dévoré, soit par Codex ou Claude qui absorbent directement le travail, soit par un futur modèle qui rendra tout ce que vous avez construit inutile, alors fuyez !
Écoutez, je suis un maximaliste de l'IA autant que quiconque, et je pense qu'ils ont à moitié raison. Les laboratoires viennent vraiment pour une énorme partie de la surface applicative. Mais « la couche applicative » n'est pas une seule opportunité homogène. La bonne façon de voir les choses est de savoir si vous êtes sur la Route de Briques Jaunes ou ailleurs dans Oz.
La Route de Briques Jaunes est notre raccourci pour le chemin que les laboratoires empruntent, où ils consacrent des ressources extraordinaires. La raison pour laquelle les laboratoires sont les mieux adaptés aux problèmes comme la génération de code, l'écriture ou la création d'images est que ces problèmes s'améliorent avec la capacité brute du modèle : chaque dollar dépensé en pré-entraînement et post-entraînement améliore la qualité du produit. Pendant ce temps, le reste d'Oz est habité par des problèmes plus complexes, souvent verticaux, qui ne se résument pas à donner à un utilisateur professionnel un outil horizontal avec accès à des outils standard et à une utilisation de l'ordinateur. La valeur vient moins de la capacité brute du modèle sous-jacent (bien que cela reste important !) que de l'échafaudage qui l'entoure, rendant la sortie fiable, conforme et opérationnelle au sein d'une industrie spécifique.
Nous voyons cela se dérouler en temps réel alors qu'OpenAI et Anthropic disent effectivement au marché qu'ils ne peuvent pas résoudre tous les problèmes avec un collègue IA générique. Ils ont annoncé des coentreprises massives déployées sur le terrain pour construire des entreprises entières autour de la configuration et de la personnalisation de leurs modèles pour l'entreprise. Vous n'investissez pas des milliards dans ces programmes si vous pensez que la prochaine version du modèle va s'en charger.
Donc, si vous voulez vous enrichir en construisant des applications d'IA – évitez la route de briques jaunes et construisez ailleurs dans Oz. Voici ce que nous avons appris, et ce que certains fondateurs de notre portefeuille ont appris, sur ce qui fonctionne.
La Route de Briques Jaunes
Si vous créez une entreprise, la Route de Briques Jaunes est le chemin le plus évident à emprunter, mais c'est le plus dangereux. Prenez un modèle performant, branchez quelques connecteurs standard (comme G Drive, Slack, Salesforce, Notion, GitHub), et ajoutez une couche d'orchestration agentique par-dessus. Magie !
Le problème est que c'est exactement ce que les laboratoires font avec Cowork et Codex. Évidemment, ils possèdent le modèle, ce qui leur donne de meilleures marges, du contrôle et la capacité d'exercer un pouvoir de fixation des prix sur quiconque est en aval. Mais peut-être plus important encore, ils possèdent également les choix architecturaux qui définissent ce que leurs produits sont conçus pour bien résoudre. Ils ont été délibérés jusqu'à présent sur le modèle plus le modèle d'appels d'outils, et c'est exactement ce que le travail horizontal à faible nombre d'étapes sur la route nécessite. Même si une startup pouvait surpasser Codex ou Claude Code, les laboratoires ont des bras de distribution massifs et le plus grand halo de marque dans l'IA.
Si vous êtes une entreprise d'applications d'IA qui exécute ce playbook avec les mêmes connecteurs, sans sous-agents ni configuration en dessous, et sans distribution, vous marchez probablement sur une route qui ne mène nulle part.
Le Reste d'Oz
Tout n'est pas sombre pour les startups. Il existe une énorme opportunité en dehors de la Route de Briques Jaunes, où les startups ont une voie claire pour posséder leur client et résoudre des problèmes complexes.
Ces entreprises construisent des expériences agentiques où le modèle est tissé à travers un réseau complexe d'outils, d'automatisations et d'intégrations (lire : logiciels), ce qui amène la plupart de ces startups à être verticales par défaut. Elles peuvent se concentrer sur un travail multi-étapes et multi-acteurs, avec des sous-agents pour des tâches spécifiques à un rôle et à un secteur, qu'Anthropic et OpenAI ne peuvent pas atteindre avec des plateformes horizontales : rassembler le contexte à travers les systèmes, puis le router à travers plusieurs humains qui doivent approuver à différentes étapes. Cela implique souvent un ou plusieurs systèmes existants, tend à nécessiter des résultats déterministes où l'ambiguïté n'est pas acceptable, et est parfois lié à un résultat commercial précieux. Les laboratoires comprennent à quel point ces problèmes sont précieux : c'est pourquoi ils construisent leurs propres ateliers de configuration externalisés, et pourquoi toute une classe haut de gamme d'entreprises d'apprentissage par renforcement existe.
Pourquoi le reste d'Oz ne sera pas possédé par le Magicien
La réponse à ce qui précède serait que jusqu'à présent, parier contre l'amélioration des modèles/laboratoires a été un assez mauvais calcul. Ils continueront probablement à s'améliorer et finiront par empiéter sur le marché desservi par ces entreprises de la couche applicative.
Les laboratoires vont certainement s'améliorer, mais je dirais qu'il y a plusieurs façons pour le reste d'Oz de se défendre au fil du temps :
Volants d'inertie de données et d'apprentissage :
Une grande partie de ce que vous intériorisez ne se trouve dans aucun ensemble d'entraînement — les normes industrielles non écrites, les standards non documentés, la connaissance tribale qui vit dans la tête des praticiens. Rien de tout cela n'est sur le web public. Aucune quantité de calcul d'entraînement ne remplace le fait d'être à l'intérieur des flux de travail où cette connaissance vit réellement. Il y a deux volants d'inertie empilés l'un sur l'autre ici : un entre les clients — des modèles qui se cumulent à mesure que vous voyez plus de variantes du même problème — et un au sein du client — le pourquoi derrière des décisions spécifiques, les exceptions non dites, les propres règles empiriques de l'entreprise qui n'émergent que par une interaction réelle avec le système.
Même si les données clients ne peuvent pas être utilisées entre les clients, les entreprises d'applications pourront tirer parti de la reconnaissance de modèles à travers les types de problèmes des clients, et l'utiliser pour informer la bonne architecture pour les problèmes futurs. Une entreprise qui a fait passer ses agents à travers une centaine de révisions juridiques, un millier de cycles de souscription d'assurance, ou dix mille campagnes SDR a intériorisé la forme du problème d'une manière que le prochain entrant ne peut pas reproduire en lançant un nouvel agent pour la première fois.
Un agent horizontal pourrait en principe construire la même infrastructure d'apprentissage. La raison pour laquelle il ne le fait pas, au-delà de la pure concentration, est l'UX : capturer ce type de connaissance dépend entièrement des surfaces de flux de travail que vous donnez à l'utilisateur, et les acteurs verticaux peuvent façonner ces surfaces autour de ce dont leur flux de travail a besoin pour faire émerger. Les outils horizontaux ne le peuvent pas. Les ensembles d'évaluation, les sorties étiquetées et les taxonomies de cas limites peuvent se cumuler en un volant d'inertie de données spécifique à un secteur qui peut alimenter un réglage fin que le prochain entrant ne peut pas générer sans une exposition de production comparable. Que cela soit possible dépend des droits sur les données, du volume d'exposition de production accumulé et de la structure des contrats clients, mais la reconnaissance de modèles s'accumule indépendamment.
Gestion de la variabilité et de la complexité des modèles : Les laboratoires font déjà du routage en interne — différentes classes de modèles pour différentes requêtes, des ensembles sous le capot. Ce qu'ils ne peuvent pas faire, c'est router entre fournisseurs, ou évaluer le modèle d'un concurrent pour une sous-tâche spécifique, ou utiliser un réglage fin open source pour la partie étroite où il est réellement le meilleur. L'entreprise du Reste d'Oz choisit le bon modèle pour chaque sous-tâche sur l'ensemble du marché des modèles, pas seulement ce que son laboratoire parent expédie. Elle fait également le travail que personne ne veut faire — relancer les évaluations sur les mises à niveau, recalibrer les invites pour les cas limites du client, déployer sans casser la production — à chaque fois qu'un nouveau modèle arrive. Les laboratoires ne font pas cela pour le compte du client ; ils vous vendent leur prochain modèle et vous disent de migrer. L'entreprise du Reste d'Oz absorbe la migration. Ce que le client obtient, c'est la meilleure intelligence disponible sur l'ensemble du marché, plus la continuité à travers chaque mise à niveau.
Optimisation des coûts : Exécuter chaque requête via Opus 4.7 est le chemin le plus rapide vers des marges brutes négatives. Les meilleures entreprises du Reste d'Oz routent à travers des niveaux de modèles — des modèles de pointe pour les tâches les plus difficiles, des modèles de milieu de gamme pour la masse, des modèles personnalisés ou affinés plus petits là où elles ont gagné le droit de les utiliser. Certaines entraînent maintenant leurs propres modèles en post-entraînement par-dessus, les optimisant pour la tranche étroite de travail qui intéresse leur client et les servant à une fraction du coût d'un appel API de pointe. Les laboratoires fixent le prix plancher : le moins d'intelligence disponible à X€. L'entreprise du Reste d'Oz vend l'inverse — le coût en euros le plus bas pour le niveau spécifique d'intelligence dont le flux de travail a réellement besoin. Cela n'est possible que si vous savez exactement de quel niveau chaque sous-tâche a besoin, ce que les laboratoires ne peuvent structurellement pas savoir dans chaque secteur vertical. Cela se traduit directement par des prix plus bas et contrôlés pour les résultats.
Gouvernance : Il y a une valeur considérable à devenir le plan de contrôle de la façon dont vos clients utilisent l'IA dans ce secteur vertical – l'endroit où les autorisations, l'audit, ce que l'agent est autorisé à faire et ce que l'agent a réellement fait convergent tous. Ce plan de contrôle est construit à partir de garde-fous spécifiques au cas d'utilisation qui semblent complètement différents selon les industries et les types d'emplois. Parce qu'ils possèdent les outils, les flux de travail et les données que l'agent touche de bout en bout, ils peuvent fournir des résultats déterministes d'une manière avec laquelle les outils horizontaux auront du mal. Ils sont également l'entité qui absorbe la complexité réglementaire pour l'acheteur final — les règles FRCP et du barreau dans le domaine juridique, HIPAA dans le secteur de la santé, SEC et FINRA dans la finance, les réglementations des assurances d'État, et ainsi de suite. Un acteur horizontal ne peut pas faire cela de manière crédible sans devenir une centaine de secteurs verticaux différents à la fois. Les DSI veulent avoir un partenaire qui déclare contractuellement qu'il gère la conformité pour les agents qu'il fournit.
Tout cela revient à la même chose : la concentration. Cela pourrait être un secteur vertical (assurance, juridique, comptabilité) ou une fonction réalisée en profondeur (ventes, support client, finance). Dans les deux cas, le travail nécessite une équipe qui se concentre sur un ensemble de clients — ses flux de travail, ses cas limites, ses réglementations. Les laboratoires ne sont pas conçus pour cela. Ils doivent être partout, pour tout le monde, ce qui est la façon dont ils ont construit la Route de Briques Jaunes en premier lieu. Le même compromis les maintient en dehors du reste d'Oz — vous pouvez être partout à la fois, ou vous pouvez être excellent dans une chose. Pas les deux.
Les ventes comme exemple – conseils pratiques du CEO technique de 11x
Comment devriez-vous penser à cela en pratique ? Voici quelques conseils pratiques de Prabhav Jain, le PDG de 11x.
Concentrez-vous sur les résultats
Un chemin tactique pour construire une entreprise résiliente face aux laboratoires est de simplement partir d'un résultat spécifique auquel vos clients tiennent vraiment. Pour nous, c'était aider les entreprises à générer plus de pipeline. À partir de là, les questions deviennent tactiques. Quelles activités voulons-nous posséder de bout en bout qui génèrent réellement du pipeline ? Décomposez chaque activité en tâches. Quelles tâches sont agentiques et lesquelles ne le sont pas. Lesquelles nécessitent une connaissance approfondie du domaine et lesquelles non. Les laboratoires expédieront également des flux de travail, mais lorsque le 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 meilleur modèle seul ne vous y mènera pas. Le travail retombe sur la bonne vieille ingénierie logicielle, et les laboratoires n'ont aucun avantage sur une entreprise d'applications concentrée sur cette surface. Par exemple, voici certaines des tâches que nous gérons, certaines agentiques, d'autres non : prospection de leads basée sur des signaux personnalisés, enrichissement de leads, recherche approfondie de comptes, récupérateur de contexte depuis le CRM, rédacteur de messages spécifiques au canal, agent de qualification de leads et système de délivrabilité des e-mails. Ce ne sont pas des tâches que vous pouvez résoudre en une seule fois et qui nécessitent une ingénierie approfondie.
La perspicacité critique dans l'analogie d'Oz est qu'environ la moitié de tout flux de travail réel qui n'est pas agentique ne confère aucun avantage au laboratoire. Ils ne sont pas meilleurs que vous pour écrire le logiciel déterministe sous la couche du modèle. Et la moitié qui est agentique nécessite toujours que vous ajustiez, entraîniez et contraigniez les modèles par rapport au résultat que vous voulez réellement. La connaissance du domaine ne se trouve souvent pas dans les données d'entraînement générales. Ces compétences sont construites à partir de zéro pour le secteur vertical ou la fonction, et introduites dans le modèle au bon moment dans le flux de travail. Lorsque nos agents qualifient un lead entrant au téléphone, je dois être formé sur ce qu'est une bonne conversation de vente pour cette industrie spécifique et ce persona. C'est le travail de l'entreprise d'applications, et cela se cumule.
Plus important encore, ces compétences deviennent obsolètes tout le temps parce que les entreprises évoluent, donc votre capacité à faire évoluer ces flux de travail et ce contexte devient un 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 » commençaient tout juste à entrer en jeu. Aujourd'hui, les gens ont un sens aigu des e-mails rédigés par IA par rapport aux humains et, surtout, cela change tous les quelques mois. Nos agents doivent constamment s'adapter à la dynamique du marché, mais c'est là que le fossé se construit. En fait, malgré cette dynamique, nos taux de réponse positive ont augmenté de 4 fois au cours des derniers mois et nous avons généré des centaines de millions de pipeline pour nos clients.
Travaillez sur des problèmes où la complexité est élevée
Les problèmes complexes sont ceux où la valeur commerciale réelle est débloquée. Sinon, vous vous retrouverez à construire une fine couche.
Décomposez tout problème commercial suffisamment complexe et le désordre apparaît rapidement. Voici un exemple du monde GTM qui semble trivial : vous ne devriez pas contacter un contact dans une entreprise si cette entreprise est déjà cliente. C'est tout sauf trivial. Peut-être avez-vous le domaine associé à l'entreprise dans votre CRM. Qu'en est-il des entreprises avec des dizaines de filiales ? Et si l'enregistrement CRM a le domaine de la société mère ? Et si un champ de correspondance obsolète dans Salesforce envoie une proposition à froid au CRO d'un client actuel ? Les données du monde réel sont désordonnées. Les humains ont du mal avec cela. Les modèles ne franchissent pas ce cap comme par magie. Mettre de l'ordre dans ce désordre nécessite des agents spécialement conçus pour la forme spécifique du problème, pas un copilote généraliste pointé vers un CRM. En fait, sur la base des données dont nous disposons, nous avons réalisé que la qualité et la fraîcheur de nos données sont bien supérieures à celles de nos clients, donc par défaut, nous nous ancrons sur les nôtres.
Les garde-fous ne servent pas seulement à empêcher les mauvaises choses de se produire. C'est ce pour quoi vos clients vous paient.
Les garde-fous sont gravement sous-estimés. Même au sein d'un même produit, chaque cas d'utilisation a besoin des siens. Pour nous, un prospect du secteur des services financiers réglementé exige des garanties différentes d'un client SaaS de milieu de gamme, et ces garanties se répercutent sur la façon dont l'agent est autorisé à écrire, qui il peut contacter, quelles données il peut toucher, ce qu'il peut dire lors d'un appel et comment chaque décision est enregistrée.
Un système unique s'effondre sous cette variance. Les garde-fous doivent être construits par cas d'utilisation, configurés par client et audités en continu, et ce travail incombe carrément à l'entreprise d'applications. C'est pourquoi nous avons des FDE et des stratèges de déploiement technique qui doivent s'adapter aux exigences de chaque client. Par exemple, nous avons travaillé avec une institution du F1000 pour faire de la prospection sortante consentie par voix auprès de leur grande base de clients PME. Les premières itérations avaient de faibles taux de réponse - nous avons dû itérer rapidement et apprendre comment amener ce type spécifique de public à s'engager dans les 10 premières secondes de l'appel. Les propriétaires de PME se comportent très différemment des acheteurs B2B plus importants ou des consommateurs. Nous générons maintenant plus d'opportunités de vente pour eux en une journée que toute leur équipe de vente pour ce segment en un mois.
L'assurance comme exemple – conseils pratiques du CEO de FurtherAI
Les ventes sont un exemple. L'assurance en est un autre, et cela fait le même point sous un angle différent. Voici comment Aman Gour, PDG de FurtherAI, envisage la construction en dehors de la route :
Lorsque nous avons commencé à déployer l'IA dans des opérations d'assurance réelles, nous entendions constamment une hypothèse particulière : le modèle est l'intelligence, et le flux de travail n'est qu'un échafaudage autour de lui.
Plus nous travaillions avec des assureurs, plus nous étions convaincus que c'était l'inverse.
Dans l'assurance, une grande partie de l'intelligence vit à l'intérieur du flux de travail lui-même. Deux assureurs peuvent faire passer une soumission par ce qui semble être le même chemin : soumission, examen, devis, liaison. Mais le chemin est la partie facile. Ce qui distingue les deux assureurs, c'est tout ce qui se trouve à l'intérieur : quels risques sont escaladés, quels signaux de perte comptent, quelle règle d'appétence gagne quand deux d'entre elles sont en conflit, quand un humain doit approuver, quelles données externes sont extraites et comment la décision finale est documentée.
Cette logique ne vit pas dans un seul moteur de règles propre. Elle est répartie entre les SOP, les examens des managers, la philosophie de souscription, l'appétence spécifique à l'assureur et des années d'expérience opérationnelle. Une grande partie n'est pas écrite sous une forme qu'un modèle peut simplement lire.
C'est pourquoi nous ne croyons pas en un agent pur qui raisonne à partir de zéro à chaque fois, et nous ne croyons pas en un flux de travail rigide qui se brise dès que la réalité devient désordonnée. Et nous construisons plutôt des flux de travail agentiques. Le flux de travail vous donne la répétabilité, l'auditabilité et le contrôle des coûts. L'agent gère la variabilité et récupère lorsque le chemin heureux se brise. L'humain reste dans la boucle pour les décisions de jugement où la responsabilité compte.
Le premier jour, cela automatise le travail manuel. Mais au fil du temps, chaque escalade devient un signal, chaque exception est un retour d'information et chaque correction humaine montre où le manuel était incomplet. Au fil du temps, le flux de travail cesse d'être un script et commence à devenir la mémoire opérationnelle de l'assureur. C'est la partie que les laboratoires trouveront difficile à atteindre. Ils continueront à expédier de meilleurs modèles et de meilleurs agents généraux, et ils devraient le faire. Mais ils ne restent pas assez longtemps à l'intérieur des flux de travail de production d'un assureur pour apprendre pourquoi un compte a été escaladé, pourquoi un risque a été refusé, ou pourquoi un souscripteur a outrepassé le guide d'appétence et avait raison de le faire.
Cette compréhension ne vient qu'en exécutant le flux de travail, en production, plusieurs milliers de fois. Le flux de travail que vous expédiez le premier jour n'est pas le fossé. La boucle que l'utilisation en production crée au fil du temps l'est.
Pour nous, c'est ce que signifie construire en dehors de la route.
Comment décidez-vous si vous êtes dans le reste d'Oz ou non ?
Le test des outils et des étapes : Combien d'étapes le travail prend-il, et quelle est la complexité des outils que vous devez construire pour le supporter ? Comparez une recherche IA horizontale dans Google Drive — une étape avec un outil et un résultat indulgent, l'utilisateur lit le résumé et redemande si c'est faux — à une révision juridique multi-étapes contre trois ans de précédents du cabinet : des dizaines d'étapes à travers de nombreux outils, un résultat qui doit passer la révision d'un associé et peut devoir être plaidé devant un tribunal. Les deux ressemblent à « un agent qui fait du travail », mais un seul d'entre eux nécessite le type de logiciel profond qu'une équipe concentrée met des années à construire.
Le test du système : Construisez-vous un système à travers lequel le client exécute son travail, ou un outil qui se superpose à un système qu'il a déjà ? Les systèmes possèdent le flux de travail de bout en bout — la capture des données, la gouvernance, les enregistrements de ce qui a été fait — et ils sont ce que le client montre lorsqu'il décrit comment le travail réel se fait. Les outils, en revanche, ajoutent simplement de l'intelligence à un flux de travail que le client exécute déjà. Le cas de l'outil génère des revenus réels et les laboratoires peuvent le prendre parce que le client ne dépend pas de vous en tant que couche d'orchestration. Un ACV élevé est généralement un signal de système, car les systèmes remplacent des effectifs réels et sont payés en conséquence, mais ce n'est pas une garantie. Demandez-vous si le client aurait encore besoin de votre outil si un laboratoire expédiait quelque chose qui est censé être en concurrence directe avec vous. Si oui, vous construisez un système. Si non, vous êtes un outil — même si votre ACV est élevé.
Le test du hedge fund / P&L : Alors que la performance des laboratoires est jugée par rapport à des benchmarks, la performance du reste d'Oz est jugée par rapport au P&L de votre client. Votre client ne se soucie pas que votre modèle ait bien noté sur SWE-Bench ou MMLU — il se soucie que votre agent ait conclu l'affaire, ait révisé le contrat correctement, ou ait lié la bonne police. S'ils sont obsédés par leur résultat spécifique au flux de travail, et non par un score de capacité générique, vous êtes dans le reste d'Oz. S'ils paient pour une capacité générique, vous leur vendez quelque chose qu'ils peuvent obtenir avec un siège Claude ou Codex. Les meilleures entreprises d'agents vont devoir exécuter comme des hedge funds — gagner sur l'alpha mesuré dans le P&L du client, et non dans les scores de benchmark.
Les deux peuvent (et vont) gagner
Nous allons voir des gagnants massifs sur et en dehors de la Route de Briques Jaunes. Les modèles continueront à gagner parce qu'ils possèdent le modèle et qu'ils possèdent la distribution pour les outils horizontaux qu'ils ont conçus.
Le reste d'Oz peut gagner s'ils possèdent le système de travail — la surface où le travail de l'entreprise s'exécute réellement et où les données qui en découlent sont capturées. Ces entreprises possèdent la capture des données, le système d'action du flux de travail et la gouvernance. À mesure que des flux de travail plus complexes mûrissent dans un secteur vertical, ils se cumulent en une expérience centrale dont le client dépend. À mesure que de nouvelles générations de modèles sont expédiées par les acteurs établis et les nouveaux entrants, l'entreprise devient la couche qui les intègre et les livre au client. Le modèle est fongible en dessous ; le système de travail ne l'est pas.
La prochaine génération de logiciels d'entreprise va être construite en dehors de la route.
Si vous la construisez, contactez-moi : [email protected].
