La question qu'on me pose, c'est « tu demandes quoi à l'IA ? ». Ce n'est pas la bonne. Un bon prompt te donne une bonne réponse, une fois. La session d'après, l'IA a tout oublié : ton projet, tes contraintes, tes règles. Ce qui rend une IA fiable dans la durée, ce n'est pas la formule magique, c'est le cadre que tu lui redonnes à chaque fois.

Ce cadre, ce n'est pas une trouvaille perso : structurer le contexte qu'on donne à une IA, c'est ce que recommandent les guides officiels, sous le nom de context engineering. Même le mot « harnais » n'est pas de moi : Anthropic parle de « harness » pour cadrer ses agents. Moi, j'ai juste construit le mien.

Pas un prompt, un système

Le harnais n'est pas un fichier, c'est plusieurs couches que je réutilise sur chaque projet.

Une constitution. Qui est l'IA pour moi et comment elle travaille : un pair senior, pas un béni-oui-oui ; comprendre avant d'implémenter ; expliquer le pourquoi avant de toucher au code ; le plus petit changement qui règle le problème. Ces règles ne changent pas d'un projet à l'autre, alors je les écris une fois pour toutes.

Un garde-fou sur les commandes qui détruisent. Une consigne écrite, l'IA peut la rater. Alors le garde-fou est mécanique : elle n'a pas le droit de lancer une commande de suppression, et un hook bloque tout rm -rf avant qu'il parte. Le reste, je peux le corriger après coup ; ça, non. C'est le seul rail que je ne laisse jamais au simple texte.

Du contexte, pas du savoir générique. L'IA sait déjà ce qu'est Terraform. Ce qu'elle ignore, c'est mon terrain. Et ce terrain, je l'ai découpé en trois.

Le triple vault

Je sépare mon contexte en trois dépôts, parce que trois choses différentes doivent rester alignées :

  • Ce que je sais (vault de savoir) : mes notes d'apprentissage, les concepts que je maîtrise. C'est le système que j'ai décrit ici.
  • Le cadre dans lequel je bosse (vault de contexte) : le projet, l'organisation, les décisions et leurs raisons. Le « pourquoi » d'un choix, pas juste le « quoi ».
  • La stack technique (vault de code) : les contraintes, ce qui dépend de quoi, ce qu'un changement peut casser.

Les garder séparés me permet de les recombiner : mon savoir, appliqué à mon cadre, sur ma stack. L'IA ne raisonne plus sur un projet moyen, elle raisonne sur le mien.

Nourrir le vault, et le garder propre

Un vault ne vaut que s'il est vivant. Le mien se nourrit et s'entretient en continu, presque comme une hygiène. Pour que ça ne devienne pas une corvée, j'ai automatisé quelques tâches :

  • Ingérer : transformer une source (un article, une décision, un incident) en note atomique, reliée au reste.
  • Récapituler : un point régulier de ce qui a bougé, que j'adapte selon l'outil ou le sujet.
  • Auditer : un passage qui vérifie l'hygiène du vault, repère les liens morts et les notes qui ont dérivé.

Ces trois-là ne sont que des exemples. Dès que je veux automatiser quelque chose, je l'encapsule dans un skill, ou un simple script que l'IA lance. Écrit une fois, réutilisé ensuite, et au passage ça économise des tokens : l'IA exécute le script au lieu de refaire tout le raisonnement à chaque fois.

Mais rien n'entre en pilote automatique. Chaque ajout passe par une relecture que je valide, comme une PR. Ma règle : une note fausse est pire que pas de note. L'automatisation nourrit le système, le jugement reste à moi. Le même principe que pour le code : je délègue l'exécution, pas la validation.

Le harnais apprend de mes corrections

Ce cadre n'est pas figé, et surtout il apprend. Quand je corrige l'IA, la correction ne se perd pas : elle devient une règle qu'elle garde. La bêtise que je lui ai reprise une fois, elle ne la refait pas. Enfin, normalement : elle sait aussi se montrer têtue. Au fil des semaines, elle fait de moins en moins les erreurs que je lui ai déjà signalées. Le cadre se resserre à partir de mes retours, sans que j'aie à tout ré-expliquer.

Plusieurs rôles, jamais le même qui valide

Sur les tâches qui comptent, je n'orchestre pas à la main. J'utilise un agent, mais qui s'appuie sur différents sous-agents : un qui conçoit, un qui exécute, un qui relit. C'est l'agent qui décide de les lancer ; moi, je lui donne les clés. Avec une règle que je tiens du travail en équipe : celui qui produit ne valide jamais. Le sous-agent qui a écrit le changement n'est pas celui qui l'approuve, comme un dev ne relit pas sa propre PR. Ça l'empêche de se donner raison à lui-même, et ça attrape ce qu'un seul passage laisserait filer.

Ce que ça m'a appris

Construire ce harnais m'a forcé à écrire ce que je veux vraiment : mes règles, mon contexte, mes limites. La moitié de la valeur est là, dans cette clarté. On croit configurer une IA, on finit par clarifier sa propre façon de travailler.

Et ce n'est pas parfait. Certaines règles que j'avais posées, je ne les suis pas (je m'étais promis des relectures espacées, je les ai vite lâchées au profit de la pratique). Le harnais n'est pas figé, c'est un truc que j'itère.

Un bon prompt te donne une bonne réponse une fois. Un bon harnais te donne une IA qui travaille comme tu veux, à chaque fois, et que n'importe qui pourrait reprendre. Le mien est public, si tu veux t'en inspirer.