# Analysez chaque version ou déploiement depuis votre CI

Lancez une analyse Pulse ou Deep de votre site à chaque publication ou déploiement, depuis GitHub Actions, Vercel, GitLab, Bitbucket, CircleCI ou un script de déploiement.

Cette page s'adresse à la personne qui construit et publie votre site. Si ce n'est pas vous, envoyez-lui le lien.

Une analyse de version s'exécute là d'où votre site est livré. Elle lance une analyse Pulse (ou Deep) de votre site, attend le résultat, le signale et bloque la publication lorsque l'analyse trouve quelque chose au niveau de gravité que vous avez choisi, ou plus grave. Votre site en ligne continue de fonctionner dans tous les cas. Chaque analyse de version utilise une analyse de votre quota mensuel, avec les mêmes limites et les mêmes vérifications de propriété qu'une analyse que vous lancez dans Lockpick. Comptez donc la fréquence de vos publications.

## Configurer

1. Ouvrez votre site dans Lockpick, choisissez **Paramètres**, puis **Configurer les scans de version**.
2. Créez une **clé CI**. Copiez-la tout de suite : Lockpick ne l'affiche qu'une fois.
3. Enregistrez-la dans les secrets de votre CI sous le nom `LOCKPICK_CI_KEY`.
4. Ouvrez la configuration de l'endroit où votre site est livré sur la page Scans de version, et copiez-la dans votre dépôt. Elle indique déjà votre site.

> **Careful**
>
> Gardez la clé dans le coffre de secrets de votre CI, jamais dans un fichier de
> votre dépôt. Quiconque possède la clé peut lancer des analyses de votre site, qui
> utilisent votre quota.

## Où cela s'exécute

| Où vous livrez                 | Quand il analyse                                           | Où va la clé                                                  |
| ------------------------------ | ---------------------------------------------------------- | ------------------------------------------------------------- |
| GitHub Actions                 | Lors de la publication d'une version, ou à la main         | Secret de dépôt `LOCKPICK_CI_KEY`                             |
| Vercel                         | Après chaque déploiement en production, ou à la main       | Secret de dépôt `LOCKPICK_CI_KEY`                             |
| GitLab CI                      | Pour les tags, après vos autres étapes, ou à la main       | Variable CI/CD masquée `LOCKPICK_CI_KEY`                      |
| Bitbucket Pipelines            | Pour les tags de version, ou à la main                     | Variable de dépôt sécurisée `LOCKPICK_CI_KEY`                 |
| CircleCI                       | Pour les tags de version                                   | Variable d'environnement du projet `LOCKPICK_CI_KEY`          |
| Fly.io, Railway, Render, autre | À la fin de votre script de déploiement ou de votre job CI | Variable d'environnement `LOCKPICK_CI_KEY` depuis vos secrets |

### GitHub Actions

Copiez l'action dans `.github/actions/lockpick-scan/` avec les deux commandes de la page Scans de version, puis ajoutez le workflow. Publiez une version, ou lancez le workflow depuis l'onglet **Actions**, et l'analyse démarre. Le résumé du job affiche le résultat.

### Vercel

Lorsque votre projet Vercel est connecté à un dépôt GitHub, Vercel prévient GitHub de chaque déploiement. Le workflow Vercel écoute ces événements et analyse après chaque déploiement en **production**, jamais les aperçus. Il faut aussi copier l'action dans le dépôt, et Vercel n'envoie ces événements qu'aux workflows de votre branche par défaut.

Chaque déploiement en production utilise une analyse de votre quota. Choisissez donc cette option seulement si vous déployez en production quelques fois par mois. Sinon, analysez plutôt lors des publications.

### GitLab, Bitbucket, CircleCI et scripts de déploiement

