Quel est le quotidien de nos consultantes et consultants en projet ? Quels sont les challenges techniques à relever et quelles solutions sont apportées ? Derrière une mise en production réussie, un déploiement ou un Proof of Concept, il y a des consultantes et des consultants, une équipe, des technologies et beaucoup d’expertise et d’intelligence collective ! Cette série d’articles vise à vous dévoiler l’envers du décor, à travers leur témoignage.

Malgré une formation qui le destinait à une carrière de recherche en chimie, Jérémy a choisi de se réorienter dans l’informatique, plus précisément le métier de l’infrastructure. Dans la foulée, il s’est intéressé au Cloud AWS, a passé sa première certification et après une première expérience au support, il s’est rapidement trouvé plongé dans un environnement de production AWS. Jérémy a ensuite rejoint l’équipe Devoteam Revolve à Lyon.

Comment en es tu venu à te reconvertir dans l’IT ?

Je ne suis pas arrivé dans l’IT complètement par hasard, nous sommes nombreux à avoir fait de longues études scientifiques et à avoir bifurqué vers l’informatique. J’avais du mal à trouver un emploi dans le domaine de la chimie après un parcours 100% universitaire, et par ailleurs, si je ne regrette absolument pas d’avoir suivi ce cursus, la réalité du métier de chercheur, très chargée en administratif, m’a incité à chercher une nouvelle orientation professionnelle.

J’ai alors trouvé une opportunité de formation dans l’IT, avec une embauche à la clé. Il s’agissait d’une formation sur l’infrastructure. DNS, DHCP, serveurs, Linux… autant de concepts qui m’étaient inconnus, mais je me suis tout de même engagé dans cette formation. Je suis donc tombé dans l’infrastructure par hasard, alors que beaucoup de mes collègues se dirigeaient plus souvent vers une reconversion dans le développement. 

Est-ce que tu t’es projeté dans ce métier ?

La formation était assez intense en termes d’horaires et de contenus, mais j’ai trouvé le sujet très intéressant. Démythifier tous ces acronymes de l’informatique, comprendre qu’un DNS est juste la traduction d’une adresse IP en un nom lisible par les humains, était assez satisfaisant. Je me suis intéressé au sujet, j’ai pris du plaisir à commencer à manipuler Linux. La formation couvrait l’administration système, le réseau, et se terminait avec une ouverture sur le Cloud, puis le passage de la certification SysOps AWS. Après deux mois et demi de formation seulement, c’était un programme un peu audacieux !

J’ai donc été embauché à la suite de la formation, et j’ai commencé dans une équipe d’infogérance de N1. Ce qui me convenait bien, pour commencer à comprendre concrètement comment fonctionne l’IT en conditions réelles. J’ai pris sur mon temps personnel pour passer la certification AWS. Je n’avais pas d’expérience, c’était du pur bachotage, mais en étudiant AWS j’ai trouvé la technologie très intéressante. Les patterns d’architecture, la façon de traiter la haute disponibilité, les déploiements continus… même si j’avais une compréhension très parcellaire du sujet, tout cela me semblait passionnant.

Et ensuite ?

J’ai eu la chance d’être le premier dans l’agence à obtenir une certification AWS, cela m’a permis de commencer une mission pour un industriel de la santé. Le projet était l’extension d’un datacenter dans le Cloud AWS. J’ai passé 18 mois sur cette mission, où j’ai fait un peu de delivery management, de l’architecture, et du build. En plus de cela, je faisais aussi la connexion avec les équipes de run. C’était un gros challenge, mais qui m’a permis de bien progresser. J’en retire une bonne expérience. Vivre une situation compliquée, les deadlines, la charge de travail, le manque de main d’œuvre…j’ai beaucoup appris sur le métier de la prestation, mais aussi sur AWS. J’avais les droits administrateurs sur la LZ, j’ai vraiment plongé dans la production. Il y a avait peu de compétences sur AWS chez le client, et de fait mes propositions n’étaient pas vraiment challengées, ce qui est toujours un risque quand on débute comme c’était mon cas.

Mais cela m’a permis de travailler sur des vrais sujets d’architecture, de faire du chiffrage, et d’apprendre les bonnes pratiques recommandées par AWS. J’ai ensuite passé la certification Architecte AWS, puis j’ai suivi un bootcamp pour préparer la certification Architecte Pro. Je me suis préparé en amont de ce bootcamp, avec pour objectif d’être prêt au passage de certification avant le début de la formation. J’ai obtenu la certification, ce qui m’a un peu surpris, mais j’avais travaillé pour. Cela m’a conforté dans mon intérêt pour le Cloud et AWS. 

Comment as-tu rejoint Revolve ?

Je me suis trouvé dans une situation où j’étais le seul à avoir des compétences Cloud, elles n’étaient pas challengées, et cela me pesait pour bien faire mon travail. J’avais besoin d’un environnement où progresser, acquérir une réelle compétence auprès d’architectes Cloud expérimentés. J’ai alors pu rencontrer Revolve par l’intermédiaire de David, avec qui j’avais passé beaucoup de temps à réviser pour les certifications, et c’est comme ça que j’ai été recruté.

Sur quels sujets as-tu commencé à travailler chez Revolve ?

