Graphes de connaissance IA : pourquoi votre agent a besoin de deux cerveaux (cortex et minus)

Découvrez l'architecture "deux cerveaux" des knowledge graphs IA : KG micro (minus) pour les faits, KG macro (cortex) pour le contexte. Audit réel avec 66 000 triplets et métriques de santé.

Débat audio sur l'article :

# DÉBAT-030 : Les bases de connaissance de l'agent IA — deux niveaux pour mieux penser **Source :** drafts/DRAFT-030-kg-micro-macro-deux-cerveaux.md **Intervenants :** Mathieu (homme), Vivienne (femme) **Durée estimée :** ~10 minutes **Date :** 2026-03-12 **Note :** Anglicismes évités. Termes techniques remplacés par des formulations françaises accessibles. Ton neutre, factuel. --- [Vivienne] Mathieu, tu as réalisé cette semaine un bilan complet de la base de connaissance de ton infrastructure d'agents automatisés. Qu'est-ce qu'une base de connaissance dans ce contexte. [Mathieu] C'est une structure qui stocke des faits sous forme de relations entre entités. Plutôt que d'avoir des données brutes dans des tableaux classiques, on représente les liens entre les choses. Par exemple : cet agent utilise cet outil. Ce fichier appartient à cette personne. Ce composant fait appel à cette interface réseau. [Vivienne] Chaque relation est donc un fait élémentaire. [Mathieu] Exactement. On appelle ça un triplet : un sujet, une relation, un objet. Comme une phrase simple. L'ensemble de ces phrases forme une carte navigable du système. [Vivienne] Et ton bilan donne quels chiffres. [Mathieu] Soixante-six mille quarante-cinq faits actifs. Sur un total de soixante-quatorze mille trois cent soixante, soit près de quatre-vingt-neuf pourcent d'actifs. Ces faits sont reliés par cent vingt-et-un types de relations différents, produits par cinquante-deux sources d'extraction distinctes. [Vivienne] Ces sources extraient les données comment. [Mathieu] Automatiquement, depuis des sources variées. L'historique des modifications du code représente vingt-cinq virgule six pourcent des faits — c'est la source principale. L'analyse des composants de l'interface représente quinze virgule neuf pourcent. La structure des répertoires, neuf pourcent. Et ainsi de suite. Tout se construit sans intervention manuelle. [Vivienne] La source la plus importante reste donc l'historique de code. [Mathieu] Oui, parce que l'historique contient des informations précieuses que le code seul ne dit pas. Qui a créé tel fichier. Qui le modifie le plus souvent. Quelle partie du système est la plus active. Ce sont des relations de propriété et d'usage qu'on ne peut pas inférer autrement. [Vivienne] Tu parlais de carte navigable. Certains points de cette carte sont plus connectés que d'autres. [Mathieu] Oui, ce sont les points de convergence. Dans mon système, l'utilisateur principal concentre douze mille cent soixante-neuf connexions — c'est logique, c'est lui qui a tout créé et modifié. L'agent principal en compte quatre mille deux cent quatre-vingt-quatre. Le projet d'interface principal, trois mille sept cent quarante-deux. [Vivienne] Ces points très connectés posent-ils un problème. [Mathieu] Ils sont utiles pour la navigation, mais il faut les filtrer dans les recherches sémantiques. Sinon ils dominent les résultats et écrasent les relations plus fines. C'est comme chercher sur une carte routière sans filtrer les autoroutes — tu ne vois plus les petites routes qui t'intéressent vraiment. [Vivienne] Parlons maintenant de ce que tu appelles le deuxième niveau. Tu as construit une couche au-dessus de cette base de faits. [Mathieu] Oui. La base de faits est excellente pour répondre à des questions précises. Mais avec soixante-six mille faits et cent vingt-et-un types de relations, la navigation devient complexe pour un agent. Comment sait-il dans quel domaine fonctionnel il opère ? La couche de contexte répond à cette question. [Vivienne] Explique ce que tu appelles domaine fonctionnel. [Mathieu] C'est un regroupement sémantique d'entités qui ont un rôle commun dans le système. Mon système en compte huit : l'interface principale en composants réactifs, l'orchestration des agents, les outils de développement, l'infrastructure, la plateforme commune, la base de connaissance elle-même, la surveillance, et la visualisation du graphe. [Vivienne] Et comment les entités sont-elles reliées à leur domaine. [Mathieu] Via ce que j'appelle des points d'ancrage. Ce sont des liens entre une entité de la base de faits et son domaine de contexte. J'en ai mil cinq cent quatre-vingt-dix-sept au total. Chaque point d'ancrage est calculé par similarité sémantique — l'entité est placée dans le domaine dont le sens est le plus proche du sien. [Vivienne] Ce calcul de similarité, comment fonctionne-t-il concrètement. [Mathieu] Chaque entité et chaque domaine sont représentés par une empreinte numérique, un vecteur de mille vingt-quatre valeurs qui capture leur sens. La proximité entre deux empreintes numériques mesure leur parenté sémantique. Plus la valeur est proche de un, plus les deux entités partagent un sens commun. [Vivienne] Et les domaines entre eux, sont-ils également comparés. [Mathieu] Oui, c'est une des forces du système. Les deux domaines d'interface ont une proximité de zéro virgule sept quatre-vingt-quatre — ils partagent beaucoup de patterns de code communs. L'infrastructure et la plateforme sont à zéro virgule sept cent trente-neuf. L'orchestration des agents et la surveillance sont à zéro virgule six cent quatre-vingt-dix-sept. Ces mesures ne sont pas des estimations, ce sont des calculs réels sur les empreintes numériques. [Vivienne] Qu'est-ce que ces mesures de proximité permettent à un agent de faire. [Mathieu] Elles permettent le raisonnement par contexte. Si un agent travaille sur un composant du domaine de visualisation, il sait que le domaine d'interface principal est très proche sémantiquement. Il peut automatiquement charger les règles de ce domaine connexe sans qu'on le lui demande explicitement. [Vivienne] C'est une forme de déduction. [Mathieu] Exactement. Sans cette couche de contexte, l'agent ne connaît que des faits isolés. Avec elle, il comprend dans quel espace fonctionnel il se trouve et quels autres espaces sont pertinents. C'est la différence entre une liste d'adresses et une carte avec des quartiers. [Vivienne] Parlons du bilan de santé. Tu as mentionné six indicateurs de contrôle. [Mathieu] Six oui, et tous sont au vert cette semaine. Le premier vérifie qu'aucun domaine n'existe sans points d'ancrage — résultat zéro pourcent. Le deuxième surveille la concentration : si un seul domaine attire trop d'entités, le découpage est mauvais. Mon domaine le plus chargé concentre trente-sept virgule dix-sept pourcent des ancres. Le seuil d'alerte est à quarante pourcent. [Vivienne] Tu es proche du seuil. [Mathieu] En zone de vigilance, oui. Ce domaine représente l'interface principale — un projet conséquent qui justifie sa taille. Mais si on devait en ajouter beaucoup d'autres composants, il faudrait le subdiviser à nouveau. Ce qui d'ailleurs a déjà eu lieu : il a été scindé en deux sous-domaines il y a quelques semaines. [Vivienne] Les quatre autres indicateurs. [Mathieu] Aucune ancre périmée. Toutes les empreintes numériques sont renseignées — c'est critique, une entité sans empreinte est invisible pour la recherche sémantique. La répartition entre domaines est équilibrée. Et aucune ancre orpheline, c'est-à-dire sans domaine parent valide. [Vivienne] La couverture des empreintes numériques est à cent pourcent dans la base de faits aussi. [Mathieu] Oui, pour les soixante-six mille faits actifs. C'est la métrique la plus importante pour la recherche sémantique. Si elle tombe en dessous de quatre-vingt-quinze pourcent, ça signifie que des faits récemment ajoutés n'ont pas encore été vectorisés, et ils seront invisibles dans les recherches par sens. [Vivienne] Qu'est-ce que ce double niveau change concrètement pour un agent qui reçoit une tâche. [Mathieu] Sans la couche de contexte, l'agent doit parcourir les soixante-six mille faits pour identifier ce qui est pertinent. Avec elle, il consulte d'abord le niveau de contexte — huit domaines au lieu de soixante-six mille entités — identifie son domaine en quelques millisecondes, et charge uniquement ce qui est pertinent. La recherche est structurée avant d'être exhaustive. [Vivienne] Un autre avantage que tu mentionnes dans l'article : la détection de dépendances inattendues. [Mathieu] C'est peut-être l'apport le plus surprenant. La base de faits contient des relations que personne n'a définies manuellement — elles ont émergé de l'analyse. Mil sept cent quatre-vingt-dix-huit faits identifient des bibliothèques installées dans le système mais jamais utilisées dans le code. Ce sont des poids morts. Mil zéro quatre-vingt-dix-neuf faits relient des agents automatisés à des composants de code par simple proximité sémantique, sans lien explicite dans le code source. Ce genre de relation invisible est précieux pour un audit d'architecture. [Vivienne] Pour les équipes qui construisent des systèmes similaires, quel est l'investissement nécessaire pour mettre en place cette architecture. [Mathieu] La couche de faits se construit automatiquement si on dispose de sources bien définies — historique de code, analyse syntaxique, configuration des outils. Le plus gros travail est de brancher les bonnes sources d'extraction. La couche de contexte est plus légère qu'elle n'y paraît : mil cinq cent quatre-vingt-dix-sept ancres pour soixante-six mille faits, soit deux virgule quatre pourcent de surcoût en stockage. Et l'audit de santé complet tourne en moins de dix secondes. [Vivienne] Deux niveaux, une architecture légère, et une santé mesurable en continu. [Mathieu] C'est ça. Un agent sans ce double niveau peut fonctionner — beaucoup le font. Mais il navigue à vue dans sa propre base de connaissance. La couche de contexte ne multiplie pas la complexité, elle la structure. C'est ce qui permet à un agent de savoir non seulement quoi faire, mais dans quel cadre il opère. [Vivienne] Merci Mathieu. [Mathieu] Merci. ---

