5 conseils pour réussir sa migration d’application dans le Cloud

9 janvier 2017

Analyse

Une migration d’application dans le Cloud, aussi basique soit-elle, n’est pas toujours simple à appréhender pour les Directions des Systèmes d’Informations (DSI), même si l’on entend souvent le contraire. De nombreuses variables doivent être prises en compte pour que cette migration soit réussie.
1. Utiliser les fondamentaux de la gestion de projet de migration

Une migration dans le Cloud est finalement un projet de migration de Système d’Information comme un autre ! Il ne faut donc pas négliger les basiques de ce type de projet, et notamment :

  • Tester sa migration. Une vraie bascule expérimentée de bout en bout, sur un échantillon représentatif de données ou d’utilisateurs est nécessaire pour s’assurer du bon fonctionnement et procéder à des éventuels ajustements. Cette bonne pratique soulève un besoin trop souvent oublié lors des migrations vers le Cloud : le besoin d’avoir un (ou même plusieurs) environnements de tests.
  • Une phase de rollback : c’est-à-dire une stratégie de retour arrière en cas d’imprévu pendant la migration. Et ce plan aura évidemment été lui aussi testé.

 

2. Préparer minutieusement la phase de transition 

Dans le cas d’une migration ne se faisant pas en « one shot », il faut anticiper les impacts de la phase de transition pour les utilisateurs, et les informer, en leur proposant des solutions pour limiter les désagréments.

Prenons l’exemple d’une migration progressive vers un nouveau système de messagerie (Office 365 ou Google Apps). Pendant la phase de migration, la DSI doit prévoir une solution pour que les utilisateurs puissent consulter les agendas de leurs collègues ou réserver des salles de réunion, … afin de ne pas affecter le fonctionnement nominal du business.

 

3. Prévoir une authentification simple pour les utilisateurs 

La multitude de login et mots de passe perd les utilisateurs et nuit au final à la sécurité du Système d’Information. Il faut donc prévoir une authentification simple pour les utilisateurs, au nouveau service Cloud : authentification implicite ou, a minima, réutilisation de l’identité déjà utilisée en interne. Techniquement, cela peut se faire de plusieurs manières. L’une d’elle consiste à déployer un service de Fédération d’Identités (comme Microsoft ADFS) dans le Système d’Information.  Elle  facilite la mise en œuvre d’interconnexions avec des solutions Cloud pour cette problématique d’authentification. Une phase qui parait anecdotique, mais qui en réalité, lève un frein important.

 

4. Ne pas négliger la sécurité

 

Le Directeur des Systèmes d’Informations, en partenariat avec son Responsables de la Sécurité des Systèmes d’Informations (RSSI), doit prendre en compte les problématiques de sécurité le plus en amont possible. Cela commence dès la négociation du contrat avec le fournisseur de la solution Cloud. Il vérifie ses engagements sur :

  • la disponibilité du système,
  • les délais d’intervention et de résolution d’incidents,
  • la réversibilité des données (capacité à récupérer les données si on venait à rompre le contrat),
  • l’engagement du fournisseur en terme de protection des données,
  •  les mises à jour en cas de vulnérabilité identifiée, …

Ensuite, au cours du projet, il est nécessaire de faire valider la façon dont le service Cloud va être intégré par le RSSI et prévoir également un audit de sécurité.

 

5. Enfin, accompagner  la conduite du changement  

 

Cela serait une erreur de ne pas prendre en compte les utilisateurs ! Après avoir fait un recueil des besoins exhaustif, il est nécessaire de les impliquer dans le choix de la solution.

Ensuite, une fois le projet lancé, il est essentiel de désigner un porteur métier, le Product Owner, en charge d’arbitrer les choix fonctionnels mais aussi, de « prêcher la bonne parole » auprès des utilisateurs : teasing, bon buzz…

Mais cela ne suffit pas. La communication tout au long du projet est primordiale pour faire adhérer et motiver les utilisateurs, qu’il faut également former et contrôler régulièrement pour assurer le bon usage des systèmes.

Besoin de plus d'informations

Grégory MOTTIER
Grégory MOTTIER

Grégory Mottier est DSI du groupe Hub One. Il a deux passions dans la vie : les nouvelles technologies et la Suède qu’il a découverte lors de sa vie étudiante. On peut qualifier Gregory de Geek ! Il a toutes les technologies possibles et inimaginables : montre connectée, smartphone, ordinateur portable, tablette… Il aime l’innovation, le développement, l’internet des objets et les méthodes agiles. Son gadget préféré : un serveur Rasberry Pi. C’est un micro serveur personnel qui lui permet de faire de la domotique, de la vidéo surveillance, et contrôler ses objets connectés.


Pour aller plus loin

Pour recevoir la documentation Hub One adaptée à vos besoins

Le présent site stocke des cookies et autres traceurs sur votre équipement (ci-après dénommés « cookies »). Ces cookies sont utilisés par Hub One pour collecter des informations sur la manière dont vous interagissez avec le site et établir des statistiques et des volumes de fréquentation et d’utilisation afin d’améliorer votre parcours en tant qu’utilisateur.
Vous pouvez choisir de ne pas autoriser certains types de cookies, à l’exception de ceux permettant la fourniture du présent site web et qui sont strictement nécessaires au fonctionnement de ce dernier. Pour accepter ou refuser l’utilisation des différentes catégories de cookies (à l’exception de la catégorie des cookies strictement nécessaires), rendez-vous dans les Préférences cookies.
Vous pouvez à tout moment revenir sur votre autorisation d’utilisation des cookies (Préférences cookies).
Le refus de l’utilisation de certains cookies peut avoir un impact sur votre utilisation du site.
En savoir plus : Politique cookies
Préférences cookies
Refuser tous les cookies
Accepter tous les cookies