Coach Professionnelle, Team Leader Transformation Agile des Organisations
Séverin Legras
Directeur Agilité, Projets & Produits
Développer la capacité de changement pour Rhapsodies Conseil signifie s’appuyer sur une méthodologie éprouvée qui transcende les approches traditionnelles, en cultivant une culture d’apprentissage continu et en encourageant l’autonomisation des équipes internes, permettant ainsi aux organisations de s’adapter avec agilité aux défis d’un environnement en perpétuelle mutation.
En adoptant une approche multimodale et cross-expertise, nous orchestrons une synergie unique entre formation, coaching agile et professionnel, mentorat et facilitation, créant ainsi un écosystème de changement sur mesure qui catalyse la transformation durable de nos clients.
Notre philosophie d’accompagnement se distingue par son engagement profond envers la valorisation du client au sein de son organisation, en nous positionnant non pas comme des prescripteurs omniscients, mais comme des facilitateurs dévoués qui catalysent une dynamique collaborative authentique et pérenne.
Notre approche se distingue par son caractère mesurable et tangible, en allant au-delà des simples indicateurs opérationnels pour évaluer l’autonomie du client, l’évolution de ses pratiques, et sa capacité à résoudre proactivement de nouveaux défis, garantissant ainsi une transformation qui s’inscrit dans la durée et s’ancre profondément dans l’ADN de l’organisation.
En intégrant systématiquement la montée en compétence des équipes clientes dans nos accompagnements, nous assurons non seulement la pérennité des changements initiés, mais nous cultivons également une véritable culture de l’adaptabilité et de l’innovation continue, permettant à nos clients de mettre en place les fondamentaux permettant une organisation apprenante.
À Rhapsodies Digital, on aime construire des solutions numériques (oui oui), et on s’est dit qu’on avait envie de partager dans le détail ce qu’on fait. C’est donc avec une série d’articles que l’on va soulever le capot, et présenter les détails techniques de nos travaux.
On va commencer par parler de notre projet Solertia (car il est tout frais, le MVP vient de sortir), de son archi, le back, le front, et de comment on a fait tout ça.
Solertia, projet visant à lister, catégoriser et présenter des entreprises au savoir-faire exceptionnel, est aussi notre premier vrai projet interne, imaginé et réalisé par une équipe très réduite, mais passionnée !
À première vue, le projet présente une architecture très classique, avec un socle API et base de données consommée par un front.
L’avantage, c’est que si, un jour, on a envie d’exposer et de monétiser nos données, c’est presque déjà fait (bon, moyennant un système d’authentification et de rate-limit bien évidemment…). Et ça tombe bien, car c’est également une des ambitions du projet.
Autre avantage, notre front n’étant qu’une couche de présentation, il ne fera pas d’écriture sur nos données, tout comme les clients potentiels de notre API, on peut donc, sans vergogne, couper en deux nos routes et ajouter une protection supplémentaire sur tout ce qui est POST/PUT et DELETE.
Notre API/Back, sera de plus un proxy pour récupérer et agréger de la data sur nos fameuses entreprises, avec notamment des connexions API avec Pappers (et d’autres sources de données qui arriveront par la suite).
C’est pour cela que le full monolithe (bien qu’avec beaucoup d’avantages, on le rappelle, utilisé par exemple chez Stackoverflow), n’a pas retenu mon attention ici.
Le choix de l’ennui : côté base de données
TL;DR : j’aime bien PGSQL.
Une de mes technos préférées, je dois l’admettre, est PostgreSQL. Robuste, ultra-performante, sécurisée et éprouvée, les nombreuses qualités de cette base de donnée relationnelle open source ne sont plus à présenter.
Son excellente gestion du JSON, avec bon nombre de fonctions et d’opérateurs prêts à l’emploi (on en parlera plus en détails sur la partie backend), peuvent permettre, par exemple, de créer des requêtes dont le résultat est directement mappables sur un DTO.
Concernant le volume de données, quelques milliers d’entreprises, il me paraissait overkill d’utiliser ElasticSearch pour l’instant (qui nécessite son serveur et donc sa maintenance — ou alors des solutions SaaS hors de prix (coucou Algolia/Melisearch)), sachant que PG dispose d’un excellent module de recherche fulltext.
Puisqu’on a évoqué un peu de NoSQL, je n’ai pas retenu cette solution non plus, car on a quand même pas mal de relations à gérer, et n’étant pas non plus un fana des micro-services (quand ce n’est pas nécessaire), je n’avais pas envie de m’embêter à ce niveau-là. PostgreSQL est mon choix rationnel, par défaut, quand je cherche une base de donnée.
Car oui, il faut le reconnaître, le NoSQL est sexy et a d’autres avantages, et match très bien quand on a moultes services qui ont leur propre système de stockage. Mais bien souvent, ce n’est qu’une question de préférence sur la modélisation, au final, on peut très bien faire du NoSQL sur PG.
Comment qu’on se cache
TL;DR : un jour oui, mais pas maintenant.
Actuellement, le projet ne dispose pas d’un système de cache applicatif, autre que ce que les technos choisies font nativement. Nous verrons après le lancement du projet, car on aime bien itérer et donc pour l’instant, on préfère avoir notre BDD en frontal de notre API.
Parce que oui, développer un système de cache, ce n’est pas auto-magique, il ne suffit pas d’installer l’excellent Redis et hop, c’est fait. Il y a du code à écrire, et pas mal de cas à gérer, ainsi qu’une dépendance et un serveur supplémentaire.
Parlons technos applicatives !
Le choix du compilé côté Backend
S’il y a bien une chose que j’ai comprise au cours de mes derniers projets, c’est que l’interprété, c’est pratique, mais c’est coûteux en performance et donc en serveur.
Côté API, il est absolument vital que les performances soient au RDV, car c’est notre backend, c’est ce qui va exposer nos données, et c’est ce qui sera le plus gros bottleneck de notre architecture.
Ce que j’aime bien avec les exécutables, c’est qu’après avoir target une plateforme, on a pratiquement besoin de rien sur le serveur pour le faire tourner, couplé avec supervisord par exemple, on peut également avoir rapidement un système simple, auto-gérable. Le choix de docker en prod est par ailleurs plus envisageable, il suffit d’une alpine vanilla et c’est parti.
Les choix évidents : Rust vs Go
Secrètement, cela fait des années que je me forme au langage Rust, que j’adore et dont j’admire le design. Gestion de la mémoire fine sans garbage collector, syntaxe élégante, typage strict, friendly compilateur, zero-cost abstractions et performances proches du C/C++.
Néanmoins, son gros (et peut-être seul ?) défaut reste son niveau d’adoption professionnelle. Bien qu’on dénombre de plus en plus de success story après un passage à du Rust (Discord, AWS, Kernel Linux, 1Password…), le nombre de développeurs est actuellement limité, et la gymnastique mentale nécessaire pour coder en Rust est importante.
Je suis convaincu que le jour où on sera plus nombreux, je pousserai fort pour que l’on puisse construire nos backend en Rust pour participer également à la popularisation de ce langage.
Surtout que tokio (les créateurs de l’async sur le langage), avance à grands pas avec son framework web ultra-performantaxum, qui je pense va tout éclater sur son passage. À l’heure où j’écris ces lignes, le projet est en v0.9.3.
Le vainqueur rationnel : Go
Et donc oui, spoiler alerte, le backend de Solertia est écrit en Go.
Rebuté par sa syntaxe dans un premier temps, loin d’être élégante, force est de constater que le langage est populaire. Certainement causé par la réécriture de pas mal de backend PHP/Nodejs/Java et avec un Google en back.
Il s’est rapidement imposé, comme un bon compromis simplicité d’utilisation/performances.
Bien qu’on s’écarte sensiblement des performances de Rust, il est sympa de voir que des calls API sont de l’ordre de la milliseconde, avec des appels BDD derrière de la transformation de data. Surtout une belle économie de CPU/RAM, juste parce qu’on utilise mieux les ressources et qu’on a besoin de peu de dépendances (genre curl en fait) sur le serveur.
Côté langage, Go est également typé strictement et se veut surtout une boîte à outils complète côté network. Et là oui, pour faire du web, c’est simple, nativement tout existe déjà dans le STD. De plus, sa gestion de la concurrence le rend très cool à utiliser.Côté librairies/framework, on est aussi très bien, avec bon nombre de choses qui existent (forcément, car le gros du truc est déjà présent dans le langage). Ici, on va juste teaser, en disant qu’on a un framework web (Gin), un semi-ORM un peu naze, mais pratique pour les migrations (Bun) et un truc génial pour auto-générer la documentation OpenAPI à partir de nos DTO d’entrée et de sortie (Huma).
NodeJS et Astro pour le front
Je vais vous l’avouer, je n’ai jamais été très grand partisan de NodeJS (étant plus côté PHP historiquement).
On peut néanmoins reconnaître que son extrême popularité a généré tout un tas de truc quand même bien cool comme Typescript et Astro, excellent framework web que l’on m’a fait découvrir très récemment (big-up à Renaud qui se reconnaitra s’il est dans les parages !). Et également, côté performance, il ne se défend pas si mal que ça. Le souci, c’est qu’on paie ça avec un nombre absolument dingue de dépendance nécessaire.
Mais l’histoire de ce choix est, en réalité, un peu plus complexe que ça.
Un truc que fait très bien Astro, c’est la génération d’un build statique (du pur HTML/CSS avec un très peu de javascript côté client). Et ça, pour le coup, j’aime bien, car ça me rappelle le côté exécutable, presque ennuyeux, prêt à l’hébergement sur un bucket (par exemple), avec 0 dépendances côté serveur et des performances forcément extraordinaires.
Le seul “soucis”, c’est que c’est complexe à mettre en place quand on a du contenu dynamique. On n’a ici pas des masses de choix :
Option A : On (re)génère des portions ou l’intégralité du site via des Hook et autre système automatisé dès que la data change.
Option B : On fait nos appels API côté client.
La deuxième solution ne me plait guère, car cela veut dire que si on veut implémenter un rate-limit pour protéger et monétiser notre API, les conséquences seront subies côté client (ou alors, on ajoute un BFF, mais ça nécessite une autre app et donc de la complexité), et qu’on va nécessairement perdre de la performance et donc l’intérêt d’un build statique.
Donc, je suis plutôt partisan ici de la première solution, sauf que c’est quand même assez compliqué à mettre en place, surtout qu’on a, en plus, un moteur de recherche à implémenter (oui, des solutions pour le build statique existent, mais on verra plus tard !).
Limités par le temps et les ressources de développement, on va donc la jouer interprété côté serveur, avec les technos qui permettent de générer un static, et on migrera vers cette solution par la suite, ça, c’est certain.
Et PHP alors ?
Croyez-moi bien qu’avec mes 8 ans d’xp en développement PHP/Symfony (et j’adore le langage depuis sa version 7), cette piste a été étudiée, finalement rejetée, car j’avais envie d’expérimenter d’autres choses, principalement pour ouvrir mes chakras (bien qu’elle fonctionne très bien !).
De plus, pour la génération de build statique (qui est, rappelons-le, notre cible idéale), on a des solutions qui sont, selon moi, bien moins éprouvées que côté NodeJS. Et de toute façon, on a de l’interactivité forte côté UI, donc on aura forcément besoin de JavaScript.
Le Backoffice
Ce qu’on a dit jusqu’à présent, c’est super, mais il faut quand même à un moment pouvoir administrer nos données, car ça ne se fait pas tout seul (dommage…).
Et bon, ouvrir un éditeur de base de données et faire les modifs comme ça, directement en prod, c’est bien nature, un peu trop à mon goût.
Le p’tit soucis, c’est que faire un back-office, c’est pénible car :
Peu de valeur quand il s’agit d’un CRUD classique (c’est notre cas).
Peu de valeur quand c’est en usage interne, on ne va pas le vendre ni le faire utiliser à d’autres personnes (c’est notre cas).
Les formulaires ajoutent toujours de la complexité, d’autant plus que ça prend du temps.
Oui, on a plein de générateurs de BO qui existent pour se simplifier la vie, mais cela reste une app et donc un truc à maintenir.
Si seulement il existait des solutions qui permettent de faire du drag & drop de composants, de gérer l’authentification et les droits des utilisateurs, de créer des formulaires en 4 clics, plug & play sur n’importe quelle API, ça serait vraiment cool pour notre use case !
Grâce à cet outil et à sa version gratuite, on a pu monter un BO en quelques jours, autour des endpoints d’écriture de notre API. Sa base est solide pour faire des formulaires et des listings simples, sur les résultats de notre API. On définit les endpoints, on map les champs sur les inputs et pouf, ça marche.
Après, il y a quand même des désavantages par rapport à un BO développé maison, certaines choses m’ont bien frustré, comme l’absence de gestion avancée des images par exemple, car le système ne propose qu’un bête input d’upload de fichier, exit donc les jolis croppers et les résolutions fixes en fonction du champ.
Une infra (plutôt) simple
Avant de terminer cet (long) article, j’aimerais tout même partager quelques mots sur l’infra choisie pour l’hébergement du projet.
Étant très sensible à la philosophie Dev Ops, mais avec des connaissances limitées en Infra as Code (IAC) et en administration réseau, j’avais tout même envie d’un environnement propre avec, surtout, de la facilité au niveau du déploiement. L’IAC puisqu’on en parle, est, selon moi, l’un des aspects les plus importants à mettre en place, parce qu’elle constitue une description exhaustive de ce qui est online.
Côté hébergement, cela fait maintenant quelques années également que j’évolue dans des environnements “cloud”, où l’approche budgétaire et la grande flexibilité sous-jacente permettent d’appliquer l’agilité et l’itération plus facilement au domaine du système, notamment encore fois, lorsque les forces vives sont réduites. Il était donc naturel pour moi d’implémenter ces outils pour Solertia.
Le Cloud de Scaleway
Etant plutôt à l’aise avec les services d’AWS, j’ai également voulu innover, et de tester les services de Scaleway, qui est européen par nature.
On retrouve tout ce qu’il faut pour construire ce que l’on désire ici :
Containers “serverless” pour pousser des images docker en prod, sans s’embêter avec Kubernetes (quelques défauts néanmoins, comme un manque de flexibilité sur les paramètres de l’autoscaller, et des healthcheck abstraits).
Containers registry et Bucket (compatible API AWS S3!) pour sauvegarder nos artifacts, backends terraform et par ailleurs assets statiques comme les images.
Base de données managée PGSQL (uniquement en v15 malheureusement, alors que la 16 est dispo depuis presque un an).
SDK terraform plutôt bien documenté, qui m’a permis, en ma qualité de gros n00b de cette techno, de faire mon IAC de façon plutôt fluide.
Monitoring natif sur Grafana, plutôt fourni.
Comme décrit plus haut, j’aime itérer et faire vivre l’architecture, ici, on ne présente que ce qui propulsera le MVP. Il est possible que cela change dans le futur (pourquoi s’en priver ? c’est un des aspects sympa qu’offre le cloud).
Docker couplé avec une CI/CD chez Gitlab
Bon c’est super tout ça, mais je n’aime pas spécialement l’idée de construire mes images docker sur mon poste et de les mettre en prod via la console UI de Scaleway.
Fort heureusement, nous utilisons Gitlab, qui avec sa puissante et beginner-friendly CI/CD m’a permis de mettre en place, pour les deux projets :
La chaîne de lint, test et build
La partie déploiement avec upload de l’image sur le registry, modification du projet terraform avec nouvelle version, apply et migrations, base de données (uniquement côté API).
Le cycle quant à lui est honteusement simple : À chaque nouvelle branche, la CI nous dit si c’est bien (ou pas, très objective qu’elle est), et à chaque nouveau tag sur main, ça déploie.
La full picture
Pour conclure, ce qu’il va falloir améliorer
Voici une mini-liste non exhaustive de ce que j’ai mal/pas fait, et que j’aimerais donc pousser par la suite :
L’auto-scalling et healthcheck côté containers, trop obscure actuellement.
Le cache, mais on en a déjà parlé.
Instant T-Shirt XXL : Faire un build statique pour le front, et donc enlever un serveur traditionnel.
Merci de m’avoir lu !
Écrit par Antoine Belluard – Responsable technique chez Rhapsodies Digital, j’ai une dizaine d’années d’expérience dans le développement informatique. Passionné par la programmation et la technologie, et poussé par un fort impostor-syndrome, je suis en apprentissage continu.
Le design system qu’est ce que c’est, pourquoi l’adopter ?
Le design system qu’est ce que c’est, pourquoi l’adopter ?
23 octobre 2024
Rhapsodies Digital
Christophe Roselmac
Responsable design Rhapsodies Digital
L’adoption d’un design system est une décision qui nécessite une compréhension approfondie des besoins de l’entreprise et une communication efficiente avec la sa direction. Dans cet article nous allons apporter notre définition à ce qu’est un design system et les gains qu’il peut apporter à une stratégie globale.
Que suppose l’adoption d’un design system ?
Référence centrale pour tous les projets de conception, le design system est le langage commun entre les designers et les développeurs. Il permet de simplifier le travail des équipes tout en préservant une harmonie dans l’expérience utilisateur et une cohérence visuelle.
La mise en place d’un design system est avant tout un travail de compréhension des besoins, des enjeux et de communication entre les équipes.
La compréhension des besoins passe par une recherche approfondie pour analyser les spécificités des produits existants, identifier les problèmes de cohérence et mesurer l’impact sur l’expérience utilisateur.
L’évaluation des enjeux passe par une compréhension des contraintes budgétaires, des ressources disponibles ou encore de l’analyse de la concurrence afin de savoir à quoi nous faisons face. Cela permettra d’être certain qu’un design system est la solution appropriée à mettre en place.
Cette évaluation des enjeux doit être partagée avec la direction de l’entreprise en mettant en évidence les avantages potentiels qu’apporteront l’adoption d’un design system pour améliorer l’efficacité globale.
Des impacts concrets sur le ROI peuvent être mis en avant, comme l’économie des coûts de développement, de réduction du temps de mise sur le marché ou encore l’amélioration de l’expérience utilisateur et constituent autant d’arguments pour des décideurs quant à son adoption.
Le choix de mettre en place un design system est une décision stratégique, tout en étant un projet à part entière qui vit et évolue au rythme de la production de l’entreprise. Cette dernière peut réaliser des gains significatifs en termes d’efficacité et d’efficience des équipes grâce à la cohérence générale de l’organisation et des produits qui en découlent.
À quel moment se demander si un design system peut être utile ?
Chaque projet a ses particularités et suit des phases d’évolutions depuis sa création. Il peut exister plusieurs contextes spécifiques où il y a une nécessité d’établir des normes et des ressources pour la conception cohérente d’interfaces.
Les deux premiers moments clés où un design system devient pertinent sont lors de la croissance de l’entreprise et/ou de son produit et lors du constat de la répétition et de la redondance d’éléments de design.
En effet, la multiplication des types d’écrans et de pages lorsqu’un produit devient plus complexe peut être facilité grâce à un design system aidant à maintenir la cohérence visuelle et fonctionnelle.
L’augmentation de l’équipe de conception peut également initier la mise en place d’un design system, concentré sur des directives claires et des composants standardisés facilitant l’intégration de nouvelles personnes rejoignant l’équipe.
La répétition et la redondance peuvent être drastiquement réduites grâce à la centralisation d’éléments dans un design system. Il sera important de consacrer du temps à sa mise en place, quand on constate que les mêmes design sont recréés dans différentes sections d’un produit ou différents projets.
Enfin, si différents membres de l’équipe produisent des design qui ne sont pas uniformes, un design system permettra d’harmoniser les styles et les éléments.
Les autres moments importants ou un design system devient indispensable sont lors de phases d’évolution importante de l’entreprise et/ou son produit, voici quelques exemples :
La migration technologique : lorsqu’un produit évolue vers un nouveau produit ou un nouveau framework, un design system à toute sa pertinence pour aider l’intégration des nouveaux composants tout en maintenant la cohérence. Cela va de paire avec de nouvelles normes de conception fournissant une base pour appliquer ces changements de manière uniforme à travers le produit.
Améliorer la collaboration : dans les environnements de travail avec des équipes interfonctionnelles ou dispersées géographiquement ou encore suite à l’intégration de nouvelles équipes suite à une acquisition, un design system fournit un langage commun, des ressources partagées et facilite la standardisation et une meilleure collaboration.
Optimiser les process de conception et développement : une documentation centrale pour la formation et la conformité avec les standards de conception issus d’un design system permet de réduire des temps de développements des nouveaux composants et style en réutilisant les éléments existants.
Vous l’aurez compris, le design system est un outil puissant et devient incontournable lorsqu’une organisation nécessite une approche systématique pour maintenir la cohérence, améliorer l’efficacité et faciliter la collaboration entre différentes équipes. Le design system devient particulièrement pertinent lorsque les défis de cohérence et de gestion de l’interface et de l’expérience nécessitent une solution structurée.
A notre niveau de cabinet de conseil et d’architecture des SI, il nous paraît indispensable d’ajouter notre pierre à cet édifice. D’autant que les précités n’ont pas tout dit…
Le Numérique Durable: pourquoi faire ?
On le dit et le redit et c’est bien le sous titre de notre travail : L’architecture est “Green by design”. En effet, depuis longtemps les architectes construisent des SI solides, non redondants donc sobres en fait…
Sans compter le temps passé à challenger les métiers sur leurs besoins. Et à éviter les travaux inutiles… Faire et défaire c’est du travail inutile et si on peut éviter c’est toujours ça d’économisé…
4 grands thèmes qui ne sont pas propres à l’architecture
Nous avons voulu que notre travail puisse être adapté en tant que guide à beaucoup d’expertise en plus de l’architecture :
Gouverner et former : qu’est ce que votre expertise / discipline / domaine de compétences peut mettre en place dans sa gouvernance et dans la formation des personnes pour intégrer les dimensions de responsable et de durable ?
Mesurer et montrer : que va-t-on pouvoir mesurer dans votre discipline et quels résultats va-t-on pouvoir montrer ?
Challenger : quels sont les thèmes ou autres domaines sur lesquels vous allez pouvoir challenger pour aller vers la diffusion des bonnes pratiques ?
Concevoir : quelles sont les bonnes pratiques lors de vos travaux de conception qui peuvent permettre d’aller vers plus de durabilité ?
Les architectes au coeur du Système d’Information
Le travail des architectes est on le rappelle ci-dessous :
L’Architecture d’Entreprise organise le dialogue entre les différents corps de métier pour définir une vision commune de l’entreprise de demain et de son SI, ainsi que la trajectoire pour y parvenir. Elle met en œuvre les approches nécessaires pour assurer la connaissance, la gouvernance et le pilotage opérationnel du SI.
A ce titre, les architectes sont au coeur des SI et des transformations et doivent donc jouer un rôle d’influenceur dans la direction du Numérique Durable. Ce guide est là pour fournir des clés à cette population particulière.
Face aux différentes évolutions réglementaires, un programme a été constitué au sein de la filiale d’Affacturage, intégrant :
Le nouveau moteur de calcul de provisions IFRS9 et le calculateur d’assiette (RWA)
La nouvelle méthode de calcul (IRBF/Standard)
L’alimentation des plateformes groupe cibles :
Assiette fournie au calculateur Bâlois du groupe
Alimentation des outils de reporting groupe
Contrôle de cohérence entre filiale et groupe
Simulation par la filiale de son niveau de Risque.
Solution
La mission de Direction de Programme consiste à assurer la cohérence, maîtriser les adhérences, les chevauchements de plannings et les échéances imposées.
L’intervention a mobilisé un profil Senior Manager :
Forte expérience de pilotage de programme
Capacité de dialogue avec tous les acteurs, métier (Risques, Clientèle…) et IT
Expertise pour sécuriser les chantiers à forte compétence métier : garanties, notation tiers, défaut client/acheteur, FBE/NPE, grappage…
Liaison Groupe : Schéma Directeur Finance Risque, calculateur groupe…
Bénéfices
Livraison des chantiers Notation et Défaut Client
Solution transitoire de prise en compte des garanties
Gain en RWA
Respect des recommandations de l’audit interne et validation des normes BCE
Les autres success stories qui peuvent vous intéresser
Dans le cadre de la mise en œuvre de la nouvelle norme IFRS 9, BPCE a initié dès 2015 le programme qui prend en charge les impacts sur l’ensemble des métiers du Groupe (Finances, Risques, Comptabilités et Consolidation…) :
Classification des instruments financiers au niveau de chaque établissement ;
Révision des plans et schémas comptables ;
Définition et simulation des modèles de dépréciation, avec spécification d’un moteur centralisé.
Missions
Accompagnement de la Direction des Risques Groupe et de la Direction des Comptabilités Groupe dans la formalisation des expressions de besoins sur :
Les Tests SPPI & Business Models ;
La Gestion des Dépréciations ;
La structuration des annexes, en lien avec les évolutions du FINREP ;
Le chronogramme de production et son insertion dans les processus existants ;
Structuration modulaire des fonctionnalités de l’outil centralisé de gestion des dépréciations : segmentation IFRS 9, fonctions de calcul, affectation des provisions, restitutions aux établissements au niveau détail contrat et agrégé comptable (production CRE) ;
Définition des échanges de flux entre les communautés informatiques et le Groupe, et au sein des SI de l’organe central (COREP, FINREP, Consolidation…) ;
Formalisation des dossiers d’architecture fonctionnelle et applicative ;
Animation des comités d’architecture fonctionnelle Groupe et communautés IT.
Bénéfices
Contenu fonctionnel partagé entre les différents acteurs du Groupe ;
Architecture cible définie et partagée aux différents niveaux du Groupe, intégrée à la stratégie d’évolution des SI et alignée sur les exigences BCBS 239 ;
Meilleure maîtrise des enjeux et des risques des projets de la filière SI ;
Définition d’une trajectoire réaliste pour le démarrage du 1er janvier 2018.
Les autres success stories qui peuvent vous intéresser