> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corgea.app/llms.txt
> Use this file to discover all available pages before exploring further.

# CLI

> Boostez votre sécurité depuis la ligne de commande

## Introduction

La CLI Corgea est un outil puissant qui aide les développeurs à détecter et à corriger les vulnérabilités de leur code. Grâce à notre scanner optimisé par l’IA (BLAST) et à la plateforme Corgea, elle identifie des problèmes complexes tels que les failles de logique métier, les vulnérabilités d’authentification et d’autres bugs difficiles à repérer. La CLI permet de scanner le code, d’examiner les résultats, d’interagir avec les correctifs et bien plus encore, tout en offrant une excellente expérience développeur.

<Tip>
  **Renforcez les capacités de votre agent de développement IA.** La CLI Corgea sert également de base à nos [intégrations agentiques](/fr/agentic_integrations) : installez l’Agent Skill Corgea et laissez votre agent IA (Cursor, Claude Code, Copilot, etc.) scanner, trier et corriger les vulnérabilités pour vous.
</Tip>

## Fonctionnalités

* **Prise en charge de plusieurs scanners** : scannez avec BLAST, notre scanner optimisé par l’IA, et chargez des rapports Semgrep, Snyk, Checkmarx, CodeQL, Fortify ou Coverity.
* **Gestion des problèmes** : répertoriez, examinez et gérez les résultats de sécurité.
* **Intégration des correctifs** : affichez et appliquez directement depuis le terminal les correctifs de vulnérabilités générés par l’IA.
* **Analyse des dépendances** : créez des inventaires de dépendances hors ligne, examinez les graphes de dépendances, générez des SBOM et évaluez les politiques avec [`corgea deps`](/fr/cli/deps).
* **Consultation des avis de sécurité des paquets** : consultez les avis connus avant de choisir ou d’installer un paquet npm ou PyPI.
* **Contrôle des installations par les gestionnaires de paquets** : avant leur installation, vérifiez et bloquez les paquets vulnérables, malveillants ou trop récents installés avec `npm`, `yarn`, `pnpm`, `pip` ou `uv`. Voir [Contrôle des installations par les gestionnaires de paquets](#package-manager-install-gate).
* **Formats de sortie flexibles** : utilisez une sortie lisible ou JSON pour faciliter les intégrations CI.
* **Intégration CI/CD** : faites échouer les builds selon les niveaux de sévérité ou des règles de blocage personnalisées.
* **Gestion des scans** : suivez la progression et les résultats des scans de vos projets.
* **Installation d’Agent Skills** : installez dans les agents de développement pris en charge les Agent Skills approuvés du registre Corgea.

## Prérequis

* **Compte Corgea** : un compte Corgea actif.
* **Token d’authentification** : un token d’API Corgea ou un token d’accès JWT valide.

Les commandes hors ligne `corgea deps scan`, `graph`, `explain`, `diff`, `sbom` et `policy init` ne nécessitent ni compte Corgea, ni token, ni configuration, ni accès réseau.

## Guide d’installation

### Installer avec npm

```bash theme={null}
npm install -g @corgea/cli
```

Le package npm regroupe les binaires natifs des plateformes prises en charge et sélectionne à l’exécution celui qui correspond à votre système d’exploitation et à votre architecture.

### Installer avec uv

Pour les utilisateurs de Python, il s’agit de la méthode recommandée. `uv tool install` crée à partir du paquet PyPI un environnement isolé pour l’outil et expose la CLI sous le nom `corgea` dans votre `PATH`.

```bash theme={null}
uv tool install corgea-cli
```

Si `uv` signale que son répertoire d’outils ne figure pas dans votre `PATH`, exécutez :

```bash theme={null}
uv tool update-shell
```

### Installer avec pip

Si vous n’utilisez pas `uv`, vous pouvez installer Corgea CLI avec pip, le gestionnaire de paquets Python :

```bash theme={null}
pip install corgea-cli
```

Cette commande télécharge le paquet Corgea CLI depuis PyPI (Python Package Index) et l’installe sur votre système. Pour plus de détails, consultez sa page PyPI : [https://pypi.org/project/corgea-cli/](https://pypi.org/project/corgea-cli/).

### Installer avec Homebrew

Pour installer Corgea CLI avec Homebrew, ajoutez d’abord le tap Corgea, puis installez la CLI :

<CodeGroup>
  ```bash MacOS theme={null}
  brew tap Corgea/cli
  brew install corgea-cli
  ```
</CodeGroup>

### Installer manuellement

Téléchargez l’archive de votre plateforme depuis la [dernière version](https://github.com/Corgea/cli/releases/latest), décompressez-la et placez le binaire `corgea` dans votre `PATH`. Les URL `latest/download` ci-dessous renvoient toujours vers la version la plus récente.

<CodeGroup>
  ```bash macOS (Apple Silicon) theme={null}
  curl -L https://github.com/Corgea/cli/releases/latest/download/corgea-aarch64-apple-darwin.zip -o corgea.zip && unzip corgea.zip
  chmod +x corgea
  sudo mv corgea /usr/local/bin
  ```

  ```bash macOS (Intel) theme={null}
  curl -L https://github.com/Corgea/cli/releases/latest/download/corgea-x86_64-apple-darwin.zip -o corgea.zip && unzip corgea.zip
  chmod +x corgea
  sudo mv corgea /usr/local/bin
  ```

  ```bash Linux (x86_64) theme={null}
  curl -L https://github.com/Corgea/cli/releases/latest/download/corgea-x86_64-unknown-linux-gnu.zip -o corgea.zip && unzip corgea.zip
  chmod +x corgea
  sudo mv corgea /usr/local/bin
  ```

  ```bash Linux (ARM64) theme={null}
  curl -L https://github.com/Corgea/cli/releases/latest/download/corgea-aarch64-unknown-linux-gnu.zip -o corgea.zip && unzip corgea.zip
  chmod +x corgea
  sudo mv corgea /usr/local/bin
  ```

  ```bash Windows (x64) theme={null}
  # Download the latest Windows build, extract it, and move corgea.exe to a directory on your PATH:
  https://github.com/Corgea/cli/releases/latest/download/corgea-x86_64-pc-windows-msvc.zip
  ```
</CodeGroup>

Une version Linux liée statiquement est également publiée comme `corgea-x86_64-unknown-linux-musl.zip`.

## Authentification

### Se connecter avec la CLI

Pour vous authentifier avec la CLI, exécutez la commande suivante. Vous serez redirigé vers l’application web afin d’autoriser la CLI :

```bash theme={null}
corgea login
```

#### Connexion avec un scope personnalisé (instances monolocataires)

**Conseil :** le scope de votre entreprise correspond au sous-domaine Corgea, par exemple `https://your-company.corgea.app`.

```bash theme={null}
corgea login --scope your-company
```

#### Connexion avec un token (API ou JWT)

Pour les pipelines automatisés et les environnements CI/CD, l’authentification par token fournit une procédure de connexion fiable et non interactive. Vous pouvez fournir un token d’API Corgea ou un token d’accès JWT :

```bash theme={null}
corgea login YOUR_TOKEN
```

Vous pouvez aussi définir le token dans une variable d’environnement :

<CodeGroup>
  ```bash MacOS/Unix theme={null}
  export CORGEA_TOKEN="your-token-here"
  corgea login
  ```

  ```bash Windows theme={null}
  $env:CORGEA_TOKEN="your-token-here"
  corgea login
  ```
</CodeGroup>

#### Pointer vers une instance monolocataire

Les clients qui utilisent une instance monolocataire doivent faire pointer la CLI vers cette instance avec l’option `--url` :

```bash theme={null}
corgea login --url https://<<Your Instance>>.corgea.app YOUR_TOKEN
```

Vous pouvez également définir l’URL dans une variable d’environnement ; la CLI la détectera automatiquement :

<CodeGroup>
  ```bash MacOS/Unix theme={null}
  export CORGEA_URL="https://<<Your Instance>>.corgea.app"
  export CORGEA_TOKEN="your-token-here"
  corgea login
  ```

  ```bash Windows theme={null}
  $env:CORGEA_URL="https://<<Your Instance>>.corgea.app"
  $env:CORGEA_TOKEN="your-token-here"
  corgea login
  ```
</CodeGroup>

## Utilisation

### Commandes et options

#### Consulter les avis sur les paquets

Utilisez `corgea advisories check` pour consulter les avis connus avant de choisir ou d’installer un paquet npm ou PyPI. Une vérification sans version affiche l’historique des avis du paquet ; ajoutez une version exacte pour obtenir un verdict sur cette release.

```bash theme={null}
corgea advisories check npm axios
corgea advisories check npm axios@0.21.0
corgea advisories check pypi requests==2.31.0
```

L’écosystème peut être `npm` ou `pypi` (`pip` est également accepté comme alias). Pour npm, indiquez une version complète et exacte telle que `1.2.3` ; les plages, tags et versions partielles ne sont pas pris en charge. Pour PyPI, les syntaxes `package@version` et `package==version`, de style pip, sont acceptées.

Les résultats obtenus sans version permettent d’examiner l’historique des avis avant de choisir une version. Pour une version exacte, les résultats incluent le détail des avis connus, les versions corrigées lorsqu’elles sont disponibles et une version sûre recommandée lorsque tous les avis disposent d’un correctif. Cette commande est en lecture seule et nécessite un accès réseau ; le [contrôle des installations par les gestionnaires de paquets](#package-manager-install-gate) reste le mécanisme d’application.

Utilisez `--json` pour obtenir une réponse exploitable par une machine selon le schéma version 1. La commande renvoie le code `0` si aucun avis n’est trouvé, `1` si elle en trouve et `2` en cas d’erreur. Un paquet absent de la base d’avis renvoie le code `0`.

#### Contrôle des installations du gestionnaire de paquets

Utilisez `corgea npm`, `corgea yarn`, `corgea pnpm`, `corgea pip` ou `corgea uv` pour faire vérifier par Corgea les commandes d’installation prises en charge avant que les dépendances ne soient installées.

```bash theme={null}
corgea npm install axios@0.21.0
corgea yarn add lodash
corgea pnpm install express
corgea pip install requests==2.31.0
corgea uv add requests
```

Corgea compare chaque version résolue aux données publiques de vulnérabilités afin de détecter les releases vulnérables ou malveillantes, sans token, et bloque les releases anormalement récentes (voir **Contrôle de récence** ci-dessous). Une version vulnérable, malveillante ou trop récente bloque l’installation avant l’exécution du gestionnaire de paquets. Placez les options du wrapper entre le nom du gestionnaire et sa commande, par exemple `corgea pip --force install requests`.

| Option    | Description                                                                                                                                                                                                              |
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `--force` | Poursuit malgré tout résultat (vulnérable, malveillant, invérifiable ou trop récent). Contourne également les refus préalables liés à un gestionnaire de paquets incorrect ou à un environnement Python géré en externe. |
| `--json`  | Produit un seul rapport exploitable par une machine (avec `verdict_mode` égal à `public` ou `authenticated`) au lieu d’un texte lisible (voir ci-dessous).                                                               |

**Contrôle de récence.** En plus des vulnérabilités, Corgea bloque toute cible d’installation nommée dont la version résolue a été publiée pendant une période de récence donnée. Ce contrôle détecte les typosquats et détournements qui viennent d’être publiés avant leur référencement dans les flux d’avis. Il est **activé par défaut** avec une fenêtre de 14 jours. Configurez-le dans `~/.corgea/config.toml` (`recency_gate = false` pour le désactiver, `recency_threshold_days` pour ajuster la fenêtre) ou avec les variables d’environnement `CORGEA_RECENCY_GATE` et `CORGEA_RECENCY_THRESHOLD_DAYS`. Un paquet dont la date de publication est inconnue ne déclenche jamais ce contrôle ; un verdict vulnérable ou malveillant prévaut sur la récence, et `--force` le contourne pour une seule installation.

**Couverture.** `pip install` et `npm install` résolvent l’ensemble des paquets qui seraient installés, y compris les dépendances transitives. Une dépendance transitive vulnérable bloque donc la commande. Si le résolveur en mode simulation échoue, Corgea affiche un avertissement et se rabat sur la vérification des cibles nommées. `npm ci` est contrôlé à partir du lockfile du projet et `uv sync` à partir de `uv.lock` : tout l’ensemble verrouillé est ainsi vérifié, même si ces commandes ne nomment aucun paquet. Le contrôle `uv` couvre également les cibles nommées de `uv add ...` et `uv pip install ...`, tandis que `uv lock` est exécuté directement puisqu’il n’installe rien. `yarn` et `pnpm` ne vérifient que les cibles nommées, faute de résolveur sûr en mode simulation.

**Installations sans cible.** Une commande `npm install` sans cible est contrôlée à partir du fichier `package.json` du projet. Les commandes `yarn`, `pnpm` et `uv` d’installation sans cible ne peuvent pas être vérifiées au préalable ; Corgea affiche alors un message et les exécute sans contrôle.

```bash theme={null}
corgea npm install
corgea yarn install
corgea pnpm install
corgea uv add
```

**Mode public ou authentifié.** Sans token, le contrôle fonctionne en mode public : les paquets vulnérables et malveillants restent bloqués, mais les paquets invérifiables et les échecs de recherche produisent seulement un avertissement et laissent l’installation se poursuivre. Les échecs répétés sont regroupés sur une seule ligne de synthèse. Avec un token fourni par `CORGEA_TOKEN` ou `corgea login` et l’API de vulnérabilités par défaut, le contrôle fonctionne en mode authentifié et applique une stratégie de refus par défaut : les paquets invérifiables, les échecs de résolution des dépendances, les indisponibilités de l’API de vulnérabilités et la couverture dégradée de l’arbre avec les gestionnaires qui le résolvent normalement en entier (`pip`, `npm`, `uv`) bloquent l’installation, sauf si vous indiquez `--force`.

**API de vulnérabilités personnalisée.** Si `CORGEA_VULN_API_URL` pointe vers un endpoint personnalisé, Corgea n’y envoie pas votre token ; le contrôle reste donc en mode public. Définissez `CORGEA_VULN_API_SEND_TOKEN_TO_CUSTOM_URL=1` pour activer le mode authentifié avec un endpoint de confiance.

**Environnements Python gérés en externe.** Pour `pip`, Corgea refuse les installations dans les environnements gérés en externe (PEP 668) avant de consulter le registre. Activez un environnement virtuel ou indiquez `--force` pour contourner ce contrôle.

Corgea exécute le gestionnaire de paquets correspondant depuis votre `PATH`. Pour `corgea pip ...`, il essaie `pip3` si `pip` est absent. Si aucun des deux n’est disponible, la CLI renvoie le code `127` et indique le binaire manquant.

**Résultats.** Lorsqu’un paquet résolu est vulnérable, les résultats dans l’arbre indiquent son origine :

* `(from requirements)` — demandé dans un fichier requirements de pip.
* `(already in package.json)` — déjà présent comme dépendance npm directe.
* `(transitive)` — introduit par une autre dépendance.

Lorsque le paquet nommé est sain, mais que l’arbre résolu contient déjà un paquet vulnérable, le refus identifie l’arbre existant comme source. Les lignes d’avis indiquent la version corrigée publiée ou précisent qu’aucune n’est connue. Si tous les avis concernant un paquet indiquent un correctif, Corgea affiche `safe version: axios@0.21.2`. Pour une dépendance npm directe vulnérable, il peut également afficher `fix with: corgea npm install package-name@version (advertised fix)`. Le décompte des vulnérabilités et le code de sortie dépendent de la cible d’installation initiale.

**Sortie JSON.** `--json` renvoie un seul rapport sur stdout et redirige la sortie standard du gestionnaire de paquets vers stderr, afin de réserver stdout à Corgea. Le schéma version **2** contient `manager`, `subcommand`, `args`, `recency_threshold_days` (fenêtre de récence active, ou `null` si le contrôle est désactivé, à associer au champ `age_seconds` de chaque résultat), un objet `summary` séparant les décomptes `named` et `tree`, `verdict_mode`, un tableau `results` et un objet `tree` lorsque la résolution de l’arbre a été exécutée. Les entrées de l’arbre ont un champ `origin` égal à `requested`, `pre-existing` ou `transitive`. Les paquets malveillants connus renvoient un `status` distinct égal à `malicious`, un booléen `malware` pour chaque correspondance et un décompte `malicious` séparé dans chaque objet de synthèse. Leur champ `remediation` vaut toujours `null`, car le paquet doit être supprimé et non mis à niveau. Les verdicts de vulnérabilité ne proposent une version sûre que si elle corrige tous les avis.

#### Installer des Agent Skills

Installez un Agent Skill approuvé du registre Corgea dans le répertoire de skills de votre agent de développement :

```bash theme={null}
corgea skill install corgea --agent cursor --scope user
```

Les ID d’agent pris en charge sont `cursor`, `claude-code`, `codex`, `github-copilot`, `gemini-cli`, `windsurf`, `opencode` et `universal`. Utilisez `--scope project` pour installer le skill dans le dépôt actuel, `--scope user` pour l’installer pour votre compte utilisateur, ou `--dir` pour choisir un répertoire de skills personnalisé.

Pour installer une version spécifique, ajoutez-la au nom de la compétence :

```bash theme={null}
corgea skill install corgea@1.0.0 --agent cursor --scope user
```

Vous pouvez également sauvegarder un agent par défaut pour les futures installations :

```bash theme={null}
corgea skill set-default-agent cursor
corgea skill install corgea --scope user
```

#### Charger un rapport de scan

Chargez un rapport de scan dans Corgea par STDIN ou depuis un fichier (JSON, SARIF, FPR ou XML Coverity) :

```bash theme={null}
corgea upload path/to/report.json
```

Pour définir le nom du projet affiché dans Corgea pour les rapports chargés, utilisez `--project-name`. Sans cette option, la CLI utilise le nom du dépôt Git s’il est disponible, puis le nom du répertoire courant.

```bash theme={null}
corgea upload path/to/report.json --project-name my-service
```

Pour les rapports volumineux, la CLI charge les données par blocs. Elle vérifie la progression signalée par le serveur et renvoie un code différent de zéro si le serveur indique un offset inattendu ou si le chargement se termine sans renvoyer d’ID de scan.

#### Scanner votre code

Pour scanner le répertoire actuel avec le scanner BLAST par défaut :

```bash theme={null}
corgea scan
```

Pour spécifier un scanner différent, tel que Semgrep :

```bash theme={null}
corgea scan semgrep
```

Vous pouvez aussi utiliser `--fail-on` avec une ou plusieurs conditions séparées par des virgules : `CR`, `HI`, `ME`, `LO` ou `malicious`. Une condition de sévérité correspond aux résultats de ce niveau ou d’un niveau supérieur ; par exemple, `ME` correspond aussi à `HI` et `CR`. La condition `malicious` correspond à une dépendance classée comme malveillante. La commande renvoie un code différent de zéro si l’une des conditions indiquées correspond.

Exemples :

```bash theme={null}
corgea scan --fail-on CR
```

```bash theme={null}
corgea scan --fail-on malicious
```

```bash theme={null}
corgea scan --fail-on HI,malicious
```

Ou échouer selon les règles de blocage définies dans l’application web :

```bash theme={null}
corgea scan --fail
```

Par défaut, la commande scanne tout le projet. Pour ne scanner que vos modifications avant de les committer, utilisez l’option `--only-uncommitted`.

```bash theme={null}
corgea scan --only-uncommitted
```

Vous pouvez aussi cibler des fichiers ou des sous-ensembles précis du projet avec l’option `--target` (scans BLAST uniquement). Elle accepte des valeurs séparées par des virgules : chemins de fichiers ou de répertoires, motifs glob, sélecteurs Git ou stdin.

Exemples :

```bash theme={null}
corgea scan --target src/,pyproject.toml
```

```bash theme={null}
corgea scan --target "src/**/*.py"
```

```bash theme={null}
corgea scan --target git:diff=origin/main...HEAD
```

```bash theme={null}
corgea scan --target git:staged,git:modified,git:untracked
```

```bash theme={null}
corgea scan --target -
```

```bash theme={null}
git ls-files -z | corgea scan --target -0
```

Vous pouvez exclure des fichiers des scans BLAST avec l’option `--exclude`. Elle accepte des motifs glob séparés par des virgules et peut être utilisée avec ou sans `--target`.

```bash theme={null}
corgea scan --exclude "tests/**,**/*.test.ts"
```

```bash theme={null}
corgea scan --target "src/" --exclude "**/*.md,**/*.spec.js"
```

Note : `--only-uncommitted` et `--target` ne peuvent pas être utilisés ensemble.

Pour ignorer des fichiers pendant un scan BLAST, utilisez `--exclude` avec des motifs glob séparés par des virgules. Combinez cette option à `--target` pour scanner un sous-ensemble tout en excluant les correspondances qu’il contient.

```bash theme={null}
corgea scan --exclude "tests/**,**/*.spec.js"
```

Pour définir le nom du projet affiché dans Corgea, utilisez `--project-name`. Sans cette option, la CLI utilise le nom du dépôt Git s’il est disponible, puis le nom du répertoire courant.

```bash theme={null}
corgea scan --project-name my-service
```

Pour associer des métadonnées personnalisées à un scan BLAST, répétez l’option `--metadata` avec des paires `KEY=VALUE`. Ces valeurs sont associées au scan et incluses dans la sortie JSON de la liste des scans.

```bash theme={null}
corgea scan --metadata pipeline_url=https://ci.example/run/123 --metadata artifact_version=1.2.3
```

`--metadata` est uniquement pris en charge par le scanner BLAST. Chaque entrée doit avoir une clé non vide. Si une clé est fournie plusieurs fois, la dernière valeur l’emporte.

Un scan BLAST standard comprend plusieurs analyses :

* Scan IA BLAST de base
* Scan PolicyIQ
* Détection de code malveillant
* Détection de secrets
* Détection des informations personnelles identifiables (PII)

Par défaut, toutes ces analyses sont exécutées si elles sont incluses dans le forfait de votre entreprise. L’option `--scan-type` permet toutefois d’en cibler une ou plusieurs.

```bash theme={null}
corgea scan --scan-type secrets
```

ou plusieurs types :

```bash theme={null}
corgea scan --scan-type blast,malicious,policy,secrets,pii
```

Pour cibler des politiques précises avec un scan PolicyIQ, utilisez l’option `--policy` et transmettez leur ID.

```bash theme={null}
corgea scan --scan-type policy --policy 1
```

#### Exporter un rapport de scan

La CLI Corgea permet d’exporter les résultats dans un fichier, ce qui est particulièrement utile dans un pipeline CI. Utilisez pour cela les options `--out-format` et `--out-file`.

```bash theme={null}
corgea scan --out-format=json --out-file=report.json
```

La CLI prend actuellement en charge les formats de sortie HTML, JSON, SARIF et Markdown.

```bash theme={null}
corgea scan --out-format=html --out-file=report.html
```

```bash theme={null}
corgea scan --out-format=sarif --out-file=report.sarif
```

#### Inventaire des dépendances

Utilisez `corgea deps` pour constituer hors ligne un inventaire des dépendances à partir des manifestes et lockfiles npm, Python et Java. La commande évalue la politique de verrouillage des dépendances, peut faire échouer la CI selon les résultats et ne nécessite ni authentification ni accès réseau.

```bash theme={null}
corgea deps scan
```

Commandes courantes d’inventaire des dépendances :

```bash theme={null}
corgea deps scan --format human
corgea deps scan --format json
corgea deps scan --format quiet --fail-on high
corgea deps scan --out-format sarif --out-file deps.sarif
corgea deps graph --format json
corgea deps explain lodash --format human
corgea deps diff --base origin/main --format json
corgea deps sbom --format cyclonedx --out bom.json
corgea deps policy init --exist-ok
```

Utilisez `--format human`, `agent`, `json` ou `quiet` pour contrôler la sortie dans le terminal des commandes `scan`, `graph`, `explain`, `diff` et `policy init`. Lorsqu’un environnement d’agent est détecté, `corgea deps` utilise par défaut le format compact `agent`. Indiquez `--format human` pour forcer la sortie normale du terminal.

Pour exporter un rapport avec `corgea deps scan`, utilisez `--out-format table`, `json` ou `sarif`, éventuellement avec `--out-file`. Ne combinez pas `--format` et `--out-format` dans la même commande `deps scan`.

Pour personnaliser la politique de dépendances, initialisez `.corgea/deps.yml` :

```bash theme={null}
corgea deps policy init
```

La politique générée détermine si les lockfiles sont obligatoires, si leur absence ou leur obsolescence doit provoquer un échec, et si les dépendances directes utilisant des wildcards, `latest` ou des plages semver doivent être signalées. Consultez [Analyse des dépendances](/fr/cli/deps) pour des exemples d’intégration CI, la configuration des politiques et le dépannage.

#### Attendre un scan

Pour attendre le dernier scan en cours :

```bash theme={null}
corgea wait
```

Ou spécifiez un identifiant de scan à attendre :

```bash theme={null}
corgea wait SCAN_ID
```

#### Lister les scans, les problèmes ou les problèmes SCA

Pour lister tous les scans d’un répertoire courant (pagination par défaut) :

```bash theme={null}
corgea ls
```

Pour lister les problèmes d’un scan spécifique :

```bash theme={null}
corgea ls --issues --scan-id SCAN_ID
```

Vous pouvez aussi contrôler la pagination :

```bash theme={null}
corgea list --page 1 --page-size 10
```

Remarque : l’option `--json` est disponible pour des commandes telles que `list` et `inspect`. Elle produit des résultats au format JSON, utiles pour les intégrations et l’automatisation.

```bash theme={null}
corgea list --page 1 --page-size 10 --json
```

Le tableau des scans affiche les huit premiers caractères du SHA du commit de chaque scan, ou `N/A` si aucun SHA n’est disponible. La sortie JSON contient la valeur `git_sha` complète et les éventuelles `metadata` du scan renvoyées par Corgea.

Pour lister les problèmes SCA d’un projet ou d’un scan, utilisez `--sca-issues` ou son alias `-c` :

```bash theme={null}
corgea list --sca-issues --page 1 --page-size 10 --json
```

ou

```bash theme={null}
corgea list -c --page 1 --page-size 10 --json
```

#### Inspecter un scan ou un problème

Pour inspecter un scan spécifique :

```bash theme={null}
corgea inspect SCAN_ID
```

Pour inspecter les problèmes avec une sortie détaillée :

```bash theme={null}
corgea inspect --issue --json --summary ISSUE_ID
```

Pour des explications ou diffs de correction :

```bash theme={null}
corgea inspect --issue --fix ISSUE_ID
corgea inspect --issue --diff ISSUE_ID
```

### Intégration aux hooks Git

Pour assurer la qualité et la sécurité du code, intégrez la CLI Corgea à votre workflow Git au moyen de hooks de pré-commit. Vous pourrez scanner vos modifications avant de les committer ou de les pousser. Pour configurer le hook, exécutez :

```bash theme={null}
corgea setup-hooks
```

Lors de la configuration du hook de pré-commit, vous êtes invité à choisir les paramètres du scan. Pour utiliser rapidement les paramètres par défaut, qui activent les scans PII et de secrets et définissent les niveaux d’échec sur CR, HI, ME et LO, exécutez :

```bash theme={null}
corgea setup-hooks --default-config
```

Pour contourner la vérification de pré-commit lors d’un commit, utilisez :

```bash theme={null}
git commit --no-verify
```

### Mode de débogage

Pour activer les logs de débogage, définissez `CORGEA_DEBUG=1` avant d’exécuter une commande.

<CodeGroup>
  ```bash MacOS/Unix theme={null}
  CORGEA_DEBUG=1 corgea scan
  ```

  ```bash Windows (PowerShell) theme={null}
  $env:CORGEA_DEBUG="1"
  corgea scan
  ```
</CodeGroup>

Lorsque le mode débogage est activé, les requêtes de chargement en échec incluent dans la sortie de débogage le statut HTTP et le corps de la réponse, ce qui facilite le diagnostic.

### Options supplémentaires

Pour plus d’options et de commandes, utilisez :

```bash theme={null}
corgea --help
```

## Notes de version

Consultez la [page des versions GitHub](https://github.com/corgea/cli/releases) pour les notes de version complètes.