Ceux-ci exécutent le même script d'analyse avec Node 20 ou plus récent. La configuration télécharge le script depuis Lockpick et définit `LOCKPICK_SITE_ID`, `LOCKPICK_SCAN`, `LOCKPICK_FAIL_ON` et `LOCKPICK_API_URL` ; la clé vient de `LOCKPICK_CI_KEY`. Le script affiche le résumé dans le journal du job et se termine avec le code 1 lorsque l'analyse échoue, ce qui arrête votre pipeline à cet endroit. C'est le contrat du script autonome : la CLI utilise le code de sortie 8 pour un seuil de constats. Voir le [tableau de comparaison](/fr/docs/cli/ci#cli-and-release-scan-script-exit-codes).

Fly.io n'a pas de notifications de déploiement, et les déploiements Railway et Render passent généralement par un job CI ou un script. Ajoutez donc le script après votre commande de déploiement (par exemple `fly deploy` ou `railway up`).

Si vous utilisez déjà la CLI Lockpick, `lockpick pulse <site> --fail-on high` fonctionne aussi avec une clé CI, à condition de placer la clé dans `LOCKPICK_KEY`. Elle ne lance que Pulse.

## Ce que peut faire une clé CI

Une clé CI ne fonctionne que pour un seul site. Elle peut lancer une analyse Pulse, lancer une analyse Deep si vous l'avez autorisé, et lire ces analyses. Elle ne peut pas voir vos autres sites, en ajouter ni modifier quoi que ce soit dans Lockpick.

Une clé CI expire à la date que vous choisissez lors de sa création (30, 90, 180 ou 365 jours), qu'elle soit utilisée ou non. La page Scans de version indique quand chaque clé a été utilisée pour la dernière fois et quand elle expire. Révoquez une clé sur cette page, et chaque pipeline qui l'utilise s'arrête immédiatement. Une clé cesse aussi de fonctionner si la personne qui l'a créée perd l'accès au site.

## Analyses Deep depuis une version

Cochez **Deep aussi** lorsque vous créez la clé pour utiliser Deep en CI, puis cochez **J’approuve les analyses Deep de votre site lancées avec cette clé**. Cocher cette case vaut votre approbation pour les analyses Deep de ce site lancées avec cette clé, si bien que la CI n'attend jamais que vous approuviez chacune d'elles. Chaque analyse Deep exige encore :

* Deep dans votre forfait, et Deep encore disponible dans votre quota ;
* [une preuve que vous possédez le site](/fr/docs/protect/prove-you-own-your-site), avec l'enregistrement toujours publié au démarrage de l'analyse.

Ensuite, réglez `scan: deep` dans le workflow GitHub (ou choisissez **deep** lorsque vous le lancez à la main), ou `LOCKPICK_SCAN=deep` partout ailleurs.

## Lorsque le job échoue

Le job échoue lorsque :

* des constats ouverts sont au niveau de `fail-on` ou au-dessus (`high` par défaut ; choisissez `critical`, `medium`, `low` ou `none`) ;
* l'analyse a échoué, a été annulée, ou tourne encore après la limite de temps (l'analyse continue dans Lockpick) ;
* Lockpick n'a pas pu lancer l'analyse, par exemple parce qu'il ne reste plus d'analyses ce mois-ci, que Deep n'est pas autorisé, que la propriété n'est pas prouvée, ou que la clé a expiré. Le job indique pourquoi et quoi faire.

Le résumé affiche la note, les constats ouverts par gravité et un lien vers l'analyse, où chaque constat indique sa correction. Il ne copie jamais les détails des constats dans vos journaux. Une analyse qui n'a pas pu tout examiner est jugée sur ce qu'elle a vu, et le résumé indique que certains domaines sont inconnus.

Relancer le même pipeline réutilise son analyse au lieu d'en lancer une autre. Cela fonctionne sur GitHub Actions, GitLab CI, Bitbucket Pipelines et CircleCI. Un déploiement Vercel est analysé une seule fois, quel que soit le nombre de fois où son événement arrive.

Une analyse de version réussie n'est pas une certification de sécurité. La couverture que Lockpick n'a pas pu évaluer est inconnue, et non réussie.