Demandes et décisions
Conversations, tickets, exigences, critères d’acceptation et validations conservent chacun leur sens propre et un responsable clairement identifié.
Une conversation ne devrait pas perdre son sens lorsque le travail devient une tâche, une modification de code ou un déploiement. Orion Workspace est conçu comme le lieu connecté qui réunit les personnes, les décisions et les éléments probants derrière une application.
L’expérience décrite ici est notre orientation pour NatusAI Orion. Le périmètre et la disponibilité du produit sont qualifiés séparément ; il ne s’agit pas d’une annonce de lancement.

Une demande donnée à titre d’illustration montre l’enchaînement prévu. Chaque étape produit un élément que la personne suivante, ou un agent autorisé, peut examiner.
Consigner le besoin. Convenir des expéditions concernées, de ce qui constitue un retard et des personnes autorisées à recevoir l’information. Un retour ne devient une exigence qu’une fois accepté.
Associer la modification exacte du code à un aperçu, aux résultats des tests et à la décision de la promouvoir. Les vérifications échouées restent visibles.
Créer une version immuable, consigner l’environnement cible et observer si l’application y satisfait à ses contrôles d’acceptation.
Garder les observations d’état, de support et d’usage qui en résultent reliées à la version. S’appuyer sur ces nouveaux éléments pour orienter l’amélioration suivante.
Processus donné à titre d’illustration, ni espace de travail en production ni démonstration d’une application publiée.
Quatre types d’enregistrements restent reliés : quiconque examine une application voit pourquoi elle a changé, et pas seulement qu’elle a changé.
Conversations, tickets, exigences, critères d’acceptation et validations conservent chacun leur sens propre et un responsable clairement identifié.
Documentation, références au code source et historique d’ingénierie restent versionnés et attribuables. Une collaboration fondée sur Git est prévue ; la forge n’a pas encore été choisie.
Tâches, tentatives, points de contrôle, diagnostics, évaluations et artefacts de vérification sont reliés aux entrées et à la version du code source qu’ils concernent.
Une modification fusionnée, une version publiée et un déploiement sain sont des résultats distincts, avec des enregistrements et des contrôles séparés.
Une tâche doit d’abord trouver la capacité et la version pertinentes, puis récupérer les schémas, exemples ou éléments probants nécessaires. Une petite modification ne devrait pas exiger de charger un dépôt entier ou tout l’historique d’une conversation.
Tentatives durables, annulation, points de contrôle et budgets rendent le travail en cours compréhensible. Les synthèses conservent les références aux sources et leur fraîcheur, tandis que les connaissances applicatives restent visibles uniquement par les participants autorisés.
Des diagnostics compacts et des différences précises aident personnes et agents à examiner le résultat sans masquer d’informations importantes sur l’exactitude ou les autorisations.


Les personnes gardent la maîtrise des objectifs métier, des accès, des budgets et des politiques d’exploitation. La visibilité au niveau de la plateforme ne donne pas accès aux données confidentielles des applications.
L’agent qui propose une modification ne peut ni approuver l’extension de ses propres autorisations, ni assouplir ses critères d’acceptation, ni activer son propre successeur.
Dites-nous ce dont votre entreprise a besoin. Nous vous aiderons à trouver un point de départ concret.
Ou écrivez-nous à contact@natusai.com
