Services de sécurité managés : le RSSI n’est pas seul responsable
Benedikt Langer
8 Min. de lecture Dans de nombreuses entreprises, le CISO est perçu comme le responsable de la sécurité. ...
Lire l'article
En bref
L’essentiel en bref
- Le Composable Enterprise remplace les architectures IT monolithiques par des modules flexibles, qui peuvent être combinés et échangés à volonté.
- Selon Gartner, les entreprises adoptant une architecture composable déploient de nouvelles fonctionnalités 80 % plus rapidement que leurs concurrents.
- Les Packaged Business Capabilities (PBC – capacités métiers packagées) et une approche API-first constituent les piliers techniques de cette méthode.
- L’adoption se fait via un modèle Strangler Fig : plutôt que de remplacer les monolithes, on les complète progressivement par des composants modulaires.
- Pour les DSI, le Composable Enterprise ne rime pas avec une complexité accrue, mais avec une moindre dépendance aux fournisseurs et un time-to-value plus rapide.
Tout DSI a déjà vécu ce scénario : un nouveau modèle économique exige une adaptation technique – et le service informatique annonce que cela prendra 18 mois. Dans un monde où les conditions du marché évoluent en quelques semaines, c’est une condamnation à mort.
Le Composable Enterprise apporte une réponse architecturale à ce défi. Au lieu de systèmes monolithiques, qui nécessitent une refonte complète à chaque modification, il mise sur des briques modulaires, combinables, interchangeables et évolutives comme des pièces de Lego. L’idée n’est pas nouvelle – mais les outils, eux, le sont.
La fin des monolithes
Les systèmes ERP monolithiques, qui représentaient l’état de l’art il y a 15 ans, deviennent aujourd’hui un risque stratégique. Difficiles à maintenir, coûteux à mettre à jour et incapables de suivre le rythme des entreprises, ils montrent leurs limites.
Le problème ne réside pas dans la technologie elle-même – SAP, Oracle et Microsoft développent des logiciels de qualité. Le vrai défi, c’est l’architecture : un système conçu pour tout faire ne peut rien modifier rapidement. Chaque modification risque d’impacter l’ensemble du système, et chaque mise à jour exige des tests de régression approfondis.
L’entreprise composable apporte une réponse à cette problématique grâce à la découplage. Les fonctions métiers sont décomposées en modules autonomes – appelés Packaged Business Capabilities (PBC, ou capacités métiers packagées) – qui communiquent via des API, mais peuvent être développés et déployés indépendamment les uns des autres.
Les Packaged Business Capabilities en pratique
Les PBC (Packaged Business Capabilities) ne se résument pas à des microservices dotés d’une étiquette marketing. Elles encapsulent une capacité métier complète – par exemple, le traitement des paiements, la gestion des stocks ou la communication client – incluant les données, la logique métier et les interfaces API.
La différence avec une approche API classique ? Les PBC sont prêtes à l’emploi et interchangeables. Si vous devez changer de prestataire de paiement, il suffit de remplacer le PBC concerné, sans que le système de commande, la comptabilité ou le reporting n’en soient affectés.
En pratique, cela se vérifie chez des entreprises comme IKEA, qui a migré son e-commerce vers un modèle composable. Résultat : les boutiques en ligne pour de nouveaux pays peuvent être lancées en quelques semaines au lieu de plusieurs mois, car les briques fonctionnelles existent déjà et n’ont plus qu’à être reconfigurées.
La stratégie d’entrée : le Strangler Fig Pattern plutôt que le Big Bang
La plus grosse erreur dans les initiatives composable ? Vouloir tout remplacer d’un coup. La meilleure approche s’inspire du Strangler Fig Pattern – littéralement, le « modèle du figuier étrangleur » – ces arbres tropicaux qui enveloppent peu à peu leur hôte jusqu’à le supplanter.
La méthode : identifier la fonction métier soumise à la plus forte pression de changement. L’isoler sous forme de Packaged Business Capability (PBC) autonome. La relier au monolithe existant via des API. Puis répéter l’opération.
Au bout de 12 à 18 mois, les fonctions critiques sont modularisées, tandis que le cœur de l’ancien système continue de tourner sans heurt. L’avantage face à une refonte Big Bang ? Le risque se dilue en une série de petites étapes, plutôt qu’en un seul saut dans l’inconnu.
Ce que les DSI doivent trancher dès maintenant
Le Composable Enterprise n’est pas une décision technologique, mais bien une décision organisationnelle. Il exige des équipes capables d’agir en autonomie, de considérer les API comme des produits à part entière et d’assumer la responsabilité de l’intégralité du cycle de vie d’un Packaged Business Capability (PBC – capacité métier packagée).
Trois questions stratégiques à poser lors de la prochaine réunion du comité de direction : premièrement, quelles fonctions métiers nous freinent le plus aujourd’hui ? Deuxièmement, quelles dépendances vis-à-vis de fournisseurs uniques représentent un risque stratégique ? Troisièmement, disposons-nous d’une structure d’équipe compatible avec un modèle de travail modulaire ?
La réponse honnête à cette troisième question déterminera le succès ou l’échec du projet. Un Composable Enterprise sans découplage organisationnel, c’est comme une voiture de sport avec le frein à main serré : beau sur le papier, mais impossible à exploiter pleinement.
Questions fréquentes
Le Composable Enterprise n’est-il qu’un nouveau terme pour désigner les microservices ?
Non. Les microservices représentent une implémentation technique, tandis que le Composable Enterprise est une stratégie commerciale. Les Packaged Business Capabilities (PBC) – ou capacités métiers packagées – peuvent s’appuyer en interne sur des microservices, mais elles encapsulent une fonction métier complète, et non un simple service technique. L’accent est mis sur l’agilité business, et non sur l’architecture technique.
Quel est le coût de la transition ?
Les coûts initiaux dépassent généralement de 10 à 20 % ceux d’une mise à niveau comparable d’un monolithe. Le retour sur investissement intervient après 18 à 24 mois, grâce à des cycles de développement plus rapides, à une réduction des coûts de maintenance et à la diminution des frais liés au vendor lock-in. À long terme, le Composable Enterprise permet des économies significatives.
Quelles entreprises en tirent le plus grand profit ?
Les entreprises soumises à une forte pression de changement : e-commerce, services financiers, médias, et toute organisation opérant sur plusieurs marchés. Plus les exigences métiers évoluent fréquemment, plus les avantages d’une architecture modulaire sont importants.
Contexte DACH : Dans l’espace germanophone (Allemagne, Autriche, Suisse), ces secteurs sont particulièrement dynamiques, avec une forte adoption des technologies agiles pour répondre aux attentes des clients et aux réglementations locales, comme la DSGVO (RGPD en français).
Avez-vous besoin d’une équipe Platform Engineering pour cela ?
Oui, à partir d’une certaine taille. Le Platform Engineering fournit l’infrastructure commune sur laquelle les équipes PBC peuvent travailler de manière autonome. Pour démarrer, une petite équipe de trois à cinq personnes suffit, chargée de gérer la passerelle API, la supervision et les pipelines de déploiement.
Peut-on combiner SAP et Composable Enterprise ?
Oui. SAP soutient explicitement une stratégie Composable via sa Business Technology Platform (BTP) et son approche Clean Core. Les extensions sont développées sous forme de modules indépendants sur la BTP, plutôt que de modifier le cœur de SAP. C’est la voie recommandée pour les clients SAP.
Contexte réglementaire : Cette approche est particulièrement pertinente dans le contexte des réglementations européennes, comme le Digital Operational Resilience Act (DORA), qui impose une plus grande résilience et flexibilité des systèmes informatiques.
Source de l’image d’en-tête : Unsplash / Shubham Dhage