Idée principale

Face à un outil qu'on veut faire écrire ailleurs — par exemple un assistant de conversation vers un serveur personnel —, la question spontanée est : comment lui faire appeler mon service ? Elle mène à construire une interface, puis à constater qu'elle ne peut pas être appelée, puis à chercher un contournement.

L'autre question, posée à la place, change le terrain : où cet outil sait-il déjà écrire ? Elle ne demande plus d'ouvrir un chemin, elle demande d'inventorier ceux qui existent. La réponse peut être un tableur, un espace de fichiers, un service déjà connecté — quelque chose de médiocre du point de vue de l'architecture visée, mais disponible immédiatement.

La première question porte sur un obstacle, la seconde sur une ressource.

Pourquoi c'est important

C'est une bascule bon marché : elle ne coûte qu'une reformulation, et elle intervient au moment où l'on est le plus enfermé — après un échec technique, quand l'énergie va vers le contournement.

Elle produit aussi un résultat de nature différente. Ce qu'on obtient n'est pas l'architecture voulue, mais un chemin qui fonctionne tout de suite et qu'on pourra remplacer plus tard.

Nuances et limites

L'inventaire des chemins existants peut être vide, et la question reste alors sans réponse.

Et ce qu'elle donne est un compromis : accepter un outil qu'on n'aurait pas choisi, avec ses limites. Le risque est de s'y installer durablement au lieu de le traiter comme une étape.

Questions ouvertes

• À quel moment décider qu'un chemin de contournement devient l'architecture définitive ?