J'ai soumis ma première app. Apple l'a refusée.

Le mail est arrivé le matin. Pas le bon.

La veille au soir, j'avais soumis Souffle — ma première app, trois mois de soirs et weekends. Le build 81, la version RC, celle qui allait enfin passer de TestFlight à l'App Store. J'avais rempli chaque champ d'App Store Connect avec soin, relu la description quatre fois, uploadé les screenshots dans trois formats. J'étais prêt.

Apple, apparemment, ne partageait pas cet avis.

Quatre motifs de refus. Pas un, quatre. Le genre de mail qui te fait reposer ta tasse de café et relire trois fois pour être sûr que tu ne rêves pas.

Le piège fiscal

Le premier motif — guideline 2.1b — disait que le reviewer n'avait pas trouvé mes achats in-app. Le Tip Jar, le petit bouton "offrir un café" que j'avais mis en place pour les gens qui voudraient soutenir le projet.

J'ai passé dix minutes à vérifier mon code. Tout était en place. Les IAP étaient configurés dans App Store Connect, le code StoreKit fonctionnait en sandbox. Qu'est-ce qui clochait ?

La réponse était dans un onglet que je n'avais jamais ouvert : Business. Le Paid Apps Agreement. Pour que les achats in-app fonctionnent — même en sandbox pour les reviewers — il faut que cet accord soit actif. Et pour qu'il soit actif, il faut remplir des formulaires fiscaux.

Des formulaires fiscaux américains. En France.

Un W-8BEN — le formulaire de l'IRS pour les étrangers. Nom, adresse, numéro fiscal français. Puis un U.S. Certificate of Foreign Status. Puis la DAC7, une directive européenne anti-évasion fiscale, nouvelle obligation depuis 2024. Trois formulaires, vingt minutes de bureaucratie inattendue.

Le truc vicieux : sans ces formulaires, Apple ne te dit rien. Pas d'erreur, pas de warning. Les IAP sont juste silencieusement désactivés en sandbox. Le reviewer lance l'app, ne voit pas le Tip Jar, et te colle un refus.

Vingt minutes de formulaires. Un refus qui aurait pu être évité.

Le disclaimer médical

Deuxième motif — guideline 1.4.1. Souffle est une app de respiration. Pour moi, c'est du bien-être, de la relaxation. Pour Apple, c'est du conseil médical sans disclaimer.

Et honnêtement, ils n'ont pas tort. L'app propose de la cohérence cardiaque, enregistre des sessions dans Apple Santé via HealthKit. Même si Souffle ne diagnostique rien et ne prescrit rien, le sujet est suffisamment proche du médical pour qu'Apple demande un garde-fou.

Le fix tenait en une phrase, ajoutée à la description : "Souffle n'est pas un dispositif médical. Consultez un professionnel de santé avant toute décision médicale."

Une ligne. Dix secondes à écrire. Mais encore fallait-il savoir qu'il la fallait.

Le compte organisation

Troisième motif — guideline 5.1.1(ix). Celui-là, je ne l'avais pas vu venir du tout.

Apple considère que les apps qui touchent à la santé — même au bien-être, même à la respiration — doivent être publiées par un compte Developer Organization, pas un compte individuel. Un compte organisation, c'est un SIRET, une structure juridique, un numéro DUNS.

Moi, j'ai un compte développeur individuel. Pas de micro-entreprise, pas de structure. Juste un développeur qui a codé un truc le soir pour aider son père à respirer.

J'ai contesté. Souffle ne donne aucun conseil médical personnalisé. Le disclaimer est en place. L'app n'a pas accès aux données de santé en écriture — elle log des sessions de pleine conscience, c'est tout. J'ai envoyé ma réponse à Apple en expliquant tout ça.

En attente de réponse. C'est le motif qui m'inquiète le plus, parce que si Apple insiste, il faudra créer une structure juridique avant de pouvoir publier. Pour une app gratuite de respiration.

Le background audio

Quatrième et dernier motif — guideline 2.5.4. L'app déclare le mode background audio dans UIBackgroundModes, mais le reviewer n'a pas entendu de son en arrière-plan.

Celui-là m'a fait sourire, parce que le code est correct. AVAudioSession est configuré en .playback, le son continue parfaitement quand tu verrouilles l'écran. Mais il faut lancer une session de respiration, activer une ambiance sonore, puis verrouiller — et ça, le reviewer ne l'a apparemment pas fait.

Le fix : pas de code à changer. Juste une réponse à Apple avec les étapes exactes pour reproduire le comportement. "Lancez l'app, démarrez une session, activez une ambiance, verrouillez l'écran, attendez — le son continue."

Leçon retenue : pour toute feature qui ne se déclenche pas depuis l'écran d'accueil, il faut mettre les étapes de reproduction dans les App Review Notes dès la première soumission. Les reviewers ne vont pas deviner.

Et maintenant

J'ai corrigé ce que je pouvais. Formulaires fiscaux remplis, Paid Apps Agreement actif, disclaimer médical ajouté, notes de reproduction détaillées pour le background audio. La contestation sur le compte organisation est partie.

Souffle est resoumise. J'attends.

Le premier réflexe après le refus, c'est la frustration. Quatre motifs. Aucun lié au code, à la qualité, à l'expérience utilisateur. Quatre problèmes administratifs, réglementaires, procéduraux. Le genre de trucs que tu ne trouves dans aucun tutoriel "Comment publier une app iOS".

Puis tu prends du recul. Et tu réalises que c'est exactement pour ça que le process existe. Apple vérifie que tu as fait les choses correctement — pas juste que ton code compile. C'est frustrant, mais c'est aussi ce qui fait que les utilisateurs font confiance à l'App Store.

Ce que j'aurais aimé savoir avant de cliquer sur "Soumettre" :

Va dans App Store Connect, onglet Business, avant toute chose. Vérifie que tous tes accords sont actifs et tes formulaires fiscaux validés. Ça prend vingt minutes et ça t'évite le motif de refus le plus bête.

Si ton app touche de près ou de loin à la santé, au bien-être, à la respiration, à la méditation — mets un disclaimer médical. Pas demain. Maintenant.

Renseigne-toi sur l'exigence du compte organisation pour les apps santé. Si tu n'as pas de structure juridique et que tu comptes en avoir besoin, commence les démarches tôt. Un SIRET ne se crée pas en un soir.

Et mets des notes de reproduction détaillées dans les App Review Notes. Tout ce qui ne se teste pas en deux taps depuis l'écran d'accueil, décris-le. Les reviewers n'ont ni le temps ni l'envie de deviner comment ta feature marche.

Le premier refus Apple, c'est un rite de passage. Ce n'est pas un mur — c'est un péage. Tu payes en patience, en formulaires et en humilité, et tu passes.

J'attends le mail. Je vous tiens au courant.

— Pato