Questions fréquemment posées

3forge est l'éditeur de 3forge Enterprise, une maillage applicatif destinée à construire et exploiter des applications temps réel à forte intensité de données. L'maillage applicatif réunit l'accès aux données, le traitement d'événements, le développement applicatif et le contrôle opérationnel dans un même runtime gouverné. Plutôt que d'assembler des produits distincts pour la messagerie, les bases de données, les tableaux de bord, les droits d'accès, le reporting et la logique de workflow, les équipes construisent sur une fondation unique de niveau production et n'écrivent que la logique propre à leur problème métier.

3forge a été conçu dès l'origine pour les institutions financières, où les applications doivent traiter des flux continus, réagir de façon déterministe aux événements, appliquer des droits d'accès très fins et rester transparentes face aux exigences opérationnelles et réglementaires.

L'maillage applicatif est le modèle d'architecture 3forge qui relie données, logique, applications et exécution au sein d'un patrimoine technique déjà existant. Elle virtualise l'accès gouverné aux données temps réel et au repos, fournit les services de runtime communs nécessaires pour construire et exploiter des applications, et connecte utilisateurs, workflows, outils analytiques et agents IA via des interfaces cohérentes.

L'maillage applicatif ne remplace pas la pile technologique de l'entreprise. Les bases de données existantes, les systèmes historiques, les applications d'entreprise, les classeurs Excel, les notebooks et les frameworks comme React restent en place et deviennent participants d'un environnement unique, observable et contrôlé. Ce qui rend une application partie prenante du maillage n'est pas l'endroit où son interface est construite, mais la cohérence avec laquelle elle accède aux données, invoque la logique, applique les contrôles et expose son fonctionnement.

L'maillage applicatif combine trois capacités que les entreprises achètent, développent et exploitent habituellement séparément :

• Maillage de données temps réel. Accès gouverné aux bases de données, flux, API, fichiers et systèmes de messagerie, avec la mise en cache, la persistance, la normalisation, le traitement d'événements complexes et la distribution contrôlée qu'exigent les charges opérationnelles.
• Application Engine. Les services récurrents dont les applications ont besoin : gestion d'état, traitement d'événements, permissions, formulaires, visualisations, reporting, tests, déploiement et supervision, afin que les développeurs se concentrent sur la logique métier.
• Operations Hub. Visibilité et contrôle à l'échelle du parc sur les applications déployées, leurs composants, dépendances, versions, licences et charges de travail.

Les piliers se renforcent mutuellement. Chaque connexion, transformation, politique et composant applicatif créé pour un projet devient réutilisable, si bien que chaque nouveau cas d'usage renforce la fondation commune au lieu de créer une pile isolée de plus.

Pas au sens générique. 3forge se décrit plutôt comme un moteur applicatif natif de la finance. La plateforme inclut des capacités de développement visuel et une composition rapide d'interfaces, mais sa vraie valeur tient au fait que le runtime lui-même intègre déjà les capacités de données, de logique, de gouvernance et d'exploitation dont les institutions financières ont besoin de façon répétée. Cela la distingue fondamentalement d'un outil low-code générique ou d'un produit de tableaux de bord autonome.

Les développeurs écrivent une logique métier explicite et conçoivent des workflows sur mesure. Le moteur prend en charge ce qui est commun, ce que 3forge appelle le développement du dernier kilomètre.

3forge est déployé dans des banques d'investissement de premier rang, des hedge funds internationaux, des sociétés de gestion, des prime brokers, des bourses, des sociétés de private equity et des fonds souverains. Les clients vont de grandes institutions sell-side comptant des milliers d'utilisateurs à des sociétés buy-side compactes qui doivent avancer vite sans construire leur infrastructure de zéro. Des milliers de développeurs dans le monde construisent sur la plateforme.

Les cas d'usage courants incluent les applications de salle de marché, le risque et le P&L temps réel, la réconciliation post-marché, la surveillance de conformité, les opérations de fonds en capital privé et les tableaux de bord opérationnels.

Les outils de BI sont conçus pour des analystes métier interrogeant des jeux de données statiques ou rafraîchis par lots. 3forge est conçu pour des développeurs qui construisent des applications sur des données en streaming temps réel, avec une latence de mise à jour inférieure à la milliseconde, du traitement d'événements complexes et un contrôle programmatique complet sur l'ensemble du système.

Contrairement aux outils de BI, 3forge est une plateforme de développement complète : elle inclut sa propre base de données en mémoire, une base historique, un framework de feed handlers, un langage de script (AmiScript) et un modèle de déploiement pensé pour des environnements de production 24/7 en secteur réglementé. Tableau et Power BI peuvent d'ailleurs consommer le maillage via le pilote ODBC 3forge : les deux approches ne s'excluent pas.

3forge est principalement déployé sur site, dans l'infrastructure du client, ce qu'exigent la plupart des clients institutionnels pour des raisons de résidence des données, de sécurité et de contraintes réglementaires. Les déploiements en cloud privé et hybrides sont pleinement pris en charge, y compris dans des environnements conteneurisés sur Kubernetes.

Des options de déploiement managé existent pour certains cas d'usage. Contactez-nous pour discuter du modèle le mieux adapté à votre environnement.

Les licences 3forge sont adaptées à l'échelle de déploiement et au cas d'usage de chaque institution. Notre équipe commerciale construit avec vous un accord reflétant le périmètre de votre déploiement, qu'il s'agisse d'une seule ligne métier ou d'un déploiement mondial multi-régions.

Sur le plan opérationnel, les licences sont administrées par le client via Operations Hub plutôt que par des échanges manuels machine par machine. Voir la section Operations Hub & Licences pour le fonctionnement de l'émission des licences, des périodes de grâce et des déploiements hors ligne.

Récompenses récentes du secteur :

• Prime Broker of the Year, Technology : HedgeWeek 2025
• Best Full-Stack Dev Platform : Trading Tech Insights Europe 2025
• Best Trading Tech Stack Platform : Trading Tech Insights USA Awards 2025
• Best Sell-Side Web-Based Development Environment : Sell-Side Tech Awards 2025
• Best Transaction Cost Analysis System Provider : Waters Rankings 2025

3forge a son siège à New York, au 225 Broadway, Floor 40, New York, NY 10007, avec des bureaux à Orlando, Londres, Singapour, Hong Kong, Tokyo et Toronto. Les demandes générales peuvent être adressées à info@3forge.com.

Le Maillage de données temps réel est le premier pilier du maillage applicatif. Il fournit un accès gouverné aux bases de données, flux, API, fichiers et systèmes de messagerie tout en laissant les systèmes sources faire autorité, et donne aux applications, aux utilisateurs et aux agents un accès unifié à l'état courant des tables, flux et procédures temps réel et historiques répartis sur les nœuds de données du maillage.

Ce n'est pas un nouvel endroit où stocker les données. C'est une couche d'exploitation commune au-dessus des référentiels, flux et systèmes que l'entreprise utilise déjà, qui ajoute entre une source et ses consommateurs la mise en cache, la persistance, la normalisation, le traitement d'événements complexes et la distribution contrôlée dont les charges opérationnelles ont besoin.

Les données temps réel sont des données en mouvement : ticks de marché, événements d'ordres et d'exécutions, télémétrie et messages arrivant en continu depuis des flux, des bus de messages et des plateformes de streaming. Leur valeur est maximale à l'instant où elles arrivent, et elles n'ont aucune forme stable interrogeable plus tard si rien ne les capture.

Les données au repos, également appelées données historiques, sont des données déjà écrites : positions, données de référence et clients, transactions passées, enregistrements de fin de journée et historique long terme conservés dans des bases, entrepôts, lacs et fichiers. Elles sont stables et interrogeables, mais elles décrivent le passé.

La plupart des vraies questions métier exigent les deux en même temps. « Quelle est mon exposition à cet instant » est un ensemble de positions au repos revalorisé par un prix vivant. « Cet algorithme se comporte-t-il normalement » est un flux d'ordres vivant comparé à une référence historique. Aucune moitié ne répond seule, et c'est pourquoi 3forge traite les deux comme un seul modèle d'exploitation plutôt que comme deux systèmes.

La virtualisation de données consiste à offrir aux consommateurs une manière unique et cohérente d'interroger, de s'abonner à et de combiner des données sans les copier au préalable dans un magasin physique unique. La plateforme présente les sources distribuées via des interfaces stables, tout en gérant derrière elles la connectivité aux sources, la normalisation, les droits d'accès, la mise en cache et le contrôle de charge.

La conséquence pratique est qu'une livraison n'a pas à attendre un programme de consolidation. Les systèmes sources continuent de faire autorité et conservent leur propre cycle de vie, tandis que les données qu'ils détiennent deviennent connectées sur le plan opérationnel plutôt que centralisées physiquement.

Parce que les deux ont des formes d'ingénierie fondamentalement différentes, et qu'une jointure doit toutes les réconcilier à la fois :

• Des modèles d'accès différents. Les données au repos se tirent par une requête qui renvoie un résultat fini. Les données temps réel se poussent sous forme de séquence non bornée d'événements. L'un est requête-réponse, l'autre est abonnement.
• Des notions de justesse différentes. Une requête historique est reproductible. Une jointure en streaming doit définir ce que « courant » signifie à chaque instant, et décider quoi faire des messages tardifs, désordonnés ou corrigés.
• Des enveloppes de performance différentes. Une requête d'entrepôt qui se mesure en secondes ne peut pas se placer sur le chemin d'un flux d'événements qui se mesure en microsecondes.
• L'état doit résider quelque part. Joindre un flux à des données de référence suppose de maintenir l'état courant en mémoire, de le garder juste alors que les deux côtés changent, et de le faire sans croissance non bornée.
• Les droits d'accès doivent couvrir les deux. Un utilisateur autorisé à voir les positions d'un desk ne doit voir que les événements vivants de ce desk, avec une application identique des deux côtés.

Résoudre cela dans chaque application produit des implémentations dupliquées et subtilement divergentes. 3forge le résout une fois dans le Center, où la base temps réel en mémoire, la base historique et le moteur de traitement d'événements complexes cohabitent dans le même runtime et peuvent être interrogés ensemble au sein d'un même datamodel.

Non. C'est le principe « laisser la donnée là où elle est ». Une donnée ne devrait pas être copiée simplement parce qu'une nouvelle application a besoin d'y accéder. Le maillage virtualise l'accès et présente les sources distribuées via des interfaces, politiques et contrôles opérationnels cohérents, tandis que les systèmes sources restent faisant autorité.

Le résultat n'est pas un nouveau référentiel central. C'est une couche d'exploitation commune au-dessus des référentiels, flux et systèmes que l'entreprise utilise déjà, dans laquelle les données temps réel et historiques restent physiquement réparties mais deviennent opérationnellement connectées.

3forge virtualise l'accès aux bases de données, flux, API et systèmes historiques pour que les équipes travaillent avec eux via une seule couche gouvernée. Les jeux de données temps réel et au repos peuvent être interrogés, joints, enrichis et opérationnalisés ensemble sans que chaque workflow reconstruise sa logique d'intégration.

La virtualisation seule ne suffit pas pour des charges opérationnelles : le maillage ajoute donc une couche fonctionnelle entre la source et le consommateur, avec mise en cache pour protéger les systèmes sous-jacents et réduire la latence, persistance pour l'analyse ultérieure, normalisation et enrichissement multi-sources, et filtrage, conflation ou règles métier appliqués aux événements vivants avant distribution.

La même information gouvernée peut être délivrée aux applications, aux agents IA, aux processus Python, aux API, aux rapports, aux tableaux de bord, aux PDF ou à Excel, sans créer un chemin d'intégration distinct pour chaque consommateur.

C'est important car les plateformes d'entreprise servent aujourd'hui une population de consommateurs bien plus large que des personnes lisant des rapports. Services, modèles, agents et workflows automatisés consomment les données en continu, chacun avec ses schémas d'accès et ses exigences de performance, et chacun qui construit sa propre intégration ajoute un jeu supplémentaire de connexions, de transformations et de contrôles d'accès à maintenir.

La gouvernance des données s'est traditionnellement concentrée sur les utilisateurs, les bases et les environnements de reporting : un accès accordé selon l'identité et le rôle, avec catalogues, outils de traçabilité et systèmes d'audit documentant comment l'information est stockée et utilisée. Ce modèle devient plus difficile à appliquer à mesure que le nombre et la variété des consommateurs augmentent. Les applications accèdent à plusieurs sources pour le compte d'un utilisateur. Les services tournent en continu sans interaction humaine directe. Les agents choisissent leurs outils dynamiquement, enchaînent des requêtes et produisent des sorties qui alimentent d'autres systèmes.

Robert Cooke, fondateur et CEO de 3forge, a décrit le risque directement : « there is now suddenly this lack of governance over how things are tested and around how things are being built, how things are connected. »

