Le besoin tech des entreprises en 2023

Geraldine Lewa from unsplash.com

Cet article est le 2e d’une série sur les évolutions en cours dans le monde du software engineering en France. Le 1er revenait sur le contexte de crise de la tech, ses causes et conséquences sur l’eco-système et la tech en général. Celui-ci porte sur les évolutions plus profondes constatées dans les entreprises vis-a-vis de leur besoin en devs* et de ce qu’elles ont à proposer pour les attirer.

*J’alias développeurs/développeuses en ‘devs’ pour plus de concision.

Pour donner un peu de contexte, j’ai eu la chance d’échanger avec une cinquantaine d’entreprises qui recrutent sur les 6 derniers mois, entrer dans leur stack, leur organisation et leurs besoins. Des entreprises qui semblent donc à première vue du bon côté de la crise puisqu’elles recrutent. Pour autant le besoin est en train d’évoluer pour tout le monde, et ce à plusieurs égards. Pour certaines il y a eu une levée sur les 12 derniers mois pour accélérer sur un product-market fit, d’autres, moins nombreuses sont en pré-scale. En moyenne les équipes que j’ai pu voir sont composées entre 10 et 30 devs. J’ai également pu échanger avec quelques scaleups qui tournent à plusieurs centaines de devs. Des entreprises à majorité franciliennes mais pas que. Des entreprises tech avant tout, c’est-à-dire dont le ou les produits phares sont un logiciel sur le web (saas, app, standalone API, objet connecté…).

Comme je le précisais dans un précédent article, il y a un shift de la recherche de croissance vers une recherche de rentabilité, y compris côté tech. Certaines équipes ont réduit leurs effectifs, ou gelé leurs embauches. D’autres recrutent au compte goutte.

Mais que recherchent vraiment les entreprises chez un ou une dev aujourd’hui ?

Le recrutement

Ces dernières années ont été caractérisées par un très fort besoin en recrutement de profils tech.

Le constat est que la manière d’exprimer son besoin est le plus souvent assez générique, car il fallait d’abord recruter vite et fort. En termes d’exigence de compétences, beaucoup d’offres se ressemblent sur le papier. Côté profil recherché on retrouve le classique:

• X années d’expérience avec au moins un langage de programmation (Python, Go, JS, Ruby etc…)
• Compréhension des principes et bonnes pratiques du développement logiciel
• Attitude de problem solver et compétences en debugging
• Capacité à travailler en équipe et en autonomie

Côté description du poste, même combat:

• Participer à la réalisation de nouvelles features
• Améliorer la qualité de la codebase et du delivery
• Tester et documenter son code
• Participer aux différentes cérémonies agiles et aux codes review

Qui ne souhaite pas recruter des profils avec ce type de description ? Quelle équipe ne tend pas à faire (à différents niveaux) ce qui est écrit ci-dessus ?

J’y vois une opportunité à préciser son besoin. L’objectif est de permettre aux candidats de plus facilement se projeter dans la réalité de ce que c’est d’être dev dans telle ou telle entreprise, et pour l’entreprise de trouver des candidats qui matchent particulièrement bien à un besoin par rapport à leurs expériences et intérêts.

“Maîtriser javascript” en soi ne veut pas dire grand chose. On pourrait préciser: maîtrise des principaux design patterns, ou encore connaissance et application des principes SOLID dans l’écriture de son code. Ce sont certes des questions qui peuvent être abordées dans un test ou un échange techniques, mais comme le rappelait Laurent Cerveau (ex-CTO de Zenly) dans une masterclass: “le mieux que je puisse faire pour tester quelqu’un en entretien, c’est de le ou la laisser me parler d’un truc cool qu’il ou elle a fait, et de creuser ses choix en posant des questions, en demandant ‘pourquoi’ à chaque fois qu’une idée est avancée”. Et pourquoi ne pas mélanger le meilleur des 2 mondes à savoir: avoir une grille de lecture des sujets précis que maîtrise ou auxquels s’intéresse un ou une candidate, pour ensuite entrer dans un échange plus profond en live, autour d’un exemple particulier vécu ?

Idem côté tests: il n’est pas compliqué de faire passer un flaky test pour maintenir le coverage. Maintenant écrire un vrai bon test unitaire qui teste un comportement (et non pas nécessairement une classe ou une fonction) et qui s’abstrait des dépendances tierces, c’est moins trivial. Et quid du monitoring, d’être capable d’écrire une bonne documentation etc… autant de compétences vitales pour une entreprises, pas toujours mises en avant dans l’expression du besoin.

Dans les licenciements constatés ces derniers mois, un certain nombre a concerné les Talent Acquisition Managers. Les EM (engineering managers) sont donc désormais un peu plus seul.es quant à l’exécution d’une stratégie de sourcing, et de recrutement en général. Pouvoir à première vue cerner un ou une candidate, ses forces, ses faiblesses et ses appétences permettrait de gagner du temps et en justesse de matching.

