Angle
« Que se passe-t-il si le client annule cet élément après validation ? » — la question tombe sur Slack, la page de support ne couvre pas le cas, et un Product Manager ouvre un environnement de test pour une demi-heure. Aller chercher la réponse dans le dépôt plutôt que dans la page ne fait que supprimer cette demi-heure : une réponse tirée du code se trompe aussi bien qu'une documentation périmée, et avec plus d'aplomb. Ce qui réduit réellement le risque n'est pas le changement de source, c'est le régime imposé à la réponse — chaque affirmation rattachée à un élément désignable, la fonction qui applique la règle, le test qui couvre le scénario, la merge request qui a introduit le comportement, l'état du feature flag ; et chaque zone non établie nommée, le test qui manque, la configuration de ce client-là qu'on n'atteint pas, la décision produit que le code semble contredire. Sans ce double régime, on remplace la mémoire imparfaite du Product Manager par la mémoire probabiliste d'un modèle, et le risque ne diminue pas : il change de porteur, passant de celui qui savait qu'il ne savait pas à l'agent de support qui croit savoir.
Synthèse
Le raisonnement part d'un coût que personne ne compte, et ce point d'entrée n'est pas anodin : il explique que l'on ait vécu si longtemps avec la situation. Chaque vérification prend une demi-heure et n'apparaît dans aucun ticket, aucune estimation, aucune ligne de roadmap. Un second coût s'y ajoute, encore moins visible, et il ne se réduit pas par les mêmes moyens : l'interruption détruit l'état de travail de celui qu'elle atteint, et une réponse obtenue en deux minutes au lieu de trente la laisse intacte.
Le déplacement vers le code est présenté comme une réponse à ce coût, et il en est une — à condition de ne pas le prendre pour une réponse au problème de fiabilité, qui est un autre problème. Le dépôt est la seule représentation qui ne diverge pas de ce que le produit fait ; mais il ne dit pas tout ce qu'un document disait. La coupure utile ne passe pas entre le code et la documentation, elle passe entre ce qui décrit — régénérable — et ce qui explique — à conserver, parce qu'aucune lecture du dépôt ne le reconstitue. Et le dépôt lui-même ne suffit pas à trancher : un feature flag y laisse deux comportements possibles, et c'est la configuration déployée qui décide lequel s'applique à un client.
C'est ici que le régime de réponse devient le vrai sujet. Deux exigences symétriques, et aucune ne remplace l'autre : citer borne ce qui est affirmé, avouer borne ce qui ne l'est pas. La première agit au moment où la réponse se produit, non au moment où on la relit — c'est ce qui la distingue d'une exigence de traçabilité, qui suppose un lecteur. La seconde donne une valeur à ce qui ressemble à un échec : signaler qu'aucun test ne couvre un cas, ou qu'une décision produit et le code divergent, est une information produit en soi.
Reste la question de savoir à qui tout cela profite, et elle se règle par la forme plutôt que par la duplication : une réponse unique découpée en angles — la réponse courte, l'usage, la valeur, les limites, les preuves — évite de maintenir cohérentes autant de versions que de métiers, et donne aux preuves un endroit où exister sans encombrer ceux qui ne les ouvriront pas.
Enfin, deux conditions bordent l'ensemble, et elles ne relèvent pas du dispositif. La première tient à la matière lue : un code dont les exceptions portent le vocabulaire du domaine se laisse interroger, un code où les règles sont dispersées derrière des noms techniques résiste — à un modèle comme à un développeur. La seconde tient au tri en amont : toutes les questions produit ne sont pas des lectures. Celles qui demandent un arbitrage ne se délèguent à rien, quel que soit l'outillage.
Ce que l'ensemble donne à voir : changer de source de vérité règle un problème d'accès, pas un problème de confiance. La confiance ne se gagne pas sur l'origine de la réponse, elle se gagne sur ce que la réponse s'oblige à montrer — et le même régime vaudrait pour une réponse tirée d'un corpus juridique ou d'un ensemble de comptes rendus.
Tensions / contradictions
Deux exigences de ce lot se contrarient sur un seuil que rien n'établit. Une réponse doit nommer ce qu'elle ne sait pas ; une réponse assortie de réserves à chaque phrase redevient inexploitable, et son lecteur retourne ouvrir un environnement de test — le coût qu'on voulait supprimer revient entier. Le point d'équilibre est décrit comme nécessaire et jamais situé.
Seconde tension, sur ce que le dispositif traite réellement. Il attaque le temps de recherche ; le coût dominant, pour un rôle dont le travail est cumulatif, est celui de l'interruption. Répondre plus vite peut donc améliorer un chiffre sans rien changer à ce qui se perd, et l'article ne dit pas comment la question cesserait d'arriver.
Troisième tension, avec la façon dont le déplacement vers le code a été raconté ailleurs : le passage de l'autorité de la spécification au dépôt y est expliqué par l'effondrement du coût d'accès. Ici, l'accès est acquis et se révèle insuffisant. Les deux tiennent ensemble, mais l'ordre des priorités s'inverse selon celle qu'on lit en premier.
Enfin, le terme même de source de vérité résiste au lot : le dépôt fait foi sur les règles, l'environnement déployé fait foi sur ce qu'un client donné voit, et l'historique fait foi sur l'intention. Trois sources, chacune souveraine sur une question — ce que le singulier de l'expression ne dit pas.
Questions
- Qu'est-ce qui, dans une organisation, vérifie que les preuves citées établissent bien ce que la réponse leur fait dire, et à quel rythme ?
- Comment une entreprise qui juge ses réponses sur leur netteté accueille-t-elle un dispositif dont une partie du livrable est l'aveu d'un trou ?
- À quelles conditions un trou signalé — un test absent, une décision produit que le code contredit — devient-il un travail engagé plutôt qu'une mention de plus au bas des réponses ?
- Que devient ce régime quand le comportement interrogé ne tient plus à un dépôt lisible mais à un modèle entraîné, dont aucune fonction ne porte la règle ?