Donner un vrai ordinateur à un assistant IA : comment Notis tourne sur Vercel

La plupart des assistants IA savent parler d’un tableur. Très peu savent en ouvrir un, lancer un script dessus et te rendre le résultat.

Cet écart, c’est toute la raison pour laquelle Notis a un Cloud Computer. Et si le Cloud Computer existe, c’est grâce à Vercel, plus précisément Vercel Sandbox, qui donne à chaque utilisateur de Notis une vraie machine Linux que l’assistant peut piloter pour lui.

Voici comment tout ça s’articule concrètement, et ce que j’ai appris en le câblant.

Deux rôles différents, deux briques Vercel différentes

Quand les gens entendent « on est sur Vercel », ils supposent que tout le produit est une app Next.js. Pas le nôtre. Notis a un backend Python/FastAPI qui porte la logique métier, la boucle de l’agent, les canaux et la distribution des outils. Cette partie ne tourne pas sur Vercel.

Ce qui tourne sur Vercel, c’est le Portal : l’app web Next.js sur laquelle les gens se connectent, à app.notis.ai. C’est la surface où tu relis tes documents, gères tes automatisations, connectes tes intégrations et regardes un agent travailler. Elle colle bien au modèle de déploiement de Vercel : des builds de preview sur chaque branche, des rollbacks instantanés, aucun serveur à surveiller.

La deuxième brique est la plus intéressante. Vercel Sandbox est un produit distinct qui lance des environnements Linux de courte durée via une API. On l’utilise comme socle d’exécution de ce que les utilisateurs voient comme le Cloud Computer.

Ce que « Cloud Computer » veut dire en pratique

Quand quelqu’un demande à Notis d’extraire une série de pages dans un tableur, de convertir un dossier de PDF, de lancer un script Python ponctuel ou de confier une tâche de code à Claude Code, l’assistant ne simule rien de tout ça. Il provisionne une sandbox et y fait le travail.

Notre passerelle vers Vercel Sandbox couvre les opérations qu’on attend d’une machine qu’on possède vraiment :

• créer et reprendre une session
• exécuter des commandes et renvoyer leur sortie en continu dans la conversation
• lire, écrire et déplacer des fichiers
• prendre et restaurer des snapshots
• associer un domaine pour qu’un serveur de dev soit accessible dans un navigateur
• arrêter et supprimer l’environnement

C’est la partie snapshots qui donne l’impression d’avoir ton ordinateur plutôt qu’un conteneur jetable. Un snapshot de base est construit à l’avance avec les runtimes et les CLI dont on s’attend à ce que les gens aient besoin, pour qu’une session ne passe pas ses deux premières minutes à installer Node. On fait le ménage dans les anciens snapshots selon un planning, parce que leur prolifération a un vrai coût et que personne ne le remarque avant l’arrivée de la facture.

Les parties dont personne ne te parle

Trois choses m’ont pris plus de temps que le cas nominal.

Les délais. Une commande en sandbox a un délai imposé par le fournisseur. La commande d’un agent, non. Si un utilisateur demande quelque chose qui prend onze minutes et que le timeout du segment est plus court, tu n’obtiens pas une erreur propre : tu obtiens un travail à moitié fait et un assistant perdu. On a fini par modéliser explicitement les timeouts de segment, pour que l’agent sache de combien de marge dispose une commande avant de démarrer, et qu’il puisse découper le travail au lieu de mourir en plein vol.

Les caches partagés entre sessions. Les caches de paquets font la différence entre un démarrage en deux secondes et un démarrage en deux minutes. Mais si une passe de maintenance supprime un cache pendant qu’une autre commande est en plein téléchargement, tu obtiens une corruption qui ressemble à un bug réseau. On a mis un flock borné autour : les commandes ordinaires font la queue derrière une passe de maintenance exclusive, et si elles attendent trop longtemps, elles s’exécutent sans verrou au lieu de griller le délai du fournisseur. Dans le pire des cas, une commande retélécharge un cache. C’est un pire cas tout à fait acceptable.

Les IP sortantes. Celle-là m’a surpris. Plusieurs services avec lesquels Notis communique, dont OpenAI et Composio, filtrent les IP sortantes par liste d’autorisation. Les sandboxes n’en ont pas de stables. Le trafic des sandboxes qui a besoin d’une adresse autorisée passe donc par un petit relais qu’on héberge ailleurs, avec une liste explicite d’hôtes de destination. Tout le reste passe en direct. C’est le genre de plomberie invisible quand elle fonctionne, et totalement déroutante quand elle ne fonctionne pas.

Pourquoi une sandbox plutôt qu’un conteneur qu’on gère nous-mêmes

J’ai déjà construit la version « on fait juste tourner Docker quelque part ». Ce n’est pas dur à démarrer. C’est dur à maintenir.

Tu finis par devoir gérer les builds d’images, les pools de machines préchauffées, l’isolation par utilisateur, la saturation des disques, le nettoyage des processus zombies et un ordonnanceur. Rien de tout ça, ce n’est Notis. Rien de tout ça n’est la raison pour laquelle on nous paie. Vercel Sandbox nous donne une API où la frontière d’isolation est le problème de l’éditeur, et où notre problème, c’est le comportement de l’agent à l’intérieur.

Le compromis, en toute honnêteté : tu hérites des limites de l’éditeur. Les délais, les plafonds de ressources et le comportement du pare-feu en bordure sont les siens, pas les tiens. On consacre de vrais efforts à détecter ces cas et à les transformer en quelque chose sur quoi un agent peut raisonner, plutôt qu’en stack trace qu’un utilisateur doit lire. C’est la taxe. Je la paierais de nouveau.

Ce que ça débloque pour la personne qui écrit à l’assistant

Voici la partie qui compte en dehors de l’ingénierie.

Comme le Cloud Computer est une vraie machine, Notis peut confier une tâche à un agent de code et le laisser travailler vingt minutes pendant que tu fais autre chose. Il peut installer une CLI dont il a besoin en cours de tâche. Il peut démarrer un serveur de dev, obtenir une URL publique, l’ouvrir dans un navigateur, faire une capture d’écran et te dire si le changement a vraiment fonctionné. Il peut garder un répertoire de travail d’un message à l’autre, pour que « continue là-dessus » veuille dire quelque chose.

C’est un produit différent d’un assistant qui ne sait que composer du texte. Et ce n’est possible que parce que quelqu’un d’autre fait tourner les machines.

Si tu construis quelque chose de similaire

Quelques conseils que je donnerais à mon moi du passé :

1. Décide tôt de ce qui est sans état et de ce qui ne l’est pas. Notre Portal vit très bien sans état sur Vercel. La sandbox, elle, a un état, volontairement. Mélanger ces hypothèses fait mal.
2. Modélise le délai dans ton agent, pas seulement dans ton client. Un agent qui sait qu’il a quatre minutes ne se comporte pas comme un agent qui le découvre après coup.
3. Fais un snapshot de ton environnement de base, puis fais le ménage. Les deux moitiés. C’est la seconde que les gens oublient.
4. Pars du principe que ta sandbox n’a pas d’identité stable sur Internet. Anticipe les listes d’autorisation avant qu’un fournisseur ne te rejette en production.

Notis est un produit mené par son fondateur. On continue d’élargir la capture vocale vers Notion à des workflows sur outils connectés, et le Cloud Computer est la brique qui a transformé « un assistant qui prend des notes » en « un assistant qui termine le travail ». Vercel fait tourner les machines en dessous.

Si tu veux voir ce que ça donne, essaie Notis et demande-lui de te construire quelque chose.