Une carrière de développeur, comment l'envisager malgré les changements technologiques continues ?Essayons de regarder en arrière : comment les révolutions passées ont-elles impacté notre profession ? Aussi bien au niveau technologie qu'humain ?
Comment envisager la prochaine révolution, la prochaine vague, que l'on soit développeur sénior ou jeune diplômé ?
Je voudrais parler ici des développeurs "mainstream", par opposition aux ingénieurs et chercheurs qui peuplent les grandes entreprises IT, et qui peuvent éventuellement bénéficier de plans de carrière à part.
De même, dans les grandes entreprises, le métier de développeur peut prendre plusieurs formes que celui de "pure codeur" :
- DEVOPS
- ingénieur cloud
- expert plateforme
- coding architect
- etc.
La carrière
La carrière de développeur a évoluée au cours du temps, ce que nous allons présenter au travers des différentes période.
1950 - 1970 : les scientifiques
Le métier des programmeurs dans les années 50 consistait à écrire des programmes en langage machine, c'est-à-dire des instructions en code binaire que l'ordinateur pouvait comprendre. Cela nécessitait une grande expertise en mathématiques et en logique. Les programmeurs devaient également comprendre les spécifications de l'ordinateur qu'ils utilisaient, car les premiers ordinateurs avaient des architectures très différentes les unes des autres.
1970 - 1990 : les analystes programmeurs
Les analystes-programmeurs du siècle dernier avaient une carrière de technicien, assimilées aux autres carrières administratives de l'entreprise. Avec une carrière typique :
- 0 à 10 ans : Technicien
- à partir de 10 ans : Responsable de service
L'analyste-programmeur avait la plupart du temps, dans les PME en tout cas, la tâche de concevoir et de programmer les applications métiers, ce qui constituait un rôle assez complet. Mainframe, AS400, VAX-VMS - les environnements étaient conçus tout-en-un et les tâches étaient complexes mais dans un univers assez bien défini.
1990 - 2010 : le simple Développeur
La bulle Internet et le passage à l'an 2000 ont boosté les besoins. Le métier de "développeur", avec la création de cursus bac+5, est né à ce moment-là.
Mais paradoxalement, la bulle de la fin des années 90 a nécessité de convertir de nombreuses personnes non prédestinée à ce métier. De plus, pour conduire des projets d'entreprise de plus grande ampleur, la sous-traitance massive et la délocalisation ont abaissé le niveau de compétence moyen. On a donc associé des rôles non-techniques pour compléter celui de "développeur", terme qui a été créé pour moderniser celui de programmeur.
De 1995 à 2010 environ, la carrière typique était donc :
- 0 à 5 ans : Développeur
- 5 à 10 ans : Analyste/concepteur
- 10 à 20 ans : Chef de projet
2010 à 2020 : les carrières techniques
Puis, la vague Agile supprimant une bonne partie de la hiérarchie dans les équipes. On a relocalisé les développements. Cela a forcé les DRH à ajouter des perspectives aux métiers techniques : l'apparition de "tech lead", d'expert et d'"architecte technique". Mais ces évolutions ne permettaient pas de gravir beaucoup d'échelon, ce qui a raccourci encore la carrière de "simple développeur".
Entre 2010 et 2020, cela a donné :
- 0 à 3 ans : Développeur
- 3 à 8 ans : Teach lead, expert technique
- à partir de 8 ans : manager technique, architecte technique
2020 à aujourd'hui
A l'heure actuelle, le nombre de développeurs est largement inférieur à la demande. Même les nombreuses reconversions, l'ouverture de nouveaux cycles universitaires et d'écoles privées n'arrivent toujours pas à couvrir les besoins. Aujourd'hui, les DRH offrent malgré elles des carrières beaucoup plus longues aux métiers de développeur, celui qui code et qui ne se content pas de manager ou de faire des recommandations.
L'environnement technique s'est complexifié également et la hiérarchie n'est pas forcément verticale dans une équipe.
On peut donc facilement avoir aujourd'hui :
- 0 à 3 ans : Développeur junior
- 3 à 8 ans : Développeur expérimenté
- à partir de 8 ans : Développeur sénior
Les révolutions technologiques
Les cycles longs des écosystèmes
J'entends par "écosystème technologique", une approche de développement construite entièrement autour d'un langage et de ses outils.
Sur cette fresque, on peut observer des cycles de 10 ans pour qu'un écosystème technologique émerge, devienne leader, puis se fasse progressivement détrôner.
voir mes sources en fin d'article
- Les logiciels monolithes, disponible via des terminaux, remplacées par la micro-informatique et les logiciels client-serveur entre 1990 et 2000. Le C et le C++ remplacent COBOL et FORTRAN.
- Ces applications client-serveur sont remplacées par des applications web entre 2000 et 2010, avec une domination de Java et PHP
- Vers 2010, les applications web générées côté serveur, sont remplacées par des frameworks Javascript et mobiles
- Depuis 2020 environ, Python s'invite dans les 1ères places de la hiérarchie grâce au développement du Big Data et le l'IA
Ces changements se répercutent sur la façon même de développer, ce qui signifie que nous devons nous reformer, sur un temps plus long, à ces nouveaux paradigmes. Le bon côté est que nous avons plus de temps pour voir le train arriver et nous n'avons pas besoin de les anticiper de façon très précoce. On a généralement le temps de saisir l'opportunité d'un nouveau projet pour faire une transition en douceur.
Les efforts nécessaires pour désapprendre les anciens réflexes et d'apprendre les nouveaux étant très exigeant d'un point de vue personnel, les changements de carrière sont plus fréquents à ce moment-là. Heureusement, il y aura également plus de temps pour continuer de maintenir les développements sur un ancien écosystème, avant sans doute de se réorienter vers un autre métier. Cette situation est la même pour d'autres métiers, dans d'autres secteur, qui permutent sur des temps longs.
Les cycles courts des frameworks
Entre chacune de ces révolutions d'écosystèmes, de mini-révolutions s'enchainent.
On peut les assimiler à l'émergence de frameworks au sein d'un même langage.
Leur cycle de vie est beaucoup plus court, ce qui constitue une particularité des métiers d'IT : on a souvent à renouveler notre panoplie d'outils tous les 5 ans !
On peut l'illustrer avec l'histoire récente du développement web :
Flash décolle en 2000 et arrive à son apogée vers 2005, où beaucoup le considère incontournable pour développer des interfaces riches.
Mais à ce moment-là, Apple, Mozilla et Google planchent activement pour moderniser Javascript et remplacer la technologie d'Adobe. En 2010, Steve Jobs déclare que Flash ne sera plus supporter sur ces appareils. Dès lors, quasiment aucun nouveau projet Flash ne verra le jour. Les développeurs web devront réapprendre à développer des interfaces en Javascript. Les incessantes nouveautés d'HTML 5 et CSS 3 rajouteront beaucoup de complexité à la transition.
Dans le même temps, JQuery était devenu le framework Javascript de référence pour les interfaces riches. Les développeurs web étaient experts de cette bibliothèque. Mais en 2016, Angular, React et les autres frameworks SPA l'ont complètement remplacé.
Il faut réapprendre à développer des interfaces sans manipuler le DOM HTML, mais faire réagir celui-ci aux modifications des données. Là aussi, beaucoup de développeurs chevronnés ont pu être démotivé de devoir réapprendre cette façon de développer.
Pour les autres, la clé a été la veille technologique.
Les répercussions sur les compétences du développeur
En effet, la veille technologique permet de percevoir assez tôt l'arrivée de ces nouveaux outils, et donne le temps de s'autoformer, de les mettre en place sur de nouveaux projets.
Cette perception doit être suffisamment précoce pour être prêt à saisir les opportunités lorsqu'elles se présentent.
Le nombre de conférence sur ces sujets le montre.
La veille technologique est quelque part une source d'angoisse : c'est une tâche chronophage, et pas forcément fructueuse : le risque est de percevoir une révolution trop tôt, alors qu'elle n'arrivera jamais à s'imposer et sera abandonnée.
En 2009, certains développeurs voient en Microsoft Silverlight le vrai remplaçant de Flash. Cependant Microsoft n'arrive pas à imposer son framework dans le milieu du web, qui est abandonné en 2012.
Cela a généré beaucoup de déception chez ses adeptes qui ont pu être dégoûtés par ces changements de tendance aussi soudain.
Son évolution personnelle
Ces caprices de la "communauté", largement influencés par les startups de la Silicon Valley, apportent leur lot d'inquiétudes : moi le développeur, qui doit déjà me tenir à l'écoute et m'autoformer en parallèle de mon travail quotidien, je peux aussi miser sur le mauvais cheval et me retrouver obsolète, en quelques années ? Oui. Ce phénomène est renforcé par les embauches continues de nouveaux diplômés, qui arrivent sur le marché en ayant déjà suivi des cours sur ces nouvelles technologies.
Nous craignons que nos connaissances deviennent obsolètes en même temps que nos frameworks préférés, que nous maîtrisons pourtant si bien.
Cette crainte conduit parfois à persister dans notre domaine de prédilection, pour rester performant, et pour que notre expertise ne soit pas remise en cause par de jeunes pousses.
La stratégie peut être valable si on est disposé à être souple : au moment où la technologie déclinera, il faudra accepter des concessions pour aller chercher les missions là où il y en a. Beaucoup d'entre nous se mettent à leur compte en tant que spécialiste.
Au contraire, quand on choisit de rester dans son entreprise, on voit que les nouveaux projets migrent sur ces nouvelles technologies. Nos collègues travaillent sur ces nouveaux projets, les uns après les autres. Cela peut être douloureux. Cela peut mener à la conclusion que sa carrière de dev est derrière soi, qu'il faut que je s'éloigner de la technique. Pourquoi pas, si on a l'envie de réorienter vers l'expertise métier et le management. Ou envisager une reconversion complète.
Mais que faire si ce n'est pas le cas ? Que dois-je faire si je n'ai pas d'appétence pour d'autres métiers ?
Repartir de zéro, tout réapprendre.
Je vais parler ici un peu de mon cas.
Je travaille aujourd'hui dans une équipe où la moyenne d'âge est 25-30 ans. A 40, l'image que l'on renvoi a dépassée celle d'un dev sénior ! Je suis un "vieux" dev sénior, et cette expérience supplémentaire ne m'apporte pas un réel avantage. Je ne suis pas plus efficace qu'à 30 ans !
Je ne suis pas moins efficace non plus : je développe des applications de gestion sur la stack MERN et je suis aussi efficace que mes jeunes collègues.
Je dirais que je me connais seulement un peu mieux, j'ai foi en mes capacités. Je sais aussi que je pourrai réapprendre.
Car je saurai toujours :
- modéliser des données métiers
- analyser un processus
- concevoir une interface utilisateur
- déployer une solution et expliquer comment l'utiliser
Je sais également qu'il faut être attentifs aux nouveaux frameworks, et attendre qu'ils s'imposent avant de les adopter. A ce moment là, je serai de nouveau un débutant, j'aurai la même courbe d'apprentissage qu'un novice.
Mais au bout de quelques moi, je pourrais de nouveau :
- modéliser des données métiers
- analyser un processus
- concevoir une interface utilisateur
- déployer une solution et expliquer comment l'utiliser
Avec autant d'expérience qu'avant.
L'avenir de notre métier
Pour conclure, parlons de l'avenir : des changements profonds de notre métier arrivent.
Ils sont encore très flous mais néanmoins incontestables : l'activité de production du code pourra être progressivement déléguée à des plateformes IA et des outils très élaborés de low-code. On voit aujourd'hui des embryons très prometteurs comme Github Copilot, Power Apps et bien sûr ChatGPT.
De plus, le développeur est une ressource beaucoup trop chère pour imaginer que les entreprises continueront d'investir des sommes faramineuses pour payer chaque morceau de code nécessaire à la transformation de leur système d'information.
Tout comme la vague du Cloud qui a changé le métier des admins sys, notre propre vague arrive inévitablement.
"On n'aura plus besoin de développeurs !"
Bien sûr que si, et ce seront ces mêmes développeurs qui deviendront des "prompt engineers" et "platform engineers". Car, au-delà du code, nous saurons toujours :
- modéliser des données métiers
- analyser un processus
- concevoir une interface utilisateur
- déployer une solution et expliquer comment l'utiliser
Ceux qui le souhaiteront pourront rester dans la partie en acceptant de changer de façon de travailler.
Le marché du travail sera forcément plus tendu, mais ne deviendra sûrement pas l'impasse que certains prédisent.
Conclusion
Vous avez compris que dans cet article, il y a beaucoup de subjectivité et de raccourcis.
Chaque situation personnelle est complexe; cependant, ces idées, cela fait longtemps que je les ai en tête.
Comme beaucoup d'entre vous j'en suis sûr.
C'est avec grand plaisir que je le partage ici, en espérant lire vos commentaires car vos opinions comptent énormément.
Sources
https://fr.wikipedia.org/wiki/Chrono..._programmation
data is beautiful
https://roadmap.sh/software-design-architecture
Transition & adapt
https://dev.to/shieldstring/how-to-e...-engineer-2064
Shifting mindset
https://www.infoq.com/articles/devel...enges-mindset/
https://www.forbes.com/sites/forbesa...h=71bc461492ec
Wikipedia timeline
https://en.wikipedia.org/wiki/Timeli...e_of_computing
Article against no-code
https://jaylittle.com/post/view/2023...pment-is-a-lie
Prompt engineer
https://tinyml.substack.com/p/it-wor...pted-it-or-the
Platform engineer
https://charity.wtf/2022/09/30/the-f...m-engineering/