# Bunkle CLI

> Bunkle est un CLI pour gérer et partager vos variables d'environnement de manière sécurisée. Une seule source de vérité pour vos secrets.

## Présentation

Bunkle résout les problèmes courants de gestion des variables d'environnement :
- Copier-coller hasardeux sur des messageries non sécurisées
- Fichiers .env qui divergent entre développeurs et environnements
- Risque de fuite critique si un laptop est compromis
- Pas de versioning ni d'historique des changements

### Fonctionnalités principales

- **Chiffrement AES-256-GCM** : Vos secrets sont chiffrés côté client avant stockage
- **Partage sécurisé** : Liens avec expiration et permissions (lecture seule)
- **Synchronisation** : Une source unique pour Dev, Staging et Prod
- **Multi-environnements** : Gérez plusieurs envs par projet
- **CLI puissant** : Intégration directe dans vos workflows
- **Row Level Security** : Chaque utilisateur ne voit que ses données

## Installation

### Prérequis
- Node.js 18+
- npm ou yarn

### Installation globale

```bash
npm install -g bunkle
# ou
yarn global add bunkle
```

### Vérification

```bash
bunkle --version
```

### Problèmes courants

**Permission denied (EACCES)** :
```bash
# Option 1: Utiliser sudo
sudo npm install -g bunkle

# Option 2: Configurer npm pour éviter sudo
mkdir ~/.npm-global
npm config set prefix '~/.npm-global'
echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.bashrc
source ~/.bashrc
```

## Démarrage rapide

```bash
# Se connecter
bunkle login

# Créer un projet
bunkle create mon-api

# Ajouter des environnements
bunkle env add development
bunkle env add production

# Ajouter des variables
bunkle var add DATABASE_URL "postgres://localhost:5432/mydb" --env development
bunkle var add API_KEY "secret-key" --env development

# Récupérer le fichier .env
bunkle pull mon-api --env development --output .

# Synchroniser les modifications locales
bunkle push --env development
```

## Commandes

### Authentification

#### `bunkle login`
Se connecter à votre compte Bunkle.

```bash
bunkle login
```

Prompts interactifs :
- **Email** : L'email associé à votre compte
- **Mot de passe** : Votre mot de passe (masqué)

La session est sauvegardée localement avec :
- Access token (JWT)
- Refresh token
- Identifiant utilisateur

#### `bunkle logout`
Se déconnecter et supprimer la session locale.

```bash
bunkle logout
```

#### `bunkle whoami`
Afficher l'utilisateur actuellement connecté.

```bash
bunkle whoami
```

### Navigation

#### `bunkle status`
Afficher le contexte actuel (utilisateur et projet sélectionné).

```bash
bunkle status
```

Affiche :
- L'utilisateur connecté
- Le projet actuellement sélectionné
- Les environnements disponibles
- Les commandes suggérées

#### `bunkle use <project>`
Sélectionner un projet comme contexte de travail.

```bash
bunkle use mon-api
```

Arguments :
- `<project>` : Nom ou ID du projet à sélectionner

#### `bunkle unset`
Quitter le projet courant.

```bash
bunkle unset
```

### Projets

#### `bunkle projects`
Lister tous vos projets.

```bash
bunkle projects
```

#### `bunkle create <name>`
Créer un nouveau projet.

```bash
bunkle create mon-api
bunkle create mon-api -d "API principale de production"
```

Arguments :
- `<name>` : Nom du projet

Options :
- `-d, --description <text>` : Description du projet

#### `bunkle pull <project>`
Récupérer les variables d'environnement d'un projet.

```bash
# Afficher les variables
bunkle pull mon-api

# Générer un fichier .env
bunkle pull mon-api --output .

# Filtrer par environnement
bunkle pull mon-api --env production --output .

# Mode lecture seule (masque les valeurs)
bunkle pull mon-api --readonly
```

Arguments :
- `<project>` : Nom ou ID du projet

Options :
- `-e, --env <name>` : Filtrer par environnement
- `-o, --output <dir>` : Sauvegarder dans un fichier .env
- `-r, --readonly` : Mode lecture seule

Fichiers générés :
- `pull projet -o .` → `.env` (toutes les variables)
- `pull projet --env dev -o .` → `.env.dev`
- `pull projet --env production -o .` → `.env.production`

#### `bunkle push`
Envoyer les variables d'environnement locales vers Bunkle.

```bash
bunkle push --env development
bunkle push --file .env.local --env staging
```

Options :
- `-e, --env <name>` : Environnement cible
- `-f, --file <path>` : Fichier .env source (défaut: .env)

Note : Les variables existantes seront mises à jour. Les nouvelles seront ajoutées. Les variables absentes du fichier local ne seront pas supprimées.

### Environnements

#### `bunkle env add <name>`
Ajouter un environnement à un projet.

```bash
bunkle env add production
bunkle env add staging --project autre-api
```

Arguments :
- `<name>` : Nom de l'environnement (ex: development, staging, production)

Options :
- `-p, --project <name>` : Projet cible (sinon utilise le projet courant)

