a16z Dernières perspectives : lorsque l'agent IA devient l'utilisateur principal du logiciel

Écrire un article : Réflexion profonde

As-tu déjà pensé que toute la logique de construction logicielle pourrait être complètement renversée ? Au cours des dernières décennies, tous les logiciels ont été conçus pour l’humain. Nous avons consacré d’innombrables efforts à optimiser l’interface utilisateur, à rendre les boutons plus faciles à trouver, à clarifier les menus, à fluidifier les processus. Mais si à l’avenir, les principaux utilisateurs du logiciel ne sont plus des humains, mais des agents IA ? Si une entreprise compte cent employés, mais mille agents IA qui travaillent, devrions-nous alors concentrer nos efforts sur l’optimisation de l’interface humaine ?

Récemment, dans un épisode de podcast chez a16z, Erik Torenberg, Steven Sinofsky et Martin Casado ont engagé un dialogue extrêmement profond avec Aaron Levie, PDG de Box. Leur question centrale était : lorsque les agents IA deviennent les principaux utilisateurs des logiciels d’entreprise, comment toute l’industrie du logiciel va-t-elle se restructurer ? Ce dialogue m’a fait réaliser que nous sommes à l’orée d’un changement de paradigme plus radical que ce que la plupart imaginent. Il ne s’agit pas simplement d’ajouter une fonctionnalité IA à un logiciel existant, mais de repenser fondamentalement la façon dont le logiciel doit être construit, comment il doit interagir, comment il doit être utilisé.

Les logiciels doivent être conçus pour les agents IA

Aaron Levie a avancé une idée qui m’a profondément fait réfléchir : si vous avez cent fois, voire mille fois plus d’agents IA que d’employés, alors votre logiciel doit être conçu pour ces agents. Ce n’est pas une question de choix, mais une tendance inévitable. Box consacre désormais autant de temps à réfléchir à l’interface des agents qu’à celle des humains. La vitesse de cette transition dépasse largement mes attentes.

La logique derrière est en fait très simple. Lorsque les agents IA deviennent les principaux utilisateurs, ils interagiront avec le système via des API, des interfaces en ligne de commande (CLI) ou des protocoles comme MCP (Model Context Protocol, protocole de contexte de modèle). Et quelle est la modalité la plus efficace actuellement ? Fournir à un agent capable d’écrire du code un accès aux outils SaaS, lui permettant d’accéder à votre flux de travail de connaissance et à votre contexte. Un tel agent ne se contente pas de lire et comprendre l’information, mais peut aussi, en écrivant du code ou en utilisant des API, accomplir des tâches.

Claude Code d’Anthropic, les super-applications en développement chez OpenAI, ou encore la fonction de calcul de Perplexity, évoluent dans cette direction. Je pense que la croissance de cette capacité ne fait que commencer. Imagine un agent qui non seulement comprend “Aide-moi à analyser les ventes du dernier trimestre”, mais qui écrit aussi du code pour extraire les données, faire des analyses, générer des visualisations, voire détecter de lui-même des tendances que tu n’avais pas remarquées. Où s’arrêtera cette capacité ? Je ne peux pas encore le voir clairement.

Mais il y a une question clé qui me hante : on entend souvent dire “construire pour l’agent”, “faire du marketing pour l’agent”, “avoir de bonnes API et un bon langage de description d’interface”. Martin Casado a exprimé une contre-vision que je partage totalement : cette façon de voir est presque totalement fausse. Pourquoi ? Parce que l’agent excelle justement à trouver le bon outil et le bon backend. Il ne choisira pas parce que votre documentation API est jolie, mais en fonction de paramètres de coût, de fiabilité du système, de persistance des données, etc. L’agent détient la sagesse collective de l’utilisation de ces plateformes.

Ce point m’a éclairé. En tant qu’industrie, nous sommes trop concentrés sur l’interface et l’API, alors que l’essence est ailleurs : nous devons construire de meilleurs systèmes eux-mêmes. Les agents nous ramènent à l’essence technologique, plutôt qu’au marketing. Autrefois, les décisions d’achat de logiciels d’entreprise étaient souvent influencées par la force de vente, la notoriété de la marque ou même des dîners d’affaires. Mais dans un monde dominé par les agents, ces facteurs verront leur importance diminuer drastiquement. Les agents choisiront en fonction de leur supériorité technique. Pour les entreprises vraiment centrées sur la technique, c’est une opportunité énorme.

