Je suis ingénieur, pas codeur. Le code n'a jamais été le métier.

Une phrase revient chaque fois qu'on me demande ce que je fais : je suis un ingénieur, pas un codeur. Ce n'est pas une pose. C'est une définition du métier. Comprendre un problème réel, choisir le moyen qui donne le meilleur résultat, le livrer, puis prouver ce qu'il a changé. Le code est l'un de ces moyens. Les agents ne changent pas cette définition. Ils la rendent impossible à ignorer.

Ce que le marché appelle « product engineer »

Le mot circule depuis quelques années. En 2019, Gergely Orosz décrit le « product-minded engineer » : un développeur qui s'intéresse au produit lui-même, veut savoir pourquoi les décisions sont prises et comment les gens s'en servent. Il lui prête neuf traits, dont la propriété d'une fonctionnalité de bout en bout et des cycles de validation courts  (ouvrir le reçu). PostHog en a fait un manuel : un product engineer parle aux utilisateurs, décide quoi construire, porte le prix, le revenu et l'expérience, fait le support. Son travail « va au-delà de livrer du code »  (ouvrir le reçu).

Je signe tout ça. Mon métier est ingénieur produit : je réponds de l'impact sur le business, pas seulement du code livré. Ma définition s'écarte pourtant de celle du marché sur deux points.

Elle part de l'ingénieur, pas du développeur. PostHog écrit « un développeur logiciel qui… ». Je préfère la définition qu'un professeur d'ingénierie, Billy Vaughn Koen, a donnée en 1985 : la méthode de l'ingénieur est la stratégie pour provoquer le meilleur changement dans une situation mal comprise ou incertaine, avec les ressources disponibles  (ouvrir le reçu). Pas un mot sur le code. Le code, un atelier, un plan de formation, un tableur, une équipe, une nuée d'agents : ce sont des ressources. Je prends celle qui donne le meilleur résultat.

Elle exige une preuve. Le marché parle de sens produit, d'empathie, de goût. J'y tiens aussi, mais un ressenti ne dit pas si le changement a eu lieu. Je veux un état de référence avant de toucher à quoi que ce soit, une hypothèse, une définition de fini, et une mesure qu'un autre peut refaire. Les chiffres, oui, au service d'un récit qu'on comprend.

Un CV d'ingénieur liste des technologies. Le mien aussi : Kotlin, Java, Fortran, Ada. C'est ce qui dit le moins de ce que je fais.

Le même métier depuis l'aciérie

Le métier, constant

1. Comprendre
2. Choisir le moyen
3. Livrer
4. Prouver

---

Les moyens, changeants

1. 2005Développeur, Steriale code : migrations, services télécoms
2. 2008Chef de projet, aciérieateliers utilisateurs, 25 applications
3. 2013Change leader, aciérieplan Lean, 35 facilitateurs, 4 000 personnes
4. 2015IT manager, Anaquaroadmap produit, code, infrastructure
5. 2017Coach agile, AltranImpact Mapping, Event Storming
6. 2018Crafting lead, OctoTDD, audits de code, formation
7. 2021Ingénieur senior, scale-upconception, livraison, production
8. 2026Ingénieur avec des agentsje conçois, les agents exécutent, je fais prouver

J'ai commencé en 2005, diplôme d'ingénieur généraliste en poche, développeur puis chef d'équipe junior chez Steria  (ouvrir le reçu) : migration d'un système de conduite de combat, services pour des opérateurs télécoms. À l'aciérie, le métier s'est élargi d'un coup.

ArcelorMittal, 2008-2013. Chef de projet sur la transformation du système d'information d'une aciérie : plus de 50 logiciels, 16 M€ de budget  (ouvrir le reçu). J'ai organisé des ateliers avec les utilisateurs finaux pour partir de leurs besoins, et dirigé le design et le développement des interfaces : 7 personnes, 25 applications  (ouvrir le reçu). J'y ai vu un opérateur expérimenté entendre qu'une machine allait casser, et déclencher l'arrêt d'urgence quelques secondes avant la casse  (ouvrir le reçu). Aucune spécification ne décrit ce savoir. Il faut aller le chercher sur place. Toyota en a fait un principe, aller voir soi-même pour comprendre la situation  (ouvrir le reçu).

Le plan d'amélioration, 2013-2014. Pas une ligne de code. Un plan Lean et Théorie des contraintes pour la coulée continue, des matrices de déploiement des coûts qui chiffrent chaque perte pour choisir les actions qui rapportent le plus, un objectif de 20 M€ de gain par an, 200 journées d'atelier  (ouvrir le reçu), et 35 facilitateurs formés pour 4 000 participants  (ouvrir le reçu). Le produit, c'était un plan que 4 000 personnes adoptent. Le moyen, c'était la formation. Même métier.

Anaqua, 2015-2017. IT manager : la roadmap produit, le développement sur toute la suite, l'infrastructure (300 k€)  (ouvrir le reçu). Trois métiers sur une seule fiche de poste.

Altran puis Octo, 2017-2021. Coach agile, j'animais des ateliers d'Impact Mapping et d'Event Storming  (ouvrir le reçu). L'Impact Mapping de Gojko Adzic  (ouvrir le reçu) part de l'objectif, puis des acteurs, puis des changements de comportement attendus, et seulement à la fin des livrables. C'est encore l'ordre dans lequel je pense. Chez Octo, j'ai mené des audits de code et donné des formations au TDD et au Clean Code  (ouvrir le reçu). La qualité du code n'est pas une fin. C'est ce qui permet de changer de direction vite quand la mesure dit qu'on s'est trompé.

