“L’atout de la reconversion est d’être un parcours choisi” (Wishow)

Est-ce que tu peux te présenter et présenter Wishow ?

‍

Moi, c'est Olivier, je suis le CTO de Wishow, que j'ai rejoint en mars 2023. J'ai une carrière de développeur. J'ai commencé aux alentours de 2005 en touchant un peu à tout, du back-end, du .NET, etc. J'ai développé une forte passion au bout de 2 ans pour les IHM (ndlr: interactions homme-machine). C'est ce qui fait que j'ai un background plutôt front-end, même si les sujets d'architecture back-end, et d'architecture logicielle d'une manière générale, m'intéressent beaucoup. J'ai vu beaucoup de sujets DevOps aussi les 4 dernières années, en même temps que ma découverte du management qui s'est faite fin 2017 chez ekino.

Concernant mon parcours, j'ai une carrière d'autodidacte. Je viens de la philo : il n'était pas du tout prévu que je fasse du dev au départ ! Mais je codais déjà quand j'étais gamin et ça me plaisait beaucoup. Quand je préparais l'agrégation de philosophie, je me suis rendu compte que je voulais travailler en équipe, avoir du feedback concret, apporter de l'outillage aux gens et améliorer leurs pratiques par le codage. Du coup, j'ai fait le switch. Je me suis remis à la programmation en autodidacte au début avec le site du zéro (ndlr: aujourd'hui OpenClassrooms), où j'ai pris mes premiers cours sur PHP et MySQL.

J'ai eu la chance de rencontrer mon premier patron qui était lui-même un autodidacte, qui a eu l'intelligence de faire ce que, à mon avis, tout le monde devrait faire aujourd'hui dans la tech lorsqu'on voit quelqu'un essayer : c'est de donner sa chance et de dire "soit tu y arrives et tu restes, soit tu n'y arrives pas et tant pis, tu feras autre chose". J’aime cette manière de voir les métiers comme c'était le cas du temps de nos grands-parents, où quand on cherchait de la place, on allait à un atelier, on était avec les collègues et on apprenait le métier sur le tas. La programmation reste encore un des rares métiers où on peut faire ça !

Je viens de la reconversion et évidemment, ce sont des valeurs que je défends. Wishow, c'est une ESN qui appartient à Wivoo, un groupe qui s'est fait remarquer il y a 3-4 ans autour de l'organisation de lives et qui a su tisser des liens avec la communauté des product managers. Il y a tout un ADN autour de l'idée de communauté, de lives, d'émissions, de communauté de pratique, de formation qui est extrêmement importante, qui a été reprise du côté tech.

L'originalité chez Wishow est son modèle économique, où l’on redistribue les richesses en fin d'année entre Wishers, ainsi que manuellement en fonction de l’écart entre TJM facturé et TJM plancher. Par cette approche, nous souhaitons arrêter avec cette opposition classique entre le salariat et le freelancing, de manière à créer une communauté d'intérêts dans tous les sens du mot « intérêts » (technique, passion, économique). C'est pour ça que Wishow, c'est avant tout un collectif de développeurs, une coopérative avec une caisse commune qui peut servir pour de la formation, qui peut servir pour de la dotation en matériel, qui peut servir pour plein de choses, mais un collectif de développeurs avec des votes, des assemblées, des votes qui se font en collégialité.

C'est quelque chose aussi qui nous permet d'aller chercher du côté de ceux qui sont intéressés par le freelancing, qui, traditionnellement, peuvent être des profils extrêmement compétents. Ça nous permet d'avoir un modèle solide et de proposer autre chose que le modèle, vu et revu, des ESN qui envoient les consultants au charbon avec des commerciaux qui touchent des primes sur des dev qui ne se sentent pas bien en mission. C'est à peu près l'anti-modèle de Wishow ! 

‍

Pourquoi recruter des profils en reconversion dans la tech ?

‍

J'y vois plein d'avantages. D'abord parce que le propre de la reconversion, c'est d'être un parcours choisi. Le développement est devenu un eldorado, et les parents des nouveaux adolescents le savent pertinemment quand ils inscrivent leurs enfants dans les écoles d'ingénieurs. Il y a un côté “parcours qui se déroule”, qui peut très bien se dérouler, mais qui parfois peut être un peu automatique. J'ai été surpris quand j'ai fait du recrutement, en tant qu'engineering manager, de voir pas mal de profils en reconversion avoir un niveau technique non négligeable et parfois avoir un goût du détail et une rigueur qui était même supérieure, dans certains cas, à des profils d'ingé. Pour moi, ce qui explique ça, c'est le fait d'avoir réellement choisi sa reconversion, d'avoir réellement choisi ce parcours par opposition à quelque chose qui se déroulerait tout seul. 

