Le logiciel extensible à l'âge agentique

Les agents de code rendent le logiciel extensible plus précieux : davantage d'utilisateurs peuvent transformer de petits irritants de workflow en outils fonctionnels.

Pendant longtemps, l'extensibilité était une fonctionnalité pour power users.

La plupart des gens utilisaient les logiciels tels qu'ils étaient livrés. Un groupe plus restreint les personnalisait avec des réglages, des scripts, des plugins, des thèmes, des macros ou des fichiers de configuration. Un groupe encore plus restreint allait plus loin et traitait le programme comme une plateforme : quelque chose à inspecter, plier et étendre jusqu'à ce qu'il corresponde à sa manière de travailler.

Ce dernier groupe était toujours limité par le coût de la programmation. Même lorsqu'une application exposait un beau système d'extension, l'utiliser demandait encore du temps, de la compétence, de la documentation, de la patience et l'envie de maintenir le résultat. Si vous vouliez que votre éditeur affiche une information de type supplémentaire, que votre navigateur ajoute un bouton sur une page ou que votre bureau affiche un petit widget personnalisé, il fallait écrire le code vous-même. Pour beaucoup de gens, la friction était trop élevée. L'idée restait une idée.

Le codage agentique change cela.

Le changement important n'est pas que tout le monde devient programmeur professionnel. C'est qu'un nombre beaucoup plus grand de personnes peut maintenant décrire un petit morceau de logiciel dont elles ont besoin et demander à un agent de code d'en construire une première version. Cela compte surtout lorsque le programme cible est déjà conçu pour être étendu.

Vous voulez une extension de navigateur qui résume les commentaires d'un post Reddit ? C'est maintenant un projet personnel raisonnable. Vous voulez un petit widget GNOME qui affiche des conjugaisons françaises pendant que vous étudiez ? Raisonnable aussi. Vous voulez une commande dans votre éditeur qui rassemble l'état du projet, ouvre le bon worktree et démarre un agent avec un prompt structuré ? Raisonnable.

Ce ne sont pas des idées de startup. Ce ne sont pas des produits. Ce sont ces petits outils personnels, spécifiques à un contexte, qui mouraient généralement avant l'implémentation parce que le gain ne justifiait pas le coût de mise en place. Les agents de code réduisent fortement ce coût.

Les agents de code réduisent le coût des petites extensions personnelles, ce qui rend davantage d'outils de niche intéressants à construire.

Cela rend les programmes extensibles plus précieux, pas moins.

Si un logiciel est une boîte fermée, l'agent ne peut que travailler autour. Il peut automatiser l'interface, générer des fichiers depuis l'extérieur ou écrire du code de collage à côté. Parfois cela suffit, mais c'est fragile. Les meilleurs résultats arrivent lorsque le programme expose une vraie surface d'extension : API documentées, hooks stables, commandes scriptables, état lisible, configuration, événements et conventions qui rendent les changements locaux naturels.

Les agents sont plus utiles lorsque le logiciel leur donne de vrais points d'extension au lieu de les forcer à travailler depuis l'extérieur.

Plus un programme peut s'expliquer lui-même, plus un agent devient utile à l'intérieur.

C'est pour cela qu'Emacs me semble à nouveau moderne.

Emacs est assez vieux pour que, selon les règles habituelles de la mode logicielle, il ressemble à une pièce de musée. À la place, son idée centrale paraît meilleure chaque année. Sa description célèbre est : « The extensible, customizable, self-documenting real-time display editor. »

Cette phrase est presque une spécification du type de logiciel qui fonctionne bien avec les agents de code.

Extensible signifie que le programme s'attend à être modifié. Customizable signifie que les utilisateurs peuvent faire servir ces changements à leur propre workflow au lieu d'attendre qu'une équipe produit valide une version générique de la fonctionnalité. Self-documenting signifie que le système porte assez d'information sur lui-même pour qu'un utilisateur, et maintenant un agent, puisse découvrir comment interagir avec lui.

