Orkas open source ou application : travailler en équipe ?

L'essentiel à retenir

« Une équipe d'agents » ne signifie pas « une équipe de collègues ». Orkas sait répartir le travail entre un Commander, des spécialistes et des agents externes. Mais si votre responsable marketing doit reprendre le projet préparé par une collègue sur son propre poste, la distinction entre les éditions devient décisive. Selon le README du projet, les projets partagés, la synchronisation cloud et la publication d'applications web sont réservés à l'application distribuée. La version exécutée depuis les sources ne les prend pas encore en charge.

Pour une PME belge de 10 à 50 personnes, le choix tient donc moins à la taille de l'entreprise qu'au trajet du travail. Un opérateur unique qui produit des livrables pour ses collègues peut rester sur l'édition open source et transmettre les fichiers par un canal déjà maîtrisé. Des collègues qui doivent entrer dans le même projet Orkas, se répartir les tâches et retrouver le contexte depuis leurs postes ont besoin des fonctions de l'application distribuée. Et si l'objectif est de mettre une application produite avec Orkas à disposition par lien public, le README précise que cette publication relève des offres payantes de l'application distribuée. Ce sont trois besoins différents. Les confondre conduit à choisir une édition sur une promesse qu'elle ne tient pas.

Le problème que ça résout

Orkas appelle « équipe » la coordination d'agents IA autour d'un objectif. Son Commander peut découper le travail, mobiliser des spécialistes, puis réunir des livrables. Un projet conserve un objectif, des règles, de la mémoire et des fichiers ; sa liste de tâches peut mêler travail humain et travail d'agents. Ces fonctions existent dans la proposition générale décrite par le README. Elles répondent à une question : comment une personne organise-t-elle un travail assisté par plusieurs agents ?

Une PME en pose une autre : comment plusieurs personnes travaillent-elles sur le même projet sans que l'une devienne la boîte aux lettres de toutes les autres ? Il faut alors pouvoir inviter un collègue, lui attribuer une tâche, partager le contexte pertinent et retrouver l'état du projet. Le README annonce des projets partagés dans l'application distribuée, avec invitation d'un coéquipier ou d'un assistant externe et attribution des tâches à une personne ou à un agent. Il exclut explicitement cette fonction de la compilation open source. Le mot « équipe » couvre donc deux réalités qui ne coïncident pas.

Prenons une équipe commerciale qui prépare une réponse à un appel d'offres. Une personne demande à Orkas de structurer les éléments, de rédiger une première version et de produire un support. Elle exporte ensuite les documents vers le dossier de travail habituel. Ici, la coopération humaine se passe hors d'Orkas. En revanche, si la personne chargée du chiffrage et celle chargée de la rédaction doivent voir les mêmes tâches et reprendre les mêmes fichiers dans Orkas, une simple copie de l'application sur chaque poste ne crée pas un projet commun. Cette nuance doit figurer dans votre choix avant toute discussion sur les modèles.

Ce que c'est concrètement

Le tableau « Download » du README distingue l'application distribuée, qui demande une connexion à un compte, et l'exécution depuis les sources, qui n'en demande pas. Le projet est sous licence MIT, mais cette licence ne donne pas automatiquement à la compilation depuis les sources toutes les fonctions du produit distribué. À l'inverse, installer l'application distribuée ne signifie pas nécessairement souscrire immédiatement à une offre payante : le README la présente comme gratuite au démarrage, avec des crédits pour son modèle intégré. Il réserve expressément la publication d'une application web aux offres payantes. Il ne détaille pas dans ce tableau le coût ou les éventuelles limites d'utilisation des projets partagés et de la synchronisation : ne bâtissez pas un budget sur une hypothèse.

Cette grille n'est pas un palmarès. La première colonne oblige à nommer le geste de travail attendu. « Nous voulons collaborer » est trop vague pour engager un choix d'outil ; « deux chargés de projet doivent ouvrir le même dossier et s'attribuer les tâches dans Orkas » est une demande à laquelle le README permet de répondre. Il faut aussi distinguer un lien public vers une application et un document que l'on transmet à un client. La possibilité de produire un fichier ne prouve pas que l'édition open source sait publier une application web.

Comment s'en servir

La synchronisation change-t-elle la promesse « local-first » ?

Local-first décrit le point de départ du stockage, pas l'absence absolue de services distants. Le README indique que les données restent sur le disque par défaut et que les clés de fournisseurs sont chiffrées localement et exclues de la synchronisation cloud. Il précise aussi que les projets partagés et la synchronisation cloud optionnelle de l'application distribuée stockent les données sélectionnées sur les serveurs d'Orkas. Une équipe ne doit donc pas déduire du mot « local » que rien ne sort jamais de l'ordinateur. Les deux fonctions collectives annoncées méritent une décision explicite sur les données qu'on accepte d'y placer.