La gouvernance ne peut donc pas se limiter au contrôle d'accès au périmètre de chaque base. Elle doit couvrir tout le chemin par lequel la donnée est demandée, transformée, distribuée et utilisée, et elle doit être observable, afin que les équipes voient quels consommateurs utilisent quelles sources, comment la donnée circule dans les applications, où les politiques sont appliquées et quand les comportements changent. Ajoutée après coup, chaque nouveau consommateur devient une exception à gérer. Intégrée à la couche par laquelle la donnée est consultée, elle est héritée par tout ce qui se construit dessus.

Les agents et workflows automatisés consomment l'information plus fréquemment, combinent un éventail plus large de sources et peuvent déclencher des actions sans attendre qu'un utilisateur navigue dans une application. Parallèlement, le développement assisté par IA augmente le nombre d'applications, de services et d'interfaces qu'une entreprise doit gouverner et exploiter.

La plateforme doit donc savoir qui ou quoi émet une demande, à quelles informations cette entité peut accéder, quelles opérations elle peut effectuer, quelle charge elle peut imposer à une source et où ses sorties peuvent être envoyées. Ces politiques doivent s'appliquer de façon cohérente que le consommateur soit une personne, une application, un processus Python ou un agent. Un agent ne doit pas disposer d'une route parallèle contournant les contrôles établis pour les utilisateurs et les applications.

Non. Les entrepôts et les lacs sont des destinations : on y déplace la donnée puis on l'y interroge. Le Maillage de données temps réel est une couche d'accès et de traitement qui se place au-dessus des systèmes que l'institution exploite déjà, y compris son entrepôt ou son lac, lequel devient généralement une source gouvernée de plus.

Le maillage conserve bien des données lorsque cela sert un objectif opérationnel. Le Center garde l'état courant dans une base en mémoire et peut persister l'historique choisi dans sa propre base historique, et l'information fréquemment demandée peut être mise en cache pour protéger le système sous-jacent. Mais l'objectif n'est pas de devenir la copie de référence unique. Les grandes entreprises continueront d'utiliser des technologies différentes pour des charges différentes, et les systèmes sources doivent souvent rester faisant autorité.

Un moteur applicatif est un runtime partagé qui standardise l'infrastructure commune dont toute application sérieuse a besoin : connectivité, sécurité, gestion d'état, supervision et contrôle du cycle de vie. 3forge applique cette idée spécifiquement aux institutions financières. Plutôt que de reconstruire la même plomberie pour chaque outil de risque, moniteur opérationnel ou workflow de reporting, les équipes construisent sur un runtime natif de la finance qui comprend déjà le temps réel, le comportement déterministe, les droits d'accès et l'auditabilité.

Un moteur applicatif définit comment le logiciel s'exécute, et pas seulement comment il s'écrit. Il gère la circulation des données, l'ordonnancement des traitements, l'allocation des ressources, la gestion des pannes et le cycle de vie de l'application.

Les moteurs de jeu comme Unity et Unreal fournissent le rendu, la physique, l'animation, la gestion des entrées, le réseau, la gestion des assets et le déploiement sous forme de runtime partagé, afin que les développeurs se concentrent sur les mécaniques, le contenu et l'expérience qui différencient leur jeu. Le développement applicatif en entreprise présente la même structure récurrente : la plupart des applications opérationnelles ont besoin de connectivité, de gestion d'état, de concurrence, de traitement d'événements, d'authentification, de droits d'accès, de workflow, de visualisation, de reporting, de supervision et de déploiement.

3forge implémente ces préoccupations une seule fois, au niveau du moteur, et les applique de façon cohérente à toutes les applications construites dessus. À mesure que davantage d'applications adoptent le moteur, les connexions, contrôles, composants et pratiques opérationnelles sont réutilisés plutôt que recréés. C'est le principe du développement du dernier kilomètre : le moteur prend en charge ce qui est commun, les développeurs se concentrent sur ce qui doit être différent.

Lorsque les équipes construisent directement sur le maillage, l'Application Engine fournit environ 95 pour cent de la fondation technique requise : gestion d'état, traitement d'événements, permissions, formulaires, visualisations, reporting, tests, déploiement et supervision. Les développeurs se concentrent sur la logique métier et l'interaction.

Les applications construites sur le maillage utilisent les mêmes données, transformations, droits d'accès et logique de traitement sans créer de couche d'intégration supplémentaire, et elles entrent dans un runtime de production contrôlé où dépendances, activité et performance sont observables par conception.

Les organisations qui évaluent comment construire un logiciel financier rencontrent en général trois approches, chacune avec un arbitrage différent entre rapidité, flexibilité, contrôle et pérennité :

• Acheter une solution éditeur. Chemin le plus rapide vers une fonctionnalité initiale quand les besoins correspondent étroitement au produit. La personnalisation est souvent limitée, l'intégration peut être complexe et la feuille de route dépend de l'éditeur. À privilégier quand le workflow n'est pas un différenciateur.
• Construire en interne. Flexibilité et maîtrise maximales, mais l'équipe conçoit, construit et maintient chaque couche de la pile, ce qui augmente le coût, le risque de livraison et la charge opérationnelle. À privilégier pour le cœur différenciant du métier.
• S'appuyer sur un moteur applicatif. Un runtime partagé de niveau production, avec des primitives réutilisables adaptées au domaine, qui combine le contrôle du sur-mesure et l'effet de levier d'une plateforme. À privilégier pour servir le cœur de métier et porter le différenciateur.

Ces termes décrivent les grands domaines de capacités de l'Application Engine 3forge. Live Data désigne l'accès gouverné aux données temps réel et historiques ainsi que le traitement événementiel. Live User Interface désigne la couche front-end des tableaux de bord, formulaires, pivots et workflows. Live Workbench désigne l'environnement dans le navigateur pour construire, tester, diagnostiquer et exploiter les applications. Live Scripting désigne la couche de logique métier native du runtime, utilisée pour encoder calculs, transformations, callbacks et comportements applicatifs réutilisables.

LivePivots™ et Live Prompting étendent le même modèle à l'analyse pivot temps réel et à l'interaction en langage naturel.

Non. Les tableaux de bord sont une sortie visible de la plateforme, mais 3forge se comprend mieux comme un runtime applicatif. Il prend en charge l'intégration de données, le traitement d'événements, les workflows, le reporting, l'outillage opérationnel, l'accès gouverné aux données et des applications complètes destinées aux utilisateurs. Réduire 3forge à la visualisation sous-estime l'architecture et fait paraître la plateforme bien plus étroite qu'elle ne l'est.

Le Center peut déjà livrer des applications headless, côté serveur, qui fonctionnent au cœur du maillage sans aucune interface utilisateur : c'est de là que vient le nom maillage applicatif. Le Web Server ajoute la capacité de produire des interfaces temps réel au-dessus de ces flux.

Les plateformes d'entreprise se déploient rarement avec succès par la seule expertise technologique. Dans le modèle du forward-deployed engineering, des spécialistes plateforme 3forge travaillent directement avec les équipes métier et technologiques sur un cas d'usage opérationnel concret, apprennent de l'implémentation et adaptent la solution aux réalités de l'organisation.

Le premier cas d'usage remplit deux fonctions : il livre une application opérationnelle et il établit des connexions, modèles de données, contrôles, composants et pratiques réutilisables. L'objectif n'est pas une dépendance permanente à des ingénieurs externes, mais d'accélérer les premières implémentations et de transférer la connaissance aux équipes internes.

3forge formule les problèmes de données et d'applications comme quatre défis liés plutôt que comme quatre programmes distincts :

• Relier données temps réel et historiques. Rendre les données vivantes et au repos, réparties dans le patrimoine, disponibles via un modèle d'exploitation cohérent, sans imposer leur consolidation dans un référentiel unique.
• Construire des applications agentiques de niveau production. Fournir les capacités techniques récurrentes au niveau de la plateforme pour que les prototypes assistés par IA deviennent des logiciels gouvernés et exploitables en production.
• Gouverner les données à l'échelle de l'entreprise. Étendre droits d'accès, traçabilité, application des politiques et audit à l'ensemble du chemin par lequel la donnée est demandée, transformée, distribuée et utilisée, pour les personnes, les services et les agents.
• Connecter données, logique et exécution. Réduire les transferts fragiles entre observation, décision et action pour qu'un signal puisse être détecté, évalué, approuvé et traité dans un même flux opérationnel.

AmiCore est le conteneur d'exécution gouverné au cœur de l'architecture 3forge. Il fournit l'environnement commun dans lequel les composants 3forge sont configurés, exécutés, supervisés et gouvernés, et applique des contrôles transverses à l'accès aux données, à la logique métier, à l'interaction utilisateur et aux interfaces externes.

