Tous les decks

L'évolution du métier

De développeur à product engineer

Le code devient courant. Le jugement devient rare. Anatomie d'une transition en cours.

Chapitre 01

Le monde d'avant.
Tout passait par le code.

Pendant des décennies, la fabrication d'un logiciel a suivi un chemin linéaire et prévisible. Le PM écrit la demande. Le développeur la réalise. L'équipe QA la vérifie. Chaque rôle restait dans son couloir, chaque étape attendait la précédente.

Dans le monde d'avant, le développeur était d'abord un expert technique. Sa valeur tenait à sa capacité à maîtriser une matière difficile : le langage, l'architecture, les frameworks, la performance, les bugs. Le code était le cœur du métier, et savoir le produire vite, proprement et durablement faisait la différence.

« L'IA ne consiste pas vraiment à écrire plus de code plus vite. Elle consiste, au fond, à construire de meilleurs logiciels. »

Addy Osmani, @addyosmani

Ce modèle reposait sur une hypothèse implicite. Le code est difficile, donc celui qui code a de la valeur. Que se passe-t-il quand cette hypothèse s'effondre ?

Chapitre 02

Middle Out.
La valeur se déplace.

Chintan Turakhia a résumé ce changement dans un schéma devenu populaire. L'idée tient en une phrase. Sortez du milieu.

Où passer son tempsComment la valeur se répartit dans le cycle de fabrication
Courbe de répartition du temps de travailHier, le temps de travail formait une bosse centrée sur le code. Demain, il se répartit en deux pics. L'intention au départ et le soin du détail à la fin prennent de la valeur, tandis que le code au milieu en perd.Temps investiHIERINTENTIONCadrageConceptionPérimètreCritères de succèsCode(écriture et relecture)↓ devient courantSOINValidationJuste l'essentielSoin du détail

Le milieu, coder, relire, corriger, se fait peu à peu absorber par l'intelligence artificielle. Copilot, Claude, Cursor. Le code devient un produit fini, plus un artisanat.

Les deux extrémités prennent toute la valeur. L'intention, comprendre quoi construire, et le soin du détail, ne livrer que ce qui compte, et bien le livrer, deviennent les compétences qui font la différence.

Chapitre 03

Les trois zones,
en clair

La courbe de valeur redessinée

D'une seule bosse centrale à deux pics aux extrémités

  • Intention

    Comprendre le problème. Identifier ce qui mérite vraiment d'être construit. Concevoir la solution. Cadrer le périmètre. Définir les critères de succès.

    FORTE VALEUR
  • Code

    Écrire du code reste nécessaire, mais ce n'est plus le centre unique de la valeur. Une partie croissante de l'écriture, de la correction et de la génération est assistée par l'intelligence artificielle. Le développeur devient moins exécutant, plus responsable de la solution produite.

    VALEUR DÉPLACÉE
  • Soin du détail

    Vérifier que la solution répond au besoin. Arbitrer ce qui doit être livré ou non. Assumer la qualité finale. Soigner l'expérience utilisateur, les détails et la cohérence d'ensemble.

    FORTE VALEUR
  • 0

    des développeurs s'appuient sur l'IA pour coder (2025)

  • 0

    de gain de vitesse sur le code répétitif

  • 0

    seulement s'en servent en amont, sur l'intention

Chapitre 04

L'évolution du métier.
Développeur, product engineer, et ensuite ?

  1. 2000 à 2015

    Le développeur front

    La valeur tient à la qualité du code. Maîtrise du langage, des modèles, de l'architecture technique. Le PM décide, le développeur exécute.

  2. 2015 à 2023

    Le développeur fullstack

    La valeur tient à l'autonomie. Interface, serveur et infrastructure. On attend du développeur qu'il comprenne le produit, mais il reste centré sur la réalisation.

  3. 2023 à 2026

    Le product engineer

    La valeur tient au jugement produit et à l'exécution. Il code avec l'IA, décide quoi construire, mesure l'impact. Le ticket s'efface au profit de la responsabilité du résultat.

  4. À partir de 2026

    L'orchestrateur

    La valeur tient à l'intention, au soin du détail et aux boucles de retour. Il pilote des agents, conçoit des systèmes, mesure le réel. Le code devient un détail de réalisation.

