OpenDAN : un AIOS personnel qui tient dans un conteneur Docker

Le problème visé : faire cohabiter des modules IA sur une seule machine

Le README résume l'ambition en une phrase : OpenDAN consolide divers modules IA au même endroit pour un usage personnel. Concrètement, le projet ne vend pas un modèle ni un service cloud, mais une couche d'organisation. Il faut y voir une tentative de réponse à un problème d'assemblage : un assistant conversationnel, un moteur de recherche dans ses propres fichiers, un correcteur linguistique et un outil de génération de contenu audio n'ont ni la même interface ni le même mode de stockage. OpenDAN propose de les traiter comme des agents nommés, chacun avec un rôle, et de les faire dialoguer dans un shell unique.

Le public visé n'est pas l'utilisateur final. Le README décrit deux modes d'installation : Docker, présenté comme la méthode recommandée, et les sources, jugées nécessaires uniquement pour faire du développement secondaire. Cette séparation est un aveu. Le projet s'adresse d'abord à des personnes capables de lire un Dockerfile et de diagnostiquer une dépendance Python cassée. Les agents intégrés cités dans la version 0.5.1 (Jarvis pour l'agenda, Mia pour les données personnelles, Tracy pour l'anglais, ai_bash pour la ligne de commande) sont des démonstrations de faisabilité, pas des produits finis.

Une architecture d'agents nommés, pas un noyau finalisé

La partie la plus intéressante du dépôt est aussi la plus instable. Le README annonce que la version 0.5.1 fonctionne en mode all-in-one, autrement dit que tout tourne dans un seul processus ou un seul conteneur. Le noyau formel du système d'exploitation, lui, est repoussé : la version 0.5.2 doit s'appuyer sur une partie du code de l'OS CYFS Owner Online Device (OOD), hébergé dans un dépôt distinct (buckyos/CYFS). Autrement dit, ce que vous installez aujourd'hui n'est pas l'architecture cible, mais une étape intermédiaire.

Les concepts visibles dans le matériel fourni sont les suivants. Un agent est décrit comme piloté par un grand modèle de langage. Un workflow permet à plusieurs agents de collaborer ; le README cite story_maker, qui assemble un outil AIGC pour produire des livres audio pour enfants. La base de connaissances locale est alimentée par des spiders qui parcourent des fichiers ou des courriels. Les canaux d'accès mentionnés sont Telegram et le courriel. Le shell AIOS sert d'interface : l'utilisateur voit avec quel agent il parle et sur quel sujet, ce qui suggère une notion de session et de contexte par agent.

Ce qui manque dans le matériel fourni est tout aussi parlant. Aucun schéma de communication entre agents n'est décrit, aucune API n'est documentée, et le format d'un fichier d'agent n'est pas montré. Le README renvoie vers une issue GitHub (le numéro 46) pour les développeurs qui veulent suivre l'évolution du système. C'est une façon polie de dire que la documentation d'architecture vit dans les discussions, pas dans le dépôt.

Installation : deux commandes Docker et une clé API

Le chemin le plus court documenté tient en trois étapes. D'abord vérifier Docker, avec `docker -version`, le README précisant qu'une version supérieure à 20.0 est attendue. Ensuite récupérer l'image :

docker pull paios/aios:latest

Puis lancer le conteneur, en gardant le drapeau -it pour la première exécution, car l'initialisation demande des informations :

docker run -v /your/local/myai/:/root/myai --name aios -it paios/aios:latest

