Organisations et Projets Scaleway : structurer et isoler vos ressources

Parcours en cours de construction

Ce parcours Scaleway est en cours de production. Les pages sortent par vagues ; certains volets sont encore en construction.

Avant de multiplier les ressources, il faut savoir où elles vivent et comment les cloisonner. Chez Scaleway, tout s'organise en deux niveaux : l'Organization (votre compte) et les Projects (des espaces de travail). Ce guide vous explique cette hiérarchie et ce qui se décide à chaque étage, vous aide à choisir un découpage qui tiendra dans la durée, puis vous fait créer un projet, le cibler dans vos commandes, lire sa consommation et le supprimer proprement. C'est le socle de gouvernance sur lequel s'appuieront la facturation, l'IAM et chaque lab de cette formation.

Ce que vous allez apprendre

Niveau : débutant à intermédiaire. Prérequis : la CLI scw configurée.

À la fin de cette page, vous saurez :

• Distinguer une Organization d'un Project, et ce qui se gère à chaque niveau
• Découper vos projets par environnement, avec une convention qui survit aux réorganisations
• Créer, lister, cibler et supprimer un projet avec scw
• Lire la consommation d'un seul projet
• Retrouver votre Organization ID et vos Project ID sans les confondre

Organization et Project : qu'est-ce qui se gère à quel niveau ?

Une Organization est le conteneur racine de votre compte ; un Project est un regroupement de ressources à l'intérieur, et chaque objet Scaleway se gère à l'un de ces deux niveaux, jamais aux deux. L'Organization est créée automatiquement à l'inscription, et vous en êtes le propriétaire (Owner). Le Project par défaut naît avec elle.

Le tableau ci-dessous se lit comme une carte : la colonne Niveau dit où chercher un réglage, et donc quelle portée donner à une politique IAM qui doit y donner accès (page « IAM concepts », validée le 2025-10-29).

Ce que vous voulez gérer	Niveau	Conséquence
Facturation, moyens de paiement, factures	Organization	un seul relevé, une seule facture, ventilée par projet
IAM : utilisateurs, applications, groupes, politiques, clés API	Organization	une identité existe pour toute l'organisation, ses droits se limitent projet par projet
Quotas	Organization	le quota de GP1-XS se partage entre tous vos projets
Support et tickets	Organization	un plan de support pour tout le compte
Réglages de sécurité (MFA, expiration des clés)	Organization	s'appliquent à tous les membres
Instances, volumes, buckets, VPC, clusters, bases	Project	vivent dans un projet, ne le quittent pas
Clés SSH	Project	à enregistrer dans chaque projet où l'on crée des Instances
VPC par défaut	Project et région	depuis le 13 mai 2025, plus aucun VPC n'est pré-créé dans un nouveau projet

Glissez pour voir

Voici comment ces niveaux s'emboîtent : une Organization contient un ou plusieurs Projects, et chaque projet regroupe ses ressources.

Voyons cela concrètement. Listez les projets de votre Organization :

scw account project list

La sortie affiche au moins votre projet par défaut (souvent nommé default), avec son ID de projet et l'ID de l'Organization auquel il appartient.

Pourquoi le projet par défaut porte-t-il l'ID de l'Organization ?

Parce que le projet par défaut est né avec l'Organization et en a reçu l'identifiant : default-project-id et default-organization-id sont identiques tant que vous n'avez pas créé d'autre projet. C'est un détail qui déroute les débutants et qu'il vaut mieux connaître avant de configurer Terraform, où les deux champs sont demandés séparément.

Vérifiez-le sur votre propre compte, c'est la manipulation d'observation de cette leçon :

scw account project list -o json \
  | python3 -c 'import sys,json; [print(p["name"], "| projet:", p["id"][:8], "| organisation:", p["organization_id"][:8], "| identiques:", p["id"]==p["organization_id"]) for p in json.load(sys.stdin)]'

Pour le projet par défaut, la dernière colonne doit afficher True ; pour tout autre projet, False. Reconfirmé le 2026-09-08 sur l'organisation de test de cette formation. Ce statut « par défaut » ne peut pas être transféré à un autre projet, ni supprimé ; son nom, lui, reste modifiable.

Comment découper ses projets ?