Je suis arrivé dans l’agence nouvellement créée à Lyon. J’ai travaillé sur Terraform pour faire un POC sur Terraform Enterprise avec Mehdi et Pierre, puis j’ai préparé la certification Developer. J’ai ensuite commencé le projet sur lequel je suis aujourd’hui, pour un client dans le secteur du transport.

Est-ce que l’environnement Revolve correspondait à tes attentes ?

Oui, j’ai trouvé exactement ce que j’étais venu chercher. Le cœur de métier de Revolve, c’est AWS; bien que l’agence de Lyon soit un peu plus jeune, nous avons déjà pas mal de compétences sur le sujet, et cela crée une émulation et un contexte propice à la montée en compétence. Sur Paris, il y a des gens très pointus sur de nombreux services AWS, et on voit que la communauté est très active, j’y trouve souvent des discussions qui m’apportent des informations utiles. Cette émulation est ce dont j’avais besoin, et qui me manquait dans ma précédente expérience.

Peux-tu présenter le projet sur lequel tu travailles ?

Il s’agit de la construction et de l’administration d’une landing zone. C’est un sujet semblable à ma première mission, avec de fortes responsabilités, un contexte de sécurité bien établi, et des règles sur les droits, les flux AWS etc. Il y a plusieurs objectifs, dont la création de remédiations automatisées pour faire respecter les règles de sécurité, pour les actions qui ne peuvent pas être bloquées en amont. Je code des fonctions lambdas en Python pour créer des événements. Cela demande parfois aussi de faire un peu d’architecture autour de la lambda : la rattacher à un event, utiliser un bucket S3, de la notification…Le maintien en conformité de toute la partie IAM demande beaucoup de travail, car il y a pas mal de legacy.

Le projet a ensuite évolué : la séparation des droits était basée sur les tags, mais dans la pratique ça ne fonctionne pas très bien, il n’y a pas assez de contrôles basés sur les tags. Sur des services comme EC2, les tags sont détaillés et fournis, sur d’autres services plus récents, ou des services comme RDS, les tags ne permettent pas de bien séparer les droits. Notre objectif était d’empêcher quelqu’un travaillant sur une application A d’impacter l’application B. Nous avons donc changé le modèle de la Landing Zone pour passer à des comptes AWS dédiés, plusieurs comptes par application, ce qui facilitera la gestion des droits. Enfin, on ajoute à cela de l’automatisation au sens devops/chaîne de déploiement.

L’automatisation, était-ce un sujet nouveau pour toi ?

Je n’avais pas travaillé sur la partie déploiement, je ne connaissais que les template sur Cloudformation, sans gestion de version dans un git, de déploiement avec des tests automatisés, etc. C’était le niveau 1 de l’automatisation en fait. Tout l’objet de la mission ici était de construire une usine à comptes AWS : définir un compte en un fichier json, avec des modules Terraform pour déployer les ressources AWS (comptes de services, VPC, remédiations automatisées, rôles d’administrateur). Donc oui, c’était relativement nouveau pour moi.

Comment s’est passée ta montée en compétence sur ces nouveaux sujets ?

Ça s’est très bien passé, pour plusieurs raisons. J’ai eu de la chance d’avoir un client qui me laisse libre de mes mouvements. Le besoin était de pouvoir déployer des comptes à la volée, de façon standardisée, et j’étais libre d’intervenir sur le Jenkins, ça m’a permis d’apprendre le Groovy, un langage java un peu simplifié, que je ne connaissais pas à ce moment. J’ai appris le langage en développant des process de déploiement. A force d’ajouter de la complexité, cela oblige à réfléchir à la maintenabilité. Ces process doivent pouvoir être utilisés, réutilisés, mis à jour… c’est à nous de faire cette maintenance, donc comment éviter que la maintenance  ne prenne trop de temps et ne génère de la dette technique ?

Sur ce projet, j’ai eu l’occasion de travailler avec un autre prestataire, beaucoup plus expérimenté que moi dans l’IT, et avec plus de connaissances de l’environnement du client. Ensemble, nous avons commencé à réfléchir à la mise en place de mécanismes aussi simples et pratiques que possibles, maintenables. Nous passons beaucoup de temps sur le design de ce qui sera codé,  plutôt que de coder tête baissée. C’est très intéressant, c’est une vraie montée en compétence, je n’apprends pas juste un langage, mais à architecturer le code, architecturer une chaîne logicielle. La montée en compétence se fait bien car je peux être aidé par quelqu’un de plus expérimenté, on arrive aussi à se challenger mutuellement, et cela donne un résultat très intéressant.

Le mot de la fin ?

J’ai trouvé chez Revolve cet environnement de compétence technique que je cherchais, qui permet de créer de l’émulation, et où on peut trouver de l’aide si besoin. Ceci afin de délivrer une prestation qui soit satisfaisante pour le client, mais aussi pour le consultant, j’aime faire du bon travail, et quand on aime un peu la technique, on aime quand c’est propre et que tout fonctionne bien. On est parfois limité par ses propres capacités, c’était mon cas avant de rejoindre Revolve, j’ai eu de l’aide pour progresser et pouvoir faire des choses techniquement saines.