Checklist avant mise en ligne d'un mini-jeu Cocos Creator : performance, paquet, adaptation et validation

Le jour de ma première soumission à la validation, j’ai fixé la popup « rejet de validation » — la tête qui tourne. Paquet trop lourd : 6,8 Mo dans le paquet principal, alors que WeChat impose 4 Mo. Trois jours de corrections : compression de textures, transcodage audio, élagage des modules moteur — j’ai fini à 3,2 Mo pour passer.

Cette expérience m’a montré que les contrôles pré-lancement suivent une logique claire. Ce n’est pas la chance : ce sont des seuils chiffrés et des méthodes de test explicites. J’ai regroupé mes erreurs en une checklist que je coche avant chaque soumission. Elle a évolué une dizaine de fois et couvre 15 points en 4 modules : performance, paquet, adaptation, validation.

Cet article partage cette checklist. Chaque point a un seuil chiffré, l’outil de test à utiliser et les pièges les plus fréquents. À la fin, vous pourrez auto-contrôler point par point et augmenter nettement vos chances d’acceptation du premier coup.

I. Contrôle performance : ne laissez pas le lag gâcher l’expérience

Les problèmes de performance sont l’une des principales causes de churn. Votre jeu peut tourner fluidement sur votre téléphone — mais votre appareil de test est probablement récent, alors que vos utilisateurs ont parfois un modèle de trois ans en arrière. L’écart de performance entre iPhone haut et bas de gamme peut atteindre 3 à 4× : ce n’est pas une blague.

1. Stabilité FPS

Critère : haut de gamme (iPhone X et plus) cible 60 FPS ; bas de gamme (iPhone 6s/7/8) cible 30 FPS. Le pic ne doit pas descendre sous 80 % de la cible — soit minimum 48 FPS haut de gamme, 24 FPS bas de gamme.

Méthode : affichage FPS intégré Cocos Creator, activé dans cc.macro :

// Afficher le FPS en développement
cc.macro.SHOW_FPS = true;

Ou Stats.js, plus visuel. Le panneau « Performance » des outils développeur WeChat affiche aussi la courbe FPS en temps réel.

Indicateurs chiffrés :

• Haut de gamme : 55–60 FPS stable
• Bas de gamme : 28–32 FPS stable
• Variation de pic ≤ 20 %

Problèmes fréquents : trop de DrawCall, saccades au changement de scène complexe, explosion simultanée de particules. Sur un projet, la mort du boss déclenchait 200 particules — 15 FPS sur bas de gamme. Réduit à 50 particules + animation tween : meilleur rendu.

Astuce : un iPhone 7 en test réel pendant 10 minutes. FPS autour de 30 qui fluctue, OK ; chutes fréquentes sous 20, à investiguer.

2. Pic mémoire

Critère : iOS impose une limite stricte. Bas de gamme (iPhone 6s/7/8) : 1 Go ; haut de gamme (iPhone X/XR/11) : 1,4 Go. Pic ≤ 70 % de la limite appareil — ≤ 700 Mo bas de gamme, ≤ 1 Go haut de gamme.

Méthode :

• Outils développeur WeChat : panneau « Débogueur - Memory », courbe mémoire
• Débogage à distance Safari : iPhone branché au Mac, menu Développement Safari

// Afficher périodiquement l'utilisation mémoire
const memoryInfo = cc.sys.getMemoryInfo();
console.log('Mémoire actuelle: ' + memoryInfo.used + 'MB');

Indicateurs chiffrés :

• Pic bas de gamme ≤ 700 Mo
• Pic haut de gamme ≤ 1000 Mo
• Taux de crash ≤ 2 % (un projet est passé de 15 % à 2 % après optimisation)

Problèmes fréquents : double chargement de texture, ressources non libérées, atlas trop grand. La doc Cocos recommande des atlas ≤ 1024×1024 ; au-delà, risque de saturation mémoire sur bas de gamme.

Astuce : sur bas de gamme, entrer/sortir 20 fois de la même scène. Courbe qui monte sans redescendre = fuite.

3. Nombre de DrawCall

