Ingénieurs ou Développeurs ?
Le fossé mental qui décide si votre projet passe à l’échelle — ou s’effondre silencieusement en production
TL;DR :
La plupart des équipes disent vouloir des « ingénieurs », mais beaucoup récompensent des « développeurs ». Pas en tant que titres — en tant que mentalités. Le mode développeur optimise le débit (throughput). Le mode ingénieur optimise l’intégrité du produit à long terme. Vous avez besoin des deux, mais vous devez être honnête sur ce que votre système encourage réellement.
Voici une question qui empêche les dirigeants de dormir (généralement juste après le troisième incident « pourquoi est-ce encore cassé ? » du trimestre) :
Bâtissez-vous une équipe de développeurs… ou d’ingénieurs ?
Avant que cela ne soit rejeté comme une nuance sémantique : cette différence a façonné le destin de projets à enjeux élevés, d’industries entières et la santé à long terme de produits dont les gens dépendent.
Et spoiler : cela n’a presque rien à voir avec les diplômes.
D’abord, supprimons le mythe des diplômes
Certains des meilleurs technologues sur Terre sont autodidactes. Certains ont des doctorats. La plupart se situent quelque part au milieu.
Les diplômes comptent dans certains domaines réglementés et critiques pour la sécurité (dispositifs médicaux, aviation, infrastructures). Mais pour la plupart des équipes produit, la ligne de démarcation n’est pas académique.
C’est ceci :
Les développeurs optimisent pour les “outputs” (livrables). Les ingénieurs optimisent pour les “outcomes” (résultats).
Gardez cela en tête. C’est tout le sujet de cet article.
Mode développeur : expédier la tâche
Le mode développeur est fondamentalement orienté tâche.
Il y a un ticket.
Il y a des critères d’acceptation.
C’est fait.
Ticket suivant.
Ce n’est pas une insulte — c’est une capacité vitale. Le mode développeur prospère lorsque :
- les exigences sont raisonnablement claires,
- la priorité est l’élan (momentum),
- l’exécution doit être régulière et mesurable.
Cela s’intègre aussi parfaitement dans les tableaux de bord et les rapports d’état (car les livrables sont faciles à compter).
Le mode d’échec : le mode développeur peut continuer à avancer pour toujours dans un backlog sans fin… sans jamais demander si l’équipe avance vers la bonne destination.
Vous pouvez expédier constamment et pourtant :
- construire la mauvaise chose, ou
- construire la bonne chose sur une fondation qui ne tiendra pas.
Mode ingénieur : interroger la réalité
Le mode ingénieur commence par un instinct différent :
« Est-ce que cela a du sens ? »
Les ingénieurs remettent en question les exigences. Ils contestent les hypothèses. Ils se soucient de ce que le système devient après ce changement — pas seulement si le ticket peut être fermé avant vendredi.
Là où un développeur voit un ticket, un ingénieur voit :
- un système,
- avec des dépendances,
- avec des compromis,
- avec des conséquences à long terme.
Le mode ingénieur pose des questions qui semblent gênantes sur le moment et inestimables plus tard :
- Résolvons-nous le vrai problème — ou le symptôme le plus bruyant ?
- Pourquoi est-ce arrivé encore une fois ?
- Cette solution devient-elle plus simple… ou juste plus grosse ?
- Quelle dette technique créons-nous, et combien cela coûtera-t-il plus tard ?
La réalité finit par auditer tout le monde.
Pourquoi beaucoup de managers préfèrent le mode développeur (et pourquoi c’est dangereux)
C’est la partie inconfortable :
De nombreuses organisations sont structurées pour récompenser le mode développeur, car il produit des métriques propres et rapportables :
- tickets fermés
- fonctionnalités expédiées
- story points brûlés
- « nous sommes dans les temps »
C’est la nourriture de confort managériale. Cela calme les parties prenantes. Cela tient dans des slides.
Le mode ingénieur produit un autre type de phrase — souvent vraie, souvent nécessaire, et souvent terrifiante :
« Nous avons trouvé quelque chose de fondamentalement incorrect. Nous devrions nous arrêter et le réparer correctement. »
Cette phrase ne rentre pas bien dans un rapport d’état hebdomadaire.
Elle menace les délais. Elle force à mettre les compromis sur la table. Elle rend l’incertitude visible.
Mais c’est aussi la phrase qui empêche des désastres coûteux.
Trois lentilles du monde réel
Ce ne sont pas des pièges. Ce sont des modèles — comment les incitations façonnent le comportement à l’échelle.
1) Quand « terminé » ne signifie pas « fonctionne » (Healthcare.gov)
Le déploiement initial de Healthcare.gov est largement cité comme un cas où de nombreuses équipes ont livré des composants et des jalons — pourtant le système complet a lutté sous la demande du monde réel.
La leçon n’est pas « les gens ne savaient pas coder ».
C’est ceci :
Lorsque les équipes sont récompensées pour l’achèvement des tâches en silos, le système peut sembler complet sur le papier… tout en échouant dans son ensemble.
2) Le pouvoir d’arrêter la chaîne (Toyota)
Toyota a institutionnalisé un principe d’ingénierie que de nombreuses organisations logicielles font seulement semblant d’avoir :
Si quelque chose ne va pas, n’importe qui peut arrêter la chaîne.
La culture ne célèbre pas le mouvement. Elle célèbre la prévention :
- trouver les défauts tôt,
- corriger les causes profondes,
- éviter de répéter les mêmes problèmes.
C’est la pensée ingénierie transformée en muscle organisationnel.
3) Construire la fondation une fois (Estonie)
L’histoire du gouvernement numérique de l’Estonie est souvent citée parce qu’elle n’a pas commencé par « numériser chaque formulaire ».
Elle s’est concentrée sur l’architecture : construire une fondation sécurisée et interopérable pour que les services puissent être bâtis de manière fiable par-dessus pendant des années.
C’est une question d’ingénieur :
« Quelle fondation rend les 1 000 prochaines fonctionnalités possibles ? »
Encadré : La vraie différence (Outputs vs Outcomes)
Voici le diagnostic le plus simple.
Outputs (optimisé développeur) : tickets fermés, fonctionnalités expédiées, story points brûlés, bugs patchés.
Outcomes - Résultats (optimisé ingénieur) : incidents répétés éliminés, complexité réduite, douleur client supprimée, résilience du système améliorée.Les livrables (outputs) ressemblent à des progrès. Les résultats (outcomes) sont des progrès — mais ils sont plus difficiles à compter.
Alors… duquel avez-vous besoin maintenant ?
La réponse n’est pas « ingénieurs gentils, développeurs méchants ». C’est une pensée paresseuse.
Vous avez besoin des deux. La vraie question est :
Que récompense votre organisation ?
Une règle empirique pratique :
- Stade précoce / périmètre clair / itération rapide → le mode développeur peut gagner.
- Complexité croissante / incidents récurrents / utilisateurs à l’échelle → le mode ingénieur devient existentiel.
Les meilleures équipes n’embauchent pas un type pour toujours. Elles développent des personnes qui peuvent changer de casquette :
- expédier quand la vitesse est essentielle,
- ralentir quand l’intégrité est essentielle,
- et expliquer le compromis en langage clair.
Encadré : Comment les leaders obtiennent plus de pensée ingénieur (sans perdre de vitesse)
Si vous voulez un comportement mode ingénieur, récompensez le comportement axé sur les résultats. Explicitement.
- Célébrez le correctif qui empêche les cinq prochains incidents — pas seulement le patch qui ferme le ticket d’aujourd’hui.
- Suivez les problèmes répétés et réduisez-les (« pourquoi est-ce arrivé encore ? »).
- Rendez le travail de simplification visible (supprimer de la complexité est un progrès).
- Protégez le temps pour la santé du système de la même manière que vous protégez la livraison de fonctionnalités.
- Créez la sécurité pour que quelqu’un puisse dire « cette exigence n’a pas de sens » sans être étiqueté « difficile ».
Pensée finale
Si votre backlog diminue mais que votre produit devient :
- plus difficile à changer,
- plus difficile à tester,
- et plus facile à casser…
vous n’avez pas un problème de productivité.
Vous avez un problème d’incitations.
Les développeurs maintiennent la machine en mouvement.
Les ingénieurs empêchent la machine de devenir un engin fragile et surcompliqué tenu par l’espoir.
Alors — que récompense votre équipe aujourd’hui : des outputs, ou des outcomes ?
TIC Insights | Perspectives pour les dirigeants naviguant dans la technologie, l’innovation et le changement.