Apple interdit-il les apps créées avec l'IA ?

Non. Les App Review Guidelines ne contiennent aucune règle visant les apps générées par IA. Une app créée avec Lovable, Bolt ou Rork est examinée avec les mêmes règles qu'une app codée à la main.

Pourquoi Apple a-t-il bloqué Replit, Vibecode ou Anything en 2026 ?

Ces blocages visaient les apps qui servent elles-mêmes à générer et exécuter d'autres apps, au nom de la règle 2.5.2 sur le code téléchargé. Ils ne concernent pas les apps que vous créez avec ces outils.

Que faire après un refus ?

Lisez le motif et le numéro de règle cités par Apple, corrigez, puis soumettez à nouveau en expliquant la correction dans les notes de revue. Si vous pensez que le refus est une erreur, vous pouvez faire appel auprès de l'App Review Board. Pour les apps GoodBarber, le service GoodBarber Takes Care gère ces corrections et la nouvelle soumission à votre place.

Pourquoi Apple refuse les apps créées par IA

Apple ne refuse pas une app parce qu’elle a été créée avec l’IA : aucune de ses règles ne vise ce cas. Il refuse les apps qui paraissent inachevées, qui ne sont qu’un site emballé, qui ressemblent trop à d’autres, ou qui partagent des données sans le dire. Or ce sont précisément les défauts les plus fréquents d’une app générée en une soirée.

Ce que disent les chiffres

En 2025, Apple a examiné 9,1 millions de soumissions et en a refusé 2,09 millions. Une soumission peut être refusée pour plusieurs motifs ; par grande section des règles, cela donne :

Section des règles	Refus en 2025
Performance (section 2 : app complète, métadonnées exactes…)	1 354 418
Legal (section 5 : confidentialité, données…)	495 673
Design (section 4 : fonctionnalité minimale, spam…)	415 532
Business (section 3 : paiements…)	283 820
Safety (section 1 : contenus…)	151 159

En mai 2026, Apple a lui-même relié la hausse des soumissions aux outils de développement par IA. En juin 2026, il a précisé sa règle sur le spam (4.3) et ajouté des exemples ; la presse spécialisée y a vu une réponse aux apps produites en masse.

Les règles qui piègent le plus souvent les apps générées

Règle	Ce qu’Apple refuse	Le piège typique d’une app générée
2.1 App complète	Une app qui plante, des liens morts, du contenu provisoire	Des textes de remplissage, des écrans vides, un bouton qui ne mène nulle part
2.3 Métadonnées exactes	Une fiche store qui ne reflète pas l’app réelle	Une description ou des captures générées qui promettent plus que l’app ne fait
2.5.2 App autonome	Une app qui télécharge du code qui ajoute ou modifie des fonctions	Une app qui télécharge et exécute du code (scripts, modules) pour ajouter des fonctions après la validation
2.5.19 Pas de fonctions cachées (ajoutée le 16 octobre 2026, elle précise une interdiction ancienne)	Des fonctions dormantes ou non documentées	Des écrans ou des options générés, oubliés dans le code
4.2 Fonctionnalité minimale	Une app qui n’est qu’un site web reconditionné	Une app web emballée sans rien d’« app » : pas de notifications, pas d’usage hors ligne, pas de fonction propre au téléphone
4.2.6 Services de génération d’apps	Les apps issues d’un service commercial de génération, sauf si le propriétaire du contenu les soumet lui-même	Publier sous le compte d’un prestataire plutôt que sous le vôtre
4.3 Spam (précisée le 8 juin 2026)	Plusieurs identifiants pour une même app, ou une app impossible à distinguer de ce qui existe	Une app de minuteur, de fonds d’écran ou de suivi qui ressemble à des milliers d’autres
5.1.1(v) Suppression de compte	Une app qui permet de créer un compte mais pas de le supprimer depuis l’app	La création de compte générée, la suppression oubliée
5.1.2(i) Partage de données	Partager des données personnelles avec un tiers, y compris une IA tierce, sans le dire et sans accord	Une fonction « IA » qui envoie les saisies de l’utilisateur à un modèle externe sans le signaler

