Pourquoi le code finit par décider de votre produit à votre place

Le code avance, la conception fonctionnelle non

Une équipe prépare la refonte d'un back-office métier complexe, facturation, processus imbriqués, scénarios non nominaux nombreux. Le développement backend a déjà commencé. La conception fonctionnelle, elle, n'est pas stabilisée : les flux cibles restent en discussion, certains arbitrages de périmètre n'ont pas été tranchés. Le risque est précis et prévisible : au prochain arbitrage, un développeur répond que le sujet a déjà été pensé, que le système va fonctionner d'une certaine façon, parce que c'est comme ça que le code a été écrit.

Cette réponse n'est presque jamais de la mauvaise volonté. C'est la conséquence logique d'une situation où personne n'a explicitement dit qui tranche quoi. Le développeur avance sur ce qui lui semble raisonnable, parce qu'il faut bien avancer. Le résultat : un back-office pensé pour la cohérence du code, pas pour l'expérience des utilisateurs qui vont s'en servir chaque jour.

Ce schéma se joue rarement en une seule fois, de façon visible. Il s'installe décision après décision, chacune minime prise isolément : un champ qu'on rend obligatoire parce que c'est plus simple à valider côté code, un écran qu'on découpe en deux parce que ça évite une requête supplémentaire, un intitulé technique qui remonte tel quel dans l'interface parce que personne n'a pris le temps de le traduire en langage métier. Prise seule, chacune de ces décisions semble anodine. Mises bout à bout sur plusieurs mois de développement, elles dessinent un produit que personne n'a choisi, construit par accumulation plutôt que par intention.

Pourquoi ce n'est pas un problème de compétence technique

Un développeur junior qui impose des choix de conception ne révèle presque jamais un problème de compétence, il révèle un vide de leadership produit que personne n'a comblé. Sur un projet de refonte d'outil interne, un développeur tout juste sorti d'école a pris, de fait, les décisions d'expérience utilisateur et d'architecture fonctionnelle, en mode résolution de problèmes techniques immédiats : comment coder ça le plus vite, plutôt que de quoi l'utilisateur a réellement besoin. Le dirigeant du client, pourtant expert de son métier, n'a pas recadré et a laissé l'équipe technique dicter l'expérience produit par accumulation de petites décisions locales.

Optimisation locale contre vision d'ensemble

Chaque décision prise dans ce mode se justifie isolément : c'est la solution la plus rapide à coder compte tenu de ce qui existe déjà. Mais une somme de décisions techniquement raisonnables, prises sans vision d'ensemble, produit un outil qui empile des réponses ponctuelles plutôt qu'une colonne vertébrale cohérente. Le prestataire censé challenger cette dérive se retrouve court-circuité, non par malveillance, mais parce que la question du fonctionnel n'est jamais revenue sur la table une fois le code lancé.

Le coût de ce vide ne se révèle presque jamais immédiatement. Il apparaît plus tard, sous la forme d'un outil que les utilisateurs contournent discrètement, de fonctionnalités qui se chevauchent sans qu'on sache laquelle est la référence, ou d'une demande d'évolution qui oblige à défaire plusieurs mois de développement parce que la direction prise dès le début ne correspondait à aucune décision métier assumée. La dette technique n'est alors qu'un symptôme : la vraie cause est l'absence d'un arbitre identifié sur ce que le produit devait faire.

Le quoi, pas le comment : le principe

Chez Leando, ce principe s'appelle le quoi, pas le comment : séparer explicitement la responsabilité de ce que le produit doit faire pour l'utilisateur de la façon de l'implémenter techniquement, et verrouiller le premier avant que le second ne le fige par défaut. Sur le projet de back-office évoqué plus haut, l'équipe a posé un principe directeur explicite, validé avec le commanditaire : les décisions se prennent par rapport à ce que le métier doit pouvoir faire, jamais par rapport à ce qui est déjà codé. La phase de conception fonctionnelle a été volontairement accélérée, cartographie exhaustive des processus existants, validation des flux cibles, pour arriver à des spécifications non négociables sur le plan fonctionnel. Le développeur garde l'entière responsabilité de la codebase. Il ne garde pas celle du produit.

Cette distinction n'oppose jamais le métier et la technique, elle les met chacun à la place où ils sont le plus utiles. Le métier connaît les cas d'usage, les exceptions réelles, ce que l'utilisateur attend au quotidien : c'est à lui de dire ce qui doit se passer. La technique connaît les contraintes d'implémentation, les compromis de performance, la dette que telle approche créerait : c'est à elle de dire comment y arriver. Le problème n'apparaît que lorsque l'une des deux parties répond à la place de l'autre, faute d'un arbitre identifié pour les départager.

