Un système d’exploitation du delivery
Cartes, documents, cockpit, pipelines, plugins et MCP doivent renforcer la même source de vérité plutôt que disperser le travail entre outils.
Stellary vise à être le système où le contexte projet, les arbitrages humains et l’exécution IA restent alignés—des signaux cockpit jusqu’au runtime gouverné, en passant par la documentation et les agents. Cette page décrit des ambitions produit ; elle est prospective et ne constitue pas un engagement de livraison.
Mis à jour 12 avril 2026
Cartes, documents, cockpit, pipelines, plugins et MCP doivent renforcer la même source de vérité plutôt que disperser le travail entre outils.
L’IA doit recommander, expliquer et accélérer—mais les actions sensibles restent explicites, autorisées et traçables.
Les runs, revues et docs doivent se distiller en playbooks, patterns et décisions réutilisables—pas seulement s’accumuler en texte.
Nous construisons vers une boucle fermée : contexte structuré → exécution gouvernée → revue humaine → connaissance mise à jour. Les agents et l’automatisation s’y branchent sans remplacer la responsabilité.
Le produit doit ressembler à un centre de commande pour les équipes qui livrent du logiciel : statut lisible, compromis explicites, et une IA qui travaille sur l’état réel du projet—pas un chat générique déconnecté du travail.
À mesure que les agents se généralisent, l’affectation doit passer du 100 % manuel à l’assisté : proposer le bon agent pour une mission selon compétences, charge, coût et historique—sans pilote automatique opaque.
La mémoire doit passer de journaux bruts à une intelligence d’équipe durable : distiller missions, documents et revues en motifs, checklists et playbooks réutilisables.
Un assistant contextuel transversal doit aider sur n’importe quelle surface sans casser le contexte local—utile, ancré, et relié aux permissions et aux actions réelles.
Les équipes mélangent runtimes locaux, MCP et exécution cloud. Stellary doit router l’exécution de façon intelligente avec une gouvernance claire, des comportements explicables et des défauts sûrs.
Les serveurs MCP doivent se propager vers les agents sous forme d’outils filtrables et assignables, avec une provenance visible—puissants, mais gouvernés pour éviter que l’explosion d’outils ne devienne un problème de sécurité ou d’UX.
Nous investissons activement dans l’exécution cloud gouvernée des agents (environnements persistants, sorties revue-friendly, workflows preview-first) comme socle de cette trajectoire.
Les arbitrages critiques deviennent des objets « décision » de premier plan : options, impact, propriétaire, échéance et historique—liés au cockpit et au delivery, pas noyés dans les commentaires.
La documentation doit évoluer vers un espace collaboratif premium : partage, responsabilité éditoriale et, lorsque c’est pertinent, co-édition temps réel entre humains et agents.
La connaissance doit être « vivante » : reliée aux cartes, missions et revues, avec des signaux lorsque les repères deviennent obsolètes.
La réflexion amont et l’idéation doivent avoir leur place dans le projet : capturer des notes brutes, affiner avec une IA structurante, puis convertir en specs, cartes ou décisions quand c’est mûr.
La collaboration externe doit être bornée : invités à périmètre contrôlé, vues publiques en lecture seule lorsque c’est justifié, et outils de revue visuelle pour des retours précis.
Là où design et implémentation se rencontrent, des intégrations plus profondes (par exemple outils de design) doivent relier handoff, previews et validation sans forcer les équipes à vivre en silos.
Une présence locale—shell desktop et pont maîtrisé vers dépôts et outils machine—peut débloquer des workflows hybrides qu’un pur web seul peine à couvrir, avec la sécurité comme contrainte de premier plan.
Les ambitions sont arbitrées, explorées et parfois reportées dans notre backlog produit interne. Les sujets passent de la découverte à la planification puis à l’implémentation au fil de l’apprentissage.
Pour l’état actuel du produit, appuyez-vous sur l’expérience dans l’app et sur la documentation. Cette page décrit une direction—pas une roadmap figée ni un calendrier.