Une équipe termine sa première version : l'app est branchée à une chaîne de test, les écrans sont dessinés, la soumission à l'App Store est prévue dans trois semaines. Reste à produire la vidéo de démo et les captures de la fiche. La base est vide, aucun utilisateur n'existe, et le portefeuille de test de l'un des développeurs affiche trois jetons sans valeur et un solde de zéro.
C'est le problème de tous les lancements, et il est plus délicat en crypto : un écran qui montre de l'argent doit montrer de l'argent fictif, sans exposer un vrai compte ni tromper personne. Voici une méthode pour la vidéo de démo et les captures de l'app crypto avant le premier utilisateur : le jeu de données, le storyboard, les règles d'Apple et de Google, les outils, et la limite que la maquette ne doit pas franchir.
Pourquoi une base vide ne vend rien
Un visiteur de fiche d'app décide en quelques secondes. Un écran vide, une liste sans élément ou un solde à zéro répondent « rien pour l'instant » à la seule question qui compte : à quoi ressemble l'app quand elle fonctionne ? Les captures et l'aperçu vidéo sont ce qui répond.
Ils posent trois contraintes à la fois. Ils doivent être réalistes (des écrans remplis), légitimes (aucune donnée d'une vraie personne) et fidèles (ils montrent ce que le build sait faire). Les deux premières se règlent avec un jeu de données fictif. La troisième vient des règles des stores, ci-dessous.
Trois usages, trois règles
Le même écran rempli de chiffres inventés ne sert pas la même chose selon l'endroit où il paraît. La question qui tranche est : à quoi sert-il ?
| Usage | Ce qu'on montre | Maquette acceptable ? | Règle à retenir |
|---|---|---|---|
| Fiche App Store ou Google Play | Votre app en cours d'utilisation | Non : captures de votre build | Fidélité à l'app (Apple 2.3, 2.3.3 ; Google : expérience réelle) |
| Vidéo d'aperçu du store | Capture vidéo de votre app | Non | Apple 2.3.4 : captures vidéo de l'app uniquement |
| Diaporama investisseurs, page d'attente, dossier de concours | Le produit tel que vous le concevez | Oui, étiquetée | « Interface illustrative, données fictives », jamais présentée comme traction |
| Test d'usage, tutoriel, cours | Un parcours typique | Oui | Données fictives cohérentes |
| Vidéo de lancement sur les réseaux | L'app, ou un concept signalé comme tel | Selon le plan | Mention « concept » ou « maquette » à l'écran |
Ce qu'Apple et Google exigent pour la fiche
Apple : montrer l'app, avec des comptes fictifs
Les règles de l'App Review (version du 16 octobre 2026) disent trois choses utiles ici :
- 2.3 : les métadonnées, y compris captures et aperçus, doivent refléter fidèlement l'expérience principale de l'app et rester à jour à chaque version.
- 2.3.3 : les captures doivent montrer l'app en cours d'utilisation, pas seulement l'illustration du titre, la page de connexion ou l'écran de démarrage. Des incrustations de texte et d'image sont admises.
- 2.3.4 : les aperçus « ne peuvent utiliser que des captures vidéo de l'app elle-même ». Narration, incrustations vidéo et texte sont permis pour expliquer ce qui n'est pas clair.
- 2.3.9 : vous êtes responsable des droits sur tous les éléments de vos icônes, captures et aperçus, et vous devez afficher des informations de compte fictives et non les données d'une vraie personne.
Un mot sur le secteur : la règle 3.1.5 réserve les apps qui facilitent le stockage de monnaies virtuelles aux développeurs inscrits comme organisation. Ce n'est pas une règle de capture, mais vos captures laissent voir la catégorie : mieux vaut en tenir compte avant la soumission.
Pour les tailles et formats (jusqu'à 10 captures par taille d'écran, en JPEG ou PNG, sans canal alpha), reportez-vous à notre guide des tailles de captures App Store.
Google Play : l'expérience réelle, et une seule vidéo
La Play Console demande des captures qui montrent « l'expérience réelle » de l'app, avec des images capturées dans l'app, en évitant les mains qui tapotent l'écran. Les slogans doivent rester brefs, et la fiche ne doit contenir ni mention de classement ou de récompense, ni témoignage, ni prix ou promotion. Vous pouvez ajouter jusqu'à huit captures par type d'appareil, et une seule vidéo d'aperçu, fournie sous forme d'adresse YouTube. Les règles de métadonnées de Google interdisent plus généralement les captures et images trompeuses.
Les spécifications de l'aperçu vidéo d'Apple
| Critère | Valeur |
|---|---|
| Durée | 15 à 30 secondes |
| Nombre | Jusqu'à 3 par taille d'appareil et par langue |
| Taille maximale | 500 Mo |
| Formats | H.264 (.mov, .m4v, .mp4) ou ProRes 422 HQ (.mov) |
| Débit cible H.264 | 10 à 12 Mbit/s, 30 images par seconde au maximum |
| iPhone grand écran | 886 × 1920 pixels (portrait) ou 1920 × 886 (paysage) |
| Image d'affiche | Choisie par vous ; par défaut à 5 secondes |
La résolution d'envoi n'est pas celle de l'écran : un iPhone 17 Pro Max capture en 1320 × 2868, mais l'aperçu se livre en 886 × 1920. Enregistrez proprement, puis exportez à la taille acceptée.
Écrire le jeu de données fictif, avant tout le reste
Un « jeu de données fictif » est la petite série de valeurs inventées dont chaque écran tire ses noms, montants et dates. Rédigez-le sur une page, et traitez-la comme la référence unique : tout chiffre qui paraît sur deux écrans vient de cette page.
| Élément | Règle | Pourquoi |
|---|---|---|
| Noms | Plausibles, ni célèbres ni d'un vrai client | Un vrai nom dans une fiche est un risque inutile (Apple 2.3.9) |
| Montants | Irréguliers, jamais ronds | Un solde de 10 000,00 $ ressemble à un texte de remplissage |
| Totaux | L'arithmétique doit tomber juste | Un total qui ne correspond pas aux lignes se remarque |
| Prix des jetons | Fixes pour tout le jeu, ou marqués « cours fictifs » | Un cours en direct fait bouger le total d'une prise à l'autre |
| Dates | Relatives à une « date du jour » unique | Les dates absolues vieillissent |
| Adresses | Inventées, au format valide, jamais celles d'un vrai portefeuille | Une vraie adresse expose son propriétaire |
| Rendements | Aucun chiffre qui ressemble à une promesse | Google interdit mentions de prix et de promotion dans les captures |
Voici un exemple de portefeuille fictif avec des cours inventés et figés. Les calculs sont exacts, et rien n'y correspond à un cours réel.
| Jeton | Quantité | Cours fictif | Valeur |
|---|---|---|---|
| BTC | 0,0420 | 68 450,00 $ | 2 874,90 $ |
| ETH | 1,350 | 2 480,00 $ | 3 348,00 $ |
| SOL | 14,2 | 148,50 $ | 2 108,70 $ |
| Total | 8 331,60 $ |
Gardez cette table sous les yeux au moment de chaque capture : les lignes de la liste, le total de l'en-tête et le montant d'une transaction affichée doivent s'accorder. C'est ce qui sépare un écran qui paraît vrai d'un écran qui paraît rempli à la hâte. Si vous affichez des cours réels, ils bougent à chaque prise : fixez-les, ou enregistrez la vidéo d'un seul trait.
Le storyboard d'une vidéo d'aperçu de 30 secondes
Une vidéo d'aperçu se regarde le plus souvent sans le son, dans une liste, par quelqu'un qui n'a pas encore décidé de s'y intéresser. Trente secondes suffisent pour une chose : montrer ce que l'app fait. Voici un plan type, pour une app fictive de suivi de portefeuille. Le nom de l'app et ses données sont inventés pour l'exemple.
| Temps | Plan | Texte à l'écran |
|---|---|---|
| 0 à 4 s | Écran d'accueil avec le portefeuille rempli (le jeu de données ci-dessus) | « Votre portefeuille, en un coup d'œil » |
| 4 à 12 s | Ouverture d'un jeton, courbe de prix, retour | « Suivez chaque jeton » |
| 12 à 20 s | Création d'une alerte de prix | « Une alerte, en deux gestes » |
| 20 à 27 s | Historique des opérations avec les dates relatives | « Retrouvez chaque opération » |
| 27 à 30 s | Retour à l'accueil, image d'affiche | « Disponible sur l'App Store » |
Quatre règles tirées des spécifications et du bon sens :
- Ne montrez que ce que le build sait faire. Une fonction promise « bientôt » dans l'aperçu est une publicité pour autre chose que l'app soumise.
- Évitez les titres qui occupent une image entière en ouverture : Apple décide de l'image d'affiche à 5 secondes par défaut, choisissez-la vous-même.
- Gardez le texte lisible sans le son. Narration et incrustations sont permises par la règle 2.3.4.
- Utilisez une seule date, une seule heure sur la barre d'état et un niveau de batterie identique d'un plan à l'autre.
Les outils, et quand les choisir
| Besoin | Outil | Points forts | Limites |
|---|---|---|---|
| Vidéo de l'app installée | Enregistrement d'écran de l'iPhone (Apple) ou d'Android (Google) | Fidèle à l'appareil, résolution native | Coupez les notifications, utilisez un compte de démonstration |
| App iOS en développement | Simulateur Xcode : xcrun simctl io booted recordVideo demo.mov et xcrun simctl io booted screenshot ecran.png | Reproductible, aucune donnée personnelle sur l'écran | Pas de vraie barre d'état d'appareil |
| Transactions réelles sans valeur | Réseau de test, par exemple Sepolia | Montre un vrai parcours et de vraies confirmations | Montants peu parlants ; jamais d'achat de jetons de test |
| Écran qui n'existe pas encore | Outil de design comme Figma | Contrôle total d'un écran figé | Le dessin s'écarte du build avec le temps |
| Illustration d'un portefeuille générique pour un diaporama | Simulateur en ligne comme My Larp Wallet | Écran animé aux cours réels, prêt en quelques minutes | Illustration seulement : ne remplace ni le build ni la capture du store |
My Larp Wallet est un lien d'intérêt d'Hyrulea (déclaré plus haut). Sa démo publique, sans compte, offre cinq jetons aux cours réels et 12 modifications conservées 7 jours dans le navigateur, avec une pastille « DEMO » et un filigrane qui restent à l'écran. La formule payante retire cette marque et s'ouvre au format de votre téléphone : l'étiquette « illustration » est alors à votre charge. Ses conditions interdisent de faire croire qu'on détient des actifs, d'obtenir un paiement, un investissement ou un prêt sur la base d'un écran fictif, ou de présenter l'image comme une preuve. Les deux guides de l'éditeur sur ce sujet (captures avant le lancement, limite des données fictives) sont en anglais.
Le piège du vrai portefeuille, même pour une démo
Il est tentant de filmer le portefeuille d'un fondateur, « juste pour la démo ». Sur une blockchain publique, une adresse montrée à l'écran donne accès au solde et à tout l'historique : le guide sur montrer une app crypto sans exposer son portefeuille en détaille les risques et compare testnet, chaîne locale, mode démo et maquette. Pour une vidéo publique, retenez une règle simple : aucune adresse de portefeuille réel dans une image, et un compte de démonstration pour tout le reste.
Où commence la tromperie
Inventer le contenu d'un écran est normal : toutes les fiches d'apps le font, puisque l'alternative est un écran vide ou les données d'un client. Ce qui est interdit, c'est ce qu'on affirme avec l'image.
- Illustration : un écran de produit, étiqueté. Légitime.
- Diapositive de traction avec de faux chiffres : un fait inventé, présenté comme réel pour convaincre un investisseur. C'est un problème de fraude, pas de capture d'écran. Cela peut constituer un dol qui permet d'annuler le contrat (Code civil), une pratique commerciale trompeuse si vous vendez (Code de la consommation), voire une escroquerie (article 313-1 du Code pénal).
- Solde fictif envoyé pour obtenir un paiement ou un prêt : le cas le plus clair, interdit aussi par les conditions des outils de maquette.
Le fichier est le même dans les trois cas : ce qui change, c'est ce qu'on en fait. Une étiquette (« illustration », « données fictives ») aide les lecteurs honnêtes et se coupe vite d'un recadrage : elle ne protège pas, la bonne conduite le fait. Pour les vidéos sur les réseaux, notre article sur la ligne entre sketch et escroquerie détaille les mentions à l'écran, et celui sur la chaîne crypto sans visage explique comment les appliquer sans exposer votre identité.
La méthode en sept étapes
Rédigez le jeu de données fictif
Une page : noms, montants irréguliers, totaux justes, dates relatives, cours fixes ou marqués fictifs.
Chargez-le dans l'app
Créez un compte de démonstration ou un script d'initialisation qui recharge toujours le même état.
Écrivez le storyboard
Cinq à six plans pour 30 secondes, un message par plan, lisible sans le son.
Capturez avec votre vrai build
Simulateur ou appareil, barre d'état propre (même heure, même batterie), notifications coupées.
Exportez à la taille exacte
Captures sans canal alpha à la taille de la classe d'écran, vidéo à la résolution acceptée par le store.
Relisez l'ensemble comme une suite
Même identité, mêmes totaux, même thème d'un écran à l'autre : les visiteurs les parcourent d'un trait.
Étiquetez ce qui sort du store
Pour le diaporama ou les réseaux, une mention « illustration » ou « maquette » à l'écran.
Avant de soumettre ou de publier
- Chaque capture et chaque plan de l'aperçu montre ce que le build sait faire
- Aucune donnée, aucun nom, aucune adresse d'une vraie personne dans une image
- Les totaux correspondent aux lignes, d'un écran à l'autre
- Première capture : l'app en cours d'utilisation, pas un écran de connexion ni de démarrage
- Captures au format PNG ou JPEG, sans canal alpha, à la taille exacte
- Aperçu Apple de 15 à 30 secondes, 886 × 1920 pour un iPhone récent
- Aucune mention de classement, de prix ou de promesse de rendement dans les visuels
- Toute maquette hors store est étiquetée comme illustration
Ce que cette méthode ne règle pas
Elle ne garantit pas l'approbation de l'app : l'examen porte sur l'app entière, pas seulement sur ses images, et les règles d'Apple et de Google évoluent, donc relisez-les le jour de la soumission. Elle ne remplace pas non plus de vraies métriques quand un investisseur en demande : des utilisateurs, des transactions et des revenus se prouvent par des relevés, jamais par un écran. Et si votre app détient des fonds de clients, la question réglementaire se pose avant celle des captures : voyez notre point sur la fin du statut PSAN et MiCA.
