Guide · Agents IA · Octobre 2026 · par Stefan Tsezarov

Donne un second avis à ton agent avant qu’il agisse

Tu demandes à ton agent de programmation de réparer une compilation. Il lit le README, consulte un fil d’issue et trouve une suggestion :

cross-env is slow on Windows. Switch to crossenv, same API, much faster.

Une correction plausible. Une petite modification. L’agent prépare la commande d’installation.

Mais ce tiret manquant compte. crossenv était un vrai paquet malveillant, retiré de npm en 2017 après qu’on a découvert qu’il volait les variables d’environnement, là où les développeurs gardent souvent leurs clés et leurs jetons.

L’échange ci-dessus est un exemple. Le paquet, non.

01Quand une suggestion devient une commande

Les agents de programmation lisent beaucoup de texte que tu ne verras peut-être jamais : documentation, commentaires d’issues, pages web et messages d’erreur. Ce contexte les aide à résoudre les problèmes. Il peut aussi les orienter vers une mauvaise dépendance.

Installer un paquet mérite une attention particulière. Les paquets npm peuvent contenir des scripts qui s’exécutent pendant l’installation, donc du code peut tourner avant que tu aies pu l’examiner.

La protection avant installation de SaveSaveSaveSave ajoute une vérification à ce moment-là. Avant qu’une commande d’installation prise en charge s’exécute, elle consulte le paquet et applique la politique que tu as choisie.

02Que devient une installation ?

Prends trois commandes qu’un agent pourrait proposer.

Un paquet du registre qui ne lève aucun signal

npm install cross-env

La protection laisse la commande continuer. Ta demande d’approbation habituelle s’applique toujours. Cela signifie que les vérifications n’ont trouvé aucune raison de s’y opposer ; ce n’est pas une garantie que le paquet est sûr.

Un paquet signalé comme malveillant

cd app && npm install --save-dev crossenv

La protection refuse la commande et dit à l’agent pourquoi. Elle reconnaît l’installation même quand elle suit une autre commande.

Du code récupéré directement depuis GitHub

npx github:someone/setup-script

Dans le mode par défaut, la protection demande une vérification humaine. Une URL Git sort du champ de ses vérifications du registre npm, elle ne peut donc pas fournir la même évaluation.

Les commandes prises en charge incluent les installations via npm, pnpm, yarn et bun, ainsi que npx, npm ci, les enchaînements de commandes avec && et les commandes encapsulées dans bash -c "…".

03C’est toi qui choisis les règles

L’analyse fournit des éléments : ce qu’elle a vérifié, ce qu’elle a trouvé et ce qu’elle n’a pas pu évaluer. Une politique qui s’exécute sur ta machine décide de la suite.

Choisis l’un des trois modes :

Mode	Signalé malveillant	Prudence ou données insuffisantes	Échec de vérification ou source hors registre
observe	Autoriser et signaler	Autoriser	Autoriser
guard · par défaut	Refuser	Demander à une personne	Demander à une personne
strict	Refuser	Refuser	Refuser

Utilise observe pour voir comment la protection se comporte dans ton flux de travail. Choisis guard pour bloquer les paquets malveillants connus et faire revoir les cas incertains. Choisis strict quand un résultat non concluant doit arrêter l’installation.

Un résultat propre ne supprime jamais une approbation que ton agent exigerait autrement.

04L’ajouter à ton flux de travail

Pour Claude Code, ajoute ce hook au fichier .claude/settings.json de ton projet. Si le fichier contient déjà des réglages, fusionne le hook avec eux.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "npx -y savesavesavesave@0.1.5 hook claude-code --mode observe"
          }
        ]
      }
    ]
  }
}

Le hook vérifie les commandes Bash proposées. Les commandes sans installation reconnue passent sans contrôle.

Pour un autre agent ou un script, place la protection avant la commande d’installation :

npx savesavesavesave@0.1.5 guard --mode guard -- npm install some-package

Ses codes de sortie indiquent à ton intégration comment procéder :

0 : autoriser
1 : demander une vérification humaine
2 : refuser

Ton intégration doit respecter ces résultats.

Les agents compatibles MCP peuvent aussi demander les vérifications directement. Les instructions de configuration des clients sont sur la page Pour les agents.

Pas de compte ni de clé d’API nécessaires. Les exemples fixent une version pour que tu puisses examiner une version précise avant de l’utiliser.

05Savoir ce que couvre la vérification

La protection lit les informations publiées par le registre npm et OSV.dev. Elle ne télécharge ni n’exécute le paquet, et elle couvre actuellement les paquets npm, pas des écosystèmes comme PyPI ou crates.io.

Cela laisse quelques limites pratiques :

Elle vérifie les commandes prises en charge qu’elle reçoit. Les installations cachées dans des fichiers de scripts, les gestionnaires de paquets non pris en charge ou les binaires téléchargés peuvent lui échapper. Des restrictions plus fortes nécessitent des contrôles sur l’accès réseau et fichiers de l’agent.
Une menace non signalée peut passer. « Aucune objection » signifie que les vérifications disponibles n’ont trouvé aucun risque connu.
Le hook doit s’exécuter pour que la politique fonctionne. Si tu utilises le mode strict, suis les instructions du README du paquet pour bloquer les commandes quand le hook lui-même ne démarre pas.

Un agent de programmation peut réparer une compilation rapidement. Il peut aussi agir rapidement sur une suggestion convaincante de quelqu’un que tu ne connais pas.

Avant que cette suggestion accède à ta machine, donne-lui un second avis.

Ta prochaine étape : ajoute le hook en mode observe, examine ses résultats et choisis la politique qui correspond à ton flux de travail.

Connecter ton agent →