Pierre-Laurent Medori, responsable de l’ingénierie backend de GoodBarber, ajoute un constat de terrain (en anglais) sur la règle 4.2 : d’après l’équipe de publication de GoodBarber, les examinateurs d’Apple testent régulièrement les apps hors ligne. Une app web emballée qui affiche un écran blanc se trahit aussitôt.

Depuis mai 2024, Apple exige aussi un manifeste de confidentialité : un fichier qui déclare les données collectées et justifie l’usage de certaines interfaces du système. Les bibliothèques courantes (Capacitor, Flutter, le moteur de React Native) doivent en fournir un.

La politique de confidentialité compte tout autant. Comme le souligne Pierre-Laurent Medori (en anglais), avant qu’Apple ne publie une app, un examinateur ouvre le lien de sa politique de confidentialité. Une page morte, ou une politique qui oublie l’outil de statistiques intégré à l’app, suffit à retarder une sortie.

Et les blocages de Replit, Vibecode ou Anything ?

Au printemps 2026, Apple a bloqué les mises à jour de Replit et de Vibecode, puis retiré l’app Anything de l’App Store, au nom de la règle 2.5.2. Ces mesures visaient les apps qui génèrent et exécutent d’autres apps à l’intérieur d’elles-mêmes, pas les apps que leurs utilisateurs créent puis publient séparément. Un porte-parole d’Apple a précisé à MacRumors que la règle ne visait pas spécifiquement les apps de vibe coding. Replit a publié une nouvelle mise à jour en mai 2026, après un accord avec Apple.

La liste à vérifier avant de soumettre

Dominique Siacci, CTO de GoodBarber, décrit deux familles de refus (en anglais) : les apps qui paraissent inachevées, et les déclarations qui ne correspondent pas à l’app. Sa méthode : transformer chaque leçon en vérification, faite avant que le store ne voie l’app. La liste ci-dessous couvre ces deux familles.

Aucun texte provisoire, aucun écran vide, aucun bouton sans destination
L’app fonctionne sur un vrai téléphone, sans planter, y compris sans réseau
L’app apporte quelque chose qu’un site ne fait pas : notifications, hors ligne, appareil photo, fonctions du téléphone
La description et les captures montrent exactement ce que fait l’app
Un compte de démonstration est fourni dans les notes de revue si l’app demande une connexion
La suppression du compte est possible depuis l’app
Les données envoyées à une IA ou à un autre tiers sont annoncées et acceptées par l’utilisateur
La politique de confidentialité est en ligne, et les déclarations de confidentialité couvrent les outils tiers
L’app est soumise sous votre propre compte développeur
Aucune fonction cachée ou désactivée ne reste dans l’app

Ce que montrent nos propres chiffres

Chez GoodBarber, l’équipe de publication (service GoodBarber Takes Care) mesure qu’environ 42 % des premières soumissions iOS sont refusées par Apple sur les 12 derniers mois (chiffres internes, avril 2026). Après correction, 91 % de ces apps sont finalement acceptées. Sur les mises à jour, le taux de refus tombe à 5 %. Ces chiffres ne se comparent pas directement à ceux d’Apple : ses 23 % de refus mêlent nouvelles apps et mises à jour, alors que nos 42 % ne portent que sur les premières soumissions. Ils montrent qu’un premier refus est fréquent, même pour des apps soignées.

Notre avis

Un refus d’Apple n’est pas une sanction contre l’IA : c’est presque toujours le signe que l’app n’est pas encore une vraie app. Le travail qui reste après la génération (finir les écrans, écrire une fiche juste, gérer les données) est précisément ce qui fait passer la validation. Si vous ne voulez pas le faire vous-même, choisissez un outil ou un prestataire qui prend en charge la soumission et les corrections : chez GoodBarber, c’est le rôle du service GoodBarber Takes Care.

Pourquoi Apple refuse les apps créées par IA, et comment passer la validation

Ce que disent les chiffres

Les règles qui piègent le plus souvent les apps générées

Et les blocages de Replit, Vibecode ou Anything ?

La liste à vérifier avant de soumettre

Ce que montrent nos propres chiffres

Notre avis

Questions fréquentes

À lire ensuite

Publier une app créée avec l'IA sur l'App Store et Google Play

Le vrai coût d'une app créée avec l'IA, du prompt aux stores (12 premiers mois)