Quel rôle tech convient à un Senior Developer dans la vague de l'IA ?
Par Bastian Brand, Ph.D. ·
Tu es bon dans ton travail, correctement payé — et de plus en plus convaincu que regarder cette vague depuis un siège de salarié est le choix coûteux. La réponse évidente, c'est “reste developer, ajoute de l'IA.” Parfois, c'est juste. Mais c'est la réponse que donne presque chaque developer, et pour un tiers d'entre eux, elle est fausse.
Le malaise, nommé précisément
Le schéma apparaît dans nos données d'assessment et dans la moitié des conversations de senior devs sur internet : le boulot va bien, la paie va bien, et pourtant quelque chose cloche. En général, c'est l'une de deux choses. Soit l'échelle hiérarchique a discrètement échangé le fait de construire contre celui de coordonner — la promotion qui a troqué tes meilleures heures contre des réunions — soit la vague elle-même est le malaise : une fenêtre de repositionnement qui ne s'ouvre qu'une fois par décennie est ouverte, et ton agenda ressemble exactement à celui de 2021.
Les deux versions sont mal diagnostiquées en “je devrais apprendre plus d'IA.” Mais les compétences ne sont pas le goulot d'étranglement pour un senior developer — la position, si. La question n'est pas quoi apprendre ensuite. C'est quel rôle dans l'écosystème convertit dix ans de profondeur en ingénierie en le plus grand levier.
Le piège par défaut : “je suis dev, donc — Developer”
L'identité est le pire conseiller de carrière dans un cycle du hype. Le codeur choisit par réflexe le rôle Developer, comme un avocat choisit par réflexe Lawyer — et pour beaucoup de developers, ce choix par défaut est réellement le bon : demande au sommet, conversion directe, l'usage le plus profond des compétences existantes. Le problème, c'est que ce choix par défaut est fait sans vérifier les alternatives, par des gens dont le véritable atout est d'expliquer, ou de curer, ou de livrer de petites choses qui leur appartiennent.
Dix ans de profondeur backend, c'est une main forte dans au moins quatre jeux différents. La jouer dans le mauvais ne échoue pas bruyamment — ça se capitalise simplement plus lentement, pendant des années.
Ce qui différencie vraiment les developers
Entre deux ingénieurs de même niveau de séniorité, les différences pertinentes pour le rôle ne sont presque jamais techniques. Elles sont comportementales :
- As-tu besoin de posséder le résultat ?Certains devs sont dynamisés par un effort d'équipe bien mené ; d'autres ne s'animent que lorsque ce qui est livré est le leur.
- Expliquer te donne-t-il de l'énergie ou t'en prive-t-il ? Écrire sur ce que tu as construit, répondre aux utilisateurs, enseigner — pour certains, c'est un second moteur ; pour d'autres, une charge.
- Combien d'incertitude de revenu peux-tu vraiment absorber ?Pas de manière idéalisée — vraiment. Des mois sans salaire sont un atout de certaines directions et un facteur rédhibitoire pour d'autres.
- Construire ou comprendre ?Un bon samedi se termine avec quelque chose qui fonctionne — ou avec un schéma que personne d'autre n'a encore vu. Ce sont des rôles différents.
Les quatre directions réalistes
Pour un senior developer qui entre dans la vague de l'IA, quatre directions couvrent la plupart des issues honnêtes (descriptions complètes sur la page des rôles) :
Rester Developer — mais spécialisé et visible
Tu veux construire, tu aimes être salarié, et la vague est ton opportunité de spécialisation. Le facteur différenciant, ce n'est pas plus de compétences — c'est rendre le travail lisible : le developer qui construit en public se capitalise ; celui qui se contente de coder devient une marchandise.
The Open-Source Contributor
Tu peux tolérer de construire des choses utilisées par des milliers de gens sans que personne ne connaisse ton nom — et tu comprends que les contributions mergées sont des références qu'aucun CV ne peut falsifier. Un rôle de construction : la réputation se convertit plus tard, en embauche, conseil ou création d'entreprise.
The Micro-Founder
Tu préfères posséder 100 % de quelque chose de petit plutôt que 5 % de quelque chose de grand, et ta journée de rêve ne comporte aucune réunion. Le modèle de levier : un produit qui gagne de l'argent pendant que tu dors. Le coût : 12 à 36 mois de patience en parallèle du job alimentaire.
The Infrastructure Landlord
Tu as ressenti le prix du compute de l'intérieur et tu vois l'infrastructure comme un marché, pas comme un coût. La position du vendeur de pelles — gagne quel que soit le produit final qui l'emporte. La barrière : des exigences en capital que la plupart des autres rôles n'ont pas.
(Et parfois la réponse honnête n'est aucune des quatre — le developer dont le véritable atout est d'expliquer appartient aux rôles de knowledge-producer, et le sait généralement dès l'instant où quelqu'un le dit à voix haute.)
Ce que coûte un mauvais choix
La version classique, c'est l'histoire de la promotion : le meilleur builder de l'équipe est nommé lead, l'agenda se remplit de coordination, et dix-huit mois plus tard il est mieux payé, plus loin du travail qui lui donnait de l'énergie, et regarde vaguement les offres d'emploi. C'est un décalage de rôle vécu au ralenti — rien n'a échoué, tout est simplement devenu plus lourd.
Le timing de la vague rend le coût plus tranchant : se mal positionner pendant une phase de hype signifie revenir plus tard, quand la crédibilité facile a disparu et que le terrain est bondé. Si le quotidien d'une direction te vide de ton énergie dans les trente premiers jours, ce n'est pas un problème de discipline — ce sont des données.
Arrête de deviner — mesure le fit
Les quatre questions ci-dessus sont l'esquisse ; l'assessment est l'instrument. 77 questions comportementales, cinq dimensions pondérées à parts égales, évaluées contre les 27 rôles de l'écosystème — plus un contrôle de capacité (heures, réserve financière, risque) pour que la réponse s'adapte à ta vie, pas seulement à ton tempérament. Gratuit, résultats en quelques minutes.
Basé sur le modèle des 27 rôles du framework Hype Cycle. À propos de la méthode →
Dernière révision : juillet 2026
Bastian Brand, Ph.D. — auteur de The Hype Cycle Playbook, le cadre derrière l'évaluation roletype et ce blog. À propos de l'auteur →