Construire l’expérience « Manager » de Notis (et la refonte qui se cache dessous)

Je réfléchis beaucoup à ce que devrait vraiment donner « utiliser des agents » au quotidien. Pas une démo de science-fiction, pas un bac à sable de prompts, mais une expérience de Manager : un centre de contrôle où tu lances des agents aussi vite que tu envoies un email, où tu fais venir le bon contexte avec des @-mentions, et où tu bascules n’importe quel chat en mode vocal instantanément.

Cette direction nous oblige à reconstruire des parties de Notis de l’intérieur. L’UX, c’est la partie visible, mais la vraie histoire, c’est la refonte en dessous : celle qui rend l’ensemble fiable sur tous les canaux, sécurisé par défaut et rapide à étendre.

Le centre de contrôle « Manager » : de la vitesse et du contexte, pas du cérémonial

L’étoile polaire est simple : je veux que Notis donne l’impression d’un cockpit. Tu ne devrais pas avoir à « configurer l’IA » à chaque fois. Le rôle du produit, c’est d’assembler le contexte vite, d’exécuter les actions en toute sécurité et de te faire avancer sans cérémonial.

Concrètement, ça veut dire que tu peux créer un agent à la volée, apporter du contexte en quelques secondes grâce aux @-mentions (automatisations, Skills, fichiers), garder la même expérience que tu sois sur le portail, sur Desktop ou dans tes canaux de messagerie, et passer à la voix sans changer d’outil ni de workflow.

La refonte : une seule API Python, fini les endpoints éparpillés et les secrets dans l’app Desktop

Pour que cette expérience devienne réelle, le backend devait arrêter de se comporter comme une collection de morceaux qui « marchent ». Nous avons regroupé le backend dans une seule API Python. Ça a supprimé les endpoints serveur éparpillés et réglé au passage un gros signal d’alerte côté sécurité : éviter d’embarquer des secrets dans l’app Desktop Electron.

Si on veut des agents vraiment opérationnels, qui touchent à l’email, aux agendas, aux CRM et aux outils internes, les fondations doivent traiter les identifiants et les frontières d’authentification comme des contraintes de conception de premier ordre, pas comme des détails réglés après coup. Ce regroupement n’a rien de glamour, mais c’est lui qui nous permet d’aller vite sans tout casser à chaque nouvelle capacité.

Exécution des outils : tout passe par un seul proxy MCP unifié

Le deuxième grand changement concerne la façon dont les outils s’exécutent. Au lieu de laisser les agents appeler les outils directement, ou de faire transiter les appels d’outils par des événements websocket, nous avons repensé l’exécution pour que toutes les actions passent par un seul proxy MCP unifié.

Ce proxy expose trois familles d’outils de façon cohérente : les outils Notis intégrés, les serveurs MCP personnalisés connectés par l’utilisateur et les outils Composio. Le proxy gère l’authentification et garantit la parité entre dev et prod, et entre les canaux (portail, WhatsApp, et d’autres). L’objectif, c’est une fiabilité ennuyeuse : une seule couche d’action, un seul modèle mental et un seul endroit pour appliquer les permissions et la journalisation.

Skills et automatisations : un cadre repensé (et simplifié)

Cette refonte nous impose aussi un modèle plus clair de ce qu’on construit. Aujourd’hui, je vois les automatisations comme des paquets d’instructions déclenchables, injectés au niveau de l’orchestrateur (webhooks, plannings, lancements manuels). Les Skills, eux, sont des capacités chargeables dynamiquement par les sous-agents, souvent associées à des scripts pour le travail déterministe, comme l’analyse ou la transformation de PDF et de DOCX.

À mesure qu’on avance vers un centre de contrôle façon Manager, les Skills commencent à ressembler à la brique la plus fondamentale. Dans ce monde-là, une automatisation, c’est en fait un Skill plus un déclencheur. Ce n’est pas qu’une question de sémantique, c’est une simplification produit. Ça nous permet de concevoir un seul objet central et de décider ensuite comment il s’exécute, au lieu de maintenir deux systèmes parallèles qui se chevauchent sans jamais vraiment s’aligner.

La stratégie d’ensemble : un Workspace agentique qui génère interfaces, bases de données et templates

C’est là que ça devient excitant. La vision à plus long terme, c’est Notis comme Workspace agentique capable de générer de l’interface, des bases de données et des templates, pour que les utilisateurs puissent construire et distribuer leurs propres « Apps » dans Notis : par exemple des workflows de comptabilité ou de facturation, d’habitude pénibles à assembler.

Sur le plan stratégique, je ne prétends pas qu’on crée tout le marché. OpenAI et Anthropic l’élargissent massivement. L’idée, c’est de surfer sur cette vague avec la bonne couche d’abstraction : un Workspace où les agents peuvent vraiment opérer, où les outils se combinent, et où les utilisateurs finaux peuvent emballer des résultats concrets dans des systèmes réutilisables. C’est ce que j’entends par « expérience de Manager ». Il ne s’agit pas de parler à une IA. Il s’agit de faire tourner le travail.