Et si on faisait connaissance ? Devoteam Revolve, ce sont des consultantes et des consultants passionnés par leur métier, des profils et des parcours variés. Dans cette série d’articles, nous vous proposons d’aller à la rencontre de celles et ceux qui font la richesse de l’entreprise, de découvrir leur vision du métier et les challenges techniques qu’ils relèvent. Aujourd’hui nous allons à la rencontre d’Etienne, Devoteam Revolve Nantes. Ancien consultant de D2SI spécialisé sur Citrix, Etienne est revenu ensuite chez Devoteam Revolve, son entreprise « de coeur », pour le challenge du Cloud et la communauté.

Etienne est également l’auteur de plusieurs articles sur Amazon AppStream.

Avec Devoteam Revolve, c’est une longue histoire ?

J’étais consultant Citrix pour D2SI de 2013 à 2015. Je travaillais sur des projets  de déploiement d’infrastructure Citrix, ou de maintien en condition opérationnelle. A la fin de l’année 2015, j’ai choisi de partir vivre en Bretagne, et comme à ce moment il n’y avait pas d’agence sur place, j’ai quitté D2SI et j’ai continué à faire du consulting Citrix pour d’autres entreprises. Mais j’étais resté en contact, j’échangeais régulièrement avec Julien Stanojevic, et en 2019 on s’est rappelés car des agences ouvraient en régions. Devoteam Revolve (à l’époque D2SI), c’était ma boîte de cœur, il y avait des liens humains et des valeurs que je n’ai pas retrouvées dans mes autres expériences professionnelles.

J’ai donc rejoint en septembre 2019 la nouvelle agence qui se montait en région Ouest, même si ça signifiait de changer de métier, de quitter l’environnement Citrix pour aller vers AWS. Et depuis, je m’éclate ! Je travaille sur AWS, sur de l’automatisation, et si j’ai fait un peu de Citrix sur AWS pour faire le lien avec mon ancienne spécialité, j’ai naturellement évolué vers AppStream, un service managé AWS pour faire du déport d’affichage comme Citrix (remote work). C’est une évolution par rapport à Citrix, on le fait différemment, avec beaucoup d’automatisation , de l’infra as code, du Powershell pour automatiser l’installation. C’est très différent de ce que je faisais avant.

Comment s’est passée ta montée en compétence sur les sujets Cloud AWS ?

Après quelques jours d’onboarding consacrés à la découverte d’AWS et des principaux services, j’ai eu accès aux plateformes en ligne type Cloud Guru, dans l’idée de passer une première certification. Cela demande un peu d’investissement personnel, mais j’ai eu la chance de commencer en même temps que Laurent Mas, un autre ancien “nouveau”. Au début, on a pas mal travaillé en binôme, plus tard nous avons d’ailleurs développé ensemble tout une partie d’automatisation sur AppStream.

La montée en puissance était donc progressive, avec un effort au début pour passer la première certification. Ensuite, c’est la pratique en mission qui fait toute la différence : on essaie de comprendre les tenants et aboutissants du sujet, d’automatiser et d’exploiter au mieux les services AWS pertinents pour le contexte du client. J’ai commencé à faire de la veille sur AWS de façon récurrente : me tenir informé sur les nouveaux services, sur les produits connexes comme les outils d’infra as code, ou les outils de CI pour automatiser le déploiement de code sur AWS (gitlab, github, ansible). On croise régulièrement tous ces produits en mission, donc il est important de creuser ces sujets pour être sûr de bien faire son métier, et être certain qu’en fin de mission, le client ait la meilleure solution possible, qui réponde à son besoin sans lui demander de fournir des efforts par la suite. Rendre le client autonome, lui fournir une solution qui demande le moins d’entretien possible, c’est mon objectif sur chaque mission. Le risque, quand on fait beaucoup d’automatisation, c’est d’arriver avec tout un lot d’outils et de code, et de ne pas impliquer le client. On doit au contraire l’embarquer dans la réalisation, pour qu’il soit autonome sur ce qui est livré.

Comment s’assurer de cela ?

Ça dépend des interlocuteurs, mais si je suis face à quelqu’un de technique, qui a le goût des choses nouvelles, j’essaie de découper le projet en petites tâches. On discute ensuite des choix techniques pour chacune d’entre elles, et j’implique mon interlocuteur dans les phases de construction et d’automatisation, de façon à l’intéresser au fonctionnement des services AWS, à l’implémentation dans Terraform d’un composant, etc. Pratiquer en même temps qu’on avance dans le design et la réalisation, co-construire, cela permet vraiment de s’approprier les sujets.

Ce n’est pas toujours le cas, tout le monde n’a pas le temps, ou l’envie, de faire du code, et dans ce cas la passation se fait par des sessions de formations informelles, où on partage les connaissances nécessaires à la compréhension de ce qui est livré. On explique les choix de technologie, comment les services sont configurés, et où le client peut faire des modifications. Je livre aussi de la documentation, parce qu’on oublie vite ce qui est transmis uniquement par oral. Et si mon interlocuteur n’est pas technique, j’essaie de vulgariser au maximum. Le plus important est de comprendre les grands concepts, pas le détail de chaque ligne de code. Si on a saisi les grandes lignes, le jour où il y a une panne, on identifie vite l’origine du problème.

