Probe
FR

Premiers pas

Relisez votre dernier commit en deux minutes

Il vous suffit d’un dépôt Git comportant au moins deux commits. La première exécution ne nécessite ni configuration, ni Docker, ni clé d’API, et n’exécute jamais votre code.

Cette page couvre Probe pour le code, l’outil en ligne de commande. Vous surveillez des fichiers Word, Excel ou PowerPoint ? Consultez Probe Desktop.

  1. Installer le binaire

    Probe est un exécutable unique. Git doit être installé ; rien d’autre n’est nécessaire pour ce guide. Téléchargez l’archive correspondant à votre système d’exploitation et à votre processeur, puis extrayez-la. Suivez ci-dessous les étapes pour votre système.

    Ouvrez un terminal dans le dossier extrait contenant probe. Sous macOS, retirez d’abord la quarantaine appliquée par le navigateur avec xattr -d com.apple.quarantine probe.

    sudo install probe /usr/local/bin/
probe version

    Pas de sudo ? Installez plutôt dans ~/.local/bin, à condition qu’il existe et figure dans votre PATH.

    Dans l’Explorateur de fichiers, créez %LOCALAPPDATA%\Programs\probe et copiez-y le fichier probe.exe extrait. Ouvrez ensuite PowerShell :

    $env:Path += ";$env:LOCALAPPDATA\Programs\probe"
probe version

    Cela définit PATH pour le terminal actuel. Pour les prochains terminaux, ajoutez le même dossier à la variable Path de votre utilisateur dans les variables d’environnement de Windows.

    La dernière commande affiche la version installée, par exemple probe v0.5.1. Pour vérifier l’archive avec les sommes de contrôle publiées, voir Vérifier un téléchargement.

  2. Comparez votre dernier commit au précédent

    Placez-vous dans n’importe quel dépôt Git et demandez à Probe ce qui a changé entre HEAD~1 et HEAD :

    cd path/to/your/repository
probe lint HEAD~1..HEAD

    lint est la moitié statique de Probe. Il compare les deux commits, collecte les signaux de risque et écrit un rapport. Il n’exécute jamais le code du dépôt, n’appelle jamais de fournisseur d’IA et n’a pas besoin de .probe.json : sans ce fichier, les valeurs par défaut intégrées pour le langage détecté s’appliquent.

    Seuls les fichiers commités sont analysés. Les modifications non commitées et les fichiers non suivis sont ignorés : commitez donc d’abord votre travail, par exemple sur une branche de brouillon. Pour que les rapports n’apparaissent pas dans git status sans toucher à .gitignore, lancez echo .probe/ >> .git/info/exclude.

  3. Lire le rapport

    Ouvrez .probe/CONFIDENCE_REPORT.md dans votre éditeur. Commencez par Suggested Human Review, une liste de plages de fichiers et de lignes classées par gravité, chacune avec la raison de son signalement :

    ## Suggested Human Review
- **high** auth/auth.go:7–7 (new): Authentication or authorization function body changed
- **high** payment/refund.go (whole file): Lines added and removed in a sensitive file; No nearby test file changed
- **high** payment/refund.go:21–21 (old): Possible input validation removed

    (new) désigne une ligne du commit candidat et (old) une ligne supprimée de la base. (whole file) marque un signal portant sur le fichier lui-même, comme un chemin sensible, plutôt que sur l’une de ses lignes. Review Surface indique combien de lignes modifiées ces plages couvrent. Les mêmes données, avec les identifiants de commit et les preuves des signaux, figurent dans confidence-report.json pour les scripts et la CI.

    Les signaux sont des raisons de regarder, pas des bugs confirmés. La référence des signaux explique chacun d’eux.

  4. Choisir ce que vous comparez

    Deux révisions quelconques conviennent. Quelques choix courants :

    CommandeCompare
    probe lint HEAD~5..HEADVos cinq derniers commits pris ensemble.
    probe lint --base mainVotre branche actuelle par rapport à main, depuis leur base de fusion, comme une pull request. Utilisez --base master si c’est votre branche par défaut.
    probe lint --base origin/main --head featureUne autre branche par rapport à la branche par défaut distante, sans l’extraire.
    probe lint main..featureLes deux commits exacts, sans base de fusion (main...feature utilise la base de fusion).
    probe lint --base main --ciComme ci-dessus, mais sort avec le code 2 lorsqu’une relecture humaine est requise, pour les scripts et la CI.

  5. Facultatif : exécutez vos vérifications dans un bac à sable

    review fait tout ce que fait lint, puis exécute les commandes de test, de vérification de types, de build et de couverture du dépôt dans des conteneurs Docker jetables et sans réseau. Il nécessite Docker avec des conteneurs Linux et une image préchargée contenant votre chaîne d’outils : Probe ne télécharge jamais d’image et n’installe jamais lui-même de dépendances. Pour un projet Go sans dépendance tierce, l’image par défaut suffit :

    docker pull golang:1.26-bookworm
