Intégrateur Scaleway API : relier projet, localisation, ressource et état réel
Scaleway expose un endpoint commun, mais chaque API est globale, régionale ou zonale et porte sa version dans l’URL. Dawap rend cette géométrie explicite, associe chaque ressource au bon projet et vérifie son état réel avant de fermer le workflow métier.
Réponse courte
Une ressource Scaleway n’existe qu’avec son projet et sa localisation exacts.
Dawap relie Organization, Project, API version, zone ou région, resource ID et identité IAM à la demande métier. Aucun projet client Scaleway nommé n’est publié : les références plus bas prouvent des garde-fous adjacents, pas une réalisation Scaleway.
- Choisir le scope global, régional ou zonal de chaque API et l’inventorier sans trou.
- Dédier une application IAM et une clé dont les permissions et le projet préféré sont vérifiés.
- Relire ressource, statut, dépendances réseau/stockage et effet métier avant de clore.
La géographie comme donnée de contrat
Global, région, zone : l’inventaire doit prouver sa couverture.
Cette matrice rend visibles les scopes interrogés, les pages effectivement lues et les erreurs partielles. Une absence de résultat ne devient jamais une absence de ressource sans couverture démontrée.
- 01Policy IAMrefus hors périmètre attendutest
- 02Signature S3région et accès bornéstest
- 03Bucket sentinellecréé dans le projet attendupreuve
- 04Révocationancienne clé retirée après basculeclôture
Signaux Scaleway
Trois défauts de scope qui fabriquent une vision fausse du cloud
Une réponse vide ou un bucket visible ne suffisent pas. Projet, zone ou région, pagination et identité de la clé doivent décrire la même cible.
L’inventaire ne lit qu’une zone et se déclare complet
fr-par-1 ne dit rien de fr-par-2 ; chaque scope attendu et chaque page doivent être comptabilisés.
La rotation change le projet préféré Object Storage
Le même appel S3 peut alors créer un bucket dans un autre projet sans que le payload change.
L’Instance existe mais son réseau reste inutilisable
Statut, IP, Private Network, volumes et contrôle consommateur doivent converger avant clôture.
Architecture Scaleway API
Un inventaire vide peut seulement signifier que le client a interrogé la mauvaise zone
L’URL Scaleway encode produit, version et souvent zone ou région. Une intégration fiable conserve cette adresse complète, traite la pagination de chaque API et refuse les defaults implicites qui déplacent silencieusement une ressource.
Scope dans l’endpoint
Classer l’API comme globale, régionale ou zonale. Une liste d’Instances sur fr-par-1 ne dit rien de fr-par-2 ; une liste régionale ne remplace pas l’agrégation de toutes les localisations autorisées.
Version épinglée
Conserver produit et version dans le contrat. v1 désigne une interface GA ; v1beta1 et v1alpha1 sont pré-GA. Les SDK et schémas doivent être vérifiés avant toute migration de version.
Projet et ressource natifs
Exiger Organization ID, Project ID et resource ID. Nom et tags restent utiles au classement, mais ne sélectionnent jamais seuls une cible d’écriture.
Application IAM dédiée
Associer la clé à une application non humaine pour un usage durable, limiter sa policy et dater son expiration. La secret key n’est montrée qu’une fois et voyage dans X-Auth-Token pour l’API Scaleway.
Object Storage à part
L’API S3 utilise Signature v4. Pour créer ou lister des buckets, le projet n’est pas passé en paramètre : le projet préféré de la clé décide de la cible et doit survivre à la rotation.
État et dépendances relus
Après création ou action, suivre le statut documenté et relire réseau, IP, volume, bucket policy ou autre dépendance utile. Un 201 ne prouve pas une ressource utilisable par l’application.
Méthode
On dessine d’abord demande–projet–scope–ressource–consommateur sur une seule API
Le pilote refuse un Project ID manquant, prouve un 403 hors policy, détecte une mauvaise zone, traverse toutes les pages et relit l’effet consommateur. Pour Object Storage, la rotation de clé est testée avec son projet préféré avant toute bascule.
Décision 1
Projet et scope sans ambiguïté
Décision 2
Inventaire multi-zone complet
Décision 3
IAM et clé réellement bornés
Décision 4
Object Storage bien attribué
Premier lot Scaleway
Prouver une ressource dans un projet et une localisation non critiques.
On choisit une API stable, on exige Project ID et zone ou région, on provoque un refus IAM et une lecture hors scope, puis on crée ou modifie une ressource réversible et on relit son état avec ses dépendances.
Sorties concrètes
Matrice Organization × Project × produit × API version × global/région/zone × owner.
Contrat resource ID, état attendu, états transitoires, réseau, volumes/objets et effet métier.
Application IAM dédiée, policy, permission sets, access key, secret key et expiration bornée.
Recette 400, 401, 403, 404, 409, 429, pagination incomplète, mauvaise zone, timeout et reprise.
Recette Scaleway API
Trois contre-tests qui révèlent les faux succès de scope
La recette cherche ce qui distingue Scaleway : endpoint zonal incomplet, clé Object Storage attachée au mauvais projet et ressource créée mais pas encore exploitable.
Le portail affiche zéro Instance parce qu’il ne lit que fr-par-1
Les requêtes zonales ne retournent que leur zone. Un inventaire qui oublie fr-par-2 ou s’arrête au premier next_page_token produit un succès HTTP et une vision faussement complète du parc.
- Entrée
- Organization, Project, produit/version, zones/régions attendues, endpoint appelé, filtres, page_size, page_token, next_page_token, resource IDs, erreurs partielles et date de fraîcheur.
- Sortie
- Matrice de couverture, pagination exhaustive, résultat partiel explicitement marqué, déduplication et métrique de fraîcheur par scope.
- Décision
- Ne jamais publier un inventaire complet si une zone, une région ou une page attendue n’a pas été lue.
La clé est rotée et le nouveau bucket arrive dans un autre projet
Pour les opérations de création et de liste de buckets par API, aucun Project ID n’est disponible en paramètre : Scaleway utilise le projet préféré associé à la clé. Une rotation avec un autre default_project_id change donc la cible sans modifier le code appelant.
- Entrée
- Application IAM, key ID, bearer, policy, Organization, default_project_id avant/après, région S3, bucket, tags, facture, consumer test et date de rotation.
- Sortie
- Contrôle de projet préféré avant activation, double lecture pendant rotation, création sentinelle non critique et blocage si l’attribution diverge.
- Décision
- Ne pas activer une nouvelle clé Object Storage tant que son projet préféré et sa visibilité S3 ne sont pas vérifiés.
L’Instance existe, mais réseau, volume ou démarrage ne correspondent pas à la demande
La création de la ressource ne prouve ni son état démarré, ni l’attachement du bon volume ou de la bonne IP, ni l’accès applicatif. Une reprise aveugle peut en plus créer un second serveur si l’idempotence métier n’est pas portée par le portail.
- Entrée
- Request ID interne, Project ID, zone, server ID, type, image, volumes, IP/Private Network, security group, status, status_detail, timestamps, quota et contrôle applicatif.
- Sortie
- Clé d’idempotence métier, relecture par server ID, gates réseau/stockage/démarrage, timeout borné et procédure de suppression ou de réparation.
- Décision
- Clore seulement sur la ressource relue et le contrôle consommateur, jamais sur le seul 201.
Maillage API
Poursuivre dans le bon univers API
Ces liens permettent de repartir vers la page principale ou vers les univers proches quand le besoin dépasse le seul connecteur.
Avis & exigence projet
Ce que l’on sécurise avec Scaleway API
Produit, version, Project ID, zone/région et resource ID restent corrélés.
Application IAM, policy, clé, expiration et projet préféré sont vérifiés.
Création, statut, dépendances, consommateur, incident et reprise ne sont pas confondus.
Pour Branchassist, passer du SSO historique à Keycloak ne devait pas transférer aveuglément les autorisations. Dawap a séparé la connexion externe des droits internes : échange du code, contrôle de l’utilisateur actif, rôles Symfony, accès par ressource, révocation des jetons et trace des connexions. Une migration IAM ancrée dans l’application métier.
Pagination API garde le bon point de reprise quand un flux devient trop volumineux pour une simple navigation. Offset, cursor et keyset changent alors le coût de reprise, la stabilité du support et la pression sur les queues, sans créer de trous ni de doublons. Il protège le run et évite aussi les reprises à l’aveugle.
Audit trail API garde la preuve utile quand le support, la conformité et le run doivent reconstituer une action sans fouiller tout le système. La trace doit montrer qui a fait quoi, quand, sur quel endpoint et avec quel contexte, puis rester exploitable après incident. Il reste utile quand un incident tombe après coup.
Questions d’achat
Questions fréquentes sur l’intégration Scaleway API
Questions fréquentes sur Scaleway API, Projects, zones, régions, IAM, clés, Instances, Object Storage, pagination et reprise.
01Pourquoi faut-il distinguer API globale, régionale et zonale ?
Le scope fait partie de l’endpoint. IAM et Billing sont globaux, plusieurs services sont régionaux et les Instances sont zonales. Une liste ne couvre que la région ou la zone appelée ; l’inventaire doit parcourir explicitement tous les scopes attendus et toutes les pages.
02Comment choisir la version d’une API Scaleway ?
La version figure dans l’URL. v1 correspond à une interface GA, tandis que v1beta1 et v1alpha1 sont pré-GA. On épingle le contrat et le SDK, vérifie le schéma utilisé puis organise une migration testée avant le retrait d’une ancienne version.
03Comment sécuriser une clé API Scaleway ?
Pour un usage durable, on rattache la clé à une application IAM non humaine, limite sa policy aux permission sets et scopes requis, fixe une expiration quand possible et teste un refus hors périmètre. La secret key n’est visible qu’une fois et ne doit pas entrer dans les logs.
04Pourquoi le projet préféré compte-t-il pour Object Storage ?
Lors de la création ou de la liste de buckets par API, aucun Project ID ne peut être fourni : Scaleway utilise le projet préféré de la clé. Une rotation doit donc conserver et vérifier default_project_id, sinon le même code peut agir sur un autre projet.
05L’API Object Storage utilise-t-elle X-Auth-Token ?
L’API Scaleway utilise la secret key dans X-Auth-Token. L’accès direct Object Storage est compatible avec le protocole S3 et demande une Signature v4 utilisant l’access key et la secret key. Le connecteur sépare ces deux modes et protège les mêmes credentials.
06Quel premier lot Scaleway recommandez-vous ?
Une ressource réversible dans un projet et une zone non critiques : API/version épinglées, application IAM dédiée, refus hors scope, pagination complète, ressource relue avec réseau ou stockage et contrôle consommateur. Object Storage ajoute la vérification du projet préféré.
API cloud & infrastructure
Vous voulez connecter Scaleway sans perdre une ressource dans un mauvais scope ?
On peut cadrer un premier workflow, livrer son intégration et rendre chaque projet, localisation, permission, ressource et reprise vérifiable.
Cadrer mon workflow Scaleway