Pivoa
L'essentiel à retenir
Starnet ressemble d’abord à un petit bureau en pixel art. Des agents occupent des pièces, circulent dans des couloirs et utilisent des objets. La lecture facile consiste à y voir une interface ludique posée sur des modèles d’IA. Elle rate le sujet.
Le projet traduit une architecture d’agents en règles visibles. Une pièce délimite une équipe et ses capacités. Un couloir autorise un passage de relais. Un objet donne accès à une capacité réelle. Chaque agent dispose de son espace de travail, de son transcript, de sa mémoire et de permissions bornées. Les tâches, journaux, coûts et plannings persistent. Les appels aux modèles et aux outils sont réels, tout comme leur coût.
Pour une PME, l’intérêt est là : rendre inspectables les droits, les transmissions, les dépenses et les responsabilités avant de chercher l’autonomie maximale. Starnet reste un projet jeune, avec des limites de compatibilité et de support à examiner. Ce n’est donc pas une recommandation d’achat. C’est une démonstration utile d’un principe de gouvernance : un agent ne devrait pas recevoir « de l’autonomie », mais un périmètre explicite pour agir.
Le problème que ça résout
Un agent IA devient risqué quand son périmètre reste implicite. Tant qu’il résume un document dans une fenêtre de chat, l’erreur est généralement visible et l’action reste humaine. Dès qu’il peut consulter des fichiers, appeler un modèle, utiliser un outil ou transmettre une tâche, la question change : quelles actions lui sont permises, sur quelles données, et jusqu’où peut-il aller sans validation ?
La plupart des interfaces rendent ces limites difficiles à lire. On voit une conversation. On voit parfois une liste d’outils. On voit moins facilement la chaîne complète : l’agent qui reçoit la mission, les capacités qu’il mobilise, le collègue artificiel auquel il passe le dossier, le coût cumulé et la trace laissée derrière lui.
Pour une PME belge de dix à cinquante personnes, cette opacité est un problème très concret. Les rôles se chevauchent. Une même personne peut gérer une partie des ventes, du support et de l’administration. Copier cette souplesse dans un système d’agents sans définir de frontières revient à automatiser les ambiguïtés de l’organisation.
Prenons un flux simple : un agent trie des demandes entrantes, un autre prépare une réponse, un troisième met à jour un outil métier. Si tous disposent des mêmes accès, le premier peut hériter de droits dont il n’a pas besoin. Si aucun passage de relais n’est formalisé, on ne sait plus qui a transformé l’information. Si les coûts sont dispersés entre plusieurs fournisseurs, une tâche apparemment banale peut mobiliser plusieurs appels sans que le responsable le voie immédiatement.
Le problème n’est donc pas seulement la qualité de la réponse. Il concerne aussi le contrôle de l’action. Qui peut lire ? Qui peut écrire ? Qui peut déléguer ? Qui paie ? Qui vérifie ? Tant que ces questions vivent dans une documentation séparée de l’exécution, elles finissent facilement par diverger du système réel.
Starnet propose une réponse visuelle à cette divergence. La topologie du bureau devient une représentation des permissions et des handoffs autorisés. On ne demande plus seulement à un agent ce qu’il sait faire. On regarde où il se trouve, ce qu’il peut atteindre et par quel chemin il peut transmettre le travail.
Ce que c'est concrètement
Starnet est un harness desktop local-first pour orchestrer des agents réels. Le pixel art est son langage d’interface, pas son résultat. Derrière les pièces et les personnages, le projet exécute des appels à des modèles et à des outils, avec des tâches concurrentes et des coûts réels.
Chaque agent a son propre workspace, son transcript, sa mémoire et un ensemble de permissions bornées. Cette séparation compte davantage que l’apparence. Elle permet de distinguer le contexte de travail d’un agent de celui de ses voisins, puis de limiter ses capacités au rôle prévu.
Le décor encode cette organisation :
- une pièce représente une équipe définie par ses capacités ;
- un couloir matérialise un handoff autorisé entre deux périmètres ;
- un objet correspond à une capacité réellement accessible ;
- les journaux, coûts, tâches et plannings sont persistés.
Cette métaphore force une discussion que les schémas d’architecture repoussent souvent à plus tard. Une porte n’est pas là pour faire joli. Elle signifie qu’une transmission est permise. L’absence de porte signifie l’inverse. Un objet posé dans une pièce doit correspondre à un pouvoir concret, donc à une surface de risque et à un besoin de supervision.
Le projet accepte une logique BYOK, avec des clés utilisées via OpenRouter ou des comptes pris en charge. Des modèles locaux peuvent aussi être employés. Le README prévient toutefois qu’ils peuvent être plus lents et moins fiables pour les tâches longues. « Local-first » ne signifie donc pas automatiquement « aucune donnée ne sort de la machine ». Le trajet dépend du modèle choisi, des outils appelés et des connecteurs activés. Cette vérification doit précéder tout usage de données internes.
Des connecteurs sont annoncés pour Telegram, Discord, Slack, Signal et Matrix. Leur présence élargit les points d’entrée possibles, mais elle ajoute aussi des identités, des secrets, des canaux et des règles de validation à administrer. Un connecteur n’est jamais seulement un confort d’interface. C’est une nouvelle frontière du système.
Au 26 septembre 2026, le dépôt public indique JavaScript comme langage principal et feat/harness-backend comme branche par défaut. Windows et macOS sont proposés publiquement. Linux ne l’est pas. Le code est sous licence MIT, tandis que la marque et les visuels sont exclus de cette licence. On peut donc examiner et réutiliser le code selon les termes de la licence, sans en déduire un droit sur l’identité visuelle du projet.
Comment s'en servir
L’usage le plus utile pour une PME ne commence pas par l’installation. Il commence par un processus borné, un responsable nommé et une carte des droits. Starnet peut ensuite servir de banc d’essai pour rendre cette carte exécutable et observable.
Étape 1 : choisir un flux réversible
Commencez par une tâche dont l’erreur peut être détectée et corrigée avant de produire un effet externe difficile à reprendre. Le classement de demandes, la préparation d’un brouillon ou l’extraction d’informations depuis un corpus défini offrent un terrain plus lisible qu’une action directe sur la facturation, la paie ou un engagement contractuel.
Décrivez l’entrée, la sortie attendue et le moment où un humain reprend la main. Le but n’est pas de prouver qu’un agent peut tout faire. Il est de savoir précisément ce qu’il fait déjà correctement, ce qu’il rate et ce que l’équipe doit encore valider.
Étape 2 : transformer les rôles en droits
Pour chaque agent, listez les ressources qu’il doit lire, les éléments qu’il peut modifier, les outils qu’il peut appeler et les actions qu’il ne doit jamais exécuter seul. Accordez le minimum nécessaire au scénario retenu.
Dans Starnet, cette matrice devient spatiale. Les agents partageant un périmètre cohérent occupent une même pièce. Les objets matérialisent leurs capacités. Cette représentation aide un dirigeant ou un responsable métier à relire l’architecture sans devoir interpréter toute la configuration technique.
Étape 3 : dessiner les passages de relais
Chaque couloir doit répondre à une question précise : quelle information passe, de quel agent vers quel autre, et sous quelle forme ? Un handoff vague transporte les mêmes défauts qu’une consigne vague. Il peut perdre le contexte, mélanger les responsabilités ou rendre l’erreur difficile à attribuer.
Prévoyez aussi le refus. Si une donnée manque, si une permission n’existe pas ou si le résultat sort du cadre, l’agent doit pouvoir arrêter le flux et demander une décision humaine. Une architecture sérieuse ne décrit pas uniquement le chemin idéal. Elle rend l’arrêt possible.
Étape 4 : observer une exécution complète
Lancez un petit ensemble de cas représentatifs, puis relisez les transcripts, les journaux, les tâches et les coûts persistés. Ne jugez pas seulement la réponse finale. Vérifiez quel agent a agi, quel outil a été utilisé, combien de passages de relais ont eu lieu et où une validation a manqué.
L’exécution concurrente mérite une attention particulière. Deux agents peuvent avancer en parallèle, mais la vitesse ne garantit ni l’ordre logique ni la cohérence. Si l’un dépend du résultat de l’autre, cette dépendance doit être visible dans le planning ou dans le flux, plutôt que supposée.
Étape 5 : attribuer la responsabilité humaine
Une pièce peut représenter une équipe d’agents. Elle ne devient pas pour autant responsable au sens organisationnel. Nommez une personne qui approuve le périmètre, suit les incidents, examine les coûts et décide des changements de droits.
Conservez également une règle simple pour toute capacité sensible : qui l’autorise, qui contrôle son usage et qui peut la retirer. La représentation visuelle facilite la discussion. Elle ne remplace ni les politiques internes, ni les obligations applicables, ni la responsabilité du dirigeant.
Étape 6 : étendre après preuve
Ajoutez un agent, un objet ou un couloir à la fois. Chaque extension doit correspondre à un besoin observé, pas à une possibilité séduisante. Comparez les résultats avant et après le changement, y compris sur les erreurs, la supervision nécessaire et les coûts d’appel.
L’autonomie utile se construit par paliers. Un système qui réussit un flux borné sous surveillance donne une base pour avancer. Un système dont les droits restent flous ne devient pas plus gouvernable parce qu’on lui ajoute des agents.
Ce que ça coûte vraiment
Le dépôt est public et le code est sous licence MIT. Cela ne rend pas le système gratuit à exploiter. Le coût total rassemble des dépenses visibles, comme les appels aux modèles, et du travail interne plus facile à oublier.
Il faut d’abord compter les licences et les API choisies. Starnet effectue de vrais appels, donc l’activité des agents génère de vrais coûts. Le BYOK donne le choix du fournisseur ou du compte pris en charge, mais transfère aussi à l’entreprise la gestion des clés, des plafonds, des accès et du suivi. Le coût dépendra du modèle, du volume de tâches, de la longueur des contextes, des outils utilisés et des reprises après erreur. La source ne fournit pas de budget standard applicable à une PME.
Vient ensuite le poste local. L’application doit tourner sur une machine compatible, aujourd’hui Windows ou macOS dans l’offre publique. Employer des modèles locaux peut réduire certains appels distants, sans supprimer le coût du matériel, de l’énergie, du stockage et du temps d’administration. Le README signale aussi une exécution potentiellement plus lente et moins fiable sur les tâches longues. Une économie d’API peut donc réapparaître sous forme d’attente, de reprises ou de supervision.
La configuration constitue un troisième poste. Il faut définir les agents, leurs espaces de travail, leurs mémoires, leurs outils, leurs permissions et leurs handoffs. Ce travail oblige à comprendre le processus métier avant de l’automatiser. S’il est bâclé, l’entreprise paie ensuite l’ambiguïté sous forme d’erreurs et d’enquêtes plus longues.
La maintenance ne disparaît pas après le premier flux réussi. Les modèles changent, les outils évoluent, les clés expirent, les connecteurs peuvent casser et les consignes dériver. Un projet jeune demande aussi d’évaluer le rythme des changements, la documentation disponible et les modalités de support avant de lui confier un processus important.
Il reste enfin les deux coûts les moins photogéniques : la supervision et la gouvernance. Quelqu’un doit relire les traces, traiter les exceptions, ajuster les droits, enquêter sur les incidents et décider si le système peut gagner en autonomie. Quelqu’un doit aussi vérifier les flux de données, les obligations contractuelles et les règles internes. Le temps humain ne disparaît pas. Il se déplace de l’exécution vers le contrôle, à condition d’avoir conçu ce contrôle dès le départ.
Le bon calcul n’oppose donc pas le prix d’un agent au salaire d’une personne. Il compare un processus actuel avec un processus instrumenté : dépenses techniques, temps de configuration, maintenance, validation, erreurs, reprises et responsabilité incluses. Sans cette vue complète, le coût affiché par le fournisseur de modèle raconte seulement une fraction de l’histoire.
Pour qui ce n'est pas
Starnet n’est pas un choix évident pour une organisation qui cherche un produit mûr, un support contractuel clairement établi ou une compatibilité Linux publique. Le projet peut être intéressant à étudier tout en restant prématuré pour un usage critique. Ces deux constats peuvent coexister.
Ce n’est pas non plus le bon point de départ si personne ne peut définir les droits des agents. La visualisation ne répare pas un processus dont les responsabilités sont inconnues. Elle rendra peut-être le flou plus visible, ce qui est déjà utile, mais elle ne décidera pas à la place de l’entreprise.
Une équipe qui exige que toutes les données restent sur son infrastructure doit examiner chaque dépendance. L’approche local-first favorise le contrôle local, mais les modèles distants, OpenRouter, les comptes pris en charge, les outils externes et les connecteurs peuvent créer des sorties réseau. Il faut cartographier le flux réel, pas se fier à une étiquette.
Le recours à des modèles locaux demande la même lucidité. Ils sont possibles, mais la source avertit de limites de vitesse et de fiabilité sur les tâches longues. Une entreprise qui attend une autonomie prolongée sans supervision doit tester cette contrainte sur ses propres cas avant d’en faire une promesse opérationnelle.
Enfin, la licence MIT concerne le code. Elle n’englobe pas automatiquement la marque ni les visuels, explicitement exclus. Réutiliser une base technique et reprendre son identité sont deux actes différents.
La bonne cible est donc une équipe capable d’expérimenter sur un périmètre borné, de lire les journaux, de suivre les coûts et d’assumer la maintenance. Si l’objectif consiste seulement à donner une apparence vivante à plusieurs chatbots, le détour ne vaut probablement pas l’effort. La valeur apparaît quand le plan du bureau devient aussi le plan des responsabilités.
Source : https://github.com/androoAGI/starnet
FAQ
Starnet est-il un jeu ou un outil d’orchestration ?
C’est un outil d’orchestration présenté comme un bureau en pixel art. Les agents appellent réellement des modèles et des outils. Les pièces, couloirs et objets représentent des équipes, des handoffs et des capacités, tandis que les tâches, journaux, coûts et plannings sont persistés.
Peut-on faire fonctionner Starnet sans envoyer de données à un modèle distant ?
Le projet permet d’utiliser des modèles locaux. Cela peut éviter certains appels à des modèles distants, mais il faut aussi vérifier chaque outil et connecteur. La source précise que les modèles locaux peuvent être plus lents et moins fiables pour les tâches longues.
Starnet est-il disponible sous Linux ?
Pas dans l’offre publique décrite par le projet au 26 septembre 2026. Windows et macOS sont pris en charge publiquement, tandis que Linux ne l’est pas. Cette limite doit être vérifiée avant toute décision d’architecture ou de déploiement.
La licence MIT autorise-t-elle à reprendre toute l’identité du projet ?
Non. Le code est sous licence MIT, mais la marque et les visuels sont exclus. La licence du code ne doit pas être interprétée comme une autorisation générale de reproduire le nom, l’univers graphique ou les actifs visuels.
Quel est le premier test pertinent pour une PME ?
Un flux court, réversible et supervisé : par exemple classer des demandes ou préparer un brouillon à partir d’un corpus défini. Il faut attribuer des droits minimaux, formaliser les handoffs, puis examiner les traces, les coûts, les erreurs et le temps humain avant d’étendre le périmètre.
Publié le 27 septembre 2026.
Cet article est un outil d'orientation, pas un avis juridique. Pour une analyse adaptée à votre situation, consultez un professionnel qualifié.
