Pourquoi une application d'annonces pour adultes ne passera jamais l'examen des stores, et ce qu'il faut construire à la place
Tôt ou tard, celui qui gère un annuaire d'annonces se pose la même question que tout fondateur d'un service mobile se pose dans les premiers mois : faut-il une application. Cela ressemble à l'étape suivante évidente. Une icône sur l'écran d'accueil, des notifications push pour un nouveau message ou une annonce vérifiée, quelque chose qui paraît plus sérieux qu'un site web. Quelqu'un dans l'équipe encapsule le site, le soumet, et quelques jours plus tard reçoit un refus qui n'a rien à voir avec un bug ou une mention de confidentialité manquante. Elle est refusée pour ce qu'est l'activité, pas pour quelque chose qui puisse être corrigé et resoumis.
C'est le point à comprendre avant d'y investir du temps de développement. Apple et Google ne décident pas application par application si votre annuaire en particulier est bien géré, bien modéré ou pleinement conforme à la loi de votre pays. Ils ont décidé il y a des années, par écrit, que cette catégorie d'activité n'a pas sa place sur leurs plateformes, point final. Ce qui suit, c'est ce que disent vraiment les règles, pourquoi il n'existe aucune configuration d'une place de marché propre, légale et avec vérification d'âge qui les contourne, et à quoi ressemble une présence mobile qui ne dépend pas d'un changement d'avis de l'une ou l'autre entreprise.
Ce que disent vraiment les règles
Les App Store Review Guidelines d'Apple traitent cela directement sous Objectionable Content, section 1.1.4. Le texte n'est pas vague : les applications ne peuvent pas contenir de "matériel ouvertement sexuel ou pornographique", et la règle précise que cela "inclut les applications de 'hookup' et les autres applications susceptibles de contenir de la pornographie ou d'être utilisées pour faciliter la prostitution, ou la traite et l'exploitation d'êtres humains". Remarquez ce que fait cette phrase. Elle n'interdit pas les images explicites, qu'un annuaire d'annonces n'a de toute façon pas besoin de montrer. Elle interdit les applications qui facilitent la prostitution en tant que fonction, quelle que soit la façon dont les annonces sont rédigées ou recadrées. Un annuaire de photos de profil élégantes et entièrement habillées avec un formulaire de réservation reste une application qui facilite ce que la règle nomme.
La politique de Google Play est, si possible, encore plus explicite pour nommer la catégorie. Sa règle sur le contenu sexuel indique que Google n'autorise pas les applications ou contenus d'application qui "font la promotion ou sollicitent un acte sexuel en échange d'une compensation", et la politique cite comme exemple précis les applications qui "font la promotion de divertissement à caractère sexuel, de services d'escorte, ou d'autres services pouvant être interprétés comme offrant ou sollicitant des actes sexuels en échange d'une compensation". Les services d'escorte sont nommés directement, pas sous-entendus. Google va plus loin et interdit séparément les "arrangements de rencontres rémunérées ou arrangements sexuels où l'on attend ou sous-entend qu'un participant fournisse de l'argent, des cadeaux ou un soutien financier à un autre participant", l'arrangement communément appelé sugar dating. Cette clause supplémentaire existe parce que des opérateurs ont tenté de décrire la même activité avec un langage plus doux, et Google a comblé cette brèche spécifiquement plutôt que de la laisser à l'interprétation.
Il vaut la peine de voir pourquoi les applications de rencontres ordinaires ne sont touchées par rien de tout cela. Tinder, Bumble et les applications similaires restent sur les deux stores parce que rien dans leur fonction annoncée n'implique de compensation pour un arrangement sexuel. C'est la ligne que tracent les deux plateformes, et c'est une ligne fonctionnelle, pas une ligne de ton. Une application de rencontres peut être aussi suggestive que son marketing le souhaite, et un annuaire d'annonces peut être aussi clinique et professionnel que ses fondateurs le souhaitent, le résultat ne change pas, parce que la question posée n'est pas "cela paraît-il respectable" mais "cela facilite-t-il des arrangements sexuels rémunérés". Un annuaire répond oui à cette question par construction, ce qui constitue le produit entier.
Pourquoi il n'existe aucun moyen habile de la contourner
Les nouveaux opérateurs ont tendance à essayer l'une de deux choses avant de l'accepter. La première consiste à décrire l'application en des termes vagues et neutres quant à la catégorie sur la fiche du store, en l'appelant application de "découverte sociale" ou de "compagnie premium" alors que la fonctionnalité réelle correspond toujours au schéma interdit dès qu'un examinateur l'ouvre. Cela ne fonctionne pas, car les équipes d'examen des deux stores ouvrent l'application, parcourent les parcours, et dans les catégories ambiguës créent généralement un compte de test et consultent les annonces comme le ferait un vrai utilisateur. Une description soignée ne change rien à ce que l'examinateur voit à l'écran trente secondes plus tard.
La seconde tentative est une scission : une application "propre" qui ne fait que parcourir des profils, associée à un paiement web ou un lien externe où la réservation ou le paiement a vraiment lieu, dans l'idée que garder la compensation hors de l'application évite la règle. Cela méprend ce que les deux politiques évaluent réellement. La règle d'Apple sur les applications à contenu généré par les utilisateurs est rédigée assez largement pour intercepter les applications qui existent principalement pour orienter les utilisateurs vers l'activité restreinte même si la transaction se conclut ailleurs, et les liens sortants sont suivis pendant l'examen précisément parce que ce schéma est courant dans de nombreuses catégories restreintes, pas seulement celle-ci. Une application qui existe pour parcourir un catalogue d'annonces de compagnie rémunérée est l'application examinée, pas l'étape de paiement à la fin.
Il existe un second coût à tenter l'un ou l'autre de ces contournements, qui pèse plus lourd qu'un simple refus. Un refus direct, où l'application est catégorisée honnêtement et relève simplement d'une règle de contenu, est traité par les deux plateformes exactement comme tel : un refus. Décrire une application d'une certaine manière dans ses métadonnées alors qu'elle fonctionne autrement une fois installée se lit différemment pour une équipe d'examen, plus proche d'une tentative de la tromper que d'une catégorisation erronée de bonne foi. L'accord développeur d'Apple lui donne une large latitude pour agir contre un compte en cas de soumissions malhonnêtes ou trompeuses, séparément et plus gravement qu'un refus de contenu ordinaire, et un schéma de resoumission d'une version déguisée de la même application refusée est le genre de schéma qui s'aggrave. Le risque réel n'est pas qu'une application refusée disparaisse. C'est qu'un compte développeur lié à une raison sociale, un compte bancaire et toutes les autres applications qui y sont enregistrées soit retiré d'un coup, pour une application qui de toute façon n'allait jamais être approuvée, quelle que soit la manière dont elle était décrite.
Rien de tout cela n'est un jugement sur l'activité sous-jacente, qui peut être entièrement légale, bien modérée et correctement vérifiée quant à l'âge dans sa propre juridiction, et échouer quand même à cet examen, parce que l'examen n'a rien à voir avec la légalité ou la qualité de la modération. C'est la politique produit d'une entreprise privée, et elle est rédigée pour exclure la catégorie en bloc, pas pour évaluer les opérateurs individuels qui s'y trouvent.
Ce qu'il faut construire à la place
L'alternative n'est pas un repli choisi faute de budget. C'est la seule présence mobile qu'un annuaire de cette catégorie peut réellement conserver sur la durée, parce qu'elle n'est pas louée à une entreprise qui a déjà déclaré, par écrit, qu'elle ne vous acceptera pas. Une application web mobile, construite avec un manifeste web et un service worker, peut être ajoutée à l'écran d'accueil d'un téléphone avec sa propre icône, s'ouvre en plein écran sans l'interface du navigateur, et se comporte comme une application installée du point de vue de l'utilisateur. Rien de tout cela ne passe par l'examen des stores d'Apple ou de Google, car elle n'est distribuée par aucun des deux. Les règles de contenu qui s'appliquent aux applications de leurs places de marché ne s'appliquent tout simplement pas à un site web, régi par des règles de navigation bien plus légères et générales sur les deux plateformes.
Les notifications push comblent l'essentiel de l'écart restant avec une application native. Le push web sur Android est mature et fonctionne comme une notification native. Sur iOS, les applications web sur l'écran d'accueil peuvent recevoir des notifications push depuis la version 16.4, qui couvre désormais pratiquement tout le parc actif d'iPhone. Un utilisateur qui ajoute l'annuaire à son écran d'accueil peut recevoir une notification pour un nouveau message, l'approbation d'une annonce ou une étape de vérification terminée, exactement comme il le ferait depuis une application téléchargée, sans qu'aucune des deux entreprises n'ait jamais à l'examiner, l'approuver ou pouvoir la retirer.
Cela élimine aussi une dépendance structurellement identique à un problème que les opérateurs affrontent déjà avec les fournisseurs d'infrastructure : une plateforme dont les conditions sont publiques, dont la réponse est déjà connue à l'avance, et qui peut mettre fin à la relation selon son propre calendrier, quel que soit le comportement de l'activité. Une fiche sur un store pour cette catégorie n'est pas un risque à combustion lente susceptible de se matérialiser après un examen des politiques. C'est un refus garanti, avec derrière une règle qu'on peut chercher et citer, ce qui en fait l'un des risques d'infrastructure les plus faciles à simplement éviter plutôt qu'à gérer.
Ce que les opérateurs doivent vraiment décider
La première décision n'est pas technique. C'est de savoir si une application allait un jour résoudre le problème qu'elle était censée résoudre. Les fondateurs veulent en général l'une de deux choses : un moyen de se sentir repérables comme le sont les applications grand public, ou un moyen d'envoyer des notifications push sans demander la permission à un navigateur. La recherche sur les stores n'est pas un canal de découverte réaliste pour cette catégorie, approbation ou non, puisqu'une fiche aussi spécifique serait retirée avant même de se positionner sur quoi que ce soit, si bien que l'argument de la visibilité ne tient même pas dans le meilleur des cas. Les stratégies de trafic organique et direct qui fonctionnent déjà pour un annuaire d'annonces ne sont pas affectées par l'existence ou non d'une application native, car aucune d'elles ne passe par la recherche sur les stores.
Il existe une catégorie plus restreinte qu'il vaut la peine de connaître, car elle est réellement différente d'une application de place de marché publique et reste parfois viable : un outil opérationnel destiné aux annonceurs vérifiés pour gérer leur propre annonce, leurs messages et leur compte, non exposé à la recherche publique et ne montrant pas lui-même un annuaire consultable de compagnie rémunérée aux utilisateurs du store. Cela se rapproche davantage d'un logiciel de gestion ordinaire, et bien que cela nécessite tout de même une lecture attentive des règles en vigueur avant tout envoi, la limite dépendant exactement de ce que montre l'application et à qui, cela n'est pas automatiquement intercepté par la même règle qui bloque une application d'annuaire destinée au public.
Pour tous les autres, la réponse est d'arrêter de traiter l'icône d'application manquante comme quelque chose dont il faudrait s'excuser ou qu'il faudrait finir par corriger. Construire à la place, correctement, l'expérience web mobile : un site rapide et installable avec un vrai manifeste, une invite à l'ajouter à l'écran d'accueil affichée à un moment pertinent plutôt qu'au chargement de la page, et des notifications push auxquelles l'utilisateur consent réellement. Ce n'est pas ici la solution de repli. C'est la seule stratégie mobile qui ne se termine pas par une lettre de refus et, si l'on insiste suffisamment, un avis de résiliation de compte pour une activité qui de toute façon n'allait jamais être admise.
