De développeur à architecte logiciel
J'ai toujours été attiré par l'informatique. C'est donc naturellement que je me suis orienté vers des études scientifiques et une école d'ingénieur.
Comme la plupart des ingénieurs juniors, nos seules expériences n'ont pas toujours de lien direct avec le monde de l'entreprise dans lequel on doit évoluer en sortie d'écoles. Pour autant, il faut savoir s'adapter et apprendre.
Notre travail évolue au fil du temps, et le code que je produisais au début de ma carrière ne ressemble en aucun cas à ce que je produis aujourd'hui.
Au tout début il m'était inconcevable de devenir architecte logiciel tellement la marche me paraissait infranchissable. Et pourtant, avec les années d'expérience, les projets qui s'enchainent, on se rend compte que la marche devient de plus en plus accessible, et on n'appréhende moins l'idée d'y aller. Il faut savoir saisir les opportunités qui nous sont offertes.
Je maintiens la stack technique Java à la DSI de Bouygues Telecom
Je fais partie d'une équipe nommée CI/CD & Frameworks.
Nos objectifs d'équipe sont la mise en place d'outils communs pour la CI et la CD, ainsi que le développement de frameworks pour répondre aux exigences de développements / qualité / sécurité de Bouygues Telecom.
Mon rôle concerne la partie java avec le maintien d'un socle basé sur SpringBoot, dont l'objectif premier est de simplifier la vie des développeurs afin qu'il n'ait que du code métier à maintenir/créer.
Dans ce socle, on trouve des aides à la mise en place de design pattern, ou tout simplement la façon d'écrire une date dans un flux JSON.
Nous pratiquons beaucoup l'inner sourcing (contribution collaborative), ainsi, bien que je sois le principal contributeur, toute personne peut proposer une évolution/correction.
Toujours se remettre en question. Accompagner les développeurs
Les SI des entreprises ont beaucoup évolué en quelques années.
Les pratiques de développement également. Le DevOps est devenu une référence à suivre !
Chez Bouygues Telecom, nous évoluons continuellement. On peut avoir fait des choix à une époque, qui peuvent être complètement remis en question par la suite. Si on a une idée d'amélioration qui peut simplifier la vie de quelques personnes, on est encouragé à explorer.
Comme je fais partie d'une équipe centrale, on a en visibilité les problèmes des différentes MOE (maîtrise d'œuvre, i.e. les équipes qui développent) . Cela permet de comprendre les besoins et ainsi de leur proposer la solution la plus adaptée. L'objectif étant qu'elle soit applicable à tous.
Je donne des formations sur le socle java et j'aime partager mes connaissances. Cela amène souvent à des échanges intéressants car chacun à un avis différent.
Même si tu ne connais pas, tu peux toujours être formé et apprendre.
On n'est jamais expert d'un sujet qu'on découvre.
J'ai commencé avec un niveau Java scolaire pourtant cela ne m'a pas empêché d'apprendre l'ensemble de l'écosystème qui va avec : que ça soit l'IDE, ou la façon de construire un projet proprement (maven), ou la façon de coder, ou encore les librairies les plus utilisées.
Cela peut paraître long, mais rien ne s'acquiert en quelques jours. Il faut savoir se laisser le temps d'apprendre et confronter ses idées à celles d'experts.
La curiosité est une qualité essentielle dans notre métier. Si on te parle d'une technologie en entretien mais que tu ne la maitrises pas : pose la question. Le fait de poser des questions va nécessairement avoir un impact positif.
Dernier point, ne pas mettre tous les mots en vogue du moment dans son C.V si tu ne maîtrise pas ton sujet! C'est le meilleur moyen d'avoir des questions dessus, et si les termes/technologies ne sont pas maitrisés, l'image transmise à ton recruteur ne sera pas la bonne.
Migration d'un socle applicatif en tomcat vers SpringBoot
On connaît tous la dette technique qui s'accumule avec le temps.
Et puis un jour, on se rend compte que la pérennité du système est mise en péril car l'OS est obsolète. Changer d'OS implique des nouvelles versions de composants tiers avec un serveur applicatif qui ne pourrait peut-être plus fonctionner. Et là c'est le drame.
On se retrouve alors à devoir migrer une application (découpée en plusieurs exécutables) de java 7 à java 11, mais surtout changer la façon de l'exécuter en passant d'une ancienne façon de packager (war) vers un jar SpringBoot.
Appréhender un chantier de migration technique est complexe. Pour éviter le piège de "on va seulement monter de version de java", l'ensemble des librairies a été migré. Là où il s'agit d'un succès, c'est que le développement de nouvelles fonctionnalités a été maintenu pendant tout le temps de la migration, mais surtout aucune anomalie bloquante n'a été détectée en production.
