Introduction

Le "second cerveau" dopé à l'IA est partout en ce moment. Le principe : vous donnez vos sources à une IA, elle génère des dizaines de notes atomiques (une idée par note), puis les relie entre elles pour créer un réseau de connaissances connectées, plein de sens.

Sur le papier, c'est séduisant. En pratique, pour la gestion des opportunités en product management, je pense que c'est une mauvaise approche.

Le monde est complexe

Pour comprendre pourquoi, il faut d'abord visualiser ce que donne un réseau de notes atomiques sur un sujet réel.

Voici une petite partie de mes notes autour de Pierre Bourdieu, issues de mes études de sociologie :

Quand on commence à comparer avec un autre sociologue — ici Niklas Luhmann, le père du Zettelkasten — la complexité explose :

Et même en essayant de simplifier par grands concepts, les liaisons restent denses. Implications, antagonismes, liaisons faibles, relations indirectes... Tout est relié, mais pas de la même manière.

Le monde est complexe. Et le product management n'y échappe pas.

Pourquoi ça ne marche pas pour le product management

Je suis opposé à cette approche pour deux raisons.

La propagation d'erreurs est incontrôlable

Quand on travaille avec une IA, il faut toujours pouvoir vérifier ce qu'elle produit. Dans un réseau de notes où tout est lié, une erreur dans une seule note peut se propager silencieusement à travers les connexions. Vous pouvez vous retrouver à défendre une opportunité basée sur une information fausse, sans même le savoir.

Avec un ensemble de fichiers limité — 30, 40 fichiers dans un répertoire dédié à une opportunité — vous avez la capacité humaine de vérifier, d'auditer. Dans un graphe de centaines de notes interconnectées, c'est illusoire.

La fenêtre de contexte explose

L'autre problème est technique. Quand vous étudiez une opportunité, vous avez besoin que l'IA reste focus : le fichier de mission, les faits acquis, les prochaines étapes à valider. C'est un contexte léger et maîtrisé.

Confrontez cette même IA à un réseau de notes sans frontières : elle va se balader de connexion en connexion, faire grossir sa fenêtre de contexte, chercher la "bonne" information dans un océan de liens. Trop d'information tue l'information.

Un réseau de notes ne se gère pas tout seul

Et il y a un problème plus profond encore. Un réseau de notes reliées entre elles ne se maintient pas par magie. Dès que le volume grandit, de nouvelles questions apparaissent :

• Les incohérences : deux notes se contredisent. Laquelle fait foi ? Sans mécanisme explicite de suivi des contradictions, l'IA (et vous) allez construire sur des fondations instables.
• Les manques : une zone entière du sujet n'est pas documentée. Mais comment le savoir dans un graphe de centaines de notes ? Un trou invisible est plus dangereux qu'un trou identifié.
• Les décisions : vous avez tranché entre deux options il y a trois semaines. Où est-ce noté ? Est-ce que la décision est encore valide ? Qui l'a prise ?

Un fichier plat ou un réseau de notes ne répondent pas à ces questions. Il faut une structure de mémoire dédiée — avec des fichiers qui tracent explicitement les contradictions, l'état de complétude, les décisions et leurs justifications.

J'ai détaillé cette approche dans un article précédent : Du fichier unique au système de contextes — pourquoi la mémoire d'un LLM ne tient pas dans un seul document. Le principe : chaque mission a son propre espace structuré — mission, état courant, sources, notes, mémoire cumulée, livrables — avec des mécanismes explicites pour gérer ce que le réseau de notes laisse dans l'angle mort.

Or, quand on décide d'étudier une opportunité, on fait un pari sur une thématique, une feature, un impact. On réduit le scope volontairement. Le système de notes devrait refléter cette réduction, pas la combattre.

L'alternative : le bounded context

C'est pourquoi je préfère une approche où chaque opportunité vit dans son propre espace borné, avec ses propres fichiers. Si j'ai besoin d'informations venant d'un autre domaine, je ne crée pas une liaison vers la source originale — je copie et j'adapte ces informations au contexte de mon opportunité.

Cette approche reprend exactement le concept de bounded context du Domain-Driven Design.

Prenons un exemple concret. Un système de paie a besoin de connaître les congés pris par les salariés ce mois-ci. Plutôt que de créer un lien direct vers le système de gestion des congés, on intègre ces données dans le domaine "variables de paie". On obtient ainsi des congés qui sont cohérents avec le domaine de la paie, au lieu d'essayer de faire entrer un concept avec tout son contexte d'origine dans un autre domaine.

Pour le product management, c'est la même logique. Chaque opportunité a son contexte propre, ses propres fichiers, sa propre vérité locale. Les informations extérieures sont importées et adaptées, pas liées dynamiquement.

Être proche — voire calqué — sur les méthodes de développement évite les couches d'abstraction entre dev et product. On ne tord plus les concepts à chaque passage d'un contexte à l'autre.

Conclusion

Le second cerveau centralisé, sans frontières entre les opportunités, n'est pas adapté au product management. La complexité qu'il expose est réelle, mais la réponse n'est pas de tout connecter — c'est de borner intelligemment.

Des espaces dédiés, auditables, où l'IA travaille sur un périmètre maîtrisé : c'est ce qui permet de garder le contrôle sur ce qu'on construit et ce qu'on défend.

Pour quels domaines le second cerveau fonctionne-t-il vraiment bien ? J'en parlerai dans un prochain article.

Sources

• Méthode Zettelkasten : https://en.wikipedia.org/wiki/Zettelkasten
• Domain-Driven Design — Bounded Context : https://martinfowler.com/bliki/BoundedContext.html
• Du fichier unique au système de contextes : https://malorean.net/articles/2026-04-21-du-fichier-unique-au-systeme-de-contextes-pourquoi-la-memoire-dun-llm-ne-tient-pas-dans-un-seul-document.html