Le deuxième point, c'est que par définition, les profils plus larges et plus transverses amènent quelque chose d'intéressant. Et souvent, c'est très intéressant de mélanger ces éléments à la culture dev : ça permet aussi d'enrichir le niveau des conversations qu'on peut avoir dans une équipe tech.

Pour moi, il y a beaucoup plus une question autour de comment encadrer correctement un profil qui vient de la reconversion, comment bien l'onboarder, comment être clair dans les missions, comment bien transmettre les connaissances, plus que la question "pour ou contre les profils en reconversion". Alors après, mon avis est nécessairement biaisé parce que je suis moi-même issu de la reconversion, mais ayant été de l'autre côté de la barrière, quasiment toutes mes expériences se sont très bien déroulées et je ne vois vraiment aucune raison de s'en priver... Surtout dans un marché tendu !

‍

Peut-on vraiment apprendre à coder en 3 mois ?

‍

Apprendre à coder en 3 mois, tout dépend ce qu'on entend par apprendre à coder et c'est une question extrêmement vaste. Connaître en 3 mois les bases de l'algorithmique dans un langage, connaître un minimum de good practice et être à même de pouvoir rencontrer des développeurs et échanger avec eux, la réponse est oui. Après, apprendre à coder, c'est le travail de toute une vie ! Si la question, c'est de savoir quand est-ce qu'un développeur est prêt pour coder de manière professionnelle en entreprise, pour être parfaitement honnête, la réponse à cette question ne peut en aucun cas être 3 mois. Par contre, est-ce qu'au bout de 3 mois, on peut déjà acquérir suffisamment de réflexes pour parfaire cet apprentissage dans le bon sens, aller plus loin et avoir les matériaux qui vont permettre de se former correctement ? La réponse est oui. Pour moi, il est raisonnable d'envisager au minimum 9 mois à toucher à plusieurs projets différents, quelle que soit la techno.

La clé pour apprendre rapidement ? Aller à des Meetups, lire des articles et surtout pratiquer, pratiquer, encore pratiquer. C'est un domaine qui est extrêmement concret. Et si possible, demander du feedback. Il faut avoir un petit repo open source pour demander du feedback, et les gens sont toujours heureux d'en partager. Mais il faut savoir s'entourer de retours concrets et apprendre en pratiquant, savoir mélanger la pratique, la théorie, prendre des notes, avoir un système aussi organisé pour retenir les choses, et ne pas avoir le réflexe toujours consulter Stack Overflow ou Google, même si c'est extrêmement important. Il faut capitaliser sur ces recherches, l'organiser, utiliser des logiciels comme Notion, ou n'importe quel logiciel qui permet de faire sa documentation soi-même. Mais c'est très important d'avoir ces outils-là, de ne pas se décourager et d'avoir une furieuse envie d'apprendre. 

‍

Comment as-tu vu évoluer les besoins en compétences tech au cours des dernières années ?

‍

Les besoins en compétences tech évoluent à peu près aussi vite que la tech elle même, c'est-à-dire à peu près tout le temps. Il y a d'abord les besoins qui sont structurels aux évolutions qu'on peut constater au sein des différents business. Il est normal, par exemple, de vouloir des architectures cloud de plus en plus décentralisées. Avec cette nouvelle façon de gérer les infrastructures « as a service » (Platform as a service, Infrastructure as a service, Software as a service, etc), on a vu le plein essor de toute l’approche “diviser pour mieux régner”. Ça, c'est des besoins qui sont structurels parce qu'on s'est retrouvés avec des DSI qui avaient des monolithes qui devenaient ingérables, et impossibles à maintenir avec le temps, alors qu'il y a un réel besoin de souplesse, pour être à même d'aller plus vite et d’apporter de l'adaptabilité à toutes les solutions logicielles mises en place. 

Ensuite, il y a une évolution dans les pratiques, parfois même dans les modes. Par exemple, avec une techno comme JavaScript, il y a un nouveau framework, une nouvelle librairie qui sort quasiment chaque jour, j'exagère à peine ! Et il y a une évolution qui est faite aussi des rencontres avec toutes ces nouvelles boîtes à outils. Certaines restent confidentielles, quand d'autres ont le vent en poupe. Ainsi, il peut y avoir un effet de mode incroyable lors d'une rencontre entre une communauté de dev et une librairie.