Le souci de la qualité du code

Il y a différentes dimensions qui couvrent ce qu’on appelle la qualité dans le software. Celle-ci doit permettre d’améliorer la confiance dans sa codebase (limiter le nombre de bugs et le temps de détection/résolution de ceux-ci) d’une part, et d’aller plus vite dans la réalisation d’une feature d’autre part, autrement dit, d’améliorer son lead time.

Le 1er est plus facilement mesurable (nombre de bugs, temps passé à résoudre etc…), mais est surtout de plus en plus mesuré: de plus en plus d’entreprises se référent aux DORA métriques pour mesurer la qualité et la performance, et c’est une bonne chose.

Le 2e aspect est plus difficile à mesurer: comment comparer la vitesse de livraison d’une feature (considérations de CI/CD à part) lorsqu’a priori on ne la développe qu’une fois ? Comment être sur qu’en appliquant tel ou tel principe dans son code on gagne du temps in fine ?

Beaucoup de voix défendent cette idée que le temps passé à faire de la qualité est un investissement rentable, en livrant moins de bugs, en sachant mieux les détecter et les résoudre, et enfin tout simplement en allant plus vite dans le développement de nouvelles features, ou le refactoring. Et ces sons de cloche sont de plus en plus entendus, pas seulement par les devs, mais aussi au niveau du business et de la stratégie: passer du temps à écrire une bonne documentation, à s’assurer de la lisibilité de son code, à bien nommer les variables, à s’extraire des dépendances externes à son domaine métier, mettre en place une stratégie de tests ambitieuse ont pour conséquence d’améliorer sont lead time. Google et IBM publiaient il y a 10 ans déjà des études démontrant cette idée là, et récemment en 2022, une autre étude sur la base de 39 codebases en production menée par Adam Tornhill et Markus Borg constatent que maintenir un focus sur la qualité de son code permet de diviser par 15 le nombre de defects (qu’on pourrait traduire par bug) et que la résolution de ces bugs prend 13 fois moins de temps que lorsqu’on est sur une codebase avec peu ou pas de standards de qualité.

Sauf que, sur une codebase qui n’en a pas ou peu, il reste difficile du jour au lendemain de mettre tout ça en place.

Les entreprises le comprennent, et cherchent donc à la fois à élever le niveau de qualité du code en interne, mais aussi à s’assurer dans leurs recrutements que les profils appliquent naturellement ces principes, ou à minima y sont sensibles.

Le souci de la qualité de l’architecture

Quant aux considérations plus architecturales, il faut déjà séparer architecture et… architecture. En effet, on utilise le même mot pour parler d’architecture de son code (clean/hexagonal architectures par exemple), que pour parler de l’architecture de son app (microservices vs. monolith). On parlera de style d’architecture dans le 1er cas, et on aura plus tendance à mettre cette partie dans l’amélioration de la qualité/maintenabilité du code (évoqué plus haut), et dans le second cas, on parlera plutôt de patterns d’architecture. On ne parlera pas ici d’architecture de l’infrastructure qui est encore un autre sujet.

Il semblerait donc qu’on revienne de plus en plus sur les bienfaits d’une architecture en microservices. Ou plutôt, qu’on a poussé trop loin les microservices en les multipliant sans limite, créant une situation où les bénéfices annoncés de ce type d’architecture (flexibilité, découplage des domaines, autonomie du déploiement continu pour ne citer qu’eux) se sont fait dépassés par la complexité accidentelle provoquée par la “microservicite” aiguë.

Récemment, Amazon Prime a annoncé en être revenu, et d’autres continuent de défendre les bienfaits du monolith, même sur des codebases conséquentes (la preuve avec Github, Shopify, Doctolib, Basecamp etc…). Car au fond maintenir des dizaines de DB, de pipelines différents, nourrit une certaine complexité. Et les apports du monolith modulaire sur ces points sont intéressants, car traitent de la séparation des domaines, tout en conservant une structure monolithique. Pour dire les choses autrement, et pour reprendre une formulation très juste de Simon Maurin, software architecte chez leboncoin: “Si on veut séparer les domaines dans une codebase, il ne faut pas confier cette séparation au réseau”.

Pour autant, on ne change pas d’architecture tous les ans, difficile de dire aujourd’hui si les entreprises feront les choix de revenir à du monolith, dans tous les cas, la modularité et le découplage ne seront plus des nice-to-have.

La montée du besoin en profils T-shaped

