Operit AI : un agent Android qui exécute des tâches, pas seulement des réponses
The most powerful AI agent and AI chat software on Android/Operit是一款Android上能力最为强大、发展最久的AI Agent
En bref
- De quoi s’agit-il ?
- Operit AI est un agent open source pour Android 8.0+ (ARM64) publié sous LGPL-3.0. Il relie un modèle de langage au système, à un terminal Ubuntu, à un navigateur et à un espace de travail de projet, avec des permissions à trois niveaux.
- À qui s’adresse-t-il ?
- Operit AI convient aux développeurs Android et aux utilisateurs avancés qui veulent un agent capable d'agir sur l'appareil et qui acceptent de gérer eux-mêmes les permissions, les canaux de mise à jour et la conformité LGPL-3.0. Ceux qui cherchent un assistant de chat léger, ou qui ne peuvent pas installer d'APK hors Play Store, doivent passer leur chemin.
- Puis-je l’utiliser commercialement ?
- Oui, sous conditions. LGPL-3.0 est une licence à copyleft faible : vous pouvez l’intégrer à un logiciel commercial ou propriétaire, mais si vous distribuez des modifications de ses propres fichiers, vous devez les publier sous la même licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 1 jour.
- En quel langage est-il écrit ?
- Principalement Kotlin, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : un assistant mobile qui ne peut rien faire sur l'appareil
La plupart des applications de chat sur Android s'arrêtent à la génération de texte. Operit AI prend le problème par l'autre bout : le README décrit une plateforme où le modèle est connecté au système Android, au terminal, au navigateur, aux fichiers et à un espace de travail de projet, avec exécution d'outils et workflows. La cible est donc l'utilisateur qui a besoin de faire aboutir une tâche (chercher une information, traiter un fichier, modifier du code, automatiser une interface) et non d'obtenir un paragraphe de réponse. Le projet est publié sous LGPL-3.0, en Kotlin, avec une application Android comme livrable principal. Le README annonce aussi une suite distincte, Operit 2, présentée comme une seconde génération indépendante avec un runtime partagé en Rust et un client Flutter : autrement dit, le dépôt Android n'est pas la seule trajectoire du projet, et il faut le savoir avant de s'engager sur le code.
Architecture : le modèle au centre, mais pas aux commandes
Le mécanisme visible dans le README est celui d'un agent à appels d'outils. Le modèle ne modifie pas directement l'appareil : il passe par des outils (fichiers, réseau, recherche, médias, système, gestion logicielle, développement) dont l'exécution est soumise à un réglage de permission à trois niveaux, à savoir autorisation automatique, demande à chaque appel, ou interdiction. Le mode par défaut est la demande. C'est une décision de conception qui a un coût : chaque action sensible interrompt le flux, ce qui protège l'utilisateur mais dégrade l'automatisation complète. Les canaux d'automatisation d'interface sont eux aussi différenciés : accessibilité, Shizuku pour un niveau de débogage ADB, ou Root. La mémoire est décrite comme un graphe, avec plusieurs espaces, import de documents, découpage en blocs, édition des relations entre nœuds et recherche hybride. Le terminal repose sur un espace utilisateur Ubuntu 24.04 ARM64 lancé par PRoot par défaut, avec chroot possible sous conditions. Enfin, les extensions se répartissent entre ToolPkg, MCP et Skill, ce qui donne trois formats à connaître plutôt qu'un seul.
Installation : un APK, des permissions, et un choix de modèle
L'installation ne passe pas par un dépôt de paquets. Le README indique de télécharger l'APK depuis la page Releases ou depuis operit.app, puis d'installer, lancer, et suivre l'assistant de configuration du modèle et des permissions. La condition matérielle est explicite : Android 8.0 (API 26) minimum et uniquement arm64-v8a. Les besoins en mémoire et en stockage dépendent de l'environnement terminal, des outils installés et des modèles locaux ; le README invite à consulter la fiche du modèle avant de le télécharger. Côté modèles, le projet accepte des services cloud compatibles OpenAI Chat et Responses, Anthropic, Gemini, des points de terminaison personnalisés, ainsi que l'inférence locale via MNN ou llama.cpp avec des fichiers GGUF, et des serveurs locaux comme Ollama ou LM Studio. Une même installation peut donc combiner plusieurs fournisseurs, avec des configurations distinctes pour le chat, la mémoire, le résumé et le contrôle d'interface. Le README précise que les données de chat, de rôle, de mémoire et de configuration restent locales, et que les requêtes vers un modèle cloud partent de l'appareil vers le fournisseur choisi.
Le terminal Ubuntu embarqué : ce qu'il implique vraiment
C'est la partie qui distingue Operit AI d'un client de chat. Le README annonce un espace utilisateur Ubuntu 24.04 ARM64, exécuté par PRoot par défaut, avec chroot lorsque les conditions le permettent, plus SSH et SFTP, tmux, vim, Python et Node.js, et des sources logicielles configurables. L'intérêt est concret : un projet peut être ouvert dans l'espace de travail, lié à une conversation, et modifié par l'agent qui lit les règles du projet et référence des fichiers. Le coût l'est tout autant. PRoot n'est pas un noyau Linux ; c'est une couche d'émulation d'appels système, et le README ne promet nulle part des performances natives. Le stockage consommé par l'espace utilisateur et les paquets s'ajoute à celui de l'application, et la gestion des sources logicielles devient une responsabilité de l'utilisateur. Pour un dépannage ponctuel sur un serveur distant, cet environnement est disproportionné : SSH depuis un client dédié sera plus simple et plus fiable.
Limites et cas où Operit AI n'est pas le bon outil
La contrainte la plus dure est matérielle : ARM64 uniquement. Un appareil x86 ou un émulateur classique n'est pas couvert par le README. Ensuite, l'automatisation d'interface dépend de permissions qui ne sont pas accordées par défaut : sans Shizuku ni Root, le canal accessibilité reste la seule voie, et le README indique que la vision par écran et l'affichage virtuel exigent des permissions et un matériel compatibles. Les fonctions de marché, MCP, Skill, voix et génération d'images peuvent contacter des services tiers, ce qui déplace une partie du traitement hors de l'appareil. Le Web Chat et l'HTTP API en réseau local sont désactivés par défaut et nécessitent un Bearer Token à l'activation : les exposer sans ce jeton est un risque d'accès, pas une fonctionnalité. Enfin, la distribution hors magasin officiel crée une charge de vérification : le README avertit explicitement que les paquets provenant de canaux inconnus peuvent être modifiés. Un utilisateur qui ne veut pas gérer ces trois sujets (permissions, exposition réseau, intégrité du binaire) sera plus à l'aise avec un assistant Android classique, même moins capable.
Face à un simple client de chat : la différence est le canal d'action
La comparaison pertinente n'est pas entre deux interfaces de conversation, mais entre deux façons d'appeler un modèle. Un client de chat classique transmet un texte et affiche une réponse : il n'a pas de canal pour écrire un fichier, lancer une commande ou cliquer dans une autre application. Operit AI ajoute précisément cette couche, avec ses outils, ses permissions et son journal d'exécution. Le revers est visible dans le README : la surface à configurer est bien plus large (fournisseurs, clés, espaces mémoire, canaux d'automatisation, sources logicielles). Un utilisateur qui veut seulement interroger un modèle local via Ollama n'a rien à gagner à installer un espace Ubuntu et un système de permissions à trois niveaux. La bonne question n'est donc pas de savoir lequel est le plus complet, mais si la tâche visée nécessite réellement une action sur l'appareil. Si la réponse est non, la complexité d'Operit AI devient un coût sans contrepartie.
Maintenance, mises à jour et implications de la LGPL-3.0
Le rythme de publication est documenté : v1.11.0 le 16 mai 2026, v1.12.0 le 1er juillet 2026, v1.12.1 le 8 août 2026, avec un dernier push sur main au 9 septembre 2026. Le projet n'est pas archivé. Cela implique une mise à jour manuelle de l'APK, puisque la distribution se fait par Releases, et une vérification de provenance à chaque fois. Le README signale aussi une évolution notable : Operit 2 est présenté comme une seconde génération indépendante, avec un runtime partagé en Rust, un client Flutter et un CLI/TUI operit2. Autrement dit, investir dans des extensions propres à la version Android n'offre aucune garantie de portage vers cette seconde implémentation. Sur le plan juridique, la licence est LGPL-3.0 : elle autorise la redistribution et la modification sous conditions, notamment de conserver les mentions de licence et, pour les œuvres dérivées, de fournir le code source correspondant. Si Operit AI est intégré dans un produit distribué, ces obligations doivent être examinées avec un juriste ; ce paragraphe n'est pas un avis juridique. Le point pratique à retenir est qu'un fork modifié devra assumer la publication de ses sources.
Conclusion éditoriale
Operit AI convient aux développeurs Android et aux utilisateurs avancés qui veulent un agent capable d'agir sur l'appareil et qui acceptent de gérer eux-mêmes les permissions, les canaux de mise à jour et la conformité LGPL-3.0. Ceux qui cherchent un assistant de chat léger, ou qui ne peuvent pas installer d'APK hors Play Store, doivent passer leur chemin. Avant de l'adopter, vérifiez trois points précis : le SHA du binaire depuis la page Releases, le réglage de permission des outils, et si le mode Web Chat ou HTTP API est activé, la présence du Bearer Token et l'exposition réseau correspondante.
Notes de la communauté