Il faut séparer trois trajets. Le projet et ses fichiers ont un lieu de conservation. Les appels au modèle ont une destination. Les connecteurs vers Gmail, Drive, Slack ou d'autres services introduisent leurs propres échanges. D'après le README, avec vos propres clés, les appels au modèle partent directement de votre machine vers le fournisseur ; le modèle Orkas intégré passe par le service de modèles géré par Orkas. Un endpoint local compatible est une autre option. Cette distinction est plus utile que l'étiquette générale « souverain » : chaque option implique un trajet différent pour les données envoyées au modèle.

Dans une PME qui traite des propositions commerciales confidentielles, la question opérationnelle devient précise : quels éléments du projet sont envoyés à quel modèle, avec quelles clés et quels connecteurs ? Le README ne donne pas à lui seul une cartographie exhaustive des données traitées par chaque option. Ne présentez donc pas l'exécution depuis les sources comme une garantie de traitement intégralement hors ligne. Avec une clé de fournisseur externe, le modèle reste externe. Et le README précise même que la saisie vocale dans la version source requiert une clé Orkas et envoie l'audio à Orkas pour reconnaissance. Si l'interdiction de tout flux externe est absolue, il faut examiner séparément chaque fonction activée et le modèle retenu ; le nom de l'édition ne suffit pas.

Le modèle choisi change-t-il la capacité à partager un projet ?

Non, pas selon les limites décrites dans le README. Le choix du modèle et celui de l'édition répondent à deux questions distinctes. Le Commander et les spécialistes intégrés partagent un réglage de modèle : modèle Orkas intégré, fournisseur choisi avec vos clés ou endpoint local. Les agents externes lancés en session locale, comme Claude Code, Codex, OpenCode, OpenClaw ou Hermes-Agent, conservent leurs propres réglages de modèle. Changer le modèle du Commander ne transforme donc pas à lui seul tous les agents externes, et installer un modèle local n'ajoute pas les projets partagés à l'édition source.

Le tableau du README fait une autre distinction : le modèle Orkas intégré figure dans l'application distribuée, tandis que l'exécution depuis les sources mentionne vos propres clés ou un endpoint local. Pour un responsable de PME, cette séparation évite deux erreurs de budget. La première consiste à croire que « application gratuite » veut dire « usage de modèle illimité » : le README parle de crédits de démarrage, sans établir ici le coût total de votre usage futur. La seconde consiste à croire que les clés personnelles de chaque collaborateur rendent automatiquement un projet partagé. La gestion des clés et le partage du projet sont deux mécanismes différents. Avant d'autoriser plusieurs personnes à travailler dans le même espace, il faut décider qui porte les clés, qui peut accéder aux livrables, et quels agents externes disposent déjà de leurs propres comptes ou autorisations. Ce sont des décisions d'organisation, pas des performances à attribuer au logiciel.

Trois situations où le choix devient clair

Une responsable marketing produit, l'équipe relit ailleurs

Elle utilise Orkas pour rassembler des sources, rédiger un projet de campagne et préparer des fichiers. Le directeur commercial relit les livrables dans le circuit documentaire existant ; personne d'autre n'a besoin d'entrer dans le projet Orkas. L'édition exécutée depuis les sources peut suffire pour cette organisation. Elle ne fournit pas de projet partagé, et ce n'est pas un défaut si le relais humain se fait volontairement ailleurs. La responsabilité de la version finale reste à définir dans ce circuit documentaire.

Attention à la continuité : si la responsable quitte son poste ou part en congé, la présence de fichiers dans Orkas sur son ordinateur ne vaut pas synchronisation automatique vers celui d'une collègue. La PME doit organiser la transmission avec ses outils de fichiers habituels. Il serait trompeur de décrire cette organisation comme une collaboration native d'Orkas.

Le chef de projet et une assistante doivent reprendre le même dossier

Le chef de projet définit les objectifs ; l'assistante suit les tâches et prépare les pièces ; tous deux doivent voir le travail dans Orkas. Les projets partagés de l'application distribuée correspondent à la fonction annoncée par le README. C'est l'option à examiner, même si l'entreprise ne compte que dix personnes. Le critère est le besoin d'accéder au même contexte de travail, pas un seuil d'effectif. Le README ne promet pas ici une édition simultanée des mêmes fichiers.

Il reste à distinguer « projet partagé » et « synchronisation activée ». Le README signale cette dernière comme optionnelle. Avant de compter sur une reprise d'un poste à l'autre, l'entreprise doit vérifier les réglages effectivement retenus et ses propres règles d'accès. Le README établit l'existence des fonctions dans l'application distribuée, pas les modalités détaillées de chaque abonnement ni une garantie sur tous les cas de reprise.

Un outil interne doit devenir accessible par URL

Une personne décrit une petite application dans Orkas et veut la faire ouvrir à des collègues dans leur navigateur. Le README indique que les applications sont créées localement dans l'interface, puis que l'application distribuée peut, avec une offre payante, les publier comme applications web via un lien public. L'édition source n'inclut pas cette publication. Ici, l'arbitrage ne porte pas seulement sur « travailler ensemble » : il porte aussi sur le mode de mise à disposition d'un logiciel.