Le terme T-shape est apparu pour la première fois en 1991, défini par David Guest pour décrire le parfait IT Manager combinant une expertise business avec des skills IT. L’expression a évolué par la suite, reprise par IDEO ou encore Valve (éditeur de Half Life pour les nostalgiques) pour parler des ingénieurs logiciel ayant une expertise approfondie dans un domaine spécifique ou un langage (la barre verticale du T), et un ensemble de connaissances généralistes sur les autres aspects de la stack (notions en infrastructure, sensibilité produit, capable d’aller sur du back ou du front même si ce n’est pas notre spécialité etc…). Pour dire les choses plus simplement, être polyvalent, savoir s’adapter à un problème et ne pas avoir peur d’aller creuser sur un sujet que l’on ne maîtrise pas ou qui ne relève pas de sa techno de prédilection. En somme, être ingénieur.e.

Et c’est un peu différent de la notion de fullstack, car dans fullstack il y a la l’idée que l’on sait faire du back ET du front (même si on a souvent une préférence). Dans le T-shape, il y a l’aspect “connaissances” mais aussi le fait de sortir de sa zone de confort tout en ayant la big picture de la stack. En somme c’est un mindset et une trajectoire.

Les entreprises ne cherchent plus simplement des “codeurs”, mais des profils qui ont une sensibilité produit, ou qui s’intéressent au tooling, à l’architecture, ou qui comprennent les concepts fondamentaux de l’infrastructure, sans pour autant être DevOps. Avant on parlait d’ailleurs d’analystes programmeurs, ou de concepteurs développeurs (merci Adrien Joly et Rudy Onfroy pour ces piqures de nostalgie). Mais l’activité d’analyste ou de concepteur s’est un peu estompée au profit de celle de codeur. J’ai pu observer dans les entreprises avec lesquelles j’ai pu échanger, un retour du besoin sur des compétences plus transverses, au-delà de son expertise spécifique, et notamment avec cette idée qu’être dev, c’est d’abord être stratège. Et comme dans toute stratégie, il faut commencer par analyser le problème et concevoir une solution avant même de partir tête baissée dans le code. Et c’est plutôt une bonne chose, car l’arrivée des AI coding assistants va probablement permettre de gagner du temps sur la partie code à proprement parler, et en laisser d’avantage sur la conception.

Besoin de montée en compétences

Devant ce besoin en profils T-shape, et même d’une façon général, quels sont les outils aujourd’hui à disposition d’une organisation pour assurer la montée en compétence de ses devs ?

Le moyen le plus classique utilisé aujourd’hui sont les formations classiques piochées dans le catalogue de l’entreprise: la plupart du temps on parle de formations de quelques jours maximum sur un sujet que l’on souhaite approfondir, avant de revenir dans son équipe. Mais lorsque cette formation est effectuée à l’extérieur, ou avec d’autres participants, en général quand on revient dans son équipe c’est d’abord pour terminer la feature qu’on laissée, et continuer sur le delivery. Il n’y a pas d’exploitation optimale des nouvelles compétences acquises, l’équipe ne sait pas vraiment en détail ce qu’on a appris, et peu de temps est consacré pour partager ses nouvelles connaissances apprises et réfléchir ensemble à comment les mettre en scène dans son quotidien. Et ce n’est pas lié à la qualité de la formation ou du formateur, mais plutôt à la manière dont elle s’inscrit dans un parcours d’apprentissage plus global. C’est une forme de patch plutôt que de vrai changement de modèle mental ou d’évolution dans son career path.

Au delà de ces formations classiques, on a également le far west des formations en ligne. Il existe de tout, du bon et du moins bon, du gratuit, du payant, mais dans tous les cas il y a tout de même un sentiment de solitude face à l’apprentissage (malgré les slack ou discord existants), dans la mesure où ces contenus se veulent les plus génériques possibles (je parle plus de la forme que du fond), et peuvent difficilement prendre en compte le contexte de la personne, de son organisation et de sa stack. On a vu de nombreuses formations et bootcamps autour de la MERN stack ou MEAN stack, mais il y a autant de stacks que d’organisations dans la pratique si on regarde au-delà des langages principaux utilisés.

L’autre moyen, à mon sens des plus efficaces, est de multiplier les occasions de pair programmer avec un senior de son équipe, voir de mob programmer avec toute son équipe. Plusieurs avantages à ça:

• on travaille dans le même contexte d’organisation et de stack
• on crée des interactions avec ses collègues, ce qui abaisse la barrière pour demander de l’aide ou une review plus tard
• cela crée de la cohésion et de l’empathie entre les membres d’une équipe

J’entends de plus en plus d’équipes qui adoptent ces pratiquent au quotidien.

Et parfois ça va encore plus loin avec des initiatives géniales comme chez Qonto, leboncoin, Octo (dont c’est la marque de fabrique), Vinted et récemment Mirakl, qui ont mis en place des programmes en interne de montée en compétences par les seniors et experts dans l’organisation. Cependant pour parvenir à cela, il faut être un certain nombre à la tech pour ne pas trop rogner sur le delivery.

