Perimetry Cloud dans votre intégration continue

Lancer un audit après chaque déploiement et faire échouer la tâche si la note baisse ou si un constat critique apparaît : GitHub, GitLab et les autres.

Mis à jour le

À partir de l’offre Solo, Perimetry Cloud peut arrêter un déploiement qui rend votre domaine moins sûr. Après chaque déploiement, votre intégration continue lance un audit du domaine (ou lit le dernier), attend le résultat, et fait échouer la tâche quand la note passe sous un minimum, quand elle baisse depuis l’audit précédent, ou quand un nouveau constat critique apparaît. Un résumé lisible s’affiche sur la page de la tâche, et le résultat en JSON va dans un fichier.

Cela marche avec l’action GitHub, ou avec la commande perimetry-ci dans toute autre intégration continue (GitLab, Bitbucket, Jenkins, CircleCI…).

L’action GitHub est disponible : Enigmacker/perimetry-cloud-action. Pour la garantie la plus forte, épinglez-la sur l’empreinte complète d’un commit plutôt que sur @v1. La commande perimetry-ci pour les autres outils n’est pas encore sur npm : d’ici là, l’API seule permet de contrôler un déploiement, voyez Toute autre intégration continue.

Mettre en place sur GitHub

  1. Dans Perimetry Cloud, ouvrez Réglages, créez une clé d’API nommée « GitHub Actions » et cochez Peut lancer des audits (laissez la case vide si la tâche ne fait que lire le dernier audit).
  2. Dans votre dépôt GitHub, ouvrez Settings › Secrets and variables › Actions et ajoutez la clé comme secret nommé PERIMETRY_API_KEY.
  3. Ajoutez une étape après celle du déploiement, comme dans l’exemple ci-dessous, avec votre domaine prouvé.
- name: Perimetry Cloud
  uses: Enigmacker/perimetry-cloud-action@v1
  with:
    api-key: ${{ secrets.PERIMETRY_API_KEY }}
    domain: example.com
    min-score: 80
    lang: fr

La clé vient du secret et n’est jamais affichée : GitHub la masque dans les journaux, et l’action ne la transmet à la commande que par l’environnement.

Options

Paramètre Par défaut Ce qu’il fait
domain Le domaine prouvé, ou son identifiant.
mode run run lance un audit et l’attend ; latest lit le dernier audit (une clé en lecture seule suffit).
timeout-minutes 15 Combien de temps attendre l’audit.
min-score aucun Échoue quand la note est sous cette valeur (de 0 à 100).
fail-on-drop true Échoue quand la note est plus basse qu’à l’audit précédent.
max-drop 0 Points que la note peut perdre avant que fail-on-drop échoue.
fail-on-new critical Échoue quand un nouveau constat de cette gravité ou plus apparaît (critical, high, medium, low, info ou none).
fail-on-open none Échoue quand un constat ouvert, nouveau ou non, est de cette gravité ou plus.
on-too-soon latest Quand l’offre ne permet pas encore un autre audit à la demande : lire le dernier audit, ou fail pour échouer.
lang en Langue des titres des constats dans le résumé (en ou fr).

Les sorties sont passed, score, grade, previous-score, score-delta, new-findings, report-url et result-file (le résultat en JSON), pour les étapes suivantes.

Ce que vous voyez

Le résumé de la tâche montre la note et la lettre, l’évolution depuis l’audit précédent, les constats ouverts par gravité, les nouveaux constats et les plus graves des constats ouverts avec leur correction, la raison de l’échec s’il y en a un, et un lien vers le rapport. Les titres des constats citent ce que publient vos sites : ils sont affichés comme du texte simple, jamais comme du balisage.

La commande se termine avec le code 0 quand le contrôle passe, 1 quand il échoue, 2 pour une erreur de configuration ou de l’API (mauvaise clé, domaine inconnu), et 3 quand l’audit n’a pas fini à temps (il continue, et son résultat sera sur la page du domaine).

GitLab CI

Ajoutez la clé comme variable CI/CD masquée nommée PERIMETRY_API_KEY, et lancez l’exemple de l’API de la section suivante dans une tâche de l’étape .post (image alpine avec curl et jq, par exemple).

Toute autre intégration continue

Le serveur local et la commande d’intégration continue seront bientôt publiés sur npm ; d’ici là, utilisez le point d’accès MCP distant ou l’API avec curl. L’API seule suffit pour lire le dernier audit et décider (ici avec curl et jq, en échouant sous 80) :

score=$(curl -fsS -H "Authorization: Bearer $PERIMETRY_API_KEY" \
  https://app.perimetry.cloud/api/v1/domains/example.com | jq '.domain.score')
[ "$score" -ge 80 ] || { echo "Note Perimetry Cloud $score sous 80"; exit 1; }

Bon à savoir

  • Les audits à la demande suivent les limites de votre offre : un par heure et par domaine avec Solo, et un toutes les 15 minutes par domaine par l’API. Avec plusieurs déploiements dans l’heure, les tâches suivantes lisent le dernier audit à la place (ou échouent, avec on-too-soon: fail).
  • Un audit prend quelques minutes. Le lancer après le déploiement lui permet de voir la nouvelle version de votre site.
  • Chaque appel compte dans la limite horaire de votre offre ; une tâche en utilise une dizaine.