Build in Public #7 : Sam Tennis est en ligne, les coulisses du lancement

TL;DR : Sam Tennis est officiellement disponible sur l'App Store ! 🎉 Mais le chemin entre "j'ai payé mes 99€ Apple Developer" et "l'app est en ligne" a été un parcours du combattant d'un mois. Configuration d'App Store Connect, 3 rejets Apple en 6 jours, bugs critiques en production, casse-tête des abonnements et chasse aux testeurs Android : je te dévoile tout, sans filtre.

---

Dans l'épisode précédent, je te présentais Sam, ce Golden Retriever coach de tennis propulsé par l'IA. L'application venait d'être validée sur l'App Store. Je pensais naïvement que le plus dur était fait.

Spoiler : Non.

Publier une application mobile en 2026, ce n'est pas juste uploader un fichier. C'est affronter deux gardiens du temple (Apple et Google), gérer une infrastructure de paiement complexe et prier pour que rien ne casse en production.

Voici le récit de ce dernier mois, transformé en guide de survie pour ceux qui voudraient se lancer.

---

1. La transparence des coûts : Combien ça coûte vraiment ?

On entend souvent qu'on peut lancer une startup pour 0€. C'est vrai pour le web, c'est faux pour le mobile. Voici ce que j'ai dû sortir de ma poche avant même de gagner le premier euro :

Total investissement initial : ~450€ (sans compter mon temps).

---

2. La préparation invisible : Ce qu'on ne te dit pas

J'ai reçu mon email de validation du programme Apple Developer le 10 décembre 2025. Ma première soumission à l'App Store ? Le 6 janvier 2026. Soit presque un mois de préparation.

Pourquoi autant de temps ? Parce qu'entre "j'ai payé mes 99€" et "je soumets mon app", il y a un monde de configuration.

Ce que j'ai dû faire dans App Store Connect

Une fois inscrit au programme Apple Developer, tu accèdes à App Store Connect — le centre de contrôle de ton app. Et là, surprise : il faut tout remplir avant de pouvoir soumettre quoi que ce soit.

Les éléments obligatoires :

• Informations de l'app : nom, sous-titre, catégorie, description courte et longue
• Screenshots : pour chaque taille d'écran (iPhone 6.7", 6.5", 5.5"... et iPad si tu le supportes)
• Politique de confidentialité : URL obligatoire vers tes CGU
• Questionnaire App Privacy : déclarer toutes les données collectées par ton app
• Informations de contact : pour que Apple puisse te joindre en cas de problème
• Notes de version : ce que fait ta première version

La configuration des abonnements (le piège)

C'est là que ça se complique. Pour une app freemium avec abonnements, tu dois :