Le dernier point est facile à sous-estimer. La documentation n'est pas seulement faite pour des humains lisant un manuel dans un navigateur. C'est aussi de la matière pour les outils. Si les commandes, variables, fonctions, keymaps, modes et hooks sont inspectables, un agent a quelque chose à saisir. Il peut demander à l'environnement ce qui existe. Il peut générer du code qui suit les conventions locales. Il peut connecter un nouveau comportement au programme de la manière attendue par celui-ci.

J'ai ressenti ce contraste directement.

Il y a quelques années, quand le vérificateur de types Flow de Facebook était encore courant dans les projets JavaScript, je voulais qu'Emacs affiche les informations de type Flow via eldoc. L'idée était simple : mettre le type près du code pendant que je travaillais. L'implémentation ne l'était pas. Il fallait comprendre l'intégration éditeur, l'interface en ligne de commande de Flow, la forme des réponses, le timing, le comportement d'affichage et l'Emacs Lisp nécessaire pour relier tout cela. Cela a pris beaucoup plus de temps que la fonctionnalité ne semblait le mériter.

Récemment, j'ai eu un autre problème. Le codage agentique avait fait des worktrees Git une partie de mon workflow quotidien, et je voulais une interface Emacs pour gérer plusieurs tâches d'agents en parallèle. Je voulais voir quels worktrees existaient, sur quelles branches ils étaient, quels agents tournaient et quelles tâches attendaient une revue. Je ne voulais pas quitter Emacs pour une application séparée si le reste de mon workflow y vivait déjà.

J'ai donc construit ceci :

emacs-superset sur GitHub →

La différence n'était pas que j'étais soudain devenu un bien meilleur programmeur Emacs Lisp. La différence était que je pouvais utiliser un agent pour m'aider à concevoir et implémenter l'outil dans un environnement déjà fait pour être étendu. En une journée, j'avais quelque chose d'assez utile pour entrer dans ma routine quotidienne.

C'est ce futur qui m'intéresse : pas seulement des applications générées par IA, mais l'adaptation assistée par IA des applications que nous utilisons déjà.

Cela suggère un autre standard pour le design logiciel. Un programme qui veut bien vieillir ne devrait pas seulement demander : « Quelles fonctionnalités devons-nous livrer ? » Il devrait aussi demander : « Que peuvent construire ici les utilisateurs et leurs agents, en sécurité, sans nous demander ? »

Cela signifie que les points d'extension devraient être traités comme des surfaces produit de premier ordre. Les API devraient être stables et documentées. La configuration devrait être inspectable. Les concepts internes devraient avoir des noms. Les commandes devraient être composables. L'état devrait être disponible sous des formes structurées. Les plugins devraient être faciles à créer, tester et partager. Le programme devrait rendre les petits changements locaux peu coûteux.

Cela ne signifie pas que chaque application doit devenir Emacs. Beaucoup d'utilisateurs veulent encore un logiciel qui fonctionne immédiatement et ne leur demande jamais de penser à des points d'extension. La plupart devraient obtenir exactement cela. Mais la présence des agents de code change l'économie de la longue traîne des besoins personnels. Des fonctionnalités autrefois trop spécifiques pour entrer dans le produit peuvent maintenant être construites par les personnes qui en ont besoin, si le programme hôte leur donne un point d'appui.

Les gagnants, je pense, seront les programmes qui exposent assez de structure pour que les agents puissent aider sans demander aux utilisateurs de devenir experts de toute la base de code.

Dans le monde pré-agent, l'extensibilité récompensait surtout l'utilisateur rare qui avait à la fois l'envie et la capacité de programmer ses outils. Dans le monde agentique, ce groupe devient beaucoup plus grand. Davantage de personnes pourront dire : « J'aimerais que ce programme fasse une petite chose différemment », puis le rendre vrai.

Cela rend l'extensibilité moins semblable à un luxe de power user et davantage à une propriété centrale du logiciel durable.