Accusé de fraude pour une mise à jour jamais publiée : ce qu'Apple est en train de sacrifier

Le 28 octobre, un développeur qui poste sur X sous le nom de Stacy a publié la capture d'un message d'App Store Connect intitulé Pending Termination Notice. Les apps de ce compte ont généré 114 000 $. Le lendemain matin, le post avait été vu environ 180 000 fois, et les réponses étaient pleines de développeurs qui allaient vérifier leurs propres vieux rejets.

L'histoire est courte. Il y a plus de six mois, une mise à jour d'une app existante ajoutait une bibliothèque. App Review l'a rejetée plus de huit fois, et presque jamais à cause de la bibliothèque. Les reproches portaient sur des mots-clés en ligne depuis plus d'un an, sur un sous-titre dans une des localisations, sur les captures d'écran, et à la fin sur le nom de l'app, celui que la plupart de ses utilisateurs tapent pour la trouver.

Stacy a demandé un appel. L'examinateur, décrit dans le post comme vraiment excellent, a dit que le nom était le dernier problème restant. L'app a été renommée et soumise de nouveau. Trois jours plus tard, un rejet générique est arrivé, qui citait encore le sous-titre et les captures. À ce moment-là, Stacy a décidé que la mise à jour n'était pas nécessaire et l'a abandonnée.

Des mois après, dans ce même fil, Apple a écrit que le compte avait été signalé pour suppression à cause d'« activités malhonnêtes ou frauduleuses ». L'app a disparu du store. Un recours est en cours devant l'App Review Board.

Ce que l'avis reproche réellement

La capture donne le raisonnement en un paragraphe : « Les soumissions d'apps depuis votre compte ont enfreint à plusieurs reprises les App Review Guidelines dans le but de contourner le processus d'examen. Après plusieurs nouvelles soumissions, les violations des guidelines détaillées dans nos échanges précédents restent non résolues. » Les versements de revenus sont suspendus, les transferts d'apps sont désactivés, et la création d'un nouveau compte « peut entraîner la résiliation du nouveau compte ou des comptes associés ».

Lisez-le lentement. Rien dans ce texte ne parle d'une fonctionnalité cachée, d'un faux avis ou d'une arnaque. Ce qui est reproché, c'est un schéma : beaucoup de nouvelles soumissions, et une violation encore ouverte à la fin. Ce schéma colle à un développeur qui teste la revue pour y glisser quelque chose. Il colle tout autant à un développeur qui a essayé de satisfaire les examinateurs, puis a renoncé et a cessé de répondre à un fil qu'il considérait comme clos.

La règle derrière tout ça est la guideline 5.6, le Developer Code of Conduct : « Un comportement manipulateur ou trompeur répété, ou toute autre conduite frauduleuse, entraînera votre exclusion du programme Apple Developer. » La guideline 2.3.1 ajoute que « un comportement flagrant ou répété est un motif d'exclusion ». Dans les deux cas, le mot qui porte le poids est répété, et soumettre encore et encore est ce que fait un développeur consciencieux quand un examinateur trouve toujours quelque chose de nouveau.

Les réponses sont devenues une file d'attente

En une journée, le fil avait réuni des développeurs avec la même lettre. J'ai lu en entier chacun des posts ci-dessous. Chacun est le récit du développeur lui-même, et aucun ne vient avec la version d'Apple.