Découpez par environnement et par système, jamais par personne : les équipes se réorganisent, les environnements durent. Le tableau se lit ligne par ligne, la colonne Quand dit dans quelle situation le découpage s'impose.

Découpage	Quand	Pourquoi
Un projet prod, un projet staging, un projet lab	dès le deuxième environnement	une politique IAM par projet, une ligne de consommation par projet, un teardown du lab sans risque pour la prod
Un projet par système ou par client	plusieurs applications indépendantes	la portée d'une politique s'appuie sur les projets : sans séparation, il n'y a rien à restreindre
Un projet par lab de formation	chaque volet de ce parcours	tout supprimer d'un coup en fin de session, et voir immédiatement ce qui reste
Le projet par défaut réservé à rien d'important	toujours	il ne peut être ni supprimé ni transféré ; il ne devrait pas héberger la production

Glissez pour voir

Une convention de nommage tient en trois segments : <système>-<environnement> (boutique-prod, boutique-staging), et pour les labs lab-<sujet>. Le champ description du projet dit qui le possède et jusqu'à quand il doit exister. Un projet dont personne ne sait à quoi il sert finit par héberger des ressources dont personne ne sait à quoi elles servent, et ces ressources se facturent au gigaoctet-heure ou à la minute sans que personne ne les réclame. La convention a une seconde vertu : elle rend les politiques IAM lisibles, parce qu'une règle « InstancesFullAccess sur boutique-staging » se comprend sans ouvrir la console, là où la même règle sur un projet nommé test2 demande une enquête. Le nom d'un projet est la première ligne de sa documentation.

Depuis le 28 août 2026, l'outil Resource Explorer, en bêta publique, liste les ressources d'une Organization à travers ses projets et ses régions : c'est l'inventaire qui manquait pour retrouver ce qu'un mauvais découpage a dispersé. Bêta oblige, ne bâtissez pas encore de procédure dessus.

Comment créer un projet pour isoler un environnement ?

La bonne pratique, dès qu'un usage devient sérieux, est de lui dédier un projet. Pour vos tests de formation, un projet lab séparé évite de polluer un environnement important et permet de tout supprimer d'un coup en fin de session.

1. Créer le projet :

   scw account project create name=lab-formation description="Environnement de test, a supprimer en fin de session"

   La sortie affiche le nouveau Project ID, différent de celui de l'Organisation.

