Pour une entreprise, l’adoption du cloud se traduit par le passage d’un parc applicatif où les applications sont hébergées sur des serveurs et gérées par l’entreprise ou son infogérant, vers un parc applicatif hébergé sur le Cloud, les plus connus étant Azure, AWS, Google et OVH. Dans ce nouveau cadre, les responsabilités sont partagées entre l’hébergeur cloud, les éditeurs de solution et les utilisateurs.
Ces transformations majeures impliquent la mise en place d’une stratégie dédiée, la réalisation de migrations d’applications et de migrations de données. Ces projets sont souvent menés par les DSI et ont un impact considérable sur les métiers, réels utilisateurs des solutions et projets déployés, dans les projets de transformation cloud. La participation active au projet des interlocuteurs métier est donc indispensable, et ce lors de 3 étapes clés.
Etape 1 du passage au cloud : Réfléchir autour des données
L’un des plus grands avantages du cloud, c’est de mettre à disposition pour tout le monde un très grand nombre de solutions. Pour choisir la solution qui répondra aux besoins spécifiques de l’organisation, les premières questions concernent les données qui vivront dans l’application. Les données sont le cœur de tout projet. Trois questions sont incontournables :
- Quelles seront les données d’entrées et les données de sorties ?
- D’où proviennent-elles ?
- Quelle est la volumétrie de données attendue ?
Les réponses à ces questions vont permettre de poser un premier cadre sur le projet et d’identifier les points clés attendus. La difficulté du projet se situe-t-elle dans le process, dans le besoin, dans la restitution, dans la transformation des données ou la volumétrie ?
Par exemple, pour construire un tableau de bord via Power BI ou Tableau pour piloter l’activité, la question doit porter sur la volumétrie des données en jeu. Dans le cas d’une faible volumétrie de données, il est possible de travailler directement avec les outils BI. En revanche, si la volumétrie est très importante, alors il faudra coupler la solution BI avec d’autres outils pour prétraiter les données (Data Bricks, Knime, Alteryx …). Ne pas se poser ces questions et se lancer directement dans des rapports BI fait peser un risque de maintenance de la solution déployée.
Les réponses à ces questions préalables vont permettre d’identifier un premier panel de solutions. Un deuxième volet de questions concerne les contraintes associées aux solutions cloud :
- A quel point les données utilisées sont critiques ?
- Y a-t-il des données personnelles ou soumises à une réglementation ?
La réponse à ces questions va permettre d’éliminer certaines solutions qui ne seront pas alignées avec la politique de risque interne ou la réglementation s’appliquant aux données concernées. Cela écarte le risque de focaliser les efforts sur un projet qui sera bloqué par la suite. Ainsi, si le projet contient des données personnelles (données de santé par exemple), celles-ci ne pourront pas être stockées à l’autre bout du monde et l’hébergeur cloud doit être en mesure de fournir des certifications adéquates. Dans le cas de l’hébergement de données de santé, des certifications spécifiques doivent être demandées à l’hébergeur, comme l’ISO 27001.
Cette première étape permet ainsi d’identifier les solutions pertinentes et les choix technologiques à privilégier. Elle permet également d’éliminer rapidement les solutions où un verrou réglementaire important pourrait survenir.
Etape 2 du passage au cloud : définir les rôles et responsabilités cibles
Le passage au cloud conduit à déléguer une partie des responsabilités associées à tout projet informatique. Ces délégations, plus ou moins fortes, dépendent grandement du mode d’hébergement choisi : SaaS, PaaS ou IaaS, que nous expliquons ci-dessous :
Pour choisir l’hébergement qui répond le mieux aux objectifs du projet, il convient avant tout de définir les besoins mais aussi les perspectives d’évolution. Par rapport aux besoins identifiés, la version standard peut-elle convenir ? Ou faudra-t-il réaliser du paramétrage spécifique, par exemple un changement de modèle de données ou la mise en place d’un système très puissant et très rapide ?
Souvent, les solutions sont accessibles sur le cloud avec différents modes d’hébergement. En fonction du degré de personnalisation souhaité, le projet s’orientera vers du SaaS, du PaaS ou du IaaS.
Un très bon exemple que nous rencontrons régulièrement chez les assureurs est l’application SAP BO, qui peut être implémentée avec différents types d’hébergement :
- Une solution SaaS, où le vendeur SAP gère l’intégralité des fonctionnalités listées ci-dessus
- Une solution IaaS, cogérée par SAP et les utilisateurs de l’application
Dès lors, les principales questions à se poser avant de choisir la solution d’hébergement concernent :
- la gouvernance : comment seront déléguées les responsabilités ? Quel RACI mettre en place ?
- La tarification & le ROI : la délégation des responsabilités implique généralement des écarts de tarification. Les écarts de coût peuvent être importants. Dès lors, il est fortement conseillé de réaliser une étude préalable de comparaison de coûts.
- Les compétences Cloud : les équipes internes détiennent-elles les compétences pour gérer et maintenir les différentes fonctionnalités associées à un hébergement des applications en mode PaaS ou IaaS ? Si ce n’est pas le cas, cela peut constituer un verrou important dans la maintenance des applications dans le cloud. Il sera alors préférable de basculer vers des solutions SaaS.
Toutes ces questions sont structurantes dans la mise en place du projet et vont définir la route suivie pour l’entièreté du projet. Une bonne anticipation est la clef pour réussir cette étape. Tout retour en arrière sera similaire à un retour au point de départ.
Etape 3 : définir la criticité de l’application
Après avoir identifié la solution et le mode d’hébergement, les métiers doivent être intégrés dans la construction du projet. Cela se traduit par une participation active dans les ateliers définissant l’architecture cible de la solution. Durant ces ateliers, il sera nécessaire d’apporter des éléments permettant de restituer la criticité de l’application. En effet, les métiers sont les plus pertinent pour restituer :
- la criticité des données en jeu : sensibilité, données personnelles…
- la criticité de l’application par rapport aux besoins et activités via l’utilisation d’indicateurs :
- RTO : temps pendant lequel une application peut être en panne ;
- RPO : durée maximale d’enregistrement des données que l’entreprise peut accepter de perdre, sans que cela ne compromette l’entreprise.
Il est important de répondre à ces questions en amont de tout développement, pour définir avec les équipes IT les meilleures bases. Les réponses vont permettre d’amorcer l’architecture associée au projet. Dans le cas où ces questions ne trouvent pas de réponse, alors il y a des chances que le projet se construise sur des mauvaises fondations impliquant des développements non pérennes. L’architecture proposée sera plus ou moins complexe en fonction des besoins énoncés précédemment, plus répondre au besoin de criticité.
Après le choix de la solution, l’étape clé est la réalisation de l’architecture, dont le but est de répondre à l’ensemble des besoins identifiés. Une fois l’architecture dessinée, plus le projet avance, plus le retour en arrière pourra être coûteux. Dès lors, un bon énoncé de ces différentes caractéristiques permettra d’aller rapidement dans la bonne direction, en particulier en ce qui concerne la réalisation des fondations.
