Atoti d’ActiveViam sert à agréger et recalculer, en mémoire, des métriques multidimensionnelles sur des données qui évoluent pendant la journée. Pour un usage en finance, l’intérêt ne se situe pas dans un écran plus rapide, mais dans la capacité à expliciter un chiffre de risque, de liquidité ou de résultat selon des axes de lecture contrôlés.
En bref.
- Atoti associe un moteur d’agrégation, un datastore en mémoire et un modèle multidimensionnel destiné à l’analyse de données opérationnelles ou financières.
- La plateforme peut charger des données après transformation ou interroger une source externe en Direct Query, selon les contraintes de fraîcheur, de volumétrie et de contrôle.
- Les usages en finance reposent sur la modélisation financière des positions, des portefeuilles, des scénarios et des règles de calcul, non sur la seule restitution graphique.
- Une migration vers Atoti doit inclure la reprise des règles enfouies dans les rapports, les univers, les procédures ETL et les fichiers de rapprochement.
- Le traitement en mémoire accélère l’exploration, mais ne corrige ni une nomenclature de référence instable ni une formule métier insuffisamment documentée.
Ce contenu s’adresse aux responsables décisionnels qui examinent ActiveViam et Atoti dans un périmètre de finance de marché, de risque, de trésorerie ou de pilotage financier. Il ne traite ni la négociation commerciale, ni la conformité réglementaire, ni la protection des données personnelles, qui relèvent respectivement de vos achats, de vos équipes conformité et de votre DPO.
Comment Atoti d’ActiveViam organise l’analyse in-memory
Atoti est présenté par ActiveViam comme un cadre d’agrégation et de calcul en mémoire. La documentation produit décrit une combinaison entre moteur de calcul, stockage en mémoire et modèle sémantique multidimensionnel. Cette structure rapproche la plateforme d’un cube OLAP, avec une particularité importante pour les équipes finance : les mesures peuvent être recalculées à partir de données mises à jour pendant les workflows opérationnels.
Le point de départ reste une table relationnelle. Une ligne peut représenter une position, une transaction, une échéance, un mouvement de trésorerie, une contrepartie ou un enregistrement de résultat. Le modèle organise ensuite ces lignes selon des dimensions telles que le portefeuille, le desk, l’entité juridique, le produit, la devise, la date de valeur ou le scénario. La compréhension de cette mécanique passe aussi par la structure d’un cube OLAP et de ses axes d’analyse, car une dimension trop vague rend les comparaisons difficiles dès la phase de recette.
Une mesure ne correspond pas nécessairement à une colonne source. Elle peut résulter d’une formule qui additionne, filtre, alloue ou convertit des montants. Une exposition nette, par exemple, dépend souvent de la nature de l’instrument, du signe de la position, de la devise de restitution et du périmètre retenu. Le calcul doit donc être rattaché à une règle versionnée, avec une définition accessible au contrôleur financier comme au développeur qui maintient le modèle.
La documentation d’ActiveViam, consultée le 18 juin 2026 sur le portail documentaire Atoti, indique que les utilisateurs peuvent explorer des métriques sur plusieurs centaines de dimensions et consulter les données au niveau le plus détaillé. Cette affirmation décrit une capacité du produit, pas un délai garanti pour votre environnement. Le temps de réponse dépendra notamment du volume chargé, des calculs imbriqués, de la cardinalité des dimensions et du nombre de requêtes simultanées.
Le traitement en mémoire n’efface pas les contraintes du socle source. Une dimension « contrepartie » construite à partir de plusieurs référentiels peut produire des doublons, même si l’agrégation est immédiate. De même, une hiérarchie de portefeuille qui varie entre le front-office et la comptabilité ne devient pas cohérente parce qu’elle est visible dans un tableau de bord. Le moteur restitue la règle qui lui est fournie. Il ne l’arbitre pas.
Les composants techniques doivent être séparés dans le dossier d’arbitrage
Dans un dossier de décision, il faut distinguer le datastore, le cube, les calculs et les interfaces. Le datastore héberge les enregistrements utilisés par les analyses. Le cube porte les agrégations, les hiérarchies et les mesures. Les interfaces permettent de consulter le résultat. Confondre ces couches produit des estimations de charge imprécises, car une correction de formule dans une mesure n’a pas le même coût qu’une reprise de flux de chargement.
| Composant Atoti | Rôle dans l’analyse de données | Point de contrôle en finance | Risque si la règle est absente |
|---|---|---|---|
| Datastore en mémoire | Conserve les données relationnelles chargées ou actualisées. | Clé de position, date de valeur, devise et identifiant de transaction. | Doublons ou lignes non rapprochables avec le système source. |
| Cube multidimensionnel | Agrège les montants selon les dimensions et hiérarchies retenues. | Concordance entre portefeuille, desk, entité et périmètre comptable. | Total cohérent en apparence, mais attribué au mauvais axe de gestion. |
| Mesure calculée | Exprime une métrique métier dérivée d’autres données ou filtres. | Formule, signe, devise, arrondi et date de référence. | Écart de rapprochement dont l’origine reste invisible dans l’interface. |
| Interface utilisateur | Expose les analyses, filtres, vues et tableaux de bord. | Population autorisée à consulter ou exporter chaque périmètre. | Lecture erronée d’un chiffre correct, ou diffusion hors périmètre. |
Ce tableau croise les composants décrits dans la documentation Atoti avec les contrôles attendus dans un socle décisionnel financier. Il a été construit à partir de la documentation ActiveViam consultée le 18 juin 2026. Aucun environnement Atoti n’a été ouvert pour cet article. La documentation confirme les composants ; elle ne remplace pas la vérification de leur paramétrage dans votre instance.
La valeur du produit apparaît lorsque l’utilisateur descend d’un montant consolidé vers les enregistrements qui le composent, puis remonte selon un autre axe sans recréer un rapport. Cette capacité doit maintenant être reliée aux cas financiers qui justifient réellement la plateforme.
Quels usages d’Atoti en finance justifient une modélisation financière dédiée
Dans la finance, ActiveViam cible des analyses où les données changent fréquemment et où le même montant doit être lu sous plusieurs périmètres. Une direction des risques ne consulte pas uniquement un total d’exposition. Elle veut le décliner par portefeuille, classe d’actifs, devise, contrepartie, maturité, entité juridique et scénario. Une direction financière peut reprendre une partie de ces dimensions, mais appliquer un autre calendrier, d’autres règles de consolidation ou un autre seuil d’arrondi.
Atoti convient lorsque ces axes sont stables dans leur définition, mais nombreux dans leur combinaison. Le modèle multidimensionnel évite alors de matérialiser un rapport distinct pour chaque question récurrente. Cette nuance compte. Un produit doté d’un moteur rapide ne remplace pas un dictionnaire de données. Avant de construire les mesures, il faut relier chaque champ à une définition, une source et un responsable ; un dictionnaire de données exploitable en recette apporte souvent plus au projet que la première maquette de tableau de bord.
Les cas d’usage les plus solides concernent la consolidation intrajournalière des positions, l’analyse de risques, la simulation de scénarios et la restitution de résultats de gestion. Dans ces périmètres, les équipes doivent être capables de changer un filtre ou une hypothèse, puis d’identifier immédiatement les enregistrements qui expliquent la variation. La plateforme est conçue pour agréger et recalculer ces indicateurs sans attendre la production différée d’un cube nocturne.
La modélisation financière doit toutefois respecter une frontière claire entre données observées et hypothèses. Une position issue du système de transactions n’a pas le même statut qu’un taux de change de simulation. Les deux peuvent coexister dans une analyse, mais elles ne doivent pas être confondues dans la même mesure sans libellé ni règle de priorité. Cette séparation devient décisive lors des revues de résultat et des rapprochements avec les systèmes comptables.
Les scénarios ne doivent pas masquer le chiffre de référence
Les simulations de type what-if sont utiles lorsqu’elles modifient un paramètre maîtrisé. Une analyse peut faire varier une courbe de taux, un cours de change, une hypothèse de défaut ou une limite de portefeuille. La valeur produite doit conserver l’identifiant du scénario, la date de calcul et le jeu de données utilisé. Sans ces trois éléments, deux utilisateurs peuvent comparer des chiffres issus de contextes différents et conclure à un écart inexistant.
Le scénario de référence doit rester accessible à côté des hypothèses. Il ne faut pas remplacer une mesure de production par une mesure simulée dans le même tableau sans signalement. Dans un socle décisionnel, l’absence de séparation entre réel, prévisionnel et stressé est une source classique de reprises de recette. Le calcul est parfois correct. Le problème provient du périmètre sélectionné à l’ouverture du rapport.
- Les analyses de portefeuille demandent des hiérarchies de gestion versionnées, car un transfert de portefeuille modifie l’attribution sans changer l’instrument détenu.
- Les indicateurs de risque exigent une granularité suffisante pour expliquer un total par transaction, contrepartie, produit et date de valeur.
- Les simulations doivent conserver le nom du scénario, l’horodatage et la source des paramètres afin que le résultat soit reproductible.
- Les restitutions de pilotage financier nécessitent une règle écrite pour les devises, les taux de conversion et les arrondis de consolidation.
- Les exports destinés à Excel doivent reprendre les filtres et le périmètre de la vue consultée, faute de quoi le fichier extrait devient un second référentiel.
La documentation Atoti consultée le 18 juin 2026 distingue les guides destinés aux utilisateurs, aux développeurs Python et Java, aux intégrateurs JavaScript et aux administrateurs. Cette séparation confirme que le produit couvre plusieurs rôles. Dans un projet, elle doit conduire à des recettes distinctes : recette des mesures, recette des écrans, recette des droits et recette des flux. Faire valider le tout par un seul profil métier reporte les défauts vers la mise en production.
L’optimisation financière ne se mesure donc pas au nombre de graphiques livrés. Elle se mesure à la possibilité d’expliquer un indicateur, de rejouer son contexte et de retrouver les lignes qui le composent. Cette exigence conduit directement à la question du chargement et de l’actualisation des données.
Comment charger les données dans Atoti sans déplacer les défauts du socle source
Atoti peut recevoir des données dans son datastore relationnel après un processus ETL, ou interroger directement une base externe grâce au mode Direct Query décrit par l’éditeur. Ce choix ne doit pas être décidé sur une préférence d’architecture. Il dépend du délai de disponibilité attendu, du coût de transformation, de la stabilité du modèle source et de la capacité à expliquer le chiffre au moment où il est consulté.
Le chargement dans le datastore convient lorsqu’un jeu de données doit être harmonisé avant analyse. Les sources peuvent porter des formats de date différents, des référentiels de devises concurrents ou des statuts métier qui ne se recoupent pas. La phase ETL permet de normaliser ces éléments, de compléter les clés de rapprochement et de rejeter les lignes inexploitables. Le rejet doit être visible dans un contrôle de chargement. Une ligne écartée sans journal de rejet devient une différence de montant lors de la recette.
Le Direct Query répond à une autre contrainte. Il évite un chargement complet lorsque certaines données doivent rester interrogées dans la base externe. Cette option réduit les duplications de données, mais elle déplace la dépendance vers la disponibilité et le comportement de la source interrogée. Le lecteur doit vérifier la nature exacte des requêtes envoyées, le volume retourné, les droits utilisés et le délai acceptable pour un écran opérationnel.
La documentation ActiveViam, consultée le 18 juin 2026 sur docs.activeviam.com, indique qu’Atoti peut charger des données relationnelles avec des transformations allant de cas élémentaires à des traitements plus élaborés, et qu’un accès direct à une base externe est prévu sans chargement ETL préalable. Le texte décrit deux mécanismes disponibles. Il ne permet pas d’affirmer que le Direct Query est adapté à tous les volumes de Big Data ni à tous les usages intrajournaliers.
Le contrôle des clés doit précéder les calculs d’agrégation
Dans les projets de reprise, les écarts les plus coûteux ne viennent pas toujours d’une formule complexe. Ils apparaissent dans les clés de jointure. Une transaction peut être chargée avec une contrepartie inconnue, un portefeuille peut avoir changé de code et une devise peut être convertie selon un référentiel différent de celui de la comptabilité. L’agrégation additionne alors des montants exacts sur des regroupements inexacts.
Le contrôle doit commencer par des comptes simples : nombre de lignes reçues, nombre de lignes chargées, nombre de clés non résolues, montant des enregistrements rejetés et date de dernière alimentation. Ces indicateurs doivent être calculés à chaque cycle et conservés dans l’historique. Une anomalie de référence détectée le lendemain est plus facile à isoler qu’une différence observée à la clôture mensuelle.
Un exemple de chiffrage permet de borner une reprise de flux. Sur un périmètre hypothétique de huit sources, avec trois mappings par source et deux contrôles de qualité par mapping, le socle représente vingt-quatre mappings et quarante-huit contrôles. En retenant une hypothèse de six heures pour documenter et tester un mapping existant, puis deux heures par contrôle, la charge atteint 144 heures pour les mappings et 96 heures pour les contrôles, soit 240 heures. Cette estimation exclut la correction des sources, la recette métier, les droits et les reprises d’historique.
Ce calcul n’est pas un ratio éditeur ni une promesse de charge. Il sert à montrer ce qui disparaît souvent d’un budget présenté sous le seul intitulé « connexion de données ». Si la documentation des mappings n’existe pas, si les règles sont enfouies dans du code ou si plusieurs sources ne sont pas réconciliées, l’hypothèse de six heures ne tient plus. Il faut alors repartir d’un inventaire détaillé, sans chercher à conserver une estimation de départ devenue fausse.
Le choix entre chargement et accès direct dépend finalement de la capacité à tracer l’origine des montants. Une analyse rapide qui ne permet pas de répondre à la question « quelle ligne source explique ce total ? » ne passera pas une recette financière exigeante.
Comment Atoti UI et les interfaces de restitution encadrent l’intelligence décisionnelle
Atoti Server peut être interrogé par plusieurs interfaces. ActiveViam propose Atoti UI pour la visualisation et l’exploration en temps réel, tout en indiquant une compatibilité avec des front ends commerciaux. La documentation distingue également un guide utilisateur, un guide de connectivité, un module complémentaire Excel, des guides de développement et une administration centralisée. Cette diversité est utile, mais elle impose de définir quelle interface fait foi pour chaque population.
Une équipe de contrôle des risques peut privilégier une vue interactive qui permet de filtrer, de descendre au détail et de comparer des scénarios. Une direction financière peut exiger un export structuré vers Excel pour compléter une note de clôture. Ces deux besoins sont légitimes. Ils ne produisent pas les mêmes risques de diffusion, de recalcul local et de perte de traçabilité.
Excel mérite un contrôle particulier. Le complément Atoti est documenté par ActiveViam comme un moyen d’enrichir l’expérience utilisateur dans Excel. L’outil peut rapprocher l’analyse décisionnelle des pratiques quotidiennes des équipes financières. Il peut aussi créer une dépendance à des fichiers enregistrés hors du circuit de validation. Les cellules alimentées par Atoti, les formules ajoutées localement et les extractions figées doivent être distinguées dans la procédure de contrôle.
La plateforme peut aussi être intégrée à des interfaces Java ou JavaScript. Ce point intéresse les équipes qui souhaitent embarquer une analyse dans un portail existant plutôt que multiplier les écrans. La responsabilité du modèle sémantique ne disparaît pas avec cette intégration. Un libellé ambigu dans une interface dédiée reste ambigu, même si le moteur d’agrégation fournit le montant attendu.
Les droits doivent être testés sur les parcours réels
La sécurité d’une application décisionnelle financière ne se résume pas à l’authentification. Il faut vérifier ce qu’un utilisateur voit après application des filtres de portefeuille, d’entité, de desk ou de pays de booking. Il faut également contrôler les capacités d’export et les possibilités de requête par les outils externes. La documentation d’ActiveViam contient un guide de sécurité et un guide d’administration ; ils doivent être lus avec vos règles internes, non à leur place.
La protection des données personnelles et les règles de conservation ne relèvent pas du présent périmètre. Votre DPO et vos équipes sécurité doivent qualifier les données présentes dans les sources et dans les exports. L’analyse décisionnelle peut transporter des identifiants de personnes, de clients ou de contreparties. La présence d’un moteur en mémoire ne modifie pas les obligations internes qui portent sur ces informations.
La recette des interfaces gagne à s’appuyer sur des parcours écrits. Un contrôleur consulte un portefeuille autorisé, applique un filtre de date, exporte une vue et vérifie que le fichier reprend le même périmètre. Un autre profil tente d’ouvrir un portefeuille interdit et doit obtenir un résultat conforme à la règle définie. Il ne s’agit pas d’un test décoratif. Une différence entre l’écran et l’export peut produire deux chiffres concurrents dans la même réunion.
Le guide d’administration Atoti mentionné dans la documentation officielle, consultée le 18 juin 2026, couvre la configuration, la gestion et le suivi d’un déploiement depuis une interface centrale. Cet élément doit se traduire, dans votre dossier de projet, par une matrice précise : qui modifie les droits, qui déploie un modèle, qui valide une mesure et qui traite une alerte de chargement. Sans cette matrice, le produit est exploité comme une boîte noire par des équipes qui ne partagent pas les mêmes responsabilités.
La qualité de l’intelligence décisionnelle dépend donc autant du parcours utilisateur que du moteur de calcul. Les chiffres doivent conserver le même contexte lorsqu’ils passent d’Atoti UI à Excel, à un portail intégré ou à un export de clôture.
Quand choisir Atoti pour remplacer ou compléter un socle décisionnel financier
Atoti ne doit pas être évalué comme un outil de tableau de bord générique. Son positionnement prend du sens quand le socle existant peine à consolider des données mouvantes, à servir des calculs multidimensionnels ou à fournir le détail qui explique une variation. Le point de comparaison n’est pas seulement l’interface actuelle. Il faut regarder les règles de calcul, les flux d’alimentation, la granularité accessible, les droits, les exports et la charge de recette.
Un parc comportant peu de rapports, des données stables et des calculs limités peut ne pas justifier une plateforme d’analyse in-memory. Dans ce cas, la reconstruction d’un modèle sémantique dans l’outil en place ou la correction des flux existants peut coûter moins cher qu’une reprise complète. L’arbitrage s’inverse lorsque les règles sont nombreuses, peu documentées et réutilisées par plusieurs populations, car leur reconstruction isolée rapport par rapport augmente le risque de divergence.
La migration doit commencer par un inventaire des objets réellement utilisés. Il faut relever les rapports, les sources, les périodes de consultation, les filtres implicites, les exports, les macros, les univers éventuels et les fichiers Excel qui complètent le dispositif. Un rapport ouvert trois fois par an peut rester utile s’il sert une clôture ou un contrôle réglementaire. Les logs ne suffisent donc pas à décider seuls. Ils fournissent une liste de départ qui doit être qualifiée avec les métiers.
La réconciliation doit accepter des écarts expliqués
Le projet ne doit jamais promettre que les chiffres d’Atoti seront identiques à ceux du socle remplacé. Les résultats peuvent différer à cause d’une règle corrigée, d’un périmètre de données assaini, d’un calendrier revu ou d’un arrondi appliqué autrement. La recette doit définir des tolérances, classer les écarts et exiger une explication pour chaque différence significative.
Un protocole utilisable peut comparer, pour une même date de référence, le total global, les dix principaux portefeuilles, les principales devises et un échantillon de transactions détaillées. Chaque écart est enregistré avec son montant, son pourcentage, sa cause supposée, le responsable de validation et le statut de correction. Un écart de 0,4 % sur un total peut être acceptable ou bloquant selon la mesure concernée ; sans seuil écrit, le comité de validation ne dispose d’aucune base d’arbitrage.
La documentation ActiveViam consultée le 18 juin 2026 confirme l’existence de guides séparés pour les développeurs, les utilisateurs et les administrateurs. Dans une migration, cette séparation implique au minimum trois recettes : les mesures et données, les parcours de consultation, puis l’exploitation technique. Réduire la recette à une démonstration d’écran reporte les défauts vers la période de double run.
Avant d’engager la reprise, sortez douze mois de traces de consultation, listez les mesures de référence et rattachez chacune à une source, une formule, un propriétaire métier et une tolérance d’écart. Ce travail indique si Atoti répond à un besoin réel de consolidation et d’analyse, ou si votre difficulté se situe d’abord dans la documentation de l’existant.
Atoti est-il uniquement un outil de visualisation financière ?
Non. Atoti combine un moteur d’agrégation et de calcul, un stockage en mémoire et un modèle multidimensionnel. Atoti UI sert à explorer les résultats, mais la valeur du produit réside aussi dans les données chargées, les hiérarchies et les mesures définies dans le modèle.
Quelle différence entre chargement ETL et Direct Query dans Atoti ?
Le chargement ETL prépare et charge les données dans le datastore Atoti après transformations. Le Direct Query permet d’interroger une base externe sans chargement préalable. Le choix doit être justifié par la fraîcheur attendue, la qualité des données, la traçabilité et les contraintes de performance de la source.
Atoti peut-il remplacer un parc de rapports existant ?
La réponse dépend du volume de rapports réellement utilisés, de la complexité des règles, des flux de données et des besoins de simulation. Une reprise n’est justifiée que si les mesures, les dimensions et les parcours utilisateurs sont inventoriés puis soumis à une recette de réconciliation.
Pourquoi les écarts de chiffres doivent-ils être prévus avant la bascule ?
Parce qu’une règle corrigée, un arrondi, une date de référence ou un périmètre de données peuvent modifier le résultat. Le projet doit fixer des tolérances et documenter chaque écart significatif au lieu de promettre une équivalence automatique entre l’ancien socle et Atoti.
Le dossier complet Socles BI hérités : auditer le parc réel avant de le migrer
