Par Paul ESTRACH, Directeur Marketing Produit chez MEGA International
A juste titre attractif, le Cloud peine à trouver un écho significatif dans le métier de l’assurance. Mais c’est avant tout encore le choix du matériel pour du matériel existant ou neuf. Il doit donc être traité comme tel, notamment en cas de migration d’applications existantes, suivant une approche objective et une stratégie claire dans laquelle le business planner doit être impliqué. Les questions de gouvernance et de sécurité doivent être prises en compte avant l’adoption.
Devenu une véritable philosophie, « Just the cloud » semble gagner l’adhésion d’un nombre croissant d’organisations. Cependant, les porteurs de risques l’acceptent lentement. Pour l’auteur : la migration complète de tout le système d’information vers le cloud sans aucune différence est une option souvent inadaptée. La décision de « zapper » tout constructeur d’architecture métier, ce qui équivaut à sous-estimer l’ensemble des processus SI et à gommer leurs principales différences : valeur métier, cycle de vie, complexité et, bien entendu, la compréhension des données traitées.
Et plus encore parce que les projets cloud sont loin d’être neutres sur le plan budgétaire. Le choix du cloud n’est pas une démarche à prendre à la légère : il peut prendre tout son sens pour certaines applications, et ne pas être utile du tout, voire s’opposer à d’autres. L’éducation doit se faire par application : une partie naturelle pour un développeur d’affaires.
1 – Gérer les éléments essentiels de l’infrastructure cloud : valeur commerciale et cycle de vie
L’utilité pour les équipes métiers – alias valeur métier, est naturellement la première chose à mesurer pour une migration vers le cloud : pourquoi construire un projet pour une application qui a très peu d’utilité ou une valeur faible en métier ? En revanche, les applications métier de base gagnent en durabilité, en efficacité, en flexibilité et en clarté en passant au cloud. C’est toute la promesse de cette option : passer moins de temps sur l’infrastructure pour consacrer plus de temps à l’amélioration des performances.
Cette valeur se mesure également dans le temps : l’application métier d’origine en fin de vie, quelle que soit sa valeur, ne migrera pas mais sera remplacée par une application « cloud native ». En revanche, les applications encore immatures ou instables (fonctionnelles ou techniques) ne doivent pas être une priorité pour la migration vers le cloud. Dans ce cas, le business developer pourra évaluer la durée de vie de chaque application pour déterminer l’importance de démarrer le projet de migration.
2 – La complexité de l’application, déterminant la charge du projet
Si le projet de migration est loin d’être neutre pour l’organisation, il le sera moins si l’application concernée devient complexe. La complexité se mesure tout d’abord en fonction des caractéristiques de l’application elle-même : la technologie utilisée pour son développement, le niveau d’un certain développement ou d’une opération spécifique, etc.
La mesure de ces composants permet d’évaluer la charge de travail de la DSI et des équipes métiers, qui sont amenées à participer à la migration, selon les types de stratégie possibles : « rehosting » (rehosting ou basculement), « replatforming » ( vers une plateforme cloud native), « rachat » (nouveau produit), « refactoring » (ou restructuration de la structure). Au contraire, il peut également être décidé d’annuler l’application (« remove the job ») ou de la conserver telle quelle (« save »). Ensemble, ces 6 stratégies (« 6R ») rendent possibles les choix pour la migration vers le cloud.
Mais la complexité de l’application s’évalue aussi par sa position dans le système d’information et son articulation avec les autres parties du système d’information. Ainsi, CRM ou ERP est de nature complexe, en raison de l’intégration avec de nombreux autres processus, même avec l’environnement de l’entreprise. Cela rend également la migration difficile. Là encore, le travail de l’architecte métier selon la cartographie du SI est un outil important d’évaluation des opportunités de migration.
3 – Sensibilité des données : gestion des risques et de la conformité
En fin de compte, ce sont aussi les données qui devront guider les choix d’une organisation en matière de migration vers le cloud. Car cette démarche est loin d’être anodine en termes de gouvernance, de gestion des risques et de conformité (GRC). Dans certains cas, cela n’est pas possible, du moins dans les clouds publics : parties sensibles du processus, employés importants d’importance (OIV) ou employés des services essentiels (OSE), administration publique, etc.
La migration des données vers le cloud devenant possible, quel que soit le secteur concerné, l’architecte métier devra assurer une gestion efficace des aspects de sécurité : gérer ses processus, ni avec ses données, ne signifie pas assurer la protection complète des EST à une autre partie. Il s’agit plutôt d’être doublement vigilant.