Le seuil de la pensée algorithmique : tout le monde ne peut pas commander un agent IA

Une discussion qui m’a marqué concerne le défi pratique pour un non-technicien d’utiliser un agent IA. Steven Sinofsky a souligné que la pensée algorithmique est extrêmement difficile pour la majorité des travailleurs. Si on leur demandait de dessiner un flux pour leur tâche, ils échoueraient probablement.

Ce constat est crucial. Imagine une équipe de 50 marketeurs responsables d’une grande ligne de produits : probablement un seul d’entre eux comprend et peut documenter tout le processus. Si on leur donne des outils ou des agents IA pour automatiser, leur capacité à expliquer “ce qu’il faut faire” est très limitée.

Aaron Levie a répondu que c’est simplement une étape supplémentaire dans le travail : il faut apprendre une nouvelle compétence. Ce n’est pas différent de chaque révolution technologique passée. Il a donné un exemple intéressant : un marketeur chez Anthropic a utilisé Claude Code pour accomplir en une seule personne ce qui nécessitait auparavant cinq à dix personnes. La clé, c’est que cette personne est déjà un penseur systémique, suffisamment technique pour y parvenir.

Mais la question essentielle est : si chaque poste pouvait être automatisé par une ressource d’ingénierie infinie, que deviendrait ce poste ? C’est une question à méditer. Peut-être que les agents deviendront de plus en plus habiles à guider vers une pensée systémique, mais pour l’instant, peu de gens savent efficacement utiliser ces outils.

Steven Sinofsky a fait une analogie brillante : sa cousine, diplômée d’une grande école de commerce, a commencé son premier emploi à l’aube de l’ère informatique. Elle n’avait jamais utilisé de tableur en master, mais la première année, on lui a dit qu’elle pouvait embaucher autant de stagiaires qu’elle voulait. Elle a alors géré toute une salle de “agents” — ces étudiants qui faisaient tout le travail de tableur. Et étonnamment, au fil des années, elle et ses collègues sont devenus des expertes en tableurs. La couche d’abstraction s’est déplacée. Ce qui nécessitait autrefois des calculatrices et des HP Financial Calculators, elle le fait maintenant elle-même dans un tableur, avec 30 itérations possibles au lieu de 2.

Ce récit m’a fait réaliser que nous sommes dans une étape similaire avec les agents IA. On pense qu’il faut 50 petits agents coordonnés par une personne très intelligente. Mais rapidement, ces agents se recouperont, se combineront en un ensemble de compétences — un code, que l’on appellera agent — qui maîtrise le marketing. On pourra leur poser des questions liées au marketing, puis leur demander d’exécuter une tâche.

Je pense que le tournant clé sera : aujourd’hui, il faut être un expert en fusée pour créer 42 agents et les faire fonctionner. Mais cette barrière va disparaître rapidement, et une grande partie du savoir métier reviendra aux experts du domaine. C’est exactement le chemin qu’a suivi l’évolution du tableur.

Les peurs des entreprises : l’intégration incontrôlable et le cauchemar des permissions

Un scénario qui m’a profondément marqué dans le dialogue : Aaron Levie a raconté avoir récemment exprimé une vision optimiste devant une salle de CFO et CIO, pour se faire répondre : “Tu es fou, tu as perdu toute crédibilité auprès de moi.” Pourquoi ? Parce qu’il disait que l’intégration allait devenir beaucoup plus simple.

Les inquiétudes des responsables IT ne sont pas infondées. Leur crainte n’est pas seulement l’agent lui-même, mais aussi la délégation humaine pour l’intégration. Lorsqu’on permet aux employés de créer de nouvelles intégrations, c’est comme leur dire : “Allez, détruisez mon système central.” Imaginez quelqu’un qui crée une nouvelle API entre le système 27 et le système 38. Si c’est juste pour générer un rapport, c’est leur problème. Mais si cela implique des écritures, là ça devient critique.

Aaron Levie pense qu’à long terme (N étant un grand nombre), on aura une version en lecture seule des intégrations d’agents. Beaucoup d’applications IA sont aujourd’hui en consommation — l’humain est le dernier utilisateur. Mais même à ce niveau, de nouveaux défis apparaissent.

