Sécuriser l’Obby des Nuages

C’est l’heure de mettre en pratique tout le module. L’Obby des Nuages va gagner des checkpoints validés par le serveur, des pièces impossibles à aspirer à distance et une boutique où l’on ne peut ni choisir son prix ni dépenser des pièces qu’on n’a pas. On terminera par une séance de tests avec deux clients, dont un qui triche volontairement.

Préparer l’Explorer

Vérifie que ton projet contient ces éléments (crée ceux qui manquent) :

Workspace
├── Checkpoints (Folder)      → Parts ancrées nommées "1", "2", "3"…
└── Pieces (Folder)           → Parts ancrées nommées "Piece"
ReplicatedStorage
├── Modules (Folder)
│   └── Catalogue (ModuleScript)
└── Remotes (Folder)
    ├── AcheterObjet (RemoteEvent)
    └── Notification (RemoteEvent)
ServerScriptService
├── Validation (ModuleScript, leçon 4)
├── Progression (Script)
├── Pieces (Script)
└── Boutique (Script)

Le Script « Checkpoints » du module 3 (qui rangeait l’étape dans un attribut Etape du joueur) est remplacé par le Script « Progression » ci-dessous : désactive-le ou supprime-le, sinon les deux scripts réagiraient aux mêmes checkpoints. Le Script « PiecesTournantes » du module 3, lui, peut rester : il ne fait que tourner les pièces.

Des checkpoints validés dans l’ordre

La documentation de Roblox donne justement l’obby en exemple de conception défensive : plutôt que de chercher à détecter un joueur qui se téléporte à l’arrivée, on impose des checkpoints obligatoires, validés dans l’ordre par le serveur. Se téléporter au checkpoint 10 ne sert alors à rien.

Les règles du serveur :

le contact vient bien d’un personnage de joueur ;
le checkpoint touché est exactement l’étape suivante (Etape + 1) ;
le personnage est vraiment proche du checkpoint (un contact peut être simulé) ;
un passage anormalement rapide est journalisé, pas puni.

-- Script « Progression » placé dans ServerScriptService (côté serveur)
local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local ServerScriptService = game:GetService("ServerScriptService")
local Workspace = game:GetService("Workspace")

local Validation = require(ServerScriptService:WaitForChild("Validation"))

local dossierCheckpoints = Workspace:WaitForChild("Checkpoints")
local notification = ReplicatedStorage:WaitForChild("Remotes"):WaitForChild("Notification") :: RemoteEvent

local DISTANCE_MAX = 15 -- studs entre le personnage et le centre du checkpoint (augmente-la si tes checkpoints sont grands)
local TEMPS_MIN_ETAPE = 2 -- secondes : un passage plus rapide est suspect (journalisé seulement)

local dernierPassage: { [Player]: number } = {}

-- Renvoie l'IntValue « Etape » du joueur, ou nil si elle n'existe pas encore
local function obtenirEtape(player: Player): IntValue?
	local leaderstats = player:FindFirstChild("leaderstats")
	local etape = leaderstats and leaderstats:FindFirstChild("Etape")
	if etape and etape:IsA("IntValue") then
		return etape
	end
	return nil
end

-- Leaderstats minimales et réapparition au dernier checkpoint
local function initialiserJoueur(player: Player)
	local leaderstats = Instance.new("Folder")
	leaderstats.Name = "leaderstats"

	local etape = Instance.new("IntValue")
	etape.Name = "Etape"
	etape.Value = 0 -- 0 = aucun checkpoint atteint (départ sur la SpawnLocation)
	etape.Parent = leaderstats

	local pieces = Instance.new("IntValue")
	pieces.Name = "Pieces"
	pieces.Value = 0
	pieces.Parent = leaderstats

	leaderstats.Parent = player

	player.CharacterAdded:Connect(function(character: Model)
		if etape.Value == 0 then
			return -- premier départ : la SpawnLocation suffit
		end
		local checkpoint = dossierCheckpoints:FindFirstChild(tostring(etape.Value))
		if not (checkpoint and checkpoint:IsA("BasePart")) then
			return
		end
		-- CharacterAdded se déclenche AVANT que le personnage soit dans le Workspace,
		-- et Roblox le place sur la SpawnLocation juste APRÈS l'y avoir mis.
		-- On attend qu'il y soit, puis une image de plus, sinon notre placement serait écrasé.
		if not character:IsDescendantOf(Workspace) then
			character.AncestryChanged:Wait()
		end
		task.wait()
		if not character:IsDescendantOf(Workspace) then
			return -- le personnage a déjà disparu (joueur parti, nouvelle réapparition…)
		end
		character:PivotTo(checkpoint.CFrame + Vector3.new(0, 4, 0))
	end)
