Aller au contenu
Forma Roblox

Rechercher dans la formation

Module 10 · Leçon 5 sur 5

Audit de performance de l’Obby des Nuages

Mène un audit complet de ton obby (scripts, physique, réseau, rendu, mémoire, streaming, interface mobile), corrige les problèmes un par un et prouve le gain avec des mesures avant/après.

  • ⏱️ 40 min
  • 📝 Quiz de 6 questions
  • 🔄 Vérifié le 24 octobre 2026
Sur cette page

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

  • Mener un audit de performance complet avec une checklist
  • Corriger les problèmes trouvés un par un, sans casser le gameplay
  • Vérifier le gain sur mobile avec des mesures avant/après
  • Documenter tes choix dans un journal de performance

C’est le moment de tout mettre en pratique. Dans cette leçon, tu vas réaliser un audit de performance complet de l’Obby des Nuages : mesurer, passer une checklist, corriger, vérifier, documenter. C’est exactement le cycle « identifier, améliorer, surveiller » que décrit la documentation Roblox. À la fin, tu auras un obby plus fluide sur mobile, et la preuve chiffrée du gain.

Étape 1 : préparer l’audit

Fais une sauvegarde

Avant de toucher à quoi que ce soit, garde une copie de ton jeu : File › Save to File As pour une copie locale, ou appuie-toi sur l’historique des versions publiées (vu au module 1). Si une optimisation tourne mal, tu pourras revenir en arrière.

Choisis tes conditions de mesure

Pour que « avant » et « après » soient comparables, fixe tes conditions une fois pour toutes :

  • le même appareil : ton téléphone de référence de la leçon 1 (et ton PC en complément) ;
  • le même parcours : par exemple, du spawn jusqu’à l’étape 10, en ramassant les pièces sur le chemin ;
  • la même durée : environ 5 minutes de jeu, plus une session de 10 à 15 minutes pour la surchauffe ;
  • le vrai jeu publié, pas Studio, pour les chiffres de FPS et de mémoire.

Remplis ta fiche de mesure « avant »

Recopie ce tableau dans un document ou un tableur :

Mesure Outil Avant Après
FPS moyen sur le parcours Performance Stats
FPS dans la zone la plus chargée Performance Stats
Pics visibles (oui/non, où) MicroProfiler
Mémoire client après 5 minutes Developer Console, Memory
Mémoire client après 15 minutes Developer Console, Memory
Ping Performance Stats
Temps de chargement (moyenne de 3 essais) Chronomètre
Heartbeat du serveur Developer Console, Server Jobs
Erreurs dans le Log Developer Console, Log

Étape 2 : passer la checklist

Passe chaque catégorie, coche ce qui est bon, note ce qui ne l’est pas. Ne corrige rien pour l’instant : d’abord l’inventaire.

Scripts

Mémoire

Physique

Réseau

Rendu

Streaming

Interface mobile

Étape 3 : un script d’audit pour gagner du temps

Compter à la main les Parts non ancrées ou les lumières avec ombres est fastidieux. Ce script fait l’inventaire pour toi. Il ne modifie rien : il compte et affiche.

-- À exécuter dans la Command Bar de Studio (vue au module 1), en mode édition (pas pendant un test).
-- Copie tout le script, colle-le dans la Command Bar, puis appuie sur Entrée.
-- Ce script ne modifie rien : il compte et affiche le résultat dans l'Output.
local Workspace = game:GetService("Workspace")
local ReplicatedStorage = game:GetService("ReplicatedStorage")

-- Dossiers du fil rouge dont les Parts ont BESOIN du contact (Touched)
local dossiersGameplay = {}
for _, nom in { "Checkpoints", "KillBricks", "Pieces" } do
	local dossier = Workspace:FindFirstChild(nom)
	if dossier then
		table.insert(dossiersGameplay, dossier)
	end
end

local function estUnObjetDeGameplay(objet: Instance): boolean
	if objet:IsA("SpawnLocation") then
		return true -- le point d'apparition a aussi besoin du contact
	end
	for _, dossier in dossiersGameplay do
		if objet:IsDescendantOf(dossier) then
			return true
		end
	end
	return false
