Comment éviter la mort sur la route de briques jaunes — la couche applicative n’est pas encore morte

• L’inquiétude se répand chez les fondateurs : la couche applicative de l’IA risque-t-elle d’être absorbée par les grands labos comme OpenAI et Anthropic ? Pourtant, la couche applicative n’est pas une opportunité unique, mais une structure divisée entre la « Yellow Brick Road » et le « Rest of Oz »
• La Yellow Brick Road désigne des domaines horizontaux comme la génération de code, l’écriture ou la génération d’images, où la qualité s’améliore simplement grâce à la progression des performances du modèle lui-même — un chemin sur lequel les labos investissent des ressources massives
• Le Rest of Oz désigne des domaines où la fiabilité et la compliance dépendent du scaffolding au-dessus du modèle, comme les workflows verticaux, multi-étapes et à validations multiples ; c’est là qu’existe une opportunité pour les startups de posséder la relation client
• Le simple fait qu’OpenAI et Anthropic aient annoncé des joint-ventures forward-deployed de grande ampleur pour la personnalisation en entreprise suggère qu’un simple coworker IA généralisé ne peut pas résoudre tous les problèmes
• La prochaine génération de logiciels d’entreprise se construira « hors de la route » (off the road), et la ligne de défense essentielle est la suivante : les modèles sont interchangeables, mais pas le system of work

---

Questions clés et hypothèses

• La question qui revient sans cesse de la part des fondateurs et des candidats est : « OpenAI et Anthropic vont-ils tout tuer ? Reste-t-il encore quelque chose à construire dans la couche applicative de l’IA ? »
• Certains en concluent que les seuls endroits permettant d’éviter une position subalterne permanente sont à l’intérieur des grands labos ou sur la frontière comme la robotique et la hard tech
• L’auteur, d’un point de vue maximaliste sur l’IA, estime qu’ils ont « à moitié raison » : il est vrai que les labos vont absorber une part importante de la surface applicative
• Mais le point essentiel est que la couche applicative n’est pas une opportunité unique — le bon cadrage consiste à se demander si l’on est sur la Yellow Brick Road ou ailleurs dans Oz

The Yellow Brick Road — le chemin qu’empruntent les labos

• Le schéma consiste à brancher sur un modèle haute performance des connecteurs standard comme G Drive, Slack, Salesforce, Notion et GitHub, puis à ajouter par-dessus une couche d’orchestration d’agents
• Ce schéma est risqué parce que les labos font déjà exactement la même chose avec Cowork et Codex
  • Posséder le modèle → de meilleures marges, davantage de contrôle et un pouvoir de fixation des prix en aval
  • Ils gardent la liberté des choix d’architecture qui permettent au produit de bien fonctionner — jusqu’ici ils ont volontairement adopté le schéma « model + tool calls », qui correspond précisément aux tâches horizontales simples situées sur cette route
• Même si une startup dépasse Codex ou Claude Code en performance, les labos disposent d’un canal de distribution immense et du plus grand halo de marque du secteur IA
• Une entreprise d’applications IA qui suit ce playbook avec la même combinaison de connecteurs, sans sous-agents, sans configuration, et sans distribution, emprunte une « route qui ne mène nulle part »

The Rest of Oz — l’opportunité des startups

• C’est le domaine où l’on construit des expériences agentiques dans lesquelles le modèle est relié à travers un réseau complexe d’outils, d’automatisations et d’intégrations, ce qui mène naturellement, dans la plupart des cas, à une approche verticale
• Cela permet de se concentrer sur des tâches multi-étapes et multi-participants qu’une plateforme horizontale ne peut pas atteindre
  • Collecter du contexte à travers tout le système, puis router vers plusieurs personnes avec validation à chaque étape
  • S’interfacer avec un ou plusieurs systèmes legacy, avec un besoin de résultats déterministes et aucune tolérance pour l’ambiguïté
  • Souvent lié à des résultats business à forte valeur
• Les labos perçoivent eux aussi la valeur de ces problèmes, ce qui explique qu’ils exploitent directement des organisations externalisées de configuration et qu’il existe une classe enterprise/upmarket du business de reinforcement learning

Pourquoi le Rest of Oz ne sera pas absorbé par le magicien