Box a lancé récemment une CLI officielle. Aaron décrit un scénario : vous donnez à Claude Code la CLI de Box, et vous pouvez interagir en langage naturel avec tout le système, orchestrer une série d’opérations avec un modèle puissant comme Opus 4.6. C’est impressionnant : dire “Uploader tout ce dossier sur mon bureau dans Box”, ou “Traiter tous les documents de ce dossier”, et cela fonctionne.

Mais le problème qui en découle est épineux. Imaginez une entreprise de 5000 employés, tous ayant accès à un référentiel partagé de documents de travail et de marketing, utilisant tous la CLI. Comment coordonner potentiellement 10 000 requêtes par heure ? Ce n’est pas une question de performance, mais de garantir que lorsqu’un agent déplace un fichier, un autre ne tente pas d’écrire ou de supprimer en même temps. Quand ces agents tournent à plein régime, cela devient un cauchemar pour les CFO et CIO.

Aaron Levie a lui-même rencontré ce problème lors de ses tests. En essayant de créer une structure de dossier pour un plan marketing, il s’est retrouvé dans une boucle infinie de création de sous-dossiers. Il a plaisanté : “Je me demande quelle est la limite de profondeur des dossiers dans Box, parce que je suis presque arrivé au bout.”

Ce petit épisode reflète un problème plus vaste : quand on donne à un agent la capacité d’agir, il peut faire des choses inattendues. Et cette imprévisibilité est ce que les entreprises craignent le plus.

Traiter un agent IA comme un employé ? Pas si simple

Une discussion sur la gestion des agents IA m’a particulièrement marqué. Lorsqu’on commence à utiliser des agents personnels, on leur donne ses propres clés API, son email, etc. Mais comment éviter qu’ils fassent n’importe quoi ?

Martin Casado a partagé une pratique : donner à votre agent son propre numéro de téléphone, sa propre carte de crédit (idéalement une prépayée CVS Visa), son propre compte Gmail. Gmail dispose de nombreux mécanismes RBAC (contrôle d’accès basé sur les rôles). On pourrait argumenter qu’on a déjà construit beaucoup de systèmes de permissions, et qu’il faut traiter l’agent comme un individu autonome.

Mais Aaron Levie a immédiatement souligné le problème : dans une équipe de 50 personnes, y aura-t-il 100 “personnes” — 50 humains et 50 agents — partageant le même espace ? Je peux superviser mon agent, mais si mon agent collabore avec d’autres et accède à des ressources qui ne devraient pas, que se passe-t-il ? Cet agent autonome, avec un état, manipule des informations d’autres personnes.

Il y a une contradiction fondamentale : pour un vrai employé, on ne peut pas voir ses canaux Slack, se connecter en son nom, ou le surveiller. Il doit assumer ses responsabilités. En revanche, pour un agent, on doit en être responsable, tout en ayant une supervision totale. Il n’a pas de vie privée.

Il y a donc un paradoxe : je dois pouvoir donner des accès à l’agent, mais aussi pouvoir intervenir à tout moment, par exemple “Tu as tout cassé, je vais tout annuler.” Mais si je peux me connecter en son nom, comment cet agent peut-il collaborer avec d’autres dans le monde réel tout en conservant confidentialité et sécurité ? En réalité, un agent est presque une extension de vous.

Aaron Levie a aussi soulevé une question de sécurité plus profonde : comment faire en sorte que l’agent conserve ses secrets ? Si vous lui dites “Ne divulgue pas X dans la fenêtre de contexte”, c’est difficile à garantir. Si tout peut entrer dans la contexte de l’agent, parce qu’il a accès à tout, il faut supposer que ces informations peuvent être injectées via des prompts malveillants.

Que signifie cela ? Que si je connais l’adresse email de votre nouvel agent, je peux lui envoyer un email, le social engineering, ce qui est beaucoup plus facile qu’avec un humain. Il est difficile de faire en sorte que cet agent ait aussi accès à des documents sensibles, comme des fusions-acquisitions.

Je pense que c’est l’un des plus grands obstacles techniques actuels pour les agents IA. Jusqu’à ce qu’on résolve ce problème, ils auront du mal à obtenir une autonomie décisionnelle et un accès aux ressources. Ils resteront une extension de l’humain, et non une entité indépendante.