Chaque instance AmiCore inclut des services dans trois domaines : le contrôle du runtime (déploiement, configuration, gestion des ressources, orchestration, supervision de santé, instrumentation), la sécurité et la gouvernance (connexion et authentification, accès par rôles, audit, gestion du système de fichiers, gestion des ports, contrôle des plugins) et l'accès et l'interopérabilité (accès natif aux données ainsi qu'interfaces REST, MCP et JDBC).

Non. AmiCore ne remplace ni un conteneur Docker, ni une machine virtuelle, ni un pod Kubernetes. AmiCore s'exécute à l'intérieur de la machine virtuelle Java, laquelle peut elle-même tourner directement sur un système d'exploitation ou être empaquetée dans une image Docker et gérée par Kubernetes ou une autre plateforme d'infrastructure.

La distinction est importante : l'infrastructure externe contrôle où le processus s'exécute et quelles ressources physiques lui sont disponibles, tandis qu'AmiCore contrôle la façon dont le maillage applicatif fonctionne à l'intérieur de ce processus. C'est ce qui étend la gouvernance au-delà du déploiement, jusque dans le runtime lui-même.

Des composants spécialisés s'exécutent dans le conteneur AmiCore :

• Relay. Couche d'intégration et de transport à la frontière avec les systèmes externes.
• Center. Composant principal de traitement des données et des événements, hébergeant la base temps réel, la base historique et le moteur de traitement d'événements complexes.
• Gateway. Couche de distribution gouvernée présentant un parc de Centers distribués derrière une interface logique unique.
• Web Server. Runtime applicatif pour l'interaction utilisateur, les workflows, le reporting et l'exécution.
• Web Manager. Stockage centralisé des layouts applicatifs, profils utilisateurs et préférences pour plusieurs Web Servers.
• Web Balancer. Point d'entrée conscient de la plateforme, qui répartit les sessions utilisateurs entre les Web Servers.

Operations Hub fournit ensuite la vue à l'échelle du parc sur toutes les instances déployées.

Le Relay se situe à la frontière entre 3forge et les systèmes externes. Il fait entrer les données et les requêtes dans le maillage et renvoie commandes ou informations traitées vers des destinations externes, en se connectant aux flux temps réel, systèmes de messagerie, bases de données, fichiers et applications locales via des feed handlers et des adaptateurs.

À l'arrivée des informations, le Relay peut les analyser, les valider et les transformer avant de les router vers un ou plusieurs Centers. Des règles de routage déterminent quels messages vont vers quels Centers, répliquent certains flux vers plusieurs destinations ou écartent les messages ne répondant pas aux critères définis. Le Relay fournit aussi la messagerie garantie et le store-and-forward pour les charges qui ne tolèrent aucune perte de données en cas d'interruption.

Le Center est le composant principal de traitement des données et des événements du maillage applicatif. Il consomme les informations vivantes provenant des Relays et d'autres composants, puis représente l'état courant de ces informations dans une base SQL en mémoire, afin que les applications interrogent des données en évolution continue via un modèle structuré.

À côté de la base temps réel, le Center fournit une base historique conçue pour de très grands volumes sur disque, de sorte que l'état courant et l'historique long terme participent au même maillage. Le Center inclut également un moteur de traitement d'événements complexes dans lequel des triggers natifs de la base agrègent, filtrent, joignent, enrichissent et transforment l'information au fil des changements des tables sources.

Le Gateway est la couche de distribution gouvernée. À mesure que le maillage s'étend sur plusieurs Centers, les applications, agents et intégrations externes se connectent à une interface Gateway unique pour interroger les données, s'abonner aux flux et invoquer des procédures, sans avoir à connaître la topologie physique.

Le Gateway peut présenter plusieurs tables sous-jacentes comme une seule table virtuelle, plusieurs flux shardés comme un seul abonnement et des procédures distribuées comme un service unique appelable, ce qui permet un map/reduce de requêtes sur un maillage distribuée. Il met aussi en cache les résultats de requêtes courantes et les instantanés d'état, consolide les abonnements qui se recouvrent puis les redistribue, et permet d'ajouter ou retirer des Centers sans redémarrage. Transport sécurisé, compatibilité d'authentification, accès par rôles et journaux d'accès s'appliquent au niveau de l'interface.

Le Web Server 3forge est l'endroit où données et logique deviennent une application opérationnelle. Il connecte les utilisateurs aux informations temps réel et historiques via des tables, formulaires, arbres, graphiques, cartes, pivots et autres composants interactifs, capables d'accepter des saisies, d'invoquer de la logique côté serveur et de déclencher des actions contrôlées.

Parce que le Web Server fait partie du même runtime que les couches de données et de traitement, l'interface reste étroitement connectée à l'état applicatif, les mises à jour vivantes sont envoyées directement au navigateur, et les droits d'accès déterminent ce que chaque utilisateur peut voir et faire. Le même modèle produit aussi des rapports PDF et e-mail planifiés ou déclenchés par événement, à partir des layouts et de la logique déjà utilisés par l'application vivante.

Le Web Manager centralise les layouts applicatifs, les profils utilisateurs et les préférences, puis fournit les bonnes informations au Web Server qui traite une session donnée. Un utilisateur ne reçoit donc pas des réglages de tableau de bord différents parce que sa session a été routée vers un autre serveur, et les équipes applicatives ne synchronisent pas manuellement les fichiers de layout sur chaque instance Web.

Le Web Balancer répartit les utilisateurs entre plusieurs Web Servers, en fournissant un point d'entrée conscient de la plateforme, ce qui évite que chaque application implémente sa propre logique de répartition. Ensemble, ils permettent à la couche Web de servir des milliers d'utilisateurs simultanés sans faire de chaque Web Server un environnement administré séparément.

Non. AmiCore fournit un runtime commun mais n'impose pas une topologie de déploiement unique. Pour un cas d'usage réduit, plusieurs composants peuvent tourner ensemble dans une seule JVM, ce qui réduit le nombre de processus à configurer et offre un chemin direct de l'intégration au traitement puis à la présentation.

Quand les charges augmentent, les composants peuvent être séparés par fonction : Relays placés près des sources, Centers distribués pour la capacité de traitement ou la résilience, Web Servers ajoutés pour plus d'utilisateurs simultanés. Les composants peuvent aussi être répartis par domaine métier, géographie, frontière de sécurité ou environnement. Le résultat n'est ni un monolithe classique ni une collection de microservices sans lien, mais un runtime componentisé, composé selon les besoins du parc applicatif.

Oui. AmiCore prend en charge un modèle de plugins permettant aux institutions d'ajouter des intégrations approuvées ou des capacités spécialisées via des points d'extension contrôlés. Le runtime s'adapte ainsi aux exigences locales sans transformer chaque extension en modification du cœur de la plateforme.

Le conteneur remplit donc deux rôles : il fournit les services natifs requis par la plateforme et il établit la frontière contrôlée à l'intérieur de laquelle la plateforme peut être étendue. La gestion des plugins est elle-même l'un des services gouvernés du conteneur.

La base historique 3forge (HDB) fournit des tables historiques en colonnes capables de contenir des milliers de milliards de lignes, persistées sur disque, avec partitionnement, et interrogeables avec la même syntaxe SQL que les tables temps réel. La capacité publiée dépasse 10 000 milliards de lignes et 1 000 colonnes.

La HDB prend en charge de grands nombres de colonnes et des types lourds comme les champs blob, une gestion de schéma qui ajoute, supprime ou modifie des colonnes sans impacter les partitions historiques, des clauses UPDATE et DELETE au niveau ligne préservant l'optimisation des partitions, et l'archivage des données temps réel depuis les flux via des approches événementielles, par lots ou par timer. Les données historiques peuvent aussi être chargées dans une table temps réel pour bénéficier de toute l'étendue des optimisations de requête, jointures comprises.

Le type de stockage est configurable colonne par colonne, et le système adapte dynamiquement les types de stockage lors de l'optimisation, partition par partition, en fonction de l'usage réel des données :

• FLAT. Types de longueur fixe comme INT, FLOAT et DOUBLE.
• VARSIZE. Types de longueur variable comme STRING et BINARY, jusqu'à 1 To.
• BITMAP. Efficace pour les chaînes à faible cardinalité.
• PARTITION. Organise les lignes en partitions isolées.

Les colonnes de partitionnement sont immuables : la conception du schéma mérite donc une planification soignée en amont. La HDB associe les anciennes partitions aux nouveaux schémas de façon transparente, en préservant l'intégrité de l'historique.

Le Center fournit des triggers natifs de la base pour exécuter la logique métier à la volée au fil des mises à jour. Combinés à la conflation, ces triggers ne traitent que le travail nécessaire. Les types suivants sont disponibles nativement :

• Aggregation pour créer et mettre à jour des tables d'agrégation.
• Projection pour des tables filtrées.
• Join pour créer des tables jointes.
• Decorate pour enrichir les données à partir d'une autre table.
• Relay pour envoyer des messages via le Relay 3forge.
• AmiScript pour exécuter des scripts personnalisés à chaque insertion, mise à jour ou suppression.

Les Centers utilisent plusieurs techniques pour concilier vitesse de transmission et contraintes techniques :

• Traitement par delta. Seules les modifications sont traitées, plutôt que de retraiter ou retransmettre l'ensemble du jeu de données à chaque mise à jour.
• Conflation. Lors de la réplication à travers l'architecture en niveaux, les Centers peuvent envoyer chaque mise à jour ou seulement la dernière à un intervalle convenu, écartant les valeurs intermédiaires et réduisant la charge en aval.
• Résumé. Des métriques de synthèse régulières ou basées sur les deltas, comme moyennes, sommes, comptages, minimums et maximums, compressent les volumes et alimentent l'analyse temporelle.
• Décoration. Des triggers événementiels enrichissent, valident et propagent les données en réponse aux changements au niveau des tables.

3forge prend en charge les principaux environnements d'entreprise sous Windows, Linux, plateformes Apple et Android. La prise en charge navigateur inclut Chrome, Firefox, Edge et Safari. La plateforme supporte également Docker et Kubernetes, différents fournisseurs cloud, les systèmes de gestion de sources courants et les environnements de conteneurs de bureau utilisés sur les postes financiers. Côté connectivité, 3forge prend en charge un large ensemble de bases de données, d'API, de systèmes de messagerie et de feed handlers.

Le pilote ODBC 3forge et le serveur RTD pour Excel sont actuellement conçus pour des clients Windows 64 bits.

3forge est livré avec plus de 35 adaptateurs de bases de données et 15 adaptateurs de flux, ce qui lui permet de consommer des données temps réel et au repos depuis pratiquement n'importe quelle source et de les présenter comme un point d'accès unique aux consommateurs. Les Centers et les Relays peuvent tous deux se connecter directement aux bases de données ; les Relays sont en outre conçus pour se connecter aux flux temps réel.

Une fois dans 3forge, les données peuvent être interrogées via l'API REST, JDBC, ODBC et MCP, ainsi que par des bibliothèques bidirectionnelles en .NET, Python, Java, WebSockets et gRPC.

Les adaptateurs de bases de données disponibles pour les Centers et les Relays incluent :

• Relationnel et entrepôts. Oracle, Microsoft SQL Server, MySQL, PostgreSQL, Sybase, SybaseIQ, IBM DB2, Snowflake, Greenplum, HP Vertica, Netezza, Impala, Hive, SQLite, MemSQL, SingleStore, Phoenix.
• NoSQL, cache et en mémoire. MongoDB, Couchbase, Redis, Apache Ignite, Hazelcast, HBase, Chronicle Queue.
• Analytique et spécialisé. KX, Apache Spark, Hadoop, Deephaven, Symphony, R, Fred, Quandl, Bloomberg.
• Fichiers et services. AMI DB, fichier plat, AMI Shell, Excel, API REST.

Des adaptateurs sur mesure peuvent être implémentés via l'API de plugins Java publiée.

Les feed handlers disponibles pour les Relays incluent Kafka, Solace, Tibco, RabbitMQ, ActiveMQ, IBM MQ, Amazon SQS, Aeron, 60East AMPS, Chronicle Queue, KX Stream, gRPC et FIX. Les flux de données de marché incluent Bloomberg BPIPE, QuantHouse et OneTick.

Comme le Relay analyse, valide et transforme les messages à la frontière d'intégration, la logique propre à chaque source n'a pas à être réimplémentée en aval.

Les Centers, Relays et Gateways exposent un ensemble commun de bibliothèques d'accès programmatique : API REST, JDBC, ODBC, .NET, Python, Java, WebSockets, gRPC et MCP.

Fournir ces interfaces au sein du runtime crée une cohérence entre elles. Un consommateur ne devrait pas bénéficier d'une gouvernance fondamentalement différente simplement parce qu'il se connecte via JDBC plutôt que REST, ou parce qu'une action est initiée par un agent plutôt que par un utilisateur.

Oui. 3forge est livré avec des intégrations Bloomberg dédiées : BPIPE pour les abonnements aux données de marché temps réel (introduit à l'été 2024) et l'adaptateur Bloomberg Datasource pour l'accès aux données historiques et de référence (introduit à l'automne 2024). Les deux sont pris en charge nativement en tant que clients Bloomberg licenciés.

Oui. 3forge est pleinement conforme au standard FDC3 2.0 pour l'interopérabilité entre applications financières, et est couramment déployé sur des navigateurs d'entreprise et conteneurs de bureau comme Here (anciennement OpenFin) et Interop.io. Les callbacks Finsemble ont été ajoutés dans la version Été 2023.

C'est important pour les firmes qui ont besoin que les applications 3forge participent à des workflows de bureau plus larges via le partage de contexte et la gestion d'intents, plutôt que de fonctionner isolément.

Oui. 3forge prend en charge gRPC pour connecter des microservices (ajouté au printemps 2025) et expose un serveur d'API REST qui rend les données de base et les informations de supervision accessibles à des systèmes externes. Des appels REST sortants peuvent aussi être effectués depuis AmiScript pour des intégrations événementielles, et le Relay peut invoquer des processus locaux ou envoyer des commandes à des applications en aval.

Les besoins minimaux varient selon la charge. Une instance de développement fonctionne confortablement sur un portable moderne doté de 16 Go de RAM. Les déploiements de production dans les banques de premier rang tournent couramment sur des serveurs à forte mémoire (256 Go à 1 To de RAM) pour accueillir de grands jeux de données en mémoire.

3forge étant un système basé sur la JVM, le dimensionnement du heap, le réglage du GC et le nombre de cœurs CPU sont les principaux leviers de performance. Notre équipe d'ingénierie solutions vous conseille sur le dimensionnement lors de l'intégration.

Oui, dans les trois cas. 3forge est conçu pour être déployé sur site, en cloud et en environnement hybride, tout en s'insérant dans les pratiques opérationnelles existantes. Les composants peuvent être distribués, dimensionnés et configurés selon les exigences de charge, de résilience, de sécurité et de géographie.

Les firmes peuvent ainsi démarrer par un déploiement ciblé et étendre le maillage à mesure que d'autres applications, sources de données et utilisateurs rejoignent la plateforme, plutôt que de s'engager dès le premier jour sur une architecture couvrant tout le patrimoine.

Oui. 3forge est distribué sous forme d'image Docker et est pleinement compatible avec l'orchestration Kubernetes. Cela inclut l'autoscaling horizontal des pods, les limites de ressources, les volumes persistants pour la base historique 3forge et l'intégration à la gestion des secrets au niveau du cluster pour les identifiants.

Operations Hub ne remplace ni Kubernetes ni l'automatisation de déploiement. Il fournit l'inventaire orienté application et les preuves nécessaires pour gouverner ces processus.

Un environnement 3forge de base peut être mis en place en quelques heures. La plupart des clients disposent d'un prototype fonctionnel intégré à leurs sources internes en quelques jours à quelques semaines, selon la complexité du pipeline de données. Les déploiements complets en production, incluant l'intégration sécurité, les workflows SDLC et la recette utilisateur, s'achèvent généralement en quelques semaines.

Les ingénieurs solutions 3forge accompagnent l'implémentation tout au long du processus.

Le meilleur point de départ est une démonstration de 30 minutes avec un ingénieur solutions 3forge. Nous adaptons l'échange à vos cas d'usage, à votre environnement de données et à la structure de vos équipes, afin que vous puissiez évaluer rapidement l'adéquation et avancer vers une preuve de concept sur votre propre infrastructure.

Utilisez le bouton « Nous contacter » sur n'importe quelle page, ou écrivez-nous directement via notre page contact.

LivePivots™ est l'approche 3forge qui fait du pivot une capacité opérationnelle vivante plutôt qu'un exercice statique de tableur. Les utilisateurs découpent de grands jeux de données en catégories dynamiques sur des centaines de colonnes et des millions de lignes, appliquent filtres et permissions, et travaillent sur des données temps réel et historiques dans une même interface gouvernée.

Le point clé n'est pas seulement que les utilisateurs puissent pivoter les données, mais qu'ils puissent le faire à grande échelle, avec les droits d'accès, et à l'intérieur de workflows vivants où le pivot se met à jour dynamiquement.

La messagerie garantie dans 3forge assure que chaque mise à jour critique est persistée durablement et délivrée de façon fiable, quelles que soient la charge du système et les conditions réseau transitoires. Les messages sont journalisés dans un write-ahead log (WAL), ce qui permet aux Centers en aval, y compris ceux temporairement hors ligne, de récupérer et rejouer les données manquées à la reconnexion.

La messagerie garantie n'effectue pas de suppression des doublons et ne doit pas être décrite comme une livraison exactement-une-fois. Elle apporte la durabilité et la continuité requises par les systèmes de trading, de risque et de conformité temps réel. Cette précision compte, car les acheteurs techniques repèrent les promesses excessives.

Les Relays 3forge prennent en charge des règles de routage dynamiques qui dispatchent les messages vers des Centers de traitement spécialisés selon le contenu, la charge ou une logique personnalisée, le tout configurable en temps réel. Chaque Center traite indépendamment sa portion de charge avant que les résultats soient fusionnés par une opération de map-reduce.

Cette architecture permet le traitement parallèle et l'agrégation haute performance sur des systèmes distribués. C'est l'un des mécanismes par lesquels un déploiement 3forge évolue horizontalement sans refonte de l'application.

Oui. 3forge inclut des capacités de transformation de messages permettant d'inspecter, modifier, enrichir ou filtrer les messages en vol sans écrire de code personnalisé, à l'aide de règles déclaratives et de scripts.

C'est particulièrement utile pour FIX et d'autres protocoles financiers, où des ajustements dynamiques peuvent être nécessaires pour prendre en charge différentes contreparties, normaliser des formats, masquer des champs sensibles ou router selon le contenu.

3forge assure la réplication des données entre une base Center primaire et une base de secours à chaud via une configuration simple. Le nœud de secours surveille la santé du primaire et peut prendre le relais en cas de panne, avec toutes les données déjà chargées en mémoire.

La réplication peut aussi servir à répartir la charge entre plusieurs Centers selon des règles de routage définies dans le Relay, augmentant à la fois la redondance et la scalabilité. L'architecture permet des déploiements plus avancés, y compris multi-régions et mondiaux.

Oui. 3forge produit des rapports PDF et e-mail automatisés à partir du même modèle de layout vivant et de la même logique que l'interface utilisateur : il n'y a donc pas de produit de reporting séparé ni de logique de présentation dupliquée.

Les rapports peuvent être adaptés à chaque destinataire et inclure graphiques, tableaux, heatmaps, grilles pivot et tables d'agrégation. Contenu, mise en forme, signatures et règles de distribution peuvent varier par rôle ou par workflow, ce qui convient aux revues de performance de trading, analyses de risque, documents clients et pièces réglementaires.

Le paquet pyami-3forge fournit une interface dédiée entre Python et le maillage applicatif. Il permet aux processus Python d'interroger les données courantes et historiques, de s'abonner aux mises à jour vivantes des Centers, de publier des informations dans le maillage et d'interagir avec les services AMI autorisés, sans se connecter indépendamment à chaque source sous-jacente.

L'accès étant médiatisé par le maillage, il peut être associé à une identité de charge de travail plutôt qu'à des identifiants personnels intégrés dans un notebook. L'activité Python peut ainsi être attribuée, restreinte aux données autorisées et incluse dans la vue opérationnelle et d'audit de la plateforme.

• Client temps réel. Pour les requêtes, la publication, les abonnements aux Centers et les mises à jour incrémentales.
• Python DB-API 2.0. Pour les applications bâties sur le modèle standard PEP 249 de connexions et curseurs, avec requêtes paramétrées, opérations par lots et procédures stockées.
• Dialecte SQLAlchemy. Pour SQLAlchemy Core et ORM, la réflexion de schéma et l'intégration pandas.
• Client JDBC pur Python. Pour un accès léger requête vers DataFrame quand l'extension native temps réel n'est pas nécessaire.

Le choix de l'interface ne change pas le modèle d'exploitation sous-jacent. Python atteint toujours les données via AMI plutôt qu'en établissant des connexions indépendantes vers chaque base, flux ou entrepôt.

Oui. Le client temps réel peut s'abonner à une ou plusieurs tables de Center. L'abonnement commence par l'instantané courant, puis délivre les ajouts, mises à jour et suppressions de lignes sous forme d'événements incrémentaux, de sorte que le code Python réagit aux changements sans interroger le serveur en boucle ni rejouer une requête entière.

Requêtes et abonnements peuvent être combinés : un processus peut charger un jeu de données historique ou de référence via SQL, puis maintenir la partie courante de son état via les mises à jour vivantes du Center. Le client temps réel prend aussi en charge le SQL asynchrone, pour soumettre une requête longue sans bloquer le flux principal.

Les workflows Python démarrent souvent dans des notebooks Jupyter qui dépendent de fichiers locaux, d'identifiants personnels, de données copiées ou d'un accès direct à un système source. Passer ce travail en production impose habituellement de reconstruire sa connectivité, ses permissions, sa supervision et son modèle d'exploitation.

Le paquet Python 3forge fournit la même interface de maillage dans les environnements exploratoires et opérationnels : un développeur peut commencer dans Jupyter puis réutiliser le même modèle d'accès dans un script planifié, un pipeline analytique, un workflow IA ou un service durable. Le code Python autour doit toujours être testé et fiabilisé, mais sa connexion aux données d'entreprise n'a pas à être remplacée.

3forge prend en charge Excel par deux voies complémentaires. Le pilote ODBC permet à Excel d'interroger le maillage via Power Query comme s'il s'agissait d'une base relationnelle classique, en parcourant les tables puis en chargeant ou transformant les données avant leur entrée dans le classeur. Le serveur RTD 3forge utilise la fonction Real-Time Data native d'Excel pour abonner des cellules individuelles à des champs publiés par un Center : les valeurs se mettent à jour automatiquement à mesure que le Center envoie des mises à jour incrémentales.

Les utilisateurs conservent ainsi les applications et méthodes de travail adaptées à leur rôle, tandis que l'accès aux données reste rattaché à un environnement AMI unique et administré.

Chaque formule identifie un cluster AMI et un champ précis d'un objet dans une table AMI :

• =RTD("AmiRtd.Server", , "<cluster>", "<table>.<object_id>.<field>")
• =RTD("AmiRtd.Server",,"N1","Trades.AAPL.price")
• =RTD("AmiRtd.Server",,"N1","Trades.AAPL.volume")

Tant que la première mise à jour correspondante n'est pas arrivée, la cellule affiche #N/A, puis montre la dernière valeur et continue de se rafraîchir au fil des publications du Center. Les cellules qui observent la même table partagent un abonnement Center à comptage de références, et celles qui demandent le même sujet partagent une valeur en cache : un classeur peut donc contenir de nombreuses formules vivantes sans créer d'abonnements amont redondants.

ODBC et RTD répondent à des schémas de consommation différents, et beaucoup de déploiements Excel utilisent les deux :

• ODBC suit un modèle requête-réponse adapté aux jeux de résultats : parcourir des tables, exécuter des requêtes SQL, récupérer des enregistrements historiques ou courants, et rafraîchir à la demande. Exemples : positions, données de référence, historique.
• RTD suit un modèle d'abonnement adapté à quelques valeurs vivantes mises à jour en continu. Exemples : prix, statuts, limites.

Un classeur peut utiliser ODBC pour récupérer une table de travail volumineuse, puis RTD pour actualiser en continu certains prix ou indicateurs opérationnels, les formules Excel combinant les deux.

Le pilote ODBC 3forge présente les tables AMI via l'interface ODBC standard de Windows : Excel, Tableau, Power BI, LibreOffice Base, Python via pyodbc, PowerShell et les applications écrites avec l'API ODBC C ou C++ peuvent donc interroger le maillage comme s'ils se connectaient à une base relationnelle classique.

Une institution peut ainsi exposer une seule surface de requête administrée au lieu de construire un connecteur par produit analytique ou de reporting. Le pilote est destiné avant tout à un usage de requête et d'analyse : il fonctionne en autocommit et ne prend pas en charge les frontières transactionnelles par commit ou rollback.

Les connexions ODBC peuvent utiliser SSL/TLS, avec TLS mutuel obligatoire lorsque des listeners AMI JDBC sécurisés sont employés. Le client présente son certificat au serveur, et le serveur peut aussi être épinglé par sa clé publique. Les connexions peuvent inclure une liste ordonnée de points de bascule, et la bibliothèque cliente réessaie avec un backoff contrôlé si le serveur AMI primaire est indisponible. Le serveur RTD utilise le même modèle de TLS mutuel.

Les deux interfaces sont actuellement conçues pour des clients Windows 64 bits. Le pilote ODBC est fourni sous forme d'installeur machine qui l'enregistre auprès du gestionnaire de pilotes ODBC de Windows et requiert des droits administrateur. Le serveur RTD pour Excel est fourni sous forme d'installeur par utilisateur, qui enregistre le composant COM pour l'utilisateur courant et ne requiert pas de droits administrateur.

AmiScript est le langage de programmation natif du maillage applicatif. Il offre un modèle unique pour travailler à la fois sur les données, la logique, les workflows et la présentation, en combinant des concepts familiers issus de Java, Python, SQL et des templates de chaînes, tout en ajoutant des fonctions et types de données pensés pour les systèmes financiers.

Comme le langage opère à travers toute le maillage, la logique n'a pas à être réécrite quand elle passe d'une couche à l'autre. Un calcul peut débuter dans le modèle de données, être réutilisé dans un workflow et apparaître directement dans une interface ou un rapport, et la même logique peut être appelée par une application externe ou un agent IA via une interface autorisée.

AmiScript inclut plus de 1 500 fonctions natives organisées en bibliothèques par domaine, afin d'assembler des workflows élaborés sans réimplémenter les primitives courantes. Les catégories incluent :

• Mathématiques, trigonométrie, arrondis, opérations binaires et encodage
• Dates, heures et horodatage, y compris timestamps à la nanoseconde
• Statistiques, moyennes, percentiles, clustering et rééchantillonnage
• Mesures financières comme le bêta et la variation en pourcentage
• Manipulation de chaînes, formatage, parsing (dont JSON et XLSX) et concaténation
• Signature cryptographique, colorimétrie, aléatoire et gestion d'URL
• Fonctions opérationnelles comme la journalisation et le contrôle de session

AmiScript adopte une syntaxe inspirée de Python pour définir maps, listes et structures imbriquées : des objets financiers complexes comme des instantanés de marché, des échelles de prix, des buckets de risque ou des objets de configuration s'expriment en ligne, sans définitions de classes verbeuses ni schémas externes. JSON est bien pris en charge dans tout l'Application Engine.

Comme ces structures sont des citoyens de première classe du langage, elles peuvent être passées directement à des calculs, composants visuels ou couches de persistance sans transformation. La même structure peut alimenter une logique de pricing, remplir une table ou piloter un graphique, ce qui élimine le code de liaison entre modélisation et exécution.

Oui. AmiScript prend en charge des définitions de fonctions fortement typées et surchargeables qui encapsulent la logique métier de façon déterministe. Les fonctions se définissent une fois et se réutilisent dans les scripts, requêtes, modèles et visuels, garantissant la cohérence des calculs financiers critiques dans tout le système.

C'est essentiel en finance, où notionnel, exposition, marge ou PnL doivent être calculés à l'identique dans les workflows de risque, de trading, de reporting et de conformité. Comme les fonctions s'exécutent dans le runtime gouverné, elles sont observables, auditables et soumises aux mêmes contrôles que le reste du système.

AmiScript s'intègre étroitement à AmiSQL : les développeurs exécutent des requêtes paramétrées sur des sources nommées avec des constructions SQL familières, tout en restant dans le cadre des droits d'accès, de l'audit et de la traçabilité. Des marqueurs comme ${USERACCOUNT} sont résolus à l'exécution, ce qui permet à un même script de s'adapter automatiquement à différents utilisateurs ou sessions sans identifiants codés en dur.

Comme l'accès aux données est intégré à la couche de script, il n'y a pas de séparation artificielle entre interroger la donnée et opérer dessus. Les résultats sont immédiatement réutilisables pour le calcul, la visualisation ou la persistance, et les valeurs calculées peuvent être insérées dans des tables, graphiques, info-bulles, tableaux de bord et rapports via le templating intégré.

La maîtrise de SQL aide, mais n'est pas indispensable pour toutes les tâches. 3forge utilise un langage de requête proche de SQL pour les datamodels, et les développeurs à l'aise avec SQL s'y retrouveront. Le Data Modeler offre un espace de travail visuel qui abstrait une grande partie de la construction des requêtes, abaissant la barrière pour les équipes moins familières des langages de requête.

Pour le traitement d'événements complexes, les jointures et les agrégations en streaming, une meilleure compréhension de SQL améliorera la vitesse de développement et la qualité des résultats.

Oui. 3forge s'intègre aux IDE courants comme Visual Studio Code via des plugins dédiés : les développeurs travaillent sur les projets de maillage aux côtés du code source, des dépôts, des outils de test et des processus de revue déjà utilisés par leurs équipes.

La communication entre l'IDE et le maillage s'appuie sur Model Context Protocol. Via cette interface, l'environnement de développement inspecte les capacités exposées par le runtime, récupère du contexte comme les schémas, procédures et objets d'exécution, et invoque les fonctions de développement autorisées. Les mêmes outils gouvernés sont disponibles que le changement suivant soit écrit à la main ou suggéré par un assistant IA.

Non. Les layouts 3forge se construisent et s'exécutent dans une fenêtre de navigateur, et les ingénieurs passent du mode Utilisateur au mode Éditeur avec une seule touche de contrôle. Il n'y a ni exécutable à compiler, ni publication vers le back-end, ni rafraîchissement du front-end, ni déploiement logiciel. Les ingénieurs voient l'effet de leurs changements immédiatement, dans la fenêtre même où ils développent.

Les changements exploratoires peuvent rester transitoires jusqu'à enregistrement explicite, ce qui favorise l'itération rapide sans modifier immédiatement le layout stocké.

• Panneaux imbriqués avec composants de navigation, onglets horizontaux et verticaux, et plusieurs niveaux d'imbrication.
• Séparateurs magnétiques pour un contrôle précis de l'agencement, et panneaux transitoires pour les vues contextuelles et les pop-ups.
• HTML dynamique pour une présentation sur mesure et une interactivité riche.
• Graphiques avancés combinant barres, nuages de points, lignes, aires, cartes, tendances, heatmaps, canvas, graphiques radiaux et 3D, mis à jour en temps réel.
• Tables d'agrégation avec groupes de colonnes, filtres avancés et édition au niveau cellule.
• Tables pivot temps réel sur des centaines de colonnes et des millions de lignes, et tables arborescentes temps réel avec hiérarchies et formules personnalisables.
• Thèmes et styles dynamiques incluant clair, sombre, contraste élevé et palettes aux couleurs de la marque, modifiables à la volée.

Les visualisations courantes incluent barres groupées, courbes multiples, tables transposées, tables pivot, tables CRUD, filtres en fil d'Ariane, heat maps, graphiques 3D, graphiques en aires et diagrammes de Sankey.

3forge prend en charge la conformité ADA via la navigation au clavier dans des tableaux de bord complexes, le filtrage de colonnes au clavier pour les tables et arbres, et le support du scripting pour la navigation entre panneaux et la gestion du focus. Les layouts prennent aussi en charge les thèmes à contraste élevé.

Les layouts sont pleinement responsives et fonctionnent sur mobile. Comme 3forge est fortement optimisé pour réduire les volumes transmis, il délivre de grands jeux de données aux navigateurs mobiles en temps réel : les dirigeants suivent leurs indicateurs clés, leur exposition au risque et reçoivent des alertes depuis une interface mobile dans le navigateur.

Oui. Les développeurs peuvent créer des composants entièrement sur mesure avec AmiScript et le framework de formulaires de la plateforme. Des composants web personnalisés peuvent aussi être intégrés via la prise en charge des panneaux externes. Pour les équipes ayant des besoins de visualisation spécifiques, comme des graphiques sur mesure ou des éléments d'interface de trading spécialisés, la plateforme fournit les points d'accroche nécessaires à l'intégration de bibliothèques tierces ou de composants propriétaires.

Oui. 3forge dispose d'une intégration native de gestion de sources (introduite à l'hiver 2020) permettant le versionnement des layouts, datamodels et scripts. Elle s'intègre aux workflows basés sur Git et prend en charge les pratiques SDLC standard : branches, fusions et revue de code.