Critère : les DrawCall impactent directement le rendu. Plus il y en a par frame, plus le GPU est sollicité. Écran d’accueil ≤ 100 ; en jeu ≤ 200.

Méthode : panneau « Build & Publish » de Cocos Creator, option statistiques de rendu cochée pour voir les DrawCall à l’exécution.

// Afficher le nombre de DrawCall actuel
const stats = cc.game._renderStats;
console.log('DrawCall: ' + stats.drawCalls);

Indicateurs chiffrés :

• Écran d’accueil ≤ 100
• En jeu ≤ 200
• Pic ≤ 350 (scènes extrêmes, marge possible)

Problèmes fréquents : pas d’atlas, dynamic atlas désactivé, trop de BMFont. Un projet : 350 DrawCall avant optimisation ; atlas des petites images + BMFont remplacé par TTF → 120.

Astuces d’optimisation :

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

• Atlas statique : TexturePacker, moins de sprites éparpillés
• Atlas dynamique : activé par défaut dans Cocos Creator ; textures < 2048
• BMFont : préférer TTF ; chaque caractère BMFont = un DrawCall

4. Temps de chargement de l’écran d’accueil

Critère : au-delà de 3 secondes, le taux de churn augmente d’environ 7 % — chiffre sectoriel, pas une intuition. Les données de la plateforme cloud WeChat montrent que pour un paquet ~3,5 Mo, un chargement initial de 4500–9000 ms corrèle à une hausse nette du churn.

Méthode :

• Outils développeur WeChat : « Détails - Code local » pour la taille du paquet
• Plateforme cloud WeChat : simulation réseau réel, temps de chargement initial mesuré

// Enregistrer le temps de chargement initial
const startTime = Date.now();
cc.director.loadScene('game', () => {
  const loadTime = Date.now() - startTime;
  console.log('Temps écran d\'accueil: ' + loadTime + 'ms');
});

Indicateurs chiffrés :

• Rendu initial ≤ 3000 ms (idéal ≤ 1500 ms)
• Barre de progression visible ≥ 80 % (l’utilisateur patiente mieux)

Problèmes fréquents : trop de ressources dans la première scène, pas de sous-paquet, tout le dossier resources chargé d’un coup. J’avais 3 personnages, 2 fonds, une pile d’UI — 5 secondes. Une image de loading + sous-paquet → 2 secondes.

Astuces :

• Première scène : un fond + barre de progression
• Cocher sous-paquet pour la scène initiale
• Ressources non essentielles en chargement distant

II. Contrôle taille de paquet : la barre des 4 Mo est infranchissable

Limite stricte WeChat : paquet principal 4 Mo, paquet total (sous-paquets inclus) 16 Mo. Ligne rouge — dépassement = rejet sans négociation. Mon cas : 6,8 Mo, trois jours pour descendre à 3,2 Mo.

5. Taille du paquet principal

Critère : paquet principal ≤ 3,8 Mo. Pourquoi 200 Ko de marge ? Fichiers générés dynamiquement à la build, et légères variations de mesure côté WeChat.

Méthode : après build, « Détails - Code local » dans les outils développeur WeChat — statistiques précises.

Indicateurs chiffrés :

• Paquet principal ≤ 3,8 Mo (ligne de sécurité)
• Paquet principal ≤ 4,0 Mo (ligne rouge, à respecter)

Problèmes fréquents :

• Trop de ressources dans resources : tout ce dossier part dans le paquet principal
• Modules moteur non élagués : Cocos embarque tout par défaut
• Dépendances npm trop lourdes

Astuce : avant build, auditer resources, déplacer le non essentiel. Dans « Paramètres projet - Modules », décocher les modules inutilisés.

// Exemple de configuration d'élagage de modules (project.json)
{
  "modules": [
    "base",
    "2d",
    "ui",
    "audio"
  ],
  // Ne pas cocher les modules inutiles, par exemple :
  // "physics" - pas de moteur physique
  // "tween" - pas de système tween
}

6. Taille du paquet total