probe review HEAD~1..HEAD --reviewer=false

    Pour les projets Node.js, Python et Rust, les images standard ne contiennent pas vos dépendances : construisez une image qui les contient et faites-y pointer sandbox.image dans une politique (étape suivante), ou laissez la politique de confiance construire cette couche avec un objet prepare. Si Docker ou l’image est absent, Probe s’arrête avec le code de sortie 4 et ne se rabat jamais sur une exécution du code sur votre machine.

  6. Adoptez-le dans votre dépôt

    Lancez probe init pour générer un .probe.json adapté au langage détecté. Relisez ses commandes et son image de bac à sable, puis essayez la politique en local :

    probe review --base main --config .probe.json

    Commitez .probe.json sur votre branche de base. Les reviews suivantes liront cette politique de confiance. Sur votre branche de fonctionnalité, lancez :

    probe review --base main --ci

    Vous travaillez avec un agent de code ? Adoptez le processus « plan d’abord » : l’agent lance probe plan --intent-file task.md --ci avant d’écrire le code (un plan signalé est confié à un humain), implémente le plan, et la CI lance probe review --plan .probe/PLAN.json --ci. Le code 0 signifie que la modification est conforme à un plan à faible risque et a passé ses vérifications : elle peut donc être fusionnée sans relecture humaine ; le code 2 liste les raisons pour lesquelles un humain doit regarder (plan gate).

    Pour aller plus loin : chaque option, code de sortie et clé de politique figure dans la référence. Pour laisser un relecteur IA tenter de reproduire des problèmes, configurez un fournisseur comme décrit dans Relecteur IA. Pour GitHub Actions, consultez le guide d’intégration CI.

  7. Affichez-le dans votre README

    Une fois que Probe relit vos pull requests, ajoutez le badge à votre README. Il renvoie vers ce site et indique que le projet utilise Probe ; ce n’est pas une approbation du code.

    vérifié par Probe

    [![verified by Probe](https://probe.technology/badge/verified-by-probe.svg)](https://probe.technology/)

    Les variantes HTML, reStructuredText, les styles shields.io et le badge dynamique de Probe Hub sont décrits dans le guide du badge.

En cas de problème

MessageQue faire
base: git rev-parse … Needed a single revisionUne révision n’existe pas. Le dépôt ne comporte peut-être qu’un seul commit (il n’y a donc pas de HEAD~1), ou sa branche par défaut n’est pas main : passez --base master ou une plage explicite.
Le rapport ne contient pas vos dernières modificationsElles ne sont pas encore commitées. Probe n’analyse que les commits ; commitez-les, puis relancez-le.
Code de sortie 2Ce n’est pas une erreur : avec --ci, il signifie qu’une relecture humaine est requise. Voir les codes de sortie.
Code de sortie 4 pendant reviewDocker n’est pas lancé ou l’image du bac à sable n’est pas présente en local. Téléchargez-la d’abord, ou utilisez lint.
reviewer.model must be configured…--reviewer a été demandé sans modèle. Retirez-le, ou configurez un fournisseur.