Terraform sur Scaleway : provisionner, et surtout détruire

Provisionner avec Terraform s'apprend en une heure ; détruire complètement s'apprend en se faisant piéger. Cette leçon déploie une infrastructure Scaleway réelle avec le provider officiel, puis la détruit, et s'attarde sur les obstacles rencontrés en conditions réelles : une gamme de volumes retirée par l'API, un snapshot qui refuse de se créer, et un destroy qui échoue trois fois de suite en laissant 28 ressources facturées derrière lui, à cause d'une régression du provider que le choix de version évite. Elle s'adresse à qui sait déjà écrire du HCL et découvre Scaleway. Vous en repartirez avec un état distant sur Object Storage, une version épinglée choisie en connaissance de cause, et une vérification de sortie qui prouve que le compte est vide plutôt que de le supposer.

Ce que vous allez apprendre

• Configurer le provider sans écrire un seul identifiant dans le code.
• Placer l'état sur Object Storage, pour qu'il survive à votre poste.
• Reconnaître une gamme retirée par l'API, et migrer vers ce qui la remplace.
• Détruire complètement, et le prouver plutôt que le supposer.

Prérequis

Cette leçon ne réexplique ni Terraform ni HCL : elle suppose acquis ce qui suit, et renvoie vers la formation correspondante plutôt que de la résumer.

• Savoir écrire du HCL et enchaîner terraform init, plan, apply et destroy, comprendre l'état et les providers : c'est le programme de la formation Terraform du site.
• Terraform 1.11 ou plus récent, la version qu'exige le bloc required_version ci-dessous et que demande le verrou du backend.
• Un compte Scaleway avec un projet dédié au lab et la CLI scw configurée sur un profil isolé, comme au volet Prendre en main.

Comment configurer le provider Scaleway sans clé dans le code ?

Un bloc provider ne doit contenir aucune clé. Le provider lit l'environnement et le fichier de configuration scw exactement comme la ligne de commande, ce qui rend le code publiable tel quel.

terraform {
  required_version = ">= 1.11"
  required_providers {
    scaleway = {
      source = "scaleway/scaleway"
      # Version VALIDÉE pour ce lab, création et destruction comprises.
      # 2.81.0 et 2.82.0 ne savent pas détruire une interface privée
      # attachée et laissent des ressources facturées derrière elles :
      # régression mesurée plus bas.
      version = "2.83.0"
    }
  }
}

provider "scaleway" {
  region = "fr-par"
  zone   = "fr-par-1"
}

Version publiée n'est pas version validée

Ce bloc épingle la version sur laquelle le lab a été rejoué de bout en bout, et c'est une décision, pas un réflexe. Les deux notions se confondent souvent, alors qu'elles répondent à deux questions différentes :

	Version amont	Version validée pour ce lab
Ce que c'est	la dernière publiée sur le registre	celle sur laquelle le lab a été exécuté de bout en bout, création et destruction comprises
Ici	2.83.0, publiée le 14 septembre 2026	2.83.0, rejouée le 14 septembre 2026
Pourquoi la distinction compte		les deux versions précédentes, 2.81.0 et 2.82.0, laissent 4 ressources facturées derrière elles au destroy, mesuré le 2026-09-09

Glissez pour voir

La discipline qui en découle vaut pour n'importe quelle dépendance. Épingler la dernière version publiée revient à supposer qu'elle marche ; épingler une version validée revient à savoir qu'elle marche. La différence se paie le jour où une régression sort, et elle se paie ici en ressources qui continuent de tourner.

Relevez donc, dans votre propre dépôt, la version amont, la version validée, la raison du choix et la date de validation. À chaque nouvelle version, cette note vous dira exactement quoi revérifier avant de remonter : ici, le destroy d'une interface attachée.

La version est épinglée à l'exact, pas en ~> 2.83. Une contrainte flottante laisse une publication amont modifier votre déploiement sans que vous ayez rien changé, ce qui est précisément la mécanique qui a introduit la régression de destruction documentée plus bas dans cette page. Un provider est une dépendance comme une autre : on choisit quand on la met à jour.

