Vous cherchez des développeurs. Il vous faut une équipe produit.

Personne ne demande à un maçon de construire sa maison.

On ne l'appelle pas en disant « voilà un terrain, voilà un budget, faites-moi une maison ». On sait, intuitivement, que ça n'a aucun sens. Le maçon monte des murs. Il ne décide pas où placer la cuisine, comment orienter le salon pour la lumière du matin, ni comment faire tenir l'ensemble dans le budget sans sacrifier ce qui compte. Pour ça, il faut un architecte, un maître d'œuvre, quelqu'un qui pense la maison avant qu'on pose la première pierre.

Et pourtant, quand il s'agit de construire le système digital qui va faire tourner leur entreprise, la plupart des dirigeants appellent le maçon.

Ils cherchent « des développeurs ». Ils demandent « qui peut me coder ça ». Ils comparent des tarifs journaliers. Et six mois plus tard, ils se retrouvent avec des murs bien droits — un logiciel qui fonctionne techniquement — mais une maison dans laquelle personne ne veut vivre.

Deux mots qu'on confond en permanence

Derrière ce malentendu, il y a une confusion de fond entre deux façons de travailler radicalement différentes : le mode projet et le mode produit.

En mode projet, on part d'une spécification. Quelqu'un a décidé quoi construire, l'a écrit dans un cahier des charges, et on exécute. Le succès se mesure au respect du périmètre, du budget et des délais. On livre. On s'en va. Le projet est « fini ».

En mode produit, on part d'un problème. On ne sait pas encore exactement ce qu'il faut construire — on le découvre en avançant, au contact des utilisateurs réels. Le succès ne se mesure pas à la conformité au cahier des charges, mais à l'usage. Est-ce que ça résout vraiment le problème ? Est-ce que les équipes l'adoptent ? Est-ce que ça crée de la valeur, mois après mois ?

Le mode projet demande « avons-nous livré ce qui était prévu ? ». Le mode produit demande « avons-nous construit ce qui était utile ? ». Ce n'est pas la même question. Et ça ne demande pas la même équipe.

La nuance a l'air théorique. Elle est brutalement concrète. Parce que le cahier des charges que vous avez rédigé au début se trompe presque toujours. Pas par incompétence — parce que personne ne sait exactement ce dont il a besoin avant de l'avoir vu tourner. Le besoin se révèle en marchant. Une équipe en mode projet suivra le plan jusqu'au bout, même quand le plan est devenu faux. Une équipe en mode produit s'arrêtera pour vous dire : « ce qu'on est en train de construire ne servira à personne, changeons de direction tant que c'est possible. »

L'équipe technique sait construire. L'équipe produit sait quoi construire.

Une équipe technique, c'est des gens qui savent coder. Et c'est indispensable — sans eux, rien n'existe. Mais coder n'a jamais été le point difficile. Le point difficile, c'est de savoir quoi coder, dans quel ordre, pour quel usage, et surtout quand s'arrêter.

Une équipe produit, c'est autre chose. C'est un ensemble de rôles qui pensent le système avant, pendant et après la construction :

Le product manager garde le lien avec le problème métier. Il tranche les priorités, dit non aux fausses bonnes idées, protège le projet de l'empilement de fonctionnalités que personne n'utilisera. Le designer conçoit la manière dont on va vraiment se servir de l'outil — pas l'écran joli, l'usage réel, celui du lundi matin sous pression. Le tech lead fait des choix d'architecture qui détermineront ce qui sera possible ou impossible dans trois ans. Et les développeurs construisent — vite, bien, mais surtout au service d'une intention claire.

Enlevez les trois premiers rôles et gardez seulement les développeurs : vous avez le maçon. Il montera exactement les murs que vous lui avez dessinés. Y compris les murs au mauvais endroit.

Un développeur exécute une décision. Une équipe produit prend la décision, puis l'exécute. La différence de prix entre les deux est faible. La différence de résultat est un gouffre.

La squad : le maître d'œuvre de votre système

Cette manière de travailler porte un nom dans les entreprises qui construisent les meilleurs produits du monde : la squad.

Spotify a popularisé le modèle. Plutôt que d'organiser ses équipes par métier — les développeurs d'un côté, les designers de l'autre, les chefs de projet ailleurs — l'entreprise a créé des squads : des unités petites, autonomes, pluridisciplinaires, chacune responsable d'un bout du produit de bout en bout. Un product manager, un designer, des développeurs, réunis autour d'un problème et non d'une tâche. Une squad ne « rend » pas un livrable à un autre service. Elle possède un morceau du système et en répond entièrement.

Ce n'est pas une mode d'organisation. C'est la traduction concrète du mode produit. Une squad, c'est le maître d'œuvre et son équipe réunis autour de la table : quelqu'un qui pense la maison, quelqu'un qui pense comment on y vivra, et ceux qui la construisent — tous engagés sur le même résultat, pas sur des périmètres séparés.

Et c'est précisément ce qui manque quand on recrute « des développeurs » ou qu'on sous-traite « du dev ». On achète des bras. On n'achète pas une tête qui pense le système à votre place quand vous n'avez pas le temps de le faire.

Le coût caché du mode projet