Sur quels sujets travailles-tu aujourd’hui ?

J’ai plusieurs projets en parallèle, souvent sur des sujets d’automatisation Windows sur AWS, dans le cadre de migration depuis des datacenters vers AWS. Je travaille sur des environnements majoritairement Windows : Active Directory, bases SQL, fermes Citrix, Microsoft RDS, etc. Certaines de ces migrations sont faites en lift&shift, pour d’autres nous essayons d’optimiser composant par composant, en passant sur des services managés. Pour les environnements remote desktop, on va basculer assez naturellement vers Amazon AppStream – cela demande même moins d’efforts qu’une migration en lift&shift.

Dans le cas de la construction d’une nouvelle plateforme sur AWS, mon objectif est d’automatiser l’ensemble du déploiement, mais aussi la gestion au quotidien, comme la publication d’une application. Tout est écrit sous forme de code, qui sert aussi de documentation de l’infrastructure et de ce qui doit être présent en production.

J’interviens également sur des missions de Landing Zone, c’est-à-dire définir l’endroit où on arrive sur AWS quand on est un nouveau client, le nombre de comptes nécessaires, comment opérer la ségrégation du réseau, les permissions, les comptes, etc. C’est du design d’environnement AWS à l’échelle d’une entreprise.

Comment on passe d’une mission à l’autre ?

Le plus compliqué, c’est d’ajuster son planning avec celui du client, et de caler les jalons d’un projet en fonction des contraintes des autres missions. Cela demande un peu de souplesse, généralement j’aborde ce point en début de mission avec le client et je lui propose un rythme d’intervention avec un certain nombre de jours par semaine. Il arrive qu’il y ait une urgence, un besoin de livraison qui oblige à décaler le planning, mais ça se passe toujours en bonne entente et dans le cadre d’une relation de confiance. C’est donnant-donnant, et le client sait qu’en retour il bénéficiera aussi de cette souplesse quand il en aura besoin. Par ailleurs, j’accompagne les consultants Devoteam Revolve juniors en mission, donc je cale aussi mes interventions pour qu’on ait du temps en commun.

Quelles sont les qualités d’un consultant Devoteam Revolve ?

Pour qu’une mission soit réussie, il faut avoir su écouter le besoin client : écouter, reformuler, s’approprier les idées et échanger jusqu’à ce que toutes les parties soient d’accord sur les objectifs. Les compétences techniques ensuite, sont des pré-requis, mais d’un consultant à l’autre il y a des différences, nous n’apprenons pas tous les mêmes choses. S’il manque une compétence sur une mission, il est possible pour certains de l’acquérir rapidement, mais il faut aussi savoir demander de l’aide.  Le travail d’équipe doit intervenir, ça ne sert à rien d’être bon tout seul dans son coin. Un bon consultant sait interagir avec les autres experts, et embarquer quelqu’un pour le faire évoluer.

Enfin, la communication est une qualité essentielle, chez le client comme au sein de Devoteam Revolve. Le consultant doit être capable de communiquer régulièrement avec son client, quel que soit le canal, pour que tout le monde soit toujours aligné au long de la mission et de la vie du projet. Il existe de nombreux outils, mais certaines choses ne passent pas par ces canaux et il faut savoir les communiquer différemment. Dans tous les cas, j’essaie toujours d’être transparent au maximum sur ce qui ne va pas, pour qu’on arrive rapidement à une solution.

Pour terminer, qu’est-ce que tu apprécies le plus chez Devoteam Revolve ?

Les gens avec qui je travaille et le contexte technique dans lequel on évolue. Je suis un “tech”, j’ai besoin que ça me titille le cerveau, et je trouve cela chez Devoteam Revolve. Ca me plaît beaucoup de passer de mission en mission en ayant toujours quelque chose à découvrir, et pour cela AWS est passionnant. La vitesse d’innovation est élevée, et pour arriver à suivre il faut se spécialiser dans un domaine.

Chez Devoteam Revolve, j’ai aussi le sentiment d’appartenir à une communauté. Je n’aime pas spécialement le terme « communauté d’experts”, l’IT est un milieu où les gens se prennent beaucoup (trop) au sérieux. On a tous des compétences spécifiques, d’autres sujets sur lesquels on est moins bons, on a donc besoin les uns des autres pour progresser. C’est quelque chose d’important pour moi et que je trouve chez Devoteam Revolve, c’est un milieu convivial où les gens ont envie d’apprendre et de travailler ensemble.

Enfin il y a chez Devoteam Revolve une culture de l’automatisation, de la bonne automatisation, c’est-à-dire automatiser tout ce qui a du sens à l’être. J’ai par exemple rencontré un consultant qui voulait automatiser tout ce qu’il faisait, mais cela n’en vaut pas toujours la peine. L’automatisation est utile pour les tâches répétitives, pour ce qu’on risque d’oublier, mais je ne vais pas automatiser une tâche que je ne ferai qu’une fois. L’automatisation a du sens, mais seulement en regard du besoin du client. Est-ce utile d’engager 3 heures ou 3 jours sur l’automatisation d’une tâche ? On doit toujours se poser la question du pourquoi, pourquoi on fait les choses, et questionner la pertinence de nos choix.