Ces derniers temps je vois pas mal de gens faire une reconversion professionnelle vers une carrière de développeur -- souvent web d'ailleurs -- ou y songer. Je pense que pas mal de gens ne réalisent pas forcément ce que ça veut dire être développeur.

Disclaimer 1 : je ne fais pas cet article pour me plaindre ou autre, clairement je ne changerai de métier pour rien au monde aujourd'hui. Je fais cet article pour que les gens curieux de ce métier voient aussi les côtés négatifs, que ceux qui se posent la question de devenir développeur le fasse en pleine conscience.

Disclaimer 2 : j'écris cet article avec mon regard de développeur web, ce qui est à la fois un biais (je connais peu la vision des autres branches) et plutôt intéressant, car j'ai l'impression que beaucoup de reconversion se fait dans le web, en particulier le front.

Des socles à peu près stables mais un monde qui bougent tout le temps

Il y a des socles qui ne bougent pratiquement pas dans le temps. Ces socles sont importants à maitriser, en tout cas ceux qui concernent la branche qu'on choisit. Parmi ces socles on retrouve : les structures de contrôle (conditions, boucle, etc.), les structures de données (tableau, liste, map, dictionnaire, set, pile, etc.), les protocoles (HTTP, TCP, UDP, etc.) ou à minima les topologies de protocoles (client-serveur, pub-sub, bus, queue, etc.). Autant je trouve que ces socles sont bien abordés dans les cursus de formations classiques (IUT, fac, école d'ingénieur) bien que pas très bien positionné du coup on a tendance à les oublier, autant ils sont souvent absents des programmes de reconversion ce qui pose des problèmes plus tard pour comprendre les choses qu'on manipule au quotidien.

Périodiquement on voit des changements systémiques forts se produire. Je parle de changement systémique, car on observe une rupture forte dans la manière dont on va fonctionner sur l'architecture générale avec des grosses implications au quotidien. J'ai par exemple en tête : les micro-services, le cloud, la programmation réactive, la programmation fonctionnelle. Je pourrais en citer d'autres mais ceux-là ont clairement eu une influence très forte sur le quotidien des développeurs, obligeant les gens à changer leur manière de penser, ce qui n'est pas évident, ce qui largue certains en les reléguant au statut de "dinosaures"… Ces changements sont d'ailleurs souvent cycliques : on va avoir une tendance qui va s'essouffler pour revenir après quelques années sous une autre forme, mais on peut réappliquer ce qu'on a retenu du cycle précédent.

