Gouvernance produit : pourquoi un CTO refuse la majorité des features

Sur dix demandes de fonctionnalités qui arrivent sur le bureau d'un directeur technique, deux ou trois seront construites. Les autres seront refusées, reportées, ou transformées en quelque chose de beaucoup plus petit. Vu de l'extérieur, cela ressemble à de l'obstruction. Vu de l'intérieur, c'est la seule chose qui empêche un produit de devenir inutilisable et une équipe de devenir inefficace.

Chaque fonctionnalité ajoutée est un engagement permanent : elle doit être maintenue, testée, documentée, migrée, sécurisée et supportée. On ne construit pas une fonctionnalité, on l'adopte.

Le vrai coût d'une fonctionnalité

Le coût visible est le développement. Le coût réel comprend :

• La maintenance, estimée entre 15 % et 25 % du coût initial chaque année.
• La charge cognitive : chaque option supplémentaire complique l'interface pour tous les utilisateurs, y compris ceux qui ne l'utiliseront jamais.
• Le couplage : une fonctionnalité mal placée rend les cinq suivantes plus lentes à construire.
• La surface d'exposition : plus de code, plus de dépendances, plus de risques de sécurité.
• Le support : une fonctionnalité peu utilisée mais mal comprise génère un volume disproportionné de sollicitations.

Un produit meurt rarement d'un manque de fonctionnalités. Il meurt régulièrement de leur accumulation.

Une grille de décision : impact, risque, dette

Pour chaque demande, trois questions posées dans le même ordre, systématiquement.

1. Impact. Qui en a besoin, combien de fois par mois, et que fait cette personne aujourd'hui à la place ? Si la réponse est « un client l'a demandé une fois », l'impact est nul jusqu'à preuve du contraire. Si la réponse est « 40 % des utilisateurs contournent le problème avec un tableur », l'impact est majeur.

2. Risque. Que se passe-t-il si on ne le fait pas ? Perte d'un client, blocage réglementaire, avantage concurrentiel perdu — ou simplement rien. Le risque de ne rien faire est presque toujours surestimé dans les réunions et sous-documenté dans les décisions.

3. Dette. Qu'est-ce que cela nous engage à maintenir pendant cinq ans ? Une fonctionnalité qui s'intègre au modèle existant coûte peu ; une fonctionnalité qui introduit un cas particulier structurel coûte pour toujours.

Une demande qui ne passe pas les trois filtres reçoit un non — un non écrit, motivé et daté, pas un silence.

Le « non » comme protection, pas comme posture

Refuser n'a de valeur que si le refus protège quelque chose d'identifiable : la vitesse de livraison, la clarté du produit, la fiabilité, la capacité de l'équipe à tenir ses engagements. Un CTO qui refuse par confort, par lassitude ou pour éviter le travail détruit la confiance aussi sûrement qu'un CTO qui accepte tout.

Trois règles rendent le refus acceptable :

• Toujours nommer ce qui est protégé. « Non, parce que cela repousserait la refonte du parcours de paiement de trois semaines. »
• Toujours proposer une alternative. Une version manuelle, un contournement, une version réduite à 20 % du périmètre qui couvre 80 % du besoin.
• Toujours dater le réexamen. « On regarde à nouveau au prochain trimestre, avec les chiffres d'usage. »

La priorisation doit être collective, la décision non

La meilleure gouvernance produit que nous observons repose sur un rituel simple : un comité produit toutes les deux semaines, réunissant direction, produit, technique et une voix du terrain (support ou commerce). Chaque demande y est présentée en cinq minutes, notée sur la grille impact / risque / dette, et tranchée dans la séance.

L'instruction est collective ; la décision finale appartient à une personne clairement désignée. Un comité qui décide à l'unanimité ne décide pas : il ajoute des fonctionnalités jusqu'à ce que tout le monde soit satisfait, ce qui est la définition exacte d'un produit sans direction.

Le registre des refus : l'outil le plus sous-estimé

Tenez la liste de ce que vous avez refusé, avec la date, la raison et le nom du demandeur. Cette liste a trois vertus.

1. Elle évite de rejouer les mêmes débats tous les trois mois.
2. Elle révèle les signaux faibles : quand la même demande revient de cinq clients différents, ce n'est plus une demande, c'est un besoin marché.
3. Elle protège l'équipe : chacun voit que les refus obéissent à une règle, pas à une humeur.

Cette discipline de gouvernance fait partie de ce que nous installons dans nos missions de CTO à temps partagé : un cadre de décision que l'entreprise garde après notre départ.

FAQ

Que faire quand un client important exige une fonctionnalité spécifique ?

Distinguer le besoin de la solution demandée. Dans la majorité des cas, le besoin réel peut être couvert par une capacité générique utile à tous vos clients, plutôt que par un cas particulier qui vous engage seul. Si la demande reste très spécifique et que le client la finance, elle doit être traitée comme du sur-mesure, avec un coût de maintenance facturé et une réversibilité prévue.

Comment savoir si on refuse trop ?

Regardez la proportion de demandes refusées qui reviennent dans les six mois : si elle dépasse un tiers, votre grille de priorisation manque quelque chose. Regardez aussi le délai entre l'identification d'un besoin réel et sa mise en production — s'il dépasse deux trimestres, le problème n'est pas le refus, c'est la capacité de livraison.

Qui doit trancher entre le produit et la technique ?

La décision produit revient au responsable produit ou au dirigeant ; le directeur technique fournit le coût, le risque et les alternatives, et pose un veto uniquement sur les sujets de sécurité, de conformité ou de faisabilité. Cette séparation évite le double écueil d'une technique qui décide de la valeur métier et d'un produit qui décide de l'architecture.