• Data and learning flywheels (volants d’inertie de données et d’apprentissage)

  • Les normes implicites d’un secteur, les standards non documentés et le tribal knowledge présent dans la tête des opérateurs de terrain n’existent pas sur le web public
  • Deux volants d’inertie se superposent
    • across-customer : des motifs qui s’accumulent en observant chez plusieurs clients les variations d’un même problème
    • within-customer : les raisons d’une décision précise, les exceptions implicites et les règles empiriques propres à une entreprise donnée
  • Une entreprise qui a traité 100 redlines juridiques, 1 000 underwriting d’assurance et 10 000 campagnes SDR a internalisé une forme du problème qu’un nouvel entrant ne peut pas reproduire avec un agent fraîchement lancé
  • La raison centrale pour laquelle un agent horizontal ne peut pas bâtir la même infrastructure d’apprentissage, c’est l’UX — seul un acteur vertical peut concevoir avec précision la surface du workflow
  • Les jeux d’eval, les sorties labellisées et les taxonomies de cas limites s’accumulent comme un flywheel de données verticales spécialisées, qui devient le carburant du fine-tuning

• Managing model variability and complexity (gestion de la variabilité et de la complexité des modèles)

  • Les labos pratiquent déjà en interne le routage par requête et les ensembles de modèles, mais ils ne peuvent pas faire du routage inter-fournisseurs, évaluer les modèles concurrents ni déployer des modèles open source fine-tunés sur des domaines étroits
  • Les entreprises du Rest of Oz choisissent, pour chaque sous-tâche, le meilleur modèle non seulement parmi les sorties du labo parent, mais dans l’ensemble du marché des modèles
  • Elles absorbent tout le « sale boulot » : relancer les evals à chaque upgrade, recalibrer les prompts selon les edge cases clients, et déployer sans casser la production
  • Le labo se contente de vendre le modèle suivant puis d’annoncer « migrez » ; l’entreprise du Rest of Oz absorbe la migration pour offrir au client à la fois la meilleure intelligence disponible sur le marché et une continuité des upgrades

• Cost optimization (optimisation des coûts)

  • Faire tourner toutes les requêtes sur Opus 4.7 est le chemin le plus court vers une marge brute négative
  • Les meilleures entreprises du Rest of Oz pratiquent un routage des modèles par niveaux
    • les modèles frontier pour les tâches les plus difficiles
    • les modèles mid-tier pour la majorité des tâches
    • des petits modèles custom ou fine-tunés là où c’est pertinent
  • Certaines vont plus loin en réalisant leur propre post-training, optimisé pour une tranche étroite de besoins clients, avec un coût de service inférieur à celui des API frontier
  • Si le labo fixe un prix plancher pour un « minimum d’intelligence à X dollars », alors les entreprises du Rest of Oz vendent l’inverse : le coût en dollars le plus faible pour le niveau d’intelligence réellement requis par le workflow

• Governance (gouvernance)

  • Il y a une vraie valeur à devenir le control plane de la façon dont le client opère l’IA dans un vertical donné — permissions, audit, ce que l’agent peut faire, et ce qu’il a réellement fait convergent tous à cet endroit
  • Ce control plane est constitué de guardrails propres à chaque use case, totalement différents selon le secteur et la fonction
  • Comme l’entreprise possède de bout en bout les outils, workflows et données, elle peut fournir des résultats déterministes qu’un outil horizontal a du mal à atteindre
  • C’est aussi elle qui absorbe la complexité réglementaire à la place de l’acheteur final
    • droit : FRCP et règles déontologiques des avocats
    • santé : HIPAA
    • finance : SEC et FINRA
    • assurance : régulation de l’assurance au niveau des États, etc.
  • Le CIO veut un partenaire qui porte contractuellement la responsabilité de la compliance des agents qu’il met en œuvre

• Conclusion commune : le focus

  • Qu’il s’agisse d’un vertical (assurance, droit, comptabilité) ou d’une fonction exécutée en profondeur (vente, support client, finance), il faut une équipe dédiée aux workflows, edge cases et réglementations d’un ensemble de clients bien précis
  • Les labos, par structure, doivent être partout pour tout le monde ; ils ne peuvent donc pas faire ce travail — il faut choisir entre « être partout » ou « faire une seule chose très bien »

Cas Sales — conseils terrain de Prabhav Jain, CEO de 11x

