Stellary

Dans la plupart des organisations techniques, le travail est éparpillé. La planification vit dans un outil, l’exécution dans un autre, la documentation ailleurs encore. L’IA agit sans contexte durable, et le management lit des signaux incomplets.

Chaque outil est correct pris isolément. C’est la couture entre eux qui coûte : recopier un ticket, retrouver la décision qui explique un choix, expliquer à un assistant un contexte qu’il oubliera à la session suivante.

Stellary part d’une thèse simple : le delivery moderne doit se gérer dans un système unique, où planification, exécution, contexte, action IA et supervision partagent les mêmes objets et le même état réel.

Le workspace est l’unité de réalité : il concentre les membres, les agents, les projets, la base de connaissance, les plugins, les compétences, les pipelines et le cockpit. Ce n’est pas un espace de suivi, c’est un environnement de production continu.

Sur cette base, cinq couches s’articulent. Le delivery porte les projets, les vues, les cartes, les sous-tâches, les champs personnalisés et les relations. Le contexte porte les documents, la connaissance et les modèles. Le pilotage porte le cockpit, les missions, les blocages et les briefings.

La quatrième couche est celle qui change la nature du produit : agents, missions, automatisations, plugins, compétences et pipelines, avec un accès MCP qui permet aux agents de manipuler les objets réels du workspace plutôt qu’une copie de leur description. La cinquième couvre la gouvernance SaaSUn logiciel accessible en ligne, généralement proposé par abonnement. : organisations, permissions, facturation, administration et supervision.

Le socle applicatif est un backend NestJS découpé par domaines produit, sur Prisma et PostgreSQL, avec une couche temps réel WebSocket pour la synchronisation des vues collaboratives. L’application est une SPA React et Vite ; l’édition documentaire repose sur TipTap.

L’authentification couvre les sessions JWT, la double authentification et les jetons d’accès personnels, nécessaires dès lors que des agents et des intégrations externes agissent au nom d’un utilisateur.

L’exploitation est instrumentée dès l’origine — Sentry pour les erreurs, Prometheus pour les métriques — et la couverture de tests combine Vitest sur le domaine et Playwright sur les parcours critiques. L’internationalisation est traitée comme une contrainte de conception, pas comme une surcouche.