Valider les commandes générées

5.9 Risques liés à l’exécution de commandes générées

Point le plus important du chapitre

Copilot CLI peut générer des commandes puissantes.

Mais une commande terminal peut :

• supprimer des fichiers ;
• modifier des permissions ;
• pousser du code ;
• déployer en production ;
• supprimer des ressources cloud ;
• exposer des secrets ;
• changer une configuration ;
• modifier un cluster Kubernetes ;
• détruire une infrastructure Terraform.

Donc la règle est simple :

Ne jamais exécuter une commande générée sans la comprendre.

Commandes dangereuses à surveiller

Suppression :

rm -rf
find . -delete

Permissions :

chmod -R 777
chown -R

Exécution distante :

curl ... | bash
wget ... | sh

Cloud :

aws s3 rm --recursive
gcloud compute instances delete
az group delete

Kubernetes :

kubectl delete
kubectl apply -f
kubectl replace --force

Terraform :

terraform destroy
terraform apply -auto-approve

Git :

git reset --hard
git clean -fd
git push --force

Exemple dangereux

Copilot propose :

git reset --hard HEAD~1

Ce que ça fait :

Revient au commit précédent et supprime les changements du commit courant dans la branche locale.

Possible perte de travail.

Alternative plus prudente :

git revert HEAD

Pourquoi ?

git revert crée un nouveau commit qui annule le précédent sans réécrire l’historique.

Exemple cloud dangereux

Copilot propose :

aws s3 rm s3://my-prod-bucket --recursive

Ce que ça fait :

Supprime récursivement le contenu du bucket S3.

Très dangereux.

Avant toute action :

aws s3 ls s3://my-prod-bucket --recursive

ou utiliser un dry-run si disponible.

Exemple Terraform dangereux

Copilot propose :

terraform apply -auto-approve

Problème :

Applique les changements sans confirmation interactive.

Plus prudent :

terraform plan

Puis seulement après review :

terraform apply

Autorisations demandées par Copilot CLI

Quand Copilot CLI veut utiliser un outil dangereux (supprimer un fichier, lancer une commande), il demande une autorisation. Trois réponses sont typiques : autoriser cette fois, autoriser pour la session, ou refuser en donnant une autre instruction.

Autoriser pour la session a une portée large : autoriser la commande rm pour la session permettrait à Copilot de supprimer n’importe quel fichier du dossier courant et de ses sous-dossiers sans redemander. Les options --allow-all-tools, --allow-all et /yolo accordent les permissions d’un coup ; on ne les utilise que dans un dossier de confiance, avec une tâche cadrée et, de préférence, un dépôt propre. L’autopilot demande ce niveau de permissions.

À l’inverse, --deny-tool interdit un outil et les autorisations préalables (--allow-tool) permettent de ne rien accorder de plus que nécessaire. En mode programmatique (-p), il faut autoriser les outils à l’avance, ce qui renforce l’intérêt d’un périmètre étroit.

Stratégie de sécurité

Pour toute commande générée :

1. Demander une explication.
2. Identifier les effets destructifs.
3. Vérifier le contexte courant.
4. Chercher une option dry-run.
5. Exécuter d’abord en environnement non-prod.
6. Lire la documentation officielle si impact élevé.
7. Faire valider si production/sécurité.
8. Sauvegarder si nécessaire.

Prompt de sécurité recommandé

Explain this command before I run it.
Identify:
- what it changes
- whether it deletes data
- whether it affects production
- required permissions
- safer alternatives
- dry-run options

Règle pour l’examen

Si une question propose :

Run the generated command immediately.

C’est presque toujours faux.

La bonne logique est :

Review and understand the command before running it.