Projet final : déployer une application complète dans le cloud

Ce projet assemble les modules précédents en une infrastructure que vous construisez de bout en bout, puis que vous vérifiez commande par commande. Il n'est lié à aucun fournisseur : le même plan se réalise sur Scaleway, AWS, OUTSCALE ou un autre, et la plus grande partie se rejoue en local, sans compte cloud ni carte bancaire. Il s'adresse à qui a parcouru les blocs réseau, compute, données et sécurité et veut savoir ce qu'il en a réellement retenu. La piste Engineer réalise les lots de construction et d'exploitation. La piste Architecte y ajoute trois lots : les garde-fous et la sortie de données, deux mises en pratique locales sans compte, et la revue écrite, lue par un humain. Seul le volet sur compte réel se jouera chez Outscale ou chez Scaleway, aux mêmes critères chez l'un ou l'autre ; il est indisponible aujourd'hui (voir les lots).

Ce que vous allez construire

Le fil rouge est une boutique en ligne : une application web à trois étages, joignable depuis Internet, dont les données ne le sont pas. Les clients consultent un catalogue, passent des commandes, et les visuels des produits sont rangés dans un seau de stockage objet privé, lu par les machines applicatives et jamais public.

Étage	Contenu	Joignable depuis
Exposé	un répartiteur de charge, terminaison TLS	Internet, ports 80 et 443
Applicatif	deux machines identiques servant l'application	le répartiteur uniquement
Données	la base des commandes, managée ou auto-gérée, sauvegardée ; le seau privé des visuels produits	l'étage applicatif uniquement

Glissez pour voir

Quatre exigences transverses complètent l'ensemble, et ce sont elles qui distinguent un exercice d'école d'une infrastructure défendable : tout est décrit par du code, rien ne sort d'un secret en clair, la restauration a été essayée, et l'environnement se détruit entièrement à la fin, sans laisser de ressource facturée derrière lui.

Où réaliser le projet, et que prouve chaque environnement ?

Trois environnements sont possibles, et chacun prouve des choses différentes : un test réussi ne vaut que par ce qu'il mesure. Cette distinction est le cœur de la méthode enseignée ici. L'émulateur Feint vérifie l'existence et les liens des ressources déclarées. Un hôte Linux capable de virtualiser (KVM ou Incus, avec dsoxlab installé) fait tourner de vraies machines et de vrais services, lancés par dsoxlab : le code Terraform, lui, se joue sur Feint. Un compte réel est le seul à valider ce qu'un fournisseur fait vraiment, au prix d'une dépense réelle.

	Feint, sans compte	Machines lancées par dsoxlab, sans compte	Compte réel
