Dans l'article précédent, on a créé un compte AWS sécurisé avec un user IAM admin. Avant de foncer sur S3, on installe un outil qui va servir dans toute la série, l'AWS CLI.

La CLI (Command Line Interface), c'est AWS en ligne de commande, très pratique pour industrialiser et automatiser des traitements.

La console sert à comprendre et à vérifier. La CLI sert à produire. Dans la série, on utilisera les deux côte à côte.

Étape 1, créer les access keys du user IAM

Dans la console on utilise un mot de passe mais pour la CLI on a besoin des access keys, une paire composée d'un identifiant public (Access Key ID) et d'une clé secrète. Le login et mot de passe des programmes, en somme.

On les crée sur le user IAM admin de l'article précédent. Jamais sur le root.

Ne crée JAMAIS d'access keys sur le compte root. Une clé root qui fuite dans un script ou un repo Git, c'est le compte entier compromis.
  1. Connecte-toi avec ton user IAM et ouvre le service IAM.
  2. Dans "Users", clique sur ton user, puis sur l'onglet "Security credentials".
  3. Dans la section "Access keys", clique sur "Create access key".
Create access key
Create access key
  1. Choisis le cas d'usage "Command Line Interface (CLI)", coche la case de confirmation et continue.
  1. L'écran final affiche l'Access Key ID et la Secret Access Key. C'est le seul moment où la clé secrète est visible. Copie les deux valeurs dans ton gestionnaire de mots de passe.

Étape 2, installer l'AWS CLI sur Windows

AWS fournit un installeur MSI classique. Télécharge la version 2 depuis le lien officiel.

https://awscli.amazonaws.com/AWSCLIV2.msi

Lance l'installeur, suivant, suivant, terminer.

Ouvre ensuite PowerShell (clic droit sur le menu Démarrer, puis "Terminal") et vérifie.

aws --version

💡
Si PowerShell répond que "aws" n'est pas reconnu, ferme le terminal et rouvre-le, le PATH n'est chargé qu'à l'ouverture. Si ça ne passe toujours pas, redémarre la machine.

Étape 3, configurer la CLI avec aws configure

On connecte la CLI au compte avec les clés de l'étape 1.

aws configure

La CLI pose quatre questions.

La région, c'est eu-west-3 (Paris), celle choisie dans l'article précédent.

AWS Access Key ID [None]: AKIA................
AWS Secret Access Key [None]: ****************************
Default region name [None]: eu-west-3
Default output format [None]: json

La CLI vient d'écrire deux fichiers dans C:\Users\<Users>\.aws\, credentials pour les clés et config pour la région.

C'est là que tout outil qui communique à AWS viendra chercher les identifiants.

⚠️
Le dossier .aws contient ta clé secrète en clair. Ne le copie jamais dans un projet et ne le partage jamais en réseau ou un repo Git.

Étape 4, les premières commandes

Qui suis-je ?

aws sts get-caller-identity

{
    "UserId": "AIDA................",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/idriss-admin"
}

Si ton user apparaît dans l'ARN, la connexion est bonne. C'est la commande de diagnostic.

Lister les buckets S3

aws s3 ls

Réponse vide, et c'est normal, on n'a encore rien créé.

Créer, remplir et supprimer un bucket de test

Un aller-retour complet en quatre commandes. On crée un bucket, on y dépose un fichier, on vérifie, on nettoie.

# Créer un bucket (le nom doit être unique au monde, adapte-le)
aws s3 mb s3://test-formation-ibdata

# Créer un fichier local et l'envoyer dans le bucket
echo "hello aws" > hello.txt
aws s3 cp hello.txt s3://test-formation-ibdata/

# Vérifier le contenu du bucket
aws s3 ls s3://test-formation-ibdata/

# Tout supprimer (le fichier puis le bucket)
aws s3 rb s3://test-formation-ibdata --force

Le cycle de vie complet d'un stockage cloud en quatre commandes. En console web, la même chose prend dix fois plus de temps.

💡
Pour un rendu plus lisible que du JSON, ajoute --output table à n'importe quelle commande. Et aws s3 cp help affiche la doc directement dans le terminal.

