L'UI n'est plus l'interface. L'agent l'est. L'UI est le rapport.
On entre dans l'ère agentique et pourtant, des fondateurs investissent encore six à douze mois à designer des interfaces que personne n'utilisera directement dans trois ans. L'utilisateur final de votre SaaS ne sera plus humain dans la majorité des transactions opérationnelles. Ce sera son agent.
Le réflexe est compréhensible. On construit ce qu'on connaît. Mais ce qu'on connaît, c'est le SaaS d'avant. Ce qu'on bâtit aujourd'hui doit fonctionner dans le monde qui s'installe, pas dans celui qui s'éteint.
Chez HUBBVEE, on pose maintenant systématiquement la même question à chaque fondateur, chaque équipe produit, chaque éditeur SaaS : est-ce que vous bâtissez agent first, ou est-ce que vous bâtissez à reculons ?
1. Le constat : bâtir à l'envers en 2026
Regardez la plupart des roadmaps SaaS livrées en 2026 et vous verrez le même artefact : des workflows linéaires emballés dans une UI bien finie, avec un humain au centre qui clique pour exécuter. Ça a l'air moderne. C'est structurellement legacy.
Si ça persiste, c'est par confort. L'UI, c'est ce que les équipes ont été entraînées à construire. Designers, PMs, ingénieurs — toute la chaîne est optimisée autour de l'écran comme unité de livraison. Les démos de sprint, ce sont des écrans. Les decks investisseurs, ce sont des écrans. L'onboarding client, ce sont des écrans.
Mais le comportement utilisateur a déjà bougé. Des fondateurs gèrent leur semaine à travers des agents. Des équipes d'opérations routent les tâches via Claude, ChatGPT et des copilotes internes. Les acheteurs commencent à demander, en appel d'offres, si le fournisseur a un serveur MCP. Le signal est sans ambiguïté. Le parcours client ne se termine plus sur un écran destiné à un humain.
Bâtir à l'envers, c'est designer pour l'utilisateur qui sort, pas pour celui qui entre.
2. La nouvelle stack : Human to Agent, Agent to SaaS, Agent to All
La nouvelle stack opérationnelle a trois couches et le SaaS n'est plus au sommet.
Human to Agent. L'humain donne l'intention. « Roule la clôture hebdomadaire. » « Rembourse le client dont la commande a été expédiée deux fois. » « Rédige un avenant de contrat pour les nouveaux termes de paiement. » La conversation se passe en langage naturel, sur la surface que l'humain préfère — un chat, un assistant vocal, un fil dans un espace de travail partagé.
Agent to SaaS. L'agent traduit l'intention en opérations à travers les plateformes qui détiennent les données. Shopify pour la commande, Klaviyo pour la fiche client, l'ERP pour l'ajustement d'inventaire, le système comptable pour l'écriture journal. Le SaaS devient une couche d'API consommée par un agent, pas une destination où un humain va cliquer.
Agent to All. C'est la couche que la plupart des équipes sous-estiment. L'agent ne reste pas dans une seule plateforme. Il orchestre l'ensemble du graphe opérationnel en parallèle. Shopify, Klaviyo, Gorgias, HubSpot, l'ERP, le tableau financier — tous touchés à l'intérieur de la même intention. Le silo applicatif disparaît au profit d'un orchestrateur transversal.
L'implication stratégique est sévère. Si votre SaaS est conçu comme une destination, vous pariez à contre-courant. Si votre SaaS est conçu comme un participant dans une orchestration pilotée par agent, vous pariez dans le sens du courant.
3. L'UI redevient ce qu'elle aurait toujours dû être : un rapport
La belle interface n'est plus le produit. Le produit, c'est l'opération. L'interface devient la surface où les humains voient ce que les agents ont fait, ce qu'ils proposent de faire ensuite, et ce qui exige une décision humaine avant d'aller plus loin.
Le design ne sert plus l'exécution. Le design sert la supervision, la validation, l'intervention.
L'attention pixel parfait se déplace :
- Du formulaire à la timeline d'activité
- Du bouton CTA au journal de décision
- Du dashboard vanity au cockpit opérationnel
- Du tunnel d'onboarding au moment de confiance où l'agent demande une autorisation humaine
Ce n'est pas la fin du design comme discipline. C'est sa réorientation. Les meilleurs designers en 2026 n'optimisent plus le chemin de clic. Ils designent la surface de collaboration humain-agent — quand l'agent décide seul, quand il demande, quoi montrer, quel contexte porter, comment confesser une incertitude.
C'est un problème de design beaucoup plus difficile que les dashboards SaaS de la décennie précédente. Et c'est celui qui compte maintenant.
4. Le harness d'agent : l'infrastructure invisible
Un agent seul ne suffit pas. Il lui faut un harness.
Le harness, c'est la différence entre une démo et une opération. C'est aussi la partie qui disparaît des slides marketing parce qu'elle n'est pas sexy. Mais c'est elle qui détermine si l'agent vous fait gagner de l'argent ou vous met à risque.
Les composantes essentielles du harness :
- Gestion du contexte et de la mémoire. Que sait l'agent à un moment donné, quoi se souvient-il entre les sessions, quoi doit-il oublier pour respecter la vie privée.
- Accès aux outils et aux APIs. Quels systèmes l'agent peut-il toucher, avec quels accès, sous quels périmètres.
- Politiques de décision et garde-fous. Qu'est-ce que l'agent peut faire de manière autonome, qu'est-ce qui demande une autorisation humaine, qu'est-ce qui est complètement interdit.
- Observabilité et journalisation. Chaque action, chaque décision, chaque appel d'outil capturé pour audit et débogage.
- Fallback humain structuré. Quand l'agent ne sait pas quoi faire, comment escalade-t-il, à qui, avec quel contexte.
- Reprise après erreur. Quand une action échoue au milieu d'une opération multi-étapes, c'est quoi le rollback, c'est quoi le retry, c'est quoi l'arrêt sécuritaire.
Sans harness, l'agent est un prototype. Il fonctionne en démo, puis il fantôme une facture, double-facture un client, ou envoie un PDF confidentiel au mauvais destinataire. Avec un harness, l'agent est une opération. Il est auditable, récupérable, gouvernable.
La plupart des échecs d'agents en production en entreprise se ramènent à une composante manquante du harness. Ce n'est presque jamais le modèle qui échoue. C'est l'absence d'infrastructure autour.
5. Structurer ses agents par discipline
La tentation, en démarrant avec des agents, c'est de bâtir un seul généraliste qui fait tout. Résistez.
Un agent généraliste unique qui touche à chaque partie de l'entreprise est, en pratique, un agent fiable nulle part. Il n'a pas de propriétaire clair, pas de périmètre clair, pas de mode de défaillance clair. Quand ça casse, personne ne sait à qui appartient le problème.
La stack d'agents qui survit calque la structure d'une organisation moderne, pas celle d'un monolithe logiciel.
Exemples de découpage par discipline :
- Agent finance — parle aux livres comptables, à la prévision de trésorerie, aux outils de réconciliation. Propriétaire : le contrôleur.
- Agent service client — parle à Gorgias, au CRM, au système de gestion des commandes. Propriétaire : le responsable de l'expérience client.
- Agent acquisition — parle à Meta Ads, Google Ads, Klaviyo, à l'entrepôt analytique. Propriétaire : le responsable de la croissance.
- Agent produit — parle à Shopify, au PIM, aux outils de gestion de catalogue. Propriétaire : le responsable du merchandising.
- Agent logistique — parle à ShipStation, aux APIs du 3PL, au système de gestion d'entrepôt. Propriétaire : le responsable des opérations.
Chaque agent a son périmètre, ses outils, ses limites, son propriétaire humain. La discipline est la clé. Chaque agent a quelqu'un dont le travail dépend de son bon fonctionnement. Chaque agent a une surface définie où il opère et une surface définie où il doit escalader.
Cette structure rend aussi les agents composables. L'agent service client et l'agent logistique peuvent collaborer sur un cas de litige de livraison sans fusionner en un seul gros blob. Chacun apporte sa spécialisation. L'orchestrateur route le cas.
6. Le SaaS legacy a un chemin de transition naturel
Le catalogue SaaS existant ne meurt pas. Il mue.
Le chemin de transition est constant à travers les catégories et se fait en trois étapes :
- Exposer des APIs propres, complètes et bien documentées. Ça a l'air basique. Ça ne l'est pas. La plupart des APIs SaaS aujourd'hui sont partielles — elles couvrent le 60 % facile de la plateforme et verrouillent le reste derrière l'UI. Agentic first veut dire que la surface API doit être complète. Chaque workflow qu'un utilisateur peut rouler dans l'UI, un agent doit pouvoir le rouler via l'API.
- Offrir une couche MCP ou équivalent pour que les agents puissent consommer la plateforme nativement. MCP (Model Context Protocol) est en train de devenir le standard de facto pour permettre aux agents de découvrir et d'utiliser des outils externes. Les éditeurs qui livrent un serveur MCP maintenant signalent au marché qu'ils comprennent où la consommation s'en va. Les éditeurs qui ne le font pas signalent l'inverse.
- Repenser l'UI comme un centre de supervision plutôt qu'un centre d'exécution. Une fois les couches API et MCP en place, le rôle de l'UI change. Elle cesse d'être le lieu où le travail se fait et devient le lieu où le travail se révise. C'est un vrai redesign produit, pas une couche de peinture.
Les éditeurs qui complètent cette transition restent indispensables et deviennent souvent plus précieux, pas moins. Ils deviennent la source canonique de vérité pour leur domaine, consommée par chaque agent qui doit opérer dans ce domaine.
Les éditeurs qui résistent à cette transition deviennent des dépendances invisibles — encapsulés, abstraits et finalement remplacés. Certains disparaîtront. D'autres traîneront comme des commodités à faible marge derrière des couches d'orchestration.
La fenêtre pour faire le virage est étroite. Les éditeurs qui bougent maintenant définissent les standards que le reste du marché sera obligé de respecter.
7. Le vrai chantier : changer de mentalité
Penser agent first, ce n'est pas brancher un chatbot sur son produit. C'est une question de design différente pour chaque fonctionnalité.
La discipline, c'est de se demander, pour chaque fonctionnalité de la roadmap : « est-ce qu'un agent devrait pouvoir faire ça sans qu'un humain clique ? »
- Si oui, l'API et le harness passent avant l'écran. L'écran est une surface de supervision, designée après que l'opération soit solide.
- Si non, on documente pourquoi. Parfois la réponse est réglementaire (une signature humaine est légalement requise). Parfois la réponse est basée sur le risque (l'action est irréversible et la confiance de l'agent n'est pas là). Parfois la réponse est vraiment liée au jugement humain (décisions créatives, ton de marque, escalades sensibles relationnellement). Quelle que soit la raison, écrivez-la. Les raisons qui ne survivent pas à un examen sérieux sont celles qui drainent silencieusement votre roadmap.
Cette discipline change tout en aval : la roadmap, le profil de recrutement, la stack technique, la façon de vendre, la façon de mesurer la valeur livrée. L'équipe qu'il faut pour livrer agent first n'est pas la même que celle qu'il fallait pour livrer UI first. Les métriques non plus.
Les entreprises qui font ce virage tôt ne bâtissent pas du « meilleur SaaS ». Elles bâtissent la prochaine couche d'infrastructure opérationnelle.
Conclusion
L'agentique ne remplace pas le SaaS. Elle le réordonne.
L'UI devient un rapport. L'API devient le produit. L'agent devient l'interface.
Ceux qui construisent encore à l'envers ne perdront pas demain. Ils perdent déjà aujourd'hui, simplement plus lentement. Chaque release qui sort comme un écran bien fini pour un utilisateur humain est une release qui consolide la position d'un paradigme qui s'en va.
La bonne nouvelle, c'est que le chemin est clair. Complétez les APIs. Livrez une couche MCP. Redesignez l'UI comme supervision. Structurez vos agents par discipline. Bâtissez le harness. Changez la question que votre équipe produit se pose avant de designer quoi que ce soit.
Chez HUBBVEE, nous accompagnons des entreprises canadiennes — qu'elles bâtissent du SaaS ou qu'elles opèrent une entreprise par-dessus des dizaines de SaaS — à faire ce virage méthodiquement. On cartographie l'écart entre la configuration actuelle et la cible agent first, on priorise les composantes qui débloquent le plus de valeur en premier, et on livre en petits incréments vérifiables. La méthodologie, c'est Voir, Trier, Agir — appliquée au virage agentique, ça veut dire voir ce que la stack actuelle coûte silencieusement, trier où les agents créent du levier, et agir sur l'agent à plus fort impact en premier.
Vous voulez évaluer le niveau de maturité agent first de votre produit ou de votre opération ? HUBBVEE fait un audit stratégique de 4 heures qui cartographie vos écarts d'API et de harness, identifie les frontières d'agents qui correspondent à votre organisation, et termine avec un plan de transition séquencé. Écrivez-moi.