export SCW_ACCESS_KEY=$(scw config get access-key)
export SCW_SECRET_KEY=$(scw config get secret-key)
export SCW_DEFAULT_ORGANIZATION_ID=$(scw config get default-organization-id)
export SCW_DEFAULT_PROJECT_ID=$(scw config get default-project-id)

terraform init

terraform init télécharge le provider, vérifie sa signature et écrit .terraform.lock.hcl. Ce fichier se versionne : il garantit que votre chaîne d'intégration installe le binaire que vous avez validé, et pas celui publié depuis.

Le compte que Terraform utilise n'est pas toujours celui qu'on croit

Le provider lit les identifiants dans un ordre de précédence que la documentation officielle énonce ainsi : d'abord les variables d'environnement, ensuite les valeurs statiques du bloc provider, enfin le fichier ~/.config/scw/config.yaml. Une variable SCW_SECRET_KEY exportée écrase donc une clé écrite dans le bloc provider, et non l'inverse. Un poste où un profil scw est configuré déploiera sur ce compte dès qu'aucune variable n'est exportée.

Attention si vous enchaînez avec Ansible : la collection stephrobert.scaleway applique la précédence opposée, le paramètre du module gagnant sur la variable d'environnement. Les deux outils du volet ne se comportent pas pareil sur ce point, ce qui suffit à déployer sur le mauvais projet quand on passe de l'un à l'autre.

Avant un premier apply, vérifiez sur quel compte vous êtes :

scw config get default-project-id

C'est la même vigilance que sur la ligne de commande, et elle vaut d'autant plus que Terraform crée des ressources facturées.

Où stocker l'état Terraform sur Scaleway ?

L'état est le seul endroit où Terraform sait ce qu'il possède. Le perdre, c'est perdre la capacité de détruire proprement : les ressources continuent d'exister et de se facturer, et plus rien ne sait les nommer.

Sur un poste isolé, l'état local suffit pour apprendre. Dès qu'une équipe ou une chaîne d'intégration entre en jeu, il se place sur Object Storage, qui parle le protocole S3.

Le tableau ci-dessous se lit par la colonne de gauche : identifiez d'abord votre situation réelle, pas celle que vous visez, puis appliquez le choix de la ligne. Changer de backend plus tard se fait par terraform init -migrate-state, donc commencer simple ne coûte rien.

Besoin	Choix	Pourquoi
Apprendre seul, ressources jetables	état local, versionné nulle part	aucune dépendance à installer, et rien à perdre
Un seul opérateur, infrastructure durable	Object Storage avec versionnage du seau	l'état survit à la perte du poste, et se restaure par version
Équipe, ou chaîne d'intégration	Object Storage + use_lockfile = true	le verrou empêche deux apply concurrents d'écrire l'un sur l'autre, à partir de Terraform 1.11
Plusieurs environnements	un seau par environnement, pas un préfixe	une erreur de key ne peut alors pas écraser la production

Glissez pour voir

terraform {
  backend "s3" {
    bucket                      = "etat-terraform-equipe"
    key                         = "socle/terraform.tfstate"
    region                      = "fr-par"
    endpoints                   = { s3 = "https://s3.fr-par.scw.cloud" }
    use_lockfile                = true
    skip_credentials_validation = true
    skip_region_validation      = true
    skip_requesting_account_id  = true
    skip_s3_checksum            = true
  }
}

use_lockfile = true est la ligne que le tableau ci-dessus recommande, et elle ne s'active pas toute seule : sans elle, deux apply concurrents écrivent l'un sur l'autre sans que rien ne le signale. Le verrou s'appuie sur un objet .tflock déposé à côté de l'état dans le même seau, donc il ne demande aucune base annexe.

Les quatre skip_ ne sont pas décoratifs : ils désactivent des contrôles propres à AWS que l'implémentation S3 de Scaleway ne sert pas. Sans eux, terraform init échoue sur une validation qui n'a pas lieu d'être.

Activez le versionnage sur ce seau. Un état corrompu se récupère alors par sa version précédente, ce qui est la seule façon de rattraper une écriture concurrente.

Que faut-il lire dans la sortie de terraform apply ?

Un plan avant tout apply, et surtout la lecture de ce qu'il annonce :

