Checklist des ressources pour le lancement d’app en 2026 : Tout ce que demandent les deux stores

Ignorer les spécifications des ressources au lancement—risque de rejet immédiat

Rien ne plombe une sortie comme une erreur de correspondance de ressources, ou la panique de dernière minute pour une feature graphic Play 1024x500 oubliée. L’approche "On corrigera après le lancement" est une perte de temps—préparez cela en amont et évitez les rejets sous 24h et les vérifications manuelles de métadonnées sur les deux stores. J’ai toujours cette checklist sous les yeux à chaque sprint de sortie ; toutes les exigences ci-dessous sont à jour pour 2026 (et oui, Apple a encore modifié les groupes de captures iPad en mai).

Checklist des ressources pour lancer une app en 2026

• Icône d’app (iOS, Android)
• Captures d’écran (familles d’appareils & specs)
• Feature Graphic (Google Play)
• Vidéo de preview d’app (optionnelle, les deux stores)
• Ressources promo (optionnel, Play Store)
• Limites des métadonnées & ce qui bloque vraiment les uploads

Icône d’app : votre passeport 1024x1024

Aucune tolérance pour une icône floue, mal centrée ou non carrée. Les deux stores demandent 1024x1024px—sans transparence—et Apple la redimensionne pour tous les appareils et emplacements publicitaires. Vous ne verrez pas d’erreurs graves sauf si vous uploadez autre chose que du PNG ou incluez de l’alpha, mais une icône trop chargée tue votre taux de conversion. Je dis toujours : regardez votre design à 60x60px. Si vous ne le reconnaissez pas de loin, recommencez.

• Specs (2026) : PNG 1024 x 1024 px, sans canal alpha, pas de coins arrondis (les stores arrondissent automatiquement), fichier <1MB.
• Docs des stores : directives App Store / référence Play Console
• Outil : Générez les icônes d’app à toutes les tailles requises

Captures d’écran : par appareil, par exigence, pas de raccourcis

C’est là que la plupart des lancements indés échouent : ne préparer que les écrans d’iPhone 14 Pro, ou uploader des captures iPad ne correspondant pas aux specs. Chaque groupe d’appareils demande son propre set. Ne soyez pas cette app avec des images étirées ou en letterbox dans la recherche—c’est une voie rapide vers une mauvaise première impression. Voici ce qu’il faut pour être "Prêt pour examen" et réussir l’upload sur les deux stores.

Specs captures App Store iOS (2026) :

• Familles d’appareils :
  • iPhone 6.7" (ex. iPhone 15 Pro Max, 1290x2796px)
  • iPhone 6.1" (ex. iPhone 15/15 Pro, 1170x2532px)
  • iPad Pro 12.9" (2048x2732px)—obligatoire pour support iPad en 2026. Plus de partage avec iPad 11" comme image groupe.
  • iPad Pro 11" (1668x2388px)—pour la fidélité, mais non requis pour publication.
• Nombre : 1-10 par taille d’appareil (minimum 1 par famille requise ; 10 recommandés pour meilleur taux de clic, 5 est le strict minimum en cas de rush).
• Format : JPG ou PNG, 72dpi, couleur RGB, <10MB par fichier. Ils rejettent les fichiers CMJN.
• Ratio : Doit correspondre exactement à la résolution de l’appareil, sans letterbox ni pillarbox.
• Outil : Générateur facile pour toutes tailles de captures iOS

Specs captures Google Play (2026) :

• Obligatoire : Minimum 2 par type (téléphone, tablette 7", tablette 10" dès que vous revendiquez le support tablette).
• Tailles recommandées :
  • Téléphone : 1080x2340px (16:9 et 19.5:9 passent, mais préférez du tall pour les téléphones récents)
  • Tablette 7" : 600x1024px ou 1200x1920px. L’examen Play préfère au moins une capture tablette full-res pour les apps signalant le support tablette.
  • Tablette 10" : 800x1280px ou 1600x2560px.
• Limites : Max 8 par type d’appareil. PNG ou JPG, 24-bit, <8MB/fichier.
• Astuce : La politique Play Console est très stricte sur les captures "non représentatives"—pas d’interfaces factices.
• Outil : Générez automatiquement toutes les tailles de captures Play Store

Feature Graphic (Google Play uniquement)

