Les coûts, le contrat et la sortie

Pourquoi

Le serveur unique sur lequel Signalements tournait avant ce cours coûtait un loyer fixe : le même montant chaque mois, qu'il soit chargé ou au repos, et une facture que personne ne regardait. Dans le cloud, chaque ressource créée dans les leçons précédentes a son propre compteur, qui tourne à l'heure, que vous vous en serviez ou non. C'est la promesse du cloud, ne payer que ce que l'on utilise, et c'est aussi son piège : on paie tout ce que l'on a oublié.

Les surprises de facture suivent presque toujours le même scénario :

• une séance de travaux pratiques se termine, on arrête les instances, on rentre chez soi ; un mois plus tard, la facture contient les instances (mises en veille plutôt qu'arrêtées), leurs adresses IP, leurs volumes et les sauvegardes de la base ;
• une démonstration laisse derrière elle un répartiteur de charge que personne ne relie plus à rien ;
• une clé d'API fuit (leçon 7), et quelqu'un crée en une nuit des dizaines d'instances pour miner de la cryptomonnaie, à vos frais.

Le coût n'est pas un sujet de comptables. C'est une propriété de l'architecture, au même titre que la disponibilité ou la sécurité : un choix de zone, de type d'instance ou de classe de stockage se paie chaque mois. Et il a un pendant contractuel que l'on regarde rarement avant d'en avoir besoin : que promet le fournisseur, que rembourse-t-il quand il ne tient pas sa promesse, et que coûte le fait de partir ?

Cette leçon termine le cours en faisant les comptes de Signalements, puis en préparant la sortie : un projet cloud bien conduit commence par savoir comment il finira.

Les concepts

Trois façons de payer

À l'usage (pay as you go). C'est le modèle par défaut de tous les fournisseurs. Chez Scaleway, les instances de calcul classiques sont facturées à l'heure de fonctionnement, les instances à carte graphique à la minute (sauf une gamme, facturée à l'heure), et la facture est établie à la fin de chaque mois civil. On peut arrêter ou supprimer à tout moment, sans engagement ni préavis.

L'engagement de dépense. En échange d'un montant mensuel garanti, le fournisseur consent une remise. Chez Scaleway, c'est le savings plan : un engagement de 12 ou 36 mois, entre 50 et 9 999 € par mois, limité aux ressources de calcul, avec une remise annoncée jusqu'à 25 % sur les instances. Le mécanisme est à lire de près : si vous consommez moins que l'engagement, vous payez quand même l'engagement (remisé) ; si vous consommez plus, le dépassement est facturé au prix public. Un savings plan ne s'annule pas et ne s'échange pas. AWS, Azure et Google Cloud proposent des mécanismes voisins (Savings Plans et instances réservées chez AWS, réservations et savings plans chez Azure, remises sur engagement chez Google Cloud).

Le contrat négocié. Au-delà d'un certain volume, les conditions se négocient avec un commercial : remises par produit, paliers, montant minimal sur la durée. Chez Scaleway, ces engagements contractuels ne sont pas disponibles en libre-service, et une résiliation anticipée peut entraîner le paiement du solde de l'engagement.

Le principe à retenir : un engagement transforme une dépense variable en dépense fixe. Il est rentable pour la part de la consommation qui est stable et certaine (les instances qui tournent jour et nuit depuis un an), jamais pour celle qui est incertaine.

La facturation d'une instance, en détail

Les pages de Scaleway sur la tarification des instances et la FAQ de facturation précisent les règles. Elles réservent plusieurs surprises.

Deux autres règles de la FAQ de facturation changent la façon de travailler :

• chaque ressource est facturée au minimum 60 minutes, et chaque période ininterrompue entre un début et une fin de facturation compte comme une ressource distincte. Démarrer et éteindre une instance dix fois dans la même heure, c'est dix heures facturées ;
• les adresses IP flexibles, les volumes et les instantanés sont facturés de leur création à leur suppression, quel que soit l'état de l'instance à laquelle ils sont, ou étaient, rattachés.

