OUTSCALE multi-comptes : patterns de séparation des environnements

Une fois l’identité posée à l’intérieur d’un compte (cf. EIM identité et accès), la question structurante suivante est : un seul compte ou plusieurs ?. Cette page traite des patterns de séparation par compte OUTSCALE — quand multi-comptes apporte de la valeur, comment se met en place la mécanique paying account / linked accounts, et quels patterns choisir selon votre contexte. Page tagguée pour les piliers Well-Architected Security (isolation), Operational Excellence (clarté opérationnelle) et Cost Optimization (suivi par centre de coût).

Ce que vous allez apprendre

Pourquoi penser multi-comptes dès la conception de l’architecture, plutôt que de tout regrouper dans un compte unique.
La mécanique OUTSCALE : paying account, linked accounts, facturation consolidée.
Quatre patterns courants : par environnement, par projet, par équipe, compte audit dédié.
Quand multi-comptes apporte de la valeur vs. quand des groups EIM dans un compte unique suffisent.
La discipline de tagging indispensable pour relier des ressources dispersées sur plusieurs comptes.

Prérequis

Avoir lu EIM identité et accès pour comprendre les concepts root user, EIM users, groups, policies.
Connaître le vocabulaire OUTSCALE ↔ AWS.
Notions de gouvernance cloud : centre de coût, environnements (dev / staging / prod), périmètres de sécurité.

Pourquoi penser multi-comptes

Un compte OUTSCALE est une frontière forte : il est isolé en termes d’IAM (un EIM user d’un compte ne voit pas l’autre compte), de réseau (les Nets et Subnets sont locaux à un compte), de quotas, et de facturation. Cette isolation forte a deux conséquences directes.

D’un côté, elle apporte des bénéfices structurants :

Isolation des incidents — une compromission d’un compte de dev ne touche pas la prod.
Limitation du blast radius — une mauvaise commande supprime au pire toutes les ressources d’un compte, pas l’ensemble.
Clarté de la facturation — chaque compte génère sa propre facture détaillée, ce qui rend trivial la répartition par projet ou par équipe.
Quotas indépendants — l’épuisement d’un quota dans un compte n’impacte pas les autres.
Conformité simplifiée — un compte dédié SecNumCloud (cloudgouv-eu-west-1) reste totalement séparé d’un compte commercial (eu-west-2).

De l’autre côté, elle a un coût opérationnel :

Multiplier les comptes multiplie les provisionnements EIM (chaque compte a ses utilisateurs, groups, policies).
Les flux réseau inter-comptes demandent une configuration explicite (peering, lien dédié).
La gouvernance (qui crée un compte, qui le ferme, qui paye) doit être structurée.

L’arbitrage classique : isoler ce qui doit l’être, mutualiser ce qui peut l’être.

Le modèle OUTSCALE — paying account et linked accounts

OUTSCALE expose un modèle simple de regroupement de comptes pour la facturation : un compte payeur (paying account) peut être associé à plusieurs comptes liés (linked accounts), et reçoit la facture consolidée de l’ensemble.

Ce que la mécanique permet

Une seule facture émise au paying account, qui couvre la consommation de tous les comptes liés.
Reporting consolidé via l’API et Cockpit : depuis le paying account, vous pouvez consulter la consommation agrégée de tous les comptes liés, par service, par sous-région et par plage de dates.
Indépendance opérationnelle maintenue : chaque compte lié reste isolé au niveau des ressources, des EIM users, du réseau. Le lien est purement financier et reporting.

Comment consulter la consommation consolidée

Depuis le paying account, l’API ReadConsumptionAccount avec le paramètre Overall: true retourne la consommation consolidée. La période se définit avec FromDate et ToDate au format ISO 8601 (YYYY-MM-DD). Exemple en oapi-cli :

# Sélection du profil paying-account via la variable d'environnement OSC_PROFILE
export OSC_PROFILE=paying-account

oapi-cli ReadConsumptionAccount \
  --Overall true \
  --FromDate "2026-04-01" \
  --ToDate "2026-04-30"

Depuis un compte lié, le même appel avec Overall: true retourne rien — la consolidation n’est accessible que depuis le paying account. C’est cohérent avec le modèle d’isolation : un compte lié ne voit pas la consommation des autres comptes du groupe.

