Par Ispahan et Srinagar, avec terminus cumulonimbus ?
Les interrogations ne portent plus, aujourd’hui, sur la pertinence des services Cloud Computing. Ces derniers se sont rendus invisibles, fiables, sécurisés, et surtout indispensables aux utilisateurs finaux. De facto, un nouveau service déployé dans une entreprise est considéré sous sa forme as-a-Service, ne serait-ce que par comparaison avec les solutions traditionnelles.
Si l’interrogation ne porte donc pas sur la qualité intrinsèque du Cloud, c’est bien son intégration au sein d’un paysage de services et solutions existantes qui cristallise les doutes.
Pour être clair : les projets IT traditionnels qui ont structuré les systèmes d’information ces 30 dernières années ont conduit à la création de systèmes interconnectés et complexes dans lesquels il est difficile d’intégrer de nouveaux services.
Alors non, nous n’allons pas vous donner une leçon d’histoire moralisatrice sur les projets d’antan, ou vous vendre les trucs et astuces pour mettre en oeuvre un SI open-service, open-data, open-bar.
Ce que l’on va partager, c’est une approche, teintée d’un retour sur nos expériences en tant qu’intégrateur entre des solutions sur site et des services dans les nuages.
“Un voyage, c’est un ensemble de trajets”
Le déploiement d’un nouveau service est l’opportunité d’échanger avec le métier autour de ses besoins, et surtout de l’impliquer dès l’initialisation dans une évolution de sa façon de travailler (on la touche là, la “transformation numérique”).
Dans ce projet, on inscrit assez naturellement les phases de recueil du besoin métier, les ateliers sur l’interface utilisateur, sur les fonctionnalités mobiles. Tout aussi naturellement, on planifie la reprise des données, la sécurisation, et les phases de test et recette.
On rétro-planifie l’ensemble par rapport à une date cible, et l’on se retrouve avec un joli Gantt.
Puis, arrivé à 60% du projet, l’un des contributeurs évoque le point de l’intégration.
La question arrive innocemment avec la reprise des données, car on s’aperçoit généralement qu’il existe plusieurs référentiels à fusionner et que “ce serait plus pratique si on avait un système avec des données de référence”.
Entre parenthèse, ce système qui existe et qui vit très bien, utilisé par une population spécifique qui n’a pas vocation à utiliser le nouveau service en cours de déploiement.
Souvent, cette question de l’intégration est mise de côté pour des questions de coûts et d’usages non encore identifiés. En effet, l’intégration est un projet à part entière qui couvre non seulement l‘ajout d’un nouveau service, mais surtout sa mise en relation avec un service existant qui n’a peut-être pas été initialement conçu pour être exposé.
La planification de ce projet est d’autant plus critique qu’elle nécessite d’être menée un peu en amont du projet principal, et doit surtout s’inscrire dans une stratégie SI cohérente, et non pas uniquement opportuniste.
“Une caravane a un point de départ et surtout une destination”
En effet, si l’enjeu de l’intégration devient critique, c’est qu’il s’inscrit dans une stratégie plus générale de construction d’un SI interconnecté avec les différents éléments qui le composent, qu’ils soient hébergés au sein des datacenters de l’entreprise ou bien consommés comme un service chez un tiers.
Cela sous-entend que l’intégration n’est pas improvisée, qu’elle est anticipée, et surtout que les modalités avec lesquelles elle est activée répondent à des pratiques clairement définies afin d’en tirer la pleine valeur.
La visée stratégique doit s’engager à répondre à des enjeux métiers IT qui, de par leur nature, dépassent le cadre pur de l’exploitation IT.
Ainsi, cette stratégie doit dépasser l’enjeu immédiat, et souvent imposé, du coût, pour s’inscrire dans une réponse durable, maîtrisée et proactive de l’évolution de l’activité de l’entreprise.
S’agit-il d’accompagner une transformation de la relation client, et donc d’ajouter des services métiers qui, en raison d’objectifs ambitieux de développement commercial, doivent être avant tout opérationnels rapidement ? D’une politique de diversification des fournisseurs pour éviter la dépendance à un fournisseur (comme l’éditeur d’un ERP) ? De l’anticipation d’une mutualisation des services IT entre plusieurs entités ?
Dans cette optique, se rapprocher d’une architecture SOA fait sens : orienter la construction de son SI vers un ensemble de services consommateurs, alimentés par un socle d’éléments de référence à travers des interfaces, des connecteurs et des APIs.
Loin d’être une simple question d’appels APIs, il s’agit surtout de préparer et construire les référentiels de données, les points d’authentification et la sécurité des communications sous la forme d’outils de référence dont l’utilisation s’impose lors du choix de tout nouveau service au sein de l’entreprise.
Ainsi, cette vision stratégique s’appuie sur un état actuel et surtout un objectif à atteindre, en définissant un ensemble de points de passage qui marquent la route à suivre.
Enfin, ce projet doit surtout s’appuyer sur un écosystème (et on ne parle pas là que des référents techniques mais aussi des référents fonctionnels !) à mobiliser : en effet, la vision stratégique de l’enjeu est indispensable mais doit s’inscrire dans une logique de coopération entre les différents intervenants, qu’ils soient internes ou externes à l’entreprise.
“L’avancée d’une caravane est l’affaire de tous”
La vision stratégique donne l’orientation, mais c’est le pilotage opérationnel qui donne le ton des chantiers à mener et de l’implication à générer.
Les phases de préparation et de planification doivent inclure nécessairement les analyses d’impact sur les différents éléments du SI, et surtout engager les responsables de ces éléments, et ce pour toutes les phases.
Un nouveau déploiement va nécessairement induire une phase de test sur différents environnements ; cette phase de tests doit comprendre des tests d’intégration avec le reste du SI. Cela signifie donc que chaque responsable doit se tenir prêt à participer à la bonne tenue de ces tests car la réussite de l’intégration dépend de leur préparation.
Et l’expérience nous a montré que le retard et la sous-estimation des enjeux d’intégration conduit à un projet mal-né, souvent peu performant, et qui demande de très longs mois de support supplémentaires pour arriver à faire émerger une situation acceptable pour tous.
Nous avons plusieurs fois constaté que le manque de préparation sur la question de l’intégration a mené des tensions et surtout à de mauvais fonctionnements du service envisagé initialement. Il est assez gênant en situation client d’avoir des services métiers inutilisables car un système n’est pas prêt à communiquer…
Pour éviter ces écueils, la participation et l’engagement des responsables de tous les services concernés sont indispensables : c’est par leur implication à chaque étape du projet que la réussite va se construire.
Les commentaires transmis lors des phases de développement et d’intégration seront autant d’atouts pour faciliter le déploiement et la mise en production du nouveau service ; tout comme ils seront autant de gages de validation de la stratégie identifiée.
Au final, les chiens aboient et la caravane passe?
Ce que nous défendons chez Nuageo, de par nos expériences, c’est que le SOA ne se décrète pas et surtout, qu’il ne s’agit pas d’un idéal absolu.
Si les concepts qu’il défend ont un intérêt indéniable dans le cadre d’un usage intensif des services Cloud, il faut avant tout définir une approche cohérente et stratégique de l’utilisation actuelle et future de son SI.
C’est à la fois la première et la plus importante condition pour que les différents services de l’entreprise comprennent jusqu’où mènera la route sur laquelle ils sont embarqués, et que notre caravane ne se disperse pas au bruit des chiens qu’elle croisera, inévitablement.
Image d’illustration par David Roberts