Ne défendez plus votre avantage concurrentiel avec des documents internes (3/5)

La plupart des produits IA protègent leur avantage avec des documents internes qui se périment en silence dès qu'arrive un ingénieur junior ou une refonte écrite à minuit. Je défends le mien avec deux contrôles intraitables, lancés à chaque commit : le premier casse le build si je livre un jour ce que j'avais juré de ne jamais construire ; le second fait échouer le wiki si je laisse une leçon chèrement payée devenir introuvable ou contradictoire. Les deux sont scellés dans la même chaîne HMAC. C'est le seul avantage qui avance vraiment à cliquet : chaque refus et chaque leçon rendent le système strictement plus difficile à faire régresser, et strictement plus utile avec le temps.

Deux scripts tournent à chaque commit.

Le premier passe toute la base de code au grep, à la recherche de ce que j'ai juré de ne jamais livrer : évaluateurs d'expressions dynamiques, outils capables de renvoyer la valeur d'un secret, modules d'appel direct aux fournisseurs, le trio fatal de l'exfiltration agentique. Qu'un seul réapparaisse, et le build casse net.

Le second parcourt le wiki et pose la question inverse : qu'est-ce qui devrait s'y trouver et ne s'y trouve pas ? Une affirmation sans source, une page de concept vers laquelle aucun lien ne pointe, deux pages écrites à des mois d'intervalle qui se contredisent. Le premier script empêche le système de devenir une CVE ; le second l'empêche d'oublier ce qu'il a déjà appris.

J'ai construit lodos autour d'une règle unique : tout refus qui compte devient un grep exécuté au build, et toute connaissance qui compte devient une page versionnée et interrogeable.

Les deux vivent dans une chaîne HMAC qui se brise à grand bruit dès qu'on touche à quoi que ce soit. Écrivez ce que vous refusez d'ajouter, écrivez ce que vous refusez d'oublier, puis faites en sorte que le build refuse de livrer sans les deux. La plupart des produits IA écrivent ce qu'ils veulent devenir et le défendent avec un document. Une minorité écrit ce qu'elle refuse de devenir et le défend avec du code. Plus rares encore sont ceux qui écrivent aussi ce qu'ils refusent d'oublier et le défendent avec un wiki qui échoue à son propre contrôle d'intégrité dès qu'une page dérive. Ceux-là construisent le seul avantage qui produise des intérêts composés.

Ce qui se dégrade et ce qui résiste

Un avantage couché sur le papier meurt sans bruit. « Nous ne journalisons jamais les secrets. » « Chaque sortie d'outil passe par un bac à sable. » « Nous validons avant que le LLM ne voie quoi que ce soit. » Ces phrases vivent dans les dossiers SOC 2 et sont vraies le jour où on les écrit. Puis un ingénieur junior ajoute une trace de débogage. Une refonte déplace la fonction de nettoyage derrière un feature flag. La phrase, elle, ne bouge pas ; le système, lui, ne lui ressemble plus. Rien ne casse. Personne ne s'en aperçoit.

L'avantage tiré de la connaissance se dégrade encore plus vite. À 2 heures du matin, un fondateur comprend enfin pourquoi un client est parti ; il jette l'intuition dans un fil Slack et l'oublie en moins d'une semaine. La leçon n'existe nulle part où l'on puisse l'interroger. Trois mois plus tard, le même schéma revient et il repaie exactement la même facture. C'est la dégradation la plus coûteuse, parce qu'il ne sait même pas qu'elle a lieu.

Les deux pannes appellent le même remède : arrimer la règle à un mécanisme qui casse en même temps qu'elle. Le build casse dès qu'un refus régresse. Le wiki échoue à son propre lint dès qu'une page devient orpheline, s'éloigne de son sujet ou se contredit. Le correctif n'est pas un processus : c'est un contrôle que le système exécute contre lui-même, à chaque passage, sans exception.

Le modèle Karpathy, version commerciale

La moitié « connaissance » n'a rien d'original. Andrej Karpathy a décrit un wiki pour LLM en trois opérations, avec une thèse : le wiki est l'exécutable, les sources brutes sont le code source, le LLM est le compilateur, le lint tient lieu de tests et les requêtes sont l'exécution.

J'ai repris le modèle, en m'en écartant sciemment sur trois points.

• Le stockage. Karpathy s'appuie sur un dossier de fichiers markdown et sur git ; j'utilise SQLite et un coffre-fort chiffré section par section. J'échange l'interopérabilité contre la confidentialité, et un export markdown propre me laisse la porte ouverte vers Obsidian le jour où j'en aurai envie.
• L'autonomie. Chez Karpathy, le LLM écrit directement ; chez moi, chaque modification passe par une fenêtre de comparaison où je valide ou je rejette, et l'agent ne touche jamais à la page canonique. Cela me coûte cinq à dix secondes par validation ; en échange, aucun agent ne réécrit mon comportement à mon insu.
• L'audit. Karpathy tient un simple journal en markdown ; je tiens une chaîne HMAC signée avec une sous-clé dérivée du mot de passe maître. Un journal retouché se trahit au démarrage suivant, par une rupture de chaîne.