terraform plan -out=tfplan
terraform show -json tfplan | python3 -c '
import sys, json
from collections import Counter
d = json.load(sys.stdin)
c = Counter(r["type"] for r in d["resource_changes"] if "create" in r["change"]["actions"])
for t, n in sorted(c.items()):
    print(f"  {n:>2}  {t}")
print(f"  total : {sum(c.values())} ressources")'

Ce décompte par type est le meilleur garde-fou de coût qui existe. Il montre d'un coup d'œil combien d'instances, de load balancers et de passerelles vont être créés, c'est-à-dire ce qui va tourner au compteur.

Les avertissements du plan méritent d'être lus plutôt que défilés. Sur une stack réelle, celui-ci est apparu :

Policy mode is deprecated and will be removed with v1 of the Instance API.

  with scaleway_instance_placement_group.app,
  on main.tf line 555, in resource "scaleway_instance_placement_group" "app":

Un avertissement de dépréciation n'arrête rien aujourd'hui et arrêtera tout un jour. Le traiter au moment où il apparaît coûte cinq minutes ; le traiter le jour où l'API retire le champ coûte une production.

Pourquoi l'API répond « b_ssd volumes are no longer supported » ?

C'est le cas le plus déroutant, parce que le code est correct et refusé quand même. Rencontré en conditions réelles sur une stack écrite quelques mois plus tôt :

Error: couldn't create volume: scaleway-sdk-go: invalid argument(s):
volume_type does not respect constraint, b_ssd volumes are no longer supported.
Use Scaleway Block Storage (SBS) volumes instead

Le message d'erreur est excellent : il nomme la contrainte, la raison, et renvoie vers la migration. La réponse, elle, est moins évidente qu'elle n'en a l'air.

1. Le réflexe qui ne marche pas

   Changer le type suffit rarement. type = "sbs_volume" sur la même ressource est refusé à son tour :

   volume_type does not respect constraint, not a valid value

2. La vraie migration change de ressource

   Un volume SBS n'est pas un volume Instance d'un autre type : c'est une ressource différente, servie par une autre API.

   # avant, refusé par l'API
   resource "scaleway_instance_volume" "donnees" {
     name       = "app-donnees"
     type       = "b_ssd"
     size_in_gb = 10
   }
   
   # après
   resource "scaleway_block_volume" "donnees" {
     name       = "app-donnees"
     iops       = 5000
     size_in_gb = 10
   }

3. Les références suivent, et le snapshot aussi

   Toutes les références au volume changent de préfixe, et le snapshot doit migrer avec lui. Sinon l'erreur suivante arrive, tout aussi déroutante :

   Error: scaleway-sdk-go: resource instance_volume with ID … is not found

   Elle signifie que scaleway_instance_snapshot cherche un volume Instance là où vit désormais un volume Block.

   resource "scaleway_block_snapshot" "modele" {
     name      = "app-modele"
     volume_id = scaleway_block_volume.donnees.id
   }

Le principe se retient au-delà de ce cas précis : chez Scaleway, l'API Instance et l'API Block sont deux mondes, et une ressource migrée d'un monde à l'autre entraîne avec elle ses snapshots et ses références. C'est le même piège que celui rencontré en ligne de commande entre scw instance snapshot et scw block snapshot.

Pourquoi terraform destroy échoue sur « Can't delete a private network interface attached to a server »

Cette erreur n'est pas une limite de Terraform, c'est une régression du provider Scaleway, présente en 2.81.0 et 2.82.0. Le message est identique à chaque tentative, il ne se résout pas en relançant, et il laisse des ressources facturées à l'heure derrière lui. La distinction compte : une limite de l'outil se contourne, une régression s'épingle. La version 2.80.0 détruit la même stack sans broncher, et la 2.83.0 le fait de nouveau.

Error: scaleway-sdk-go: precondition failed: ,
Can't delete a private network interface attached to a server

Le tableau ci-dessous résume la mesure, faite le 2026-09-09 puis complétée le 2026-09-14, sur une reproduction minimale : 1 VPC, 1 Private Network, 1 instance DEV1-S et 1 interface privée, appliquée puis détruite une fois par version. Lisez la colonne de droite comme le vrai coût de la panne : ce qui reste dans l'état est ce qui reste sur la facture.