• @Tom4icecram fait des apps à plein temps depuis plus de dix ans, et son profil indique désormais « All Apps are currently down. » Son résumé : « Du jour au lendemain, une app qu'ils ont approuvée viole leur contrat. Ils vous accusent d'activité malhonnête ou frauduleuse. Tout votre compte tombe, avec des années de travail sans rapport. »
• @thebuildersince, développeur indépendant avec huit apps en ligne, avait vu l'une d'elles rejetée il y a presque un an à cause d'un mot dans son nom. L'app a été renommée, approuvée, puis mise à jour et approuvée de nouveau, et laissée tranquille pendant neuf mois. Cette semaine, la même formule « violé à plusieurs reprises » est arrivée. « Je n'aurais jamais imaginé qu'être rejeté, corriger, puis être approuvé reviendrait un an plus tard sous le nom de "fraude". » Le formulaire de recours, souligne le développeur, accepte 2 000 caractères.
• David Razmadze, développeur iOS depuis plus de six ans, dit que le compte a été résilié cette année « après six ans sur l'App Store ».
• Javi (@rameerez) a écrit en juillet 2025 que les tâches de notarisation d'une app macOS étaient bloquées depuis des jours, donc l'étape suivante a été un e-mail au support développeur, « et la chose suivante que je sais, c'est qu'ils ont RÉSILIÉ tout mon compte développeur ?! »

Stacy a publié une suite le lendemain matin avec les détails que tout le monde demandait. L'app a presque trois ans, son taux de remboursement est bas et elle est en ligne sur Google Play. La bibliothèque servait à l'attribution publicitaire, et aucun des rejets ne la concernait. La théorie de Stacy : « une vague de bannissements automatiques qui vérifient simplement si vous avez eu une série de rejets dans le passé. » Personne en dehors d'Apple ne peut le confirmer. Le cas de @thebuildersince colle à cette théorie de façon troublante, puisque là le rejet avait été corrigé et approuvé.

Certains signalements sont justifiés, et une histoire qui paraît nette dans un post peut changer d'allure quand l'autre partie s'exprime. En août, John Gruber a retiré un récit de rejet App Store, le premier en 24 ans de Daring Fireball, parce que le compte du développeur l'avait induit en erreur. J'ai ça en tête en lisant tout ce qui précède. Ce qu'aucun de ces développeurs ne décrit, c'est un avertissement précis avant l'avis.

Apple a un vrai problème de fraude

Rien de tout ça ne se passe dans le vide. En 2025, Apple a résilié 193 000 comptes développeur pour des soupçons de fraude et rejeté plus de 138 000 inscriptions. Elle a retiré près de 59 000 apps pour bait-and-switch, des apps approuvées comme un puzzle ou une calculatrice puis transformées après la revue en outils de fraude financière, et rejeté plus de 22 000 soumissions pour des fonctionnalités cachées ou non documentées.

Le 16 octobre, douze jours avant le post de Stacy, Apple a de nouveau durci les guidelines. Une nouvelle règle 2.5.19 interdit les fonctionnalités cachées, dormantes ou non documentées et cite l'obfuscation de code comme motif de résiliation. Pour les apps avec du contenu généré par les utilisateurs, elle ajoute que les développeurs qui « ne corrigent pas les violations identifiées après notification peuvent être considérés comme enfreignant le Developer Code of Conduct ». Je ne sais pas si quoi que ce soit de cela a pesé dans le dossier de Stacy. Cela décrit en revanche l'humeur dans laquelle App Review travaille cet automne.

Vue de l'intérieur de cette humeur, une app qui revient sans cesse avec le problème signalé toujours ouvert ressemble au premier coup d'un bait-and-switch. Je comprends pourquoi ce schéma est signalé. Ce que je ne peux pas défendre, c'est un signalement qui peut finir en verdict de fraude alors que le même fil contient un appel où un examinateur disait qu'il restait une seule chose à corriger.

La sanction frappe le plus fort ceux pour qui elle n'a pas été écrite

Une opération frauduleuse traite un compte développeur comme un consommable. C'est pour ça qu'il y en avait 193 000 à résilier en une seule année, et pourquoi l'avis consacre une phrase à décourager d'en ouvrir de nouveaux. Pour ces gens-là, être exclu du programme à vie, c'est une ligne dans une lettre et le prix d'une nouvelle identité.