Bonus, gérer plusieurs comptes avec les profils

Ce qu'on a configuré à l'étape 3, c'est le profil par défaut. Il suffit largement pour toute la série, on reste sur un seul compte. Mais autant connaître le mécanisme tout de suite, parce qu'en mission tu peux avoir besoin de jongler entre plusieurs environnements.

La CLI gère ça avec des profils nommés. Même commande qu'à l'étape 3, avec un nom en plus.

aws configure --profile client

La CLI repose les quatre mêmes questions et ajoute une section [client] dans tes fichiers config et credentials. Le profil par défaut n'est pas touché.

Ensuite, tu précises le profil sur chaque commande.

aws s3 ls --profile client

Sans --profile, c'est le profil par défaut qui répond.

Pour éviter de le répéter sur toute une session, tu peux le fixer dans le terminal.

$env:AWS_PROFILE = "client"
aws sts get-caller-identity
💡
aws configure list-profiles liste tous tes profils. aws configure list montre lequel est actif et d'où viennent les valeurs

La checklist finale

  • [ ] Access keys créées sur le user IAM (pas le root), secret sauvegardé.
  • [ ] AWS CLI v2 installée.
  • [ ] aws configure fait, région eu-west-3, format json.
  • [ ] aws sts get-caller-identity renvoie bien ton user IAM.
  • [ ] Le bucket de test a été créé puis supprimé sans erreur.

La suite ?

Le poste de travail est prêt, console et terminal. Dans le prochain article, on attaque la collecte. On fait atterrir nos premiers fichiers de données dans AWS de trois façons (console, CLI, Python avec boto3), et on introduit le jeu de données e-commerce qui va nous suivre dans toute la série.

Aller plus loin

Tu prépares la certification AWS Certified Data Engineer Associate (DEA-C01) ? La CLI, les access keys et la gestion des identifiants sont des sujets récurrents de l'examen. Pour t'entraîner, j'ai créé des questions d'examen blanc en français.

👉 S'entraîner sur DataCertification.fr

Tu veux que je t'accompagne sur ton projet data (AWS, Snowflake, dbt, modélisation, coûts) ?

👉 Réserver un appel de 30 minutes

Questions fréquentes

À quoi sert l'AWS CLI par rapport à la console ?

La console sert à explorer et vérifier visuellement. La CLI sert à produire, répéter et automatiser. En mission, les deux s'utilisent côte à côte.

Où sont stockées les clés AWS sur Windows ?

Dans C:\Users\<User>\.aws\. Le fichier credentials contient les clés, le fichier config la région et le format. Tous les outils de l'écosystème (boto3, Terraform, dbt) lisent ces fichiers.

Que faire si une access key a fuité ?

La désactiver puis la supprimer dans IAM, onglet Security credentials du user, et en recréer une. Une clé compromise se révoque en 30 secondes sans mettre le compte en danger.

AWS CLI v1 ou v2 ?

La v2, sans hésiter. C'est la version maintenue, avec un installeur Windows autonome qui n'exige pas Python. La v1 ne sert plus que sur de vieux systèmes.

Peut-on utiliser AWS en ligne de commande sans rien installer ?

Oui, avec CloudShell, un terminal accessible directement dans la console (l'icône terminal en haut de l'écran), avec la CLI préinstallée et déjà authentifiée. Pratique pour dépanner, mais pour le quotidien la CLI locale reste plus confortable.

Faut-il connaître la CLI pour la certification DEA-C01 ?

Oui. L'examen ne demande pas de réciter des commandes, mais il faut comprendre comment la CLI s'authentifie, où vivent les identifiants et ce qui se scripte avec. Le cycle de vie des access keys est un sujet classique.

Comment utiliser plusieurs comptes AWS avec la CLI ?

Avec les profils nommés. La commande aws configure --profile <nom> crée une section dédiée dans les fichiers config et credentials, sans toucher au profil par défaut. On sélectionne ensuite le profil avec l'option --profile sur chaque commande, ou pour toute une session en fixant la variable d'environnement AWS_PROFILE.