Pour travailler sur plusieurs comptes OUTSCALE depuis la même machine, définir plusieurs profils dans ~/.osc/config.json (un par compte) et basculer via la variable d’environnement OSC_PROFILE :

# Bascule sur le profil prod
export OSC_PROFILE=prod
oapi-cli ReadVms

# Bascule sur le profil audit
export OSC_PROFILE=audit
oapi-cli ReadConsumptionAccount --Overall true

Permissions du fichier : chmod 600. Détails dans la page Outils CLI OUTSCALE.

Ce que la mécanique ne fait pas

Le modèle paying / linked d’OUTSCALE traite principalement la facturation et le reporting consolidé. Il ne propose pas nativement :

Une hiérarchie organisationnelle complexe (équivalent des Organizational Units AWS).
Des policies de service appliquées globalement à plusieurs comptes (équivalent des Service Control Policies AWS).
Une fédération SSO automatique entre comptes — chaque compte gère ses propres EIM users (la fédération SSO se configure compte par compte, vers votre IdP).

Si vous avez besoin de gouvernance multi-comptes plus poussée, elle se construit côté client : un IdP central pour la fédération, un référentiel partagé de policies EIM (réutilisées par script ou Terraform), une stratégie de tagging discipline (cf. plus bas).

Quatre patterns courants de séparation

Ces patterns ne s’excluent pas — beaucoup d’organisations les combinent (par exemple : un compte par environnement et un compte audit transversal).

Pattern 1 — Un compte par environnement (dev / staging / prod)

C’est le pattern le plus courant et le plus structurant. Chaque environnement est dans un compte dédié, ce qui isole fortement les incidents et clarifie la gouvernance.

Compte	Rôle	Accès humain
`prod`	Production de l’application	Restreint — seulement Ops + RSSI + break-glass
`staging`	Pré-production miroir	Ouvert à Dev + Ops
`dev`	Développement, expérimentation	Ouvert à Dev

Bénéfices :

Une mauvaise commande en dev ne touche pas la prod.
Les fenêtres de déploiement prod sont matérialisées par un changement de compte explicite.
Les quotas prod sont indépendants — un test stress en dev ne bloque pas le scaling de la prod.
La facture prod est isolée — comptable et FinOps directs.

Coût :

Trois jeux d’EIM users à provisionner (sauf fédération SSO bien faite).
Trois Nets, trois jeux de Subnets, trois Route Tables.
Synchronisation explicite des configurations entre environnements (gérée en IaC — voir Volet 3).

C’est le pattern par défaut pour toute application en production sérieuse.

Pattern 2 — Un compte par projet ou produit

Dans une organisation qui héberge plusieurs produits indépendants, chaque produit prend son compte. Cela isole les équipes, les budgets, les incidents.

Compte	Rôle
`produit-alpha`	Toute l’infra du produit Alpha (dev + staging + prod selon la maturité)
`produit-beta`	Toute l’infra du produit Beta
`transversal`	Services partagés (DNS, observabilité, IdP)

Ce pattern peut se combiner avec le pattern par environnement : alpha-prod, alpha-staging, alpha-dev, beta-prod, etc. Le nombre de comptes augmente mais l’isolation est maximale.

Pattern 3 — Un compte par équipe / business unit

Pour une grande organisation, chaque business unit (BU) ou équipe métier dispose de son compte. La facturation consolidée remonte au paying account central, mais chaque BU gère son budget et ses ressources.

Compte	Rôle
`bu-finance`	Infrastructure de la BU Finance
`bu-rh`	Infrastructure de la BU RH
`bu-it-shared`	Services IT mutualisés
`paying`	Compte payeur central

Ce pattern délègue la responsabilité opérationnelle aux BUs tout en conservant une vue financière centralisée côté DSI.

Pattern 4 — Compte audit / sécurité dédié

Quel que soit le pattern principal retenu, un compte « audit » transversal est une bonne pratique pour la sécurité et la conformité.

Compte audit	Rôle
`audit`	Réception centralisée des logs OMS de tous les comptes du groupe, exécution des scans de posture (audit Well-Architected), accueil de l’IdP fédéré

Caractéristiques typiques d’un compte audit :

Accès très restreint — uniquement RSSI, audit interne, automation dédiée.
MFA matérielle sur tous les comptes humains.
Lecture seule sur les autres comptes via roles cross-account ou exports de logs.
API Access Rules restrictives (IP du SOC ou du runner CI/CD d’audit).

