---
title: "Organiser vos environnements"
description: "Structurer dev, staging et production en plusieurs namespaces : quand en créer un, comment le demander, et le pattern tooling → dev/prod permis par le réseau intra-organisation."
source_url:
  html: https://docs.blackswift.cloud/operer/organiser-vos-environnements/
  md: https://docs.blackswift.cloud/operer/organiser-vos-environnements.md
---

# Organiser vos environnements

> Structurer dev, staging et production en plusieurs namespaces : quand en créer un, comment le demander, et le pattern tooling → dev/prod permis par le réseau intra-organisation.

Un même namespace peut héberger **plusieurs applications** sans le moindre
problème ; toutefois, créer un namespace dédié reste utile pour :

* **Séparer les environnements** (développement, staging, production) ;
* Réutiliser les *mêmes noms* de ressources — par exemple un `Service` nommé
  `api` ou une `ConfigMap` `settings` — sans collisions ;
* **Cloisonner les budgets** : chaque namespace a ses propres
  [quotas](https://docs.blackswift.cloud/reference/quotas-et-limites.md), donc son propre plafond de dépense.

:::note[Un namespace suffit souvent]
Si vos services partagent le même cycle de vie et la même équipe, il est souvent
plus simple de les garder dans un seul namespace. Nous conseillons néanmoins de
différencier au minimum développement et production.
:::

## Demander un namespace supplémentaire

La création est **gratuite** et passe par le
[support](https://docs.blackswift.cloud/depanner/contacter-le-support.md) (validation manuelle). Indiquez :

1. **Identifiant d'organisation complet** (ex. `acme-rtximz`) ;
2. **Nom souhaité** (ex. `staging`) — format `a-z`, `0-9`, `-`, commence par une
   lettre ;
3. **Usage** (dev, test, prod…).

Le namespace créé suivra le modèle :

```text
c-<identifiant-organisation>-<nom>
# Exemple : c-acme-rtximz-staging
```

## Le pattern dev / prod / tooling

Une organisation typique :

| Namespace | Rôle |
| --- | --- |
| `c-acme-rtximz-dev` | Développement — requests réduites, [scale à zéro la nuit](https://docs.blackswift.cloud/operer/consommation-et-facturation.md) |
| `c-acme-rtximz-prod` | Production — replicas ≥ 2, [HPA et PDB](https://docs.blackswift.cloud/operer/scaling-et-disponibilite.md) |
| `c-acme-rtximz-tooling` | Outillage transverse — CI, jobs d'administration, supervision maison |

Le [réseau intra-organisation étant ouvert](https://docs.blackswift.cloud/comprendre/isolation-reseau.md), le
namespace `tooling` peut joindre dev et prod sans configuration : pratique pour
un runner CI qui déploie partout, ou un outil de supervision maison.

Pour promouvoir une version entre environnements, utilisez **la même image,
taguée immuablement** (`v1.4.2`, un digest ou un SHA de commit — pas `latest`) et
ne changez entre namespaces que la configuration
([ConfigMaps/Secrets](https://docs.blackswift.cloud/deployer/configmaps-et-secrets.md)).

:::caution[dev peut joindre prod]
L'ouverture intra-organisation joue dans les deux sens : un pod de dev peut
joindre la base de prod, et
[aucune NetworkPolicy client ne peut l'empêcher](https://docs.blackswift.cloud/comprendre/isolation-reseau.md#le-piège-à-connaître--dev-peut-joindre-prod).
Protégez-vous par la configuration : des **secrets distincts par environnement**
(mots de passe de base différents en dev et en prod), et jamais d'URL de prod
dans une config de dev.
:::

## Bien démarrer un nouveau namespace

- Votre kubeconfig existant y donne accès immédiatement — mais son **namespace
  par défaut ne change pas** : pensez au `-n` ou changez de contexte
  ([rappel](https://docs.blackswift.cloud/demarrer/recuperer-votre-kubeconfig.md)) ;
- Chaque namespace reçoit ses propres quotas, son
  [Issuer TLS](https://docs.blackswift.cloud/deployer/exposer-en-https.md), son ServiceAccount CI et sa
  [sauvegarde quotidienne](https://docs.blackswift.cloud/operer/sauvegardes-et-restauration.md) — rien à
  configurer ;
- Multiplier les environnements multiplie les plafonds : deux namespaces = 2 × 20
  pods, 2 × 10 vCPU…