Benedict Evans : pourquoi les pilotes IA calent avant l’échelle

Cinq ou dix projets pilotes réussis ne se transforment pas automatiquement en centaines de workflows transformés. L’analyste indépendant Benedict Evans, ancien associé chez Andreessen Horowitz, documente ce mur du passage à l’échelle dans un essai publié le 3 septembre 2026, « AI, Tools and Transformation ». Son constat : la friction ne vient plus du modèle, mais de l’organisation qui doit l’absorber.

Ce qu’il faut retenir 1. Réussir cinq ou dix pilotes IA ne dit rien de la capacité à en déployer une centaine à l’échelle d’une organisation entière. 2. Le rôle de « forward-deployed engineer », déjà connu chez Palantir, s’impose comme le chaînon manquant entre le modèle et le métier. 3. La question « faut-il faire développer un outil sur mesure ou basculer vers un logiciel existant » se pose désormais en réunion, en temps réel. 4. L’écart de réflexe entre générations — un enfant qui reformule un problème sans y penser, un adulte qui reste bloqué dans son ancien schéma — illustre la vraie barrière : mentale, pas technique. 5. Le risque n’est pas l’absence d’outils IA mais leur prolifération incontrôlée, sans gouvernance ni cohérence entre équipes.

Un enfant reformule en une phrase ce qu’un cadre met des mois à comprendre

Benedict Evans ouvre son essai sur une scène domestique. Un enfant, en observant son père se débattre avec une tâche, lui lance : « um, daddy, did you realise you could just do it like this? » — une reformulation instantanée, sans effort apparent, du problème que l’adulte abordait encore selon d’anciens réflexes. La réponse du père, telle que la rapporte Evans, tient en une question : « Why would I want that? »

Cette anecdote n’est pas un simple effet de style. Elle condense l’argument central de l’essai : la difficulté à tirer parti des outils d’IA générative n’est presque jamais une question de capacité du modèle. Elle tient à la structure mentale de celui qui l’utilise — sa manière de découper un problème, ses habitudes de travail, ses attentes sur ce qu’un outil est censé faire. Un enfant qui grandit avec ces outils ne porte pas ce bagage. Il ne cherche pas à faire entrer l’IA dans un gabarit préexistant ; il part du résultat voulu et laisse l’outil trouver le chemin.

Pour une organisation, ce fossé générationnel se rejoue à l’identique, mais avec des enjeux économiques. Un cadre habitué à un logiciel métier depuis quinze ans ne se demande pas si ce logiciel reste la bonne réponse : il se demande comment faire tenir l’IA dans les cases de ce logiciel. C’est précisément ce réflexe que Benedict Evans identifie comme le principal frein à la transformation — bien avant les limites techniques des modèles eux-mêmes.

Du copilote qui répond aux questions à l’outil qui s’insère dans le travail

Le point de bascule que décrit Evans se loge dans une phrase de réunion, presque anodine : « should we get Claude to make something or move this to Notion? » Cette question n’aurait eu aucun sens deux ans plus tôt. Elle suppose qu’une équipe puisse arbitrer, en direct, entre commander un logiciel sur mesure à un modèle de langage et adopter un outil de gestion générique existant — deux options désormais placées au même niveau de coût et de délai.

Ce basculement change la nature du choix logiciel dans l’entreprise. Historiquement, la décision de « construire ou acheter » (build vs buy) engageait des semaines d’arbitrage, un budget dédié, une équipe de développement mobilisée pendant des mois. Quand un modèle peut produire un outil fonctionnel en quelques heures, cette décision migre du comité de pilotage vers la réunion d’équipe hebdomadaire. Ce n’est plus une question stratégique tranchée une fois par trimestre ; c’est un arbitrage opérationnel tranché plusieurs fois par semaine, par des personnes qui n’ont ni le titre ni la formation d’un directeur des systèmes d’information.

Benedict Evans ne présente pas ce glissement comme une simplification. Il le présente comme un déplacement du goulot d’étranglement. Là où l’obstacle était autrefois la capacité de développement — trouver des développeurs, prioriser leur temps, financer un projet — l’obstacle devient la capacité de jugement : savoir quand un outil bricolé en interne suffit, et quand il vaut mieux s’appuyer sur un produit mûr, maintenu, sécurisé. Ce jugement ne s’acquiert pas en formation accélérée. Il se construit par l’usage répété, ce qui ramène à l’écart générationnel évoqué plus haut : ceux qui ont manipulé ces outils depuis leurs débuts développent une intuition que d’autres devront acquérir lentement, projet après projet.

Ce contexte éclaire pourquoi la conversation sur l’IA en entreprise a changé de vocabulaire en l’espace de deux ans. On ne parle plus de « déployer un chatbot » mais d’« insérer un agent dans un workflow ». La différence n’est pas cosmétique : un chatbot répond à une question posée depuis l’extérieur du processus de travail ; un outil embarqué modifie le processus lui-même, souvent sans qu’aucune ligne de code classique n’ait été écrite par une équipe technique dédiée.

Le fossé entre dix pilotes réussis et cent workflows transformés

C’est à ce stade qu’Evans introduit l’objection la plus concrète de son essai, formulée par un interlocuteur resté anonyme dans le texte : « Wait, but we’ve got 100s of workflows and we’ve done five or 10 pilots. That doesn’t seem to scale? » Cette phrase résume à elle seule la déconvenue vécue par nombre de directions qui ont multiplié les preuves de concept sans jamais atteindre une transformation d’ensemble.