2. Consulter le projet (attention à la syntaxe, voir l'encadré) :

   scw account project get project-id=VOTRE_PROJECT_ID

   La sortie doit afficher le nom, la description et la date de création.

3. Supprimer le projet quand vous n'en avez plus besoin :

   scw account project delete project-id=VOTRE_PROJECT_ID
   scw account project list

   La liste ne doit plus contenir lab-formation.

get et delete attendent project-id=

Contrairement à beaucoup de commandes scw, account project get et account project delete ne prennent pas l'identifiant en argument positionnel : il faut écrire project-id=<id>. Un simple scw account project delete <id> échoue avec « Valid arguments are: project-id ». Un projet ne se supprime que s'il ne contient plus de ressources.

Comment cibler un projet précis ?

Par défaut, vos commandes agissent dans le projet par défaut de votre profil ; pour travailler dans un autre projet, deux options existent, et l'une des deux se vérifie.

Pour une commande ponctuelle, passez l'argument project-id :

scw instance server list project-id=VOTRE_PROJECT_ID

Pour toute une session, fixez le projet par défaut de votre profil scw, puis relisez-le :

scw config set default-project-id=VOTRE_PROJECT_ID
scw config get default-project-id

La seconde commande doit renvoyer l'identifiant que vous venez de passer. C'est le pendant, côté projet, de la région et de la zone par défaut vues précédemment. Un profil scw dédié à votre lab, pointant sur le projet lab, est le montage le plus sûr : on ne crée pas une ressource dans le mauvais projet parce qu'on a oublié de changer de contexte. La variable SCW_DEFAULT_PROJECT_ID, si elle est exportée, l'emporte sur le fichier : c'est le premier endroit où chercher quand une commande atterrit dans le mauvais projet.

Lire la consommation d'un seul projet

La facturation se gère au niveau de l'Organization, mais la consommation se lit projet par projet, et c'est ce qui rend le découpage rentable. L'argument project-id de scw billing consumption list filtre la consommation du mois ; billing-period=YYYY-MM remonte à un mois passé.

scw billing consumption list project-id=VOTRE_PROJECT_ID -o json \
  | python3 -c 'import sys,json; d=json.load(sys.stdin); print(len(d), "lignes,", round(sum(x["value"]["units"]+x["value"]["nanos"]/1e9 for x in d),2), "EUR")'

Sur un projet de lab fraîchement créé, la sortie doit afficher 0 lignes, 0 EUR. Sur le projet par défaut de l'organisation de test de cette formation, mesuré le 2026-09-08 : 13 lignes, 3,04 € pour le mois. C'est cette lecture par projet qui vous dira, à la fin de chaque volet, si le lab a bien été détruit.

Retrouver ses identifiants

Deux identifiants reviennent partout, l'Organization ID et le Project ID, et on les confond d'autant plus facilement que le projet par défaut porte le même que l'organisation.

L'Organization ID se trouve dans la console, page Paramètres de l'organisation, avec un bouton Copier l'ID. Le Project ID se trouve dans les paramètres du projet, ou dans la sortie de scw account project list. En ligne de commande, scw config get default-organization-id et scw config get default-project-id donnent ceux du profil courant.

Un alias plutôt qu'un identifiant

Se connecter et jongler avec un identifiant d'organisation long et illisible n'est pas pratique. La console propose un alias d'organisation : un nom que vous choisissez pour vous connecter à la place de l'ID (via une URL alias.account.scaleway.com). Un confort appréciable, en particulier pour la connexion des membres de votre organisation, qui s'identifient par l'organisation, un nom d'utilisateur et un mot de passe.

Des projets qui traversent les régions

Un Project est transverse aux régions : vous pouvez regrouper dans un même projet des ressources situées à Paris, Amsterdam ou Varsovie. Le projet est donc une frontière d'organisation et de droits, pas une frontière géographique. La localité, elle, se choisit ressource par ressource via la zone ou la région. Une nuance depuis le 13 mai 2025 (page « VPC concepts ») : un nouveau projet ne reçoit plus de VPC par défaut par région ; le premier Private Network d'une région dans ce projet exigera d'abord un VPC.

Limites, quotas et plafonds

Ces valeurs viennent de la page officielle des quotas d'Organisation (validée le 2025-10-29) et des concepts Organizations and Projects ; elles bornent le découpage avant toute question de coût.

Plafond	Valeur	Source
Projets par Organisation	25	quotas d'Organisation
Projet par défaut	1, non supprimable, statut non transférable, nom modifiable	concepts Organizations and Projects
Portée d'une politique IAM	Project (un, plusieurs ou tous) ou Organization	concepts IAM
Principal par politique	1 (utilisateur, application ou groupe)	concepts IAM
Clés SSH par Organisation	50	quotas d'Organisation
VPC par défaut dans un projet créé après le 13 mai 2025	0, à créer	concepts VPC
Filtre de consommation	project-id et billing-period=YYYY-MM	scw billing consumption list -h

Glissez pour voir

Le plafond de 25 projets se heurte vite à un découpage par personne ou par expérience. Un projet par environnement et par système suffit à une PME pendant des années ; un projet par développeur atteint la limite en un trimestre.

Antipatterns à éviter

Ces erreurs ont en commun de rendre l'IAM et la facturation illisibles, sans qu'aucune commande ne refuse jamais rien.

Antipattern	Conséquence	Discipline
Tout dans le projet par défaut	impossible d'isoler, de facturer ou de nettoyer séparément ; le projet ne peut pas être supprimé	production, staging et lab dans trois projets
Un projet par personne	limite de 25 atteinte, ressources orphelines au départ de chacun	projets par système et environnement, droits par politique IAM
Supprimer le projet « pour nettoyer » sans lister ses ressources	refus, puis ressources oubliées dans un projet qu'on croit vide	relister chaque famille de ressources, puis supprimer
Donner à une identité une portée Organization par commodité	elle voit et touche tous les projets, prod comprise	portée limitée aux projets nécessaires ; Organization réservée à la facturation et à l'IAM
Enregistrer la clé SSH dans un seul projet	connexion refusée sur les Instances des autres projets	une clé SSH par projet où l'on crée des Instances

Glissez pour voir

Organisations et Projets sous l'angle Well-Architected

Operational Excellence : un projet dit ce qu'il contient

Quelqu'un qui découvre votre compte peut-il deviner à quoi sert chaque projet ? Oui, si le nom suit <système>-<environnement> et si la description dit qui le possède. La discipline est de créer le projet avant la première ressource, jamais après, et de réserver le projet par défaut à ce qui n'a pas d'importance.

Security : le projet est le rayon d'explosion

Que peut casser une clé API compromise ? Tout ce que sa politique autorise, dans les projets qu'elle couvre. La discipline est de faire coïncider la portée des politiques avec les projets : une identité de lab ne voit que le projet de lab, et une écriture hors périmètre répond insufficient permissions. Le volet Sécurité en fait la démonstration.

Cost Optimization : une ligne de consommation par projet

Combien coûte le lab de ce mois, sans mélanger avec la production ? scw billing consumption list project-id=… répond en une commande, à condition que le lab ait son projet. La discipline est de lire cette ligne en fin de session et de la vouloir à zéro.

Pièges courants

Le tableau se lit par la colonne Symptôme : c'est ce que vous voyez à l'écran, message exact compris quand il y en a un ; la colonne Cause dit ce qui se passe réellement, et la colonne Solution la commande ou le geste qui débloque.

Symptôme	Cause	Solution
Valid arguments are: project-id	identifiant passé en positionnel	écrire project-id=<id> pour get et delete
Une commande vise le mauvais espace	confusion Organization ID / Project ID, ou SCW_DEFAULT_PROJECT_ID exportée	scw config get default-project-id, scw account project list
Impossible de supprimer un projet	il contient encore des ressources	relister serveurs, volumes, IP, buckets, VPC ; supprimer ; réessayer
Impossible de supprimer le projet par défaut	le projet par défaut ne se supprime pas	créer un autre projet pour vos essais
Impossible de créer un Private Network dans un projet neuf	aucun VPC dans la région depuis le 13 mai 2025	créer un VPC d'abord
Permission denied en SSH sur une Instance d'un autre projet	clé SSH enregistrée dans un autre projet	enregistrer la clé publique dans ce projet, puis redémarrer l'Instance

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• L'Organization porte facturation, IAM, quotas, support et sécurité ; le Project regroupe les ressources et les clés SSH.
• Le projet par défaut porte le même ID que l'Organization, ne se supprime pas, ne se transfère pas ; vérifiable avec scw account project list -o json.
• Une Organisation compte 25 projets au maximum : découpez par système et environnement, jamais par personne.
• On crée avec scw account project create ; get et delete attendent project-id=<id> ; un projet ne se supprime que vide.
• On cible un projet avec project-id= (ponctuel) ou scw config set default-project-id= (session), et SCW_DEFAULT_PROJECT_ID exportée l'emporte.
• scw billing consumption list project-id=… donne la consommation d'un seul projet ; 13 lignes, 3,04 € sur le projet de test le 2026-09-08.
• Un Project est transverse aux régions : frontière de droits, pas de géographie ; depuis le 13 mai 2025, plus de VPC par défaut.
• Resource Explorer (bêta publique depuis le 28 août 2026) inventorie les ressources à travers projets et régions.

Pour aller plus loin

• Object Storage : Le stockage objet, dont les clés API portent un projet préféré, une conséquence directe de ce découpage.
• Lab fil rouge des Fondations : Un projet dédié créé au début, supprimé à la fin, et la consommation lue entre les deux.
• IAM : donner le droit minimal à une CI : La portée d'une politique s'appuie sur les projets ; sans découpage, il n'y a rien à restreindre.

Ressources externes

Les pages officielles sur lesquelles cette leçon s'appuie, avec ce qu'on y cherche ; leur champ de validation date chaque fait cité.

• Organizations and Projects concepts : projet par défaut, portée transverse aux régions, quotas.
• Organization quotas : la limite de 25 projets et les quotas par produit.
• IAM concepts : ce qui se gère au niveau Organization et ce qui se limite au Project.
• VPC concepts : la fin des VPC par défaut pour les projets créés après le 13 mai 2025.

×

📖 Voir la documentation →