La plateforme prend aussi en charge des hooks SDLC permettant d'imposer des politiques de promotion, du développement à la recette puis à la production, sans quitter l'environnement 3forge.

Oui, le développement concurrent sur un même layout est pris en charge depuis la version Printemps 2025. Le Merge Tool intégré permet à plusieurs développeurs de modifier indépendamment puis de réconcilier les différences avant promotion, d'une manière qui comprend la hiérarchie des layouts AMI plutôt que de traiter le layout comme du XML ou de la configuration brute.

Le développement se déroule dans un environnement navigateur qui réunit modélisation des données, analyse de requêtes, développement AmiScript, construction de layouts, débogage et inspection opérationnelle. Les équipes définissent leurs modèles de données, construisent tableaux de bord et workflows, écrivent la logique métier, créent des traitements événementiels et gèrent les changements sous gestion de sources depuis un seul environnement.

Comme le runtime et l'environnement de développement sont le même système, un changement peut être écrit, exécuté et observé dans des conditions réelles sans cycle de compilation, publication et redéploiement. L'objectif n'est pas seulement de construire des interfaces plus vite, mais de livrer des applications de bout en bout plus vite.

Les datamodels conviennent généralement mieux au façonnage de données par utilisateur et piloté par requête, tandis que les tables temps réel conviennent mieux à un état partagé, piloté par deltas, entre de nombreux utilisateurs. Cette distinction compte pour l'échelle et l'architecture. Les équipes devraient éviter d'utiliser des modèles par utilisateur pour un état chaud partagé globalement lorsqu'une table temps réel serait plus appropriée.

