Idée principale

Graphify, un outil qui transforme un dépôt de code en graphe de connaissances, enchaîne deux étapes : une construction, où une IA lit chaque fichier pour en déduire les éléments et leurs relations, puis une exploration — découpage en groupes, carte interactive, rapport, recherche de chemins. La seconde étape ne lit pas les fichiers : elle lit un graphe au format standard de la bibliothèque NetworkX, et ne vérifie pas d'où il vient.

Cette indifférence à la provenance découpe l'outil en deux morceaux séparables. On peut garder l'exploration et remplacer la construction par n'importe quel producteur du même format : un script de 160 lignes qui lit les liens internes d'un wiki Obsidian suffit à alimenter toute la partie aval, sans clé d'API.

Le point d'insertion n'est pas choisi au hasard : c'est le format d'échange entre les étapes, et c'est précisément là que l'étape la plus coûteuse rend son résultat.

Pourquoi c'est important

Cela donne une façon de lire un outil avant de l'adopter ou de le rejeter : chercher le format qui circule entre ses étapes. Un outil conçu pour un autre usage devient réutilisable dès qu'on sait produire, par un autre chemin, ce que son étape amont produisait.

Cela déplace aussi la question du coût. Ce qu'on paie dans un tel outil n'est pas l'outil entier, c'est l'étape qu'on ne sait pas remplacer.

Nuances et limites

Un format accepté n'est pas un format compris. L'outil continue d'attendre ce que son étape d'origine produisait : sur des notes, il signale 12 884 avertissements parce que les liens n'ont pas de fichier source, une notion qui n'a de sens que pour du code. Le détournement fonctionne, mais à côté du contrat implicite de l'outil, et une mise à jour peut le casser sans prévenir.

Questions ouvertes

• Une étape aval qui n'a jamais été testée sur un graphe venu d'ailleurs produit-elle des résultats faux sans le signaler, ou seulement des avertissements ?