• Focus on outcomes (se concentrer sur les résultats)

  • Le chemin tactique pour bâtir une entreprise résistante aux labos consiste à partir d’un résultat précis qui compte vraiment pour le client — chez 11x, la génération de pipeline
  • Décomposer chaque activité en tâches → distinguer ce qui est agentique de ce qui ne l’est pas, et ce qui exige ou non une vraie finesse de compréhension métier
  • Dans des workflows multi-étapes, avec entrées désordonnées, états difficiles à interpréter et contraintes du monde réel, de meilleurs modèles ne suffisent pas ; il faut du génie logiciel classique, et sur cette surface les labos n’ont aucun avantage
  • Exemples de tâches prises en charge par 11x
    • prospecting de leads à partir de signaux custom, enrichment de leads, recherche approfondie sur les comptes
    • fetcher de contexte CRM, générateur de messages par canal, agent de qualification des leads, système de délivrabilité email
  • Le travail d’une entreprise applicative consiste à injecter au bon moment dans le workflow la connaissance métier absente des données d’apprentissage générales, et cet avantage s’accumule
  • Les compétences deviennent vite obsolètes à mesure que le business évolue ; la capacité à faire évoluer workflow et contexte devient donc en soi un avantage concurrentiel
    • Exemple : depuis l’apparition des emails écrits par l’IA, la sensibilité des utilisateurs change tous les quelques mois, et l’agent doit continuellement s’adapter à la dynamique du marché
    • Au cours des derniers mois, le positive reply rate a été multiplié par 4, générant pour les clients des centaines de millions de dollars de pipeline

• Work on problems where complexity is high (travailler sur des problèmes à forte complexité)

  • C’est dans les problèmes complexes que se débloque la vraie valeur business ; sinon, on devient un thin wrapper
  • Exemple GTM : la règle simple « ne pas contacter une personne dans une entreprise déjà cliente » devient en pratique très complexe
    • Il peut exister un mapping de domaines dans le CRM, des entreprises avec des dizaines de filiales, des cas où seul le domaine de la maison mère est enregistré, et des champs de matching obsolètes dans Salesforce qui envoient au CRO d’un client existant un cold pitch
  • Les données du monde réel sont désordonnées, et ni les humains ni les modèles ne les résolvent par magie — il faut des agents conçus pour un objectif précis, pensés pour la forme concrète du problème
  • D’après les données de 11x, la qualité et la fraîcheur de leurs propres données sont supérieures à celles du client, ce qui fait de l’ancrage sur leurs propres données la stratégie par défaut

• Guardrails — non pas un simple filet de sécurité, mais l’essence même de ce pour quoi le client paie

  • Les guardrails sont gravement sous-estimés, et même au sein d’un même produit, chaque use case en requiert de différents
  • Les garanties demandées par un prospect de services financiers régulés et par un client SaaS mid-market ne sont pas les mêmes, ce qui se répercute sur la manière dont l’agent rédige, les personnes qu’il contacte, les données auxquelles il accède, ce qu’il dit au téléphone et la façon dont ses décisions sont journalisées
  • Un système one-size-fits-all s’effondre ; il faut une conception par use case, une configuration par client et un audit continu
  • C’est pour cela qu’ils emploient des FDE (Forward Deployed Engineer) et des stratèges de déploiement technique qui ajustent le système aux exigences du client
  • Cas d’une institution F1000
    • exécution d’appels sortants vocaux basés sur le consentement auprès d’un vaste parc de clients SMB
    • dans les premières itérations, le taux de décroché était faible → apprentissage rapide de la façon d’engager un dirigeant de SMB dans les 10 premières secondes d’un appel
    • les dirigeants de SMB se comportent différemment des grands acheteurs B2B ou des consommateurs ; aujourd’hui, sur ce segment, le système génère en une journée plus d’opportunités commerciales que l’équipe commerciale du client en un mois

Cas Insurance — Aman Gour, CEO de FurtherAI

• Une hypothèse rencontrée à répétition lors du déploiement de l’IA dans les opérations d’assurance — « le modèle est l’intelligence, le workflow n’est qu’un scaffolding » — l’a conduit, à mesure qu’il travaillait avec des carriers, à la conviction inverse
• Dans l’assurance, une grande partie de l’intelligence réside dans le workflow lui-même
  • Même si deux carriers suivent le même parcours (submission → review → quote → bind), toute la différence se trouve dans ce qui se passe à l’intérieur
    • quels risques sont escaladés
    • quels signaux de sinistre sont jugés importants
    • quelle règle d’appetite l’emporte lorsqu’elles entrent en conflit
    • à quel moment intervient la validation humaine, quand appeler des données externes, et comment documenter la décision finale
  • Cette logique n’est pas rassemblée dans un moteur de règles propre et centralisé ; elle est dispersée entre SOP, revues managériales, philosophie de souscription, appetite propre au carrier et années d’expérience opérationnelle, et une grande partie n’est même pas documentée dans une forme lisible par le modèle