1. Créer tes produits in-app dans App Store Connect (abonnement mensuel, annuel, etc.)
2. Configurer les groupes d'abonnements (pour les offres de mise à niveau)
3. Connecter RevenueCat (c'est le Stripe des applications mobile) à ton compte App Store Connect via des clés API
4. Créer des comptes Sandbox pour tester les achats
5. Rédiger les conditions d'abonnement qui s'afficheront aux utilisateurs

Tout cela m'a pris 2-3 semaines de configuration, tests et re-tests. Et je ne compte pas le développement du paywall côté code.

---

3. La forteresse Apple : Mes 3 refus

Début janvier, j'ai enfin cliqué sur "Soumettre pour vérification" via TestFlight. Tout semblait vert. J'étais confiant.

Il faut savoir qu'Apple teste vraiment ton application. Des humains (ou des bots très avancés) la manipulent. Résultat ? 3 refus en 6 jours.

Refus #1 : Le piège de l'iPad

Date : 6 janvier 2026
Motif : Guideline 2.1 - Performance: App Completeness

J'avais pourtant désactivé le support iPad dans la configuration de mon projet. Mais surprise : Apple teste quand même ton app iPhone sur iPad pour vérifier qu'elle s'affiche correctement en mode "zoom".

Le verdict : Mon app n'était pas responsive. L'interface était cassée sur grand écran (éléments qui débordent, texte illisible, boutons inaccessibles).

La solution : Optimiser pour iPad (responsive design, layouts adaptatifs) dès le début.

Refus #2 : L'enfer du Paywall (RevenueCat)

Date : 7 janvier 2026
Motif : Guideline 3.1.1 - In-App Purchase

C'est le point qui m'a fait le plus transpirer. Mon app utilise RevenueCat pour gérer les abonnements. Mais il y a un problème de l'œuf et de la poule :

1. Apple ne valide pas les abonnements que j'ai paramétré dans l'App Store Connect tant que l'app n'est pas validée.
2. L'app (et RevenueCat) ne peut pas afficher les produits si Apple ne les a pas validés.

Résultat : Les testeurs d'Apple arrivaient sur un écran d'abonnement vide ou buggé. Refus immédiat.

J'ai passé plusieurs jours à comprendre la subtilité de la configuration entre l'App Store Connect et RevenueCat. Le problème venait de la Sandbox qui n'était pas bien paramétrée. Une fois la sanbox en état de marche, les abonnements en cours de validation s'affichent pour l'équipe review d'Apple.

La solution :

• Synchroniser correctement RevenueCat avec App Store Connect
• Se documenter sur le mode Sandbox d'Apple.

Conseil : Assure-toi que tes produits sont en statut "Prêt à être soumis" et que ton code gère parfaitement les cas où l'API ne renvoie rien.

Refus #3 : La paperasse juridique

Date : 9 janvier 2026
Motif : Guideline 5.1.1 - Legal: Privacy

Il manquait un lien fonctionnel vers les engagements de respect des utilisateurs hébergés sur le site d'Apple. Apple exige que les liens vers tes CGU et la politique de confidentialité soient directement visibles sur l'écran où tu proposes l'abonnement. Pas dans un menu caché, pas dans les réglages : sur l'écran du paywall.

C'est bête, mais Apple ne rigole pas avec le juridique. C'est un détail que tu peux facilement rater si tu n'as jamais publié d'app avec des achats in-app.

La solution : J'ai ajouté les liens nécessaires en bas de l'écran d'abonnement :

• "Conditions d'utilisation"
• "Politique de confidentialité"

Au final : Le 12 janvier 2026, soit 6 jours après ma première soumission, j'ai reçu le fameux email "Your app has been approved". ✅

Mais ce n'était pas fini. La V2 pour corriger les premiers bugs a été validée le 15 janvier 2026, et je suis actuellement en version 1.0.3 (mise à jour le 20 janvier 2026).

---

4. Le Labyrinthe Android

Si Apple est un gardien sévère à l'entrée, Google est un gardien procédurier.

Sur le Play Store, le problème n'est pas la review du code, mais la confiance. Pour un nouveau compte développeur personnel (créé après novembre 2023), Google impose une règle stricte : tu dois avoir 12 testeurs actifs pendant 14 jours consécutifs avant de pouvoir demander la mise en production.

C'est là que le bât blesse. Je n'ai pas 12 téléphones Android sous la main.

De plus, la fragmentation d'Android (Samsung, Pixel, Huawei...) rend le développement plus complexe. J'ai eu des bugs d'affichage spécifiques à certains modèles que je n'avais jamais vus sur iPhone.

Mon appel à l'aide : Si tu joues au tennis et que tu es sur Android, j'ai besoin de toi ! En échange : 1 an d'accès Pro offert (valeur 49€).

---

5. Le bug du "Jour 1" et la leçon des mises à jour OTA

L'app est validée sur iOS. Champagne. 🥂

Quelques heures plus tard, des abonnés Make Time la téléchargent. Et là, c'est le coup de chaud.

Je reçois des messages : "L'app bug à la fin de l'onboarding."

Je suis à mon poste de salarié, je ne peux rien faire dans l'immédiat.

Le problème ? Un bug entre l'onboarding et l'arrivée sur l'écran d'accueil, que je pensais avoir corrigé sur ma version TestFlight.

L'OTA : un outil à double tranchant

Avec Expo, tu peux pousser des mises à jour "Over The Air" (OTA). C'est-à-dire mettre à jour le code JavaScript de l'app sans repasser par la validation Apple (qui prend 24h à 48h).

Sur le papier, c'est magique. En pratique, c'est dangereux.

J'ai utilisé l'OTA plusieurs fois au début. Et j'ai vite compris le piège : on pousse une "amélioration" qu'on croit être une amélioration... mais qui fait crasher l'app encore plus. Tu n'as pas testé suffisamment, et maintenant tous tes utilisateurs ont la version bugguée.

---

6. Le Business Model : En attendant le premier million

L'application est téléchargeable gratuitement (Freemium). Mais l'IA (Gemini) me coûte de l'argent à chaque question posée. J'ai donc mis en place un abonnement :

• Prix : 49,99€ / an (ou 5,99€ / mois).
• L'offre : 3 jours d'essai gratuit pour convaincre.
• La taxe : Apple et Google prélèvent 15% de commission (tant que je fais moins d'1 million de $ de CA, ce qui me laisse un peu de marge... 😉).

Le calcul est simple : il faut que la valeur perçue du coach (dispo 24/7) soit supérieure au prix d'une seule heure de cours particulier (environ 45€).

---

📊 Le Bilan : Temps et Argent

Leçon : Je pensais passer plus de temps pour valider l'application mais au final 3 refus c'est plutôt bon. Un développeur a été refusé 39 fois avant de voir son application validée. Donc je m'estime heureux. Par contre je ne pensais pas que même après la validation de l'app, il fallait prévoir de nombreux correctifs pour la rendre stable.

---

✅ Ma Checklist Anti-Refus

Si tu lances une app mobile, vérifie ces points avant de soumettre :

Technique

• [ ] Testé sur iPhone ET iPad (ou limité à iPhone uniquement)
• [ ] Testé sur plusieurs tailles d'écran (iPhone SE, Pro, Pro Max)
• [ ] Testé en mode sombre
• [ ] Achats in-app fonctionnels dans l'environnement sandbox
• [ ] Pas de crash au démarrage
• [ ] Test avec un compte complètement vierge (fresh install)

Légal

• [ ] Politique de confidentialité (URL accessible et fonctionnelle)
• [ ] Conditions d'utilisation (URL accessible et fonctionnelle)
• [ ] Liens visibles sur l'écran d'abonnement (pas cachés dans un menu)
• [ ] Pas de contenus interdits (santé, finances sans licence...)

Métadonnées

• [ ] Screenshots pour toutes les tailles requises (iPhone + iPad si applicable)
• [ ] Icône aux bonnes dimensions (1024x1024px)
• [ ] Description claire du contenu de l'app
• [ ] Catégorie adaptée

Spécifique Apple

• [ ] Pas de mention d'autres plateformes (Android, web) dans l'app
• [ ] Pas de prix affichés "en dur" (utiliser les prix dynamiques de l'App Store)
• [ ] Info.plist avec toutes les permissions justifiées
• [ ] Produits in-app en statut "Prêt à être soumis" dans App Store Connect

Spécifique Google

• [ ] 12 bêta-testeurs pendant 14 jours consécutifs
• [ ] Formulaire de déclaration de contenu rempli
• [ ] Conformité aux règles publicitaires si applicable

---

❓ Questions fréquentes (FAQ)

Combien de temps prend la validation App Store en 2026 ?

En moyenne, compte 24 à 48h par review. Mais avec les refus, j'ai mis 6 jours entre ma première soumission et la validation (3 refus du 6 au 12 janvier 2026). Prévois toujours 2 semaines de marge pour la phase de review.

Attention : Ce délai ne compte pas la préparation d'App Store Connect (descriptions, screenshots, configuration des abonnements...) qui m'a pris presque 1 semaine en plus.

Pourquoi mon app a été refusée pour les achats in-app ?

Apple refuse si tes produits ne sont pas en statut "Prêt à être soumis" dans App Store Connect, ou si ton code ne gère pas le cas où l'API ne renvoie rien. Utilise RevenueCat pour simplifier la gestion et teste toujours en mode Sandbox avec plusieurs comptes.

Combien coûte la publication d'une app mobile en 2026 ?

Compte minimum 450€ pour les outils obligatoires :

• 99€ Apple Developer Program (annuel)
• 25€ Google Play Console (unique)
• ~20€/mois Expo pour les builds
• Domaine pour la landing page et CGU
• Crédit IA Cursor

Sans compter ton temps de développement.

Comment éviter les refus Apple pour iPad ?

Optimiser l'UI pour iPad avec des layouts adaptatifs (plus long mais meilleur pour l'expérience utilisateur) Apple teste toujours ton app iPhone sur iPad en mode "zoom", même si tu ne supportes pas officiellement iPad.

Qu'est-ce qu'une mise à jour OTA et comment ça marche ?

Avec Expo, les mises à jour OTA (Over The Air) permettent de corriger du code JavaScript sans repasser par Apple (qui prend 24-48h).

Attention : L'OTA est à double tranchant. Tu peux pousser une "amélioration" qui casse l'app pour tous tes utilisateurs. Mon conseil : réserve l'OTA uniquement pour des corrections mineures bien testées (typos, petits ajustements UI). Pour tout le reste, passe par TestFlight puis soumission App Store.

Comment recruter 12 testeurs Android pour Google Play ?

Google exige 12 testeurs actifs pendant 14 jours consécutifs pour valider la qualité de ton app. Mes stratégies :

• Newsletter : Demander à tes abonnés (avec une contrepartie : accès Pro offert)
• Communautés : Poster sur Reddit, Discord, forums liés à ta niche
• Entourage : Famille, amis, collègues avec Android
• Formulaire de candidature : Créer une landing page dédiée pour faciliter les inscriptions

---

🎯 Récap : Les 3 leçons à retenir

Si tu lances une app mobile en 2026, voici ce que tu dois retenir de mon expérience :

1. Budget réaliste : 450€ minimum + 1 mois de marge

Ne te lance pas avec juste les 99€ d'Apple. Compte aussi Expo (~60€ pour 3 mois), RevenueCat (gratuit jusqu'à 2500$/mois de revenus), le domaine, et surtout 1 mois de matelas entre "j'ai payé mon compte Apple" et "mon app est en ligne". La préparation d'App Store Connect prend aussi du temps.

2. Teste avec un compte vierge avant chaque soumission

95% de mes bugs venaient de mon compte de test "pollué" qui avait déjà passé l'onboarding. Crée un compte de test 100% fresh (jamais utilisé) pour chaque review. Simule toujours la première expérience utilisateur.

3. Configure RevenueCat ET App Store Connect en parallèle

Le problème de l'œuf et de la poule (les produits qui ne s'affichent pas tant que l'app n'est pas validée) m'a coûté un refus. Avant de soumettre :

• Synchronise RevenueCat avec App Store Connect
• Vérifie que tes produits sont en statut "Prêt à être soumis"
• Teste en mode Sandbox avec plusieurs comptes de test Apple
• Ajoute un fallback dans ton code si l'API ne renvoie rien

---

Tu veux lancer une app mobile ? Tu es déjà en galère avec Apple/Google ? Envoie moi un email (guillaume@maketime.fr), je réponds à tout le monde. J'ai fait toutes les erreurs pour que tu ne les fasses pas. 😉

📱 Découvrir Sam Tennis sur l'App Store →

---

Cet article fait partie de la série Build in Public. Tu veux suivre l'aventure Sam Tennis en direct ? Abonne-toi à la newsletter.