Provider	terraform destroy	Ressources restantes
2.80.0	code 0, 7 secondes	0
2.81.0	code 1, erreur 412	4
2.82.0	code 1, erreur 412	4
2.83.0	code 0, 13 secondes	0

Glissez pour voir

La cause tient en un changement d'appel d'API. Jusqu'en 2.80.0, le provider supprimait l'interface par la route v1 rattachée au serveur, DELETE /instance/v1/zones/fr-par-1/servers/{id}/private_nics/{id}, qui accepte une interface attachée et rend 204 No Content. Depuis la 2.81.0, publiée le 17 août 2026, il appelle une route v2alpha1 rattachée à l'interface, DELETE /instance/v2alpha1/zones/fr-par-1/private-network-interfaces/{id}, qui refuse en 412 tant que l'interface est attachée. En 2.81.0 et 2.82.0, le provider ne détache jamais avant de supprimer, d'où le blocage. Ces relevés viennent de TF_LOG=DEBUG, que vous pouvez reproduire.

La 2.83.0, publiée le 14 septembre 2026, garde la route v2alpha1 mais détache l'interface avant de la supprimer : un POST /instance/v2alpha1/zones/fr-par-1/servers/{id}/detach-private-network-interface précède le DELETE, et c'est ce détachement qui manquait. Mesuré le 2026-09-14 sur la même reproduction, avec la version téléchargée du registre : apply en 65 secondes, destroy en 13 secondes, code 0, état vide et projet vide au contrôle scw.

Le blocage est structurel, et c'est ce qui le rend pénible. Votre code déclare server_id dans l'interface, donc Terraform sait que l'interface dépend du serveur, donc il détruit l'interface d'abord. Or c'est exactement ce que l'API refuse désormais. Terraform ne peut pas inverser cet ordre, et vous non plus.

Un destroy qui échoue laisse une facture qui court

C'est le moment exact où l'on croit avoir nettoyé. La commande a rendu la main, elle a affiché ses erreurs au milieu d'autres lignes, et il reste des instances, un load balancer et une passerelle qui se facturent à l'heure.

Sur la stack de 50 ressources de ce lab, le premier destroy en a supprimé 22 et en a laissé 28, dont six instances. Les deux tentatives suivantes en ont supprimé zéro : le même ordre produit la même erreur.

Ce qui ne débloque pas

Deux réflexes naturels ne servent à rien ici, et les écarter fait gagner du temps. Ils ont été testés le 2026-09-09 sur la reproduction minimale, avec le provider 2.82.0, c'est-à-dire l'une des versions affectées.

Arrêter le serveur ne change rien. Avec l'instance en état stopped, vérifié par scw instance server get, la suppression renvoie le même 412. Ce qui bloque est l'attachement, pas l'état d'alimentation.

Cibler le serveur ne change rien non plus. terraform destroy -target=scaleway_instance_server.essai sort en code 1 et laisse les 4 ressources : pour détruire le serveur, Terraform commence par détruire l'interface qui en dépend, et retombe sur le refus. Il n'existe aucune issue sans sortir du graphe : retirer l'interface de l'état avec terraform state rm reste possible, mais c'est précisément quitter la gestion par Terraform.

Les deux parades qui fonctionnent

La parade durable est l'épinglage sur une version qui détruit. Contraindre le provider à la 2.83.0, ou à la 2.80.0 si vous ne pouvez pas monter, évite le problème plutôt que de le rattraper. Le retour à 2.80.0 est sans risque pour l'état : aucun changement de SchemaVersion n'affecte cette ressource entre 2.80 et 2.82.

scaleway = {
  source  = "scaleway/scaleway"
  version = "2.83.0"
}

La parade de rattrapage sert quand la stack est déjà bloquée sur une version affectée. Supprimez l'interface par le CLI, qui utilise toujours la route v1 fonctionnelle, puis laissez Terraform finir. Le terraform destroy suivant se termine en 17 secondes : son rafraîchissement constate la disparition de l'interface et la retire du graphe.

scw instance private-nic delete \
  server-id=<id-du-serveur> private-nic-id=<id-du-nic> zone=fr-par-1

terraform destroy -auto-approve

Si le destroy lancé dans la seconde qui suit échoue encore sur le même 412, relancez-le : l'API met un court instant à propager la suppression.

