Nous voulons qu’Orkas soit le socle sur lequel repose une entreprise AI-native. Cet objectif mène tout droit à une question : comment plusieurs personnes et plusieurs Agents collaborent-ils sur un même projet ?
La réponse est assez différente du travail d’équipe auquel nous sommes habitués. Pour comprendre pourquoi, mieux vaut repartir de l’origine de la collaboration entre humains. (Pour le guide pas à pas du produit, voir Projets partagés : comment les personnes et les Agents IA travaillent ensemble dans Orkas. Cet article porte sur la réflexion qui le sous-tend.)
La collaboration humaine s’est construite autour de deux limites humaines
D’abord, notre bande passante et notre mémoire sont limitées. Nous ne pouvons absorber qu’une quantité limitée d’informations à la fois, et nous n’en retenons qu’une partie. Les équipes doivent donc communiquer sans cesse : partager les nouvelles, s’aligner sur les objectifs, s’aligner sur l’avancement. Réunions hebdomadaires, stand-ups, comptes rendus quotidiens et hebdomadaires, « on fait un point rapide ? », « il faut qu’on s’aligne » : tout cela sert à compenser cette limite.
Ensuite, une grande partie doit se faire en face à face. En personne, il y a plus de canaux que les seuls mots : le langage corporel, le ton et les expressions du visage transmettent tous de l’information. Quand quelqu’un vous dit « le plan me paraît bien » de l’autre côté de la table, vous entendez s’il le pense vraiment. Tout aussi important, se voir en personne crée de la confiance. C’est pour cela que tant d’équipes à distance se retrouvent encore physiquement de temps en temps.
Ce qui change quand les Agents arrivent
Dans une équipe faite de personnes et d’Agents, la dimension humaine de la collaboration compte toujours. Mais travailler avec des Agents est très différent de travailler avec des personnes. Les Agents ont trois forces nettes et trois faiblesses nettes.
Trois forces
Une grande bande passante et une forte capacité d’exécution. C’est particulièrement vrai pour les tâches aux objectifs clairs et mesurables. Et les tâches que les Agents savent mener à bien deviennent vite plus longues, plus difficiles et plus complexes. En présentant son propre Agent de programmation, Meta décrit une tâche d’optimisation de noyaux GPU sur laquelle l’Agent a travaillé jusqu’à 24 heures et effectué plus de 1 000 appels d’outils (Meta). En octobre 2026, Linus Torvalds a publié une série de correctifs pour le noyau Linux dont le code, les programmes de test et la première version du message de commit avaient été écrits par Claude Code ; il a lui-même effectué les mesures sur sa machine (LWN).
Le savoir et les outils du monde entier, de bout en bout et d’une discipline à l’autre. Le pré-entraînement a déjà condensé le savoir du monde dans le modèle. Avec les bons outils, un Agent peut porter un même travail d’un bout à l’autre en traversant les disciplines : rédiger le PRD → concevoir → développer → tester → livrer. Quand des personnes font ce même travail, il faut que produit, design, développement et QA travaillent ensemble, avec un nouveau cycle d’alignement à chaque passage de relais.
Peu de faiblesses humaines, et pas de confiance à bâtir d’abord. Un Agent ne se fatigue pas, n’a pas de mauvais jours et n’a pas honte de poser une question basique. Un nouvel Agent peut commencer dès qu’il dispose du contexte du projet. Pas de période de prise en main, pas de relation à construire au préalable.
Trois faiblesses
Il lui faut un contexte propre. Un mauvais contexte le fait dévier. Nous l’avons vécu nous-mêmes : un champ de notre tableau de bord analytique indiquait que les données « ne peuvent pas être reliées », alors qu’elles pouvaient l’être ; c’est le champ lui-même qui était mal calculé. Deux Agents différents ont lu cette ligne, et tous deux ont abandonné une analyse complète du parcours utilisateur. Une personne qui voit cette conclusion demanderait : « Est-ce toujours exact ? » Un Agent la prend généralement pour argent comptant.
Il attribue mal les causes sur la durée. Quand plusieurs variables influent en même temps sur le résultat, il incrimine facilement la mauvaise, et il faut que des personnes le corrigent. Pendant un temps, quelques nouvelles pages de notre site n’étaient pas indexées par Google. Un Agent a conclu que « le site n’a pas assez d’autorité, donc Google ne veut pas lui consacrer de budget d’exploration » et a recommandé de commencer par obtenir des liens entrants. Nous avons contesté et vérifié : la grande majorité des pages du site étaient déjà indexées. Les quelques pages qui ne l’étaient pas ressemblaient plutôt à des sujets trop éloignés de la thématique du site. Le budget d’exploration n’y était pour rien, et miser sur les liens entrants aurait été une erreur.
Il s’adapte mal à un environnement qui change, surtout quand le changement ne figure pas dans ses données de pré-entraînement. Un site qui vient d’être refondu, une règle de plateforme qui vient de changer, un produit lancé le mois dernier : une personne remarque que « ce n’est plus pareil » et change d’approche. Un Agent continue souvent de s’appuyer sur ce qu’il sait déjà et retente la même chose, encore et encore.
Pourquoi les messageries ne conviennent pas
Les messageries ont été conçues pour des personnes qui travaillent avec des personnes : les messages défilent les uns après les autres, les @mentions et les accusés de lecture tiennent tout le monde au courant, et l’information est dispersée entre les canaux. Cette conception compense exactement les deux limites décrites plus haut. Les gens ont peu de bande passante et la mémoire courte, alors on publie sans arrêt et on s’aligne sans arrêt.
Pour les Agents, ce n’est pas la bonne forme :
- Les bavardages, les discussions en cours de route et les plans abandonnés par la suite ne sont, pour un Agent, que du bruit dans le contexte.
- Un Agent n’a pas besoin de bâtir la confiance par la conversation.
- Ce dont un Agent a vraiment besoin, c’est d’un contexte propre et d’une tâche claire.
La collaboration entre personnes et Agents doit donc être repensée. Et à mesure que les Agents gagnent en capacités, notre façon de collaborer continuera elle aussi d’évoluer. Dans Orkas, nous sommes encore en train de chercher.
Ce que fait Orkas : garder ce qui n’a pas changé, repenser ce qui a changé
Notre approche consiste à garder les parties de la collaboration qui n’ont pas changé et à repenser celles qui ont changé. Voici un projet partagé dans Orkas ; les quatre idées correspondent aux quatre zones mises en évidence.
1. Attribuer, transmettre et relire le travail : À faire
Cela existait bien avant les Agents, et nous en avons toujours besoin. Pour l’instant, chaque tâche de nos projets a un responsable humain, et c’est une personne qui répond du résultat final.
Dans le produit, cela fonctionne ainsi. Chaque élément à faire est attribué à une personne, et c’est elle qui décide quel Agent fait le travail. Seul le responsable peut lancer l’élément ; l’Agent s’exécute sur l’ordinateur du responsable, avec son modèle et ses crédits. Une fois le travail fini, l’Agent passe l’élément à En attente de confirmation au lieu de le marquer lui-même comme terminé. L’élément n’est terminé qu’après vérification par le responsable, qui y apporte au besoin ses modifications.
2. Partager objectifs, informations de fond et contexte : Objectifs et règles, Mémoire
Ici, personnes et Agents partagent le même contexte, si bien que les faits essentiels restent alignés.
Dans un projet, « Objectifs et règles » et « Mémoire » sont partagés par toutes les conversations de ce projet, et les Agents les suivent à chaque fois. Par exemple, inscrivez dans Objectifs et règles une définition comme « rétention mensuelle = nouveaux utilisateurs qui reviennent le mois suivant », et consignez les décisions clés dans la mémoire du projet. Quand un nouveau membre et ses Agents arrivent, ils lisent exactement la même chose dès le premier jour.
3. Transmettre par des fichiers, garder le processus à part
La Bibliothèque du projet se synchronise entre les membres, et un élément à faire peut porter n’importe quel fichier en pièce jointe. Le travail se transmet sous forme de fichiers, pas d’historique de discussion.
Nous gardons volontairement à part l’essentiel du processus intermédiaire, pour qu’il ne devienne pas un bruit de contexte nuisible pour les Agents. Les onglets verrouillés Tâches et Automatisation n’appartiennent qu’à vous. Un Agent peut enchaîner des centaines d’étapes et essayer trois approches avant de produire un seul rapport. Votre collègue ne reçoit que le rapport ; le processus reste dans vos propres tâches et ne se retrouve jamais dans le contexte de ses Agents.
4. Partager ses Agents privés avec l’équipe
Les membres peuvent partager leurs Agents privés pour que le reste de l’équipe les utilise. Ces Agents portent l’expérience de leur propriétaire et son jugement sur la qualité. Les partager fait gagner du temps à tout le monde, et les problèmes repérés à l’usage peuvent être corrigés grâce à l’autoévolution, ce qui élève ce dont le projet tout entier est capable.
Quand un Agent est partagé, Orkas regroupe ses instructions de travail et ses skills, y compris ceux qu’il a acquis seul en travaillant. Sa mémoire et son historique de conversation ne sont pas inclus. Quand la personne qui l’a partagé met l’Agent à jour, les membres reçoivent automatiquement la nouvelle version.
Un problème ouvert, encore à ses débuts
La collaboration entre personnes et Agents n’en est qu’à ses tout débuts, et les réponses n’ont pas encore convergé. À mesure que les modèles progressent, une grande partie de ce dont les Agents ont besoin pour collaborer passera dans les modèles eux-mêmes.
Certains modèles savent déjà le faire nativement : lancer plusieurs sous-Agents en parallèle pour explorer un problème sous différents angles, ou planifier d’abord puis confier l’exécution du plan à des sous-Agents. Muse Spark Open, dont Meta a publié les poids en accès libre en octobre 2026, est décrit comme entraîné à découper le travail, à le confier à des sous-Agents et à les coordonner (blog PyTorch).
Notre façon de collaborer changera donc à mesure que les modèles s’amélioreront. Les éléments à faire, le contexte partagé, la transmission par fichiers et les Agents partagés sont notre réponse à ce que les modèles savent faire aujourd’hui, pas la forme définitive.
Pour conclure
Nous avons gardé ce qui n’a pas changé : quelqu’un est responsable du travail, quelqu’un le relit, et les objectifs comme le contexte restent alignés. Nous avons repensé ce qui a changé : transmettre par des fichiers, garder le processus à part, et transformer l’expérience et le goût de chacun en Agents que l’équipe peut utiliser.
Nous explorons encore ce sujet, et nous aimerions confronter nos expériences. Si vous dirigez une équipe où personnes et Agents travaillent ensemble, essayez d’abord sur un seul projet. Orkas est en téléchargement gratuit pour macOS et Windows.