Ce qui coûte sans qu'on y pense

Reprenons l'architecture du cours et listons ce qui a un compteur :

La documentation des bases managées précise un point que l'on découvre en général sur la facture : quand on supprime une base, ses sauvegardes automatiques et ses instantanés ne sont pas supprimés ; ils sont purgés à la fin de leur période de rétention, ou à la main.

Le trafic sortant

Faire entrer des données dans un cloud est presque toujours gratuit. Les en faire sortir, vers Internet ou vers un autre fournisseur, ne l'est pas toujours : ce sont les frais de sortie (egress fees). Ils comptent pour deux raisons. La première est la facture d'une application qui sert beaucoup de contenu. La seconde est stratégique : des frais de sortie élevés rendent coûteux le départ vers un autre fournisseur, et contribuent au verrouillage (lock-in).

Les grilles tarifaires diffèrent fortement d'un fournisseur à l'autre. Relevés le 5 octobre 2026 sur les pages tarifaires des fournisseurs :

• chez Scaleway, la page des instances indique que les prix affichés incluent le trafic sortant ; pour le stockage objet (région de Paris), 75 Go de trafic sortant par mois sont inclus, puis 0,01 € par Go ; les transferts entre régions européennes de Scaleway et à l'intérieur d'une région sont gratuits ;
• chez AWS, 100 Go de trafic sortant vers Internet par mois sont gratuits, tous services et toutes régions confondus (hors Chine et GovCloud), puis le trafic est facturé au Go selon des paliers et des régions que la page de tarification détaille.

Ces chiffres changent : ne les recopiez pas dans un document d'architecture sans la date et la source.

Estimer avant, vérifier après

Une estimation sérieuse se fait ressource par ressource, à partir des grilles tarifaires, avec trois colonnes : la quantité, le prix unitaire daté, la durée. Pour une ressource à l'heure qui tourne en permanence, on compte environ 730 heures par mois (8 760 heures par an divisées par 12) ; le mois réel compte entre 672 et 744 heures. Quelques prix horaires relevés sur la page des instances le 5 octobre 2026, hors taxes :

Le reste de l'architecture (volumes, IP, base, passerelle, répartiteur) se lit sur les mêmes pages, et l'estimateur de la console, présent sur les pages de création, fait le calcul pour une instance avec ses volumes et son IP. Scaleway précise que cette estimation est indicative et ne l'engage pas.

L'estimation se vérifie ensuite dans la consommation réelle, que la console présente dans le gestionnaire de coûts (Cost Manager), filtrable par catégorie, produit et projet, et que l'API de facturation expose ligne par ligne. C'est là qu'apparaît ce que l'estimation avait oublié.

Attribuer les coûts : projets et étiquettes

Une facture n'est utile que si l'on sait à qui elle appartient. Chez Scaleway, l'unité d'attribution est le projet : le gestionnaire de coûts et l'API de consommation filtrent par projet. Un projet par application et par environnement (leçon 7) donne donc, gratuitement, une facture lisible par application et par environnement.

Les étiquettes (tags) que l'on pose sur les ressources (tags.0=signalements à la création d'une instance) servent à retrouver et filtrer les ressources (la plupart des commandes list acceptent un filtre tags). Chez AWS, des étiquettes déclarées cost allocation tags deviennent des axes de la facture ; la documentation précise qu'il faut les activer dans la console de facturation avant qu'elles n'apparaissent dans les rapports, et qu'elles peuvent mettre 24 heures à apparaître. Azure et Google Cloud ont des mécanismes voisins (étiquettes et labels). Dans tous les cas, une convention écrite (quelles clés, quelles valeurs, obligatoires ou non) vaut mieux qu'une liste d'étiquettes improvisées.

Budgets et alertes

