Graph engineering : des boucles aux graphes de savoir

Le 18 juillet 2026, Peter Steinberger a posté sur X une question ironique sur le passage des boucles aux graphes. Hamel Husain a embrayé et publié un article intitulé Loop Engineering Is Dead. Enter Graph Engineering. En une semaine, le terme était partout.

C’était surtout une blague sur la vitesse à laquelle ce domaine invente de nouvelles disciplines — on est passé de prompt engineering à context engineering, puis harness engineering, loop engineering et graph engineering en dix-huit mois, avec des définitions qui se recouvrent largement.

Mais la blague a fait mouche parce qu’elle désigne quelque chose de réel. Voici la partie qui mérite d’être gardée.

Trois choses qu’on appelle « graph engineering »

Le terme est arrivé en portant au moins trois idées distinctes. La majeure partie de la confusion en ligne, ce sont des gens qui s’engueulent d’une idée à l’autre.

1. Les graphes d’orchestration. Concevoir un système multi-agents comme un graphe explicite plutôt qu’une boucle while : nœuds typés, transitions typées, points de reprise. C’est le terrain de LangGraph et Temporal. C’est de la vraie ingénierie, et ça compte surtout si vous construisez de l’infrastructure d’agents.

2. Les graphes de boucles. Des réseaux de cycles d’auto-amélioration qui s’observent les uns les autres. Conceptuellement intéressant, et de l’avis général le moins actionnable aujourd’hui.

3. La connaissance et la mémoire structurées en graphe. Le savoir de l’agent stocké comme des nœuds et des arêtes typés qu’il peut réellement parcourir, au lieu d’un tas de documents qu’il relit et redevine à chaque fois.

Si vous ne construisez pas d’infrastructure d’orchestration — et la plupart d’entre nous n’en construisent pas, même ceux qui regardent les agents entrer dans l’espace de travail — c’est le n°3 qui change votre quotidien. C’est aussi le plus ancien et le mieux étayé des trois : les graphes de connaissances précèdent le terme de plusieurs décennies.

Pourquoi les arêtes battent la recherche

Voici l’exemple qui fait comprendre.

Demandez à un agent : « Pourquoi on a abandonné Redis pour la file de jobs ? »

La recherche plein texte vous rend tous les documents contenant « Redis » — soit, après quelque temps de travail, des dizaines de fichiers dont aucun n’est la réponse. La recherche vectorielle vous rend des documents qui ressemblent à la question, ce qui est souvent pire : sémantiquement proches, causalement hors sujet.

Un graphe répond en trois sauts :

file de jobs   --decided_by--> ADR-007 (file Postgres)
ADR-007        --supersedes--> ADR-003 (file Redis)
ADR-003        --caused------> Incident 2026-03-11

La réponse n’est dans aucun document. Elle est dans le chemin entre eux. Une recherche ne peut pas retrouver un chemin : elle retrouve des nœuds, et espère que vous les relierez vous-même.

Et notez le détail décisif : les arêtes sont nommées. supersedes n’est pas caused, qui n’est pas decided_by. Enlevez les étiquettes et vous revenez à « ces fichiers ont un rapport, on ne sait pas lequel » — ce qui oblige l’agent à tous les ouvrir et à réinférer la relation, exactement le travail que vous vouliez lui éviter.

Les arêtes typées, c’est toute l’astuce. Le reste est de la plomberie.

Votre vault Markdown en est déjà à 80 %

Voici l’observation sous-estimée de toute cette discussion : un vault Markdown bien tenu constitue déjà l’essentiel d’un index GraphRAG.

Regardez ce qu’un vault de notes avec des wikilinks vous donne gratuitement :

• Des nœuds — un fichier par idée, source ou décision
• Des arêtes — chaque [[wikilink]] est une connexion que quelqu’un a délibérément établie
• La résolution d’entités réglée par construction — [[ADR-007]] désigne le même nœud partout où il apparaît. Pas d’appariement approximatif, pas de collisions d’embeddings, pas de « est-ce que ces deux mentions parlent de la même chose ? »

Ce dernier point n’est pas anodin. La résolution d’entités est précisément l’endroit où la plupart des pipelines automatiques de graphes de connaissances s’effondrent en silence. Un vault contourne le problème parce qu’un humain a nommé l’entité une fois, et que le lien fait l’identité.

