L'appel qui m'a fait dire non
Un directeur opérations m'a appelé l'année dernière. « Combien de développeurs vous pouvez mettre sur ce projet pendant six mois ? » J'ai répondu : « On ne vend pas des mois-développeur. On livre des produits qui marchent. » Silence. Il a presque raccroché.
Six semaines plus tard, il a signé. Pas parce qu'on l'avait convaincu. Parce qu'il avait essayé deux autres prestataires entre-temps et que les deux lui avaient renvoyé des devis au temps passé sans questionner son périmètre. Il avait compris la différence.
C'est cette différence que j'ai envie d'expliquer ici. Parce que quand on l'a vue une fois, on ne la confond plus jamais.
Les deux modèles
Il y a deux manières de livrer un produit. Elles se ressemblent à l'extérieur. Elles sont opposées à l'intérieur.
La première s'appelle souvent agence, ou ESN, ou prestataire. Le contrat porte sur du temps. Vous donnez un cahier des charges, ils chiffrent en jours-homme. Si le cahier des charges est mauvais, ils livrent un produit mauvais, et ce n'est techniquement pas leur problème.
La seconde s'appelle un partenaire produit. Le contrat porte sur un résultat. On challenge votre cahier des charges parce que c'est notre rôle. Si le périmètre vous mène dans le mur, on vous le dit avant de signer, pas après livraison.
Le coût horaire des deux peut être identique. Le résultat sur six mois ne l'est jamais.
Ce qu'un partenaire produit fait que l'agence ne fait pas
Quatre choses concrètes :
- On dit non. Un partenaire produit refuse régulièrement des fonctionnalités demandées. Pas par caprice. Parce qu'on a vu vingt fois ce qu'elles font à un produit. Une agence dit oui, c'est facturable.
- On regarde les chiffres. On veut voir vos analytics, vos taux de conversion, vos retours utilisateurs. Pas pour faire joli, pour décider quoi construire ensuite. Une agence n'en demande pas l'accès, ce n'est pas dans le périmètre.
- On reste après le lancement. Le lancement n'est pas la fin. C'est le moment où on apprend si on a eu raison. Une agence livre, facture, part. Un partenaire reste pour les itérations qui transforment un produit moyen en produit utilisé.
- On partage des standards. Conventions de code, processus de revue, observabilité, sécurité. Quand on quitte un projet, votre équipe peut continuer sans nous parce qu'on a transmis ces standards. C'est l'inverse du modèle qui crée du verrouillage.
Le moment où on dit non
Un fondateur SaaS nous a demandé l'année dernière d'ajouter un module de chat in-app. « Tous nos concurrents l'ont. » On a regardé son taux d'adoption sur la fonctionnalité actuelle qu'il sous-utilisait : 12 %. On lui a dit : avant d'ajouter une nouvelle fonctionnalité, on double l'adoption de celle qui existe déjà.
Il n'aimait pas la réponse. Il s'attendait à un devis. Trois mois plus tard, l'adoption est passée à 38 % avec deux semaines de travail ciblé sur l'onboarding. Le module de chat n'est jamais arrivé. Il n'en a plus besoin.
C'est ça, dire non au bon moment.
Chirurgie ou table rase
Quand on hérite d'un produit existant, le réflexe junior est de tout réécrire. C'est plus excitant, plus propre techniquement, et c'est presque toujours une mauvaise décision.
Un produit en production, même mal codé, contient une chose qu'aucun nouveau code n'a : la connaissance des cas réels que vos utilisateurs vivent. Chaque ligne bizarre est souvent un patch pour un cas que vous avez oublié.
Notre approche par défaut, c'est la chirurgie : on identifie les trois ou quatre points qui font vraiment mal (performance, dette technique critique, modules qui bloquent les évolutions) et on les corrige sans toucher au reste. Six semaines au lieu de six mois. Risque divisé par dix.
Une agence livre ce que vous avez demandé. Un partenaire vous aide à demander ce qu'il faut.
Comment on partage la propriété
L'ownership partagé n'est pas un mot à la mode. C'est une pratique opérationnelle. Concrètement, sur chaque projet :
- Vous avez accès au code dès la première ligne. Pas à la livraison, dès le premier commit.
- Vos décideurs assistent à la rétro de fin de sprint. Pas pour valider, pour voir ce qu'on apprend.
- Les arbitrages techniques importants sont écrits et partagés. Pas dans un PowerPoint. Dans le repo, à côté du code.
- Quand on quitte le projet, on laisse une équipe interne ou un nouveau partenaire capable de continuer. C'est testable.
Le test simple
Si vous voulez savoir si votre prestataire est une agence ou un partenaire produit, posez une question :
Le lundi matin, qui chez vous pense à mon business ?
Une agence vous donnera le nom d'un chef de projet qui pense à votre planning. Un partenaire produit vous donnera le nom de la personne qui a relu vos derniers chiffres et qui a une idée à vous soumettre.
Les deux sont utiles. Ils ne coûtent pas la même chose. Ils ne livrent pas la même chose.
Si vous hésitez
Le bon moyen de savoir avec qui vous travaillez, c'est de leur faire passer le test sur un petit périmètre avant de signer le grand contrat. Une revue produit de trente minutes suffit pour voir comment on raisonne, ce qu'on challenge, et si on vous dit non quand il faut.