Le Workbench est un IDE dans le navigateur, inclus dans le runtime gouverné AmiCore. Il donne un accès immédiat aux données, composants et logiques disponibles dans l'environnement courant, dans la limite des droits de l'utilisateur : les développeurs explorent les données, exécutent des requêtes, inspectent les objets applicatifs, testent la logique et déboguent sans avoir à reproduire l'environnement ailleurs.

Parce qu'il fonctionne à l'intérieur du runtime, le Workbench expose des informations difficiles à reproduire dans un éditeur externe : l'état vivant, le déroulement de l'exécution, les valeurs et la façon dont une procédure interagit avec l'application environnante. Il est particulièrement utile en début de développement, lors d'une investigation opérationnelle et pour le travail collaboratif avec des spécialistes métier.

Non. Le Workbench ne remplace ni la gestion de sources ni le cycle de développement logiciel de l'institution. Il apporte une couverture immédiate de la plateforme, tandis que les IDE externes soutiennent le processus d'ingénierie plus large, aux côtés des dépôts, outils de test et workflows de revue.

Le Workbench prend également en charge les workflows d'intégration continue, une cohérence multiplateforme sur les navigateurs modernes et une production responsive indépendante du terminal.

Oui. Dans le Workbench, l'aide est intégrée au flux de développement plutôt que reléguée à une destination séparée. À mesure que les développeurs saisissent commandes, fonctions ou expressions, le Workbench affiche sur place les paramètres disponibles, les types attendus, les valeurs de retour et les usages courants.

Comme le système d'aide est piloté par le même modèle sous-jacent que celui qui exécute la logique, il reflète en temps réel la syntaxe, les capacités et les contraintes exactes de l'environnement.

Le Data Modeler est l'espace de travail visuel qui définit comment les données sont consultées, transformées, combinées et livrées à une application. Les développeurs connectent bases de données, fichiers, flux temps réel et autres sources, puis utilisent SQL et AmiScript pour filtrer, joindre, calculer, agréger et fusionner le résultat en datamodels réutilisables.

Il montre aussi les dépendances entre sources, datamodels, panneaux applicatifs et relations. Les développeurs peuvent tester les requêtes, inspecter résultats et erreurs, paramétrer les modèles avec des variables applicatives ou des sélections utilisateur, et configurer le comportement d'exécution : traitement au démarrage, rafraîchissement automatique, conflation, délais et limites de résultats. Contrairement à un outil de modélisation entité-relation classique, le Data Modeler représente la couche opérationnelle de traitement des données d'une application.

Oui. Le débogueur en ligne 3forge s'exécute dans le Workbench. Des points d'arrêt peuvent être placés sur des lignes précises d'AmiScript, et les scripts se lancent en mode debug depuis l'interface même où ils sont écrits. Lorsque l'exécution atteint un point d'arrêt, le panneau Debugger affiche les variables courantes et la pile d'appels, et l'exécution peut se poursuivre jusqu'aux points d'arrêt suivants.

Comme le débogueur est intégré à l'environnement, les callbacks AmiScript peuvent être exécutés et testés directement contre une instance 3forge connectée, avec des données réelles ou de test. C'est particulièrement précieux pour les applications événementielles, où la logique peut être invoquée au chargement d'un layout, à l'exécution d'un datamodel, lors d'une interaction utilisateur avec un champ ou une table, ou lors d'un changement d'état sous-jacent.

Le DB Shell est l'interface en ligne de commande interactive pour interroger, configurer et administrer la base du Center, en exécutant de l'AMI SQL avec une syntaxe familière proche de MySQL. Les utilisateurs récupèrent et modifient des données, créent ou altèrent des schémas, et gèrent les objets du Center : tables, index, procédures, triggers, timers, vues dérivées et objets de base personnalisés.

Il fournit aussi des outils d'inspection : SHOW expose les objets en cours d'exécution dans le Center, DESCRIBE retourne l'AMI SQL nécessaire pour reconstruire un objet, et DIAGNOSE renvoie des informations opérationnelles comme la consommation mémoire d'une table. Le Shell est également accessible via Telnet et SSH, avec un sous-ensemble de fonctionnalités plus limité.

La console F1 est l'interface d'administration et de diagnostic en ligne de commande d'une instance AMI Web en fonctionnement. Via une connexion authentifiée à un port de console dédié, les administrateurs inspectent utilisateurs actifs, connexions, sessions Web, layouts chargés et activité de session sans passer par l'interface graphique.

Elle expose les ressources utilisées par chaque session : exécutions de datamodels, erreurs, durées de traitement, tables générées, flux temps réel, processeurs, panneaux et consommation mémoire. Elle permet aussi des actions opérationnelles comme terminer une session ou une connexion, créer des sessions headless et exécuter de l'AmiScript dans une session choisie. Là où le DB Shell se concentre sur la base du Center, la console F1 se concentre sur le runtime AMI Web.

Le Merge Tool est l'interface graphique de revue, de combinaison et de résolution des changements apportés à un layout AMI par plusieurs développeurs. Plutôt que de comparer du XML ou de la configuration brute, il interprète les changements dans le contexte de la structure de l'application, en reconnaissant fenêtres, panneaux, datamodels, scripts, réglages et visualisations.

Les différences sont présentées sous forme d'arbre navigable comparant le layout partagé d'origine, les changements du développeur et ceux enregistrés par d'autres. Chaque modification peut être acceptée, rejetée ou combinée, les conflits sont identifiés avec une résolution proposée lorsque c'est possible, et le résultat fusionné peut être prévisualisé et testé dans AMI avant enregistrement.

3forge aborde l'IA sous l'angle de l'adoption gouvernée plutôt que de l'enthousiasme générique. La plateforme fournit un accès gouverné aux données temps réel, un runtime résilient, un contrôle tenant compte des droits d'accès et de l'observabilité : les firmes peuvent ainsi passer l'IA à l'échelle sans contourner les contrôles, dupliquer la complexité existante ou créer des chemins d'accès opaques vers des données sensibles.

Le principe sous-jacent est que le code généré par IA ne supprime pas les responsabilités de production : identité, permissions, état, concurrence, erreurs, reprises, tests, déploiement, supervision et auditabilité. Il les accroît souvent, en produisant davantage de code et de services. L'approche soutenable consiste à fournir ces capacités récurrentes au niveau de la plateforme pour que développeurs et agents se concentrent sur la logique métier.

3forge expose une surface gouvernée de développement et d'accès aux données via le Model Context Protocol. Plutôt que de connecter un assistant IA directement à chaque base, API ou flux de messages, l'institution expose des capacités choisies de la plateforme à travers le maillage applicatif.

Selon les outils mis à disposition et l'identité de l'utilisateur, un assistant autorisé peut récupérer de la documentation, inspecter des composants, explorer des schémas, construire et exécuter des requêtes AMI SQL, consulter des logs ou invoquer des opérations d'exécution autorisées. La connexion MCP ne crée pas de route parallèle contournant les contrôles : données, procédures, composants et actions disponibles restent soumis à l'authentification, aux droits d'accès, aux politiques de déploiement et aux contrôles d'audit appliqués par le runtime gouverné.