Là je parlais de cycle relativement long de plusieurs années, en tout cas long à l'échelle de l'informatique (dont on peut situer le début soit un peu avant la seconde guerre mondiale avec les travaux théoriques d’Alan Turing, soit dans les années 1950 quand on a commencé à créer des vrais ordinateurs programmables), mais on peut voir des changements à des cycles beaucoup plus courts aussi, en particulier dans le web. Quelques exemples de cycle : Angular a 2 versions majeures par an, React 1 version majeure par an, Java a 2 version majeure par an, JavaScript a une version chaque année (qu'on ne nomme pas JavaScript 1, 2, 3, mais ECMAScript 2021, 2022, 2023, depuis ECMAScript 6 ou ES6 aussi appelé ECMAScript 2015 ou ES2015). Si vous regardez les historiques de version, vous verrez qu'au fil des années on voit une accélération des versions. Cette accélération a des avantages et des inconvénients. Côté avantage on pourra voir que les versions sont plus petites, donc on a besoin de moins de temps pour apprendre ce qui change ; côté inconvénients le plus gros c'est qu'on doit prévoir des migrations plus souvent, et on est plus ou moins obligé de suivre pour ne pas être largué encore une fois.

On peut voir aussi qu'on a des luttes pour devenir leader : Angular était le maitre il y a quelques années, React a pris le dessus en s'imposant, mais React stagnant et Angular se renouvelant peut-être que cette tendance va s'inverser à nouveau ou peut-être qu'un nouvel acteur viendra doubler les deux leaders historiques. Java se fait aussi grignoter par Kotlin, à minima sur certains marchés, sans vraiment perdre sa position. Kubernetes a très fortement pris la place de pas mal d'outils qu'on utilisait massivement avant.

Si on maitrise bien les socles, on peut s'appuyer dessus pour transposer ce qu'on savait vers les nouveautés, mais pour ça il faut avoir eu le temps d'apprendre ces socles. En effet comme je l'expliquais, un peu tout bouge tout le temps, donc suivre est déjà difficile sans en plus devoir revenir à la base en continu.

Créativité et résolution de problèmes

Si dans la partie d'avant je parlais plutôt de l'aspect technique, le quotidien ce n'est pas tellement le code en lui-même. En fait je dirais même que savoir coder c'est la partie facile du métier. En effet programmer, c'est une technique qu'on apprend purement et simplement comme on apprendrait à jouer d'un instrument ou dessiner.

Développer c'est plus qu'écrire du code. Il y a une part de créativité et une grosse part de résolution de problème. La part de créativité vient aussi de l'expérience pour moi : être capable de mixer tout ce qu'on a déjà vu comme solution, tout ce qu'on connait comme technique pour créer la solution à un nouveau problème. On peut recouper les problèmes pour mettre en face des familles de solutions, mais on peut difficilement faire plus, on fait dans la vaste majorité des cas du sûr mesure, on dira parfois de l'artisanat (je ne rentrerai pas dans les détails, cherchez "software craftmanship" sur moteur de recherche préféré vous trouverez votre bonheur !)

En parallèle, il faut être conscient que la majorité du temps on le passe à résoudre des problèmes, que ce soit le petit élément qui ne s'affiche pas comme on le voudrait, le calcul qui ne s'applique pas sur un cas particulier pas du tout identifié, la fonction qu'on pioche dans le framework ou la librairie qui ne fait pas du tout ce qui est indiqué dans la documentation (quand il y a une documentation et qu'on ne doit pas deviner le fonctionnement en testant un peu au hasard), se battre avec le compilateur ou l'ensemble d'outil pour comprendre comment avancer sans toujours avoir d'indication clair sur le problème, passer la journée sur une erreur qui vient d'une erreur bête qui se corrige en une ligne ou même régulièrement contre les humains. En effet une bonne partie des problèmes qu'on a viennent d'imprécisions humaines : mauvaise compréhension, emploi d'un vocabulaire compris différemment, évidence non-explicité, solution à un faux problème, etc.

Si vous n'aimez pas résoudre des problèmes, souvent des problèmes absurdes en plus : le développement n'est pas fait pour vous.

Au bout de la chaîne hiérarchique mais pas trop quand même…

Les développeurs sont en bas de la hiérarchie. Il faut être très clair là-dessus : on a pas le pouvoir, on est des moyens de production comme beaucoup de gens travaillant à l'usine. Le seul gros avantage qu'on a c'est que le secteur est pénurique, et donc les entreprises ont besoin de plus de développeurs que le marché en propose. Par contre n'allez pas croire pour autant que votre part du gâteau sera forcément grosse, votre salaire sera très fortement corrélé à votre niveau d'étude en informatique (et je dis bien en informatique, si vous avez un bac+8 en bio, faite une reconversion en informatique, vous serez placé sur le marché comme si vous aviez moins d'un an d'étude en informatique), et le nombre d'année d'expérience pro (stage et alternance souvent plus ou moins exclus). En fonction de votre spécialité vous serez aussi plus ou moins avantagé. Dans pas mal de cas, il faut aussi changer d'entreprise pour vraiment avoir une vraie augmentation et suivre le prix du marché, le marché évoluant très vite aussi, le turn-over est important.

Je vais quand même relativiser un point : en étant développeur, on est quand même plutôt bien payé pour ce qu'on fait.

Mais en étant en bas de la hiérarchie, souvent plus une ressource qu'un humain, le statut cadre apporte peu. On a très peu de pouvoir pour faire changer les choses, trancher des décisions. Et dans un sens, c'est logique, ça permet de valoriser la branche, mais on se retrouve à tous être cadre, sans que ça veuille dire grand-chose sur notre quotidien.

