capacité de changement

La capacité de changement de Rhapsodies Conseil

La capacité de changement de Rhapsodies Conseil

7 janvier 2025

Capacité de changement

Ombeline de Lavenère-Lussan

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. 

rd solertia

Solertia – L’archi

Solertia - L'archi

29 octobre 2024

Rhapsodies Digital

Antoine Belluard

Responsable technique Rhapsodies Digital

À 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 !

On y va ?

Boring or not boring ?

Le choix de l’ennui : côté application

Le projet Solertia en gros résumé

À 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-performant axum, 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 :

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 :

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 !

Ah, mais si ça existe et ça s’appelle Retool !

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 :

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 :

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 :

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.

design system

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.

numérique durable

Un guide des bonnes pratiques d’Architecture pour le Numérique Durable: pourquoi faire ?

Un guide des bonnes pratiques d’architecture pour le Numérique Durable : pourquoi faire?

23 mai 2024

Architecture

Olivier Constant

Senior Manager Architecture

Le Numérique Durable ou Responsable est en plein essor. Des guides sont sortis récemment et proposent divers outils. 

Le gouvernement: https://ecoresponsable.numerique.gouv.fr/publications/bonnes-pratiques/ ou des associations: https://www.greenit.fr/categorie/bonnes-pratiques/ en proposent des versions.

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é…

bonne pratique architecture

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.

Articles qui pourraient vous intéresser

allocation fonds propres

Pilotage de programme d’allocation de fonds propres

Pilotage de programme d'allocation de fonds propres

7 novembre 2020

– 1 min de lecture

Patrick Rose

Contexte

Face aux différentes évolutions réglementaires, un programme a été constitué au sein de la filiale d’Affacturage, intégrant :

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 :

Bénéfices

Les autres success stories qui peuvent vous intéresser

IFRS9-finance-risk

Programme IFRS9 Finance/Risk

Programme IFRS9 Finance/Risk

4 novembre 2020

– 2 min de lecture

Patrick Rose

Contexte

Dans le cadre de la mise en œuvre de la nouvelle norme IFRS 9BPCE 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…) :

Missions

Bénéfices

Les autres success stories qui peuvent vous intéresser