Toujours obligatoire en 2026. Visible dans la recherche et certains affichages web—les absentes ou hors specs tuent discrètement votre taux d’acquisition. Beaucoup d’apps zappent ça ou utilisent un crop de capture d’écran (paresseux). Faites en une image percutante et lisible en petit—pensez Spotify ou Calm, pas un mur de texte.

• Specs : 1024 x 500px, JPG ou PNG 24-bit (sans alpha), <1MB.
• Pièges : Ne mettez pas de logos essentiels sur les bords—Google recadre certaines surfaces.
• Outil : Conception et redimensionnement de feature graphic

Vidéo de preview d’app : optionnelle, mais pas vraiment

Techniquement, vous pouvez lancer sans vidéo. La plupart des développeurs indés la sautent la première fois, mais les données de conversion de mes lancements montrent qu’une preview à peu près correcte surpasse les captures seules—surtout sur Play, où la vignette vidéo domine votre fiche. Si vous ne faites qu’une, privilégiez Google Play (1 paysage, max 30 secondes).

• App Store : 15-30s, M4V/MP4, 1920x886px pour iPhone (horizontal) ou 886x1920px (vertical), max 3 par famille d’appareils. Pas de promo croisée ni pub—Apple détecte et rejette les overlays "download on Google Play".
• Play Store : Lien YouTube, recommandation 30s paysage (16:9), 720p mini. Strict sur les "images in-app", pas de promos filmées en face caméra.

Ressources promo : pas obligatoires, mais utiles

Neuf lancements indés sur dix que je vois ne prévoient pas d’images/stickers promo pour le Play Store—jusqu’à ce qu’une opportunité de mise en avant ou bannière arrive et vous force à bricoler un visuel 180x120px en 10 minutes. Pas obligatoire au lancement, mais si vous voulez jouer pour des features store, préparez ces six fichiers une fois et versionnez-les avec vos sources. (Liste la plus récente via Play Console.)

• Bannière TV : 1280x720px
• Capture Wear OS : 384x384px (si support montre connecté revendiqué)
• Image promo : 180x120px (rare en 2026 mais pas dépréciée—considérée pour certaines places en recherche)

Métadonnées : titres, descriptions, et où vous allez bloquer

L’upload des ressources échouera instantanément si résolution incorrecte. Les limites de métadonnées ne vous pileront qu’après collage d’une description travaillée, avec une erreur "longueur invalide" en pleine soumission. Pas de conseils vagues ici sur "optimiser vos mots-clés"—la limite entre "accepté" et "erreur" est la coupure stricte de caractères réellement appliquée par les stores.

• iOS :
  • Titre : 30 caractères
  • Sous-titre : 30 caractères
  • Texte promo : 170 caractères
  • Description : 4000 caractères
  • Mots-clés : 100 caractères (séparés par des virgules)
• Google Play :
  • Nom de l’app : 50 caractères
  • Description courte : 80 caractères
  • Description complète : 4000 caractères
  • Quoi de neuf : 500 caractères
• Piège : Play rejette les emojis ou caractères spéciaux dans le titre, et App Store refuse nettement la répétition du nom de l’app dans le sous-titre. Vérifiez avec un éditeur texte simple—les guillemets typographiques se glissent lors du copier-coller depuis Google Docs.

Tests et soumission : l’étape oubliée

Avant de lancer l’upload, testez en batch toutes vos ressources sur appareil (fonds mode clair/sombre, nouvelles encoches d’appareils, iPad en paysage pour split view si vous comptez les tablettes). Les stores ne prévisualisent pas comme vos vrais utilisateurs verront. J’utilise ScreenshotWhale pour une dernière vérification sur appareils et attraper les erreurs bêtes—c’est plus rapide que de réexporter chaque taille depuis Figma, et corrige la plupart des pièges ci-dessus.

Maintenir cette checklist à jour

Les specs changent, souvent juste avant une deadline ou autour de WWDC/Google I/O. Ajoutez aux favoris les docs que vous utilisez réellement, ne vous fiez pas à des threads Reddit hasardeux ou à des rumeurs Discord sur les tailles acceptées. Si Apple ou Google glissent une famille d’appareils ou modifient discrètement un nom (comme "Feature Graphic" devenant "Listing Banner" sur Play dans certains pays—ce cas est apparu en bêta l’automne dernier), vérifiez les exigences actuelles avant chaque lancement. Les cases cochées ici m’ont sauvé d’au moins quatre catastrophes le jour J—espérons qu’elles vous sauveront aussi.