gap-trap — Le portique de sécurité du code que personne ne relit

État des lieux

Il existe un aveu que la plupart des outils d'IA n'osent pas faire. gap-trap, lui, le pose noir sur blanc dès le README : « The rules are text, and the only thing that reads them is the agent that breaks them. » Traduction : vos belles intentions, écrites dans un fichier d'instructions, ne sont lues que par l'agent chargé de les violer. Quand un agent écrit l'essentiel du code, personne ne relit chaque diff, la qualité dérive, et la dérive prend toujours les mêmes formes — l'utilitaire qui existe déjà, la frontière de couche franchie parce que le raccourci compilait, le test qui vérifie que le code s'est exécuté plutôt que ce qu'il fait.

gap-trap n'est pas un outil qu'on ouvre : c'est une compétence d'agent, un dossier de fichiers Markdown et de scripts, publiée le 13 septembre 2026 par Pliable Pixels, le développeur historique de l'écosystème ZoneMinder (compte GitHub ouvert en 2013, bio « I code like a Kindergarten »). Elle est l'extraction directe d'un projet réel : zmNinjaNg, le client ZoneMinder réécrit en TypeScript, où un unique mainteneur a fait atterrir 2 313 commits et 14 annulations en huit mois, des agents écrivant tout le code sans relecture de diff. À 58 étoiles, 14 commits et zéro release, le dépôt a deux jours d'existence à la date du dossier.

La carte des menus

Ici, le menu est court : gratuit, sans compte, sans hébergement, licence MIT. L'installation passe par npx skills add pliablepixels/gap-trap (le CLI skills de Vercel Labs, 31 654 étoiles) ou par une copie manuelle dans ~/.claude/skills/. Aucune page de tarifs, aucune société, aucune levée de fonds — un contraste net avec les lancements Product Hunt qui remplissent la même veille.

En revanche, l'addition se paie ailleurs : le verrou de modèle. La compétence refuse de démarrer si le modèle n'est pas de classe Opus (Opus 4.8+, Opus 5, Fable, Mythos). Sonnet, Haiku et tout ce qui est en dessous : arrêt immédiat, message imposé mot pour mot, et interdiction explicite des contournements — pas de sous-agents Opus dépêchés depuis un orchestrateur plus petit, pas de « on commence par les parties faciles », pas de version allégée. L'auteur assume : la phase de découverte écrit des contrats, et un mauvais contrat se paie à chaque session ultérieure.

Ce que la bête sait vraiment faire

Le dispositif installe quatre artefacts une seule fois dans le dépôt. Les contrats : une entrée par sous-système (HTTP, journalisation, configuration, authentification), tenant en quatre lignes — ce que le sous-système possède, le chemin unique à emprunter, ce qu'il ne faut jamais utiliser même si ça marche, et la barrière qui vérifie. Le proven red : une tâche de CI qui exécute les tests ajoutés contre le code d'avant la modification, et échoue s'ils passent aussi — un test qui ne peut pas échouer ne prouve rien. Les ratchets : des compteurs de problèmes connus qui peuvent baisser, jamais monter. Les playbooks : les faits appris à ses dépens, pour que la session suivante n'ait pas à les réapprendre.

S'y ajoutent six familles de barrières : la barrière de grep (un test qui scanne le code à la recherche d'un motif interdit), la barrière d'instructions (pas de noms de projet dans les fichiers d'instructions, budget de mots respecté, empreintes de commit citées réellement existantes, pas d'adresse électronique qui traîne), le ratchet, le proven red, le test de mutation (on inverse une branche dans un module sensible et on exige que ses tests échouent) et la vérification du corps de la pull request.

Le support multi-langage est concret : Node et Python obtiennent des barrières natives qui tournent avec npm test ou pytest ; Go, Rust, Java, Ruby, .NET, PHP, Swift et C++ reçoivent des versions shell qui ne réclament que git, grep, awk et la commande de test du dépôt. La règle M2 résume l'esprit : « read what a gate measured, not only its exit code. A job that skips itself is green. »

Les couleuvres à avaler

La première couleuvre est la plus grosse : deux jours d'existence, quatorze commits, zéro release, zéro tag, un contributeur, un watcher, deux forks. Le facteur de bus vaut 1. npx skills add récupère ce qui est là, sans épinglage possible.

La seconde : n = 1. Les 2 313 commits, les 14 annulations et la moyenne de 7,9 sur 10 sont des auto-déclarations de l'auteur sur son propre projet. Aucune évaluation tierce n'existe, et le seul chiffre de performance (une minute pour 4 400 tests, un build et trois lints) porte sur le dépôt d'origine, pas sur un dépôt nouvellement équipé.

La troisième : le verrou de modèle est un coût tarifaire autant que technique, qui exclut les modèles économiques et les petits dépôts. La quatrième : la charge d'installation est lourde pour un dépôt sain — quatre artefacts, six familles de barrières, un fichier de contrat par sous-système. Sur un petit dépôt, c'est plus de machinerie que de code. La documentation le reconnaît elle-même.

Enfin, pas un produit, une pratique : ni interface, ni compte, ni hébergement. Et une communauté inexistante — pas d'issues, pas de Hacker News, pas de Reddit, un unique relais dans une newsletter d'actualité allemande.

Verdict

gap-trap est le cadre le plus honnête sur le sujet le plus tabou du vibe coding : ce que devient la qualité quand plus personne ne relit. Il ne vend pas une IA de plus, il vend une règle vérifiable — « une règle qu'on peut vérifier par script et qui ne désigne aucune barrière est un défaut » — tirée d'un dépôt de 2 939 commits plutôt que d'un article de blog. Mais c'est un chantier au portique de sécurité encore neuf, calibré sur un projet, un langage et un mainteneur, et qui refuse les modèles économiques. À prendre comme une pratique à surveiller, pas comme un produit à installer les yeux fermés.