Pour un développeur dont l'app a rapporté six chiffres et que ses utilisateurs trouvent par son nom, la même ligne met fin à l'activité sur les plateformes Apple. Chaque app du compte quitte le store, avec ses notes, son classement et les utilisateurs qui auraient reçu la version suivante. Celui qui n'a jamais pris de raccourci est celui qui a le plus à perdre d'une sanction conçue pour des gens qui n'ont rien à perdre.

Il n'y a pas non plus d'ailleurs sur iOS. Depuis iOS 17.4, les utilisateurs de l'UE peuvent installer des apps depuis des marketplaces alternatifs et depuis le site des développeurs, ce qu'on cite souvent comme la réponse au pouvoir de l'App Store. Ces apps doivent quand même être notarisées par Apple, et la description qu'Apple donne d'un marketplace est un service qui reçoit des apps notarisées « d'autres membres de l'Apple Developer Program ». Les guidelines disent que les apps en infraction sont « retirées de l'App Store et bloquées pour l'installation via une distribution alternative ». Un compte résilié n'a aucune route vers un iPhone, dans aucun pays.

Là où ces développeurs vont à la place

Alors ils vont vers Android et vers le web, et ils emportent leurs prochaines idées avec eux. L'app de Stacy est déjà sur Google Play, et d'après Stacy elle s'y porte bien. C'est la partie qu'Apple sous-estime, à mon avis.

Je suis développeur iOS depuis iPhone OS 2, le jour de l'ouverture de l'App Store en juillet 2008. Toutes les apps que j'ai publiées depuis sont sous un seul compte Apple, et après dix-huit ans j'ai toujours peur qu'un avis comme celui-ci tombe un matin dans ma boîte mail. Je n'ai jamais acheté un avis, caché une fonctionnalité ni livré une chose à l'examinateur et une autre aux utilisateurs. En lisant le fil de Stacy, je ne suis plus sûr que ça suffise.

Une de mes propres apps est déjà victime de cette peur. Sing It Like Britney: Karaoke avait une fonction centrale, le Chaos Mode, qui la distinguait des autres apps de karaoké à sa sortie. Un jour, une validation a conclu qu'il s'agissait d'une copie d'autres apps. Je ne le crois pas, mais je ne veux pas de ce signalement sur mon compte pendant que des avis comme celui de Stacy circulent. Je l'ai donc retirée moi-même de l'App Store, volontairement, pour que mon compte reste hors de portée d'un schéma comme celui de Stacy. Elle était réservée à iOS quand j'ai décidé de la retirer, et son développement passera prochainement à Android uniquement.

Je construis en natif et iPhone d'abord parce que pendant la plus grande partie de ces années, le marché était clair. Vous suivez les règles, vous êtes rejeté, vous corrigez ce que l'examinateur nomme, vous publiez. Un rejet pouvait être lent, mesquin ou carrément faux, et c'était quand même une conversation qui se terminait par une décision sur un build.

Ce qui use cette confiance, c'est l'incohérence bien plus que la sévérité. Des mots-clés approuvés pendant un an sont rejetés sur une mise à jour qui n'y touchait pas. Un examinateur au téléphone nomme le dernier problème et le suivant en liste trois autres. Une soumission que vous avez abandonnée revient des mois plus tard comme pièce à charge. Chacun de ces épisodes apprend au développeur qu'une approbation passée ne protège de rien, et qu'être persévérant et réactif peut se lire comme une tentative de contournement.

Ceux qui choisissent aujourd'hui où construire en premier tireront la conclusion évidente. Si une mise à jour en panne peut devenir un dossier de fraude, une petite équipe doit s'assurer que l'app iPhone ne soit jamais toute l'entreprise : Android dès la première version, une version web quand c'est pertinent, une liste d'utilisateurs qu'Apple ne détient pas. Chacune de ces mesures est une gestion du risque raisonnable. Chacune fait aussi d'iOS un canal parmi d'autres pour exactement les développeurs qui en faisaient autrefois le principal.