end

local function surContactCheckpoint(checkpoint: BasePart, partieTouchee: BasePart)
	-- 1. Le contact vient-il d'un personnage de joueur ?
	local player = Players:GetPlayerFromCharacter(partieTouchee.Parent)
	if player == nil then
		return
	end

	local numero = tonumber(checkpoint.Name)
	local etape = obtenirEtape(player)
	if numero == nil or etape == nil then
		return
	end

	-- 2. Uniquement l'étape SUIVANTE : ni retour en arrière, ni saut d'étapes
	if numero ~= etape.Value + 1 then
		return
	end

	-- 3. Distance réelle : un tricheur peut provoquer un contact à distance
	if not Validation.estAPortee(player, checkpoint.Position, DISTANCE_MAX) then
		return
	end

	-- 4. Heuristique : passage trop rapide → on note, on ne punit pas
	local maintenant = os.clock()
	local precedent = dernierPassage[player]
	if precedent and maintenant - precedent < TEMPS_MIN_ETAPE then
		warn(string.format("[Anti-triche] %s : étape %d atteinte en %.1f s", player.Name, numero, maintenant - precedent))
	end
	dernierPassage[player] = maintenant

	-- Tout est valide : le SERVEUR met à jour la progression
	etape.Value = numero
	notification:FireClient(player, "Étape " .. numero .. " atteinte !")
end

-- On branche chaque checkpoint du dossier
for _, checkpoint in dossierCheckpoints:GetChildren() do
	if checkpoint:IsA("BasePart") then
		checkpoint.Touched:Connect(function(partieTouchee: BasePart)
			surContactCheckpoint(checkpoint, partieTouchee)
		end)
	end
end

Players.PlayerAdded:Connect(initialiserJoueur)
-- Joueurs déjà présents si le script démarre après eux (rare, mais possible en test)
for _, player in Players:GetPlayers() do
	task.spawn(initialiserJoueur, player)
end

Players.PlayerRemoving:Connect(function(player: Player)
	dernierPassage[player] = nil
end)

Des pièces ramassées par le serveur

Pour une pièce, le serveur vérifie que le joueur est assez près et applique un cooldown par joueur : même en se téléportant partout, un tricheur ne peut pas vider la carte en une fraction de seconde. La pièce disparaît pour tout le monde, puis réapparaît au bout de quelques secondes.

-- Script « Pieces » placé dans ServerScriptService (côté serveur)
local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local ServerScriptService = game:GetService("ServerScriptService")
local Workspace = game:GetService("Workspace")

local Config = require(ReplicatedStorage:WaitForChild("Modules"):WaitForChild("Config"))
local Validation = require(ServerScriptService:WaitForChild("Validation"))

local dossierPieces = Workspace:WaitForChild("Pieces")

local VALEUR_PIECE = Config.VALEUR_PIECE -- réglage commun du module Config (valeur décidée par le SERVEUR)
local DISTANCE_MAX = 12 -- studs
local DELAI_REAPPARITION = 10 -- secondes avant que la pièce revienne

-- Un même joueur ne peut ramasser qu'une pièce toutes les 0,2 seconde
local peutRamasser = Validation.creerCooldown(0.2)