Les startups : profiter sans limites de l’IA

Un point qui m’a particulièrement marqué : la vitesse de diffusion des capacités IA sera bien plus lente que ce que pensent les Silicon Valley insiders. La raison ? Les contraintes auxquelles font face startups et grandes entreprises sont radicalement différentes.

Aaron Levie explique que les startups peuvent partir de zéro, sans les risques évoqués, car elles n’ont rien à perdre. C’est la trajectoire que nous suivons. Mais si vous demandez à une grande banque comment configurer un NanoClaw (un agent IA hypothétique) pour automatiser ses opérations, vous verrez l’écart.

Ce qui différencie ces deux mondes ? Les grandes entreprises ont 75 systèmes hérités à intégrer, des exigences de conformité strictes, des décennies de standards de sécurité, des mécanismes complexes de gestion des permissions. Et surtout, elles ont beaucoup à perdre. Si un agent d’une grande banque divulgue des données clients, c’est la faillite assurée.

Steven Sinofsky prévoit que les startups brûleront leur capital disponible, en faisant semblant que le coût ne compte pas. Beaucoup de grandes entreprises seront paralysées par la peur, et n’agiront pas. Les employés commenceront alors à acheter et utiliser ces outils eux-mêmes, pour faire ce que les grandes structures ne veulent pas dépenser.

Certaines entreprises, pour des raisons diverses, seront prêtes à prendre des risques, car leur situation financière le permet. Elles deviendront des leaders dans leur domaine, à condition de rester financièrement saines. Il n’y aura pas de situation où un CFO, par peur d’être licencié, empêche tout le monde d’y aller. Il y aura des erreurs, mais c’est normal.

Je pense que cela créera une segmentation très intéressante du marché. Les PME audacieuses, prêtes à investir tôt et à prendre des risques, pourraient prendre une avance sur les grands groupes. Elles auront suffisamment de ressources pour l’IA, sans être entravées par des systèmes hérités ou une aversion au risque.

Par ailleurs, de nouveaux types de services émergeront. Imaginez créer une agence marketing, une société de conseil en ingénierie ou une entreprise de design architectural, entièrement basée sur des agents IA, sans barrières d’information, avec tout le contexte nécessaire, capable de programmer à la demande. Ces entreprises auront un potentiel disruptif énorme, jusqu’à ce que les acteurs établis puissent se libérer de leurs contraintes.

Le budget token : le nouveau champ de bataille de la gestion de projet

Une discussion sur le budget token m’a paru à la fois réaliste et absurde. Aaron Levie dit : “Les discussions sur le budget de calcul pour les agents seront parmi les plus folles dans les prochaines années.”

Pourquoi ? Parce que les coûts de calcul représentent entre 14 % et 30 % du chiffre d’affaires de toute entreprise technologique cotée. Le coût de calcul est deux fois, voire trois fois, celui de l’ingénierie — et cette différence peut faire toute la différence sur le bénéfice par action.

Steven Sinofsky pense que nous n’avons pas encore la réponse, et que les CFO veulent toujours une réponse à des questions qu’ils ne comprennent pas. Wall Street leur impose de donner un chiffre, puis ils sont licenciés, et le cycle recommence. Ce n’est pas nouveau : on a vécu cela avec la bande passante internet, les tubes à vide, les transistors, le nombre de programmeurs.

Mais Aaron Levie insiste : cette fois, c’est différent. Il avance un bon point : jamais auparavant chaque utilisateur final d’une organisation n’a eu la capacité de lancer des ressources de façon totalement flexible. Et dans bien des cas, c’est tout à fait rationnel.

Cela ressemble à la transition vers le cloud dans les années 2000, quand on est passé du CapEx (dépenses d’investissement) à l’OpEx (dépenses d’exploitation), puis à une dépense illimitée. Aaron se remémore que chez Box, les CFO disaient : “Vous ne comprenez pas, nous sommes une entreprise agricole, on ne connaît que le CapEx”, ou alors “Nous sommes une entreprise OpEx, on aime le cloud.” La différence comptable influence vraiment l’adoption technologique.