Chapitre 05

La redistribution
des compétences

La même personne, à trois époques. Voici comment son éventail de compétences se transforme.

  • Hier
  • Aujourd'hui
  • Demain

INTENTION

Découverte du besoin

Hier
Ajd.
Demain

Conception de systèmes

Hier
Ajd.
Demain

Définition des critères de succès

Hier
Ajd.
Demain

CODE

Code pur

Hier
Ajd.
Demain

Formulation des consignes à l'IA

Hier
Ajd.
Demain

SOIN DU DÉTAIL

Expérience utilisateur et finition

Hier
Ajd.
Demain

Analyse des données d'usage

Hier
Ajd.
Demain

Distribution

Hier
Ajd.
Demain

Trois profils,
trois époques

  • Hier

    Le développeur

    • Reçoit des tickets
    • Optimise la vitesse de production
    • Se mesure en points d'effort
    • Livre des fonctionnalités
    • Responsable de la technique
  • Aujourd'hui

    Le product engineer

    • Cerne le problème
    • Optimise l'impact
    • Se mesure aux résultats obtenus
    • Livre des solutions
    • Responsable du produit
  • Demain

    L'orchestrateur

    • Formule l'intention
    • Optimise les systèmes
    • Se mesure au réel
    • Pilote des agents
    • Responsable de bout en bout

Chapitre 06

Les qualités humaines.
Ce qui fait la différence.

Au-delà du code, c'est ton jugement et ta manière de travailler qui comptent. Voici les cinq qualités qui séparent un bon développeur d'un excellent product engineer.

  • 01

    Sens du résultat

    Tu te sens responsable du résultat, pas seulement de la livraison. Tu mesures l'effet réel sur l'élève.

  • 02

    Curiosité et autonomie

    Une vraie envie d'apprendre de nouveaux outils. La capacité d'avancer seul entre plusieurs sujets.

  • 03

    Sens du produit

    Tu sais te mettre à la place d'un lycéen de 17 ans et te demander si ce que tu construis l'aide vraiment.

  • 04

    Communication

    Tu expliques tes choix avec clarté. Tu donnes et reçois des retours en fin de cycle.

  • 05

    Pragmatisme

    Tu résous des problèmes complexes en allant à l'essentiel. Pas de complexité inutile, pas de compromis sur la qualité.

Chapitre 07

Notre façon de travailler
chez Edumapper

On ne fonctionne pas à la chaîne. Chez Edumapper, on s'organise en cellules produit.

La cellule produit

Une équipe resserrée, responsable d'un sujet de bout en bout

Cellule produit

1 product engineer
et 1 PM ou fondateur

Vivier d'experts

Sollicités au besoin,
sans alourdir la cellule

  • Design
  • Données
  • Science
  • Orientation
  • Juridique
  1. Idéation
  2. Prototype
  3. Test avec les utilisateurs
  4. Itération

Pas de chaîne où le PM écrit la consigne, le développeur exécute et l'équipe QA vérifie. La cellule possède son sujet de l'idée à la mise en ligne. Tu n'es jamais en bout de chaîne, tu es là dès le départ.

Chaque cellule avance dans une boucle d'itération continue. Pour aller vite et bien, elle s'appuie sur un vivier d'experts partagés qu'elle sollicite au besoin.

Chapitre 08

Comment avancer
dans ce nouveau monde

  1. Passe moins de temps à réaliser, plus à comprendre le problème.
  2. Confie le milieu à la machine. Agents, chaînes de traitement, génération de code.
  3. Investis dans la finition. C'est là que se loge le plaisir d'usage.
  4. Mesure l'effet réel, pas la quantité de code produit.
  5. Apprends à formuler l'intention mieux que quiconque.
  6. Ne livre que le nécessaire. Pas plus, mais avec soin.
  7. Le code est un détail. Le jugement est le produit.