Revue de code en CI

Une quality gate dans votre CI,
en place avant votre café.

Chaque pull request contrôlée au regard de votre playbook — depuis GitHub Actions ou GitLab CI, sans rien à installer et sans rien à qui faire confiance en dehors de votre propre pipeline.

# The whole integration — GitHub Actions or GitLab CI
- run: |
    git diff "origin/main...HEAD" |
    curl -sS --fail-with-body -X POST "$NORMIK_URL/api/ci/gate" \
      -H "Authorization: Bearer $NORMIK_TOKEN" --data-binary @-

Un seul job. C'est toute l'installation.

Aucune GitHub App à autoriser, aucun webhook à router, aucun compte bot à gérer. Votre CI envoie le diff à Normik avec un token de workspace ; le code de statut HTTP porte le verdict — 422 bloque le merge, 200 le laisse passer.

Des commentaires sans application

Sur GitHub Actions, le job publie le résumé des violations en commentaire de pull request avec son propre GITHUB_TOKEN. Sur GitLab, le même résumé devient une note de merge request dès que vous fournissez un token de projet — le job token intégré de GitLab n'a pas le droit d'écrire de note. Vos reviewers voient le chemin, la ligne, la sévérité et la règle enfreinte — dans la revue, pas dans un log de CI.

Fail-open, volontairement

Si votre clé API manque ou si le provider du modèle est en panne, le check passe et en explique la raison. Une quality gate doit arrêter le code non conforme, jamais prendre vos livraisons en otage à cause d'un incident chez un tiers. La nôtre en est incapable : elle est fail-open par conception.

Seules les vraies violations bloquent

La sévérité fait partie de chaque règle : error bloque le merge, warning et info remontent sans bloquer. Et Normik ne signale que des lignes réellement ajoutées dans le diff — un modèle ne peut pas halluciner une violation sur du code auquel vous n'avez pas touché.

Votre code ne fait que passer

Le diff est analysé en mémoire sur votre propre clé API et n'est jamais stocké. Ce que nous conservons, c'est le résultat : quelles règles ont été contrôlées, ce qui a été enfreint, à quelle ligne — la matière première de votre dashboard de conformité.

Chaque contrôle, tracé

Chaque exécution est consignée dans l'historique des analyses avec ses violations, alimente le taux de conformité, et sa consommation de tokens est suivie par provider. La gouvernance a besoin de preuves.

Les règles derrière la gate vivent dans votre playbook — et vos agents peuvent corriger les violations avant le commit.

Contrôlez votre prochaine pull request. Un seul job CI suffit.

Commencer gratuitement — sans carte bancaire

Une quality gate dans votre CI,en place avant votre café.