L'IA libère la place pour développer de nouvelles compétences

Quand un agent peut coder presque tout ce qu'on lui demande, savoir exécuter un ticket ne suffit plus. Deux responsabilités restent difficiles à remplacer : décider ce qu'il faut construire et tenir la dette technique.

Vous êtes encore payé pour la partie que l'agent apprend le plus vite.

En régie, on vous confie un périmètre déjà décidé. Vous transformez les tickets en code, puis vous passez au suivant. Même lorsque le travail est bon, il reste difficile à distinguer de celui d'un autre développeur sur un CV.

Exécuter

Vous recevez un périmètre déjà fermé.

Quelqu'un d'autre choisit le problème et la solution. Votre valeur est jugée sur la vitesse à laquelle vous livrez le code demandé.

Répondre du résultat

Vous prenez la décision avant de coder.

Vous clarifiez le besoin, choisissez la plus petite solution utile et imposez vos standards à l'agent. Le code devient un moyen, pas la preuve de votre valeur.

Des humains planifient et valident le travail, tandis que des agents réalisent l'implémentation.
L'agent prend en charge l'implémentation. Vous restez responsable du plan et de la validation.

Cette position a un nom : Product Engineer.

Il reste développeur et ajoute une responsabilité produit. Il garde les deux responsabilités que l'agent ne peut pas assumer à sa place.

Product

Décider ce qui mérite d'être construit.

Comprendre le besoin réel, réduire le périmètre et mesurer si la solution améliore quelque chose pour l'utilisateur.

Engineer

Répondre de ce qui part en production.

Tenir la dette technique, fixer les standards et relire le code de l'agent comme n'importe quelle autre contribution.

Le Product Engineer ne cherche pas à coder plus vite. Il décide mieux et assume ce qu'il livre.

Vous pouvez commencer sans quitter votre mission.

Vous n'avez pas besoin de lancer un produit le soir. Votre mission contient déjà des problèmes que personne ne prend : une dette qui ralentit l'équipe, un incident qui revient ou une étape du produit que personne ne mesure.

  1. Repérez un problème assez petit pour être pris sans attendre un nouveau titre.
  2. Proposez la plus petite brique utile, puis mesurez ce qu'elle change.
  3. Gardez la décision et son impact pour pouvoir les raconter sans exposer le client.

Lego Driven Development

Partez de la brique la plus simple qui répond au besoin. N'en dépliez une nouvelle que lorsque la complexité l'exige. Vous progressez sur un vrai produit sans demander six mois de chantier ni une permission générale de tout refaire.

J'ai commencé par prendre la dette que personne ne voulait.

En janvier 2022, j'étais en ESN sur un pôle web de deux développeurs. Je livrais les tickets d'un périmètre décidé ailleurs. J'ai commencé par demander du temps pour remettre à niveau une codebase encore en Angular 9.

Pendant une année, la dette technique a occupé la moitié des sprints. J'ai préparé plus de 200 tâches techniques en trois ans pour une équipe pouvant mobiliser six développeurs. Sur la même période, le pôle est passé de 3 à 16 développeurs.

Cette expérience m'a donné une preuve que les recruteurs pouvaient lire. J'ai ensuite rejoint Criteo.

Une décision visible vaut plus qu'une technologie de plus sur un CV.

Ajouter "Product Engineer" sous votre nom ne suffit pas. En entretien, il faut montrer des décisions réelles, leurs conséquences et une façon de travailler qu'une boîte produit peut évaluer. C'est ce qui permet de viser les rôles et les niveaux de rémunération autour de 60 k sans quitter son CDI avant d'avoir signé.

Comprenez ce déplacement avant de le subir.

Chaque semaine, je partage une analyse pour comprendre ce que l'IA déplace, prendre du terrain dans votre mission et transformer vos décisions en preuve professionnelle.

Recevoir les prochaines analyses