Plan d'adressage, ressources et dépendances déclarés	oui	oui	oui
Cycle Terraform complet, second plan vide, environnement recréé	oui	non, Terraform se joue sur Feint	oui
Sortie Internet par la passerelle NAT, refus réel depuis Internet	non (aucun paquet n'est routé)	non prouvée	oui
Trafic réel qui traverse le répartiteur, sonde qui retire une instance cassée	non	oui (répartiteur pas encore fourni par le catalogue de labs, à monter à la main, voir plus bas)	oui
Stockage objet	non émulé	banc local, sous Docker ou Podman, monté à la main tant que le lot Stockage n'est pas publié dans le catalogue	oui
Base auto-gérée, sauvegarde et restauration	non	oui	oui
Permissions réellement refusées	non, jamais vérifiées	non	oui
Facture et budget	non	non	oui

Glissez pour voir

Faites-les dans cet ordre : Feint, hôte local, compte réel. L'émulateur vous permet de rater le plan d'adressage cinq fois sans conséquence, ce qui est exactement le moment où l'on apprend. L'hôte local valide ensuite ce que seul un service qui tourne peut valider. Le compte réel vérifie en dernier ce qui exige un fournisseur, sur un périmètre réduit, et il n'impose aucun fournisseur : les critères restent les mêmes chez Outscale ou chez Scaleway. Son volet Outscale est indisponible pour l'instant et aucun autre volet sur compte réel n'est encore publié : la colonne de droite dit donc ce qu'un compte réel prouvera à son ouverture, aucun plafond de dépense n'est annoncé aujourd'hui, et il le sera, daté et relevé chez le fournisseur, avec le volet. Tant qu'il manque, les preuves « compte réel » ne se jouent pas, et votre revue dit qu'elles manquent.

L'hôte local a un prérequis matériel que Feint n'a pas. Il faut une machine Linux qui virtualise, avec KVM ou Incus, et dsoxlab installé. Pour le banc de stockage objet, il faut aussi Docker ou Podman, et rclone v1.75.2 pour la copie du lot Sortie. Pour le lot Garde-fous, il faut Conftest. Sans la machine qui virtualise, vous restez sur Feint et sur les quiz : la preuve du projet est alors partielle, et c'est à vous de le dire dans votre revue. Pour voir tourner de vraies machines derrière l'émulateur lui-même, la page faire tourner de vraies machines et s'y connecter en SSH est un complément facultatif.

Le piège du stockage objet avec Feint

Le stockage objet n'est pas émulé par Feint, et une requête qui le vise part vraiment sur Internet vers le vrai fournisseur. Si votre configuration Terraform crée un bucket, elle tentera de le créer pour de bon.

Lancez feint doctor depuis le répertoire de votre configuration avant tout apply : il relit vos fichiers et signale les signatures connues de ce genre de fuite. Les limites exactes sont dans ce que Feint prouve et ne prouve pas.

Le plan d'adressage

Commencez par écrire ce tableau avant de créer quoi que ce soit. La plage du réseau ne se modifie plus après création chez la plupart des fournisseurs, et c'est la seule décision de ce projet qui soit vraiment irréversible.

Rôle	Zone A	Zone B	Route par défaut
Exposé	10.50.1.0/24	10.50.2.0/24	passerelle Internet
Applicatif	10.50.11.0/24	10.50.12.0/24	passerelle NAT
Données	10.50.21.0/24	10.50.22.0/24	aucune

Glissez pour voir

Réseau : 10.50.0.0/16. Les dizaines séparent les rôles, ce qui rend une adresse lisible d'un coup d'œil : 10.50.22.7 est une base en zone B.

La dernière colonne porte l'essentiel de la sécurité de ce projet. L'étage de données n'a aucune route vers l'extérieur, donc une donnée volée ne part pas facilement, et cela ne coûte rien : il suffit de ne pas ajouter la route.

Quels lots réaliser, selon votre piste ?

Le projet se découpe en lots, vérifiés chacun par l'état du système et non par vos commandes. Les quatre premiers, dits de construction et d'exploitation, sont ouverts à la piste Engineer et se jouent en local, à la main tant que leurs lots ne sont pas publiés dans le catalogue de labs. Les suivants relèvent de la piste Architecte. Le tableau dit où chaque lot se joue et ce qui est réellement prouvé : un choix de modèle ou une décision écrite se lit par un humain, seul l'état d'un système se prouve.

Lot	Piste	Où	Ce que vous livrez	Ce qui est prouvé
Dimensionnement	Engineer, Architecte	dsoxlab (KVM ou Incus)	un gabarit de machine justifié par un relevé de charge pris dans le lot	le gabarit ; le choix du modèle est évalué
Stockage	Engineer, Architecte	dsoxlab (outil fio) et banc objet local	une mesure de débit et de latence interprétée, une famille de stockage choisie, dont celle du seau de visuels de la boutique	la mesure interprétée ; le choix est évalué
Données	Engineer, Architecte	dsoxlab (KVM ou Incus)	la base des commandes, auto-gérée, qui n'écoute que sur son IP privée, sauvegardée puis restaurée sur une base neuve, comptages comparés	le raccordement privé et la restauration
Reconstruire et détruire	Engineer, Architecte	Feint	un second plan vide, l'environnement recréé, un inventaire vide après destruction	tout le geste
Garde-fous	Architecte	local	une politique Conftest que vous écrivez vous-même, variante de la règle de la leçon : elle refuse tout plan dont une ressource n'a pas les étiquettes environnement, equipe et projet, impose pour environnement une valeur permise (par exemple dev, recette ou prod) et vérifie aussi les actions update ; une étiquette Scaleway sans = ("environnement") doit être refusée, et non ignorée en silence (méthode dans la section Conftest de la leçon garde-fous), branchée et respectée	le garde-fou d'étiquetage ; comptes et budget sont évalués
Sortie	Architecte	local, deux stockages objet	une copie du seau de visuels vers un second stockage, empreintes sha256sum identiques	la sortie de données ; la grille de réversibilité est évaluée
Revue écrite	Architecte	document	la revue de la section « La revue d'architecture »	rien par machine : un humain la lit
Volet sur compte réel	Architecte	compte réel, chez Outscale ou Scaleway	indisponible : pas encore de ressources à créer, de plafond de dépense ni de contrôle de destruction	rien aujourd'hui : le volet Outscale ouvrira quand la vérification d'état des ressources Outscale existera

Glissez pour voir

Ces lots s'appuient sur les gestes des modules précédents : la sauvegarde et la restauration PostgreSQL pour le lot Données, la sortie de données pour le lot Sortie, le garde-fou d'étiquetage pour le lot Garde-fous. L'énoncé exécutable de chaque lot et sa vérification automatique par dsoxlab sont portés par le catalogue de labs Cloud (cloud-dsoxlab-training). Ce catalogue est publié depuis le 12 octobre 2026, mais seulement avec quatre labs de sa première vague : aucun lot du projet final n'y figure encore, et rien n'en est câblé sur cette page. Les éléments qui en dépendent (le répartiteur devant deux instances, les machines et les bancs des lots Dimensionnement, Stockage et Données) sont indisponibles aujourd'hui. Cette page fixe donc l'architecture, les critères et la méthode, et vous les appliquez à la main en attendant.

Comment assembler l'architecture, étape par étape ?

Huit étapes, dans cet ordre, construisent l'application à trois étages. Les lots du tableau vérifient chacun un morceau de l'ensemble ; ces étapes sont le fil rouge qui décrit l'ensemble, et les lots y sont rappelés entre parenthèses. Un lot se joue seul en local ; l'assemblage complet, avec la sortie Internet et les permissions réellement refusées, ne se prouve que sur un compte réel, dont le volet Outscale est aujourd'hui indisponible. Chaque étape s'appuie sur la précédente : le filtrage n'a pas de sens sans le découpage réseau, et l'alerte n'a rien à observer avant que le service ne réponde. Livrez-les une par une, en vérifiant l'étape avant de passer à la suivante, plutôt que de tout construire puis de tout déboguer ensemble.

1. Le réseau

   Réseau privé en /16, six sous-réseaux, deux tables de routage, une passerelle Internet, une passerelle NAT. Rien d'autre.

   Révision : tables de routage et passerelles.

2. Le filtrage

   Trois groupes de sécurité, un par étage. Chacun n'autorise que l'étage précédent, en référençant le groupe plutôt qu'une plage d'adresses. L'accès d'administration ne vient jamais de 0.0.0.0/0.

   Révision : sécurité réseau.

3. Les machines

   Deux instances applicatives, dans deux zones différentes, préparées par cloud-init et sans aucun secret dans leurs données de configuration. Prenez la taille en dessous de votre intuition, puis justifiez-la par un relevé de charge (lot Dimensionnement).

   Révision : choisir et dimensionner une machine.

4. Le répartiteur et le nom

   Répartiteur de niveau 7, terminaison TLS, sonde de santé sur une adresse applicative et non sur le port. Un nom de domaine pointe vers lui, avec un TTL court le temps du projet.

   Révision : répartition de charge et TLS et DNS managé.

5. Les données : la base et le seau de visuels

   Base des commandes dans l'étage de données, chiffrée, qui n'écoute que sur son adresse privée, avec sauvegardes activées et une fenêtre de restauration que vous aurez vérifiée. Managée chez un fournisseur qui la propose, auto-gérée sur une machine de l'hôte local (lot Données). Les visuels des produits vont dans un seau de stockage objet privé, sans accès public, lu par l'identité des machines applicatives (lot Stockage).

   Révision : joindre une base sans passer par Internet, réplication, sauvegarde et bascule et sauvegarde et restauration à distance.

6. Les identités et les secrets

   Une identité de charge de travail au droit minimal. Chez les hyperscalers, c'est une identité attachée à la machine ; chez Scaleway et Outscale, aucune identité attachée n'est documentée (absence documentaire, à confirmer auprès du fournisseur), donc le secret se récupère par un identifiant à durée courte, jamais par une clé longue écrite sur le disque. Le mot de passe de la base vit dans un gestionnaire de secrets, jamais dans le code ni dans cloud-init.

   Révision : gérer les identités et les accès.

7. La gouvernance

   Toutes les ressources étiquetées environnement, equipe et projet, avec un contrôle par politique as code sur le plan d'infrastructure plutôt que par un refus natif (lot Garde-fous). Un budget mensuel avec alerte à 50 %, 80 % et 100 % ; chez Outscale, où aucune alerte de budget n'est documentée, un script planifié qui lit la consommation en tient lieu.

   Révision : gouvernance et coûts.

8. L'observabilité

   Les journaux du répartiteur et des machines envoyés au service de journalisation, avec une rétention explicite et non celle par défaut. Une seule alerte, mais une vraie : le taux d'erreurs HTTP 5xx au-delà d'un seuil, routée vers une adresse que vous relevez.

   Révision : exploiter un environnement cloud.

Les critères de validation

Chaque ligne se vérifie par une commande ou une manipulation, pas par une impression. C'est la partie qui compte : une infrastructure qui « a l'air de marcher » n'a rien prouvé. La dernière colonne dit où le contrôle est possible, pour que vous ne cherchiez pas à vérifier sur Feint ce qu'il n'émule pas.

Ce qui doit être vrai	Comment le vérifier	Où
Le site répond en HTTPS	curl -I https://votre-nom renvoie 200 et un certificat valide	compte réel
Le second plan est vide	terraform plan après apply n'annonce aucun changement	Feint, compte réel
Les machines applicatives ne sont pas joignables	une connexion directe vers leur adresse échoue par expiration	compte réel
La base n'est pas joignable depuis Internet	idem, depuis une machine extérieure ; en local, elle n'écoute que sur son adresse privée	local, compte réel
Les machines sortent bien vers Internet	une mise à jour de paquets réussit depuis une machine applicative	compte réel
Une machine arrêtée ne casse pas le service	éteignez-en une, le site répond toujours	local, compte réel
La sonde retire un serveur défaillant	arrêtez le service applicatif sur une machine, elle sort de la rotation	local, compte réel
Aucun secret n'est en clair	relisez cloud-init et le dépôt : aucun mot de passe	local
La restauration fonctionne	restaurez la base dans une instance de test, chronomètre en main	local, compte réel
Le budget alerte	descendez temporairement le seuil, vérifiez que l'alerte arrive	compte réel
Tout est étiqueté	en local, conftest test plan.json rend le code 0 sur votre plan, et un code non nul sur quatre plans à refuser : sans étiquette, avec environnement=demo, avec une étiquette environnement sans valeur, et avec une ressource existante dont on retire une étiquette (action update) ; avec un compte réel, listez les ressources sans étiquette : la liste doit être vide	local, compte réel
Le seau des visuels est privé	une requête anonyme vers un objet est refusée, la lecture n'est permise qu'à l'identité des machines applicatives	compte réel
L'administration n'est ouverte à personne	aucun groupe de sécurité n'autorise le port 22 ou 3389 depuis 0.0.0.0/0	Feint, compte réel
Le filtrage référence des groupes	relisez les règles : aucune plage d'adresses privées codée en dur entre étages	Feint, compte réel
Le certificat est correct	openssl s_client -connect votre-nom:443 -servername votre-nom renvoie une chaîne complète et valide	compte réel
Les journaux arrivent	provoquez une erreur 500, retrouvez-la dans le service de journalisation	compte réel
L'alerte part vraiment	abaissez le seuil d'erreurs, provoquez-en, vérifiez la réception	compte réel
La rétention est choisie	aucun flux de journaux ne conserve « indéfiniment » par défaut	compte réel

Glissez pour voir

Le test que tout le monde saute

C'est la ligne « éteignez-en une ». Elle prend deux minutes et c'est la seule qui prouve que votre architecture est réellement redondante.

Le résultat est instructif dans les deux cas. Si le site tient, vous avez la preuve que la répartition fonctionne. S'il tombe, vous venez de découvrir en conditions choisies ce que vous auriez découvert un dimanche soir : une session en mémoire, une sonde qui teste le mauvais port, ou deux machines dans la même zone.

Chronométrez aussi le retour à la normale quand vous rallumez. C'est votre RTO réel (la durée de reprise après une panne) sur une panne simple.

La revue d'architecture

Une fois l'ensemble debout, rendez une revue écrite sur six axes, notée comme dans le gabarit de la leçon Well-Architected Frameworks. L'exercice prend une heure et vaut plus que la construction elle-même, car il transforme un montage en décisions assumées. Les cinq premiers axes sont les piliers communs à AWS, Azure et Google Cloud ; le sixième ajoute la souveraineté. Le pilier de durabilité n'est pas évalué ici.

Axe	La question à se poser
Sécurité	Que peut atteindre un attaquant qui compromet une machine applicative ?
Fiabilité	Qu'est-ce qui tombe si une zone entière disparaît ?
Performance	Quelle ressource sature en premier, et l'ai-je mesurée ?
Coût	Quelle serait la facture mensuelle, et quel poste domine ?
Excellence opérationnelle	Puis-je tout recréer depuis zéro avec le code, sans mémoire humaine ?
Souveraineté	Sous quelle juridiction sont mes données, et à quel coût puis-je partir ?

Glissez pour voir

Répondez par écrit, avec une note de 0 à 3 et une preuve par axe, pour la boutique et non pour une architecture en général. Une note de 3 exige une mesure ou un test daté, par exemple le chronomètre de la restauration ou le résultat de l'arrêt d'une machine ; sans preuve, la note vaut 0. Trois lignes par axe suffisent, et une réponse embarrassée signale toujours un vrai trou. La question sur le coût mérite un chiffre, même approximatif : une architecture dont personne ne sait estimer la facture est une architecture que personne n'arbitrera.

Terminez par les trois risques les plus graves, chacun avec une décision. Corriger, accepter ou reporter : chaque décision est consignée dans un ADR (fiche courte qui garde la décision et sa raison), reprise dans un plan d'action avec un propriétaire et une échéance. Un risque accepté porte le nom de la personne qui en assume la conséquence. Dites aussi ce que votre environnement n'a pas pu prouver (stockage objet sous Feint, permissions sans compte réel) : une revue qui avoue ses limites vaut plus qu'une revue qui les cache. Cette revue n'est vérifiée par aucune machine, un humain la lit.

Refaire le même projet ailleurs

Le meilleur usage de ce capstone est de le rejouer sur un second fournisseur. Le plan d'adressage ne change pas, les groupes de sécurité non plus, et vous mesurez alors ce qui est réellement transférable.

Ce qui se transpose tel quel : le découpage, les plages, la logique des trois étages, la sonde de santé, le principe de l'étiquetage. La règle Rego d'étiquetage, elle, s'adapte : elle lit des étiquettes en liste, et AWS les exprime en dictionnaire.

Ce qui demande une traduction : les noms des services, la façon de rendre un sous-réseau public, et surtout le modèle de permissions, qui diffère réellement d'un cloud à l'autre comme l'explique la page IAM.

Ce qui change vraiment la facture : le trafic sortant et la passerelle NAT, dont le traitement varie du tout au tout selon le fournisseur.

Détruire l'environnement, et vérifier qu'il ne reste rien

Le dernier lot du projet est sa destruction, et c'est un exercice à part entière. Une commande de destruction qui se termine sans erreur ne prouve pas que le compte est vide : elle prouve que l'outil a supprimé ce qu'il connaissait. Tout ce qui a été créé à côté, ou recréé automatiquement par un service, lui échappe.

1. Sauvegardez d'abord ce que vous voulez garder. Il s'agit du code d'infrastructure, vos réponses écrites à la revue d'architecture, et une capture de la facture du mois. Le reste est jetable, c'est le principe.

2. Lancez la destruction depuis votre outil, puis relisez son compte rendu ligne à ligne. Une ressource « conservée » y apparaît explicitement, et c'est souvent le seul endroit où vous la verrez.

   terraform destroy

3. Chassez les restes, qui se logent toujours aux mêmes endroits. Le tableau ci-dessous liste ceux qui survivent le plus souvent, et qui continuent à être facturés en silence.

4. Relevez la consommation 48 heures après la destruction, puis attendez la facture mensuelle. Le relevé, daté du jour où vous le prenez, montre ce que votre inventaire a oublié, mais le fournisseur ne documente pas toujours sa fréquence de mise à jour : un poste peut y arriver en retard. Seule la facture mensuelle fait foi, et c'est elle qui confirme que le compte est vide.

Ce qui survit à la destruction	Pourquoi	Ce que ça coûte
Les instantanés de disques et de bases	souvent créés hors du code, ou générés à la suppression de la base	facturés au gigaoctet, sans limite de durée
Les disques détachés	la suppression d'une machine ne supprime pas toujours son volume	plein tarif du stockage bloc
Les adresses IP publiques réservées	une adresse réservée reste facturée même sans usage	repère AWS au 12 octobre 2026 : 0,005 USD par heure (environ 3,60 USD par mois), attachée ou non (aws.amazon.com/vpc/pricing)
Les seaux de stockage objet non vides	un seau avec du versionnage refuse d'être supprimé tant que les anciennes versions existent	stockage plus requêtes
Les groupes de journaux	leur rétention par défaut est parfois illimitée	stockage qui ne décroît jamais
Les clés de chiffrement	leur suppression est différée d'un délai de sécurité, et la facturation dépend du fournisseur : AWS ne facture pas une clé en attente de suppression, mais la facture à nouveau si la suppression est annulée	repère AWS au 12 octobre 2026 : 1 USD par clé et par mois pour une clé active (aws.amazon.com/kms/pricing)
Les secrets	même logique de suppression différée, mais AWS ne facture pas un secret marqué pour suppression (documentation AWS Secrets Manager)	facturés au secret et par mois tant qu'ils ne sont pas marqués pour suppression
Les enregistrements DNS et la zone	rarement gérés par le même code que l'infrastructure	coût de la zone hébergée

Glissez pour voir

Le délai de suppression différée n'est pas un bug

Une clé de chiffrement et un secret ne se suppriment pas immédiatement : le fournisseur impose une période de récupération, typiquement de sept à trente jours, pendant laquelle l'objet est inutilisable mais restaurable.

Ce comportement est une protection, pas une gêne : il existe précisément parce qu'une clé supprimée par erreur rend illisibles toutes les données qu'elle protégeait, définitivement et sans recours. Vous ne pouvez pas le contourner, seulement raccourcir le délai à sa valeur minimale quand le fournisseur le permet.

La conséquence pratique est simple : votre compte peut ne pas être à zéro le jour de la destruction. Selon le fournisseur et l'objet, une ligne peut persister sur la facture le temps du délai : une clé ou un secret en attente de suppression n'est pas facturé chez AWS, alors qu'un instantané l'est (voir le tableau). Vérifiez sur la grille de votre fournisseur, et sachez de quelle ligne il s'agit.

Prenez l'habitude de détruire, y compris quand vous comptez recommencer demain. Une infrastructure décrite en code se reconstruit en quelques minutes, et cette reconstruction est justement le contrôle qui prouve que votre code est complet. Un environnement qu'on n'ose plus détruire est un environnement dont personne n'est certain qu'il se recrée : c'est exactement la situation que ce projet cherche à vous faire éviter.

À retenir

• Chaque environnement prouve autre chose : Feint vérifie l'existence et les liens, les machines lancées par dsoxlab un service qui tourne, le compte réel ce que seul un fournisseur fait.
• Les quatre lots de construction et d'exploitation se jouent en local, à la main tant que leurs lots ne sont pas publiés dans le catalogue de labs, sans compte ni carte bancaire ; garde-fous et sortie, deux lots locaux, puis la revue écrite relèvent de la piste Architecte ; seul le volet sur compte réel se jouera chez Outscale ou Scaleway, et il est indisponible pour l'instant.
• La destruction fait partie du projet. Une commande de destruction sans erreur ne prouve pas que le compte est vide : un relevé daté à 48 heures repère les restes, la facture mensuelle fait foi.
• Instantanés, disques détachés, adresses réservées et groupes de journaux sont les restes les plus fréquents, et ils se facturent en silence.
• Écrivez le plan d'adressage avant de créer quoi que ce soit : c'est la seule décision irréversible du projet.
• L'étage de données n'a aucune route sortante. Gratuit, et c'est la mesure qui gêne le plus un attaquant.
• Référencez les groupes de sécurité entre eux plutôt que des plages : la règle décrit un rôle et survit aux changements d'adressage.
• Aucun secret dans cloud-init, qui est lisible depuis la machine et depuis la console.
• Un second plan vide est le vrai test de votre code d'infrastructure.
• Éteignez une machine pour de bon, et chronométrez la restauration : ce sont les seuls tests qui prouvent la redondance et votre RTO réel.
• La revue se rend par écrit : une note de 0 à 3 et une preuve par axe, trois risques classés, une décision signée par risque.
• Rejouez le projet sur un second fournisseur pour mesurer ce qui est vraiment transférable.

×

📖 Voir la documentation →