Un seul responsable, de l'idée au logiciel qui tourne

Qu'est-ce qu'une approche « orientée produit » concrètement ?

Un développeur exécute une spécification. Un builder orienté produit remonte à la question d'avant : pourquoi ce logiciel existe-t-il ? Avant d'ouvrir l'éditeur, je cherche le problème métier réel, l'utilisateur qui souffre, la valeur à créer.

Concrètement, cela change trois choses :

• Le tri des fonctionnalités. Ce qui n'améliore pas l'expérience ou le résultat business ne mérite pas d'être construit.

• Le choix des outils. Je prends ceux qui font le travail, pas ceux qui sont à la mode.

• La mesure. Un logiciel qui tourne, ce n'est pas un logiciel livré — c'est un logiciel qui produit l'effet attendu en production.

C'est cette logique qui a guidé la plateforme SaaS Guetteur pour un industriel HSE : partir du besoin terrain, pas du catalogue technique.

Pourquoi confier idée, architecture et code à une seule personne ?

Parce que la perte d'information se produit à chaque passage de main. Le chef de projet interprète le besoin, l'architecte interprète le chef de projet, le développeur interprète l'architecte. À l'arrivée, le produit ressemble rarement à l'intention de départ.

Quand la même personne tient toute la chaîne, cette déperdition disparaît :

• La décision d'architecture est prise par celui qui écrira le code — donc réaliste, jamais théorique.

• Le contexte métier ne se dilue pas dans une chaîne de transmission.

• Il n'y a qu'un seul responsable à qui parler, de la stratégie à la mise en production.

C'est exactement la trajectoire décrite dans l'étude de cas Upply : de l'architecture au code, un seul responsable.

Comment choisir les bons outils sans céder à la mode ?

Mon critère est simple : est-ce que cet outil résout le problème plus vite, plus sûrement, plus durablement ? Le reste est du bruit.

• Symfony depuis 2013, parce que c'est solide, mature et maintenable sur la durée.

• Vue.js ou AstroJS, parce que la productivité côté interface se traduit en délais tenus.

• Supabase, parce que cela accélère la mise sur le marché sans sacrifier la robustesse.

• L'IA générative, parce qu'elle multiplie ma productivité sur les tâches répétitives — sans remplacer le jugement.

La meilleure architecture n'est pas la plus impressionnante : c'est celle qui s'adapte aux besoins de l'entreprise, pas l'inverse. Ce principe structure ma prestation d'architecture logicielle.

Quand cette approche fait-elle vraiment la différence ?

Elle est décisive dans les contextes où le problème métier est complexe et où l'erreur d'interprétation coûte cher :

• Un produit à construire de zéro, où chaque décision précoce engage la suite — comme la plateforme de mise en relation Infreelancing.

• Un existant à stabiliser, où il faut comprendre le code avant de le toucher, comme sur FashionNetwork.com : framework legacy stabilisé, dette technique maîtrisée.

• Une organisation qui doit avancer vite, sans multiplier les intermédiaires ni diluer la responsabilité.

Diriger l'ingénierie dans des environnements exigeants — RueDuCommerce, Meetic, AramisAuto, des sociétés du groupe Nestlé — m'a appris une chose : la valeur ne vient pas du nombre de personnes autour de la table, mais de la clarté de la responsabilité.