Bibliothèque de playbooks
Des playbooks de départ, écrits pour être applicables.
Un playbook vide ne vaut rien le premier jour. Ce sont des points de départ assumés — chaque règle ici est assez précise pour qu'un reviewer senior puisse la juger conforme ou non à partir des lignes qu'une pull request ajoute, c'est-à-dire exactement ce que Normik voit.
Ce niveau d'exigence élimine des choses. « Expliquez dans la description pourquoi vous avez ajouté cette dépendance » et « ne modifiez jamais une migration déjà passée » sont de bons standards de revue, et aucun des deux n'est dans cette bibliothèque : la gate lit les lignes ajoutées, pas les descriptions de PR ni l'historique d'un fichier — elle ne pourrait donc que rester muette ou deviner. Ces standards-là méritent d'être écrits — dans votre checklist de revue, pas comme une règle de gate qui bloque un merge.
Ce n'est pas une loi universelle. Certaines de ces règles seront mauvaises pour votre codebase, et une ou deux le seront pour tout le monde. Prenez-les comme le premier jet d'un argumentaire, pas comme un standard à respecter.
Socle de sécurité des API
Les règles de frontière que le CRUD généré oublie systématiquement.
Les équipes qui livrent des API HTTP — Node, Python, Go, quel que soit le framework.
10 règles6 error4 warning
Conventions Next.js App Router
La discipline de la frontière serveur/client, là où le code généré fuit le plus.
Les équipes produit sur Next.js 14+ avec l'App Router.
11 règles4 error6 warning1 info
Terraform et infrastructure as code
Les règles pour les diffs où un oubli en revue supprime une base de données.
Les équipes plateforme et infrastructure qui relisent des pull requests Terraform ou OpenTofu.
10 règles6 error2 warning2 info
Service back-end TypeScript
L'honnêteté à l'exécution : des types réellement vérifiés, des erreurs réellement traitées.
Les équipes qui exploitent des services Node/TypeScript — serveurs d'API, workers, jobs.
11 règles6 error4 warning1 info
Migrations de base et changements de schéma
Les règles zéro interruption pour les PR qui verrouillent une table en pleine heure de pointe.
Les équipes qui déploient en rolling update sur une base Postgres ou MySQL en production.
11 règles6 error3 warning2 info
Isolation des données multi-tenant
La seule classe de bugs où un filtre oublié se solde par une notification de violation de données.
Les équipes SaaS dont une seule base sert de nombreux clients — y compris les agences qui gèrent des workspaces clients.
10 règles7 error3 warning
Garde-fous pour le code généré par IA
Les modes de défaillance propres au code écrit par un agent.
Toute équipe où les agents (Claude Code, Cursor, Copilot) écrivent une part significative du diff.
10 règles4 error5 warning1 info
Comment les utiliser
Importer un playbook en bloc est le moyen le plus rapide de faire détester la gate à votre équipe. Les trois étapes ci-dessous font la différence entre un playbook que l'on maintient et un playbook que l'on contourne.
01
Prenez celles dont vous débattriez vraiment
Une règle mérite sa place quand une violation changerait réellement votre avis en revue. Copiez celles qui correspondent à une discussion que votre équipe a en boucle, et laissez le reste — une règle à laquelle personne ne croit ne produit que du bruit, que l'équipe apprend à ignorer.
02
Réécrivez-les avec vos mots
Remplacez nos chemins d'exemple par les vôtres, nommez vos vrais modules partagés et dites pourquoi la règle existe dans votre codebase. Le modèle juge mieux quand l'énoncé porte votre intention plutôt qu'une intention générique.
03
Démarrez avec moins de règles bloquantes que prévu
Seule la sévérité error bloque un merge. Importez un playbook majoritairement en warning, observez quelques semaines de vraies pull requests, puis promouvez les règles qui se sont révélées utiles. Une gate qui bloque dès le premier jour est désactivée la deuxième semaine.
Ce qui sépare une règle qui fonctionne d'une règle qui génère du bruit est détaillé dans la documentation du playbook. Vous pouvez aussi pointer un agent de code vers un repo existant et laisser Normik rédiger des règles à partir de ce qu'il y trouve — elles arrivent en attente de revue humaine, jamais actives d'elles-mêmes.
Vous voulez voir l'une de ces règles se déclencher sur du vrai code avant de créer un compte ? La sandbox lance une analyse en direct sur un extrait que vous collez, ou créez un compte gratuit et ajoutez les règles que vous avez retenues — une par une, ou rédigées pour vous à partir d'un repo vers lequel vous pointez un agent.