On peut aussi parler de l'agilité. Un des créateurs de l'agilité en parle d'ailleurs très bien depuis au moins 2015, c'est un échec au sens où ça n'a pas permis de rendre les développeurs plus autonomes, mais juste déplacer la responsabilité vers les développeurs : c'est le développeur qui n'a pas réussi à la fois à produire et à s'organiser, pas le système qui l'a placé là dans un contexte où ce n'était pas possible. Je ne vous dis pas pour autant de ne pas pratiquer l'agilité, on peut quand même en tirer beaucoup de chose, mais pour être efficace en agilité, il faut être dans un contexte où on applique correctement l'agilité.

En une phrase : je trouve qu'on a beau avoir toute l'expertise technique des projets, on a souvent peu la main sur les choix structurant, ces choix-là, on a tendance à seulement les subir et devoir s'y adapter sans que ce soit logique.

Les ESN… et les autres

Si un courant de petite ESN qui fonctionnent différemment est présent et grossi, le gros des ESN c'est quand même souvent l'usine pour les développeurs. La comparaison que j'ai fait plus tôt n'était pas un hasard : dans beaucoup d'ESN, on nous met sur un projet, on est présent seulement pour écrire du code et remplir des lignes de temps pour définir à qui envoyer la facture. Mon plus gros problème est l'absence de recherche de qualité : ces ESN vont chercher à maximiser l'argent gagné, peu importe ce que ça implique pour le projet lui-même. En suivant cette logique en régit, j'ai vu des projets avec des mois de retard, des projets avec aucun moyen de valider que tout fonctionnait, des projets qu'on aurait mis moins de temps à jeter pour tout ré-écrire que faire évoluer ou des combos de ce genre de tare… Quand on parle d'assistance technique (quand on est envoyé chez le client), on voit beaucoup de mensonge sur les compétences, des développeurs sur-vendu qui sont a des postes qui ne collent pas du tout à leur profil…

Heureusement, il y a comme je disais un courant de relativement petite ESN qui sortent du lot, cherchent à fonctionner différemment, pas toute avec les mêmes priorités mais quand même dans le bon sens : faire que les collaborateurs soient bien, faire en sorte que les projets soient bien faits, être un minimum transparent avec le client pour construire de manière perenne quelque chose. Je peux citer à minima SFEIR, Zenika, Kanoma, Shodo et Takima, que je connais bien, il y en a d'autres, il faut parler avec les gens pour les trouver.

J'ai un peu tapé sur les ESNs, mais c'est pas forcément mieux hors des ESNs. On est aussi assez vite dirigé par la rentabilité à tout prix, pas forcément par la construction d'un bon produit. J'ai souvent vu les équipes de développement qui subissaient complètement les décisions prisent avec des logiques purement financières sans possibilité de négocier le moindre délai.

Conclusion

Je pourrais parler des heures de tout ce que j'ai vu ou qu'on m'a raconté qui ne va pas dans le milieu informatique (n'hésitez pas à me contacter si vous voulez qu'on échange sur le sujet), j'ai évoqué quelques points, je pourrais en citer beaucoup d'autres : le manque de diversité, le machisme ambiant dans certaines équipes, les gens réfractaires aux changements dans un monde qui bougent en continue, les clichés qu'on subit, les logiciels de développements qui sont souvent assez nuls, le gros pourcentage de personne en burn out, etc. En tout cas si vous lisez ceci avant une reconversion ou des études en informatique, ayez conscience que ce n'est pas un milieu aussi parfait que ce qu'on décrit parfois. Je sais qu'il y a des emplois bien pires que ceux de l'informatique, mais ça dépend aussi très fortement de nos critères personnels, il faut donc être bien conscient de ce qu'est ce milieu. Le meilleur moyen de le comprendre c'est de parler avec des gens qui y travaillent.

Tout ça se base sur mon expérience, mon avis et ma vision des choses, est-ce que j'ai tort ou raison je n'en sais rien dans l'absolu. En tout cas je sais que c'est le métier que j'ai choisi, pas forcément en pleine conscience de tout ça mais en tout cas c'est un travail qui reste un travail-passion aujourd'hui pour moi -- ce blog se serait pas là sinon je pense -- mais ne le sera pas forcément pour vous et potentiellement un calvaire loin de l'image qu'on peut avoir de ce métier.

Sources :

Crédit photo : https://pixabay.com/photos/cyclone-storm-hurricane-clouds-2102397/