Idée principale

Chaque outil vertical embarque désormais ses propres agents, et ils sont bons : Zendesk sur la documentation de support, Figma sur la conception d'écrans. Cette montée en puissance est réelle, mais elle ne referme pas l'écart, parce que la limite n'est pas dans la qualité de l'agent — elle est dans le périmètre de données auquel il a accès.

Ce qui permet de produire un artefact juste n'est pas une source, c'est le croisement de plusieurs : le code source, l'historique des évolutions, les merge requests, et les règles métier accumulées par le Product Manager au fil des échanges avec les clients. Zendesk ne connaît pas les merge requests. Figma ne connaît pas les règles métier. Chacun voit sa face et produit une sortie cohérente avec elle.

La conséquence pratique : le croisement est aujourd'hui tenu par une personne, pas par un outil. Et c'est ce croisement qui permet non seulement de générer un document, mais de challenger ce qui existe déjà — un agent enfermé dans un périmètre n'a rien contre quoi confronter ce qu'il lit.

Pourquoi c'est important

Cela répond à l'objection la plus fréquente à toute compétence d'assemblage : « les SaaS feront ça tout seuls ». Ils feront mieux chacun dans leur couloir ; la position qui consiste à voir plusieurs couloirs à la fois n'est pas celle qu'ils occupent.

Cela indique aussi où chercher la valeur quand on outille un travail produit : pas dans le meilleur outil par tâche, mais dans les jonctions que personne ne couvre.

Nuances et limites

La limite est un état, pas une loi. Un protocole d'échange de contexte entre agents peut donner à chaque outil l'accès aux autres périmètres, et l'argument perd alors sa force — il tient tant que les périmètres restent étanches.

Et un croisement tenu par une personne a ses propres défauts : il n'est ni documenté, ni reproductible, ni transmissible.

Questions ouvertes

• Ce croisement peut-il être formalisé, ou tient-il précisément à ce qui n'est écrit nulle part ?