Depuis 2021, je suis ingénieur senior  (ouvrir le reçu) dans une scale-up parisienne : je conçois, je livre, j'exploite. Plus de quinze ans que je change de moyens, pas de métier.

Pourquoi l'IA confirme le métier au lieu de le remplacer

Si le métier était de taper du code, l'IA le remplacerait. PostHog le dit sans détour : n'importe qui peut payer 20 dollars pour une machine qui crache du code qui marche assez bien  (ouvrir le reçu), donc le code ne suffit plus, à lui seul, à créer un avantage. « Mais voici la bonne nouvelle : il n'a jamais suffi. »

Anthropic a interrogé 132 de ses ingénieurs et chercheurs en août 2025  (ouvrir le reçu). Beaucoup décrivent un rôle qui passe d'écrire du code à piloter des IA, et tous deviennent plus « full-stack ». Ils nomment aussi le piège : le paradoxe de la supervision. Superviser Claude demande justement les compétences qui s'atrophient quand on lui délègue trop.

J'ai voulu faire vivre ce piège plutôt que l'expliquer. En juin 2026, j'ai conçu en deux jours un atelier, « IA = Ingénieur Augmenté / Ingénieur Aliéné », animé le 4 juin à Alpes Craft  (ouvrir le reçu). Une même codebase, un clone de Medium, et deux phases. D'abord descendre un backlog plus long que le créneau, en déléguant à l'agent. Puis reprendre ce qui a été livré et l'attaquer sous tous les angles avec l'IA, en tranchant soi-même à chaque sortie d'agent.

Entre les deux, un quiz individuel sépare ce que je crois de ce que fait mon code. Une question demande où un article publié devient visible. Le système de tags de la codebase n'enregistre rien : aucun article n'est jamais atteignable par tag  (ouvrir le reçu). Qui coche « par tag » a supposé que le produit marche sans l'avoir vérifié.

Ce matin-là, moins de trois heures avant le début, j'ai écrit à mon agent l'idée centrale de l'atelier : « on revient à notre métier d'ingénieur qui consiste à comprendre des problèmes et à y trouver des solutions innovantes. On passe alors en position méta très souvent […] si on en profite pour apprendre au passage, on devient nous-même superpuissant »  (ouvrir le reçu). Le document de conception le résume en une ligne : produire devient de moins en moins coûteux, comprendre devient la ressource rare.

Aujourd'hui, je ne tape presque plus de code  (ouvrir le reçu). Je conçois, je pilote des agents, j'exige des preuves, je tranche. Ce n'est pas une lacune à excuser. C'est le même métier, avec un levier plus long. L'expérience sans les agents, c'est de la lenteur. Les agents sans l'expérience, c'est du volume sans direction.

Se passer des agents aujourd'hui serait une faute. Croire qu'ils construiront seuls un produit de A à Z en est une autre. L'humain garde les décisions qui demandent du jugement, jusqu'au « je ne le sens pas ». Les agents prennent la mise en œuvre. Mon travail est de bâtir le système qui permet ça.

La démarche, en six gestes

Avec ou sans agents, je suis la même boucle.

1. Aller voir le besoin à la source. Un utilisateur, une session, une plainte, un log. Pas le résumé qu'on m'en fait.
2. Écrire l'état de référence avant de changer quoi que ce soit. Sans lui, aucune amélioration ne se démontre.
3. Poser une hypothèse et une définition de fini. Fini est un fait observable chez l'utilisateur, pas un ticket fermé.
4. Choisir le moyen le moins cher qui répond. Souvent un script plutôt qu'un modèle. Parfois un atelier. Parfois une suppression.
5. Livrer petit, mesurer, recommencer. Une hypothèse par expérience, pour qu'un échec désigne sa cause.
6. Prouver. Un chiffre dit d'où il vient et comment on le recompte.

Ce qu'on apprend au sixième geste repart au premier.

Je m'applique la règle. Chaque affirmation de ce site porte un reçu : la source, la méthode, la date, la solidité de la preuve  (ouvrir le reçu). Un identifiant de reçu inconnu fait échouer le build, et le site ne se déploie pas  (ouvrir le reçu). Les faits de carrière de cet article sont marqués « déclarés » : c'est ma parole, et le reçu le dit (pourquoi des reçus).

Comment l'appliquer

1. Avant la première ligne de code, écrivez l'état de référence. Un chiffre, une capture, un test qui échoue. Si vous ne pouvez pas l'écrire, vous ne savez pas encore ce que vous changez.
2. Rédigez « fini » comme un fait chez l'utilisateur. « Un nouvel inscrit publie son premier article en moins de deux minutes », pas « la PR est mergée ».
3. Listez trois moyens avant d'en choisir un, dont un sans code. Un réglage, un script, une page de doc, une suppression. Il gagne plus souvent qu'on ne croit.
4. Allez voir l'usage chaque semaine. Une session utilisateur, la file du support, une heure à côté de quelqu'un qui se sert de votre outil.
5. Avec les agents, déléguez l'exécution, jamais la compréhension. Le test de mon atelier : pouvez-vous dire ce que fait le code livré cette semaine sans le relire ? Sinon, vous avez livré du volume, pas un résultat.
6. Donnez un reçu à vos propres chiffres. Dans un bilan, une revue de sprint, un CV : d'où vient le nombre, et comment un autre le recompte.

Le titre change selon les entreprises : product engineer, staff, lead. Le métier, lui, ne change pas. Comprendre, concevoir, livrer, exploiter, mesurer : le tout, pas un morceau. Les agents ont rendu le morceau du milieu presque gratuit. Il reste tout le reste, et c'est le métier.