Quel est le quotidien de nos consultants, et comment évoluent-ils dans leur métier ? Cette série d’articles vise à vous dévoiler l’envers du décor, à travers leur témoignage. Nous vous proposons aujourd’hui de découvrir le parcours de Clément : développeur il y a quelques années, il s’est petit à petit intéressé à l’automatisation pour évoluer vers des compétences Ops, DevOps et finalement en arriver au développement d’applications Cloud Native.

Quel est ton background professionnel ?

Après une formation en génie logiciel, j’ai commencé en tant que développeur java. Pendant 8 ans environ, j’ai fait du développement backend dans le milieu bancaire, ce qui m’a donné une bonne base dans le développement. J’ai alors commencé à m’intéresser à l’automatisation, et notamment à l’intégration continue avec Jenkins dans l’objectif d’automatiser les builds. A ce moment, on ne parlait pas encore de chaîne d’intégration continue, et ce qui m’intéressait dans l’intégration continue, c’était la qualité logicielle : compiler le logiciel, exécuter les tests, exécuter les outils de qualimétrie de code.

Comment en es-tu arrivé à aller au-delà du rôle de développeur ?

Petit à petit, je me suis intéressé à ce qui allait devenir par la suite le pipeline de déploiement continu et à ce qui se passait au delà de mon application et de mon rôle de développeur. En tant que développeur, on construisait l’application, on créait un package applicatif qui était transmis aux équipes d’ops en charge du run de l’application. C’est l’image célèbre que nous connaissons tous, les développeurs et les ops séparés par un mur, avec chacun des objectifs et des motivations différentes. Comme l’intégration continue demandait des compétences Ops, j’ai commencé à m’intéresser au sujet et au travail de mes ops : que font-ils de mon package logiciel ? Comment opèrent t-il l’application ? C’est à ce moment que j’ai vraiment franchi le pas du DevOps, notamment en participant à des soirées DevOps Paris Meetup pour prendre le temps de discuter et de comprendre les différents points de vue..

Comment es-tu monté en compétence sur la partie Ops ?

En parallèle de mon intérêt pour les compétences mises en oeuvre dans la partie Ops, mes missions chez D2SI ont évolué pour aller vers plus d’Ops. J’ai ainsi intégré une équipe où nous étions responsables du développement et des opérations. Cela m’a permis de découvrir le run de notre application, et de comprendre qu’il n’est pas si simple de mettre (et de maintenir) en production une application. A ce moment, le marché et D2SI évoluaient vers le Cloud, et j’ai commencé à me former sur AWS. Je vois AWS comme “la bonne façon” de faire de l’Ops, qui permet de tout automatiser et de programmer l’infrastructure comme on le fait avec les applications. De fait, en développant mes compétences Ops dans AWS, j’en suis venu à développer une application dans AWS, et donc revenir vers le développement, pour faire du développement d’application cloud native. La boucle était bouclée : du développement vers l’Ops, puis de l’Ops au Cloud, pour arriver au développement d’applications Cloud native.

Comment tes missions ont-elles évolué ?

Au départ, je faisais du développement pur, puis après être monté en compétence sur la partie CI/Jenkins, j’ai intégré une équipe où j’avais le rôle devops, dans une équipe constituée où nous étions responsables du dev et du run de l’application. C’est là où j’ai fait mes armes en tant qu’Ops. Quand j’ai commencé à travailler sur AWS, j’ai effectué plusieurs missions de courte durée pour monter en compétence sur le sujet et sur les différents outils du Cloud. Aujourd’hui je fais du développement Cloud native avec l’application My D2SI (application interne de diffusion d’informations et d’événements), sur laquelle je travaille avec des stagiaires. C’est un projet qui fait appel à mes compétences en développement, et à tout ce que j’ai appris depuis sur AWS.

Qu’est ce que cette expérience a changé pour ton métier ?

Avoir travaillé du côté développement et ops m’a donné une vision globale de la problématique. Dans le développement d’applications Cloud native, on inclut complètement l’infrastructure au développement logiciel. Avant je développais du logiciel, maintenant je développe une application. Cela inclut le logiciel, l’infrastructure, et toutes les procédures qui permettent de gérer l’application au quotidien. C’est une approche plus complète qui demande d’utiliser les compétences de développeur logiciel et les compétences d’ops pour construire et opérer un service.

Comment D2SI t’a aidé dans cette évolution ?

D2SI a rendu cette évolution possible. Nous avions des pionniers sur AWS qui ont défriché le terrain et D2SI nous a donné les moyens d’expérimenter. D2SI m’a aussi donné les moyens, le temps pour me reconvertir et pour m’auto-former sur aws. En amont, il y a eu de nombreux échanges qui m’ont permis de comprendre ce qu’étaient le cloud et l’automatisation, via les KM (moments d’échange et partage de connaissances) et les discussions. Ensuite, j’ai eu du temps pour m’auto-former, je comprends mieux les choses en les découvrant plutôt qu’en me les faisant expliquer. Après avoir découvert les principes de base, j’ai commencé sur la console, puis c’est le projet My D2SI qui m’a permis d’expérimenter, de manipuler de façon concrète avec le besoin d’arriver à un résultat. Un projet concret fait qu’on se heurte à des difficultés, et on fait avancer le projet en résolvant ces difficultés.

Sur quoi travailles-tu aujourd’hui ?

Je suis actuellement sur une mission de migration sur le Cloud, et je travaille également sur le développement d’une application Cloud native de sécurité sur AWS. Il s’agit d’une application Serverless basée sur AWS Lambda qui vise à sécuriser l’usage d’AWS par les équipes : l’application effectue a posteriori des contrôles sur les actions des développeurs, et apporte les correctifs quand une action n’est pas conforme aux pratiques de sécurité : mauvaise configuration de security group, bucket S3 public, etc. L’application génère ensuite un reporting sur ce qui a été fait et qui a été corrigé, l’objectif étant de ne pas bloquer les développeurs, tout en éduquant sur les bonnes pratiques du Cloud.