L'IA n'a pas supprimé mon travail, elle en a déplacé le centre de gravité

Un retour d'expérience sur six mois de travail augmenté et sur la question que ça pose au recrutement.

Le contexte

Je porte plusieurs casquettes au quotidien. Solutions Architect, Product Manager, Scrum Master, développeur. Selon les projets et selon les jours, je passe de l'une à l'autre. À côté de ça j'ai mes side projects et un rôle de CTO. Et j'ai des enfants dont je suis les devoirs et les exercices, sans parler de la maison.

Écrit comme ça, sur le papier, ça ne tient pas. Pendant longtemps ça ne tenait effectivement pas très bien. Ce qui a changé, ce n'est pas mon organisation. C'est la nature de ce que je fais réellement dans une journée.

Ce que l'IA fait à ma place aujourd'hui

Je vais être précis, parce que je pense que le flou est le principal problème des discours sur ce sujet. Voici ce qui est réellement délégué chez moi :

• Le développement. Pas du boilerplate, du vrai code de feature, avec des specs que je fournis.
• Les tests. Génération, couverture, cas limites que je n'aurais pas pensé à écrire un vendredi soir.
• La gestion du backlog. Découpage des epics, rédaction des user stories, estimation initiale, mise à jour des tickets.
• Le design system. Composants, tokens, documentation, cohérence entre les écrans.

Ce qui reste chez moi :

• Cadrer le problème avant qu'il devienne une tâche.
• Arbitrer entre plusieurs solutions techniquement valables.
• Valider ou refuser ce qui est produit.
• Assumer les conséquences.

Le mot important dans cette deuxième liste est le dernier. Assumer.

Les effets concrets

Trois choses ont changé et je les mesure.

Je tiens plusieurs projets en parallèle sans perdre le fil. Avant, le parallélisme me coûtait un prix caché : le temps de rechargement du contexte. Reprendre un projet laissé trois jours, c'était vingt minutes pour retrouver où j'en étais. Aujourd'hui l'état du projet est documenté au fil de l'eau, et je reprends beaucoup plus vite.

J'ai gardé de l'énergie pour le reste. C'est le point que je n'avais pas anticipé. La fatigue de fin de journée n'était pas seulement une fatigue de production, c'était une fatigue d'accumulation de petites décisions sans enjeu. Nommer une variable, choisir un pattern de dossier, rédiger le ticket. Ces micro décisions ne fatiguent pas individuellement, elles fatiguent par leur volume.

Le suivi scolaire de mes enfants tient dans la semaine. Je le mentionne parce que c'est le meilleur indicateur que j'ai. Ce n'est pas un gain de productivité mesuré en story points, c'est un gain de disponibilité mentale. Et c'est celui qui compte le plus pour moi.

Ce que je pense pouvoir déléguer ensuite

Je ne crois pas être arrivé au bout. Je vois déjà des choses qui sont aujourd'hui de mon ressort et qui ne le seront plus dans quelques mois. La rédaction de la documentation d'architecture. La préparation des cérémonies agiles. Une partie de la revue de code, sur les critères objectivables au moins. Peut être le premier niveau d'arbitrage technique, quand le contexte est suffisamment cadré.

La direction est claire : je descends progressivement vers le haut de la chaîne. Je passe moins de temps à faire et plus de temps à décider ce qui doit être fait.

La vraie question : qu'est ce qu'on recrute demain ?

C'est là que ma réflexion se déplace du personnel vers le collectif.

Si l'exécution se compresse à ce point, est ce qu'on recrute encore un développeur, un PM ou un Scrum Master ? Ou est ce qu'on recrute une capacité à cadrer, orchestrer et porter un périmètre en autonomie ?

Mon intuition penche vers la seconde option. Mais je veux être honnête sur les limites de cette intuition, parce que je vois trois angles morts dans mon propre raisonnement.

Angle mort numéro un : je valide parce que j'ai déjà fait

Mon setup fonctionne pour une raison que je ne dois pas oublier. Je suis capable de repérer une mauvaise décision d'architecture en quelques secondes parce que j'ai vécu les conséquences des mauvaises décisions d'architecture. Je sais reconnaître un test qui ne teste rien parce que j'ai déjà livré du code couvert à quatre vingt pour cent et cassé en production.

Cette capacité de validation n'est pas une compétence séparée. Elle est le résidu de dix ans d'exécution.

Donc quand je dis qu'on recrutera des orchestrateurs plutôt que des exécutants, je dois préciser : un orchestrateur sans profondeur technique ne valide rien. Il approuve. Ce n'est pas la même chose, et la différence ne se voit pas tout de suite. Elle se voit six mois plus tard, dans la dette.

Angle mort numéro deux : la charge de décision est plus discrète que la charge d'exécution

Je dis que je suis moins fatigué. C'est vrai. Mais je surveille quelque chose.

Quand vous exécutez, votre limite est visible. Vous n'écrivez pas dix mille lignes dans une journée, votre corps vous arrête. Quand vous décidez, la limite est invisible. Rien ne vous empêche de prendre soixante décisions dans une journée. Simplement, les dix dernières seront moins bonnes que les dix premières, et vous ne le saurez pas sur le moment.

Le goulot d'étranglement n'a pas disparu de l'équipe. Il s'est déplacé vers moi. Si je multiplie le débit par trois sans changer ma capacité d'arbitrage, je ne suis pas plus performant, je suis juste devenu le point de défaillance unique du système.

Ce que je fais pour l'instant : je limite volontairement le nombre de sujets ouverts en parallèle, et je force un délai avant les décisions structurantes. Ce n'est pas parfait mais c'est mieux que de croire que ma capacité de jugement est illimitée.

Angle mort numéro trois : comment fabrique t on les seniors de 2032 ?

C'est celui qui me préoccupe le plus et je n'ai pas de réponse.

Le junior apprenait en faisant les tâches que je délègue aujourd'hui à l'IA. Le CRUD, les tests unitaires, le ticket mal écrit qu'il fallait clarifier avec le PM. C'était ingrat et c'était formateur. Ce n'était pas un passage obligé par tradition, c'était le mécanisme par lequel on accumulait les cicatrices qui permettent de valider plus tard.

Si on retire cette marche, on ne supprime pas la marche. On la déplace vers le haut et on la rend infranchissable. On recrutera des seniors pendant cinq ans, puis on cherchera des seniors qu'on n'aura pas formés.

Je pense que le vrai chantier des équipes tech dans les trois prochaines années n'est pas l'adoption de l'IA. C'est la reconstruction d'un parcours d'apprentissage quand le terrain d'entraînement a disparu. Peut être en faisant faire aux juniors la validation plutôt que la production. Peut être en leur donnant à débugger ce que l'IA a produit, ce qui est un excellent exercice. Je n'en sais rien encore.

Ce que je retiens

Le métier ne disparaît pas. Il se durcit par le haut.

Le profil qui gagne n'est pas celui qui sait tout faire à la surface, c'est le T bien dessiné: une vraie profondeur sur un domaine, plus assez de largeur pour piloter le reste sans se faire raconter n'importe quoi. Cette combinaison était déjà valorisée. Elle devient la condition d'entrée.

Et ce qui se contracte, ce n'est pas le rôle de développeur. C'est le poste d'exécution pure, quel que soit son intitulé. Le PM qui recopie des specs, le Scrum Master qui anime des rituels sans arbitrer, le dev qui implémente sans questionner le besoin. Ces trois là sont menacés par la même chose.

Je continue d'observer. Ce texte est un instantané de ma réflexion à date, pas une conclusion. Si votre expérience diffère de la mienne, je suis très intéressé de l'entendre.

TakkJokk,