Le plugin MCP 3forge offre une prise en charge de premier ordre pour Claude Code, Codex et GitHub Copilot, avec des intégrations générées pour Gemini et Cursor. Les équipes de développement travaillent ainsi dans leurs environnements habituels sans concevoir et maintenir un jeu distinct de prompts et d'instructions 3forge pour chaque assistant.

Via une interface commune, plusieurs assistants travaillent sur la même surface contrôlée. L'institution définit ce que l'environnement expose, tandis que les développeurs utilisent les outils de codage adaptés à leurs pratiques.

Pour Claude Code, le plugin fournit des commandes directes couvrant les activités de développement courantes :

• 3forge-init établit le contexte du projet.
• 3forge-plan prépare un plan d'implémentation.
• 3forge-query soutient l'exploration de données et les requêtes AMI SQL.
• 3forge-runtime interagit avec l'instance connectée.
• 3forge-review relit une implémentation ou un changement proposé.
• 3forge-debug assiste l'investigation applicative et d'exécution.

Ces commandes sont des points d'entrée vers les mêmes skills et outils MCP sous-jacents, et non des chemins d'accès distincts.

Une connexion MCP de base donne à un assistant compatible l'accès aux outils et informations exposés par le runtime. Le plugin MCP 3forge ajoute un modèle de développement autour de cette connexion, en dotant les outils de codage IA de skills 3forge réutilisables, d'agents de développement spécialisés, de workflows guidés et de conventions d'interaction avec une instance en fonctionnement.

Le plugin combine deux types de connaissances, délibérément séparés. Des instructions de développement stables décrivent comment aborder des activités comme planifier une application, construire une requête, modifier un layout ou investiguer un incident d'exécution. La connaissance propre à l'environnement est récupérée depuis l'instance connectée : documentation, composants déployés, outils exposés, schémas, logs et capacités d'exécution. À mesure que le déploiement évolue, l'assistant s'adapte sans que chaque détail soit figé dans le plugin.

Le plugin inclut une bibliothèque de skills couvrant l'écriture d'applications, l'accès aux données, l'interaction avec le runtime, la configuration, la revue et le débogage. Un skill donne à l'assistant une méthode structurée pour un type de tâche : inspecter le schéma d'un Center avant de construire une requête AMI SQL, travailler sur un layout applicatif avec les patrons de panneaux pris en charge, ou investiguer un incident à partir de la configuration et des logs.

Pour les demandes plus larges, des agents de développement spécialisés répartissent le travail : l'un inspecte l'environnement, un autre construit la requête, un autre organise le layout, un autre relit l'implémentation proposée. Ces agents ne créent pas d'autorité distincte : ils opèrent via les outils, la documentation et les permissions accordés à l'assistant de codage d'origine.

Oui, lorsqu'il y est autorisé. Via MCP, l'assistant découvre les composants disponibles dans l'environnement connecté et identifie les outils associés à chacun, puis adresse sa demande au composant responsable de la donnée, de l'application ou de la fonction concernée. Des outils globaux donnent accès à la documentation, aux logs et aux capacités communes, tandis que des outils spécifiques exposent les fonctions de chaque composant.

Cela comble une lacune importante du développement assisté par IA : un modèle qui raisonne uniquement à partir des fichiers sources peut produire du code plausible syntaxiquement mais déconnecté du déploiement réel. L'assistant ne reçoit que les outils et informations exposés à son identité, et son activité d'exécution peut être gouvernée et auditée via le maillage.

3forge maintient un corpus de connaissances structuré pour le développement assisté par IA, contenant la documentation de référence des fonctions exposées via MCP ainsi que des patrons réutilisables montrant comment les combiner pour interroger des données, construire des applications, travailler sur des layouts et interagir avec le runtime. Le corpus est organisé par domaine fonctionnel afin que l'assistant reçoive des indications pertinentes pour la tâche en cours.

3forge inventorie la surface d'outils MCP réelle et audite la documentation et les patrons associés au regard de l'implémentation, en vérifiant que les fonctions exposées sont couvertes et que noms, paramètres, syntaxe, clés de configuration et comportements documentés restent exacts. L'audit ne modifie pas le code source de la plateforme et n'accepte pas ses propres modifications de documentation : il produit une différence relisible et un rapport d'audit, préservant une étape d'approbation humaine. Lorsqu'une affirmation ne peut être vérifiée, elle est remontée pour revue manuelle plutôt que tranchée par inférence.

Le plugin MCP 3forge suit un modèle documenter, vérifier, appliquer. Avant de proposer un changement, l'assistant consulte la documentation et les patrons de développement 3forge pertinents, et lorsqu'un outil de validation est disponible, il vérifie l'implémentation proposée avant de tenter de l'appliquer.

Cela ne rend pas automatiquement correct tout changement généré par IA. Cela crée des étapes explicites où les hypothèses peuvent être identifiées, la syntaxe testée et les changements invalides rejetés. Lorsque la fonction de la plateforme le permet, le travail généré peut rester en attente ou transitoire jusqu'à ce qu'un développeur l'applique ou le valide explicitement : layouts et panneaux peuvent donc être explorés et affinés sans que chaque action intermédiaire devienne un changement permanent.

Ask AI est le chatbot 3forge intégré directement dans l'environnement 3forge Web : les utilisateurs travaillent avec leurs données et applications en langage naturel sans passer de l'interface opérationnelle à un outil d'IA séparé. Parce que l'interface conversationnelle se trouve dans l'application, elle peut utiliser le contexte déjà disponible pour l'utilisateur.

Son autorité effective est déterminée par l'identité et les droits de l'utilisateur, les outils mis à disposition de l'assistant et les politiques configurées par l'institution. Il ne reçoit pas d'accès illimité aux bases, composants ou applications sous-jacents. Pour les usages analytiques, il traduit une demande en langage naturel en AMI SQL, et peut être configuré en lecture seule ou, avec l'autorisation appropriée, disposer de fonctions choisies de définition ou de modification de données.

Selon les permissions de l'utilisateur et la configuration de l'institution, le chatbot peut :

• Répondre à des questions en langage naturel à partir des données disponibles dans le maillage.
• Construire et exécuter des requêtes AMI SQL.
• Interagir de façon conversationnelle avec les applications et workflows 3forge.
• Invoquer des fonctions d'exécution explicitement autorisées.
• Déléguer des tâches à des agents spécialisés de la plateforme.
• Utiliser des agents et instructions créés pour des applications propres à l'institution.
• Travailler avec les modèles et fournisseurs d'IA configurés.
• Conserver et poursuivre les conversations d'un utilisateur d'une session à l'autre.

Oui. L'institution sélectionne les modèles et fournisseurs d'IA autorisés. Lorsque plusieurs modèles sont configurés, les utilisateurs peuvent être autorisés à choisir l'option adaptée depuis la conversation.

Les administrateurs contrôlent aussi quels outils l'assistant peut invoquer, si les conversations sont conservées, et combien d'actions ou d'étapes déléguées peuvent être effectuées lors d'une demande. Ces limites évitent qu'une conversation ouverte ne devienne une séquence incontrôlée d'opérations sur le runtime. L'historique peut être conservé par utilisateur, permettant de poursuivre une investigation d'une session à l'autre tout en préservant l'attribution.

Ce sont deux voies complémentaires vers le maillage applicatif. MCP permet à des assistants de codage et outils d'IA externes d'interagir avec le maillage via une interface standard ; il convient surtout aux développeurs et agents travaillant depuis des outils de codage, des IDE et des systèmes d'automatisation externes.

Ask AI offre l'expérience intégrée aux utilisateurs travaillant directement dans une application 3forge, en apportant l'accès en langage naturel au même environnement opérationnel où données, workflows et contexte utilisateur existent déjà. Les deux réduisent le besoin de connexions directes aux sources, de copies de données et d'intégrations IA spécifiques à chaque application, et maintiennent l'interaction IA dans le modèle d'identité, de droits, d'instrumentation et d'audit du maillage.

Oui. Les agents accèdent aux données par des chemins gouvernés, héritent des permissions et peuvent être journalisés, supervisés et contrôlés centralement. Un agent ne doit pas disposer d'une route parallèle contournant les contrôles établis pour les utilisateurs et les applications : il entre dans le runtime par une interface définie, ne reçoit que le contexte et les fonctions auxquels il a droit, et laisse une trace attribuable de son activité.

La gouvernance n'est donc pas ajoutée à chaque application après développement. Elle est héritée de l'environnement dans lequel l'application s'exécute.

Chiffres publiés pour le Center 3forge :

• Capacité de la base historique : plus de 10 000 milliards de lignes
• Colonnes de la base historique : plus de 1 000
• Débit de la base temps réel : plus de 2 millions d'opérations par seconde
• Latence de la base temps réel : moins de 100 microsecondes

Les chiffres réels d'un déploiement donné dépendent du matériel, de la conception du schéma, de la concurrence et de la nature de la charge.

Deux points de repère issus des données de marché. Le flux consolidé des transactions et cotations actions américaines (le SIP) transporte environ 2,5 milliards de messages par jour de bourse. Si une ligne correspond à un message SIP consolidé, 10 000 milliards de lignes représentent environ 4 000 jours de bourse, soit à peu près 16 ans.

Les données du marché des options sont bien plus denses, avec environ 200 milliards de mises à jour de cotations par jour sur OPRA en période active. Même à ce rythme, 10 000 milliards de mises à jour représenteraient environ 2,5 mois de trafic de cotations d'options.

Oui. STAC, cabinet de recherche technologique qui évalue les nouvelles technologies sous des charges pertinentes pour les institutions financières, a testé et confirmé de façon indépendante que 3forge Web dépasse les performances temps réel des front-ends lourds traditionnels.

Peter Lankford, directeur exécutif de STAC, a déclaré : « We found that on average, the system responded with charts of 2 million data points in roughly 3.7 seconds. We also found that as 25,000 records representing 700 thousand database fields streamed into the system every second, the system made new records available for user queries in less than 150 milliseconds on average. »

3forge est déployé dans des institutions comptant des milliers d'utilisateurs simultanés en exploitation mondiale 24/7. Le Web Balancer et le Web Manager assurent la montée en charge horizontale de la couche web en tant que composants natifs, sans dépendre d'une infrastructure tierce. La capacité effective dépend de la complexité des tableaux de bord et du nombre d'abonnements actifs par session.

La latence de bout en bout, de la réception de la donnée de marché à la mise à jour de l'interface, se situe typiquement dans la plage de quelques millisecondes pour un déploiement standard. Pour les workflows sensibles à la latence comme le pricing d'options ou le suivi d'exécution, l'architecture en mémoire élimine le coût des allers-retours vers des bases externes, là où la plupart des solutions concurrentes introduisent des délais.

3forge prend aussi en charge des granularités d'horodatage à la nanoseconde et à la microseconde pour la mesure fine de la latence et les analyses au niveau courtier.

Plusieurs mécanismes maintiennent la réactivité du navigateur quand les volumes augmentent :

• Traitement côté serveur. Les calculs sont déportés vers les Centers et le Web Server ne renvoie que les résultats pertinents, comme des agrégats, ce qui préserve la bande passante et la réactivité du front-end.
• Transmission de ce qui est visible. Les jeux de données qui alimentent graphiques, tables et pivots sont conservés dans la couche Web et transmis au navigateur uniquement lorsqu'ils sont visibles à l'écran.
• Propagation temps réel. Quand un élément change dans l'interface, 3forge propage intelligemment ce changement aux jeux de données et vues liés, pour que l'interface reste cohérente à mesure que la complexité augmente.

La base historique 3forge est conçue pour stocker de très grands jeux de séries temporelles et d'événements sur disque avec des requêtes rapides à la demande, en utilisant la même syntaxe SQL que les tables temps réel. Elle s'intègre directement au Center, si bien que données historiques et temps réel peuvent être interrogées ensemble dans un même datamodel, sans couche d'entrepôt séparée.

La disposition en colonnes, les stratégies de stockage par colonne, le partitionnement et l'indexation par tri la rendent économique à très grand volume. Les schémas peuvent être modifiés instantanément sans réécriture des données.

Non. La montée en charge de la couche web est assurée nativement par le Web Balancer : aucun répartiteur de charge externe ni service mesh n'est requis, même s'ils peuvent être utilisés si votre politique d'infrastructure l'impose. La montée en charge de la couche données passe par l'ajout de nœuds Center sous réplication, sans dépendance à des couches externes de cache ou de messagerie pour les fonctions cœur.

Les Gateways peuvent aussi appeler d'autres Gateways pour s'étendre efficacement entre centres de données et régions, et des Centers peuvent être ajoutés ou retirés sans redémarrer le Gateway.

