Tous les produits de la catégorie suivi du temps — y compris le nôtre — demandent à l’utilisateur de beaucoup cliquer avant de devenir réellement utiles. Paramètres de projet. Groupes de permissions. Règles de notification. Constructeurs de rapports personnalisés. Le glisser-déposer dans la vue planning. La première semaine avec n’importe lequel de ces outils se ressemble toujours : on ouvre une boîte de dialogue, on choisit dans une liste, on enregistre, on attend le rechargement de la page, on ouvre la boîte de dialogue suivante. Une demi-journée plus tard, on a un espace de travail qui fait à peu près ce dont l’équipe a besoin.

Pendant longtemps, ces clics étaient le prix à payer pour utiliser un logiciel. La friction de la mise en place faisait partie du travail.

Ce qui est en train de changer — doucement au début, puis de plus en plus vite — c’est que ce coût n’est plus nécessaire. Il existe une autre façon de transmettre l’intention de l’utilisateur au produit, et une fois qu’on a utilisé un logiciel construit sur cette autre approche, l’ancienne commence à paraître lourde. Pas lente. Lourde. Comme si elle vous demandait de faire un travail que vous ne pensez plus vous incomber.

Ce ressenti est en train de se diffuser chez beaucoup de gens en ce moment, discrètement. C’est ce petit moment intime auquel ressemble un changement de catégorie vu de l’intérieur, avant que le discours public ne rattrape son retard.

Le contrat de traduction

Jusqu’à très récemment, le seul mécanisme dont nous disposions pour transformer l’intention d’un utilisateur en comportement informatique, c’était l’interface : menus, boutons, champs, boîtes de dialogue, poignées de glissement. L’utilisateur pensait « je veux que les commerciaux et les ops voient ce rapport, mais que seuls les ops puissent le modifier », et son travail consistait à traduire cette pensée en la bonne séquence de clics répartis sur trois écrans. Le travail du produit, c’était de rendre cette séquence aussi courte et sans ambiguïté que possible. Des carrières entières se sont construites sur la différence entre quatre clics et trois.

Nous avons fait de notre mieux dans cette contrainte. Certains des produits les plus appréciés de la dernière décennie étaient simplement le fruit d’équipes qui avaient rendu la séquence plus courte que tout le monde.

Mais la contrainte était toujours là. C’était le contrat de l’époque : l’utilisateur fait la traduction, le logiciel exécute le résultat.

Une affirmation prudente

Je tiens à être prudent sur ce que j’avance ici, parce que la conversation autour de l’IA et du logiciel est devenue un peu floue.

Je ne dis pas que les fonctionnalités vont disparaître. Les produits doivent toujours faire des choses précises ; le monde a toujours besoin de facturation, de suivi du temps, de gestion des stocks et de CRM. Je ne dis pas non plus que « le langage naturel est la nouvelle interface » au sens fort, où tout deviendrait une fenêtre de chat. Le chat est une forme parmi d’autres, et bien souvent, ce n’est pas la bonne.

Ce qui se passe concrètement, c’est que la couche de configuration des logiciels — les mille petites décisions qu’un utilisateur doit encoder via des clics pour que le produit fasse ce qu’il faut dans sa situation — devient accessible par le langage. Ce que vous configuriez à la main, vous le décrivez. Ce que le produit vous obligeait à assembler à partir de briques élémentaires, le produit l’assemble pour vous, à partir de votre description.

C’est une affirmation plus modeste que « l’IA change tout ». C’est aussi une affirmation plus solide. L’ère de l’interface ne touche pas à sa fin parce que quelqu’un a inventé un truc radicalement nouveau. Elle touche à sa fin parce que la part de chaque interface qui demandait à l’utilisateur de faire un travail de traduction n’a plus besoin d’exister.

Dans notre propre produit

Chez WebWork, nous avons intégré cela directement dans le tracker. WebWork AI est un assistant agentique qui vit aux côtés du reste du produit. Vous lui demandez ce que vous avez besoin de savoir sur votre équipe, et il vous répond. Vous lui dites de créer une tâche, un projet, un standup, et il le fait. Il observe les signaux du quotidien — qui s’est connecté quand, qui suit quoi, où l’activité monte ou descend — et fait remonter ce qui compte, sans que vous ayez à aller chercher. Risque de burnout, dépassement de budget, anomalies dans les habitudes de quelqu’un : un manager en est informé avant même d’avoir eu l’idée de poser la question.

Ce qui est remplacé, ce ne sont pas les écrans de configuration eux-mêmes. Ils sont toujours là pour ceux qui les veulent. Ce qui est remplacé, c’est le travail de les manipuler. Les questions auxquelles vous répondiez en ouvrant trois tableaux de bord, vous les posez désormais en une phrase. Les tâches que vous créiez en cliquant sur cinq champs, vous les décrivez maintenant à la voix ou dans un chat. Le rapport hebdomadaire que vous assembliez à la main est assemblé pour vous et arrive dans votre boîte mail.

L’interface n’a pas disparu. C’est le travail de la manipuler qui a disparu.

Ce que le travail devient

La question naturelle, pour quiconque travaille dans le logiciel, c’est de savoir si tout cela nous met au chômage — si construire un produit revient, à terme, simplement à le décrire à un modèle.

Je ne le pense pas, mais la réponse est plus intéressante qu’un simple non. Le travail qui disparaît, c’est celui de traduire l’intention de l’utilisateur en primitives d’interface. Ce travail a toujours été dérivé ; on le faisait parce que l’utilisateur ne le pouvait pas, pas parce que c’était la partie intéressante. Le travail qui reste, et qui devient plus difficile, c’est de déterminer exactement ce que le produit doit faire, pour quels utilisateurs, dans quelles situations, avec quels compromis. Le travail de décision. Le travail de goût. Le travail du « pourquoi ceci et pas cela ».

Quiconque a travaillé dans le logiciel pendant plus de quelques années sait que la conception d’une page de paramètres était rarement le facteur limitant de la qualité d’un produit. Le vrai goulot d’étranglement, c’était de savoir ce que cette page de paramètres devait permettre à l’utilisateur d’exprimer. Ce savoir-là ne va nulle part ; il devient même plus visible, parce qu’on ne peut plus le dissimuler derrière l’artisanat de l’interface.

La traduction comme défaut

Pour ceux qui construisent des logiciels aujourd’hui, ce que je voudrais partager — non pas comme une prédiction, mais comme quelque chose sur lequel nous agissons concrètement avec notre propre produit — c’est que chaque endroit où vous demandez actuellement à l’utilisateur de traduire son intention en clics est désormais un défaut. Pas une surface fonctionnelle. Un défaut. Cela a toujours été un emprunt fait aux limites de ce que le logiciel pouvait comprendre. La limite s’est déplacée.

Ce qui remplacera les clics ne sera pas le même dans chaque catégorie. Parfois ce sera une description. Parfois un exemple. Parfois un agent unique qui observe ce que vous faites pendant une semaine et vous pose ensuite, gentiment, trois questions. La forme varie. Le principe, non : la charge de la traduction passe de l’utilisateur au système, là où elle aurait toujours dû être, et où pour la première fois elle peut effectivement résider.

Les logiciels que les gens utiliseront dans quelques années seront plus silencieux que ceux qu’ils utilisent aujourd’hui. Moins de clics. Moins de configuration. Moins de choses à retenir. Plus de ce qu’ils voulaient vraiment, plus vite, en y laissant moins d’eux-mêmes.

Nous ne construisons pas vers une interface plus bruyante. Nous construisons vers une interface plus silencieuse.