Le montage de volume n'est pas cosmétique. Le README insiste sur le fait qu'OpenDAN génère des données personnelles pendant son fonctionnement (historique de conversation avec les agents, données d'agenda) et que ces données résident sur le disque local. Sans le montage vers /root/myai, elles restent enfermées dans le conteneur. Les exécutions suivantes se font avec `docker start -ai aios`, et le drapeau -ai peut être omis pour un démarrage en mode service sans interface.

Un point mérite d'être signalé : la clé API OpenAI est présentée comme un prérequis de préparation, avec un renvoi vers beta.openai.com. Le README ajoute que l'obtention d'un jeton peut représenter un obstacle pour les nouveaux venus et suggère de rejoindre un groupe d'essai pour en obtenir un temporaire. Cette dépendance à un service tiers pour la configuration initiale est un choix de conception, pas un détail d'installation.

Le modèle local LLaMa comme soupape, et ses conditions

Le README liste parmi les nouveautés de la 0.5.1 la possibilité de changer le grand modèle de langage utilisé par un agent, avec le support d'un modèle open source exécuté localement (LLaMa). C'est le point qui donne au projet sa cohérence : si l'objectif est de garder le contrôle de ses données personnelles, envoyer chaque conversation à une API distante affaiblit l'argument. Le montage d'un disque local et l'exécution d'un modèle sur sa propre machine vont dans le même sens.

Le matériel fourni ne dit rien des ressources nécessaires. Aucune indication de VRAM, de taille de quantification, de latence ni de matériel minimal n'apparaît. Le README mentionne seulement que Docker rend OpenDAN compatible avec un large éventail d'environnements (PC, Mac, Raspberry Pi, NAS), ce qui est une affirmation de portabilité du conteneur, pas du modèle. Faire tourner LLaMa sur un Raspberry Pi et faire tourner OpenDAN sur un Raspberry Pi sont deux choses différentes, et le dépôt ne permet pas de trancher.

Il faut donc lire cette fonctionnalité comme une porte ouverte, pas comme un chemin balisé. La bascule vers un modèle local est annoncée ; la procédure, les contraintes matérielles et les performances ne sont pas documentées dans les éléments disponibles.

La base de connaissances locale et ses cases non cochées

Le mécanisme de connaissance personnelle repose sur des spiders qui ingèrent des fichiers ou des courriels existants, puis les organisent en base interrogeable par les agents. L'agent Mia est présenté comme celui qui gère les données personnelles et les range dans une base de connaissances. Le README précise que les fichiers texte et les formats d'image courants sont pris en charge, et laisse explicitement non cochée la ligne concernant les autres formats courants.

C'est une limitation réelle, pas une note de bas de page. Un PDF, un document bureautique ou une archive de courriels dans un format propriétaire ne sont pas annoncés comme supportés. Or ce sont précisément les formats dans lesquels dorment la plupart des données personnelles qu'un utilisateur voudrait interroger. Tant que cette case reste vide, l'expression base de connaissances locale désigne un périmètre étroit : du texte brut et des images.

Le README ne documente pas non plus la manière dont les données sont indexées, si un modèle d'embedding est appliqué, ni comment la recherche est effectuée. On sait qu'il y a des spiders et une base, pas comment l'ensemble fonctionne. Pour un lecteur qui évalue le projet, c'est la zone la plus opaque du dépôt.

Workflows, magasin d'agents et ce qui n'est pas encore là

La collaboration entre agents est présentée comme une fonctionnalité implémentée, avec un workflow intégré nommé story_maker qui combine un outil AIGC pour produire des livres audio pour enfants. C'est un exemple concret, et il a le mérite de montrer à quoi sert un workflow : enchaîner plusieurs agents et outils pour un résultat qu'un seul agent ne produirait pas.

Le reste du catalogue est manuel. Le README indique que l'installation de nouveaux agents et workflows se fait par téléchargement et installation à la main. Le magasin centralisé, appelé OpenDAN Store, qui devait permettre l'installation en un point unique des agents, workflows et modèles, est reporté à la 0.5.2. Cette absence change l'expérience : il n'y a pas de découverte ni de mise à jour automatisée des composants. Chaque ajout passe par une opération manuelle que la documentation disponible ne détaille pas.

Le README mentionne aussi un noyau de calcul IA distribué, disponible pour des sélections complexes. La formulation est vague et aucun détail d'implémentation n'est fourni. Il faut la traiter comme une intention inscrite dans la feuille de route, pas comme une capacité sur laquelle bâtir une architecture.

Alternatives : LangChain et le problème du périmètre

L'alternative la plus directe n'est pas un autre AIOS, c'est une bibliothèque d'orchestration comme LangChain. La différence d'approche est nette. LangChain fournit des abstractions en bibliothèque : vous écrivez du Python, vous composez des chaînes, vous choisissez votre stockage vectoriel, votre modèle et votre interface. OpenDAN fournit un environnement complet avec un shell, des agents prénommés, un conteneur Docker et une base de connaissances intégrée. Le premier vous laisse assembler ; le second vous donne un assemblage déjà fait, avec les choix qui vont avec.

Cette différence a des conséquences pratiques. Avec LangChain, la mise à jour d'une dépendance cassée est votre problème, mais vous contrôlez chaque brique et rien ne vous oblige à adopter une notion d'agent prédéfinie. Avec OpenDAN, vous héritez d'un shell et d'un mode all-in-one qui, de l'aveu du README, n'est pas l'architecture finale. Vous héritez aussi d'une dépendance à l'écosystème du projet pour les agents et workflows, tant que le magasin n'existe pas.

Pour un usage strictement bibliothèque, LangChain reste plus prévisible. Pour quelqu'un qui veut voir tourner un système multi-agents complet sur sa machine sans écrire l'orchestration, OpenDAN a un intérêt de démonstration que LangChain n'a pas.

Coût de maintenance et licence MIT

Le dépôt est publié sous licence MIT, ce qui autorise l'usage, la modification et la redistribution, y compris dans un contexte commercial, à condition de conserver la notice de copyright et le texte de la licence. Le matériel fourni ne mentionne aucune restriction additionnelle. Cela ne dit rien du statut des modèles que vous branchez dessus : une clé API OpenAI reste soumise aux conditions d'OpenAI, et un modèle LLaMa exécuté localement relève de sa propre licence, que le README ne traite pas. C'est un point à vérifier séparément avant tout usage autre qu'expérimental.

Sur la maintenance, les éléments disponibles donnent un signal mitigé. Le dépôt n'est pas archivé et le dernier push indiqué est daté du 28 mars 2026. Les versions publiées, elles, sont plus anciennes : 0.5.1 en avril 2024, après 0.0.4 en juin 2023 et 0.0.3 quelques jours plus tôt. L'écart entre l'activité de commit et le rythme des publications suggère que le projet avance sur la branche principale sans étiqueter de version intermédiaire.

Le README lui-même prévient : le projet est à un stade très précoce et des changements importants sont possibles. La version 0.5.1 est décrite comme un MVP et le noyau formel est repoussé à la 0.5.2. Concrètement, cela signifie qu'une mise à jour peut modifier le fonctionnement des agents ou la structure des données stockées dans /root/myai. Le coût de maintenance n'est pas mesurable à partir des éléments fournis, mais l'absence de magasin centralisé et de documentation d'architecture en augmente le poids pour quiconque veut suivre le projet sur la durée.

Conclusion éditoriale

OpenDAN convient à un développeur Python qui veut expérimenter une architecture multi-agents sur sa propre machine, avec un modèle local LLaMa ou une clé OpenAI, et qui accepte de lire du code encore mouvant. Ce n'est pas un outil à mettre entre les mains d'un utilisateur non technique : le README mentionne lui-même des problèmes de dépendances Python lors de l'installation depuis les sources. Avant de vous engager, vérifiez trois points concrets dans le dépôt : le contenu réel du répertoire doc/QuickStart.md, l'état du support des formats de fichiers dans la base de connaissances (le README coche les fichiers texte et les images, mais laisse les autres formats non cochés), et le contenu du fichier docker-compose ou du Dockerfile pour comprendre ce qui est monté dans /root/myai.

Sources officielles

1. fiatrete/OpenDAN-Personal-AI-OS on GitHub
2. License: MIT
3. Project website
4. README
5. Releases