L'architecture s'étend dans plusieurs directions sans changer de modèle d'exploitation. On place davantage de Relays près des nouvelles sources, on introduit davantage de Centers pour le traitement, le stockage ou la résilience régionale, on ajoute des Gateways pour un accès consolidé et des Web Servers à mesure que la population d'utilisateurs croît.

Un déploiement peut évoluer verticalement en allouant plus de ressources à une instance, horizontalement en ajoutant des instances, ou fonctionnellement en séparant des composants aux exigences de performance et de disponibilité différentes. Le maillage n'est pas défini par une topologie physique, mais par la constance des rôles, protocoles et contrôles qui demeurent quand la topologie change.

Oui. Selon la conception du déploiement, les schémas de résilience peuvent inclure la réplication de Centers en hot-hot ou hot-warm, plusieurs composants Web, la répartition web et la gestion distribuée des profils utilisateurs. Pour la continuité de messagerie, 3forge prend en charge la journalisation et le rejeu afin que les composants en aval récupèrent les données manquées après reconnexion.

La récupération doit être discutée dans le contexte de l'architecture de déploiement précise, et non comme une case à cocher universelle.

Dans un déploiement haute disponibilité, l'état du Center est répliqué en continu vers un nœud de secours à chaud, qui surveille la santé du primaire et peut prendre le relais en cas de panne avec toutes les données déjà chargées en mémoire. Les feed handlers se reconnectent et reprennent leurs abonnements, ce qui maintient le jeu de données en mémoire à jour.

Pour les cas exigeant une persistance historique complète à travers les pannes, la base historique 3forge offre un stockage durable sur disque qui survit aux redémarrages de nœuds.

Oui. L'architecture de réplication prend en charge les déploiements multi-régions et mondiaux. Elle est couramment utilisée par des institutions opérant entre New York, Londres, Hong Kong et d'autres places financières, où chaque région exige à la fois performance locale et cohérence inter-régions. Des mécanismes de réplication avancés pour le Center ont été introduits dans la version Été 2022.

Les clients Python et ODBC prennent aussi en charge les déploiements distribués, avec des points de bascule ordonnés et une reconnexion automatique lorsque le point actif devient indisponible.

3forge s'intègre aux systèmes de gestion de clés d'entreprise comme HashiCorp Vault et CyberArk, permettant un accès aux clés en temps réel sans stocker d'identifiants sensibles sur le serveur. Mots de passe et chaînes de connexion sont récupérés dynamiquement à l'exécution et ne persistent jamais sur disque dans le déploiement 3forge. Cette capacité a été introduite dans la version Hiver 2021.

Le modèle de licence est conçu pour éviter qu'un problème de connectivité temporaire ne devienne une panne de production. Si une instance ne parvient pas à joindre Operations Hub au démarrage, elle peut continuer à utiliser sa dernière licence pendant une période de grâce configurable.

Pour les environnements sans serveur de licences, 3forge peut émettre une licence autonome scellée à un hôte local et vérifiée à chaque démarrage. Aucun serveur ni réseau n'est nécessaire pour ce processus.

L'authentification est extensible via les protocoles d'authentification unique du marché, avec une prise en charge complète de SAML 2.0 et OAuth 2.0, permettant l'intégration à des fournisseurs d'identité comme Okta, Azure AD et Ping Identity.

Comme l'authentification est fournie au niveau du conteneur AmiCore, elle s'applique à l'ensemble du déploiement plutôt qu'à un module applicatif isolé. Une requête REST, une requête JDBC, une action utilisateur ou une invocation MCP entrent par des interfaces différentes tout en restant soumises au même modèle d'identité, de droits et d'audit.

Oui. L'autorisation s'appuie sur un cadre de contrôle d'accès par rôles très granulaire, dont les définitions de politiques prennent en charge les rôles imbriqués, les hiérarchies de groupes et les droits au niveau de la donnée. Les permissions peuvent s'appliquer jusqu'au champ ou à la cellule, garantissant une stricte ségrégation de la visibilité entre utilisateurs et équipes.

Le filtrage des droits est appliqué au niveau de l'exécution des requêtes : il ne peut donc pas être contourné depuis l'interface. C'est essentiel pour les déploiements multi-desks où différentes tables de négociation ou régions doivent avoir des vues cloisonnées de données partagées.

Oui. Toutes les données, au repos comme en mouvement, sont protégées par un chiffrement de bout en bout : TLS pour la transmission et AES pour le stockage, avec des protocoles de réplication sécurisés garantissant cohérence et intégrité dans les déploiements distribués.

L'intégration de 3forge aux systèmes de gestion de clés d'entreprise garantit que les clés de chiffrement sont gérées à l'extérieur et renouvelées selon votre politique de sécurité.

Oui. 3forge est certifié SOC 2 Type 2 par l'AICPA.

3forge fait également l'objet d'évaluations de sécurité dans le cadre des due diligences fournisseurs des institutions financières de premier rang. Un dossier de documentation sécurité comprenant schémas d'architecture, synthèses de tests d'intrusion et politiques de traitement des données est mis à disposition des clients sous NDA pendant la phase d'achat.

Certaines institutions financières et organisations gouvernementales appliquent des politiques définies au niveau du RSSI qui exigent des garanties strictes sur le code exécutable, l'accès aux données et l'auditabilité des comportements. Le mode lockdown est une configuration système qui impose ces garanties :

• Système de fichiers. Lecture, création ou modification uniquement dans des chemins prédéfinis et protégés.
• Ports et sockets. Pas de sockets arbitraires ni d'accès réseau libre.
• Bibliothèques Java. Pas de chargement de paquets Java personnalisés.
• Layouts d'interface. Pas d'injection JavaScript : seul le code contrôlé par le moteur s'exécute.

En garantissant que seul du code élaboré dans 3forge peut s'exécuter, le mode lockdown assure une couverture d'audit complète et l'application des droits sur chaque fichier, port, bibliothèque et interaction avec des données externes.

Oui. 3forge journalise les actions utilisateurs, les événements d'authentification et les accès aux données avec un niveau de granularité configurable, et le Gateway tient des journaux d'accès de toutes les interactions. Les journaux d'audit peuvent être exportés vers votre SIEM, votre plateforme d'agrégation de logs ou votre système d'archivage de conformité.

Cela répond aux exigences d'audit interne comme aux obligations réglementaires au titre de MiFID II, de la FINRA et de cadres similaires.

La gouvernance d'infrastructure opère habituellement de l'extérieur vers l'intérieur : elle détermine quel logiciel peut être déployé, où il peut s'exécuter, quelles ressources il peut consommer et dans quelles zones réseau il peut entrer. AmiCore ajoute une gouvernance depuis l'intérieur du runtime applicatif.

Il authentifie utilisateurs et services, les associe à des rôles, et applique ces rôles aux données, procédures et fonctions applicatives auxquelles ils peuvent accéder. Il gère aussi des aspects d'exécution comme l'accès au système de fichiers, les ports réseau, les plugins, la configuration des composants, l'allocation de ressources et la supervision. C'est d'autant plus important quand des agents IA deviennent participants des workflows d'entreprise, car les mêmes contrôles s'appliquent quelle que soit l'interface empruntée.

Operations Hub est la couche de contrôle à l'échelle du parc pour un déploiement 3forge. C'est une application hébergée par le client qui catalogue les applications 3forge déployées et leurs instances, supervise leur santé et leur utilisation, identifie les versions, gère les licences et génère alertes et rapports.

Là où AmiCore gouverne ce qui se passe dans chaque runtime, Operations Hub enregistre où ces runtimes sont déployés, comment ils se comportent, quelles versions ils utilisent et s'ils opèrent dans le périmètre de leur licence. Le résultat est un inventaire vivant adossé à des preuves opérationnelles, plutôt qu'une liste maintenue à la main de ce que les équipes croient avoir déployé.

Non. Operations Hub fonctionne entièrement dans l'environnement du client et ne nécessite aucune connexion directe du parc déployé vers l'infrastructure de 3forge.

Operations Hub collecte des informations de santé et d'utilisation auprès des instances AmiCore enregistrées, avec une granularité au composant. Au niveau du runtime, cela comprend CPU, mémoire, nombre de threads, ramasse-miettes, connexions utilisateurs et sessions actives. Il peut aussi descendre dans la télémétrie interne du conteneur AmiCore : ports ouverts, partitions, fichiers ouverts et signaux au niveau du système d'exploitation.

Moyennes glissantes, maximums et minimums sur différentes périodes fournissent une base pour identifier des besoins de capacité durables et des tendances émergentes, plutôt que de réagir à des mesures isolées. Alertes et rapports PDF planifiés peuvent être dirigés vers les équipes responsables de domaines produits ou de régions.

Le modèle de supervision recherche aussi l'absence et l'incohérence. Si une instance attendue cesse de se signaler, Operations Hub peut indiquer que le service est peut-être bloqué, déconnecté ou ne fonctionne plus comme enregistré. Si une instance non enregistrée ou une demande hors périmètre apparaît, l'écart est remonté avant de devenir un problème d'inventaire, de licence ou d'audit.

Cela complète la supervision d'infrastructure sans la remplacer. Les outils classiques indiquent qu'un hôte ou une JVM consomme de la mémoire. Operations Hub ajoute le contexte 3forge : quelle application tourne, quels composants elle contient, où elle est déployée, quelle version elle utilise et comment se comportent ses sessions et ses licences.

Operations Hub construit un inventaire structuré autour de l'application, plutôt que de traiter chaque processus comme un enregistrement isolé. Une application est enregistrée une fois avec son domaine métier, sa description et ses régions autorisées, et ses instances en fonctionnement se rattachent à cet enregistrement avec environnement, région, hôte, statut, JVM et composants installés.

Les écarts de version deviennent visibles à l'échelle du parc : les équipes technologiques identifient quelles instances sont passées à une version supportée et lesquelles restent sur une version antérieure. La planification des mises à niveau devient une liste définie d'applications et d'instances concernées, plutôt qu'une investigation à recommencer à chaque version.

Operations Hub centralise l'émission et l'inventaire des licences. Une clé parente fournie par 3forge permet à l'institution de générer et gérer des licences filles en interne. Les licences sont associées à des applications, domaines produits et régions enregistrés, plutôt que verrouillées définitivement à un hôte.

Quand une instance approuvée démarre, elle se déclare au serveur de licences et reçoit automatiquement une licence au niveau machine, chaque attribution étant enregistrée. C'est le seul moment où le serveur de licences est sollicité : aux démarrages suivants, la paire de clés est validée localement et l'instance démarre seule, entièrement hors ligne. L'utilisation peut être analysée par application sur des périodes quotidiennes, hebdomadaires et mensuelles.

Oui. 3forge peut émettre une licence autonome scellée à un hôte local, nommant l'application, les hôtes autorisés et les dates de validité, vérifiée localement à chaque démarrage. Aucun serveur ni réseau n'est nécessaire.

Lorsqu'un serveur de licences est utilisé, un administrateur de confiance local crée une clé secrète sur le portail client 3forge, qui délègue l'autorité d'émettre des licences machines locales, bornée à des noms d'hôtes, applications et une date d'expiration précis. Une attribution seule n'a aucune valeur : elle ne compte que rattachée au document 3forge d'origine.

Là où Operations Hub fournit la télémétrie de haut niveau sur l'ensemble du maillage, chaque composant est instrumenté pour une investigation fine de l'exécution du code, de l'accès aux données, de la latence et du débit :

• Analyse de threads en flamme. Profilage de performance qui visualise la répartition du temps d'exécution entre fonctions et met en évidence précisément les chemins de code lents.
• Visualiseur de logs avancé. Des visualisations dédiées analysent les logs applicatifs pour décrire l'allocation mémoire de la JVM, sa consommation et sa marge, à partir des messages traités dans les files, avec des observations générées pour guider l'analyse.
• Analyse de latence de bout en bout. La latence est mesurée et corrélée depuis les horodatages d'événements jusqu'aux paquets individuels, présentée dans des layouts vivants qui font apparaître tendances, valeurs aberrantes et dérive de performance.
• Attribution des ressources par session et par application. Le Workbench attribue l'usage des ressources au sein d'une même JVM à des utilisateurs et applications précis, ce qui permet de détecter les déséquilibres, de protéger le temps d'exécution des utilisateurs critiques et d'identifier les applications qui génèrent la charge.

3forge publie des versions majeures nommées environ trois à quatre fois par an, selon un rythme saisonnier. Chaque version apporte de nouvelles fonctionnalités, des améliorations de performance et des corrections. Des correctifs traitant des problèmes critiques sont mis à disposition au fil de l'eau entre les versions majeures.

Les notes de version de 3forge Enterprise sont publiées sur le portail 3forge à l'adresse portal.3forge.com/release-notes.htm. Un résumé de chaque version est également disponible sur notre page notes de version.