Mais la question du budget token est encore plus fine. En tant que responsable technique, faut-il faire en sorte que chaque prompt soit évalué en termes de coût de calcul ? Faut-il privilégier des prompts longs ou courts ? Faut-il paralléliser ? Quel est le seuil de tolérance à la perte de tokens ?

Aaron pense qu’il faut dépenser beaucoup de tokens, car cela permet d’expérimenter. Le responsable technique doit-il encourager son équipe à lancer 10 expérimentations en parallèle ? Même si cela gaspille 90 % des tokens, cela peut mener à une voie de succès. Ou faut-il plutôt concevoir un système parfait avant de lancer ?

Au moment de l’enregistrement, beaucoup s’affolent à l’idée de limiter Claude Code à un Max de prompts. C’est une question très concrète, qui ne sera résolue que lorsque nous aurons suffisamment de capacité de data centers.

Mais je partage la vision à long terme de Sinofsky : ce problème finira par disparaître. La clé, c’est de faire des calculs à la Benioff, en se demandant : combien vaut l’outil pour un commercial qui paie 100 000 dollars par an ? Et pour un ingénieur, si on lui donne X dollars, son outil doit valoir au moins cette somme à un moment donné.

Et la loi des grands nombres finira par équilibrer tout cela. Avec suffisamment d’ingénieurs utilisant beaucoup de calculs, la tendance sera à l’équilibre. Nous sommes encore en transition : il y a deux ans, beaucoup pensaient que le coût de l’IA se limitait à un chatbot. Ils avaient tort, car ils voyaient cela comme un cas d’usage isolé, alors qu’en réalité, c’est une transformation à l’échelle de la plateforme.

L’avenir des systèmes SaaS : la valeur du niveau de données

Une discussion sur l’avenir des systèmes d’entreprise m’a marqué : Martin Casado a souligné que les fournisseurs SaaS ne vendent pas vraiment des données métier, mais un savoir-faire, une expertise, un système complet. Mais les agents veulent acheter des données, simplement y avoir accès, sans limite. Or, ce n’est pas leur modèle d’affaires.

Cela a toujours été un point de tension avec des systèmes comme Workday ou SAP : combien d’API autoriser ? Salesforce a connu trois refontes majeures de sa plateforme pour cela. La question technique est : qu’est-ce qu’un système de référence (system of record) quand on veut accéder aux données ?

Steven Sinofsky a été très clair : “Tenter de faire un SAP avec du vibe coding, c’est absurde.” Tout le savoir-faire métier dans SAP ne réside pas seulement dans une couche de données bien orchestrée. Il est dans l’UI, dans la couche intermédiaire, dans la façon dont on l’utilise.

Mais Aaron Levie a une vision différente. Il pense qu’avec suffisamment d’itérations, l’agent finira par choisir lui-même ses outils. Même s’il ne pourra pas remplacer complètement un système d’entreprise, après plusieurs générations, il pourra rencontrer tellement d’obstacles que l’agent dira : “Il faut que tu remplaces ton ancien système RH, sinon je ne peux pas automatiser ce processus.”

C’est une idée disruptive. Imaginez : si le nombre d’agents est 100 ou 1000 fois celui des humains, et si ces situations se répètent, il faudra finir par construire une pile logicielle spécifique pour ces agents. Peut-être que quelques systèmes, comme certains ERP, resteront en place, mais tout le reste dépendra de la capacité de votre infrastructure à leur fournir les bonnes données pour faire leur boulot. Votre architecture IT devra donc être conçue pour supporter ces agents.

Martin Casado a souligné une nuance que je partage : on parle souvent de “marketing pour l’agent”, “de devenir une API”, “d’avoir de bonnes descriptions d’interface”. Mais c’est presque totalement faux. La vraie force des agents, c’est leur capacité à trouver le bon backend. Ils ne diront pas “cet API est joli, la documentation est claire”, mais “ce paramètre de coût, cette persistance, c’est ça qui compte”. En réalité, ils détiennent la sagesse collective de notre utilisation de ces plateformes.

Il a donné un exemple : chaque fois qu’il laisse un agent choisir une plateforme cloud, il utilise des critères significatifs, pas seulement l’interface. En tant qu’industrie, nous sommes trop concentrés sur ces interfaces, alors que le vrai enjeu, c’est de construire de meilleurs systèmes, qui seront choisis.