Le problème n’est pas arithmétique — il ne suffit pas de répéter la méthode des pilotes cent fois. Chaque pilote réussi bénéficie généralement d’un alignement rare : un sponsor motivé, un processus déjà bien documenté, une équipe volontaire pour tester, un périmètre volontairement restreint pour limiter les risques. Ces conditions ne se reproduisent pas mécaniquement sur l’ensemble des processus d’une organisation. Un workflow de facturation, un processus de conformité réglementaire et une chaîne de support client n’ont ni la même structure, ni les mêmes contraintes de données, ni les mêmes parties prenantes. Traiter les cent workflows suivants comme des variations des dix premiers pilotes revient à sous-estimer la diversité réelle du travail dans une organisation.

C’est ici qu’Evans situe l’émergence d’un rôle hybride, déjà rodé ailleurs dans l’industrie du logiciel : le « forward-deployed engineer », popularisé par des entreprises comme Palantir bien avant la vague actuelle de l’IA générative. Ce profil ne se contente pas d’entraîner ou d’ajuster un modèle depuis un laboratoire ; il s’installe physiquement ou fonctionnellement dans l’équipe métier, observe le workflow réel, et adapte l’outil au terrain plutôt que d’attendre que le terrain s’adapte à l’outil. Ce rôle se distingue nettement de celui du « machine learning scientist », davantage tourné vers la performance du modèle en tant que tel que vers son intégration dans un processus métier concret.

Cette distinction de rôles éclaire pourquoi tant d’organisations restent bloquées après leurs premiers succès. Elles disposent souvent d’une expertise technique solide côté modèle, mais peu ou pas de capacité d’ingénierie déployée directement dans les équipes métier. Or c’est précisément ce second maillon qui permet de faire passer un outil du statut de démonstration à celui d’usage quotidien, workflow après workflow.

Ce que change concrètement la présence d’un ingénieur déployé au plus près du métier

L’essai de Benedict Evans souligne un autre obstacle, plus culturel que technique : la résistance de responsables métier qui ne perçoivent pas l’intérêt d’un changement d’outil quand l’ancien fonctionne « suffisamment bien ». C’est le sens de la réplique « Why would I want that? » citée plus haut : elle ne traduit pas un rejet de l’IA en tant que telle, mais l’absence de perception du gain, tant que personne n’a montré concrètement, sur le processus précis de cette personne, ce que l’outil change.

C’est exactement le travail qu’un forward-deployed engineer est censé accomplir : non pas convaincre par la démonstration abstraite d’une capacité générale du modèle, mais montrer, sur le workflow spécifique d’une personne donnée, la différence entre l’ancienne façon de faire et la nouvelle. Ce travail est lent, personnalisé, non industrialisable au sens classique du terme — ce qui explique en partie pourquoi il peine à suivre le rythme de cent workflows simultanés évoqué plus haut.

Les conséquences organisationnelles dépassent la seule question technique. Une entreprise qui multiplie les outils construits en interne, par équipe, sans coordination centrale, s’expose à une fragmentation silencieuse : plusieurs versions d’un même besoin résolues différemment selon les services, des données traitées avec des niveaux de rigueur inégaux, une dette de maintenance qui ne pèse sur personne en particulier jusqu’au jour où un outil bricolé casse en pleine production. Le glissement du « qui a le droit de construire un outil » vers « n’importe quelle équipe peut demander à un modèle de le faire » déplace un risque de gouvernance qui n’a pas disparu — il a simplement changé d’adresse, de la direction informatique vers chaque équipe individuelle.

Une lecture qui reste à confronter à des organisations moins matures

L’argument de Benedict Evans convainc sur le terrain qu’il documente — de grandes organisations technologiquement avancées, où la question n’est plus « faut-il adopter l’IA » mais « comment l’étendre sans perdre le contrôle ». Il mérite néanmoins d’être nuancé pour des structures plus modestes ou moins équipées.

D’abord, tout le monde n’a pas les moyens de recruter un forward-deployed engineer par équipe métier : ce rôle suppose une masse critique de projets et un budget que la plupart des PME n’ont pas. Ensuite, l’idée que la barrière soit désormais purement organisationnelle et non plus technique mérite d’être questionnée pour les cas d’usage impliquant des données sensibles, réglementées ou peu structurées, où les limites du modèle restent réelles, indépendamment de la maturité de l’organisation qui l’emploie. Enfin, l’anecdote du choix entre « faire développer par Claude » et « basculer sur Notion » suppose une culture déjà familière avec ces outils ; elle ne dit rien du chemin qu’il reste à parcourir pour une organisation qui découvre à peine ces usages.

Ces réserves ne contredisent pas la thèse centrale de l’essai. Elles en précisent le périmètre : le diagnostic du fossé entre pilotes et échelle est solide, mais la solution qu’il esquisse — un rôle hybride, immergé, itératif — reste elle-même coûteuse à généraliser, ce qui reproduit à un niveau supérieur le même problème de passage à l’échelle qu’elle est censée résoudre.

Une question de répartition, pas de disponibilité de l’outil

Le déplacement que décrit Benedict Evans a une conséquence directe pour toute organisation qui a multiplié les pilotes sans transformation d’ensemble : le problème à résoudre n’est plus l’accès à un modèle performant, largement disponible désormais, mais la répartition du jugement nécessaire pour l’appliquer, processus par processus. Recruter davantage de forward-deployed engineers, former les équipes existantes à ce rôle hybride, ou accepter une fragmentation contrôlée des outils métier : ces choix engagent des arbitrages différents selon la taille et la maturité de chaque organisation.

Le fossé que pointe Evans entre dix pilotes et cent workflows ne se refermera pas par une nouvelle génération de modèles plus puissants. Il se refermera, ou non, par la capacité de chaque organisation à déplacer du jugement humain là où l’outil, seul, ne sait pas encore décider à quoi il doit ressembler.

Sources citées – Benedict Evans, « AI, Tools and Transformation », 3 septembre 2026.