Migration cloud : comment mener le projet et préparer ses équipes au changement ?
18 April 2019
Un projet de migration cloud est souvent présenté comme une occasion pour des ingénieurs de prendre du plaisir : on change de technologie, on va vers le cloud, c'est l'éclate ! Et pourtant, lorsque le projet débute, des réticences apparaissent et les ingénieurs trainent visiblement des pieds. Pourquoi ce revirement alors qu'on leur offre un projet unique et fun ? Pourquoi ces mauvaises volontés qui menacent le projet ?
En fait, loin d'être une gourmandise pour techies, une migration est un véritable tsunami technique et émotionnel. En effet, en dehors des aspects techniques, une migration vers le cloud c’est surtout une migration vers une nouvelle culture qui remet en question la façon dont les ingénieurs font leur métier depuis des années. Ce changement fait peur. Je vous propose de voir de quelle façon vous pouvez anticiper et remédier à ce problème.
Ce qui change pour les équipes
Tout d'abord, pour bien comprendre, je voudrais illustrer avec un exemple l'ampleur des changements pour les équipes. Il ne s'agit pas ici de faire le tour des nombreux changements, j'aurai certainement l'occasion d'y revenir dans d'autres billets, mais de vous faire ressentir ce qui provoque cet état de stress chez vos collaborateurs.
De nombreuses choses changent, mais le changement le plus remarquable est certainement la gestion des infrastructures comme du code. En effet, dans le cloud, l'accès aux infrastructures se fait de façon programmatique. Cela signifie que les infrastructures peuvent être décrites, déployées et manipulées comme des programmes. En clair, dans un monde « infrastructure as code», un serveur est représenté par un bout de code, comme ceci :
Pour remplacer ce serveur par un plus gros, il suffit de changer le bout de code, comme cela :
Cette gestion des infrastructures comme du code est une véritable révolution. Elle apporte de la souplesse, de la vitesse et tout un tas d'autres avantages, mais aussi des contraintes, à savoir :
- d'abord, et de façon évidente, il faut savoir faire du code, ou avoir des affinités pour cela. Fort heureusement, les informaticiens sont quand-même bien placés pour savoir le faire ou pour apprendre vite,
- ensuite, il faut gérer ce code comme le feraient des développeurs : mettre en place des outils pour écrire ce code, le partager, le tester, le déployer, en conserver des versions successives, .... et au final, mettre en place tout un processus de travail auquel les administrateurs systèmes sont généralement étrangers (ce n'est tout simplement pas leur boulot).
Enfin, en corolaire avec cette gestion par le code, vient une autre approche qu’il est parfois difficile à intégrer : l’approche des infrastructures immuables comme stratégie de gestion des machines virtuelles. Dans cette approche, une machine en production est considérée comme immuable : une fois lancée, on y touche plus.
Si elle a besoin d’être mise à jour, une nouvelle machine est créée pour la remplacer.
Si elle pose problème et doit être dépannée, la correction est appliquée sur une nouvelle machine lancée à sa place, qui devient le nouveau standard gravé dans la pierre.
On ne dépanne plus rien, on remplace. Les machines ne sont sont plus que du code, déployées en quelques clics et quelques minutes.
Ce concept de machine « jetable », désacralisée est difficile à accepter car les machines avec lesquelles ces équipes ont l’habitude de travailler sont des machines physiques, qui ont une grande valeur, et qui ne sont en aucun cas des consommables. Les américains parlent de "pets and cattle" : autrefois, les serveurs physiques étaient les animaux de compagnie des administrateurs systèmes, tous différents, chacun avec sa petite spécificités qui faisait son côté attachant. A présent, les serveurs sont considérés comme du bétail (cattle), sans que rien ne les distingue les uns des autres. La gestion différenciée des pets a laissée place à la gestion de groupe du cattle.
Ces chamboulements et ces changements de philosophie sont perçus comme une menace par les ingénieurs, et surtout par ceux qui ont le plus à y perdre, ceux qui se sentent largués, ceux qui n’ont que de faibles compétences techniques ou des compétences orientées plutôt vers la maintenance physique, voire mécanique des éléments d’infrastructure et de data center : le câblage, l’électricité, la maintenance des installations de base.
Comment les équipes vivent-elles le changement ?
Par le fait même de ces nouvelles activités, de ces nouvelles approches, le cloud est un challenge pour les équipes. Voici une courbe qui représente la performance et la motivation lors de l’introduction d’un changement majeur.
Cette courbe est valable dans tous les cas, pas seulement pour les migrations vers le cloud. Imaginons que vous déménagiez à l’étranger, vous connaîtriez alors les mêmes phases de (dé)motivation :
Phase 1 :
Il y a tout d’abord la phase d’enthousiasme initial. Super, on va faire du cloud, c’est cool ! Tout le monde est content, on a un nouveau projet, en plus c’est du cloud, c’est cool, on va faire quelque chose de nouveau. Si vous déménagiez, vous diriez certainement "Je vais vivre à Shanghai, c'est génial !"
Phase 2 :
Puis viennent la peur et l’incertitude lorsqu’on se rend compte que ça demande pas mal d’effort. A un certain moment, on est même au fond du trou, le moral dans les chaussettes. C’est alors qu’on entend des choses comme « c’est compliqué, on y comprend rien, c'est nul", puis : « de toute façon ça ne marchera pas, chez nous on ne bosse pas comme ça, etc, etc… ».
Si vous aviez déménagé à l’étranger, c’est là que vous diriez que de toute façon il est nul ce bled, ils ne savent pas faire la cuisine et les frites vous manquent. A ce moment-là, on envisage de tout plaquer et de rentrer à la maison, ou d’annuler le projet dans notre cas. Le découragement est tel, qu’à quoi bon s’entêter ? De toute façon, c’est nul !
Phase 3 :
Puis on s’y fait : on remonte la pente, les premiers succès remettent le sourire aux lèvres des membres de l’équipe, ça va mieux ! On se ressaisit. Les gens trouvent leur place, ils ne se sentent plus menacés et prennent du plaisir dans cette nouvelle activité. Les difficultés sont toujours là, ça reste difficile, mais les choses s’organisent et ça va mieux. On sent que l’on progresse dans la bonne direction. Vous recommencez à apprécier la cuisine locale.
Phase 4 :
Enfin, en phase 4, avec la prise de confiance et la performance régulière, c’est la routine qui s’installe. Plus personne ne pense à remettre le projet en cause et on commence même à en sentir les bénéfices. Même les gens qui s’y opposaient le plus farouchement sont à présent convaincus et ne veulent plus revenir en arrière. C’est cool le cloud !
Comment préparer les équipes au changement ?
Malgré leur côté montagnes russes émotionnelles, on peut tirer parti des ces phases en les intégrant dans notre projet de migration cloud :
Phase 1 :
Cette phase est donc la phase de deuil de l’activité. On réalise que ce que l’on sait faire ne se fait plus de la même façon. On se sent inadéquate, ou carrément largué. C’est dur à encaisser, on a toujours fait son métier d’une certaine façon, et tout d’un coup, on nous le change ! Alors forcément, la première réaction, c’est le rejet.
Dans cette phase, le seul moyen de s’en sortir, c’est par la réalisation que l’on est capable de faire les choses et de suivre le mouvement. Je préconise :
des formations
Vos ressources humaines peuvent vous aider à mettre en place une analyse des compétences présentes au sein de l'équipe et un plan de formation personnalisé pour construire les nouvelles compétences. Il faut résister à la tentation de "reformatter" tout le monde et de faire repartir vos ingénieurs de zéro. Il vaut mieux capitaliser sur leur expérience et les spécialiser dans leurs métiers "historiques", de cette façon ils verront une continuité plutôt qu'un challenge, et se sentiront moins en danger. Et puis, quoi de plus naturel que de capitaliser sur les compétences d'un ingénieur réseau pour faire le réseau, et de laisser un administrateur de stockage s'occuper du stockage dans le cloud ?
la mise à disposition des outils
Indispensable pour favoriser l'expérimentation par chacun et la familiarité avec les outils et les concepts. Ce bac à sable doit rester disponible jusqu'à la fin et il faut encourager les ingénieurs à y aller jouer : à présent, à partir de maintenant, cela fait partie de leur travail. Et bien que vous pensiez peut-être qu'ils ne sont pas là pour s'entrainer ou s'amuser dans un bac à sable, fut-il numérique et dans le cloud, il en va de leur capacité à migrer puis à opérer vos infrastructures dans le cloud...
la mise en place de référents cloud
Les référents cloud sont les éclaireurs de vos équipes techniques, ils ont un rôle plus avancé et leur mission est de :
- développer une architecture hybride,
- créer des architectures de référence ré-utilisables pour les différentes applications,
- tester / éprouver les designs,
- répondre aux questions et notamment les questions « comment fait-on pour » dans un mode exploratoire,
- se concentrer sur la gestion des identités et des assets cloud,
- établir la gouvernance des coûts,
- favoriser et mettre en place les formations cloud et l’évangélisation pour tous dans l’entreprise.
Certains appellent cela le "cloud center of excellence". J'apprécie le côté flatteur pour l'égo des membres de ce groupe et la motivation associée, mais je trouve que le côté élitiste divise plus l'équipe dans sa globalité qu'il n'unit les membres du "cloud center of excellence". Je préfère donc mon appellation de référents cloud.
Phase 2 :
Ce qui nous emmène à la 2ème phase : la phase neutre émotionnellement. ça y est, on remonte la pente, on se sent capable !
Il faut profiter de cette phase pour préparer la landing zone (préparation du réseau, des droits d’accès, des rôles et responsabilités, du monitoring, etc…) et réfléchir à l’architecture de l’ensemble.
De mon point de vue, réfléchir ensemble est important : tout le monde ne pourra pas construire, seuls certains le feront, mais tout le monde doit avoir participé : cela cimente la compréhension, fédère autour des nouvelles activités, et évite de nourrir un sentiment d'exclusion.
C'est aussi dans cette phase qu'ont lieu les expérimentations destinées à valider les architectures et les méthodes de migration. Il faut en profiter pour impliquer tout le monde, tester en douceur les compétences acquises par chacun et valider le chemin parcouru, les besoins de formations complémentaires et tendre la main à ceux qui sont en difficulté. Il est essentiel de veiller à ne laisser personne à la traine, de quittancer les difficultés et de montrer aux gens que vous les soutenez, que vous croyez et investissez en eux. Dans le cas contraire, les mauvaises humeurs vont refaire surface et ceux qui seraient en train de couler seront tentés d'entrainer avec eux par le fond ceux auxquels ils pourront se raccrocher, voire de torpiller le projet dans son ensemble (n'oubliez pas qu'à ce stade, la migration n'a pas encore commencée et peut donc encore être annulée...ce dont certains pourraient être tentés de profiter !).
Phase 3 :
La phase 3 est la phase du renouveau et de la migration : on se sent prêt, la compétence est acquise, les fondamentaux sont prêts, on peut migrer pour de bon.
Tout le monde aura travaillé de concert pour arriver jusque là, tout le monde doit continuer à être impliqué, chacun dans son métier, chacun dans sa spécialité. Même si tout n'est pas encore parfait, tout au long du processus la compétence de l’équipe aura augmenté et sera solidifiée. L'équipe ne se sera pas fragmentée, les gens ne se seront pas sentis menacés mais intégrés, inclus. Ils continuent à faire partie de l'équipe, on continue à compter sur eux et ils ne sont pas menacés de disparition car ne l'oublions pas, après la migration, il faut encore opérer les infrastructures, celles qui sont dans le cloud, mais aussi celles qui seront restées dans le data center.
