Inari passe en MIT, sur un cœur à nous

Inari a commencé comme une couche de peinture sur l'excellente appli de quelqu'un d'autre. Aujourd'hui c'est un cœur, une interface web et un client Android à nous, écrits pour la façon dont on travaille vraiment, et tout le dépôt est en MIT. Voici ce qu'on a emprunté, pourquoi c'est bien, et pourquoi on a arrêté d'emprunter.

Ce que vous y gagnez. Le code du nouvel Inari, une image honnête de ce qui le distingue de Cloudroom (à quoi sert chacun), et les raisons de notre choix, pour savoir lequel vous convient.

Ce qu'on utilisait : Cloudroom

Cloudroom, de David Ondrej, est une appli de bureau pour Claude Code, Codex et Pi. Vos agents tournent sur votre Mac ou dans le cloud, sur vos propres abonnements. Son interface est en Apache-2.0, son cœur peut être auto-hébergé, et l'usage local ne demande aucun compte. Pendant quelques semaines on l'a fait tourner ainsi, repeint à nos couleurs, avec notre signature kitsune et notre nom. On n'a jamais forké son moteur : un petit outil patchait chaque version amont sur place. C'était le premier Inari.

Pourquoi il est génial

• La téléportation. Déplacer un fil en cours d'exécution de votre Mac vers le cloud, et retour, avec la même discussion, le même modèle et le même effort.
• Un ordinateur cloud par fil, avec sa propre branche Git, et un curseur pour ce qu'un agent cloud peut faire sur votre Mac : rien, lecture seule, demander d'abord, ou tout.
• Plusieurs comptes Claude et Codex, qu'on change en un clic, et le « computer use » : des agents qui voient et pilotent des applications du bureau.
• Le rythme et le soin. Plus de cinquante versions en moins de quatre semaines, signées et notarisées, avec une appli mobile.

Il est fait pour des gens aux besoins structurants : plusieurs abonnements frontier, du travail qui doit tourner dans le cloud, une équipe. C'est un vrai problème, et il est bien résolu. Ce n'est pas tout à fait le nôtre.

Ce dont on avait besoin

• Nos machines, pas le cloud d'un éditeur. Un portable, une machine à GPU, un petit serveur, autant qu'on veut, qui coopèrent.
• Un coût maîtrisé. Des modèles locaux gratuits, les offres gratuites quand elles existent, un abonnement frontier seulement quand la tâche le mérite. Un seul endroit qui mutualise tous nos accès.
• Une famille. Un enfant qui utilise l'IA sur le cœur familial pendant qu'un parent suit chaque fil, et un ami qui continue un fil sur sa propre machine.
• Rien à ouvrir comme compte, rien qui appelle chez nous, et un état d'agent qui est un fichier qu'on peut lire.
• Petit. Un binaire statique d'environ 6 Mo par machine, une dizaine de mégaoctets de mémoire au repos.

Ce que fait Inari maintenant

• Déplacer un fil en le glissant sur une autre machine : la conversation, les fichiers et l'état voyagent ensemble, en deux phases et avec retour arrière.
• Tous les agents par un seul protocole. Claude Code, Gemini CLI et OpenFox parlent tous l'Agent Client Protocol : un fil peut changer de modèle, de mode ou d'agent sans perdre son historique. La page montre les modes propres à chaque agent (plan, accepter les modifications, build…) et ses commandes slash.
• Les autorisations dans la conversation. Quand un agent demande à lancer quelque chose, une carte apparaît dans son fil : refuser, autoriser une fois, ou toujours autoriser ici. Le mode auto laisse un fil agir sans demander, et chaque action reste journalisée. Stop interrompt un agent immédiatement.
• Les passes de cœur. Une passe de collaboration partage des fils avec un ami ; une passe de supervision laisse un parent suivre les fils d'un enfant et répondre aux demandes des agents, et l'enfant voit toujours qu'il en est ainsi.

Le client Android est une appli fine : il ouvre l'interface d'un cœur derrière l'empreinte du téléphone, garde l'identifiant de votre portail dans le Keystore Android, et reçoit ce que d'autres applis partagent (une photo, un document, un lien) directement dans la zone de message. L'adresse de votre cœur et le lieu de publication des mises à jour sont des réglages de build, jamais dans le code source.

Là où Cloudroom reste devant

On ne cherche pas à l'égaler sur l'ordinateur cloud par fil, sur le computer use, ni sur une appli de bureau signée pour macOS. Si c'est ce qu'il vous faut, utilisez Cloudroom : il est excellent, et les idées qu'on a gardées (téléporter un agent en cours, changer de modèle en cours de fil) sont les siennes.

Le dépôt, et la licence

Le nouveau dépôt est github.com/bengua/inari, en MIT, et il est aussi développé sur notre forge. Il contient le cœur en Rust, l'interface web, le client Android et la documentation. Le premier Inari, et le fork de l'interface de Cloudroom sur lequel il tournait, sont archivés sous inari-v1 et inari-gui, gardés pour mémoire. Aucun code de Cloudroom n'est dans le nouveau, et on le dit pour être clair sur ce qui est à nous.

L'essayer

git clone https://github.com/bengua/inari.git
cd inari
cargo build --release          # un binaire : target/release/inari-core-rs
# écrire un node.json (docs/node.md liste toutes les options), puis :
target/release/inari-core-rs node node.json

Ouvrez l'adresse de la passerelle que vous avez configurée. Ajoutez les agents installés sur cette machine aux harnesses du fichier, et rattachez une deuxième machine à la première avec inari-core-rs join. Pour le téléphone, android/build.sh compile l'appli dans un conteneur ; indiquez-lui votre cœur avec un fichier build.env (voir android/README.md).

Inari n'a pas de connexion par conception. Liez sa passerelle à la boucle locale et atteignez-la depuis vos autres machines par un réseau privé (Tailscale, WireGuard, un tunnel SSH), derrière un reverse proxy qui demande un identifiant si vous le voulez. Le transport des cœurs authentifie mais ne chiffre pas : gardez-le sur ce réseau privé.

Sources : Inari (MIT), Cloudroom GUI (Apache-2.0), Agent Client Protocol. Merci à David Ondrej pour Cloudroom, sur lequel ce projet a tourné et dont il a appris.

Utile ? Dites-nous ce qu'il faut mesurer ensuite.