Les mises à niveau sont conçues pour rester rétrocompatibles avec les layouts et configurations existants. Le processus standard consiste à déployer le nouveau binaire 3forge dans un environnement de préproduction, à faire passer votre parc applicatif existant par les tests de recette, puis à promouvoir en production. L'équipe support 3forge peut aider à planifier les mises à niveau dans les environnements complexes.

Operations Hub fournit l'inventaire orienté application qui rend le périmètre de mise à niveau explicite, en montrant quelles instances tournent sur quelle version dans tout le parc.

Oui, maintenir la rétrocompatibilité est un engagement central de 3forge. Les AmiScript, layouts et datamodels existants continuent de fonctionner après une montée de version. Lorsque des changements de comportement sont introduits, ils sont clairement documentés dans les notes de version avec un guide de migration. Les fonctionnalités dépréciées sont généralement maintenues sur plusieurs cycles avant retrait.

Les projets 3forge doivent être conduits avec la discipline d'ingénierie logicielle habituelle. Les layouts et la configuration pertinente doivent vivre en gestion de sources, et les déploiements être promus au minimum du développement à la production, idéalement avec une étape de QA ou de recette entre les deux.

Les équipes doivent valider les tableaux de bord complets et leur configuration dans les environnements inférieurs avant promotion, plutôt que de considérer un export de layout comme prêt pour la production.

Oui. Le Workbench permet aux développeurs d'éditer, exécuter et tester des callbacks AmiScript directement contre une instance 3forge connectée, avec des données réelles ou de test, avant que les changements ne soient enregistrés dans la définition du layout ou promus vers un environnement supérieur.

La prise en charge des objets transitoires fait que les modifications exploratoires n'affectent pas le layout stocké tant qu'elles ne sont pas explicitement enregistrées.

Le Center inclut des outils de test et de couverture de code qui analysent quel code a été invoqué, temps d'exécution compris, ainsi qu'un débogueur avec points d'arrêt et codes d'erreur explicites pour parcourir la logique personnalisée.

Un planificateur de requêtes précompile et planifie l'exécution pour optimiser les performances, ce qui est utile pour valider qu'un datamodel se comporte comme prévu sur des données de forme réaliste.

Oui. La plupart des clients exploitent au moins trois environnements : développement, recette et production. L'intégration de gestion de sources et les hooks SDLC de 3forge sont conçus pour soutenir les workflows de promotion entre ces environnements. Les layouts et configurations sont stockés sous forme de fichiers versionnables et promouvables via des pipelines CI/CD standard.

Les tests doivent couvrir la justesse du code, la disponibilité des données, les droits d'accès, la performance sous charge et le comportement au déploiement. Pour les modèles de données et la logique applicative, les équipes doivent valider non seulement que le code compile, mais aussi que les hypothèses de source, de schéma et de rafraîchissement sont correctes.

Une bonne stratégie de test 3forge inclut l'inspection des résultats intermédiaires, la validation des droits propres à chaque utilisateur et des tests de promotion dans les environnements inférieurs avant mise en production.

Des ingénieurs 3forge dédiés assurent un support 24/5 pendant la semaine de bourse, afin que les équipes résolvent rapidement leurs problèmes et poursuivent leurs développements. Au-delà des canaux de support standard, 3forge propose documentation produit, notes de version, certification et services de réduction des risques projet.

3forge peut également accompagner les évaluations techniques, l'implémentation, les questions d'architecture et les interventions structurées sur des projets sous tension ou en difficulté. 3forge n'est pas seulement une plateforme logicielle, mais aussi un partenaire de livraison lorsque c'est nécessaire.

La documentation technique complète, incluant la référence AmiScript, l'API des composants, les guides de configuration et les schémas d'architecture, est disponible sur doc.3forge.com. Elle est mise à jour à chaque version et inclut des références API consultables, des tutoriels et des exemples pratiques.

Plus de 25 heures de tutoriels structurés accompagnent les équipes des fondamentaux jusqu'aux schémas avancés de production. Un programme de certification formel est disponible en partenariat avec Mallon Associates.

3forge propose également un parcours d'intégration structuré, animé par des ingénieurs solutions, couvrant le développement AmiScript, la conception de datamodels, la configuration des feed handlers et les bonnes pratiques de déploiement en production, sur site ou à distance.

3forge intègre une console de supervision qui expose les métriques d'exécution : mémoire par table, débit d'abonnements, temps d'exécution des requêtes et statistiques de heap JVM. Des outils d'analyse mémoire par colonne aident à identifier les schémas inefficaces, et l'API REST rend les données de supervision accessibles à des plateformes d'observabilité externes comme Grafana ou Datadog.

Operations Hub ajoute la vue à l'échelle du parc, et l'outillage au niveau composant, comme l'analyse de threads en flamme, le LogViewer et l'analyse de latence de bout en bout, permet une investigation plus poussée. Pour les incidents de production complexes, l'équipe d'ingénierie 3forge intervient directement via le canal de support.

Oui. Les clients actifs ont accès au portail développeurs et à la base de connaissances 3forge, qui incluent des questions-réponses consultables, des schémas et recettes courants, des guides de migration et des exemples contribués par la communauté. Les équipes d'ingénierie clientes participent également à une communauté Slack partagée où les ingénieurs 3forge sont actifs et disponibles pour les échanges techniques.

3forge propose trois modèles de livraison, et le même runtime de niveau production, le même outillage et le même cadre de gouvernance s'appliquent aux trois :

• 3forge construit (livraison clé en main). 3forge prend l'entière responsabilité de la conception et de la livraison de l'application selon des exigences et un calendrier définis.
• Votre équipe construit (autonomie). Les équipes internes conçoivent et déploient de façon indépendante, à l'aide de la documentation publique, des tutoriels et du support.
• Les deux construisent (modèle hybride). Des Forward Deployed Engineers 3forge s'intègrent à vos équipes, combinant appropriation interne et accélération spécialisée.

La plateforme étant un moteur applicatif et non un produit fermé, les firmes peuvent passer d'un modèle à l'autre dans le temps sans compromettre la cohérence architecturale.

Dans le modèle clé en main, 3forge travaille selon une structure de projet gérée, avec périmètre, jalons et livrables clairement définis, et des points d'étape réguliers assurant transparence et supervision pour la direction tout au long du cycle.

La livraison exploite l'intégralité du moteur applicatif, y compris les primitives préexistantes pour l'intégration de données, les droits d'accès, le traitement temps réel, la composition d'interfaces et l'outillage opérationnel. Le système final est livré entièrement configuré pour votre infrastructure, votre marque, votre gestion d'identité et votre cadre de droits. C'est un déploiement prêt pour la production, pas un prototype. Ce modèle convient lorsque rapidité, clarté de la responsabilité et exécution garantie priment.

Dans le modèle hybride, les spécialistes 3forge opèrent au sein de votre workflow de développement en apportant conseil d'architecture, schémas de production et expertise d'optimisation. Votre institution conserve la maîtrise architecturale et la propriété du domaine tout en bénéficiant de l'expérience d'ingénieurs ayant déployé la plateforme dans des environnements de production variés.

La collaboration pratique garantit que la connaissance reste dans votre organisation : vos développeurs reçoivent un accompagnement concret et des recommandations de bonnes pratiques en construisant de vrais systèmes plutôt que des exemples abstraits. Ce modèle maximise la vitesse tout en préservant la connaissance interne et l'autonomie à long terme.

Oui. 3forge étant bien documenté, les équipes internes peuvent concevoir et déployer de façon autonome. La plateforme s'adresse aux praticiens techniques, avec une documentation publique complète sur doc.3forge.com, plus de 25 heures de tutoriels structurés, un programme de certification en partenariat avec Mallon Associates et un support d'ingénierie 24/5 pendant la semaine de bourse.

Ce modèle convient aux organisations disposant d'une forte capacité de développement interne et souhaitant institutionnaliser cette expertise.

3forge Enterprise est normalement introduit dans un patrimoine de données existant, et la stratégie de déploiement découle du besoin traité. Points d'entrée courants :

• Accélérer une nouvelle application. Connecter les sources nécessaires là où elles se trouvent et les exposer via des interfaces gouvernées, pour que l'équipe applicative se concentre sur la logique métier au lieu des connecteurs, caches, droits d'accès et supervision.
• Industrialiser l'analytique ou l'IA. Préserver le travail analytique réalisé dans Excel, Python ou Jupyter tout en changeant sa façon d'atteindre les données d'entreprise et les processus de production.
• Relier des applications fragmentées. Fournir le maillage entre des outils qui fonctionnent individuellement mais ne transmettent pas données, état et décisions de façon cohérente.
• Introduire des applications pilotées par l'IA en toute sécurité. Placer une couche d'accès gouvernée entre des applications construites rapidement et les systèmes d'entreprise, en remplacement des API temporaires et connexions directes aux bases.
• Stabiliser un projet sous tension. Insérer 3forge de façon ciblée pour prendre en charge les parties du système qui bloquent la livraison, en préservant ce qui fonctionne déjà.

Oui. Quand un projet est déjà retardé ou instable, repartir d'une nouvelle fondation architecturale crée généralement un risque supplémentaire. 3forge peut être inséré de façon sélective pour prendre en charge les parties du système qui bloquent la livraison : mouvements de données peu fiables, absence d'état temps réel, logique métier dupliquée, interfaces lentes, supervision incomplète ou workflows traversant trop de systèmes.

Comme la couche de stabilisation est elle-même prête pour la production, l'intervention immédiate peut devenir partie intégrante du maillage à long terme, plutôt qu'une nouvelle rustine à retirer plus tard.

• Cadre d'évaluation technologique pour quantifier les besoins selon la complexité de la stratégie, les classes d'actifs traitées, les volumes et la croissance attendue.
• Checklists d'implémentation couvrant l'intégration de données, la configuration des systèmes de risque, la mise en place du reporting réglementaire et la connectivité de trading.
• Outils de calcul de ROI quantifiant les gains de productivité, la réduction du risque opérationnel et les comparaisons de coût total de possession.
• Modèles d'architecture de solution pour les configurations de fonds courantes selon les stratégies : multi-gérants, systématiques, orientées crédit.
• Supports d'ateliers clients, grilles d'évaluation de fournisseurs, feuilles de route d'implémentation et un guide de gouvernance et de bonnes pratiques.

3forge s'adresse à un éventail de profils, mais toutes les tâches n'exigent pas le même niveau de compétence. Certains utilisateurs se concentrent sur la construction de tableaux de bord ou l'interrogation des données, tandis que des profils plus avancés prennent en charge le scripting, le traitement d'événements, la modélisation de données et le développement de plugins. La plateforme est accessible à plusieurs profils techniques, certaines capacités restant destinées à des ingénieurs ou à des équipes plateforme solides.

3forge est utilisé dans le trading et le front office, la gestion des risques, la conformité réglementaire, la gestion de portefeuille, le private equity, l'intégration et l'orchestration de données. Parmi les workflows concrets : carnets d'ordres consolidés, réconciliations temps réel, analyse des coûts de transaction FX, échelles de repo et de dividendes de trésorerie, surveillance des limites de crédit en temps réel, détection d'anomalies de trading, surveillance d'algorithmes et coupe-circuits, reporting CAT, attribution factorielle intrajournalière, calcul de carried interest et de waterfalls, constitution de golden records et cache d'entrepôt de données.

Les clients ont construit plus de 500 cas d'usage distincts en finance sur le maillage applicatif. La valeur se cumule lorsqu'une firme utilise un seul moteur pour plusieurs workflows plutôt que d'acheter ou construire chacun séparément. Voir les cas d'usage pour le détail.

Oui. L'équipe d'ingénierie solutions 3forge fournit un accompagnement concret, de la revue d'architecture initiale et la conception du modèle de données jusqu'à la mise en production. Pour les clients soumis à des délais précis, 3forge peut intégrer des ingénieurs au sein de l'équipe cliente afin d'accélérer le développement. Notre offre de services entreprise couvre l'accompagnement stratégique et technique dans la durée, au-delà du déploiement initial.

L'IA fait désormais partie des fonctionnalités livrées et non d'une feuille de route future. Les capacités actuelles incluent l'interface MCP gouvernée, le plugin MCP 3forge pour les outils de codage IA, des agents de développement spécialisés, le chatbot Ask AI intégré et un corpus de connaissances audité pour la documentation destinée aux modèles.

3forge continue d'élargir les façons dont utilisateurs, développeurs, services et agents interagissent avec les données d'entreprise, tout en maintenant l'identité, les droits d'accès, le contrôle des charges, l'observabilité et l'auditabilité exigés en production. Les détails de la feuille de route sont partagés avec les clients dans le cadre de notre programme de briefings produit.