Là, ce qu'on remarque lors des dernières années, c'est une très forte évolution des besoins en termes de DevOps, de SRE (ndlr: site reliability engineering), de manager d'infrastructure de plateforme. Il y a aussi de plus en plus de postes de dev full-stack, parce qu'on veut avoir des dev front qui comprennent le back et des dev back qui peuvent en faire la UI (ndlr: user interface) qui correspond aux APIs et services développés par leurs soins. Côté mobile, on a comme d'habitude 2 écoles autour du développement natif et du développement cross-platform. Tous les 2 ans à peu près, on a le nouveau framework magique qui devrait permettre de se passer complètement du natif. On se rend compte dans les faits que ce n'est pas si simple que ça : ça demande de réelles connaissances des écosystèmes Apple et Android, et avec une approche cross, on a souvent des petits soucis à résoudre, certes insurmontables, mais à prendre en compte. 

Au final, l'évolution des profils est très largement parallèle à l'évolution des technologies, de ce qu'elles permettent de faire d'une part, et à l'évolution du marché d'autre part.

‍

Avec l'émergence des IA génératives, aura-t-on encore besoin de développeurs dans quelques années ?

‍

Pour avoir beaucoup essayé moi-même l'IA générative avec du code, je dois avouer que mes résultats sont mitigés. J'ai parfois des choses de qualité assez médiocre, et parfois j'ai des résultats étonnants de pertinence et de qualité. Ça, c'est pour parler de là où on en est actuellement. Mais si on fait l'hypothèse d'une IA qui corrigera ces défauts, et c'est tout à fait réalisable, la question se pose quand même encore.

Pour moi, le rôle de l'IA générative dans la programmation, ça va être de plus en plus de faire les tâches besogneuses. En tant que CTO, je remarque par exemple qu'au quotidien, si j'ai du parsing de data à faire ou si je dois générer avec une boucle à 20 000 itérations sur un fichier d'URLs, je vais pouvoir compter sur l'IA pour aller plus vite et me concentrer sur les sujets où il y a un réel besoin de réflexion.

En fait, il faut distinguer 2 choses dans l'activité de programmation. Il y a une activité de conception et de compréhension parfois abstraite des différentes portions de code. Là, il s'agit vraiment d'imaginer, de concevoir, de schématiser. Je pense que ce rôle pourra toujours et de manière pertinente être confié à des humains. Et sur des tâches qui sont des tâches de pure production, on a eu trop tendance ces 10 dernières années à considérer les développeurs comme étant essentiellement des gens qui produisent. C'est bien évidemment en partie vrai. Sauf que leurs compétences vont bien au-delà. Il ne faut jamais oublier que nos développeurs sont en très large partie des ingénieurs. Et dans l'étymologie du mot "ingénieur", il y a une racine avec "génie". On parle d'ailleurs de génie logiciel, car il y a une dimension forte d'invention et de conception. C'est une activité très demandeuse sur le plan cognitif. Et tout cet aspect-là a tout à fait sa place en collaboration avec des IA génératives qui pourraient faire les "basses besognes".

Donc, pour moi, ce n'est pas du tout une menace pour les ingénieurs. Au contraire, ça pourrait être un très bon assistant pour gagner en vitesse. En tout cas moi, j'ai envie de rester optimiste, et ça nous donne la responsabilité d'être encore plus avancés, encore plus intelligents avec l'IA générative pour faire les choses sur lesquelles on n'a pas trop le temps de se pencher. 

‍

Vers où évoluent les plus gros besoins en compétences tech ?

‍

Si on essaie de se projeter à l'horizon de 2-3 ans, on commence à voir certaines tendances : comme je disais plus tôt, une demande de plus en plus forte du côté des profils SRE, DevOps et dev full-stack de manière très claire. Beaucoup de besoins aussi, mais ce n'est pas nouveau, côté data, data science et data engineering. Je pense que l'arrivée de l'IA générative va rendre les rôles de ML engineer (ndlr: Machine Learning engineer) et de ML Ops, de plus en plus importants.

En ce qui concerne l'IA générative, il va y avoir aussi de plus en plus de besoin de contrôler ce qui en sort. Je m'attends à ce qu'il y ait de plus en plus de métiers qui émergent autour de l'éthique dans le numérique, avec des instances pour mesurer les dangers et les apports potentiels apportés par tel ou tel modèle. Ce n'est pas, à proprement parler, un métier tech. Par contre, ce sont des profils qui vont travailler dans la tech et concernés de plein fouet par les apports de la tech.

Évidemment, pour des entreprises de service comme Wishow, le nerf de la guerre, ce sera de proposer aussi ce type de profil, de savoir anticiper ces évolutions et savoir transformer ça en service clé-en-main pour nos clients.

‍