Ce qui manque à un vault brut, ce sont les étiquettes. [[ADR-007]] vous dit qu’il y a un lien entre deux notes. Il ne dit pas lequel. Ce sont les 20 % restants.

À quoi ça ressemble concrètement

C’est la partie autour de laquelle Minibase Vault a été construit, alors autant être concret sur son fonctionnement plutôt qu’abstrait sur ses possibilités.

Les nœuds viennent de la lecture. Vous cliquez sur l’extension Minibase sur tout ce qui mérite d’être gardé — une page de doc, une RFC, un fil X, une conférence — et ça atterrit en Markdown propre dans une base de connaissances locale. Pas de copier-coller, pas d’étape d’export, pas d’onglet « je lirai plus tard » qui meurt au prochain crash du navigateur.

Les arêtes sont enregistrées, avec une raison. Le vault tient un _graph.json à sa racine :

{
  "edges": [
    {
      "from": "AI Research/attention-paper-20260405-1200.md",
      "to": "AI Research/transformer-tutorial-20260408-0900.md",
      "reason": "Both explain the attention mechanism in transformers"
    }
  ]
}

Claude écrit ces arêtes lui-même, via le serveur MCP du vault, quand il lit en travers de vos notes et repère une connexion. Elles ressortent ensuite en lignes Related: dans le _index.md de chaque base, pour que la toile soit visible par vous aussi, pas seulement par le modèle.

Les chemins se condensent en pages. Quand un groupe de notes liées devient assez dense, Claude peut les synthétiser en une page _topic-*.md qui cite ses sources. La prochaine fois que vous enregistrez quelque chose dans ce groupe, la page de synthèse est déjà là, prête à être mise à jour. C’est l’effet cumulatif : le vault devient plus intelligent, pas seulement plus gros.

Les orphelins sont signalés. Une passe de lint remonte les doublons, les notes orphelines, le contenu périmé et les grappes mûres pour une synthèse. Les graphes se dégradent ; il faut bien que quelque chose le remarque.

Tout tourne en local. L’index de recherche est du SQLite FTS5 avec classement BM25, le graphe est un fichier JSON, et rien de vos notes ne quitte la machine.

Où je tempérerais l’enthousiasme

Deux réserves honnêtes, parce que c’est un terme devenu populaire en une semaine, et que la popularité va plus vite que le fond.

Les arêtes de Minibase portent une raison, pas un type formel. "reason": "Both explain the attention mechanism" est une phrase, pas supersedes. C’est très supérieur à un wikilink non étiqueté, et très inférieur à une ontologie. Si vous avez besoin de relations strictement typées pour du raisonnement multi-sauts à grande échelle, il vous faut une vraie base de graphes — et il faut être honnête avec soi-même sur la maintenance que ça implique.

La plupart des gens n’ont besoin de rien de tout ça. Si votre savoir tient en cinquante notes, la recherche suffit. Les graphes deviennent rentables quand vous avez assez de matière pour avoir commencé à oublier ce que vous possédez — et quand vos questions sont causales (« pourquoi avons-nous ») plutôt que lexicales (« où ai-je lu »).

Le terme « graph engineering » ne survivra probablement pas à l’année. L’idée en dessous — que la structure entre vos notes vaut plus que le volume de notes — était vraie bien avant d’avoir un nom, et le restera après.

Commencez par la version ennuyeuse

1. Enregistrez ce que vous lisez en Markdown au lieu de le mettre en favori. Un favori est un pointeur vers une chose qui pourrit ; un fichier est une chose que vous avez.
2. Gardez tout en local, dans un seul dossier, un fichier par source.
3. Laissez votre IA lire le dossier entier — via MCP, pas par copier-coller — et posez-lui des questions qui exigent deux documents pour être résolues.
4. Enregistrez les connexions qu’elle trouve. Puis reposez la question le mois suivant.

Voilà le graph engineering pour ceux qui ne livrent pas de frameworks d’orchestration. C’est du context engineering avec les connexions écrites noir sur blanc.

---

Minibase convertit n’importe quelle page web en Markdown propre en un clic, directement dans un vault local que votre IA peut fouiller et relier. L’extension est gratuite avec un nombre illimité de sauvegardes ; Minibase Plus (5,99 $/mois ou 34,99 $/an) ajoute les modèles IA, l’historique et la transcription vidéo. minibase.md.