Sur une stack qui porte plusieurs interfaces, supprimer directement les serveurs va plus vite que de traiter chaque interface une à une. C'est ce qui a débloqué le lab de 50 ressources.

for id in $(scw instance server list zone=fr-par-1 -o json \
            | python3 -c 'import sys,json;[print(s["id"]) for s in json.load(sys.stdin)]'); do
  scw instance server delete "$id" zone=fr-par-1 \
      with-volumes=all with-ip=true force-shutdown=true
done

terraform destroy -auto-approve

L'option qui compte vraiment est with-ip=true : sans elle, l'adresse survit au serveur et reste facturée. with-volumes vaut déjà all par défaut dans le CLI, l'écrire relève de l'habitude explicite plutôt que de la nécessité. C'est le reste discret dont personne ne se souvient six mois plus tard.

Comment prouver qu'un compte Scaleway est vraiment vide ?

Un Destroy complete! n'est pas une preuve. Il dit que Terraform a supprimé ce qu'il connaissait, pas que le compte est vide. Les ressources créées hors Terraform, ou recréées par un service, lui échappent.

terraform state list | wc -l     # doit valoir 0

Puis la vérification qui fait autorité, famille par famille :

scw instance server list zone=fr-par-1
scw block volume list zone=fr-par-1
scw block snapshot list zone=fr-par-1
scw instance image list zone=fr-par-1
scw instance snapshot list zone=fr-par-1
scw instance ip list zone=fr-par-1
scw lb lb list zone=fr-par-1
scw lb ip list zone=fr-par-1
scw vpc-gw gateway list zone=fr-par-1
scw vpc-gw ip list zone=fr-par-1
scw vpc private-network list region=fr-par

Onze listes, et onze doivent être vides. Sur le lab réel, seuls sont restés le Default security group créé par Scaleway et les clés SSH antérieures, ce qui est le retour à l'état de départ.

Le dernier contrôle est la facture, 48 heures plus tard : la console de facturation voit ce que votre inventaire a oublié.

Ce que la version 2.82.0 apporte, et ce qu'elle casse

Deux nouveautés changent ce qu'on peut décrire en code, publiées dans la version 2.82.0 du 1er septembre 2026. Toutes deux viennent de l'évolution du produit, et aucune ne compense la régression décrite plus haut : la même version reste incapable de détruire une interface privée attachée.