Google Play n'est pas un refuge. Ses pages d'aide disent qu'un compte résilié perd toutes ses apps, ses utilisateurs, ses statistiques et ses notes, que les comptes liés sont résiliés avec lui, et que les nouveaux comptes le seront aussi. Se répartir sur plusieurs stores ne rend aucun d'eux plus équitable. Cela rend une décision isolée survivable.

Si vous avez un vieux rejet dans App Store Connect

Personne en dehors d'Apple ne sait exactement ce qui fait passer un dossier de rejeté à signalé. Voici les habitudes que j'adopterais aujourd'hui, et aucune n'est une garantie.

1. Fermez les fils abandonnés par écrit. Si vous avez décidé de ne pas publier une version rejetée, répondez à App Review et dites que vous retirez la modification et que vous ne la soumettrez plus. L'avis parle de violations qui « restent non résolues », et un rejet auquel vous avez cessé de répondre ressemble exactement à ça vu de l'autre côté.
2. Gardez chaque message de rejet et chaque capture, y compris ceux que vous avez résolus. Le cas de @thebuildersince était corrigé et approuvé, et il est quand même revenu un an plus tard. Si vous devez un jour faire appel, la trace de ce que vous avez changé et quand est la preuve dont vous disposez.
3. Mettez chaque appel dans le fil. Après un appel téléphonique avec App Review, postez un court résumé écrit de ce qui a été convenu. L'examinateur suivant lit le fil, et un appel n'y laisse rien.
4. Ne soumettez de nouveau qu'avec un changement et une note. Chaque soumission doit corriger quelque chose de nommé dans le dernier rejet et le dire dans les Notes for Review. Plusieurs soumissions d'affilée avec les mêmes métadonnées ressemblent à un sondage de la revue, quelle que soit l'intention.
5. Utilisez la voie de la correction de bug quand elle s'applique. Les guidelines disent que, pour les apps déjà sur le store, « les corrections de bugs ne seront pas retardées pour des violations de guidelines, sauf celles liées à des questions légales ou de sécurité ». Vous la demandez dans App Store Connect et vous vous engagez à traiter le problème dans la soumission suivante.
6. N'ouvrez pas de nouveau compte après un avis. La lettre dit qu'il peut faire tomber le nouveau compte aussi. Faites appel à l'App Review Board, répondez exactement à ce que l'avis cite, et si la règle est la 5.6, suivez le chemin de retour que la guideline décrit elle-même : « une déclaration écrite détaillant les améliorations que vous prévoyez d'apporter ».
7. Gardez vos utilisateurs joignables en dehors du store. Une liste d'e-mails, un site web, une version Android. Avec ça, une résiliation est un mois terrible. Sans ça, c'est la fin de l'entreprise.

Si vous êtes aux prises avec un rejet en ce moment, j'ai écrit sur ce qu'Apple rejette au titre des règles 4.2 et 4.3 et sur ce que signifie vraiment un examen long, et il y a ici une page sur comment faire passer une app rejetée.

Ce qu'Apple est en train de sacrifier

App Review existe pour garder le store digne de confiance, et chaque développeur honnête y gagne quand ça marche. Un système incapable de distinguer un fraudeur de quelqu'un qui a renoncé à une mise à jour après huit tours dépense une autre sorte de confiance, celle que les développeurs placent en Apple, et il la dépense sur les gens dont la plateforme a le plus besoin. Ils répondent à chaque rejet, renomment leur app quand on le leur demande et prennent le téléphone. Ce sont aussi ceux qui ont une vraie activité qui pourrait déménager.

J'espère que l'App Review Board annulera vite celle-ci, et qu'Apple dira publiquement qu'abandonner une mise à jour rejetée n'est pas de la fraude. D'ici là, les conseils que je donne à mes clients incluront une version Android et une liste de diffusion, et ces conseils ne concernaient pas Apple auparavant.