Quinze clics, une phrase
Lundi, 8 h. Une responsable de formation ouvre la plateforme. Elle ne touche pas au menu. Elle écrit : « Assigne le module d'accueil aux trente nouveaux, échéance vendredi, et préviens-les. »
Félix lui renvoie une carte : trente noms, une date, un message, un coût. Elle relit. Elle valide. Quinze clics sur quatre écrans tiennent désormais en une phrase.
Nous n'avions pas planifié cette bascule. Début octobre, nous avons compté tout ce qu'un utilisateur peut faire à la main dans notre logiciel : 989 gestes. Puis nous les avons appris à Félix, famille par famille.
En quelques semaines, les habitudes ont changé de camp. Plus personne ne demande « où est ce réglage ? ». On demande le résultat. Un superviseur de centre d'appels ne croise plus trois tableaux : il demande quels conseillers ont baissé sur l'accueil ce mois-ci.
Je n'ai pas encore le chiffre pour le prouver. Mais j'ai assez vécu de bascules pour reconnaître celle-ci : on ne revient pas en arrière.
Quarante ans à montrer du doigt
Depuis le premier Macintosh, en 1984, se servir d'un logiciel veut dire pointer. On cherche le menu. On ouvre la fenêtre. On remplit les champs. Le logiciel ne comprend rien, alors c'est nous qui apprenons sa carte.
Les modèles de langage ont inversé la charge. Le logiciel comprend enfin une intention dite avec nos mots. On arrive à destination sans connaître la carte.
Les développeurs l'ont vécu les premiers. Dans beaucoup d'équipes, on n'écrit presque plus le code : on le décrit, l'assistant l'écrit, on le relit. Le code est toujours là. La frappe, elle, a disparu, et le vrai travail est monté d'un étage : savoir ce qu'on veut, puis vérifier qu'on l'a obtenu.
Les écrans de gestion prennent le même chemin, et pour la même raison.
La saisie va mourir
Formulaires, menus déroulants, cases à cocher une à une : c'est l'étage qui tombe en premier. Les réglages qu'on touche deux fois par an, les opérations en masse, les tâches qui traversent quatre écrans. Une phrase y bat quinze clics, et personne ne pleurera ces clics.
Les fonctions enterrées vont enfin servir. Un logiciel de gestion cache l'essentiel de ses fonctions au fond des menus, et la plupart des clients n'en exploitent qu'une fraction. Quand on peut demander, on n'a plus besoin de savoir où chercher.
L'administrateur change de métier. Il n'opère plus l'outil : il formule une intention, puis il contrôle. On lui demandera moins de savoir où cliquer, davantage de savoir quoi demander.
Surtout, chaque action a désormais un prix. Un clic ne coûte rien à l'éditeur. Une phrase coûte des jetons : chez nous, un peu moins d'un centime de dollar par échange. Nous l'avons déjà réduit d'un tiers. Il ne tombera jamais à zéro.
Un dogme s'effondre sans bruit. Le SaaS reposait sur un coût marginal quasi nul : un client de plus, un usage de plus, presque rien à payer. Avec un agent, chaque demande a un coût de revient.
Et la confiance change d'adresse. Quand une phrase touche deux cents comptes, il faut pouvoir dire qui a demandé quoi, et ce que la machine a compris. Le journal d'audit sort de la cave technique pour devenir une fonction du produit.
Personne ne délègue son regard
On parle pour demander. On regarde pour comprendre. Un tableau de progression se lit en deux secondes, et personne ne veut qu'on le lui récite. Même Félix, quand il répond à voix haute, finit par : « je vous mets le détail à l'écran ».
La main garde l'avantage sur le geste fin. Ordonner un parcours, retoucher une diapositive, placer un objet dans une scène en 3D : répéter dix fois « un peu plus à gauche », c'est un supplice.
La confiance passe par les yeux. Avant d'agir sur deux cents apprenants, on veut voir la liste. Le formulaire, lui, renaît sous forme de carte à valider, préparée d'avance, au moment exact où elle sert.
Apprendre reste un geste. Côté apprenant, l'écran est le produit : le quiz, la simulation d'appel, le jeu de rôle. On ne délègue pas son entraînement.
Et le métier reste dans le logiciel. La règle de notation d'une grille, l'ordre d'un parcours, les droits de chacun. Un agent privé de ces règles parle bien, mais il parle à côté.
Vos écrans ne sont plus votre produit
À ceux qui éditent un logiciel, je le dis sans détour : votre produit, ce sont désormais vos capacités. Chaque action du métier doit exister comme une capacité sûre, limitée à l'espace du client et aux droits de la personne, validable avant exécution. L'écran devient un client de ces capacités. L'agent en est un autre.
Nous l'avons appris en chemin. Un agent passe partout où vos écrans avaient des garde-fous implicites : un bouton absent, un menu réservé. Chaque capacité doit revérifier elle-même qui demande, et pour quel espace.
L'écran devient une preuve. Dialogue d'abord, écran ensuite : chaque action de l'agent doit finir sur l'écran qui montre le résultat. L'effort de conception quitte les formulaires pour aller vers ce qui se regarde : tableaux, aperçus, écarts.
Le mode manuel devient une assurance. Si l'essentiel de l'administration passe par l'agent, une panne du fournisseur d'IA paralyse vos clients. Tout ce qui est critique doit rester faisable à la main.
Enfin, il faut forcer le regard, gentiment. Un responsable qui ne voit plus jamais ses écrans perd l'image de ses données, et ne repère plus les erreurs de la machine. Oser l'IA, oui. Garder la main, toujours.
Reste la question qui fâche : qui paie l'intelligence ?
MCP, ou la double facture
On me répond souvent : pourquoi construire un agent ? Ouvrez un serveur MCP, et laissez le client brancher son propre assistant. Le protocole, lancé fin 2024, est aujourd'hui adopté par les grands assistants. Sur le papier, c'est élégant.
Regardons la facture. Le client paie son abonnement au logiciel, tarifé à l'époque où la valeur passait par les écrans. Il paie aussi son assistant, qui fait désormais le travail des écrans. Deux factures pour un seul service.
L'éditeur, lui, garde l'hébergement, la sécurité et le support. Mais il perd la relation : il ne voit plus ce que son client cherche à faire, ni où il bute. Il devient une base de données avec des droits d'accès. Donc remplaçable.
| L'intelligence vient de | Qui paie les jetons | La facture du client | Le piège |
|---|---|---|---|
| L'éditeur, inclus dans l'abonnement | L'éditeur | Un forfait plus cher | Une dépense variable cachée sous un prix fixe |
| L'éditeur, facturé à l'usage | Le client, en crédits | L'abonnement, plus sa consommation | Le client hésite à demander |
| Le client, par MCP | Le client, chez son fournisseur d'IA | Deux factures, si rien ne change | L'éditeur devient interchangeable |
La double facture n'a rien d'une fatalité. Elle disparaît le jour où l'éditeur sépare dans son prix le métier (les données, les règles, les droits) de l'intelligence (les jetons). Le client choisit alors qui fournit l'intelligence. S'il apporte la sienne, il paie moins.
Chez nous, la question est presque tranchée. Centres de formation, banques, écoles d'Afrique de l'Ouest : rares sont ceux qui paient déjà un assistant d'entreprise. Pour eux, l'IA du logiciel est la seule IA, et elle doit afficher son prix avant chaque action.
MCP restera une porte utile pour les grandes organisations déjà équipées. Mais une porte n'est pas un modèle économique. La valeur d'un SaaS, demain, se logera là où l'assistant générique ne sait rien : la pédagogie, les grilles, l'historique de chaque apprenant, les règles du métier.
Trois questions pour lundi matin
Si vous éditez un SaaS : le jour où vos clients ne verront plus aucun de vos écrans, que leur restera-t-il de vous ?
Si vous en achetez un : le jour où l'IA tombe en panne, votre équipe peut-elle encore travailler ?
Et dans les deux cas : qui paie l'intelligence que vous utilisez, combien, et le voyez-vous avant de dire oui ?
Nos utilisateurs ont arrêté de cliquer. Ils n'ont pas arrêté de regarder. Les logiciels qui l'oublieront deviendront des tuyaux.