Les Instance Templates entrent dans le provider (PR #4206), sous la ressource scaleway_instance_template. Côté produit, ils sont disponibles depuis le 15 juillet 2026, sans mention de bêta au changelog. Ils décrivent une configuration réutilisable et figée, type de machine, image, volumes, réseau, étiquettes et cloud-init, et constituent le chaînon qui manquait entre l'image et la flotte.

Les groupes d'autoscaling aussi (PR #4299), sous la ressource scaleway_autoscaling_group, arrivés dans le provider avec cette même version du 1er septembre 2026. Ils sont en bêta publique depuis le 25 août 2026 côté Scaleway, disponibles à fr-par, nl-ams et pl-waw : à traiter comme tels dans un code de production, avec un chemin de repli. Un produit à ce stade de maturité peut changer de schéma sans préavis, ce qui, sur une ressource gérée par Terraform, se paie en recréation.

L'arbitrage n'a plus lieu d'être depuis la 2.83.0, qui apporte les templates, l'autoscaling et une destruction propre. Si votre code est encore en 2.82.0, montez de version ; si vous ne le pouvez pas tout de suite, prévoyez la suppression des interfaces au CLI dans votre procédure de démontage. L'épinglage à 2.80.0 reste sûr, mais il vous prive des deux nouveautés.

Limites, quotas et plafonds

Un déploiement Terraform échoue rarement sur la syntaxe, souvent sur un plafond. Les valeurs ci-dessous viennent de la page officielle des quotas d'Organisation de Scaleway, dont la date de validation est le 29 octobre 2025, et de l'aide du CLI relevée le 2026-09-08. Elles se lisent comme des garde-fous à intégrer dans le code : un count qui les dépasse produit une erreur à l'apply, à mi-chemin du déploiement, avec des ressources déjà créées.

Plafond	Valeur	Portée
VPC	256	par Organisation
Private Networks	100 par VPC, 255 par Organisation	deux plafonds distincts, le plus bas gagne
Instances attachées à un Private Network	512	par Private Network
Private Networks attachés à une Public Gateway	10	par Organisation, voir la note ci-dessous
Seaux Object Storage	100	par Organisation
Clés API	50	par Organisation, voir la note ci-dessous
Instances DEV1-S	10 sans vérification d'identité, 20 avec	par Organisation

Glissez pour voir

Deux de ces valeurs sont contredites par une autre page officielle, et la règle de cette formation est de le dire plutôt que de choisir celle qui arrange. La FAQ IAM annonce « up to 100 API keys by default » là où la page des quotas dit 50 ; la FAQ Public Gateways, validée le 24 septembre 2025, annonce 8 Private Networks par passerelle là où la page des quotas dit 10, dans son tableau par Organisation. Dans les deux cas, la page des quotas est la plus récemment validée, au 29 octobre 2025 : c'est elle qui fait foi ici, et l'écart est à vérifier sur votre propre compte.

Le plafond des instances est celui qui surprend le plus. Il dépend de la vérification d'identité du compte, pas du crédit disponible : un compte dont seul le moyen de paiement est validé plafonne à 10 machines DEV1-S, et plusieurs gammes ne sont pas ouvertes du tout avant vérification. Une stack qui déclare count = 12 passe donc le plan sans broncher, puis casse en plein apply. Vérifiez le plafond avant d'écrire la boucle, pas après.

Une limite d'un autre ordre mérite d'être connue, en restant précis sur son périmètre. L'issue #3616 du provider, ouverte le 20 janvier 2026 et étiquetée priority:highest, décrit des erreurs 403 intermittentes sur la ressource scaleway_baremetal_server. Le rapporteur les attribue à un nombre d'appels API trop élevé au rafraîchissement, hypothèse que Scaleway n'a pas confirmée à ce jour. Comme Terraform rafraîchit par défaut dix ressources en parallèle, réduire ce parallélisme avec terraform plan -parallelism=1 est le contournement rapporté, et SCW_DEBUG=1 sert à observer les appels pour confirmer le diagnostic. Étendre ce raisonnement à toute grosse stack reste une extrapolation : à traiter comme une piste, pas comme une règle.

Antipatterns à éviter

Ces quatre erreurs ont un point commun : elles ne se voient pas le jour où on les commet. Elles produisent un déploiement qui marche, et une facture ou une panne des semaines plus tard, quand plus personne ne fait le lien avec la décision d'origine. C'est ce décalage qui les rend coûteuses.

Antipattern	Conséquence	Discipline
Contrainte de version flottante (~> 2.8)	une publication amont change votre déploiement sans commit de votre côté : c'est ainsi que la régression 2.81.0 arrive	épingler la version exacte, versionner .terraform.lock.hcl, mettre à jour sciemment
État sur le poste de travail	le poste tombe, l'état disparaît, les ressources continuent de se facturer sans que rien ne sache les nommer	backend Object Storage, versionnage du seau activé
Croire Destroy complete! sur parole	des ressources créées hors Terraform ou laissées par un échec partiel restent facturées	vérification de sortie sur les onze familles, puis la facture à 48 heures
Clés API dans le code ou les variables	la clé part dans l'historique Git et y reste après suppression du fichier	variables d'environnement ou profil scw, jamais d'identifiant dans le HCL
Parallélisme par défaut sur des ressources lentes à rafraîchir	403 intermittents et échecs non reproductibles, rapportés sur scaleway_baremetal_server (#3616)	-parallelism=1 quand le symptôme apparaît, et SCW_DEBUG=1 pour confirmer la cause

Glissez pour voir

Terraform sur Scaleway sous l'angle Well-Architected

Le code d'infrastructure déplace le risque, il ne le supprime pas. Les trois piliers ci-dessous posent chacun une question qu'un auditeur poserait, et la discipline qui y répond. Ils sont à lire avant d'écrire la stack, pas au moment de l'incident.

Excellence opérationnelle

Question clé : si la personne qui a écrit cette stack part demain, que reste-t-il ? Un dépôt qui contient le HCL mais pas le .terraform.lock.hcl ne se rejoue pas à l'identique. Un état sur un poste de travail ne se reprend pas du tout.

Discipline : versionner le code et le fichier de verrouillage, placer l'état sur Object Storage, épingler la version du provider à l'exact, et écrire la procédure de démontage dans le dépôt à côté de celle de déploiement.

Optimisation des coûts

Question clé : qui paie l'instance qu'un destroy en échec a laissée derrière lui ? Personne ne la retrouve, parce qu'elle n'apparaît sur aucun tableau de bord tant qu'on ne la cherche pas. Le lab de cette leçon en a laissé 28 d'un coup.

Discipline : traiter le code de sortie de terraform destroy comme un résultat à vérifier, faire suivre chaque démontage d'une vérification de sortie famille par famille, et contrôler la facturation 48 heures plus tard, délai au-delà duquel la consommation est consolidée.

Fiabilité

Question clé : que se passe-t-il si deux personnes lancent apply en même temps ? Sans verrou, la seconde écriture écrase la première, et l'état ne décrit plus l'infrastructure réelle. La divergence se découvre au destroy suivant, au pire moment.

Discipline : activer le verrouillage sur le backend, activer le versionnage du seau pour pouvoir revenir à un état antérieur, et ne jamais modifier à la main une ressource gérée par Terraform, sous peine de dérive silencieuse.

Pièges courants

Symptôme	Cause	Solution
b_ssd volumes are no longer supported	l'API Instance ne crée plus de volumes	migrer vers la ressource scaleway_block_volume
not a valid value sur type = "sbs_volume"	ce n'est pas un type mais une autre ressource	idem, changer de ressource, pas de valeur
resource instance_volume … is not found sur un snapshot	scaleway_instance_snapshot sur un volume Block	utiliser scaleway_block_snapshot
Can't delete a private network interface attached to a server	régression du provider en 2.81.0 et 2.82.0 : la route v2alpha1 refuse une interface attachée	passer en 2.83.0, ou revenir à 2.80.0 ; sur une stack déjà bloquée, supprimer le NIC avec scw instance private-nic delete puis relancer destroy
terraform init échoue sur le backend S3	contrôles propres à AWS	ajouter les quatre options skip_
Déploiement sur le mauvais compte	le profil scw est lu faute de variables	vérifier scw config get default-project-id avant l'apply
Une adresse survit au serveur supprimé	with-ip n'a pas de valeur par défaut	ajouter with-ip=true ; with-volumes vaut déjà all

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

• Aucun identifiant dans le bloc provider : l'environnement et le profil scw suffisent, et le code reste publiable.
• .terraform.lock.hcl se versionne : c'est lui qui rend le déploiement reproductible.
• L'état sur Object Storage demande quatre options skip_ que l'implémentation S3 de Scaleway ne sert pas.
• Le décompte du plan par type est un garde-fou de coût : il montre ce qui va tourner au compteur.
• Un avertissement de dépréciation se traite quand il apparaît, pas le jour où l'API retire le champ.
• L'API Instance et l'API Block sont deux mondes. Un volume migré entraîne ses snapshots et ses références.
• La destruction des interfaces privées est cassée en 2.81.0 et 2.82.0, et rétablie en 2.83.0 : mesuré le 2026-09-09 et le 2026-09-14, 2.80.0 et 2.83.0 détruisent en quelques secondes quand 2.81.0 et 2.82.0 échouent en 412 et laissent tout en place.
• Un destroy en échec laisse une facture qui court : sur la stack de 50 ressources, 22 supprimées et 28 restantes, dont six instances, et zéro supprimée aux deux tentatives suivantes.
• Destroy complete! n'est pas une preuve. Onze listes le sont, et la facture à 48 heures tranche.

Pour aller plus loin

• Ansible : exploiter ce que Terraform a provisionné : le troisième temps du triptyque, sur l'infrastructure que cette leçon a créée.

Ressources externes

• Documentation du provider Scaleway sur le registre Terraform : la référence des ressources et de leurs arguments, version par version.
• Dépôt scaleway/terraform-provider-scaleway : les notes de version, et les issues où se lisent les régressions avant qu'elles ne vous atteignent.
• Quotas d'Organisation Scaleway : les plafonds cités dans cette page, à vérifier pour votre propre compte.

×

📖 Voir la documentation →