Ce journal recense, semaine après semaine, ce qui a été développé dans la plateforme. Les nouveautés arrivent sur les organisations hébergées au fil des mises en production.
- Moteur — ordre garanti par référence. Les messages d'une même référence (par exemple les versions successives d'une opération) sont traités dans l'ordre, même s'ils arrivent dans le désordre. Un réglage du studio définit le sort d'un message sans numéro de séquence.
- Messagerie — rien de perdu au redémarrage. Chaque message est journalisé avant d'être acquitté ; au redémarrage, le traitement reprend depuis le journal.
- Workflow — étape confiée à un agent IA, en option. Une transition peut solliciter un agent déployé, avec la trace de chaque appel et un incident si l'appel échoue.
- Console — journal des appels MCP. Par serveur, par compte et par organisation, avec filtres, détail et export CSV ; prompts et ressources de l'organisation versionnés.
- Studio — projets dans git. Un projet se lie à un dépôt : pousser, récupérer, détection des conflits ; le déploiement peut partir d'une chaîne d'intégration externe.
- Sites — publication versionnée. Un site web externe se publie en versions, avec retour à une version précédente.
80 corrections sur la période.
- Rapports — éditeur de rapports interactifs. Filtres, visualisations et données dans un même écran ; totaux, sous-totaux, médiane et écart-type calculés par le service de données ; un clic sur un graphique filtre le rapport.
- Organisations — cloisonnement à la création. Chaque organisation reçoit son propre périmètre réseau, en conteneurs comme sur Kubernetes, libéré à sa suppression.
- Catalogues par organisation. Chaque organisation voit les cas d'usage et les services qui lui sont ouverts ; les autres sont refusés par le serveur, pas seulement masqués.
- Connecteurs MCP — connexion par OAuth. Un client MCP se connecte avec une clé d'API de l'organisation, après un écran de consentement en français et en anglais.
- Studio — utilisable sur tablette et téléphone. Designer de workflow, correspondances, rapports et formulaires s'adaptent aux petits écrans.
- Studio — tables de décision guidées, contrôlées et testables comme le moteur les évalue ; la validation d'un flux propose de corriger les constats en une commande annulable.
72 corrections sur la période.
- Sécurité — une identité par instance. Chaque instance démarre sous sa propre identité, avec des secrets dérivés pour elle seule, dans le réseau de son organisation.
- Ressources — limites par instance. Mémoire, processeur et nombre de processus sont bornés pour chaque instance.
- Clés d'API — portées étendues. Une clé peut demander l'accès au studio, à la messagerie, au CMS ou à l'ingestion de flux, et rien de plus.
- Services de données — exposition en liste blanche. Un jeu de données n'est exposé que s'il est déclaré ; tout le reste est refusé par défaut.
- Base de données — schéma versionné. Les évolutions du schéma de la plateforme passent par des migrations versionnées et rejouables.
95 corrections sur la période.
- Console d'instance unique pour tous les types d'instance : configuration sur une page, avec la provenance de chaque réglage et ceux qui attendent un redémarrage.
- Journaux d'instance lisibles pour tous les types, avec niveaux, recherche et suivi en direct.
- CMS — stockage au choix. Le contenu sur une base au choix, les fichiers sur tout stockage objet compatible S3.
- Studio — un site se publie en une seule action, et le journal de publication reste consultable après la fermeture du dialogue.
- Workflow — reprise. Une instance de processus perdue se restaure à sa place, et l'écran dit où elle en est.
- Courriel — destinataires restreints. Une instance peut limiter les adresses auxquelles elle écrit.
68 corrections sur la période.