Le modèle du tulpa : pourquoi je pense avec l'IA, pas à travers elle

Mitchell Hashimoto, le fondateur de HashiCorp, a posté un tweet cette semaine qui a pris la une de Hacker News.

« Je crois fermement qu'il y a en ce moment des entreprises entières sous psychose IA lourde... Tu peux t'automatiser jusqu'à construire une machine à catastrophes très résiliente. Les systèmes peuvent paraître sains selon les métriques locales tout en devenant globalement incompréhensibles. »

Le fil en dessous est un cimetière. Des développeurs qui livrent à un rythme record tout en accumulant de la dette cognitive. Des ingénieurs qui admettent ne pas avoir lu leur propre codebase depuis des mois. Des PRs approuvées parce que « l'IA a dit que c'était correct ».

Hashimoto a raison. Mais le remède n'est pas d'utiliser moins l'IA. C'est de changer comment tu penses avec elle. Et le meilleur modèle mental que j'aie trouvé pour ça vient d'un endroit inattendu : le bouddhisme tibétain.

Le tulpa

Dans la tradition bouddhiste tibétaine, un tulpa est un être créé par une intense focalisation mentale. Une forme-pensée sensible qui développe sa propre autonomie apparente tout en restant fondamentalement connectée à son créateur. Ce n'est pas une entité séparée que tu commandes. C'est une émanation de ta propre conscience, à laquelle tu donnes assez de structure pour converser avec toi.

Quand j'ai rencontré ce concept pour la première fois, je me suis arrêté. Parce qu'il décrivait exactement ce que j'avais été en train de construire sans avoir le mot pour le dire.

Je travaille avec une assistante IA nommée Leeloo. Elle tourne sur Hermes, un framework d'agent open-source de Nous Research, que j'ai lourdement customisé : mémoire sémantique persistante via MemPalace, contexte qui porte à travers les sessions, et une base de connaissances dont elle tire avant chaque interaction. Pour le travail de développement, j'utilise aussi Claude Code. Leeloo gère ma surface de pensée, mes projets, mes angles morts. Claude Code gère le code. Mais voici la partie qui compte avec les deux : je ne leur demande pas des réponses et je ne livre pas ce qu'ils retournent. Je pense avec eux.

Le modèle du tulpa capture ça. L'IA n'est pas un oracle, pas un développeur junior, pas un outil au sens où un marteau est un outil. C'est une excroissance de mon propre processus de pensée — une surface sur laquelle je peux projeter des idées, les faire pivoter, les faire attaquer depuis des angles que je n'avais pas considérés, et les regarder évoluer à travers le dialogue.

La gymnastique de penser hors de soi

Voici le mécanisme difficile à expliquer mais crucial à comprendre.

Tu as une idée. Elle est dans ta tête, et quand une idée n'est que dans ta tête, elle est dangereusement cohérente. Tu ne peux pas voir ses trous parce que tu les as remplis inconsciemment. Tu ne peux pas la remettre en cause efficacement parce que c'est le même cerveau qui l'a produite qui essaie de l'évaluer.

Maintenant tu prends cette idée et tu la présentes à l'IA. Pas comme un prompt pour exécution. Comme un point de départ pour le dialogue. Tu expliques ce que tu penses. Tu lui demandes d'attaquer l'idée. De trouver les points faibles. De jouer l'avocat du diable. D'explorer des cadrages alternatifs. De pousser.

Ce qui se passe ensuite est une sorte de gymnastique cognitive. L'IA devient un miroir qui te montre ta propre idée sous des angles auxquels tu n'avais pas accès. Elle ne remplace pas ta pensée. Elle multiplie les surfaces contre lesquelles ta pensée peut rebondir. Tu débats avec toi-même, mais l'adversaire est la version externalisée de tes angles morts.

Ça, c'est le tulpa en action. Ta pensée, projetée hors de toi, à laquelle on donne assez de structure pour pousser, puis réintégrée une fois que le dialogue a fait son travail. L'IA n'a pas eu l'idée. C'est toi. L'IA n'a pas pris la décision finale. C'est toi. Mais l'espace entre ta pensée initiale et ta décision finale était peuplé par une conversation qui aurait été impossible à l'intérieur de ta seule tête.