• La conclusion, à chaque fois, n’est ni un agent pur qui raisonne depuis zéro, ni un workflow rigide qui casse dès que la réalité devient désordonnée, mais des agentic workflows
  • workflow → répétabilité, auditabilité, contrôle des coûts
  • agents → gestion de la variabilité, reprise quand le happy path se brise
  • human-in-the-loop → appels de jugement là où la responsabilité compte
• Au Day 1, il s’agit d’automatisation manuelle ; puis, avec le temps, chaque escalation devient un signal, chaque exception un feedback, et chaque correction humaine révèle un point manquant du runbook, si bien que le workflow évolue en mémoire opérationnelle (operating memory) du carrier
• Les labos continueront de lancer de meilleurs modèles et de meilleurs agents généralistes, mais ils ne peuvent pas apprendre quels comptes ont été escaladés, quels risques ont été refusés ou pourquoi un underwriter a eu raison d’inverser un guide d’appetite, à moins de rester suffisamment longtemps dans la production du carrier
• « Le workflow lancé au Day 1 n’est pas le moat ; le moat, c’est la boucle créée au fil du temps par l’usage en production »

Trois tests pour savoir si l’on appartient au Rest of Oz

• The tools-and-steps test (test des outils et des étapes)

  • Combien d’étapes le travail comporte-t-il, et à quel point les outils de support sont-ils complexes ?
  • Comparaison
    • recherche IA horizontale (à travers Google Drive) : 1 étape, 1 outil, résultat tolérant — si c’est faux, on repose la question
    • redline juridique (comparaison avec trois ans de précédents du cabinet) : des dizaines d’étapes, de multiples outils, une sortie qui doit passer une revue de partner et peut finir contestée au tribunal
  • Dans les deux cas, « un agent travaille », mais un seul des deux exige un logiciel profond construit pendant des années par une équipe focalisée

• The system test (test du système)

  • Êtes-vous en train de construire le système par lequel le client fait passer son travail, ou seulement un outil posé au-dessus d’un système déjà existant ?
  • Un système possède de bout en bout la capture des données, la gouvernance et l’historique d’exécution ; c’est ce que le client désigne comme « l’endroit où le vrai travail se passe »
  • Un outil se contente d’ajouter de l’intelligence à un workflow que le client exploite déjà ; cela peut générer du revenu, mais c’est aussi un territoire que les labos peuvent prendre
  • Un ACV élevé est souvent un signal de système, sans être une garantie — le vrai critère est le suivant : si un labo lance un produit concurrent, le client a-t-il encore besoin de votre outil ?

• The hedge fund / P&L test (test hedge fund / P&L)

  • La performance des labos se mesure sur des benchmarks ; celle du Rest of Oz se mesure sur le P&L du client
  • Le client se moque des scores SWE-Bench ou MMLU — il veut savoir si l’agent a closé le deal, correctement redliné le contrat, ou fait binder la bonne police
  • Si le client est obsédé par des résultats spécifiques au workflow → Rest of Oz ; s’il paie pour une capacité générale, alors un siège Claude ou Codex suffit
  • Les meilleurs business d’agents doivent jouer comme un hedge fund : produire un alpha mesuré sur le P&L du client

Les deux camps peuvent gagner

• Il y aura aussi d’immenses gagnants sur la Yellow Brick Road — les labos possèdent les modèles et la distribution des outils horizontaux qu’ils conçoivent eux-mêmes
• La condition de victoire du Rest of Oz, c’est la possession du system of work — la surface où le travail de l’entreprise s’exécute réellement et où les données sont capturées
  • posséder la capture des données, le système d’action du workflow et la gouvernance
  • à mesure que les workflows complexes mûrissent dans un vertical, ils se condensent en une expérience centrale dont le client devient dépendant
  • quand de nouvelles générations de modèles arrivent, l’entreprise devient la couche qui les intègre et les délivre
  • les modèles sont fungibles en dessous, mais pas le system of work
• La prochaine génération de logiciels d’entreprise se construira « hors de la route »