Conventions de nommage courantes :
- `development` ou `dev` : Développement local
- `staging` : Environnement de test
- `production` ou `prod` : Production
- `test` : Tests automatisés
- `preview` : Déploiements de preview

#### `bunkle var add <key> <value>`
Ajouter ou modifier une variable d'environnement.

```bash
bunkle var add API_KEY "sk-123456789" --env production
bunkle var add DATABASE_URL "postgres://user:pass@host:5432/db" --env production
bunkle var add SECRET "value" --env dev --project mon-api
```

Arguments :
- `<key>` : Nom de la variable (ex: DATABASE_URL, API_KEY)
- `<value>` : Valeur de la variable

Options :
- `-e, --env <name>` : Environnement cible
- `-p, --project <name>` : Projet cible

Note : La valeur est automatiquement chiffrée (AES-256) avant stockage.

Conventions de nommage :
- Majuscules avec underscores : `DATABASE_URL`
- Préfixes pour grouper : `AWS_ACCESS_KEY`, `AWS_SECRET_KEY`
- Suffixes pour le type : `REDIS_URL`, `REDIS_PORT`

## Guides

### Workflow complet pour équipes

#### Configuration initiale (lead développeur)

```bash
bunkle login
bunkle create mon-api -d "API principale"
bunkle env add development
bunkle env add staging
bunkle env add production
```

#### Ajouter les variables

```bash
# Development
bunkle var add DATABASE_URL "postgres://localhost:5432/dev" --env development
bunkle var add API_KEY "dev-key-123" --env development
bunkle var add DEBUG "true" --env development

# Production
bunkle var add DATABASE_URL "postgres://prod-db:5432/prod" --env production
bunkle var add API_KEY "prod-key-789" --env production
bunkle var add DEBUG "false" --env production
```

#### Onboarding d'un développeur

```bash
bunkle login
bunkle projects
bunkle pull mon-api --env development --output .
```

#### Modifier une variable

```bash
bunkle var add API_KEY "new-prod-key-abc" --env production --project mon-api
```

#### Synchroniser depuis un fichier local

```bash
echo "NEW_VAR=hello" >> .env.development
bunkle push --file .env.development --env development
```

### Multi-environnements

Un environnement représente un contexte d'exécution. Chaque environnement peut avoir ses propres valeurs pour les mêmes variables.

| Variable | development | production |
|----------|-------------|------------|
| DATABASE_URL | localhost:5432 | prod-db.aws.com |
| DEBUG | true | false |
| LOG_LEVEL | debug | error |

Types d'environnements courants :
- **development** : Environnement local, debug activé
- **test** : Tests automatisés (CI/CD)
- **staging** : Réplique de production pour tests d'intégration
- **production** : Environnement live

#### Intégration avec les frameworks

**Next.js** :
```bash
bunkle pull mon-api --env development --output .
# Crée .env.development, chargé automatiquement par Next.js
```

**Node.js (dotenv)** :
```javascript
require('dotenv').config({ path: '.env.production' })
```

**Docker** :
```yaml
# docker-compose.yml
env_file:
  - .env.production
```

### Sécurité

#### Architecture

```
UTILISATEUR (email + password)
        ↓
AUTHENTIFICATION (Supabase Auth, JWT tokens)
        ↓
ROW LEVEL SECURITY (chaque user ne voit que ses données)
        ↓
CHIFFREMENT (AES-256-GCM, données chiffrées au repos)
```

#### Chiffrement AES-256-GCM

| Propriété | Valeur |
|-----------|--------|
| Algorithme | AES-256-GCM |
| Taille de clé | 256 bits |
| IV | 12 bytes aléatoires par valeur |
| Auth Tag | 16 bytes pour l'intégrité |

Chaque valeur est chiffrée avec un IV unique.

#### Row Level Security (RLS)

```sql
CREATE POLICY "Users can only see their own projects"
ON projects
FOR SELECT
USING (auth.uid() = user_id);
```

#### Stockage local

Le CLI stocke localement :
- Access token (JWT) - expire après 1 heure
- Refresh token
- ID du projet courant

Les tokens ne sont jamais affichés dans les logs.

#### Bonnes pratiques

**À faire** :
- Utiliser des mots de passe forts et uniques
- Se déconnecter sur les machines partagées
- Différencier les credentials entre environnements
- Faire une rotation régulière des secrets
- Ajouter `.env*` au .gitignore

**À éviter** :
- Commiter des fichiers .env dans Git
- Partager des credentials via Slack/WhatsApp
- Utiliser les mêmes credentials en dev et prod
- Stocker des credentials dans le code source

#### Mode lecture seule

```bash
bunkle pull mon-api --readonly
# Affiche : DATABASE_URL=post****5432
```

Utile pour vérifier les variables sans exposer les valeurs lors d'un partage d'écran.

## Liens

- Documentation : /docs
- Installation : /docs/installation
- Démarrage rapide : /docs/quickstart
- Commandes : /docs/commands/*
- Guides : /docs/guides/*