Pourquoi les applications de paiement codées au feeling sont rejetées de l'App Store

Les applications de paiement codées au feeling (« vibe-coded ») sont rejetées de l'App Store à un taux plus élevé que presque tout autre type d'application dans la file d'attente d'examen, et les raisons n'ont généralement rien à voir avec la qualité du code. Une application codée au feeling — que vous avez construite en décrivant ce que vous vouliez à un assistant IA et en publiant ce qu'il a écrit — peut sembler identique à un travail professionnel. L'examen d'Apple ne note pas le code. Il vérifie qui a soumis l'application, quel mécanisme de paiement gère quel type de biens, si les autorisations matérielles ont été approuvées séparément et si l'examinateur peut effectuer une transaction réelle. Ce sont précisément les éléments qu'un assistant IA ne peut pas générer.

C'est le mur auquel tout le monde se heurte après avoir créé un point de vente personnalisé avec un modèle d'IA : le code est prêt en une après-midi, mais l'installer sur un iPhone en tant que véritable application de caisse est un processus de conformité, pas une tâche de codage.

Votre IA a-t-elle acheminé les paiements via le mauvais système ?

Le motif de rejet le plus fréquent est l'utilisation d'un mauvais mécanisme de paiement pour les biens vendus, et les assistants IA excellent particulièrement à se tromper sur ce point. Les Directives d'examen de l'App Store d'Apple tracent une ligne stricte. Les contenus et services numériques consommés au sein de l'application doivent utiliser le système d'achat intégré d'Apple conformément à la directive 3.1.1. Les biens physiques et les services du monde réel — un café, une coupe de cheveux, une commande expédiée — doivent faire l'inverse selon la directive 3.1.5(a) : ils ne doivent pas du tout utiliser les achats intégrés et nécessitent une méthode de paiement externe.

Un modèle de codage reproduit le schéma de paiement qui dominait ses données d'entraînement — du code d'achat intégré standard issu de tutoriels d'abonnement, ou un SDK de paiement web issu d'exemples d'e-commerce — sans jamais vous demander ce que vous vendez. Demandez-lui « une application qui accepte les paiements » et vous obtiendrez l'un des deux, choisi par les statistiques plutôt que par les règles d'Apple. Les règles varient également selon les pays : suite à la décision Epic de 2025, les applications sur l'App Store américain peuvent proposer des liens vers des options d'achat externes pour les biens numériques, mais cette exception ne s'applique qu'aux États-Unis. Une application distribuée dans le monde entier doit toujours respecter la règle la plus stricte partout ailleurs.

Êtes-vous seulement autorisé à soumettre une application de paiement ?

Apple exige que les applications gérant des flux financiers ou des services financiers soient soumises par l'institution qui réalise réellement ces services, avec les licences requises dans chaque région où l'application est disponible — c'est la directive 3.2.1. Un développeur indépendant publiant une application de paiement générée par IA n'est pas une institution financière agréée, et une agence qui en soumet une pour un client ne l'est pas non plus. Proposer l'application dans un pays où la licence de transfert de fonds n'existe pas mène au même rejet, avec un motif différent.

Les examinateurs d'Apple n'évaluent pas si votre programme de conformité est de qualité ; ils vérifient si l'entité appropriée a soumis l'application et la rejettent dans le cas contraire. Aucun prompt ne peut résoudre cela.

Pourquoi le Tap to Pay fait-il l'objet d'un processus d'approbation distinct ?

Accepter des cartes sans contact sur un iPhone nécessite l'autorisation « Tap to Pay on iPhone » — une demande distincte auprès d'Apple, indépendante de l'examen de l'application, accordée à une entité juridique plutôt qu'à une base de code. L'autorisation de développement est généralement validée en un jour ou deux. L'autorisation de publication passe par l'équipe des opérations d'Apple, prend généralement une à deux semaines et nécessite de collaborer avec un prestataire de services de paiement pris en charge. Un assistant IA écrira volontiers le code du Tap to Pay sans mentionner tout cela ; si vous soumettez l'application avant que l'autorisation ne soit accordée, elle sera rejetée.

L'acceptation de cartes physiques entraîne également des exigences qui ne dépendent pas d'Apple : matériel de lecture certifié, règles EMV et conformité PCI pour tout ce qui touche aux données de carte. Rien de tout cela ne ressort d'un modèle qui écrit du Swift.

L'examinateur peut-il réellement finaliser une transaction ?

La directive 2.1, Exhaustivité de l'application, bloque discrètement plus d'applications de paiement que les règles de paiement elles-mêmes. Les examinateurs doivent pouvoir tester l'application dans son intégralité, y compris le flux de paiement. Une application de paiement nécessite généralement un compte marchand, une vérification d'identité, et parfois un compte bancaire — des éléments auxquels un examinateur ne peut pas s'inscrire pendant l'évaluation. Les soumissions codées au feeling échouent constamment ici, car le créateur n'a souvent jamais configuré de véritable compte marchand lui-même ; l'application n'a été testée qu'avec des données fictives générées par l'IA. Sans un compte de démonstration fonctionnel et un moyen d'exécuter une transaction de test, l'application est rejetée comme incomplète, et chaque nouvelle soumission coûte un autre cycle d'examen.

Alors, qu'est-ce qui est réellement déployé ?

La partie difficile n'a jamais été le code. Un assistant IA peut produire une interface de caisse fonctionnelle en une après-midi, mais la distribution sur l'App Store est un parcours du combattant fait d'autorisations, de licences et de politiques d'examen qui échappent totalement à la portée d'un prompt. La démo fonctionne, mais l'infrastructure n'existe pas encore.

Pour un commerçant vendant des biens physiques, la conclusion pratique est plus simple : ne vous lancez pas dans cette file d'attente. Votre entreprise a besoin d'un système de caisse fonctionnel, pas de sa propre application sur l'App Store — les coûts de licence, de certification matérielle et de gestion des examens n'ont de sens que pour les entreprises dont le produit est le logiciel de paiement lui-même. Gérez votre comptoir sur une plateforme POS qui a déjà absorbé ces coûts (Final est conçu exactement de cette façon — les paiements passent par Final Pay avec du matériel de terminal certifié, sans application à publier vous-même), et consacrez l'argent des cycles d'examen à des éléments qui génèrent du chiffre d'affaires, comme un flux de caisse plus rapide et des frais de carte effectifs moins élevés.

Le processus d'examen d'Apple existe pour de bonnes raisons — les applications financières défaillantes nuisent aux gens. C'est simplement un processus que la plupart des commerçants n'ont jamais besoin de subir, peu importe qui ou quoi a écrit l'application.