Un budget est d'abord un seuil de surveillance, pas un plafond : celui de Scaleway ne coupe aucune ressource. (Certains fournisseurs permettent d'attacher des actions automatiques à un budget, comme les budget actions d'AWS, mais il faut les concevoir et les configurer soi-même.) Chez Scaleway, on définit un budget mensuel en euros pour l'organisation, puis jusqu'à dix alertes de facturation (billing alerts), chacune à un pourcentage du budget, envoyées par courriel, SMS ou appel de webhook. La documentation fait trois mises en garde :

• l'alerte est une estimation ; des coûts engagés avant son déclenchement peuvent apparaître ensuite, et seule la facture mensuelle fait foi ;
• l'alerte se déclenche sur le montant toutes taxes comprises, alors que le suivi de consommation affiche les montants hors taxes ;
• l'alerte porte sur le montant facturé, remises déduites : avec un bon de 100 € et un budget de 150 €, l'alerte à 100 % part quand 150 € sont facturés, donc quand la consommation réelle a atteint 250 €.

Les équivalents sont AWS Budgets, les budgets d'Azure Cost Management et les budgets de Cloud Billing chez Google Cloud.

Le SLA : ce qu'il promet, ce qu'il rembourse

Un SLA (Service Level Agreement, accord de niveau de service) est un engagement contractuel : un niveau de service mesurable (le plus souvent un taux de disponibilité mensuel), une méthode de mesure, des exclusions, et une compensation si l'engagement n'est pas tenu.

Lisons celui des instances Scaleway, en vigueur à la date de vérification :

• Tous les types ne sont pas couverts. Les gammes dédiées et spécialisées et les instances à carte graphique ont un objectif de 99,5 % de disponibilité mensuelle ; certaines gammes partagées, 99 % ; les gammes DEV1, GP1, PLAY2, PRO2, COPARM1 et ENT1, ainsi que les instances de développement, n'ont aucun objectif.
• L'indisponibilité est définie étroitement : une perte de connectivité externe d'au moins quatre minutes consécutives. Une dégradation de performance, des erreurs passagères ou une coupure de trois minutes ne comptent pas, pas plus que les maintenances annoncées.
• La compensation est un bon d'achat, pas un remboursement : pour une instance dédiée, 10 % du montant mensuel de la ressource entre 99 % et 99,5 % de disponibilité, 25 % entre 95 % et 99 %, 100 % en dessous de 95 %, plafonnée au montant facturé pour les ressources concernées. Il faut la réclamer, journaux à l'appui, au plus tard trente jours après la fin du mois concerné.

Faites le calcul : 99,5 % d'un mois de 30 jours (43 200 minutes) autorise 216 minutes d'indisponibilité, soit 3 h 36. Si votre application rapporte 10 000 € par heure et que l'instance coûte 41 € par mois, une panne de cinq heures vous coûte 50 000 € et vous rapporte, au mieux, un bon de 10,25 € (25 % de 41 €). Un SLA n'est pas une assurance. Il dit ce que le fournisseur vise et ce qu'il risque, pas ce que vous perdez. Votre disponibilité vient de votre architecture : deux instances dans deux zones derrière un répartiteur (leçons 3 et 6), pas du SLA d'une instance.

Le verrouillage et la réversibilité

Le verrouillage fournisseur est le coût, technique, financier et organisationnel, de quitter un fournisseur. Il vient de trois sources :

• les services propriétaires : une API sans équivalent ailleurs, une base de données au format maison, un service d'IA intégré au code ;
• les données : leur volume (et les frais pour les sortir), leurs formats ;
• les savoir-faire et les contrats : des équipes formées à un outil, un engagement de trois ans.