Meta description : Découvrez l'architecture "deux cerveaux" des knowledge graphs IA : KG micro pour les faits, KG macro pour le contexte. Audit réel avec 66 000 triplets et métriques de santé.

Mots-clés : graphe de connaissance IA, knowledge graph agent IA, base de connaissance agent IA, RAG architecture knowledge graph, KG micro macro IA

Comment un agent IA sait-il ce qu'il sait ? C'est une question qui paraît simple, mais dont la réponse change tout à la manière dont on conçoit un système intelligent. Un agent qui répond à vos questions ne « pense » pas dans le vide — il navigue dans une représentation structurée du monde. Et la qualité de cette représentation détermine directement la qualité de ses réponses.

Qu'est-ce qu'un graphe de connaissance IA ? Un graphe de connaissance (Knowledge Graph, KG) est une base de données qui stocke des relations entre entités sous forme de triplets : sujet → relation → objet. Appliqué à un système d'agents IA, il constitue la mémoire structurée et navigable de l'infrastructure — faits, dépendances, historique, contexte fonctionnel.

Dans mon infrastructure d'agents autonomes, j'utilise une architecture que j'appelle « deux cerveaux » : un graphe de connaissance micro pour les faits bruts, et un graphe de connaissance macro pour le contexte fonctionnel. Après un audit complet de cette architecture cette semaine, je partage les chiffres réels et ce que cette dualité change concrètement.

Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.