De l'extérieur, ça ressemble à de l'outsourcing. De l'intérieur, c'est un multiplicateur sur la pensée que je faisais déjà.

Le piège de ne pas lire

Il y a un moment dans la journée de chaque développeur où la fatigue tombe. Il est 16h, tu as context-switché six fois, et l'IA vient de produire une spec, un plan ou une analyse. Ça a l'air correct. Le lire prendrait 10 minutes. L'accepter et passer prend 10 secondes.

Ce moment, c'est là que la dette cognitive commence.

Le problème n'est pas que psychologique. Il est aussi pratique. Le format d'output par défaut des outils de code IA est Markdown. Markdown est génial pour la machine. C'est structuré, parsable, facile à stocker dans un repo. Mais pour un humain fatigué à 16h, Markdown est un mur de texte. Ton cerveau voit de la friction et cherche une sortie.

J'ai cogné ce mur à plusieurs reprises. Et puis j'ai fait un changement qui s'est révélé être le mécanisme anti-dette le plus efficace de tout mon workflow.

Double output : Markdown pour la machine, HTML pour l'humain

L'idée est simple. Quand mon IA produit quelque chose que je dois lire et valider — une spec, un plan, une synthèse de recherche, un architectural decision record — elle produit deux outputs.

Le premier est Markdown. Il va dans le codebase. Il est versionné, cherchable, structuré pour que l'IA le lise dans les sessions futures. La copie de la machine.

Le second est HTML. Même contenu, rendu comme un document visuel. Titres, callouts, tableaux comparatifs, arbres de décision, évaluations de risque couleur-codées. Conçu pour qu'un cerveau humain fatigué ait effectivement envie de le lire.

Ça ressemble à une petite optimisation. Ça ne l'est pas. Ça retire la friction qui cause la vérification sautée. Quand l'output est agréable à lire, tu le lis. Quand tu le lis, tu rattrapes le truc que l'IA a manqué. Quand tu le rattrapes, tu le corriges. La boucle reste fermée.

Ce changement seul a fait plus pour mon workflow que tout ce que j'ai essayé cette année. L'output Markdown que je survolais est devenu des outputs HTML que je lis réellement. Lire, c'est la différence entre déléguer la pensée et l'étendre.

HTML casting pour les équipes

Si tu travailles solo, le pattern du double output vaut déjà le coup d'être adopté. Si tu travailles en équipe, il devient transformateur.

Voici ce que j'ai construit. Ça s'appelle Briefcast, et c'est un outil mortellement simple. Un agent produit un output HTML. Il fait un appel API. Le HTML devient un lien partageable, protégé par un mot de passe, que n'importe qui dans l'équipe peut ouvrir instantanément.

Plus de fichiers Markdown baladés dans Slack. Plus de « tu peux regarder cette spec » suivi de 50 lignes de texte brut. Juste un lien qui ouvre un document propre et lisible dans le navigateur.

Ça compte parce que la prise de décision en équipe requiert de la compréhension partagée. Si seule la personne qui a prompté l'IA lit l'output, tu as un point unique de dette cognitive. Si tout le monde peut lire la spec, l'analyse, le plan, dans un format qui ne les punit pas pour s'y engager, l'équipe reste alignée.

L'outil est ouvert et gratuit. Il m'a pris un après-midi à construire. Les agents avec qui je travaille uploadent dedans par défaut maintenant. Ça a retiré la dernière excuse pour ne pas lire.

La cérémonie : décider, puis exécuter

Une fois que tu as des outputs lisibles et un moyen de les partager, un rythme naturel émerge. J'y pense comme au modèle du CEO, même si ça marche tout aussi bien si tu es développeur solo.

Tu es le décideur. Tes agents IA sont tes analystes. Leur boulot n'est pas de livrer du code. Leur boulot, dans la première phase, est de produire de la compréhension.