Ce compte sert aussi de point de centralisation pour :

Les rapports de conformité (preuves SecNumCloud, ISO, HDS).
L’audit des accès sur l’ensemble du groupe.
Les archives long terme des logs et exports OOS critiques.

Multi-comptes ou groups EIM ? Le critère de décision

Pour des structures plus petites ou des projets en début de cycle, il n’est pas toujours pertinent de partir directement en multi-comptes. Une séparation par groups EIM dans un seul compte peut suffire.

Critère	Multi-comptes adapté	Groups EIM dans un compte unique adapté
Production critique en jeu	✅	❌
Plusieurs équipes / BUs autonomes	✅	❌
Conformité réglementaire stricte (OIV, OSE)	✅	❌
FinOps avec répartition de coûts par projet	✅	⚠️ (possible via tagging mais moins propre)
Petite équipe, un seul projet, charge limitée	❌	✅
Phase exploratoire, prototype	❌	✅
Coût opérationnel à minimiser	❌	✅

Trajectoire fréquente : démarrer avec groups EIM dans un compte unique sur un projet pilote, puis basculer vers multi-comptes par environnement dès que la production se profile. Ce point de bascule est l’un des seuils de maturité d’une équipe cloud.

La discipline de tagging — indispensable

Avec ou sans multi-comptes, une stratégie de tagging disciplinée est indispensable pour relier les ressources dispersées et alimenter le reporting FinOps.

Tags structurants à mettre en place dès le J1

Tag	Valeur exemple	Pilier WAF	Usage
`env`	`prod`, `staging`, `dev`	OperationalExcellence	Distinguer les environnements
`project`	`monprojet`	OperationalExcellence	Regrouper par projet
`owner`	`equipe-data`	OperationalExcellence	Identifier le responsable
`cost-center`	`cc-1234`	Cost	Imputer les coûts en FinOps
`compliance`	`secnumcloud`, `hds`	Sovereignty	Signaler les contraintes réglementaires
`lifecycle`	`permanent`, `temporary`	Cost	Identifier les ressources temporaires à nettoyer

Cette stratégie doit être commune à tous les comptes du groupe — c’est ce qui permet, par exemple, de répondre à la question « combien coûte le projet X au total, tous environnements confondus ? » en agrégeant les exports de consommation des comptes prod, staging et dev.

Appliquer les tags via la CLI

# Taguer une VM existante
oapi-cli CreateTags \
  --ResourceIds '["i-12345678"]' \
  --Tags '[
    {"Key": "env", "Value": "prod"},
    {"Key": "project", "Value": "monprojet"},
    {"Key": "owner", "Value": "equipe-data"},
    {"Key": "cost-center", "Value": "cc-1234"}
  ]'

Mieux : appliquer les tags dès la création des ressources, dans le code Terraform (Volet 3), pour qu’aucune ressource ne soit créée sans son jeu de tags structurants.

Bonnes pratiques (par pilier Well-Architected)

1. Multi-comptes par environnement dès la prod — pilier Security

Dès qu’une production sérieuse est en jeu, séparer prod dans un compte dédié, distinct des comptes staging et dev. Cette discipline limite drastiquement le blast radius d’une erreur ou d’une compromission.

2. Compte audit transversal — piliers Security + Operational Excellence

Mettre en place un compte audit dédié pour centraliser les logs OMS, les exports de conformité et les scans de posture. Ce compte est un investissement opérationnel qui paye au premier audit ou au premier incident.

3. Fédération SSO vers un IdP central — piliers Security + Operational Excellence

Plutôt que de gérer des EIM users séparément dans chaque compte, fédérer tous les comptes vers le même IdP. Le cycle de vie des accès devient transverse : un employé qui quitte est révoqué partout en une seule action.

4. Tagging commun aux comptes du groupe — piliers Cost + Operational Excellence

Stratégie de tagging unifiée entre tous les comptes du groupe (env, project, owner, cost-center, compliance, lifecycle). C’est ce qui permet ensuite l’agrégation FinOps par projet, par équipe ou par centre de coût, indépendamment de la structure multi-comptes.

5. Consolidation des coûts par paying account — pilier Cost