local function preparerPiece(piece: BasePart)
	local transparenceInitiale = piece.Transparency
	local disponible = true -- état connu du serveur seulement

	piece.Touched:Connect(function(partieTouchee: BasePart)
		if not disponible then
			return -- déjà ramassée (évite aussi les contacts multiples d'un même personnage)
		end

		local player = Players:GetPlayerFromCharacter(partieTouchee.Parent)
		if player == nil then
			return
		end

		-- Le personnage est-il vraiment à côté de la pièce ?
		if not Validation.estAPortee(player, piece.Position, DISTANCE_MAX) then
			return
		end

		-- Ramassage trop rapide pour ce joueur ?
		if not peutRamasser(player) then
			return
		end

		local leaderstats = player:FindFirstChild("leaderstats")
		local pieces = leaderstats and leaderstats:FindFirstChild("Pieces")
		if not (pieces and pieces:IsA("IntValue")) then
			return
		end

		-- On désactive la pièce AVANT de récompenser : un second contact ne passera pas
		disponible = false
		piece.Transparency = 1
		piece.CanTouch = false
		pieces.Value += VALEUR_PIECE

		task.delay(DELAI_REAPPARITION, function()
			disponible = true
			piece.Transparency = transparenceInitiale
			piece.CanTouch = true
		end)
	end)
end

for _, piece in dossierPieces:GetChildren() do
	if piece:IsA("BasePart") and piece.Name == "Piece" then
		preparerPiece(piece)
	end
end

Pourquoi deux protections ? La variable disponible empêche qu’une même pièce soit comptée deux fois (par deux parties du corps, ou par deux joueurs en même temps). Le cooldown par joueur, lui, limite la vitesse de ramassage d’un même joueur.

Une boutique impossible à truquer

Le catalogue

Le catalogue est un ModuleScript dans ReplicatedStorage.Modules : le client peut le lire pour afficher les prix, et le serveur l’utilise pour décider. Un tricheur peut modifier sa copie locale, mais cela ne change rien à la copie du serveur.

-- ModuleScript « Catalogue » placé dans ReplicatedStorage > Modules (partagé client/serveur)
export type Objet = {
	nom: string, -- nom affiché (accents autorisés)
	prix: number, -- prix en pièces
}

local Catalogue: { [string]: Objet } = {
	TrailNuage = { nom = "Traînée Nuage", prix = 25 },
	TrailSoleil = { nom = "Traînée Soleil", prix = 75 },
	TrailAurore = { nom = "Traînée Aurore", prix = 150 },
}

return Catalogue

Ces identifiants (TrailNuage, TrailSoleil, TrailAurore) sont ceux du module 5, qui complétera ce catalogue avec les couleurs des traînées.

Le script serveur de la boutique

Le client envoie uniquement l’identifiant de l’objet, par exemple "TrailNuage". Le serveur répond sur le même RemoteEvent avec FireClient pour indiquer si l’achat a réussi.

-- Script « Boutique » placé dans ServerScriptService (côté serveur)
local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local ServerScriptService = game:GetService("ServerScriptService")

local Validation = require(ServerScriptService:WaitForChild("Validation"))
local Catalogue = require(ReplicatedStorage:WaitForChild("Modules"):WaitForChild("Catalogue"))

local acheterObjet = ReplicatedStorage:WaitForChild("Remotes"):WaitForChild("AcheterObjet") :: RemoteEvent

local LONGUEUR_ID_MAX = 50
local peutAcheter = Validation.creerCooldown(1) -- un achat par seconde maximum

-- Objets possédés, gardés sur le serveur (sauvegardés au module 5)
local objetsPossedes: { [Player]: { [string]: boolean } } = {}

local function acheter(player: Player, idObjet: unknown): (boolean, string)
	-- 1. Type et taille
	if not Validation.estTexte(idObjet, LONGUEUR_ID_MAX) then
		return false, "Requête invalide."
	end
	local id = idObjet :: string

	-- 2. Débit
	if not peutAcheter(player) then
		return false, "Doucement ! Réessaie dans un instant."
	end

	-- 3. L'objet existe : le PRIX vient du catalogue du serveur, jamais du client
	local objet = Catalogue[id]
	if objet == nil then
		return false, "Cet objet n'existe pas."
	end

	-- 4. Pas déjà possédé
	local possedes = objetsPossedes[player]
	if possedes == nil then
		return false, "Tes données ne sont pas encore prêtes."
	end
	if possedes[id] then
		return false, "Tu possèdes déjà cet objet."
	end

	-- 5. Solde réel, lu sur le serveur
	local leaderstats = player:FindFirstChild("leaderstats")
	local pieces = leaderstats and leaderstats:FindFirstChild("Pieces")
	if not (pieces and pieces:IsA("IntValue")) then
		return false, "Tes données ne sont pas encore prêtes."
	end
	if pieces.Value < objet.prix then
		return false, "Il te manque " .. (objet.prix - pieces.Value) .. " pièce(s)."
	end

	-- 6. Transaction : on retire le prix et on ajoute l'objet, sans pause entre les deux
	pieces.Value -= objet.prix
	possedes[id] = true
	return true, objet.nom .. " achetée !"
end

-- Les arguments en trop (un « prix » envoyé par un tricheur, par exemple) sont simplement ignorés
acheterObjet.OnServerEvent:Connect(function(player: Player, idObjet: unknown)
	local succes, message = acheter(player, idObjet)
	acheterObjet:FireClient(player, succes, message)
end)

Players.PlayerAdded:Connect(function(player: Player)
	objetsPossedes[player] = {}
end)
for _, player in Players:GetPlayers() do
	objetsPossedes[player] = {}
end

Players.PlayerRemoving:Connect(function(player: Player)
	objetsPossedes[player] = nil
end)

Les étapes 5 et 6 se suivent sans aucune pause (pas de task.wait ni d’appel réseau entre elles). Deux demandes ne peuvent donc pas « passer entre les gouttes » pour dépenser deux fois les mêmes pièces.

Le côté client

En attendant l’interface du module 5, un LocalScript de démonstration achète la Traînée Nuage au bout de quelques secondes et affiche la réponse du serveur :

-- LocalScript placé dans StarterPlayer > StarterPlayerScripts (côté client)
local ReplicatedStorage = game:GetService("ReplicatedStorage")

local acheterObjet = ReplicatedStorage:WaitForChild("Remotes"):WaitForChild("AcheterObjet") :: RemoteEvent

-- Réponse du serveur
acheterObjet.OnClientEvent:Connect(function(succes: boolean, message: string)
	if succes then
		print("Achat réussi :", message)
	else
		warn("Achat refusé :", message)
	end
end)

-- Démonstration : on DEMANDE l'achat par son identifiant (au module 5, ce sera un bouton)
task.wait(5)
acheterObjet:FireServer("TrailNuage")

Avec Claude Code

Cette leçon touche cinq fichiers : demande d’abord un plan, puis fais écrire un script à la fois (Progression, puis Pieces, puis le Catalogue et la Boutique), en testant entre chaque. Le prompt est précis parce qu’il reprend chaque règle de sécurité de la leçon, avec ses chiffres, et donne les tests de la section suivante comme critère de réussite. Le LocalScript de démonstration n’a pas de nom dans la leçon : le prompt l’appelle DemoAchat.

Sécuriser checkpoints, pièces et boutique

Commence par me proposer un plan (mode plan), sans modifier de fichier. Ensuite, on écrira un script à la fois, en testant entre chaque.

Contexte : mon jeu Roblox « Obby des Nuages » est un projet Rojo. Je sécurise la progression, les pièces et la boutique : le client ne fait que demander, le serveur valide tout.
Ce qui existe déjà : src/ServerScriptService/Validation.luau (estTexte, estAPortee, creerCooldown…) ; dans default.project.json, les RemoteEvents AcheterObjet et Notification dans ReplicatedStorage.Remotes ; dans Studio, Workspace.Checkpoints (Parts ancrées "1", "2", "3"…) et Workspace.Pieces (Parts ancrées nommées "Piece"). Les conventions sont dans CLAUDE.md.
Objectif : (1) l'étape n'avance que checkpoint par checkpoint, et le joueur réapparaît sur son dernier checkpoint ; (2) une pièce ramassée rapporte 1 pièce, disparaît pour tout le monde et revient 10 secondes plus tard ; (3) un achat de traînée n'aboutit que si le joueur a assez de pièces et ne possède pas déjà l'objet.
Fichiers concernés : crée dans src/ServerScriptService les Scripts Progression.server.luau, Pieces.server.luau et Boutique.server.luau ; crée src/ReplicatedStorage/Modules/Catalogue.luau (TrailNuage 25, TrailSoleil 75, TrailAurore 150, chacun avec un nom affiché) et le LocalScript de démonstration src/StarterPlayer/StarterPlayerScripts/DemoAchat.client.luau (achète "TrailNuage" au bout de 5 secondes et affiche la réponse). Supprime src/ServerScriptService/Checkpoints.server.luau s'il existe (Progression le remplace). Ne modifie rien d'autre.
Contraintes techniques : Progression crée les leaderstats (Folder "leaderstats" avec les IntValue Etape = 0 et Pieces = 0) à PlayerAdded et pour les joueurs déjà présents ; à CharacterAdded, il attend que le personnage soit dans le Workspace puis une image (task.wait()) avant de le placer avec PivotTo 4 studs au-dessus de son dernier checkpoint. Quand une étape est validée, Progression prévient le joueur avec Notification:FireClient(player, "Étape N atteinte !"). Un seul script par dossier, qui parcourt ses Parts (pas un script par Part). Boutique répond sur AcheterObjet avec FireClient(player, succes, message).
Sécurité : checkpoint accepté seulement si numero == Etape + 1 et si Validation.estAPortee(player, checkpoint.Position, 15) ; un passage en moins de 2 secondes est journalisé avec warn, jamais puni. Pièce : distance au plus 12 studs, cooldown de 0,2 seconde par joueur, pièce marquée indisponible AVANT d'ajouter la récompense ; la valeur d'une pièce est décidée par le serveur. Achat : le client envoie seulement l'identifiant ; dans cet ordre, Validation.estTexte(id, 50), cooldown de 1 seconde, objet présent dans Catalogue, objet pas déjà possédé, solde réel lu dans leaderstats.Pieces ; le prix vient TOUJOURS du Catalogue ; le débit et l'ajout à l'inventaire se suivent sans aucune pause (ni task.wait ni appel réseau). Tout argument en trop est ignoré.
Cas limites : contact d'une Part qui n'appartient pas à un personnage ; joueur qui tombe sur un checkpoint précédent (il ne recule pas) ; deux joueurs sur la même pièce ; leaderstats ou inventaire pas encore prêts (message « Tes données ne sont pas encore prêtes. ») ; arguments piégés (nil, 0/0, une table, un texte de 10 000 caractères, un identifiant inconnu) ; joueur qui part (vide les tables indexées par Player).
Vérification : en mode Server & Clients avec 2 clients, une pièce n'est ramassée qu'une fois ; mettre Pieces à 9999 dans la fenêtre Properties d'un client ne permet pas d'acheter TrailAurore ; un LocalScript temporaire TestTriche (arguments piégés, 20 achats en rafale, téléportation au checkpoint 3) ne fait gagner ni objet ni étape ; selene et StyLua ne signalent aucune erreur. Supprime TestTriche à la fin.

À vérifier dans le code produit :

dans Progression, la condition est bien numero ~= etape.Value + 1 → return, et non numero > etape.Value ;
Validation.estAPortee est appelé dans Progression et dans Pieces : un contact Touched n’est pas une preuve ;
dans Pieces, la pièce est rendue indisponible (disponible = false) avant pieces.Value += VALEUR_PIECE ;
dans Boutique, OnServerEvent ne lit que (player, idObjet), et le montant débité est objet.prix, lu dans Catalogue[id] ;
entre la vérification du solde et l’ajout de l’objet, aucune ligne ne fait de pause (task.wait, appel …Async) ;
aucun remote « de debug » ne reste dans le projet, et TestTriche a bien été supprimé.

Tester ses protections

Une protection non testée est une protection qui ne marche pas. Utilise le mode Server & Clients de Studio : dans le menu déroulant des modes de test, choisis-le, règle 2 clients et lance. Studio ouvre une fenêtre serveur et une fenêtre par client.

Test 1 : deux joueurs, une pièce

Avec les deux clients, approche-toi de la même pièce. Un seul joueur la récupère, elle disparaît dans les deux fenêtres, et elle revient après 10 secondes. Vérifie les compteurs dans la fenêtre serveur (Explorer → Players → ton joueur → leaderstats).

Test 2 : un faux solde

Dans la fenêtre du client 1, ouvre Players → ton joueur → leaderstats → Pieces et mets Value à 9999 dans Properties. Puis fais acheter "TrailAurore" (change l’identifiant dans le LocalScript de démonstration). Tant que ton vrai solde est inférieur à 150 pièces, l’achat est refusé : le serveur voit toujours ton vrai solde. Dans la fenêtre serveur, Pieces n’a pas bougé.

Test 3 : un client tricheur

Ajoute temporairement ce LocalScript, qui imite un logiciel de triche :

-- LocalScript TEMPORAIRE « TestTriche » (StarterPlayerScripts) : simule un client malveillant
-- À SUPPRIMER après les tests !
local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local Workspace = game:GetService("Workspace")

local acheterObjet = ReplicatedStorage:WaitForChild("Remotes"):WaitForChild("AcheterObjet") :: RemoteEvent
local player = Players.LocalPlayer

task.wait(8)

-- Arguments piégés : tous doivent être refusés par le serveur
acheterObjet:FireServer(nil)
acheterObjet:FireServer(0 / 0)
acheterObjet:FireServer({ prix = 0 })
acheterObjet:FireServer(string.rep("A", 10000))
acheterObjet:FireServer("ObjetInexistant")
task.wait(1.5) -- on attend la fin du cooldown d'achat (1 s) pour isoler le test suivant
acheterObjet:FireServer("TrailAurore", 0) -- le « prix » est ignoré : le serveur lit 150 dans son catalogue
task.wait(1.5)

-- Spam : au plus un achat par seconde passe le cooldown
for _ = 1, 20 do
	acheterObjet:FireServer("TrailNuage")
end

-- Téléportation : le client déplace son propre personnage (la position est répliquée !)
local character = player.Character or player.CharacterAdded:Wait()
local dernierCheckpoint = Workspace:WaitForChild("Checkpoints"):FindFirstChild("3")
if dernierCheckpoint and dernierCheckpoint:IsA("BasePart") then
	character:PivotTo(dernierCheckpoint.CFrame + Vector3.new(0, 3, 0))
end

Résultats attendus dans l’Output :

chaque argument piégé reçoit un refus : « Requête invalide » pour nil, NaN, la table et le texte géant, « Cet objet n’existe pas » pour l’identifiant inconnu ;
l’achat de "TrailAurore" avec un prix de 0 est refusé (« Il te manque… ») si tu as moins de 150 pièces : le prix envoyé n’a servi à rien ;
sur les 20 demandes de spam, une seule passe le cooldown (et l’achat ne réussit que si tu as assez de pièces et ne possèdes pas déjà la traînée), les 19 autres reçoivent « Doucement ! » ;
le personnage apparaît bien sur le checkpoint 3 (le client contrôle sa position), mais ton Etape ne passe pas à 3 si tu n’as pas validé les étapes 1 et 2. La téléportation ne rapporte rien ;
si le détecteur de déplacements de la leçon 4 est actif, il signale cette téléportation dans l’Output, sans exclure personne.

Ce qu’il faut retenir

Les checkpoints n’acceptent que l’étape suivante (Etape + 1) et vérifient la distance réelle : se téléporter ne sert à rien.
Les pièces sont ramassées par le serveur : distance, cooldown par joueur, pièce désactivée avant la récompense.
Le client envoie seulement l’identifiant de l’objet ; le serveur vérifie le type, le débit, l’existence, la possession et le solde réel, avec le prix de son catalogue.
Retirer les pièces et ajouter l’objet se fait sans pause entre les deux.
On teste avec Server & Clients et un LocalScript « tricheur » temporaire, à supprimer avant publication.

Rechercher dans la formation

Sécuriser l’Obby des Nuages

🎯 Dans cette leçon, tu vas apprendre à…

Préparer l’Explorer

Des checkpoints validés dans l’ordre

Des pièces ramassées par le serveur

Une boutique impossible à truquer

Le catalogue

Le script serveur de la boutique

Le côté client

Tester ses protections

Test 1 : deux joueurs, une pièce

Test 2 : un faux solde

Test 3 : un client tricheur

Ce qu’il faut retenir

Sources et pour aller plus loin

Quiz : vérifie tes acquis

🎯 Dans cette leçon, tu vas apprendre à…

Préparer l’Explorer

Des checkpoints validés dans l’ordre

Des pièces ramassées par le serveur

Une boutique impossible à truquer

Le catalogue

Le script serveur de la boutique

Le côté client

Tester ses protections

Test 1 : deux joueurs, une pièce

Test 2 : un faux solde

Test 3 : un client tricheur

📌 Ce qu’il faut retenir

📚 Sources et pour aller plus loin

Ce qu’il faut retenir

Sources et pour aller plus loin