end

local compte = {
	parts = 0,
	nonAncrees = 0,
	decorsAvecContact = 0,
	transparencePartielle = 0,
	maillagesPrecis = 0,
	lumieresAvecOmbres = 0,
	emetteursParticules = 0,
	scripts = 0,
}

for _, objet in Workspace:GetDescendants() do
	if objet:IsA("BasePart") and not objet:IsA("Terrain") then
		compte.parts += 1
		if not objet.Anchored then
			compte.nonAncrees += 1
		end
		if objet.CanTouch and not estUnObjetDeGameplay(objet) then
			compte.decorsAvecContact += 1
		end
		if objet.Transparency > 0 and objet.Transparency < 1 then
			compte.transparencePartielle += 1
		end
		if objet:IsA("MeshPart") and objet.RenderFidelity == Enum.RenderFidelity.Precise then
			compte.maillagesPrecis += 1
		end
	elseif objet:IsA("Light") and objet.Shadows then
		compte.lumieresAvecOmbres += 1
	elseif objet:IsA("ParticleEmitter") then
		compte.emetteursParticules += 1
	elseif objet:IsA("LuaSourceContainer") then
		compte.scripts += 1
	end
end

print("===== Audit de l'Obby des Nuages =====")
print(string.format("Parts dans Workspace : %d", compte.parts))
print(string.format("Parts non ancrées : %d", compte.nonAncrees))
print(string.format("Décors avec CanTouch actif : %d", compte.decorsAvecContact))
print(string.format("Parts semi-transparentes : %d", compte.transparencePartielle))
print(string.format("MeshParts en RenderFidelity Precise : %d", compte.maillagesPrecis))
print(string.format("Lumières avec ombres : %d", compte.lumieresAvecOmbres))
print(string.format("Émetteurs de particules : %d", compte.emetteursParticules))
print(string.format("Scripts dans Workspace : %d", compte.scripts))
print(string.format("Objets dans ReplicatedStorage : %d", #ReplicatedStorage:GetDescendants()))

Ces chiffres ne sont pas des « notes » : il n’existe pas de nombre magique de Parts à ne pas dépasser. Ils te montrent où regarder. Par exemple, 40 Parts non ancrées dans un obby sans objets physiques, c’est suspect ; 25 scripts dans le Workspace, c’est peut-être un script de rotation copié dans chaque pièce.

Étape 4 : corriger, un problème à la fois

Classe ta liste : d’abord ce qui gêne le plus les joueurs selon tes mesures (pics, FPS bas sur mobile, plantages), ensuite le reste. Puis, pour chaque problème :

  1. Corrige-le avec les techniques de la leçon 4 (et de la leçon 3 pour le streaming).
  2. Teste le gameplay concerné.
  3. Mesure dans tes conditions fixées.
  4. Note le résultat dans ton journal (voir l’étape 6).

Pour l’Obby des Nuages, les corrections les plus probables sont :

  • ancrer les Parts oubliées ;
  • passer les décors (nuages, rambardes, îles décoratives) en CanCollide, CanTouch et CanQuery à false, et leur CollisionFidelity en Box ou Hull s’il s’agit de MeshParts ;
  • remplacer la rotation des pièces côté serveur par le LocalScript de la leçon 4 ;
  • vérifier que le compteur de pièces réagit à Changed (comme ScriptInterface au module 5) et ne tourne pas à chaque image ;
  • réduire les nuages semi-transparents superposés et les lumières avec ombres ;
  • vérifier les réglages de streaming et corriger les LocalScripts qui plantent avec un petit rayon.

Étape 5 : vérifier le gain et traquer les régressions

Une régression, c’est quelque chose qui marchait et ne marche plus (ou des performances qui se dégradent après une mise à jour). Pour les repérer :

  • Rejoue tout le gameplay, comme décrit ci-dessus.
  • Teste à plusieurs dans Studio (mode serveur + 2 clients, comme au module 4) : les problèmes de LocalScripts et de streaming apparaissent souvent là.
  • Refais le test du petit rayon (StreamingTargetRadius à 64) puis remets la valeur recommandée.
  • Remplis la colonne « Après » de ta fiche, sur ton téléphone de référence. C’est là que le gain compte.

Surveiller après la publication

Une fois la nouvelle version publiée, la page Performance du Creator Dashboard prend le relais. Dans le Creator Hub, ouvre Creations, choisis ton jeu, puis le menu Monitoring › Performance. Elle affiche notamment, ventilés par plateforme :

  • la fréquence d’images des clients ;
  • le taux de plantage des clients et les sorties inattendues par manque de mémoire ;
  • la mémoire des clients et du serveur, et le heartbeat du serveur.

Tu peux aussi ventiler les métriques client par version du place (Place Version) pour comparer ta nouvelle version aux précédentes. Au moment de la rédaction (octobre 2026), la documentation indique que les graphiques nécessitent au moins 100 utilisateurs actifs par jour : sur un petit jeu, tes mesures manuelles restent donc essentielles.

Étape 6 : documenter tes choix

Tiens un journal de performance. Un simple tableau suffit :

Date Changement Avant Après Décision
24/10 Rotation des pièces passée côté client … FPS zone 2 (téléphone) … FPS zone 2 Gardé
24/10 Nuages décoratifs : CanCollide, CanTouch, CanQuery à false … … Gardé
24/10 StreamingTargetRadius réduit à 512 … décor lointain qui « pop » (apparaît d’un coup) Annulé, retour à 1024

(Remplace les « … » par tes propres mesures : chaque jeu et chaque appareil donne des résultats différents.)

Ce journal t’évite de refaire deux fois la même expérience, explique tes réglages à un futur collaborateur, et te permet de retrouver vite la cause d’une régression.

Ce qu’il faut retenir

  • Un audit suit le cycle : sauvegarder, mesurer (avant), passer la checklist, corriger un problème à la fois, mesurer (après), documenter.
  • La checklist couvre scripts, mémoire, physique, réseau, rendu, streaming et interface mobile.
  • Un script d’inventaire dans la Command Bar montre où regarder, mais ne remplace pas la mesure.
  • Après chaque série de corrections, rejoue tout le gameplay pour éviter les régressions, puis vérifie le gain sur ton appareil de référence.
  • Après publication, la page Performance du Creator Dashboard suit FPS, mémoire et plantages par appareil et par version.

Sources et pour aller plus loin

Quiz : vérifie tes acquis

6 questions · réussite à partir de 70 % · valide chaque réponse pour voir l’explication

  1. Question 1QCMPendant l’audit, tu trouves cinq problèmes. Quelle méthode permet de savoir lequel apportait vraiment un gain ?
  2. Question 2Trouve le bugCe script d’audit doit compter les Parts non ancrées de tout le Workspace. Il affiche 0, alors que plusieurs plateformes rangées dans des dossiers ne sont pas ancrées. Où est le bug ?
    local Workspace = game:GetService("Workspace")

local nonAncrees = 0
for _, objet in Workspace:GetChildren() do
	if objet:IsA("BasePart") and not objet.Anchored then
		nonAncrees += 1
	end
end
print("Parts non ancrées : " .. nonAncrees)
  3. Question 3Vrai ou fauxAprès une optimisation, il faut rejouer tout l’obby (kill bricks, checkpoints, pièces, boutique, sauvegarde) pour vérifier que rien n’est cassé.
  4. Question 4QCMQuel outil permet de suivre, après publication, la fréquence d’images, la mémoire et le taux de plantage de tes joueurs par type d’appareil ?
  5. Question 5QCMPourquoi tenir un journal de performance (date, changement, mesure avant, mesure après, décision) ?
  6. Question 6Améliore ce promptTu veux que Claude Code t’aide à mener l’audit de performance de l’Obby des Nuages. Quelle version du prompt donnera le meilleur résultat ?
    Le prompt de départ
    fais l'audit de performance de mon jeu et corrige tout

    Choisis la meilleure version de ce prompt.