Article

Comment une plateforme peut-elle servir de fondation à votre futur SI ?

Dans un article précédent, nous avons partagé l’intérêt d’adopter une approche plateforme. Par sa capacité à agréger des contenus ou services, la plateforme permet à l’entreprise d’élargir sa proposition de valeur et de proposer à son client une réponse plus pertinente à ses besoins. Dans cet article, nous allons mettre en avant des prérequis techniques de la plateforme et montrer comment elle peut servir de fondation à votre futur SI.

1. L’accès

La plateforme a pour finalité de connecter un client à des services ou des contenus, par nature hétérogènes. Sa première obligation est qu’il soit aisé d’y entrer : côté front office, que l’utilisateur accède aux services ou contenus demandés de manière fluide; côté back-office, que l’intégration de ces contenus et services - en partie extérieurs à l’entreprise -, soit facilitée par des interfaces d’échange normalisées avec la plateforme.

En clair, il faut que les API (Application Programming Interface) de la plateforme présentent une certaine homogénéité et, idéalement, qu’elles se conforment au standard de l’OpenAPI, qui fait office de norme en la matière. Pour y parvenir, la meilleure solution consiste à insérer une couche de transcodage entre la plateforme et les API tiers pour faire abstraction des hétérogénéités et défauts de normalisation de ces dernières.

2. L’API management

Cette couche, appelée API management, est une brique centrale de la plateforme. Au-delà de sa fonction de normalisation, elle se voit attribuée plusieurs autres rôles. Elle a ainsi pour tâche d’anonymiser les flux d’information qui traverse la plateforme pour garantir la confidentialité des échanges entre le client et le service. Elle peut aussi être le point de collecte des indicateurs d’usage de la plateforme et permettre ainsi sa monétisation. Elle joue également un rôle clé dans la sécurisation du dispositif.

3. La sécurité

La sécurité des accès, la protection des données et la résilience aux attaques sont évidemment des enjeux cruciaux. Même si chaque service se protège individuellement, il est important de prévoir la sécurité de la plateforme d’un point de vue global. Et c’est naturellement au niveau de l’API management que cela se passe. L’API management contient les politiques de sécurité qui protègent la plateforme contre les cyberattaques et qui la placent en conformité par rapport aux principes et standards de sécurité usuels tels que ceux édictés par l'OWASP (Open Web Application Security Project). C’est aussi elle qui gère les règles d’authentification des utilisateurs de la plateforme.

4. La résilience

Au-delà des aspects de sécurité, la plateforme doit aussi assurer sa résilience face à la défaillance éventuelle de ses composants. Plusieurs moyens permettent d’y parvenir :

• Tout d’abord, préférer une architecture en micro-services. Avec ce type d’architecture, les services proposés fonctionnent de manière autonome, avec leurs propres ressources (bases de données, serveurs virtuels, etc.). Un dysfonctionnement sur un service ne produit ainsi pas d’effet critique sur les autres. Il est possible d’augmenter encore la tolérance aux pannes en doublonnant les micro-services.
• Privilégier l’utilisation d’un système d’échange de messages asynchrone. Un bus asynchrone, qui conserve les messages destinés au service défectueux et les réémet dès son rétablissement, ajoutera de la robustesse à l’ensemble.
• Prévoir un protocole de remédiation qui permet à la plateforme de se relancer automatiquement au dernier point de contrôle.
• Mettre en place un dispositif de disjoncteur, qui alertera le fournisseur et/ou l’utilisateur en cas de défaillance du composant appelé.

5/ La capacité d’expansion (scalabilité)

L’architecture en micro-services présente un autre atout : elle facilite le développement fonctionnel de la plateforme. Isolés dans des containers, les micro-services peuvent se déployer un à un, indépendamment les uns des autres et sans avoir à redimensionner la plateforme. On peut les faire évoluer, les corriger ou en ajouter de nouveaux, en parallèle, sans impact sur les autres services. Comme le code de chacun d’entre eux est léger, les développeurs peuvent, en outre, apprendre à les maîtriser progressivement. La plateforme bénéficie, par ailleurs, de l’élasticité du cloud qui permet d’adapter les capacités aux variations de charge.

Dans certains cas de figure, où des pics de connexion importants sont à prévoir, une architecture de type Function as a Service peut s’envisager pour les services concernés par la forte variabilité. Avec ce type d’architecture, la gestion des capacités permettant à la plateforme de tenir la charge revient en effet entièrement à l’opérateur de cloud.

Vers le SI de demain

On le voit, une plateforme contient tous les ingrédients de base d’un système d’information, et une approche moderne. Construire une plateforme, c’est ainsi une opportunité de poser les fondations de votre futur SI. Et de le construire progressivement, brique par brique, projet par projet, en activant les nouveaux services dans le cloud, au fur et à mesure du décommissionnement des anciens. Et cela, en limitant le risque.