Pourquoi l'IA ne réinventera pas le logiciel du jour au lendemain : Benedict Evans sur les limites des outils génératifs

Le dernier essai de Benedict Evans, « IA, outils et transformation », s'oppose au fantasme de la Silicon Valley selon lequel l'IA permettrait aux utilisateurs de générer spontanément les logiciels dont ils ont besoin, éliminant ainsi le besoin des suites logicielles d'entreprise traditionnelles. Son argument principal : le goulot d'étranglement n'est pas de construire des outils, mais de savoir quels outils construire et de faire en sorte que des centaines de personnes les adoptent.

La « blague de l'ingénieur » inversée

Evans commence par la blague classique : un ingénieur passera une heure à automatiser une tâche qui prend 10 minutes. Mais avec l'IA, « vous pouvez créer cet outil en cinq minutes, et vous n'avez pas besoin d'être un ingénieur. » L'idée enivrante est que le logiciel devient dynamique, génératif, libre — beaucoup plus de tâches automatisées avec beaucoup moins de code. Pourtant, il met en garde que cela méconnaît la façon dont les logiciels sont adoptés dans les entreprises réelles.

Pourquoi la plupart des utilisateurs ne sont pas des créateurs d'outils

S'appuyant sur la réalité d'une grande entreprise typique — des centaines d'applications SaaS, des scripts et des feuilles de calcul — Evans note que la plupart des gens ne sont pas comme les ingénieurs de la Silicon Valley. « Si vous êtes un très bon avocat en droit matrimonial, vous passez toutes vos journées à penser à vos dossiers et à vos clients, pas à ce que ferait un excellent logiciel de découverte juridique. » C'est pourquoi les modèles de feuilles de calcul et les suggestions « Fichier/Nouveau » existent : ils tentent de combler le fossé pour les non-créateurs, mais ils restent des réponses partielles.

Les opportunités manquées sont souvent invisibles pour ceux qui les ont. Evans cite le rôle émergent de l'« ingénieur déployé en avant » — quelqu'un qui peut parcourir un cabinet d'avocats ou un bureau d'architecture et repérer le potentiel d'automatisation que l'expert ne voit pas, comme un adolescent féru de technologie pourrait dire : « Papa, tu savais que tu pouvais simplement faire comme ça ? »

Voir le problème est la partie difficile

Au-delà de la perception individuelle, de nombreuses automatisations transformatrices n'étaient pas évidentes même pour les ingénieurs. « Nous pouvons tous penser à des exemples de choses que nous utilisons quotidiennement et dont notre première réaction a été "Pourquoi voudrais-je cela ?" » Le problème peut être intégré dans un autre flux de travail, et trouver la bonne solution nécessite souvent de redéfinir le problème lui-même — ce qui a pris une demi-douzaine de tentatives infructueuses pour de nombreuses entreprises de logiciels prospères.

L'automatisation touche les départements, pas seulement les individus

Étendre un changement de flux de travail au-delà d'un seul utilisateur est ce qu'Evans appelle le spectre « institutionnalisé à improvisé ». Une feuille de calcul ascendante peut gérer un département, mais un nouveau processus de comptabilité fournisseurs touche cinq départements, trois systèmes d'enregistrement et quatre régimes réglementaires. Ce changement « doit être un achat, une décision et un processus de vente de 18 mois », pas seulement une invite d'IA rapide.

Aucun de ces problèmes n'est résolu en facilitant l'écriture de code. Les parties difficiles — reconnaître le besoin, définir l'outil et conduire l'adoption — restent obstinément humaines et organisationnelles. C'est un contrepoint sobre au récit de la « démocratisation de la création de logiciels » que nous entendons si souvent.