Présentation de notre Rapid-API-Delivery Framework - RAPID Framework !
Un framework, c’est un cadre de travail. Rien ne vous empêche de l’alléger ou de le surcharger. Vouloir l’exécuter tel quel serait un non-sens, car vous devez l’adapter à vos besoins.
“La gouvernance, la gouvernance, la gouvernance, mais vous n’avez que ce mot dans la bouche vous autres consultants !” Pas faux. Et à force de l’avoir entendu chez nos clients concernant la gouvernance de l’API, nous l’avions souvent mis de côté à la suite. Jusqu’à ce que par effet balancier, des clients reviennent nous voir pour avoir notre avis sur le sujet. Évidemment on se dit qu’il y a une tendance naissante, alors nous affutons nos convictions, préparons nos slides, travaillons un peu sur le sujet chez nos clients, jusqu’à ce que cette mini-bulle se dégonfle à nouveau. L’histoire de l’informatique étant un éternel balancier, et comme nous avons pu accumuler de l’expérience, quel meilleur moment, où tous nos clients n’ont de yeux que pour l’IA, ses LLM et ses POC à la réussite aléatoire, que de finaliser notre vision ! Et quel meilleur moyen que par le biais d’un framework ?
Bien sûr il faudrait qu’il soit simple, adaptable, compréhensible. Adapté aux petites structures comme aux grandes.
Qu’il serve de base de travail, quitte à le modifier en profondeur. Et que cet article soit le plus autoporteur possible, aussi. Et le plus droit au but !
Et bien sûr, nous nous portons disponibles pour toute explication à l’oral, n’hésitez pas à nous contacter !
Let’s begin : Quelles sont les besoins et les rôles ?
Vous savez à quoi on reconnaît l’architecte ? C’est celui qui à chaque fois demande “Quel est le besoin ?”. Besoins et rôles sont très liés.
Faisons simple alors et voici donc la liste des rôles (à raccourcir ou à compléter selon vos besoins) :
De Small à Large Governance – La bonne taille de tee-shirt pour votre gouvernance !
Via notre expérience empirique, les besoins de gouvernance peuvent être très simples comme très larges. De plus, un même rôle peut être attribué à une ou plusieurs personnes à temps plein, comme on peut avoir un pool de personnes portant la même casquette de responsabilité. C’est avant tout une question de charge. Nous évoquons ce sujet, car c’est souvent par la question “Qui va s’occuper de quoi” qui vient en premier. Alors que c’est la question qui devrait arriver à la fin seulement. Quel est le besoin ? Quel est le besoin ? Et… Quel est le besoin ? Le besoin d’une gouvernance, c’est de définir les rôles et interactions, par rapport aux enjeux que l’on a. Savoir qui fait quoi, ce n’est que de la déclinaison opérationnelle de ce qui doit être pensé en amont.
Bref, par rapport aux rôles vus dans le schéma centralisé, quels sont ceux qui sont utiles, ou pas vraiment utiles ?
Après décentralisé/centralisé, c’est à nos yeux la deuxième question !
Maintenant voyons comment ces rôles s’agencent.
Nous les avons découpés en trois catégories :
Think – On réfléchit aux APIs futures, et au futur de la plateforme ;
Design – On designe les APIs ;
Build & Run – On les implémente, et on suit le run.
Ensuite selon la taille des équipes et des ambitions, nous avons défini trois tailles de gouvernance.
La large, pour plus de 40 personnes
La médium pour 15-40 personnes :
Et la small pour moins de 15 personnes :
Centralisé ou décentralisé ?
Grande question à se poser. Et c’est un grand débat ! Nous sommes chez Rhapsodies assez fan des organisations décentralisées, ne serait-ce que parce que c’est ainsi que nous sommes organisés. Certes. Mais les organisations décentralisées évitent les bottlenecks organisationnels. Y compris dans les grandes organisations. Néanmoins, les contraintes de spectre de compétences, de maturité, peuvent faire pencher la balance vers une organisation centralisée. Il n’y a pas forcément de règle tacite qui saurait dire rapidement. Disons que l’on peut chercher au début à avoir une équipe centralisée d’API Management, pour ensuite progressivement décentraliser au fur et à mesure de l’augmentation de la maturité des équipes. Ce qui s’entendrait parfaitement. Mais en gros cela change quoi centralisé ou décentralisé?
Pour ceux qui verraient flou en regardant cette image, nous allons la faire simple.
En centralisé, l’équipe API s’occupe de tout – La définition, la roadmap, l’implémentation, la mise en production, etc.
En décentralisé, l’équipe API ne s’occupe que du cadre (frameworks techniques, documentaires, organisationnels, validation des APIs définies). Tout le reste, c’est aux équipes projets de le faire.
Et forcément, les tâches à minima des équipes API varient du coup.
En centralisé nous avons ce scope de responsabilités (qui les contiennent toutes) :
Quand en décentralisé, forcément le scope est plus restreint (et du coup l’effet bottleneck est beaucoup moins élevé) :
Et forcément l’effet bottleneck est beaucoup moins élevé. C’est en tout cas à nos yeux une grande étape de la réflexion. L’autre étape étant de visualiser la charge et les enjeux que vous pouvez avoir.
Ah ! Et point important ! Les rôles que nous mettons sont bien à voir dans l’idée d’une organisation totalement centralisée, ou totalement décentralisée. A vous de ventiler les rôles que vous voyez dans le schéma centralisé dans votre propre organisation, pour identifier quel rôle sera centralisé ou non.
Conclusion
Retraduisons, un framework, c’est un cadre de travail. Rien ne vous empêche de l’alléger ou de le surcharger. Vouloir l’exécuter tel quel serait un non-sens, car vous devez l’adapter à vos besoins. Nous espérons en tout cas qu’il vous aidera à y voir plus clair sur les besoins de gouvernance récurrents dans le monde des APIs. Et n’hésitez pas à nous contacter pour avoir nos retours voir même les vôtres !
Les 3 & 4 juin derniers a eu lieu l’événement du Marcus Evans sur l’évolution de l’Architecte d’Entreprise. C’était l’occasion pour nous d’y animer la table ronde HIP. Elle a donné lieu à un échange passionnant entre Fabrice Legoeffic (Chief Architect Sephora) et Ibrahima Ndiaye (CTO La Fabrique Digitale RATP/Architecte d’entreprise) sur 4 enjeux clés :
Maturité HIP : Deux approches, un même défi
Premier constat : chacune des deux organisations est consciente des enjeux liés à la nécessité d’adopter une stratégie d’intégration polyvalente et avance à son rythme selon ses contraintes, ses priorités projets et son niveau de maturité.
RATP : La transition est en cours du point-à-point vers l’API management, avec un fort enjeu de conduite du changement interne. L’intégration avec un écosystème partenaire est un moteur pour monter en maturité (standardisation et normalisation).
Sephora : À date, chaque zone géographique dispose de sa propre stratégie d’intégration, de ses socles. L’objectif moyen terme est de rationaliser, d’avoir une approche commune avec une convergence des socles (WebMethods, APIM, Kafka), avec une interrogation persistante sur le Target Operating Model (global vs région).
Temps réel : Pragmatisme avant tout
Le temps réel n’est plus un mythe technologique, mais reste un défi d’adoption métier.
RATP : certains systèmes offrent une réponse en quasi temps réel, mais l’information temps réel reste un défi. La RATP se focalise sur la valeur métier (flux voyageurs, maintenance) plutôt que sur la technologie
Sephora :une approche différenciée US / Europe. Les US sont très orientés temps réel vs APIs en Europe. Ici encore, il ne s’agit pas de faire du temps réel à tout prix, il est mis en œuvre sur les use cases qui s’y prêtent (click & collect, pilotage vente magasin) via une fondation Kafka. Il s’agit d’un gros changement de paradigme qui change les habitudes projets. Par ailleurs, l’intégration temps réel avec les SaaS (…) n’est pas simple, elle dépend fortement de leurs demies interfaces techniques disponibles.
Sécurité : Architecture défensive
La sécurité by design devient incontournable dans les stratégies d’intégration modernes.
RATP : Une segmentation stricte pour les infrastructures critiques (SI industriel vs SI Digitale vs SI de gestion), un équilibre entre interopérabilité et sécurité.
Sephora : Sécurité by design, la Sécurité est impliquée le plus en amont possible des projets. Garantir l’isolation multi-marques et la gestion stricte des données personnelles est une obligation stricte. Le middleware d’intégration, notamment l’API Gateway joue un rôle clé dans la sécurisation de l’exposition de nos services.
Résilience : Flexibilité et pragmatisme
L’avenir appartient aux architectures qui savent s’adapter sans tout révolutionner.
Consensus : L’IA ne remplacera pas les mécanismes d’intégration à court terme
Clé du succès : Best of Breed équilibré, éviter l’ultra-centralisation, conserver les connecteurs natifs quand pertinents
Insight majeur : La réussite d’une stratégie HIP repose autant sur l’accompagnement du changement que sur les choix technologiques !
Transformation de l’Architecture d’Entreprise 2025 : De la Gouvernance à l’Influence
Transformation de l'Architecture d'Entreprise 2025 : De la Gouvernance à l'Influence
Synthèse approfondie de l’événement Marcus Evans du 4 juin 2025
Une Révolution Paradigmatique
L’événement Marcus Evans des 3-4 juin 2025 a marqué un tournant décisif dans l’évolution de l’architecture d’entreprise française. Avec des interventions des architectes de grandes entreprises françaises, l’événement a révélé une transformation fondamentale : le passage d’une approche traditionnelle de gouvernance vers un modèle d’influence proactive.
La Révolution de l’Influence selon un leader du transport public
Le CTO , a présenté la keynote révolutionnaire sur la maximisation de la valeur stratégique . Son message central bouleverse les pratiques établies :
« L’architecture d’entreprise n’est plus seulement une question de cadre, c’est une question d’impact »
Les 4 Piliers de la Transformation
Mission & Batailles : Définir la véritable mission de l’architecte d’entreprise
Gouvernance → Influence : Passer d’une approche traditionnelle à une approche plus dynamique
Outils d’Action : Comment passer à l’action avec des outils et déclencheurs concrets
Call to Action : Favoriser l’adhésion plutôt que le contrôle
L’architecte moderne ne cherche plus à tout contrôler mais à influencer intelligemment : « Nous n’avons pas besoin de tout contrôler, nous devons influencer les bonnes choses et les bonnes personnes ».
Cette approche repositionne l’architecte comme un catalyseur de transformation plutôt qu’un gardien de processus.
L’Évolution du Rôle de l’Architecte
Le cas d’un leader mondial de la cosmétique : Maîtriser la Convergence Globale-Locale
Présentation d’une étude de cas sur l’organisation matricielle de l’architecture d’entreprise d’un leader mondial de la cosmétique.
Avec 3 000+ points de vente dans +30 marchés , cette entreprise illustre parfaitement les défis de convergence à l’échelle mondiale.
Niveau 2 – Principes Alignés : Principes communs, exécution autonome
✚ Cohérence stratégique
⊖ Risque de divergence technique
Niveau 3 – Technologies Partagées : Technologies communes, opérations indépendantes
✚ Économies d’échelle, réduction OPEX
⊖ Support business fort requis
Niveau 4 – Assets Réutilisés : Composants communs, adaptations locales
✚ Accélération déploiement
⊖ Gouvernance robuste nécessaire
Niveau 5 – Instance Globale : Solution unique, efficacité standardisée
✚ OPEX minimal, convergence business
⊖ CAPEX initial élevé
Vision Inspirante
Ce leader de cosmétique, s’inspire d’Antoine de Saint-Exupéry : « As for the future, your task is not to foresee it, but to enable it » , positionnant l’architecture comme un enabler du futur plutôt qu’un simple gestionnaire du présent.
Implication Précoce : Être impliqué dès le début du processus
Approche par les Risques : Travailler le besoin avant la solution technique, avec une approche par les risques après les enjeux business
Amélioration Continue : S’appuyer sur les assets transverses et améliorer le socle en continu
Développement Durable : La Nouvelle Priorité Stratégique
Impact Environnemental du Numérique
La table ronde du 4 juin , modérée par Philippe Bucco (Club Urba-EA) , a positionné le développement durable comme priorité stratégique .
Chiffres Clés Révélateurs
Équipements Utilisateurs : 72% des impacts de réchauffement climatique , avec des impacts majoritairement répartis entre fabrication et utilisation
Centres de Données : 46% de l’empreinte carbone du numérique , représentant 11% de l’électricité française (51,5 TWh)
Réseaux : La phase d’utilisation concentre les impacts
Gouvernance Éco-Responsable
Besoin urgent d’une gouvernance pour prioriser les projets à impact environnemental minimisé et écarter ceux jugés « déficitaires ».
Impact IA non comptabilisé : Les impacts de l’arrivée de l’IA ne sont pas encore comptabilisés , nécessitant une anticipation stratégique.
Excellence Opérationnelle
Transformation vers un Modèle Éditeur
Le Directeur Architecture d’Entreprise de ce leader du transport voyageurs, a présenté la réussite de son organisation dans sa transformation vers un modèle éditeur Loading…
Transformation de l’Architecture d’Entreprise 2025 : De la Gouvernance à l’Influence
De la Gouvernance à l'Influence
L’avenir appartient aux architectures qui savent s’adapter sans tout révolutionner.
Synthèse approfondie de l’événement Marcus Evans du 4 juin 2025
🎯 Introduction : Une Révolution Paradigmatique
L’événement Marcus Evans des 3-4 juin 2025 a marqué un tournant décisif dans l’évolution de l’architecture d’entreprise française. Avec des interventions de leaders comme Ibrahima Ndiaye (RATP Groupe), Fabrice Le Goëffic (Sephora), et Simon Fournier (SNCF Connect & Tech), l’événement a révélé une transformation fondamentale : le passage d’une approche traditionnelle de gouvernance vers un modèle d’influence proactive.
🌟 La Révolution de l’Influence selon RATP Groupe
Le Nouveau Paradigme d’Ibrahima Ndiaye
Ibrahima Ndiaye, CTO Fabrique Digitale chez RATP Groupe , a présenté la keynote révolutionnaire sur la maximisation de la valeur stratégique . Son message central bouleverse les pratiques établies :
« L’architecture d’entreprise n’est plus seulement une question de cadre, c’est une question d’impact »
Les 4 Piliers de la Transformation
1. Mission & Batailles : Définir la véritable mission de l’architecte d’entreprise
2. Gouvernance → Influence : Passer d’une approche traditionnelle à une approche plus dynamique
3. Outils d’Action : Comment passer à l’action avec des outils et déclencheurs concrets
4. Call to Action : Favoriser l’adhésion plutôt que le contrôle
L’Évolution du Rôle de l’Architecte
L’architecte moderne ne cherche plus à tout contrôler mais à influencer intelligemment : « Nous n’avons pas besoin de tout contrôler, nous devons influencer les bonnes choses et les bonnes personnes » .
Cette approche repositionne l’architecte comme un catalyseur de transformation plutôt qu’un gardien de processus.
🌐 Sephora : Maîtriser la Convergence Globale-Locale
L’Approche Matricielle de Fabrice Le Goëffic
Fabrice Le Goëffic, VP Enterprise Architecture chez Sephora , a présenté une case study remarquable sur l’organisation de l’architecture d’entreprise .
Avec 3 200+ points de vente dans 35 marchés , Sephora illustre parfaitement les défis de convergence à l’échelle mondiale.
Niveau 2 – Principes Alignés : Principes communs, exécution autonome
l ✅ Cohérence stratégique
l ❌ Risque de divergence technique
Niveau 3 – Technologies Partagées : Technologies communes, opérations indépendantes
l ✅ Économies d’échelle, réduction OPEX
l ❌ Support business fort requis
Niveau 4 – Assets Réutilisés : Composants communs, adaptations locales
l ✅ Accélération déploiement
l ❌ Gouvernance robuste nécessaire
Niveau 5 – Instance Globale : Solution unique, efficacité standardisée
l ✅ OPEX minimal, convergence business
l ❌ CAPEX initial élevé
Vision Inspirante
Sephora s’inspire d’Antoine de Saint-Exupéry : « As for the future, your task is not to foresee it, but to enable it » , positionnant l’architecture comme un enabler du futur plutôt qu’un simple gestionnaire du présent.
Les Tensions Identifiées par Bertrand Hug (Groupe SEB)
La session sur l’impact des budgets cybersécurité a révélé des tensions majeures :
l Augmentation des coûts cyber au détriment des projets d’innovation
l Exigences sécuritaires croissantes ralentissant l’innovation
l Phases de validation multiples et contradictoires
Stratégies de Résolution
Implication Précoce : Être impliqué dès le début du processus
Approche par les Risques : Travailler le besoin avant la solution technique, avec une approche par les risques après les enjeux business
Amélioration Continue : S’appuyer sur les assets transverses et améliorer le socle en continu
🌱 Développement Durable : La Nouvelle Priorité Stratégique
Impact Environnemental du Numérique
La table ronde du 4 juin , modérée par Philippe Bucco (Club Urba-EA) , a positionné le développement durable comme priorité stratégique .
Chiffres Clés Révélateurs
Équipements Utilisateurs : 72% des impacts de réchauffement climatique , avec des impacts majoritairement répartis entre fabrication et utilisation
Centres de Données : 46% de l’empreinte carbone du numérique , représentant 11% de l’électricité française (51,5 TWh)
Réseaux : La phase d’utilisation concentre les impacts
Gouvernance Éco-Responsable
Besoin urgent d’une gouvernance pour prioriser les projets à impact environnemental minimisé et écarter ceux jugés « déficitaires ».
Impact IA non comptabilisé : Les impacts de l’arrivée de l’IA ne sont pas encore comptabilisés , nécessitant une anticipation stratégique.
🚀 Excellence Opérationnelle : SNCF Connect & Tech
Transformation vers un Modèle Éditeur
Simon Fournier, Directeur Architecture d’Entreprise , a présenté la réussite de SNCF Connect dans sa transformation vers un modèle éditeur Loading…
######TABLE RONDE ######
🚀 Retour sur la table ronde que nous avons animée : Hybrid Integration Platform (HIP), Interopérabilité & Sécurité : Quelle architecture pour une stratégie orientée business ?
Elle a donné lieu à un échange passionnant entre Fabrice Legoeffic (Chief Architect Sephora) et Ibrahima Ndiaye (CTO La Fabrique Digitale RATP/Architecte d’entreprise) sur 4 enjeux clés :
📊 Maturité HIP : Deux approches, un même défi
Premier constat : chacune des deux organisations est consciente des enjeux liés à la nécessité d’adopter une stratégie d’intégration polyvalence et avance à son rythme selon ses contraintes, ses priorités projets et son niveau de maturité.
RATP : La transition est en cours du point-à-point vers l’API management, avec un fort enjeu de conduite du changement interne. L’intégration avec un écosystème partenaire est un moteur pour monter en maturité (standardisation et normalisation).
Sephora : À date, chaque zone géographique dispose de sa propre stratégie d’intégration, de ses socles. L’objectif moyen terme est de rationaliser, d’avoir une approche commune avec une convergence des socles (WebMethods, APIM, Kafka), avec une interrogation persistante sur le Target Operating Model (global vs région).
⚡ Temps réel : Pragmatisme avant tout
Le temps réel n’est plus un mythe technologique, mais reste un défi d’adoption métier.
RATP : certains systèmes offrent une réponse en quasi temps réel, mais l’information temps réel reste un défi. La RATP se focalise sur la valeur métier (flux voyageurs, maintenance) plutôt que sur la technologie
Sephora :une approche différenciée US / Europe. Les US sont très orientés temps réel vs APIs en Europe. Ici encore, il ne s’agit pas de faire du temps réel à tout prix, il est mis en œuvre sur les use cases qui s’y prêtent (click & collect, pilotage vente magasin) via une fondation Kafka. Il s’agit d’un gros changement de paradigme qui change les habitudes projets. Par ailleurs, l’intégration temps réel avec les SaaS (…) n’est pas simple, elle dépend fortement de leurs demies interfaces techniques disponibles.
🔒 Sécurité : Architecture défensive
La sécurité by design devient incontournable dans les stratégies d’intégration modernes.
RATP : Une segmentation stricte pour les infrastructures critiques (SI industriel vs SI Digitale vs SI de gestion), un équilibre entre interopérabilité et sécurité.
Sephora : Sécurité by design, la Sécurité est impliquée le plus en amont possible des projets. Garantir l’isolation multi-marques et la gestion stricte des données personnelles est une obligation stricte. Le middleware d’intégration, notamment l’API Gateway joue un rôle clé dans la sécurisation de l’exposition de nos services.
🎯 Résilience : Flexibilité et pragmatisme
L’avenir appartient aux architectures qui savent s’adapter sans tout révolutionner.
Consensus : L’IA ne remplacera pas les mécanismes d’intégration à court terme
Clé du succès : Best of Breed équilibré, éviter l’ultra-centralisation, conserver les connecteurs natifs quand pertinents
Insight majeur : La réussite d’une stratégie HIP repose autant sur l’accompagnement du changement que sur les choix technologiques !
Success Story au Maroc
Success Story au Maroc
13 mai 2025
Success Story
Amine Mahfoud Filali
Directeur Rhapsodies Conseil Maroc
Rhapsodies Conseil Maroc a accompagné un client du secteur bancaire.
Contexte et enjeux
Un programme a été lancé pour faire évoluer le SI en désimbriquant le Core Banking existant qui avait été étendu sur trop de fonctions et faire évoluer le SI au global. Le choix s’est porté sur une modularisation du SI, seule solution à même de permettre de répondre aux différents besoins d’évolution.
Rhapsodies Conseil a réalisé un audit sur ce programme et ses différents composants pour analyser les causes du retard et l’alignement sur les bonnes pratiques d’architecture de la cible
A la suite de cet audit, un accompagnement dédié sur l’architecture du programme et son suivi a été mis en place avec des experts de Rhapsodies Conseil.
Mission
Accompagner le programme et les projets au jour le jour
Arbitrer les décisions d’Architecture
Proposer des remédiations de la dette accumulée par les anciens arbitrages
Décrire la cible d’architecture et les paliers
Equilibre des choix entre les briques progicielles et développement
Désimbrication de la vente et de la gestion des produits du Core Banking
Mise en place d’une nouvelle solution de vente et de gestion des contrats
Mise en place d’un référentiel de gestion des produits, des tarifs et de la facturation
Mise en œuvre d’un portail conseiller unifié
Exposition des fonctions de conseil et de vente aux différents canaux
Intégration de ces solutions avec le reste du SI et des partenaires de la banque
Résultats
Un accompagnement dédié au programme par un architecte référent
Capacité d’influer sur les décisions du programme
Capacité d’échange haut niveau avec les éditeurs sur les briques stratégiques du programme
Autres success stories qui pourraient vous intéresser
Terraform, grand favori du public concernant les logiciels d’Infrastructure as Code est connu principalement comme étant Cloud Agnostic. Mais le connaissez-vous réellement ? Terraform c’est près de 5000 fournisseurs de plateformes, infrastructure ou Saas allant bien au-delà du Cloud et un rachat récent soulevant un problématique de souveraineté.
Quelles sont les limites de cet outil qui paraît pouvoir tout faire ? Comment marche t-il et où se trouve sa prévalence par rapport à ses concurrents ? Sa place de favori est déjà remise en question et cette dynamique semble bel et bien en marche..
Le fonctionnement de Terraform ainsi que ses limites
Bien que Terraform soit souvent qualifié d’outil cloud agnostic, cela ne signifie pas pour autant que le même code peut être déployé tel quel sur AWS, Azure ou OVH. En réalité Terraform nécessite une configuration spécifique pour chaque (cloud) provider.
Pour bien comprendre cette nuance, il est essentiel de revenir sur le fonctionnement de Terraform et de clarifier ce que signifie réellement le terme cloud – ou provider – agnostic dans ce contexte.
Terraform utilise le langage HLC (Hashicorp Langage Configuration) pour communiquer avec les plateformes des fournisseurs. Cette communication se fait par le biais d’appels vers les APIs mis en place par ces fournisseurs. En théorie Terraform peut communiquer avec toute plateforme ou service qui expose une API. Mais bien évidemment la plupart des plateformes dont on parle sont intégrées via des “providers Terraform”.
Les APIs des fournisseurs, que ce soit niveau protocole, services exposés, champs requis etc diffèrent les uns des autres entraînant inéluctablement une différence au niveau de la suite d’instructions demandée à Terraform pour chaque provider.
Comme on peut le voir dans l’arborescence suivante, on devra typiquement créer un dossier spécifique à chaque provider, en plus d’un dossier partagé pour des variables plus globales.
Le fait d’avoir tous les providers décrits dans le même projet nous permet d’établir une logique et des conditions sur quand et comment utiliser chaque provider. Terraform a bien évidemment d’autres avantages.
Utilisez pleinement Terraform
On l’a dit Terraform c’est près de 5000 providers dont les solutions souveraines OVH, Scaleway ainsi que les incontournables Kubernetes, Datadog, AWS, GitHub etc.
Cette diversité permet :
De combiner des infrastructures on-premise et cloud, permettant de gérer au même endroit l’intégralité des ressources d’un projet hybride.
En corollaire, optimiser les coûts en mettant en concurrence les services des différents fournisseurs (exp. stockage dans AWS, bases de données dans GCP)
Créer des configurations spécifiques et réutilisables: En choisissant d’exposer certains modules comme point d’entrée, l’équipe OPS ou Opérationnelle peut offrir aux équipes de développeurs une façon simple de créer des ressources en masquant toute la logique propre au fournisseur à l’intérieur desdits modules.
Exemple: Ici on implémente les modules application, database etc avec toute leur complexité “cachée”
De plus, Terraform est de type déclaratif, c’est-à-dire qu’il décrit l’état final de l’infrastructure: l’ordre dans lequel on déclare les ressources n’est donc pas important, ce qui peut faire une préoccupation technique en moins.
Enfin, Terraform permet de réduire la courbe d’apprentissage lors du lancement ou du basculement d’un projet vers de l’IaC.
Nous le verrons dans les lignes suivantes, l’IaC est également une façon non négligeable d’optimiser ses ressources.
Optimisation des ressources, résilience et numérique durable
Les outils d’IaC quels qu’ils soient permettent de décrire comment construire et donc reconstruire une infrastructure simplement en exécutant un code. Cette facilité offre de la résilience: si l’infrastructure est corrompue, il suffit de la reconstruire en ré-exécutant le code versionné “avant incident”.
Un autre avantage est qu’on peut se permettre de détruire totalement notre infrastructure au moment où l’on en a pas besoin, pour la reconstruire aussitôt que le besoin s’en re-fait sentir. Cela implique que l’on peut supprimer notre environnement de dev ou de pré-prod le week-end ou le soir en fin de journée pour la reconstruire à l’identique le lundi matin.
Cette économie de ressources génère des optimisations financières notamment pour les services facturés à l’heure et une utilisation plus responsable des ressources.
Souveraineté de la plateforme
L’acquisition récente de Hashicorp (la société derrière Terraform) par IBM pose un problème au niveau de la souveraineté.
Terraform propose trois offres :
Terraform CLI : Communautaire (chacun peut créer/rajouter un provider) et “Open Source” (voir note en fin d’article)
HCP Terraform : Terraform version SaaS, hébergé sur la plateforme Cloud de Terraform: la Hashicorp Cloud Platform
Terraform Enterprise : La version hébergeable dans nos propres datacenters ou cloud privés.
En matière de souveraineté, la discussion s’articule ici autour de la version Communautaire Terraform CLI qui, en plus d’être la plus populaire, est la seule qui ne soit pas propriétaire.
Ce rachat de Terraform par IBM donc, pourrait entraîner des changements de licences dans la version communautaire. Le mot d’ordre pourrait peu à peu devenir l’accroissement des bénéfices commerciaux au détriment de la communauté Terraform.
Et pour cela, pas forcément besoin d’un revirement de situation à 180°, des décisions à priori anodines pourraient contraindre la liberté d’agir sur la version communautaire et ainsi inciter à se tourner vers les versions payantes.
De plus, IBM ayant également sa propre plateforme Cloud, l’entreprise pourrait mettre celle-ci en avant, au détriment du multi-cloud à la Terraform. (1)
A noter le parallèle flagrant avec le rachat de Red Hat par IBM en 2019.
Vous avez la main…
La souveraineté des données est une préoccupation majeure de notre temps et force est de noter que la communauté est très résiliente à s’efforcer de proposer des solutions Open Source dès lors que celle-ci est menacée.
Depuis le changement en 2023 de la license de Terraform CLI, la version “Open Source” de Terraform vers la license BSL (Business Source License) qui restreint les usages à but de compétition commercial directe, une solution dérivée nommée Open TOFU a vu le jour et continue de prendre de l’ampleur avec le rachat récent.
Il est vrai que IBM assure à ce jour sur le site Hashicorp que Terraform CLI restera “Always Free”, mais les adages “la confiance n’exclut pas le contrôle”, “il ne faut pas pas mettre tous ses oeufs dans le même panier non souverain”, ainsi que le principe du “zero trust”, sont autant de beaux préceptes qu’il serait prudent de garder à l’esprit.