« Non mais en fait ça, on y a déjà pensé, on va faire comme ça, parce qu'on a fait ça comme ça dans le code. »

Ce que ça change concrètement dans l'avancement d'un projet

Une fois cette frontière posée, un message de gel de périmètre peut être envoyé sans bloquer le projet : certaines zones de développement restent suspendues tant que les décisions fonctionnelles ne sont pas arrêtées, pendant que d'autres, déjà cadrées, avancent normalement. Ce séquencement rejoint directement la logique développée dans notre article sur le rôle de garde-fou face à la pression d'aller vite dans le code : ralentir localement le développement sur un périmètre encore instable n'est pas un frein au projet, c'est ce qui évite de devoir défaire, en production, des décisions prises par défaut.

À quoi ressemble une spécification non négociable

Concrètement, une spécification fonctionnelle verrouillée n'est pas un document de cinquante pages figé pour toute la durée du projet. C'est un nombre restreint de règles écrites noir sur blanc, validées par la personne qui porte la responsabilité métier, et dont la reformulation exige un nouvel arbitrage explicite plutôt qu'une interprétation silencieuse en cours de développement : la liste des statuts qu'un dossier peut prendre, l'ordre dans lequel certaines étapes doivent obligatoirement s'enchaîner, ou le périmètre exact des utilisateurs autorisés à déclencher une action sensible. Tout le reste, la façon dont ces règles sont codées, reste entièrement à la main de l'équipe technique.

Cette séparation des responsabilités rejoint aussi, à une échelle différente, le principe qui consiste à confier à une même personne le pilotage du SI et des méthodes métier : dans les deux cas, il s'agit de nommer explicitement qui arbitre, plutôt que de laisser l'arbitrage se faire par défaut, au fil des décisions techniques quotidiennes.

Ce que ce principe exclut, et où il s'arrête

Ce principe ne s'applique pas à toute décision prise sur un projet. Il vise spécifiquement les choix qui changent l'expérience de l'utilisateur final ou une règle métier, pas les arbitrages purement techniques où laisser la main à l'équipe de développement reste la bonne décision : le nommage d'une variable, la structure interne d'un service, le choix d'une librairie n'ont pas besoin d'un arbitrage fonctionnel. L'appliquer partout transformerait un principe de clarté en lourdeur bureaucratique, et pousserait les équipes à le contourner plutôt qu'à le suivre.

Le principe exclut également de traiter chaque avis technique comme une tentative de contourner le métier. Un développeur qui signale qu'une solution demandée coûtera trois fois plus cher à maintenir qu'une alternative proche apporte une information précieuse, pas une résistance à écarter. La différence tient à qui tranche ensuite : une fois la contrainte posée sur la table, c'est au porteur de la responsabilité fonctionnelle de décider si le coût supplémentaire se justifie, pas au développeur de trancher seul parce que personne d'autre n'était dans la pièce.

Ce principe suppose aussi qu'une personne soit identifiée pour porter cette responsabilité fonctionnelle. Sur un projet où le rôle de traduction entre métier et technique reste à construire, poser d'abord cette fonction importe davantage que d'en verrouiller le contenu : notre article sur le pont entre métier et technique détaille comment installer cette fonction de traduction avant même de chercher à verrouiller quoi que ce soit.

Le test à faire avant votre prochain arbitrage

Avant de lancer le développement d'une fonctionnalité qui touche à l'expérience de vos utilisateurs, posez une question simple : si un développeur revenait demain en disant qu'une contrainte technique impose telle solution plutôt qu'une autre, qui, précisément, a le mandat de trancher si cette solution reste acceptable pour le métier ? Si vous ne trouvez pas de nom pour répondre à cette question, c'est que le code répondra à votre place, sans jamais vous demander votre avis.

Ce test coûte moins de cinq minutes et peut se faire en réunion de lancement, avant la première ligne de code. Il révèle immédiatement si votre projet a un porteur fonctionnel identifié ou si cette responsabilité reste, de fait, vacante. Dans le second cas, la corriger maintenant coûte infiniment moins cher que de découvrir, plusieurs mois plus tard, que des dizaines de petites décisions ont construit un produit que personne, côté métier, n'a vraiment choisi.