Idée principale

Ce qu'un concurrent publie — un module, un écran, une intégration, un agent IA — est la sortie d'un raisonnement qui, lui, ne sort pas : quel client il visait, quel outcome il cherchait à produire, contre quelle alternative il se battait, quelle contrainte interne l'a conduit à cette forme-là plutôt qu'à une autre.

Le relevé de fonctionnalités collecte donc la partie du travail qui ne porte pas l'information. Deux produits peuvent adresser le même besoin par des réponses très différentes, et deux réponses identiques peuvent venir de raisonnements opposés. Reproduire la réponse sans avoir reconstitué le raisonnement ne reconduit rien de ce qui la rendait juste : c'est reproduire un geste.

Pourquoi c'est important

Cela explique pourquoi la copie échoue sans qu'on puisse l'attribuer à une mauvaise exécution. La fonctionnalité copiée fonctionne, elle est livrée, et elle ne produit pas l'effet observé chez l'autre — parce que l'effet tenait au client visé et à l'alternative combattue, pas à la forme.

Cela donne aussi la bonne question à poser devant une sortie concurrente : non pas « que faut-il rattraper ? » mais « quel problème cela cherche-t-il à résoudre, quel gain est promis, quelle friction est supprimée ? » — une question à laquelle on peut répondre sans copier.

Nuances et limites

Le raisonnement n'est pas toujours reconstituable, et il n'est pas toujours profond : une fonctionnalité concurrente peut être le résultat d'une demande d'un gros client, d'une opportunité technique ou d'un arbitrage de calendrier. Prêter systématiquement une intention stratégique à ce qu'on observe est l'erreur symétrique de la copie.

Et certaines réponses sont devenues des attendus de marché : les reproduire n'est alors pas une stratégie, mais une condition d'entrée, ce qui est une décision différente et légitime.

Questions ouvertes

• À quoi reconnaît-on qu'un raisonnement reconstitué depuis l'extérieur est plausible, plutôt que projeté par celui qui l'observe ?