La réversibilité, c'est la capacité organisée à partir : récupérer ses données dans des formats exploitables, dans un délai connu, à un coût connu, et reconstruire le service ailleurs. Elle se prépare à l'entrée, pas à la sortie. L'architecture de Signalements est, à dessein, faite de briques standard : des instances Linux qui font tourner une image OCI, PostgreSQL (un pg_dump se restaure partout), un stockage objet compatible S3 (que des outils comme rclone copient d'un fournisseur à l'autre), et, dans la suite du parcours, Kubernetes et Terraform. Le verrouillage n'est jamais nul (les politiques IAM, le réseau, les noms des types d'instances ne se transposent pas), mais il est connu et borné.

Le règlement européen sur les données

Le règlement (UE) 2023/2854, dit Data Act, applicable depuis le 12 septembre 2025, consacre son chapitre VI au « changement de services de traitement de données », ce qui inclut le cloud. Ce qu'il impose aux fournisseurs, en substance :

• le contrat doit permettre au client de changer de fournisseur, ou de rapatrier toutes ses données exportables et ses actifs numériques sur sa propre infrastructure, avec un préavis de deux mois au plus et une période de transition de trente jours au plus (article 25). Si c'est techniquement impossible, le fournisseur doit le justifier et proposer une période qui ne peut dépasser sept mois ;
• le contrat doit lister les catégories de données exportables, et celles qui en sont exclues parce qu'elles relèvent du fonctionnement interne du service ;
• après la transition, le client dispose d'au moins trente jours pour récupérer ses données ;
• les frais de changement de fournisseur, frais de sortie de données compris, sont réduits au coût réel du fournisseur depuis le 11 janvier 2024, et interdits à compter du 12 janvier 2027 (article 29).

Les grands fournisseurs ont anticipé : AWS, par exemple, accorde depuis mars 2024 le trafic sortant gratuit aux clients qui quittent ses services, sur demande au support, en citant la direction prise par le Data Act. Le règlement ne supprime pas le verrouillage technique ; il en retire une partie du coût financier, et il oblige les contrats à dire ce qui sort et comment.

Le cours suivant de la partie, Cloud souverain : choisir et justifier, traite l'autre versant du contrat : sous quelle juridiction tombent vos données, ce que changent les lois à portée extraterritoriale comme le CLOUD Act américain, et ce que garantit une qualification comme SecNumCloud de l'ANSSI.

En pratique

Toutes les commandes de cette partie se lancent avec votre profil de propriétaire ou avec une identité qui a les jeux de permissions de facturation (BillingReadOnly pour lire, BillingManager pour créer budgets et alertes) dans une règle à périmètre organisation.

Lire la consommation du mois

$ PROJET=$(scw account project list name=signalements -o json | jq -r '.[0].id')
$ scw billing consumption list project-id="$PROJET" -o json \
    | jq -r '.[] | [.category_name, .product_name, .resource_name, .billed_quantity, .unit,
                    ((.value.units // 0) + (.value.nanos // 0) / 1e9)] | @tsv'

La commande renvoie les lignes de consommation du mois en cours pour le projet ; billing-period=2026-09 interroge un mois passé. Les montants sont des objets « argent » de l'API Scaleway, avec une partie entière (units) et des nanos (nanos) : le filtre jq les recompose. Pour la consommation au niveau de chaque ressource, sur une plage de dates choisie, scw billing charge list interroge l'API FinOps, dont la documentation prévient que ses totaux peuvent différer légèrement de ceux de la facture, faute d'arrondis et d'agrégations identiques.

Un budget et des alertes

$ BUDGET=$(scw billing budget create consumption-limit=50 enabled=true -o json | jq -r .id)
$ ALERTE=$(scw billing budget-alert create budget-id="$BUDGET" threshold=80 -o json | jq -r .id)
$ scw billing budget-alert-notification create budget-alert-id="$ALERTE" \
    email-addresses.0=equipe-signalements@exemple.fr

• consumption-limit=50 : un budget de 50 € par mois, en euros entiers (le SDK précise : sans centimes). Le budget porte sur l'organisation entière, pas sur un projet.
• threshold=80 : l'alerte se déclenche à 80 % du budget. Ajoutez-en une à 100 % ; le maximum est de dix alertes.
• La notification peut aussi partir par SMS (sms-phone-numbers.0=) ou vers un webhook (webhook-urls.0=), qui reçoit un POST JSON contenant la date de début de facture et le seuil atteint : de quoi poster un message dans le canal de l'équipe.

Un budget de 50 € pour un projet de formation n'a rien d'arbitraire : il doit être supérieur à ce que vous dépensez normalement (sinon l'alerte sonne chaque mois et plus personne ne la lit), et bien inférieur à ce que coûterait une nuit d'abus.

L'inventaire avant le ménage

Avant de supprimer quoi que ce soit, on fait l'inventaire de tout ce que contient le projet, dans toutes les zones. C'est le moment où l'on découvre l'IP orpheline d'une séance précédente. Un petit script, inventaire.sh :

#!/usr/bin/env bash
# Inventaire des ressources facturables d'un projet Scaleway, toutes zones et régions.
set -euo pipefail
projet=$(scw account project list name="${1:?nom du projet}" -o json | jq -r '.[0].id')

lister() {  # titre, puis la commande scw sans -o json
  local titre=$1; shift
  echo "== $titre"
  "$@" project-id="$projet" -o json \
    | jq -r '.[] | [.id, (.name // .address // "-"), (.zone // .region // "-")] | @tsv'
}

lister "Répartiteurs de charge"   scw lb lb list zone=all
lister "IP de répartiteurs"       scw lb ip list zone=all
lister "Passerelles publiques"    scw vpc-gw gateway list zone=all
lister "IP de passerelles"        scw vpc-gw ip list zone=all
lister "Instances"                scw instance server list zone=all
lister "Volumes bloc"             scw block volume list zone=all
lister "Instantanés bloc"         scw block snapshot list zone=all
lister "Instantanés d'instances"  scw instance snapshot list zone=all
lister "IP flexibles"             scw instance ip list zone=all
lister "Réseaux privés"           scw vpc private-network list region=all
lister "Bases de données"         scw rdb instance list region=all
lister "Sauvegardes de bases"     scw rdb backup list region=all
lister "Espaces de registre"      scw registry namespace list region=all
echo "== Buckets (projet préféré de la clé utilisée, région fr-par)"
scw object bucket list region=fr-par

$ chmod +x inventaire.sh && ./inventaire.sh signalements

Quelques choix méritent une explication :

• zone=all et region=all interrogent toutes les zones ou régions ; sans eux, chaque commande ne regarde que la zone par défaut du profil, et une instance créée dans fr-par-2 passe inaperçue. Les commandes de liste de scw parcourent toutes les pages de résultats et renvoient un tableau JSON, d'où le .[].
• Le filtre jq prend le nom, ou à défaut l'adresse (les IP n'ont pas de nom), et la zone ou la région selon que la ressource est zonale ou régionale.
• Les buckets font exception. L'API S3 n'a pas de notion de projet : la commande liste les buckets du projet préféré de la clé utilisée (leçon 7), dans une région. Lancez-la avec une clé dont le projet préféré est signalements, et pour chaque région utilisée.

Le ménage, dans l'ordre

L'ordre suit les dépendances : on supprime d'abord ce qui utilise les autres ressources, en dernier ce qui est utilisé.

$ scw lb lb delete <id-lb> release-ip=true zone=fr-par-1
$ scw vpc-gw gateway delete <id-passerelle> delete-ip=true zone=fr-par-1
$ scw instance server delete <id-sig-app-1> with-volumes=all with-ip=true force-shutdown=true zone=fr-par-1
$ scw instance server delete <id-sig-app-2> with-volumes=all with-ip=true force-shutdown=true zone=fr-par-2
$ scw block snapshot delete <id-instantane> zone=fr-par-1
$ scw instance ip delete <ip-restante> zone=fr-par-1
$ scw vpc private-network delete <id-reseau-prive> region=fr-par
$ scw rdb instance delete <id-sig-db> region=fr-par
$ scw rdb backup delete <id-sauvegarde> region=fr-par
$ scw registry namespace delete <id-espace> region=fr-par

Les options comptent plus que les commandes :

• release-ip=true et delete-ip=true libèrent l'adresse IP du répartiteur et de la passerelle. Sans elles, l'IP reste réservée, et facturée.
• with-ip=true fait de même pour l'IPv4 flexible de l'instance ; with-volumes=all (la valeur par défaut, explicitée ici) supprime ses volumes.
• La base se supprime après les instances qui l'utilisent, et ses sauvegardes automatiques après la base, puisqu'elles lui survivent.

Pour le bucket, une précision trouvée dans le code source de la ligne de commande : l'aide de scw object bucket delete annonce la suppression du bucket « avec tout son contenu », mais la commande n'appelle que l'opération S3 DeleteBucket, que le protocole S3 refuse sur un bucket non vide. Videz-le d'abord (avec aws s3 rm s3://<bucket> --recursive et le profil de la leçon 5, sans oublier les versions d'objets si le versionnement est actif), puis supprimez-le.

Relancez enfin ./inventaire.sh signalements : chaque rubrique doit être vide. Le lendemain, la consommation du jour dans le gestionnaire de coûts doit l'être aussi.

Sous le capot

Du compteur à la facture. Chaque produit émet des événements de début et de fin de facturation pour chaque ressource (création, démarrage, extinction, suppression). La FAQ de facturation de Scaleway les liste par type de ressource : pour une instance, la facturation commence à la mise sous tension et s'arrête à l'extinction ; pour une IP flexible, à la réservation et à la libération ; pour un volume ou un instantané, à la création et à la suppression. Entre deux événements, le temps est compté en heures entamées, avec un minimum d'une heure par période. Ces périodes sont agrégées par produit et par SKU (stock keeping unit, la référence tarifaire d'un produit dans une configuration donnée), puis par projet, ce que montrent les champs sku, billed_quantity et unit de la consommation. La facture mensuelle applique ensuite, dans l'ordre documenté par Scaleway, les gratuités et périodes d'essai, la remise du savings plan, puis les bons et crédits, et enfin les taxes.

Pourquoi la veille coûte comme la marche. Une instance en veille (stopped in place) garde sa place sur l'hyperviseur, avec ses volumes locaux : la machine physique reste réservée pour elle, donc facturée. L'extinction (power off) transfère les données locales vers un stockage de volumes et rend la place à la réserve commune ; c'est pourquoi elle est plus lente, que le redémarrage peut prendre du temps, et qu'elle n'est pas facturée. La facture reflète ici une réalité physique : on paie ce qui est réservé, pas ce qui calcule.

Pourquoi le trafic sortant coûte, et l'entrant pas. Les liens d'un fournisseur vers Internet passent par des accords d'échange de trafic (peering) et de transit avec d'autres opérateurs, souvent dimensionnés et payés selon le sens le plus chargé. Pour un fournisseur dont les clients servent surtout du contenu, c'est le sens sortant : le trafic entrant emprunte la direction la moins chargée, presque sans coût supplémentaire, ce qui explique en partie l'asymétrie des prix. À cela s'ajoute la stratégie commerciale, que le Data Act vise explicitement : facturer cher la sortie retient les données. Les écarts de prix entre fournisseurs, bien plus grands que les écarts de coûts réels, montrent que la stratégie pèse au moins autant que la technique.

Pièges courants

« J'ai tout éteint. » Éteindre arrête la facturation de l'instance, pas celle de ses volumes, de son IP, de la base, du répartiteur ni de la passerelle. Et « mettre en veille » ne l'arrête pas du tout.

Supprimer l'instance, garder l'IP. Par défaut, scw instance server delete conserve l'IP flexible ; terminate aussi. Même chose pour les IP des répartiteurs et des passerelles. Les IP orphelines sont la fuite la plus banale.

L'inventaire limité à la zone par défaut. Sans zone=all, la ressource de fr-par-2 n'existe pas pour vos commandes ; elle existe pour la facture.

Le bucket invisible. Une liste de buckets faite avec une clé dont le projet préféré est un autre projet ne montre pas ceux de signalements.

Les sauvegardes orphelines. Elles survivent à la base. Elles survivent aussi à l'oubli.

Le budget pris pour un plafond. Une alerte ne coupe rien. Si une limite dure est indispensable, il faut l'écrire soi-même (un webhook qui déclenche un script d'arrêt), en mesurant le risque de couper la production pour une erreur de seuil.

L'alerte qui n'arrive pas. Remises, bons et taxes décalent le déclenchement (voir plus haut). Testez le canal de notification une fois, avec un seuil bas, plutôt que de découvrir le jour d'un incident que l'adresse était fausse.

L'engagement pris trop tôt. Un savings plan de 36 mois signé pendant la première semaine d'un projet engage sur une consommation que personne ne connaît encore. Attendez quelques mois de consommation stable.

Le SLA invoqué pour une instance sans objectif. Les gammes de développement et plusieurs gammes courantes n'ont pas d'objectif de disponibilité : vérifiez la page SLA du produit avant de choisir le type pour la production.

Sécurité

L'alerte de facturation est un détecteur d'intrusion. Une clé volée sert d'abord à créer des ressources de calcul, et cela se voit sur la consommation avant de se voir ailleurs. Un budget raisonnable, des alertes à des seuils bas et un canal que quelqu'un lit vraiment sont une mesure de sécurité, peu coûteuse, qui complète le journal d'audit de la leçon 7. Pour un environnement de formation ou d'essai, une alerte très tôt dans le mois (10 % d'un petit budget) détecte l'anomalie en quelques heures.

Les quotas sont un garde-fou. Chaque organisation a des quotas par produit et par type de ressource, que Scaleway décrit comme une protection contre les abus, et qu'il relève sur demande au support après vérification du moyen de paiement et de l'identité. Ne les relevez pas « au cas où » : un quota bas sur les instances à carte graphique, que vous n'utilisez pas, limite ce qu'une clé volée peut créer. Le message Quotas exceeded à la création d'une ressource signale qu'un quota est atteint.

Les données de facturation sont sensibles. Elles décrivent votre architecture (produits, noms de ressources, volumes) et votre activité. BillingReadOnly ne se donne pas à tout le monde, et BillingManager, qui modifie les moyens de paiement et les alertes, encore moins.

La réversibilité est aussi une mesure de sécurité. Un fournisseur peut disparaître, être racheté, changer de juridiction ou de prix. Pouvoir exporter et reconstruire dans un délai connu, c'est une mesure de continuité d'activité au même titre qu'une sauvegarde. Le cours Sauvegarde, restauration et PRA y revient.

En production

FinOps. À l'échelle d'une entreprise, la maîtrise des coûts du cloud devient une discipline : la FinOps Foundation définit le FinOps comme un cadre opérationnel et une pratique culturelle qui maximise la valeur de la technologie, permet des décisions fondées sur les données et crée une responsabilité financière par la collaboration entre les équipes d'ingénierie, de finance et métier. Elle l'organise en trois phases, que l'on parcourt en boucle : informer (rendre les coûts visibles et attribués), optimiser (ajuster les tailles, supprimer le gaspillage, négocier les engagements), opérer (mettre en œuvre et suivre les décisions). Le cours FinOps du chapitre Exploiter le développe.

L'attribution d'abord. Avant toute optimisation, chaque euro doit avoir un propriétaire : un projet par application et par environnement, une convention d'étiquettes, et un tableau de bord mensuel par équipe. Une équipe qui voit sa propre facture la réduit d'elle-même ; une facture globale n'appartient à personne.

Le juste dimensionnement. La plupart des instances sont surdimensionnées par prudence au démarrage, puis jamais revues. Les métriques de charge (le cours Prometheus) disent ce qui est réellement utilisé ; un changement de type est souvent la première économie.

Les engagements pour la base stable. Une fois la consommation stable mesurée sur plusieurs mois, un savings plan sur cette base, et uniquement sur elle ; le reste reste à l'usage.

Le plan de sortie, écrit. Pour une application qui compte, un document court, revu une fois par an : où sont les données et dans quels formats elles s'exportent ; par quel moyen et en combien de temps (volume, débit, frais éventuels) ; quels services propriétaires seraient à remplacer, et par quoi ; quelles clauses du contrat s'appliquent (préavis, transition, récupération). Un exercice de sortie partiel, par exemple restaurer la base et le bucket chez un autre fournisseur, transforme ce document en certitude.

Chez Lyneko, chaque application vit dans son propre projet Scaleway, ce qui donne une facture par application sans effort, et les applications sont déployées sur Kapsule à partir d'images OCI et de charts Helm, des formats que n'importe quel cluster Kubernetes sait lire.

Exercices

1. Le mois des oublis (niveau 100). Une personne en formation a créé, le 1er du mois, deux instances PRO2-XXS avec chacune une IPv4 flexible et un volume bloc. Le 3, elle les met en veille. Le 10, elle les supprime avec scw instance server delete <id> sans autre option. Listez, pour la fin du mois, ce qui a été facturé et ce qui l'est encore.

2. Lire un SLA (niveau 100). Une instance POP2 a connu dans le mois trois coupures de connectivité : une de 3 minutes, une de 2 heures pendant une maintenance annoncée, une de 4 heures non annoncée. Le mois compte 30 jours. Quelle disponibilité au sens du SLA, quelle compensation, et que devez-vous faire pour l'obtenir ?

3. Estimer Signalements (niveau 100). Construisez le tableau d'estimation mensuelle de l'architecture de production du cours : deux instances, leurs volumes, la base sig-db avec ses sauvegardes, le bucket (prévoyez 50 Go de pièces jointes et 100 Go de trafic sortant par mois), la passerelle, le répartiteur et leurs IP. Prenez les prix sur les pages tarifaires de Scaleway en notant la date. Puis, après une semaine de fonctionnement réel, comparez avec scw billing consumption list.

4. Plan de sortie (niveau 100). En dix lignes au plus, rédigez le plan de sortie de Signalements vers un autre fournisseur européen : données, formats, outils, délais, points de verrouillage, clauses contractuelles.

Récapitulatif

• Le cloud se paie à l'usage (à l'heure, chez Scaleway, avec un minimum d'une heure par période de marche), par engagement (savings plan : on paie l'engagement même sans consommer) ou par contrat négocié.
• Une instance éteinte ne coûte plus, une instance en veille coûte comme en marche ; les IP flexibles, les volumes, les instantanés et les sauvegardes de bases survivent souvent aux ressources qui les utilisaient, et se paient.
• Les frais de sortie varient beaucoup d'un fournisseur à l'autre ; ils pèsent sur la facture et sur la liberté de partir.
• On estime ressource par ressource avec des prix datés, on vérifie dans la consommation réelle, on attribue par projet (et par étiquettes chez AWS, Azure, Google Cloud).
• Un budget et des alertes surveillent, ne coupent rien, et détectent aussi les clés volées.
• Le ménage commence par un inventaire de toutes les zones et régions, et suit l'ordre des dépendances, IP comprises.
• Un SLA définit étroitement l'indisponibilité et compense en bons d'achat : ce n'est pas une assurance.
• La réversibilité se prépare à l'entrée ; le Data Act impose préavis et transition courts, et interdit les frais de changement de fournisseur à compter du 12 janvier 2027.

Pour aller plus loin

• La FAQ de facturation et la page de tarification des instances de Scaleway, à relire avant chaque nouveau produit : les règles de début et de fin de facturation y sont détaillées.
• Le chapitre VI du règlement (UE) 2023/2854, sur EUR-Lex, court et lisible, et la page Data Act explained de la Commission européenne.
• Le cadre de la FinOps Foundation (finops.org), pour les capacités qui composent une pratique FinOps.
• Le cours Cloud souverain : choisir et justifier, qui poursuit la réflexion sur le contrat du côté de la juridiction et des qualifications.
• Le lab du cours, qui reprend l'architecture complète de Signalements, la vérifie, puis la supprime avec l'inventaire de cette leçon.