Critère : paquet total (principal + sous-paquets) ≤ 16 Mo. Les sous-paquets peuvent se charger à distance, mais la vitesse dépend du réseau — le cœur reste dans le principal et le sous-paquet du premier écran.

Méthode : les logs de build affichent la taille de chaque sous-paquet ; la somme = total.

Indicateurs chiffrés :

• Total ≤ 15 Mo (sécurité)
• Total ≤ 16 Mo (ligne rouge)

Stratégie de sous-paquets suggérée :

• Cœur (principal + premier écran) < 10 Mo
• Fonctionnalités secondaires : 20–50 Mo
• Scènes (chargement distant) : 30–100 Mo

Problème fréquent : sous-paquet du premier écran trop gros — un projet mettait tous les modèles de personnages dedans : 8 secondes d’attente au lancement.

7. Taux de compression des ressources

Critère : textures, audio et polices = les trois poids du paquet. Mesure : textures ~45 %, audio ~25 %, polices ~15 %. Bien les compresser peut diviser la taille par deux.

Méthode : comparer taille fichier source et taille après build.

Indicateurs chiffrés :

• PNG → JPG (sans transparence) : −50 à 70 %
• WAV → OGG : −65 à 70 %
• Sous-ensemble de police (fontmin) : −80 à 90 %

Outils recommandés :

• TinyPNG : compression PNG, glisser-déposer
• TexturePacker : atlas + compression
• Audacity : WAV → OGG
• fontmin : sous-ensemble de caractères utilisés uniquement

Problèmes fréquents :

• Fond en PNG sans transparence → JPG
• Audio en WAV → OGG
• Police complète 10 Mo+ → 100 Ko avec les glyphes du jeu

Astuce : TinyPNG sur une PNG — une image de fond 500 Ko peut passer à 150 Ko.

8. Configuration des sous-paquets

Critère : stratégie de chargement cohérente, sans pénaliser le démarrage. Première scène en sous-paquet obligatoire ; ressources non essentielles hors paquet principal.

Méthode : ordre de chargement et dépendances de la première scène.

Indicateurs chiffrés :

• Première scène en sous-paquet : oui
• Temps de chargement première scène : ≤ 3000 ms
• Ressources non essentielles hors principal : vérifier resources

Problèmes fréquents :

• Première scène référençant des ressources hors principal → téléchargement du sous-paquet avant d’entrer
• Sous-paquets mal découpés par métier
• Mauvais timing : télécharger les sous-paquets suivants dès l’écran de loading

// Exemple de chargement de sous-paquet
cc.assetManager.loadBundle('level-pack', (err, bundle) => {
  if (err) {
    console.error('Échec chargement sous-paquet', err);
    return;
  }
  bundle.loadScene('level-1', (err, scene) => {
    cc.director.runScene(scene);
  });
});

Astuce : tester en 4G. Si le sous-paquet du premier écran dépasse 5 secondes, revoir la stratégie.

III. Contrôle adaptation : ne pas planter sur un seul modèle

L’adaptation est souvent négligée. Tout va bien sur votre appareil de test, puis les retours arrivent : UI masquée, bandes noires, décalage au changement d’orientation. C’est systémique — un seul appareil ne suffit pas.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

9. Adaptation écran

Critère : résolution de conception, stratégie d’adaptation, bandes noires. Jeu portrait : 720×1280 (9:16) ou 750×1334 ; paysage : l’inverse.

Méthode : tests réels sur au moins 3 ratios :

• 16:9 (classique, majorité Android)
• 18:9 (récent, Xiaomi/Huawei)
• 19,5:9 (iPhone X, encoche)

Indicateurs chiffrés :

• Résolution : 720×1280 ou 750×1334
• Stratégie : portrait → hauteur fixe ; paysage → largeur fixe
• Bandes noires : aucune, ou réparties uniformément

Code clé :

// Portrait : adapter la hauteur
cc.view.setDesignResolutionSize(720, 1280, cc.ResolutionPolicy.FIXED_HEIGHT);

// Paysage : adapter la largeur
cc.view.setDesignResolutionSize(1280, 720, cc.ResolutionPolicy.FIXED_WIDTH);