La question qu’on est en droit de se poser alors c’est: dans une période de frugalité comme aujourd’hui est-ce vraiment possible d’assurer la montée en compétence progressive et avancée de ses devs ? Une telle mise en place n’est pas si simple et demande du temps. Qui plus est du temps de gens experts sur le sujet dans l’organisation. Et sans aller jusqu’à créer une académie en interne, le simple fait de faire du pair ou du mob programming nécessite du temps. Or quand on réduit les effectifs ou qu’on gèle ses embauches, on va plutôt inciter les experts à se refocus sur le delivery et la qualité de la stack elle-même, plutôt que de passer du temps à faire monter en compétences les profils moins expérimentés.

Le problème reste entier et n’est pas encore totalement résolu à l’heure actuelle.

Sensibilité produit

On pourrait dire qu’un ou une bonne dev c’est 1/3 de hard skills, 1/3 de soft skills et 1/3 de connaissance métier. Et sur ce dernier point, cela implique d’avoir une connaissance fine du secteur, des contraintes et des règles de gestion de son produit. Par ailleurs être agile, c’est être vraiment au contact des utilisateurs, écouter leurs feedbacks, et avancer de manière incrémentale et itérative.

Cela peut passer par la participer à la conception des users stories plutôt que de simplement prendre des tickets déjà rédigés les uns après les autres. Des ateliers comme les events storming ou le story mapping sont de plus en plus utilisées dans les organisation tech pour faire émerger la logique métier en équipe, main dans la main entre produit, QA, UX et devs.

Les entreprises attendent de plus en plus des devs d’être sensibles au besoin de l’utilisateur, et pas seulement quand on fait du front, mais aussi côté back, car on parle ici de comportement du système et des utilisateurs sur son produit. Ces qualités sont de plus en plus recherchées et prisées des entreprises qui recrutent.

La question du remote

Vaste question, devenue très conflictuelle ces derniers temps. Ce n’est pas aussi simple qu’on l’imagine de faire du remote. Evidemment du point de vue purement logistique pour les devs, c’est mieux: moins de transport, moins de réunions intempestives, plus de focus, meilleur équilibre perso/pro.

Mais dans le même temps on a envie de:

• maintenir une culture d’entreprise forte
• favoriser le partage de connaissances
• favoriser les interactions entre devs: pair programming, échanges avec les autres devs
• permettre des moments de mentoring fréquents
• la création et l’entretien du lien social entre les équipes

J’ai pu observer de plus en plus d’entreprises revenir à un mode plus hybride, par opposition au full remote des années Covid. Cela implique a priori de recruter à minima dans sa région. Or beaucoup de devs habitent loin des métropoles, diminuant ainsi leur employabilité vis-à-vis de ces entreprises.

Certaines organisations ont sans doute mal géré le full remote, en même temps personne n’avait la recette magique, ce qui a pu créer un mauvais précédent. La culture remote n’est pas quelque chose de trivial à mettre en place. De la même manière qu’il faut respecter le besoin des devs, il faut également respecter le besoin des boîtes, tant qu’il ne s’agit pas de faire du contrôle ou du micro-management.

Si les salaires ne vont augmenter au même rythme qu’avant et si les grands plans d’embauches continuent d’être plus rares qu’avant, qui de l’oeuf (l’entreprise) ou de la poule (les devs) fera le premier pas vers l’autre en termes de critères de conditions de travail ? Il n’y aura probablement pas une seule réponse à cette question, et très certainement que d’autres facteurs vont devenir de plus en plus importants pour trancher, comme un produit qui a du sens et de l’impact, ou encore un environnement pour progresser dans les meilleures conditions, ou enfin des pratiques fortes et ancrées autour de la qualité logicielle.

Conclusion

Les besoins des entreprises évoluent, plutôt pour aller vers du mieux, à savoir un besoin plus rationnel (fini l’embauche pour l’embauche parce qu’on a de l‘argent), plus fin, mieux défini, et qui accompagne l’augmentation du soin apporté à la qualité.

Tout cela implique une mise à jour du côté des devs, mise à jour dans les conditions de travail, mais aussi et surtout dans les compétences à développer. Il ne s’agit plus seulement d’aller vers telle ou telle techno à la mode, mais de prendre de l’ownership sur la stack en général, d’être polyvalent et curieux, pour dire les choses autrement: d’être d’avantage un software engineer qu’un simple “codeur”.

Avant de passer au point de vue des devs, à ce que 2023 change pour eux, et à comment appréhender cette nouvelle donne pour être en position de force sur le marché de l’emploi, je vais revenir sur un des bouleversements fondamentaux de 2023: l‘éclosion de l’IA à grande échelle et ses impacts côté dev.