Atelier NFR

13 juin 2025

CR par Eric

Accès au support de présentation

Le document présenté en séance est disponible à ce lien (à vérifier, certains n'ont pas accès sans poste CA) : Atelier 06 – Exigences non fonctionnelles (PPT)

Participants

BEDDIAF Hichem, BOUCHET Yannick, DORE Marc, DUMAS Geoffrey, DUTERNE Cyrille, GAUDIN Yannick, ZIELINSKI Hervé, HOURI Menahem, KAPITANFFY Stephane, MAZADE Sebastien, MONNIER Arnaud, MUNOZ RIFFO Patricio, PAGE Joseph, PHILIPPON Eric, TROGNON Stephane, TROUVE Jerome, XAMBO Benjamin, ZOUAKI Asma

Normes d'architecture "cloud native" dans Mocca

Une demande d'accès au portail est nécessaire pour les prestataires. Yannick Gaudin a mis à disposition les documents.
Normes à haut niveau applicables à notre projet :
- Si une norme est absente, on peut en proposer de nouvelles.
- Si besoin de challenger une norme, exposer pourquoi dans un processus dérogatoire (DA CAGIP / CVA CAAS).

Référentiels et normes

La plupart des référentiels (ex. : numérique responsable, DORA…) sont déjà pris en compte dans le projet.
L’architecte référent est Patrick U.
Les normes RSE à appliquer seront communiquées ultérieurement.

MESARI

Le projet doit passer par les comités CAA, puis se coordonner avec CA-GIP pour les instances de validation de l’offre commune.
- ✅ Consensus en séance sur cette approche.
Question posée : la validation par CAGIP est-elle un prérequis à celle de la CAA ?
Composants déjà intégrés à des offres CA-GIP (ex. : Flexible LakeHouse) ne nécessitent pas de MESARI spécifique.
- Le MESARI visera donc les composants Cloud et nouveaux composants On-Premise.
Possibilité d’avoir plusieurs MESARI :
- Un pour les composants CA-GIP
- Un autre pour l’instanciation CAA
- 📌 Action : Patricio se renseigne.
Le MESARI actuel n’est pas pertinent.
- Peut-être utile pour récupérer certains NFR (ex. : DIMA/PDMA).
- 📌 Action : vérifier possibilité de partager les MESARI de BforBank ou CACIB (Yannick G.).

Analyse des risques

Consolidation des éléments et comités liés aux analyses de risques dans un dossier unique.
- Objectif : faciliter les travaux et garantir la cohérence.
- Maintien par DA-MA avec contributions projet.
- ✅ Consensus en séance.

Processus d’architecture

L’équipe projet se concentre sur les comités/processus CAA (ex. : DA-MA).
CAGIP instruit les processus communautaires sur la base des validations avec CAA.
En cas de risques résiduels, raccourcis ou divergences, les éléments sont partagés à CASA & CAGIP pour validation.

CRC

Canal utilisé pour partager les MESARI avec CASA et identifier les risques résiduels.
📌 Utiliser le "Kit d’instruction CRC" (doc Confluence, accès à confirmer).
Contacts : Christine Boris et Mathieu Plantefol.
Il pourrait y avoir 3 CRC (3 périmètres DPO), même si un seul MESARI global.

CVA / CVSA CAGIP

Réunion tous les mercredis matin.
Présentation des éléments à valider (DA-MA, patterns, etc.) par l’entité (cluster GEA).

DICP

Identifier les DICP cibles des applicatifs.
3 niveaux :
- Offres de services CA-GIP (ex. : Data Plane vs Control Plane)
- Offres CAA
- Usages
Le DICP de la plateforme = le plus contraignant des usages.
- ✅ Consensus en séance
- 📌 Action : Eric vérifie consolidation avec Chantier 2
Certains DICP peuvent être renforcés par les couches applicatives (ex. : preuve de conformité complémentaire).
À sonder : usages SAS, Oracle, MapR.
Notes :
- Si Cloudera est remplacé chez CAPS et LCL, D = 4.
- C = 4 attendu (hébergement de données C4 hors DFE chez un tiers).

2SR

Aucun usage 2SR sur la plateforme actuelle.
Si de tels usages apparaissent, ils seront portés par les applicatifs (pas la plateforme MA).
- ✅ Consensus en séance

Réversibilité

Rappels

Réversibilité = au niveau des usages (data products), pas des composants.
Objectif : architecture hybride avec hub d’intégration.
Types :
- Réversibilité standard : 18 mois, tous usages.
- Réversibilité de crise : seulement certains usages critiques (analyse en cours).
- Certains usages critiques ou avec données C4 DFE seront directement hébergés on-premise (plus besoin de réversibilité de crise).

Cas extrême : sortie de Dataiku (Low-Code/No-Code)

Présenté dans une slide.
Effort de sortie estimé : M (moyen à fort).

Scorecards de réversibilité

Proposition d’utiliser une logique type "DICP-R".
À respecter :
- Normes & guidelines de développement.
- Contrôles automatisés (ex. : SonarQube dans CI/CD).
- Score de portabilité déterministe.
- Inscription au registre des usages à tester.
✅ Ouverture à la création de scorecards – 📌 Patricio à solliciter.

Tests de réversibilité

📌 Action : atelier à planifier (Eric), inscrit dans backlog archi.
Dépend de la mobilisation des métiers.
Intégration possible dans les PSI (question ouverte).
Définir un RACI clair (Entités, CA-GIP).
Comparaison avec PRA : tests plus impactants que les bascules classiques CA-GIP.

Capacity planning (cible réversibilité)

Étapes :
- Évaluer besoins pour héberger usages on-prem.
- Ajouter les usages éligibles à la réversibilité de crise.
- Permettra des tests dans des conditions réalistes.
- Inclure également le besoin en stockage pour backups.

Données vers cible on-premise / réversibilité

📌 Action : atelier à prévoir (Eric), inscrit dans backlog archi.
Possibilité de mise en œuvre par un Y (fonctionnalité du hub d’intégration).
Problème potentiel de synchronisation gauche/droite.
Flux retours cloud → on-premise possibles pour certains usages.

Isolation et partitionnement des projets

📌 Action : atelier à prévoir (Eric), backlog archi.
GCP : isolation probable par enveloppes projets (à confirmer).
Flexible LakeHouse : hypothèse d’isolation via namespace (à confirmer).
Mapping GCP ↔ on-prem à étudier avec l’équipe Flexible LakeHouse.

Backup

📌 Action : atelier à prévoir (Eric), backlog archi.
Hub = rejeu depuis fichiers originaux on-premise (hors EBCDIC : transcription possible).
Pas de synchronisation vers BigQuery prévue dans le lot 1.
Cela pourrait être envisagé vers 2027 avec Kafka.

HSM GCP

Actuellement disponible uniquement en mode Multi-Tenant.
Un PoC Single-Tenant réalisé pour CA-CIB (certification M003 attendue).
GA prévue début 2026.
Migration transparente (APIs identiques).
Pour début de projet :
- Utiliser le HSM Multi-Tenant du KMS.
- 📌 À faire valider par le CRC.
- Passage vers le Single-Tenant possible ensuite (après homologation).
🔔 Attention aux quotas de requêtes sur KMS/HSM (rappel Sébastien M.).

Notes par Joseph Page

Hybridation, réversibilité standard, Redondance, Backups et DR, PRA/PCA

Objectif de cet atelier

Identification des processus & livrables liés aux NFR (e.g. MESARI, CRC, etc.) ainsi que des contributeurs
Initialisation du référentiel documentaire applicable au projet MA, à mettre à disposition de tous les intervenants Chantier 1
- identifier documents de doctrine et les référentiels de règles existants dans le groupe afin de créer un référentiel documentaire applicable à la plateforme MA
- Si possible, identifier des documents de NFR ou les analyses MESARI pouvant servir d'exemple, même partiellement applicables, pour initier le registre des NFR du projet MA (ex: Plateforme Data CAA, IA Factory, etc.)
Processus de réversibilité standard
- Partager et, au besoin, compléter/amender la listes des assets impliquées dans une réversibilité (data, socles logiciels data, code usages, etc.) : Périmètre technique de la réversibilité
- Identifier les mesures de sécurisation du processus standard de réversibilité

Participants

Nom	Prénom	Statut
BEDDIAF	Hichem
BOUCHET	Yannick	CA-GIP
DORE	Marc	CA-GIP
DUMAS	Geoffrey	CA-GIP
DUTERNE	Cyrille
GAUDIN	Yannick
ZIELINSKI	Hervé
HOURI	Menahem	PRESTATAIRE CA-GIP
KAPITANFFY	Stephane	PRESTATAIRE CA-GIP
MAZADE	Sebastien
MONNIER	Arnaud
MUNOZ RIFFO	Patricio	CA-GIP
PAGE	Joseph
PHILIPPON	Eric
TROGNON	Stephane	CA-GIP
TROUVE	Jerome	CA-GIP
XAMBO	Benjamin	CA-GIP
ZOUAKI	Asma	CA-GIP – Organisateur

Documents de normes

(Arnaud présente les documents principaux étudiés lors du cadrage)

Arnaud insiste sur l'importance de la norme d'architecture "Cloud Native" mais regrette que la plateforme où il se trouve ne semble pas accessible aux prestataires et demande à ce qu'on puisse y accéder. Sébastien Mazade dit que normalement les prestataires peuvent demander un accès même si c'est visiblement compliqué. Sébastien et Yannick B propose d'extraire les documents et de les envoyer.

Eric demande si les normes s'appliquent directement ou si elles sont à re-validées. Patrico répond que oui, elles sont à appliquer, mais qu'on peut demander des adaptations si nécessaire.

Si la DA-MA veut une nouvelle norme, elle doit la présenter au cran au-dessus, DA CA-GIP ou DA CAA.

Processus MESARI

Patricio propose de s'aligner avec les normes CA-GIP. Benjamin Xambo propose qu'on s'assure de passer dans tous les comites CAA et qu'on se coordonne avec CA-GIP pour passer aussi dans leurs comités (CASA ?)

Benjamin Xambo insiste sur l'importance que le projet MA soit éligible comme plateforme communautaire, c'est-à-dire qu'il doit être conçu pour être utilisé par d'autres projets au sein de la CAA, et pas seulement pour le projet MA lui-même.

Le CRC aujourd'hui est le canal qui nous permet de partager nos mesaries avec CASA et d'identifier les risques résiduels Contact CASA : Christine Boris et Mathieu

Yannick B insiste sur l'importance que le dossier CRC soit cohérent avec le reste, et souhaite donc un dossier global qui agrège les différentes aspects de l'analyse de risque. Benoit Nadjime participera.

Un dossier est maintenu par les membres de la DA-MA, avec les contributions des membres du projet.

Les composants qui font déjà partie de d'autres offres n'ont pas besoin de faire l'objet de MEZARI de notre côté (notamment Flexible LakeHouse). La MEZARI concerne les composants Cloud et les nouveaux composants On-Premise. Le contour du MEZARI sur laquelle nous allons devoir travailler c'est l'instanciation et l'orchestration. Cela va peut-être déboucher sur plusieurs MEZARI. Patricio prend le point de se renseigner dessus.

Kit d'instruction et détail du processus CRC

Yannick B confirme qu'on doit s'appuyer sur le "Kit d'instruction et détail du processus CRC". (il faut qu'on arrive à y avoir accès. le doc est sur Confluence)

Process Architecture CAA (CVA, CVSA)

Benjamin confirme. La réunion est tous les mercredi matin. C'est en fait le représentant de l'entité, donc là, ça serait le cluster GEA qui vient présenter. Par exemple avec les docuements de la DA-MA. L'importance c'est le fond, pas les documents. Peut permettre de faire des choix de patterns d'archi dont on est sûr qu'ils conviennent à tout le monde.

RSE

Benjamin confirme que le RSE est au coeur du processus standard d'architecture. Notre architecte référent est Patrick, il est rompu à l'exercice. Les normes RSE à appliquer, nous serons communiquées en temps voulu.

Taxonomie des NFR

Comment ne pas repartir de zéro ? Arnaud et Eric demande comment on peut repartir de MEZARI/documents existants.

Une partie des NFR est déjà couvertes : - dans la/les MEZARI - normes - des documentations

Mais Yannick B ne sait pas aujourd'hui comment les consolider.

Il faut qu'on aille chercher un exemple sur une platforme existante la plus proche possible de la plateforme MA. Par exemple BforBank ou CA-CIB.

Les personnes de CA-GIP disent qu'ils n'ont pas accès aux MEZARI de BforBank ou CA-CIB. Et les personnes de CAA n'ont pas accès aux MEZARI des autres entités non plus.

NFR essentielles plateforme communautaire

Arnaud demande si on est capable d'estimer ces matrices dès aujourd'hui.

Il faut demander d'abord quels sont les DICP cibles des applicatifs.

3 niveaux de DICP:

celui des offres de services CA-GIP
celui des offres CAA
celui associés aux usages

Le plus contraignant des usages cale le DICP de la plateforme.

Yannick B rappelle que les usages existants ont des DICP et qu'ils vont s'appliquer à la plateforme cible.

Sébastien Mazade : c'est mieux d'avoir des DICP différents par briques (par exemple Data Plane vs Control Plane).

Proposition de DICP par Arnaud : 3342 (C obligatoirement à 4 à cause d'Archer ?) Mais Yannick B ne veut pas qu'on se fixe un DICP trop contraignant dès le début, car on ne sait pas encore quels usages on va avoir. Il faut qu'on sonde les usages d'abord, notamment SAS et Oracle.

L'analyse au niveau usages est peut-être déjà consolidée mais on ne sait pas. Il faut en discuter avec le chantier 2. Attention, il y a du volume donc c'est une grosse dépendance au chantier 2.

Si on a l'ambition de remplacer Cloudera chez CAPS et LCL, le D est à 4. En revanche Mapr n'est pas à 4

Réversibilité standard

Arnaud fait un rappel du cadrage MA pendant lequel le concept a déjà été présenté dans les comités. L'important c'est le cadre en bas :

La structuration du plan de réversibilité T=0 a été réalisée conjointement avec GCP.

Les travaux suivants sont en cours de réalisation avec l'équipe projet :

Plan de back-up et de sauvegarde des données, du code, des programmes...

Plan de réversibilité détaillé (cible, modalités de déclenchement, mirroring des services, planning détaillé....)

Stratégie et exécution de tests de réversibilité (dans le satellite : approche PMV, tester l'ingestion et le stockage des données, la portabilité et l'exécution des usages...).

En accord avec la consigne de renforcer le dispositif de contrôle sur la réversibilité dans le contexte géopolitique actuel, CAA propose de compléter les travaux sur la réversibilité « standard », basée sur la norme ARCHER par des travaux sur une réversibilité de « crise » et de faire un focus sur la continuité d'activité.

Eric: L'analyse des usages concernées par la réversibilité de crise est en cours.

Réversibilité standard : réversibilité à 18 mois qui s'applique à tous les usages Réversibilité de crise : uniquement certaines usages, à définir

Explication de la réversibilité par Eric.

L'objectif est d'avoir une architecture hybride. Le hub d'intégration est le premier élément permettant la réversibilité.

On cherche à avoir les meilleures offres disponibles sur chaque plateforme, mais en gardant en tête qu'on a besoin de pouvoir basculer nos traitements de la zone cloud public vers la cible de réversibilité, ne proposant pas les mêmes produits.

On a pas nécessairement le formalisme et les critères pour identifier du critique, mais il y a déjà des usages qu'on a déjà identifiés pour être sur le satellite On-Premise. Il n'y aura donc pas d'instanciation dans le Cloud pour eux. Cela devrait simplifier l'équation.

HSM GCP

David : rappelle qu'ils viennent de faire un PoC pour CA-CIB de Single Tenant HSM et qu'il sera certifié M003. Google sortira bientôt la fonctionnalité en GA. On a accès parce qu'on a le support Premium qui permet d'avoir les Private Previews. La migration depuis l'offre actuelle vers la nouvelle offre sera presque transparente puisque les APIs devraient rester les mêmes. Vu que c'est en Private Preview, il ne faut pas s'appuyer dessus pour le début du projet.

Rappel :

KMS : certification niveau 2
Cloud HSM : certification niveau 3
Single Tenant HSM : meilleur pour l'isolation, cible lorsque ça sera en GA

Sébastien rappelle qu'il faut faire attention au quota de requêtes sur les KMS/HSM. Les KMS ont moins de restrictions.

C'est à nous de prendre le boulot de détailler la façon dont on respecte le cadre ARCHER auprès des CRC.

La solution Multi-Tenant HSM existante est déjà validée par ARCHER. Il faut monter un dossier auprès de CRD pour valider l'usage de la solution 2 (peut-être sous forme de dérogation), en expliquant qu'on veut migrer vers Single-Tenant HSM (solution 3).

Retour à la Réversibilité standard

Rappel : si on trouve des usages 2SR, il a été décidé qu'ils soient portés par les applicatifs et pas par la plateforme MA.

Eric commente rapidement les slides

La réversibilité s'entend d'abord sur l'aspect Usages.

Arnaud évoque que le terme "Usage" pourrait être remplacer par "Data Product" qui sera le nouveau référentiel, et donc la réversibilité devrait s'appliquer à la maille "Data Product".

Yannick B ajoute que l'estimation "M" sur la partie "No-Code/Low-Code" porte sur le scénario d'une sortie de Dataiku également (la slide présente le cas "extrême" où on se fâche avec tout le monde)

Premier plan de réversibilité

Eric commente la slide, complété par Arnaud par moment

Questions/Remarques :

Yannick B : il manque des éléments non-techniques. Réponse : ce plan se concentre sur les aspects techniques, mais il faudra bien sûr un plan de réversibilité global qui inclut les aspects non-techniques.
Patricio : Google avait proposé de créer un ScoreCard de réversibilité pour chaque composant. Est-ce qu'on l'applique ? Réponse Eric : Il y a a 2 sujets : les capacités de la plateforme et mettre des contrôles pour vérifier que ce qui est produit est portable. Pour les capacités : par exemple un Data Product est éligible à un cas de réversibilité de crise, on doit déterminer ces éléments de socle qu'il faudra déjà instancier. S'il n'est pas éligible, on ne le met pas dans l'instanciation dans la partie création en cible. Pour les contrôles, oui il faudrait qu'on ajoute des guidelines et des tests automatiques dans le plan de réversibilité. Arnaud propose de s'appuyer sur SonarQube parce qu'il saurait déjà remonter des problèmes de portabilité et que ça serait un bon point de départ, mais pas suffisant. Est-ce qu'on sait comment établir cette ScoreCard de façon déterministe ? L'objectif n'est pas forcément d'être à 100% sur cette ScoreCard, mais au moins d'avoir l'information et d'en être conscient, côté plateforme et côte métier, notammment vis-à-vis des niveaux de criticité des usages.
Les flux en Y : Ca sera peut-être une feature du hub d'intégration que de vérifier qu'on est synchro de chaque côté. Cela touche aussi les sujets de backups. En tout cas, c'est un point à éclaircir rapidement.
Partionement : sur GCP, l'isolation est au niveau des projets. Côté Flexible Lakehouse quelle isolation entre les domaines ? Quel mapping entre GCP et On-Premise ? Patricio émet l'idée qu'un namespace puisse apporter l'isolation nécessaire côté Flexible Lakehouse. Tous : Faisons un atelier sur le sujet !

Tests de réversibilité

Questions/Remarques :

Marc: Est-ce qu'on définit une cible de backup de donnée en interne avant de les envoyer sur GCP ? (sources opérationnelles, etc.) Réponse : Le Hub a l'ambition d'avoir une capacité de rejeu qui s'appuie sur le fichier originaux sur les capacités de stockage On-Premise du Hub (à l'exception peut-être de l'EBCDIC où on gardera peut-être une transcription au lieu des originaux). A date ce n'est pas clair qu'on ait besoin de synchroniser (CDC) vers BigQuery, des bases opérationnelles, on pressent que ça arrivera vers 2027, pas avant, car ce n'est pas dans le lot 1 du projet. On s'appuiera alors probablement sur les capacités de rejeu de Kafka.
Il faut qu'on teste les cas d'usages avec les métiers. Réponse : Oui, mais il y a aussi des cas uniquement techniques. Mais attention, si on doit faire valider les tests de réversibilité par les métiers, cela nécessite leur mobilisation, de les impliquer fortement. Et pourquoi pas l'intégrer au "DICP-R" ?
Stéphane : Est-ce le test de réversibilité est complet ou pas ? dans le cadre du PSI ? Est-ce que certaines usages doivent être réversibles plus rapidement que d'autres ? Réponse : C'est le travail en cours d'évaluation de criticité des usages qui vous nous aider à l'identifier.
Stéphane : Quid du Capacity Planning ? Réponse : les besoins se limiteront aux usages que l'on veut tester. Il y a une capacité minimale qui existe de toute façon pour les usages On-Premise, il faudra donc prévoir une capacité additionnelles pour prévoir les tests de réversibilité. Il faudra revoir régulièrement le Capacity Pllanning pour s'assurer qu'on a la capacité de faire les tests de réversibilités.
Jérôme : Il est important de définir le RACI au de la réversibilité et des tests de réversibilité. Qui sont les acteurs ? Qui va être le garant ? Surtout que ça implique des changements de technos donc les impacts sont plus importants que les bascules auxquelles CA-GIP est habitué aujourd'hui. Réponse : Oui. Notamment Entités vs CA-GIP (peut-être pas si différent de ce que CA-GIP fait aujourd'hui sur d'autres projets). Il doit y a voir des similitudes avec les tests de PRA. Arnaud et Eric prennent le point de la gouvernance des tests de réversibilité et proposent de monter un atelier.