// Zone visible réelle
const visibleSize = cc.view.getVisibleSize();
console.log('Zone visible: ' + visibleSize.width + 'x' + visibleSize.height);

Problèmes fréquents :

• Mauvaise stratégie : portrait avec largeur fixe → bandes haut/bas
• Widget mal configuré : nœuds ne suivent pas les bords
• Résolution trop large : contenu tronqué sur certains modèles

Astuce : Widget pour fixer l’UI clé aux bords — ex. pièces en haut à droite, quel que soit le ratio.

10. Encoche / écran goutte d’eau

Critère : zone sûre ; UI clé non masquée. Encoche iPhone X, goutte d’eau ou trou Android en haut.

Méthode : iPhone X/XR/11 ; Android encoche (Huawei Mate, Xiaomi haut de gamme).

Indicateurs chiffrés :

• UI clé ≥ 50 px du haut
• UI clé ≥ 50 px du bas (zone Home virtuelle)
• Détection zone sûre : API SafeArea

Astuces d’adaptation :

// Récupérer SafeArea iOS
const safeArea = cc.sys.getSafeArea();
const topPadding = safeArea.top;
const bottomPadding = safeArea.bottom;

// Adapter les nœuds
this.topNode.y = -topPadding;  // décalage vers le bas
this.bottomNode.y = bottomPadding;  // décalage vers le haut

Ou Widget avec marges dynamiques depuis la zone sûre.

Problèmes fréquents :

• Titre sous l’encoche
• Bouton bas sous la barre Home virtuelle
• Trou Android non testé : position variable selon la marque

Astuce : simulateur WeChat « iPhone X », puis un Android encoche en réel.

11. Compatibilité modèles

Critère : couvrir les modèles courants ; performance acceptable sur bas de gamme. La plateforme cloud évite d’acheter une flotte de téléphones.

Méthode :

• Plateforme cloud WeChat : gratuite, modèles courants mini-jeux
• Testin cloud : payant, couverture plus large

Modèles suggérés :

• iPhone 6s/7/8 : référence bas de gamme, plafond performance
• iPhone X/XR/11 : milieu/haut de gamme, encoche
• Huawei/Xiaomi/OPPO/vivo Android courants

Indicateurs chiffrés :

• FPS bas de gamme ≥ 30
• Mémoire bas de gamme ≤ 70 % limite appareil
• Taux de crash ≤ 2 %
• Taux d’installation réussie ≥ 99 %

Problèmes fréquents :

• Tests iPhone uniquement : Android hétérogène, bas de gamme parfois pire qu’iPhone 6s
• Vieux modèles ignorés : des utilisateurs ont encore un iPhone 7 en 2024
• WebGL non testé : versions basses, effets absents

Astuce : trois catégories — votre appareil dev (haut), iPhone 7 (iOS bas), Android milieu 2019.

12. Bascule portrait / paysage

Critère : schéma d’adaptation et fluidité. Jeux autorisan les deux (ex. puzzles) : UI se réorganise à la rotation.

Méthode : rotation réelle ; scénarios forcés portrait/paysage.

Indicateurs chiffrés :

• Durée bascule ≤ 500 ms
• Réorganisation UI sans décalage
• Rendu normal après bascule

Problèmes fréquents :

• Positions de nœuds incorrectes : Widget non mis à jour
• Écran noir : échec rechargement scène
• Saccades : scène trop lourde

// Écouter la rotation
cc.view.on('resize', () => {
  const isLandscape = cc.view.getFrameSize().width > cc.view.getFrameSize().height;
  this.updateUILayout(isLandscape);
});

// Logique de réorganisation UI
updateUILayout(isLandscape: boolean) {
  if (isLandscape) {
    // Layout paysage
    this.scoreLabel.x = -200;
    this.scoreLabel.y = 300;
  } else {
    // Layout portrait
    this.scoreLabel.x = 0;
    this.scoreLabel.y = 600;
  }
}

Astuce : si une seule orientation, verrouiller dans les paramètres projet pour éviter le chaos à la rotation.

IV. Contrôle validation : qualifications, confidentialité, contenu