S'inscrire

Le KG micro : le cerveau factuel

Un graphe de connaissance (Knowledge Graph, KG) est une base de données qui stocke des relations entre entités sous forme de triplets : sujet → relation → objet. Par exemple : mgrr-agent-code-reviewer USES_TOOL Bash ou ConfigLoader.svelte CALLS_API GET /api/contacts.

Mon KG micro contient actuellement 66 045 triplets actifs (sur 74 360 au total, soit 88,8 % d'actifs). Ce n'est pas une collection arbitraire de faits — chaque triplet a été extrait automatiquement depuis des sources réelles : dépôts git, fichiers de code, sessions d'agents, configurations.

Ce que représentent ces 66 000 triplets

La diversité est frappante : 121 types de relations différentes, 35 types de sujets, 53 types d'objets, alimentés par 52 sources d'extraction distinctes.

Les relations les plus fréquentes donnent une idée de ce que le graphe « sait » en priorité :

RELATED_TO (7 440 triplets) : similarité sémantique entre entités
OWNS (5 814) et CREATES (5 672) : attribution de code depuis l'historique git
DIR_CONTAINS (5 561) et CONTAINS (5 555) : structure des répertoires
IMPLEMENTED_IN (4 718) : lien entre entité KG et chunk de code source
DEPENDS_ON_VERSION (1 824) : dépendances versionnées (ex : axios@1.6.0)

Concrètement : quand un agent cherche « qui est responsable de ce composant ? », il traverse la relation OWNS issue de l'historique git. Quand il cherche « quelles fonctions ce fichier importe-t-il ? », il parcourt IMPORTS_FUNCTION. Le graphe est une carte navigable de l'infrastructure.

Les hubs : les nœuds les plus connectés

Comme dans tout graphe réel, certains nœuds concentrent beaucoup de connexions. Les trois premiers hubs de mon KG micro sont :

user : 12 169 connexions (auteur git des modifications)
claude/agent : 4 284 connexions (agent IA principal)
svelte5/projet : 3 742 connexions (le projet frontend principal)

Ces hubs sont utiles pour la navigation — ils permettent de trouver rapidement les entités centrales — mais ils doivent être filtrés dans les visualisations pour ne pas écraser les nœuds plus spécifiques.

D'où viennent les données ?

Les quatre sources dominantes couvrent la majorité du graphe :

git-log (25,6 %) : historique de commits, ownership, qui a créé/modifié quoi
svelte5-parse (15,9 %) : analyse AST des composants Svelte5 (props, stores, events, appels API)
dir-hierarchy (8,9 %) : arborescence des répertoires
grepai-chunks (7,1 %) : liens vers les chunks de code source indexés dans GrepAI

La qualité des embeddings est à 100 % — chaque triplet est vectorisé avec bge-m3 (1024 dimensions), ce qui permet la recherche sémantique directement dans le graphe. Aucune alerte n'est levée sur la santé du KG micro.

Le KG macro : le cerveau contextuel

Le KG micro est excellent pour répondre à des questions factuelles précises. Mais il a une limite : avec 66 000 triplets et 121 types de relations, la navigation peut devenir complexe. Comment un agent sait-il dans quel domaine fonctionnel il opère ? Comment navigue-t-il de « ce composant Svelte » vers « l'équipe qui le maintient » vers « les agents IA responsables de ce domaine » ?

C'est le rôle du KG macro : une couche sémantique au-dessus du graphe micro qui organise les entités en domaines fonctionnels.

8 domaines, 1 597 ancres

Le KG macro identifie actuellement 8 domaines fonctionnels et les relie via 1 597 ancres (des liens entre une entité micro et son domaine macro).

Domaine	Ancres	%
GrepAI-Frontend-Svelte	591	37,0 %
GrepAI-AgentOrchestration	425	26,6 %
GrepAI-DevTools	308	19,3 %
GrepAI-Infrastructure	124	7,8 %
GrepAI-Platform	66	4,1 %
GrepAI-KnowledgeGraph	39	2,4 %
GrepAI-Monitoring	38	2,4 %
GrepAI-Frontend-KGViz	6	0,4 %

Le domaine GrepAI-Frontend-Svelte domine avec 37 % des ancres — ce qui reflète la réalité : le projet principal est une application Svelte5 conséquente. GrepAI-AgentOrchestration avec 26,6 % représente l'infrastructure d'agents IA. Ces deux domaines à eux seuls couvrent 63,6 % du système.

Les relations entre domaines : ce que le cosinus révèle

Le KG macro ne se contente pas d'organiser — il mesure les chevauchements sémantiques entre domaines via une similarité cosinus réelle (pas une heuristique, une vraie mesure vectorielle calculée sur les embeddings bge-m3).

Les résultats sont parlants :

Frontend-Svelte ↔ Frontend-KGViz : cosinus 0,784 — les deux interfaces partagent des patterns de code très similaires
Infrastructure ↔ Platform : 0,739 — couches techniques proches
DevTools ↔ Platform : 0,730 — les outils de développement dépendent fortement de la plateforme
AgentOrchestration ↔ Monitoring : 0,697 — les agents et leur monitoring sont sémantiquement liés

Ces scores permettent à un agent de raisonner : « je travaille sur un composant KGViz, le domaine Frontend-Svelte est très proche (0,784), je vais aussi charger les règles de ce domaine. »

L'audit en pratique : les métriques qui comptent

Un KG sans audit régulier devient rapidement une base de faits périmés. Voici les métriques que je surveille et ce qu'elles indiquent.

Santé du KG micro

Taux d'activité : 88,8 % des triplets sont actifs. Les 11,2 % inactifs correspondent à des entités supprimées ou obsolètes, conservées pour la traçabilité mais filtrées dans les requêtes courantes.

Couverture des embeddings : 100 %. C'est la métrique critique pour la recherche sémantique — un triplet sans embedding est invisible pour la recherche vectorielle. Un taux inférieur à 95 % devrait déclencher une alerte.

Diversité des sources : 52 sources d'extraction. Plus ce nombre est élevé, plus le graphe capture des facettes différentes du système. Un graphe alimenté par une seule source (uniquement le git-log, par exemple) manquerait toute la dimension sémantique des imports, des appels API, des dépendances versionnées.

Santé du KG macro : les 6 alertes vertes

L'audit du KG macro vérifie 6 conditions de santé. Toutes sont au vert :

anchor_gap = 0 % : aucune entité macro sans ancres micro
hub_concentration = 37,17 % (seuil : 40 %) : le domaine le plus dense ne concentre pas trop d'ancres — le graphe n'est pas déséquilibré
expired anchors = 0 : aucune ancre périmée
embedding nulls = 0 : tous les nœuds macro sont vectorisés
jaccard uniformity : bonne répartition des entités entre domaines
orphan anchors = 0 : aucune ancre sans domaine parent valide

Le seuil de hub_concentration à 40 % est particulièrement important. Si un seul domaine attire trop d'ancres (> 40 %), cela signifie que le découpage en domaines est mal calibré — trop d'entités s'accumulent dans un « sac » générique plutôt que d'être réparties dans des domaines spécifiques. À 37,17 %, je suis en zone de vigilance mais hors d'alerte.

Ce que cette architecture change

Pour un développeur qui construit un système RAG ou une base de connaissance pour ses agents, la distinction micro/macro n'est pas anecdotique. Elle change la manière de penser les requêtes et le routing.

Le routing sémantique par domaine

Sans KG macro, un agent qui reçoit une tâche sur un composant Svelte doit soit connaître à l'avance à quel domaine appartient ce composant, soit faire une recherche full-scan dans les 66 000 triplets. Avec le macro, la fonction kg_macro_domain_for('ConfigLoader.svelte') renvoie instantanément GrepAI-Frontend-Svelte, et l'agent sait quelles règles de domaine charger en priorité.

La bridge sémantique : traverser les deux niveaux

La fonction kg_macro_bridge('mgrr-agent-planner', 'mgrr-agent-code-reviewer') trace un chemin entre deux agents via les domaines macro. Au lieu de chercher une relation directe dans 66 000 triplets, elle monte au niveau macro, traverse les relations OVERLAPS_WITH, et redescend. C'est l'équivalent d'un GPS qui passe par les grandes routes avant de vous guider dans les petites rues.

La détection de dépendances inattendues

La force du graphe micro est de révéler des dépendances qui ne sont pas évidentes à la lecture du code. NEVER_IMPORTED (1 798 triplets) identifie des packages installés mais jamais importés. SEMANTICALLY_LINKED connecte un agent IA à des composants de code sans qu'il y ait de lien explicite dans le code source — juste une proximité sémantique calculée sur les embeddings.

Ces relations « inattendues » sont celles qui ont le plus de valeur pour un audit d'architecture.

Pour aller plus loin : les métriques de santé pour les développeurs RAG

Si vous construisez un système similaire, voici les métriques à surveiller en priorité (avec les requêtes SQL correspondantes) :

Taux d'activité des triplets : SELECT COUNT(*) FILTER (WHERE active) * 100.0 / COUNT(*) FROM rag_knowledge_graph. Cible : > 85 %.

Couverture embeddings : SELECT COUNT(*) FILTER (WHERE embedding IS NOT NULL) * 100.0 / COUNT(*) FROM rag_knowledge_graph WHERE active = true. Cible : 100 %.

Concentration des hubs : surveiller que les top-5 nœuds ne représentent pas > 50 % des connexions totales. Les super-hubs (user, claude) sont normaux dans un graphe git, mais doivent être filtrés dans les requêtes sémantiques.

Ancres macro : SELECT macro_entity, COUNT(*) as anchors, ROUND(100.0*COUNT(*)/SUM(COUNT(*)) OVER(), 1) as pct FROM kg_macro_anchors WHERE active=true GROUP BY macro_entity ORDER BY anchors DESC. Si un domaine dépasse 40 %, revoir le découpage.

Drift de versions : SELECT * FROM v_lib_version_drift WHERE drift_severity NOT ILIKE 'LOW%'. Les packages installés en plusieurs versions dans différents projets sont une source de bugs silencieux.

Imports morts : SELECT * FROM kg_dead_imports() WHERE verdict ILIKE 'ORPHAN%'. Des packages installés mais jamais importés alourdissent le bundle sans apporter de valeur.

L'audit complet (6 alertes macro + métriques micro) tourne en moins de 10 secondes sur une infrastructure modeste. Il devrait faire partie de tout pipeline CI sérieux.

Conclusion

Deux cerveaux, une seule intelligence. Le KG micro sait tout — faits, relations, dépendances, historique. Le KG macro sait où — dans quel domaine fonctionnel opère chaque entité, quelles zones se chevauchent, où sont les déséquilibres.

Un agent sans cette dualité peut fonctionner — la plupart le font. Mais il navigue à vue dans sa propre base de connaissance, sans carte à grande échelle. L'ajout du niveau macro ne multiplie pas la complexité : c'est une couche légère (1 597 ancres pour 66 000 triplets, soit 2,4 % de surcoût en stockage) qui change fondamentalement la qualité du raisonnement.

La vraie valeur de cette architecture n'est pas dans les chiffres de l'audit — elle est dans ce qu'elle permet : des agents qui savent non seulement quoi faire, mais dans quel contexte ils opèrent. C'est la différence entre un assistant qui consulte un annuaire et un expert qui comprend l'organisation.

Articles liés :
- Surveillance des agents IA : gardes-fous et mécanismes de contrôle
- Claude tokens et optimisation du contexte
- Agent tasks : observabilité multi-environnement
- Benchmark modèles IA locaux 2026

Qui suis-je ?

Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.

J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.

Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.

L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.

La technologie, les méthodes, le management sont le cœur de mes compétences.

Vous pouvez me faire confiance sur ces points là.

Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr

Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100 % IA.

Mathieu Grenier 12 mars 2026