Je pense que cette idée est très profonde. À l’ère des agents, la supériorité technique deviendra encore plus cruciale, et le marketing ou le packaging perdront de leur importance. Les produits réellement compétitifs seront ceux qui maîtrisent la technique, et ceux qui s’appuient surtout sur la vente auront du mal.

Ma réflexion : nous sous-estimons l’ampleur de cette transformation

En écoutant tout ce dialogue, mon sentiment principal est que Wall Street et l’industrie dans son ensemble utilisent un cadre erroné pour comprendre l’impact économique de cette révolution. Aaron Levie a raison : le vrai problème, c’est que tout le monde essaie d’évaluer la valeur économique, mais ils surestiment ou sous-estiment l’ampleur de l’opportunité d’au moins un ordre de grandeur.

Steven Sinofsky a illustré cela avec l’histoire du PC : on pensait que la consommation de MIPS (millions d’instructions par seconde) était limitée, mais on n’avait pas anticipé ce qui se passerait si on mettait ces MIPS dans chaque bureau. Et on pensait que le logiciel suivrait la croissance des MIPS, mais seul Bill Gates et Paul Allen ont compris qu’on pouvait vendre le logiciel séparément.

La même chose s’est produite avec le cloud. On pensait que c’était simplement déplacer des serveurs — environ 60 000 par an — dans des data centers externes. Personne n’a prévu que la consommation allait augmenter d’un facteur mille.

Pour l’IA, c’est pareil. Le modèle de Wall Street est une répartition fixe des revenus. Ils pensent que chaque entreprise dépensera une somme fixe chaque année. Mais avec le cloud, Salesforce, par exemple, génère 2 milliards de dollars par an en CRM, en achetant des serveurs, des licences Oracle, en supportant des déploiements compliqués, et en consultant pendant des années. Si on permet à chaque vendeur de s’inscrire individuellement, sans friction, cela change tout.

Je pense que l’agent IA va entraîner une expansion de marché encore plus grande, voire exponentielle. Quand chaque travailleur du savoir aura un ou plusieurs agents à ses côtés, la consommation de logiciels, la quantité de données traitées, la puissance de calcul nécessaire, vont exploser. Ce n’est pas une compétition à somme nulle : ce n’est pas simplement transférer du travail humain vers des agents, mais créer de nouvelles possibilités et de nouvelles valeurs.

Aaron Levie a mentionné qu’en tant qu’investisseur, il a observé une croissance asymptotique dans environ 240 entreprises d’infrastructure ces six derniers mois. Pourquoi ? Parce qu’aujourd’hui, on écrit plus de logiciels que jamais. Avec plus de logiciels, plus d’agents, il y aura plus de consommation de calculs. Quand chaque smartphone consommera massivement d’IA, et que l’IA en périphérie deviendra réalité, la demande augmentera d’un milliard de fois.

Je crois que nous vivons une “ère du transistor”. Steven Sinofsky a illustré cela avec l’exemple des tubes à vide : autrefois, on pensait que tout le Dakota serait rempli de tubes à vide, que l’on changeait dans les couloirs en patin à roulettes, pour la Seconde Guerre mondiale. Puis quelqu’un a dit : “Et si on utilisait des transistors ?”

Les tokens seront comme les MIPS d’IBM. IBM vendait plus de MIPS chaque année à un prix plus bas, mais en facturant toujours par MIPS, jusqu’à ce qu’on réalise que leur courbe de coût baisse, car ils produisent des MIPS plus vite que leur prix ne baisse. La même logique s’appliquera aux tokens.

Mais à court terme, nous allons vivre beaucoup de chaos et d’incertitude. Les entreprises vont hésiter entre investir, contrôler leurs coûts, gérer leurs risques. Les startups vont prendre des risques audacieux, avancer rapidement. Il y aura des échecs, mais aussi des succès. À long terme, la direction est claire : le logiciel doit être conçu pour les agents, les API seront plus importantes que l’UI, la qualité du système surpassera le marketing, le coût de calcul continuera de baisser, tandis que l’usage explosera.

Ce n’est pas une simple mise à niveau d’outils, mais une transformation radicale du paradigme du calcul. Ceux qui comprendront cela et agiront définiront la nouvelle décennie technologique. Ceux qui s’accrocheront à l’ancien cadre seront laissés derrière.

Ce changement ne fait que commencer.