Un lien public n'est pas une politique d'accès interne. Le README ne suffit pas à affirmer qui peut ouvrir ce lien, quelles protections sont disponibles ou comment s'administrent les droits. Si l'outil contient des données de clients, ne confondez pas facilité de diffusion et autorisation de diffusion. Vérifiez les modalités du service avant de mettre ce cas dans un cahier des charges.

Ce que ça coûte vraiment

L’exécution depuis les sources ne facture pas une fonction de projet partagé qu’elle ne fournit pas. Elle exige en revanche que quelqu’un prépare l’environnement, maintienne l’application et choisisse un mode d’accès aux modèles. Avec des clés de fournisseurs, la facturation des appels relève de ces fournisseurs. Avec un endpoint local, les coûts passent par le matériel et son administration. Une licence MIT ne transforme donc pas l’outil en service sans coût d’exploitation.

L’application distribuée est annoncée comme gratuite pour démarrer avec des crédits du modèle intégré. Le README indique que des offres payantes ajoutent notamment des crédits, davantage de projets partagés, la synchronisation et la publication d’applications. Il ne faut pas promettre un nombre de collaborateurs, une fréquence de synchronisation ou une enveloppe de crédits sans vérifier l’offre réellement retenue. Pour comparer les deux éditions, additionnez au prix affiché les appels aux modèles externes, le temps d’administration et le canal de transmission des livrables que vous devrez conserver.

Pour qui ce n'est pas

Ne choisissez pas Orkas pour un besoin de coédition en temps réel : le README annonce des projets partagés, mais ne décrit pas une édition simultanée de documents par plusieurs personnes. Si c’est la condition centrale, demandez une démonstration de ce parcours avant d’en faire le cœur du projet.

L’édition source ne convient pas si chaque collègue doit ouvrir les mêmes tâches depuis son poste dans Orkas. L’application distribuée ne convient pas non plus si votre politique interdit un compte Orkas ou les flux de données nécessaires aux fonctions collectives que vous souhaitez activer. Dans ces deux cas, distinguez le besoin d’orchestrer des agents du besoin de collaborer entre humains : vous pouvez utiliser un espace documentaire déjà gouverné pour le second, sans faire dire au premier qu’il le remplace.

Quelles questions mettre sur la table avant de choisir ?

Posez-les en réunion de décision, pas comme protocole de test technique. Qui ouvre le projet chaque matin ? Les collègues doivent-ils seulement recevoir un livrable ou intervenir dans la liste de tâches Orkas ? Qui a besoin de retrouver la mémoire du projet sur un autre poste ? Une application web doit-elle être publiée, ou un fichier remis par le canal habituel suffit-il ? L'entreprise accepte-t-elle un compte Orkas ? Quels flux accepte-t-elle pour les modèles et les connecteurs ?

On peut alors formuler une règle simple. Si Orkas reste l'atelier d'une personne, l'édition source est cohérente lorsque les modèles et les contraintes de poste conviennent. Si Orkas devient l'espace commun de plusieurs personnes, l'application distribuée est nécessaire pour les fonctions de partage et de synchronisation annoncées. Si la publication web est une exigence, vérifiez l'offre payante correspondante et ses conditions. Aucun de ces choix ne dispense de décider qui valide un livrable et où se trouve sa version approuvée.

Le guide déjà consacré à l'audit d'une orchestration d'agents traite d'une autre question : comment observer un agent en mission. Ici, l'enjeu est le plan de travail humain que l'on achète ou que l'on se donne. Un logiciel peut coordonner beaucoup d'agents sur un poste et rester, pour les collègues, un atelier individuel. C'est ce décalage qu'il faut trancher avant de distribuer le travail.

Source : https://github.com/Orkas-AI/Orkas

FAQ

La version open source d'Orkas permet-elle d'inviter un collègue dans un projet ?

Non, d'après le README : les projets partagés sont réservés à l'application distribuée. Deux personnes peuvent échanger des fichiers par un autre outil, mais ce n'est pas une invitation native dans un même projet Orkas.

Peut-on synchroniser l'édition exécutée depuis les sources ?

Le README précise que sa synchronisation cloud n'y est pas prise en charge. Il annonce cette fonction comme optionnelle dans l'application distribuée. Un mécanisme externe de partage de fichiers n'est pas équivalent à la synchronisation du projet décrite par Orkas.

Faut-il payer pour publier une application web ?

Le README réserve cette possibilité aux offres payantes de l'application distribuée. Il n'en donne pas dans ce passage le prix ni toutes les conditions d'accès. Une application créée localement n'est pas automatiquement publiée sur le web.

Utiliser un modèle local garantit-il une collaboration locale entre collègues ?

Non. L'endpoint local concerne les appels au modèle du Commander et des spécialistes intégrés. Le partage de projets dépend de l'édition ; les agents CLI externes gardent aussi leurs propres réglages de modèle.

L'application distribuée impose-t-elle la synchronisation cloud ?

Le README la qualifie d'optionnelle. Le choix de l'édition, l'activation de la synchronisation et le trajet des appels au modèle doivent être décidés séparément.

---

Publié le 3 novembre 2026.

Cet article est un outil d'orientation, pas un avis juridique. Pour une analyse adaptée à votre situation, consultez un professionnel qualifié.