Choisir un paying account central pour le groupe, et utiliser la consolidation via l’API ReadConsumptionAccount pour le reporting global. Cela simplifie la facturation comptable et donne une vue financière unique quel que soit le nombre de comptes liés.

6. Documentation des relations entre comptes — pilier Operational Excellence

Maintenir un document interne (typiquement dans le wiki d’équipe ou un README dans un dépôt Git) qui liste tous les comptes du groupe, leur rôle, le paying account, les EIM admins, les contacts. Ce document devient la source de vérité pour les opérations transverses.

Antipatterns à éviter

Antipattern	Conséquence	Discipline correcte
Tout dans un seul compte « pour simplifier »	Une compromission impacte toute l’infra ; impossible de séparer FinOps	Multi-comptes par environnement dès la prod
Trop de comptes trop tôt	Sur-engineering, coût opérationnel élevé sur un petit projet	Démarrer en groups EIM, basculer multi-comptes au bon moment
Tagging incohérent entre comptes	Reporting FinOps cassé, impossible d’agréger par projet	Tagging unifié documenté, appliqué en IaC
EIM users séparés par compte sans SSO	Comptes orphelins après départ d’un employé	Fédération SSO vers un IdP central
Pas de compte audit	Les logs OMS et la posture sont dispersés sur N comptes	Compte audit transversal dès le J1 du multi-comptes

Multi-comptes sous l’angle Well-Architected

Security — isolation et blast radius

La séparation par compte est l’outil le plus radical pour limiter le blast radius. Sur un compte unique, une AK/SK qui fuit avec une policy Allow * permet à un attaquant de toucher toutes les ressources. Sur multi-comptes bien fait, l’attaquant est cantonné au compte compromis — la prod reste protégée si elle est dans un autre compte.

Le compte audit dédié et la fédération SSO vers un IdP central sont des compléments essentiels du pattern.

Operational Excellence — clarté opérationnelle

Multi-comptes apporte de la clarté : qui possède quoi, qui paye quoi, qui peut accéder à quoi. Cette clarté simplifie la gouvernance et facilite l’onboarding des nouvelles équipes.

Le coût opérationnel (provisionnement EIM, configuration réseau inter-comptes) est compensé par l’industrialisation IaC (Volet 3) qui rend la création d’un nouveau compte structuré quasi gratuite.

Cost Optimization — répartition et FinOps

La facturation par compte est le moyen le plus simple de répartir les coûts par projet, par équipe ou par centre de coût. Combiné au tagging unifié, cela alimente directement un reporting FinOps actionnable.

Le paying account centralise le paiement tout en conservant la lisibilité par compte lié.

Sovereignty — séparation entre commercial et SecNumCloud

Pour une organisation qui mélange charges commerciales (eu-west-2) et charges SecNumCloud (cloudgouv-eu-west-1), avoir des comptes distincts pour chaque catégorie clarifie la gouvernance souveraine. Le compte SecNumCloud peut faire l’objet de règles d’accès renforcées (API Access Rules restrictives, MFA matérielle obligatoire, audit dédié).

À retenir

Un compte OUTSCALE est une frontière forte d’isolation : IAM, réseau, quotas, facturation.
Le modèle OUTSCALE expose un paying account + linked accounts avec facturation consolidée — la consolidation se consulte via l’API ReadConsumptionAccount avec Overall: true.
Quatre patterns courants (combinables) : par environnement, par projet, par équipe / BU, compte audit transversal.
Multi-comptes par environnement dès qu’une production sérieuse est en jeu — la séparation est l’outil le plus radical pour limiter le blast radius.
Pour les petits projets ou phases exploratoires, des groups EIM dans un compte unique restent acceptables.
Tagging unifié (env, project, owner, cost-center, compliance, lifecycle) appliqué dès le J1 et commun à tous les comptes du groupe.
Compte audit dédié + fédération SSO vers un IdP central = bonnes pratiques structurantes pour tout groupe multi-comptes.

Prochaines étapes

EIM identité et accès Les concepts root user, EIM users, groups, policies, MFA — préalable à toute structuration multi-comptes.

Réseau — design Net + Subnets Concevoir un réseau par compte, avec stratégie multi-AZ.

Découverte du Cockpit OUTSCALE My Data > My Consumption pour visualiser la consommation consolidée.

Outils CLI OUTSCALE Configuration multi-profils oapi-cli pour basculer entre comptes.