Le mode projet a l'air moins cher. C'est son piège. Sur le devis, une équipe qui exécute un cahier des charges coûte moins qu'une équipe qui pense le produit. Le tarif journalier est plus bas. Le périmètre est « clair ». On croit acheter la même chose en moins cher.

Sauf qu'on n'achète pas la même chose.

Ce que le mode projet vous fait payer, vous ne le voyez pas au mois 1. Vous le payez au mois 8, quand le système est livré « conforme » mais que vos équipes continuent de contourner ses limites à coups d'Excel. Vous le payez quand chaque évolution redevient un nouveau projet à cadrer, à chiffrer, à négocier — parce que personne n'a pensé le système pour vivre et grandir. Vous le payez quand vous réalisez que la connaissance de votre produit est partie avec le prestataire, parce qu'il a livré du code, pas une compréhension.

Un système construit en mode projet est un livrable. Un système construit en mode produit est un actif. Le premier est figé le jour de sa livraison. Le second continue de créer de la valeur, parce qu'il a été pensé pour épouser un métier qui évolue — et parce qu'une équipe a compris ce métier assez profondément pour le faire évoluer avec vous.

C'est exactement là que se joue la souveraineté. Posséder son système, ce n'est pas seulement en détenir le code source. C'est détenir la capacité de le faire évoluer, de comprendre pourquoi il est construit comme ça, de ne pas dépendre à vie de celui qui a monté les murs. Le mode projet vous laisse propriétaire de murs que vous ne comprenez pas. Le mode produit vous rend architecte de votre propre système.

« Et si l'IA code à ma place ? »

Depuis un an, une objection nouvelle s'invite dans chaque conversation avec un dirigeant : « Tout ça, c'était vrai avant. Mais aujourd'hui l'IA code toute seule. Le vibe coding change la donne, non ? »

Oui. Et c'est précisément ce qui rend cet argument plus vrai que jamais.

Le vibe coding — décrire ce qu'on veut en langage naturel et laisser un agent produire le code — fait s'effondrer le coût de la construction. Concrètement, il donne à tout le monde un maçon gratuit. N'importe qui peut désormais générer une fonctionnalité en quelques minutes, sans écrire une ligne.

Mais regardez ce que ça déplace. Si le maçon devient gratuit, monter des murs ne vaut plus rien. Ce qui prend de la valeur, c'est tout ce que le maçon n'a jamais su faire : décider où placer les murs, dans quel ordre les monter, lesquels ne jamais construire, et comment garantir que l'ensemble tiendra encore debout dans trois ans.

Le vibe coding ne vous donne pas un maître d'œuvre. Il vous donne un maçon infatigable qui construira exactement ce que vous lui demandez — y compris n'importe quoi, à une vitesse record.

C'est là que se cache le vrai danger de cette nouvelle ère. Hier, une mauvaise décision coûtait cher à exécuter, donc on prenait le temps d'y réfléchir. Aujourd'hui, elle s'exécute en un week-end. Le risque n'est plus de sous-construire — c'est de vibe-coder pendant trois mois un empilement de fonctionnalités qui tiennent par miracle, que personne ne comprend, et qu'on ne peut plus faire évoluer sans tout casser. La dette, technique comme produit, se crée plus vite qu'avant, pas moins.

Autrement dit : l'IA a rendu l'exécution triviale et le jugement décisif. Elle n'a pas supprimé le besoin d'une équipe produit. Elle l'a rendu vital. Plus le maçon est puissant, plus il faut quelqu'un pour lui dire quoi construire.

Quand le maçon suffit vraiment

Toute cette démonstration a une limite, et il serait malhonnête de la passer sous silence.

Parfois, vous avez juste besoin d'un maçon. Quand le besoin est parfaitement défini, stable, sans zone d'incertitude — un site vitrine, une intégration simple, une fonctionnalité isolée dont la spécification ne bougera pas — le mode projet est le bon choix. Y appliquer une squad complète serait du gaspillage. On ne mobilise pas un maître d'œuvre pour repeindre un mur.

Le discernement est là : distinguer ce qui relève de l'exécution pure de ce qui relève de la construction d'un système vivant. Pour tout ce qui touche au cœur de votre métier — le système qui encode votre façon de travailler, celle qui fait votre différence — vous n'êtes pas dans l'exécution. Vous êtes dans la conception d'un actif stratégique. Et un actif stratégique ne se confie pas à des bras. Il se confie à une équipe qui pense.

La question à se poser avant de recruter qui que ce soit

La prochaine fois que vous vous apprêtez à « trouver des développeurs » pour construire votre système, arrêtez-vous une seconde. Et posez-vous une seule question.

Est-ce que je cherche quelqu'un pour exécuter une décision que j'ai déjà prise — ou est-ce que je cherche une équipe pour prendre les bonnes décisions à ma place, là où je n'ai ni le temps ni le recul de les prendre ?

Si c'est la première réponse, cherchez un maçon. Ils sont nombreux, compétents, et souvent moins chers.

Mais si c'est la seconde — et pour tout ce qui fait vraiment tourner votre entreprise, c'est presque toujours la seconde — alors vous ne cherchez pas des développeurs. Vous cherchez une équipe produit. Le jour où vous arrêtez de confondre les deux est le jour où votre système digital cesse d'être une dépense pour devenir un avantage.