Ce ne sont pas des querelles de principe, mais l'adaptation commerciale d'un modèle conçu pour la connaissance personnelle : l'esprit reste intact, et le prix devient celui qu'un acheteur soumis à la conformité accepte de payer.

Les deux versants avancent au même cliquet

Le versant refus et le versant connaissance ont exactement la même forme : l'un cherche ce qui ne doit jamais exister, l'autre ce qui ne doit jamais manquer. Dans les deux cas, on vérifie une absence ; dans les deux cas, l'échec est visible ; dans les deux cas, tout finit dans la même chaîne HMAC.

Quand je pose une question au wiki et que la réponse tient la route, l'interface propose de l'enregistrer comme page, en un clic. Si j'accepte, la réponse devient durable : la session suivante la retrouve, et la question ne se repose plus jamais. L'indicateur que je surveille, c'est la part des réponses que j'enregistre ; elle augmente avec le temps. Le wiki est la seule partie du système qui devienne strictement plus solide à mesure que je m'en sers.

Le versant refus obéit à la même mécanique. Chaque fonctionnalité qui menace un invariant arrive avec un nouvel invariant inscrit dans le script de vérification ; celui-ci est passé de sept contrôles à trente-deux en huit mois. Chaque capacité est livrée avec le grep qui referme sa propre classe d'abus. À chaque livraison, la base de code interdit strictement plus de choses qu'avant.

La plupart des équipes voient là deux sujets distincts. C'est la même discipline appliquée à deux absences : ce qui ne doit jamais exister, et ce qui ne doit jamais être oublié.

Ce que ça coûte, et pourquoi ce coût est le sujet

Je perds de la vitesse précisément sur les fonctionnalités qui se heurtent aux refus et sur les réécritures qui contourneraient le wiki. Un utilisateur avancé réclame un évaluateur d'expressions en ligne : refusé. Un client réclame un outil qui renvoie la valeur d'un secret : refusé. Le moi de l'an prochain sera tenté d'arracher la boucle de validation parce qu'elle donne une impression de lenteur ; le build l'en empêchera.

Mes notes de version ne ressemblent à celles d'aucun concurrent : elles nomment les refus aussi souvent que les nouveautés. Impossible d'en tirer un récit de croissance bien lisse, car il faudrait taire tout ce que j'ai délibérément refusé de construire.

Ce que j'y gagne ne tient pas sur une page de vente : ça se joue dans un entretien commercial avec un acheteur d'un secteur réglementé. Cet acheteur n'entend pas « nous ne pouvons pas » comme il entend « nous promettons de ne pas le faire ». Un responsable conformité ne traite pas de la même façon une chaîne HMAC dont la moindre retouche se voit et un simple journal en markdown. Quant au fondateur qui alimente son wiki aujourd'hui, il écrit pour celui qu'il sera dans six mois. On n'atteint aucune de ces personnes avec une promesse marketing.

Cinq pièces à voler

Aucune n'a besoin des autres. Ensemble, elles forment le modèle.

1. Un moteur de workflow déclaratif, sans le moindre évaluateur d'expressions.
2. Un coffre-fort scindé en deux espaces de stockage, où l'IA est structurellement incapable de renvoyer un secret en clair.
3. Un script d'invariants exécuté au build, écrit selon la discipline de la preuve par la négative.
4. Un wiki qui met en œuvre les trois opérations de Karpathy et enferme son journal dans une chaîne HMAC.
5. Une boucle d'apprentissage limitée à la proposition, où l'agent n'écrit jamais son propre comportement.

Prenez-les dans l'ordre qui vous arrange. Leur seul point commun est la discipline : écrire ce que vous refusez de livrer et ce que vous refusez d'oublier, faire contrôler les deux par le build, puis prouver les contrôles en tentant délibérément de les violer. Le reste n'est que de l'ingénierie.

La suite

La dernière boucle est celle qui m'a demandé le plus de temps. L'agent suit la conversation, repère les moments où son propre catalogue de compétences gagnerait à changer, et propose une modification. J'approuve ou je rejette. Cette modification emprunte la même fenêtre de comparaison que n'importe quelle proposition de page, et l'agent n'écrit jamais son propre comportement. Le véritable avantage se joue là, dans ce point de passage obligé entre la proposition et la validation. Le prochain article raconte cette boucle, et ce court passage du prompt de disposition qui a justifié à lui seul tout le travail d'ingénierie.

Rejoindre la liste d'attente