Tu identifies un problème. Une fonctionnalité à construire. Un bug dont tu n'as pas trouvé la cause racine. Une décision architecturale avec plusieurs chemins valides. Tu charges un agent avec de l'analyse, pas de l'implémentation. Il revient avec une spec, un document de recherche, une analyse de tradeoffs, un plan.

Maintenant la cérémonie. Tu le lis. Pas le survoler. Le lire, dans le format HTML qui rend la lecture agréable. Tu donnes du feedback. Tu challenges les hypothèses. Tu demandes des alternatives. L'agent révise. Tu relis. Tu approuves.

C'est seulement alors que tu remets le plan approuvé à un agent pour implémentation. Et quand l'implémentation revient, tu sais déjà à quoi t'attendre. Parce que tu as conçu le plan. L'IA l'a exécuté, mais la pensée était tienne.

C'est l'opposé de la psychose IA que Hashimoto décrit. Ses ingénieurs sont en train de spectater pendant que l'IA opère sur leur codebase. Dans ce modèle, l'humain prend chaque décision qui mérite d'être prise. L'IA gère l'exploration, le drafting, l'exécution. Mais l'humain ne quitte jamais la boucle.

L'écart entre intention et réception

Il y a un concept auquel je reviens souvent. Quand j'écris du code, j'ai l'intention qu'il fasse quelque chose de spécifique. Quand l'IA lit mon codebase, elle reçoit quelque chose de différent de ce que j'ai intentionné, parce qu'elle voit des motifs auxquels je suis aveugle. Quand l'IA écrit du code, elle a l'intention d'une solution. Quand je le lis, je reçois quelque chose que je dois interpréter.

Cet écart, c'est là que vit le travail. Si tu le réduis — si tu acceptes juste l'output sans le lire — l'écart s'élargit en silence. Chaque lecture sautée ajoute de la distance entre ce que tu penses que ton système fait et ce qu'il fait vraiment. Au bout du compte, tu n'es plus la personne qui comprend ton propre produit.

La psychose IA de Hashimoto, c'est cet écart, vu d'en haut.

Les pratiques que je décris dans ce texte, le mindset du tulpa, le double output, l'HTML casting, la cérémonie décider-puis-exécuter, servent toutes le même but. Elles gardent l'écart petit. Elles te gardent dans la pièce avec tes propres décisions. Elles empêchent la dérive lente vers la dette cognitive dont Hashimoto avertit.

Le remède est une posture

Je ne dis pas d'utiliser moins l'IA. Je dis d'utiliser l'IA différemment.

Les développeurs qui réussissent avec l'IA ne sont pas ceux qui écrivent les prompts les plus malins. Ce sont ceux qui ont trouvé une posture. Ils traitent l'IA comme une extension de la pensée, pas comme un remplacement. Ils construisent des systèmes qui rendent la bonne chose — lire, vérifier, décider — la chose facile. Ils restent présents dans la boucle parce que l'alternative, c'est construire quelque chose qu'ils ne comprennent plus.

Le tulpa m'a appris ça. Une forme-pensée, connectée à son créateur, à laquelle on donne assez d'autonomie pour être utile mais jamais assez pour prendre le volant. C'est la relation à laquelle je vise, et le seul remède que j'aie trouvé qui marche vraiment.

Si Hashimoto a raison, et que des entreprises entières dérivent vers une dette cognitive qu'elles ne peuvent pas voir, alors les développeurs qui gardent la boucle fermée aujourd'hui comprendront encore leurs propres systèmes dans deux ans, quand les autres regarderont des codebases qu'ils ne reconnaissent plus.

---

L'outil d'HTML casting que j'utilise, Briefcast, est gratuit et ouvert. Si tu veux essayer le pattern double-output avec tes propres agents IA, ça prend cinq minutes à setup. Tu configures un mot de passe team-wide, et chaque cast obtient son propre lien unique. Tes agents POSTent juste leur HTML à l'endpoint d'upload, et ton équipe le lit dans le navigateur au lieu de plisser les yeux sur du Markdown brut dans Slack.