La validation stress le plus. Les problèmes techniques, vous les testez ; les règles WeChat sont détaillées mais l’exécution a des subtilités. Depuis 2026, WeChat utilise une validation assistée par IA : mises à jour en 2–4 h ; première version : 1–2 jours ouvrés.

13. Complétude des qualifications

Critère : droits d’auteur logiciel, enregistrement ICP, licence de publication (achats intégrés). Manque d’un élément = rejet.

Méthode : checklist officielle ; nom et entité identiques partout.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Indicateurs chiffrés :

• Droits d’auteur logiciel : entité et nom = compte (caractère par caractère)
• ICP : validation obtenue (7–20 jours ouvrés)
• Licence de publication : obligatoire avec IAP ; dispensable monétisation publicitaire pure

Problèmes fréquents :

• Nom droits d’auteur avec un mot en plus : ex. certificat « 比邻消消乐 », jeu « 比邻消消乐小游戏 » → rejet
• Soumission avant validation ICP (7–20 jours)
• Licence sur entité A, compte jeu entité B

Astuce : certificat, capture ICP, licence côte à côte ; vérifier nom et entité caractère par caractère.

14. Politique de confidentialité et protection des mineurs

Critère : entrée politique de confidentialité, authentification réelle, système anti-addiction. Exigences renforcées en validation 2026.

Méthode : simuler un mineur ; vérifier la logique anti-addiction.

Indicateurs chiffrés :

• Politique : entrée visible accueil (popup ou bouton)
• Anti-addiction mineurs : ≤ 1 h/jour ; interdit 22h–8h
• Avertissement jeu sain : affiché à l’accueil

Problèmes fréquents :

• Pas de popup politique au lancement
• Pas d’authentification réelle ou anti-addiction non appliquée après auth
• Avertissement jeu sain absent

Astuce : identité mineure (< 18 ans) ; limites anti-addiction ; connexion après 22h → message d’interdiction.

15. Conformité du contenu

Critère : nom, publicité, lignes rouges contenu. Nom = qualifications ; pub ≤ impact sur fonctions clés ; pas de contenu interdit.

Méthode : auto-contrôle selon règles de validation ; nom, pub, éléments de contenu.

Indicateurs chiffrés :

• Nom : pas de termes interdits / marques ; aligné qualifications
• Part publicité : ≤ 50 % ; ne masque pas les fonctions clés
• Contenu : pas de violence, contenu adulte, jeu d’argent, sensibilité politique

Problèmes fréquents :

• Nom avec « 软件 » (logiciel) : ex. « XX软件小游戏 » → rejet
• Pub sur bouton « Démarrer »
• Partage incitatif : « partagez pour débloquer » → rejet
• Nom en anglais pur : ex. « CocosGame » → nom chinois requis

Top 5 des motifs de rejet :

1. Paquet trop lourd (principal > 4 Mo)
2. Nom ≠ droits d’auteur logiciel
3. Politique de confidentialité sans popup
4. Partage/abonnement incitatifs
5. Publicité masquant les fonctions clés

Astuce : parcourir ce top 5 — ~80 % des rejets. Les éviter suffit souvent pour passer du premier coup.

Tableau rapide : 15 points à cocher avant mise en ligne

À imprimer et cocher avant soumission :

Cochez chaque ligne ; soumettez quand les 15 sont OK. Un seul point manquant peut déclencher un rejet et des jours de correction.

Conclusion

Les contrôles pré-lancement ne sont pas optionnels : ils conditionnent directement le taux d’acceptation. Performance → churn ; paquet → rejet ; adaptation → plaintes ; non-conformité validation → une semaine perdue.

La valeur de cette checklist : seuils chiffrés (pas de devinettes), méthodes de test (pas au hasard), pièges fréquents (éviter ceux des autres).

Imprimez-la près de votre écran. Cochez avant chaque soumission. C’est un peu lourd — mais trois jours de rejet coûtent bien plus.

Première mise en ligne : le stress est normal. Avec cette checklist, vous contrôlez systématiquement. Bonne validation du premier coup et bon lancement.