Apple rejette les applications vibe-coded. Le signal dépasse l'App Store.

Apple a discrètement commencé à rejeter et à retirer de l'App Store une catégorie précise de soumissions : les applications conçues avec des outils de vibe coding — ces services qui génèrent un produit fonctionnel à partir de quelques prompts, sans véritable code. Le Financial Times a documenté la tendance cette semaine, et celle-ci pèse plus lourd que n'importe quel rejet individuel.

Le cadrage n'est pas anti-IA. Apple invoque les mêmes directives de revue qu'elle utilise depuis des années : qualité minimale, fonctionnalité réelle, absence de tromperie sur ce que l'application fait vraiment. Ce qui a changé, c'est le volume de soumissions qui échouent à ces contrôles, et leur provenance.

L'App Store n'est pas la partie la plus intéressante de l'histoire. Ce qui l'est, c'est ce qu'elle révèle quand on livre un produit qui a été généré plutôt qu'ingénié, sur n'importe quelle plateforme dotée d'un examinateur à l'entrée.

Ce que l'App Review fait réellement

Les rejets se concentrent autour de quelques numéros de directives que tout développeur habitué connaît par cœur. La 4.2.1 vise les applications non fonctionnelles ou qui ne sont en réalité que des doublons. La 4.3 couvre le spam, y compris les applications qui copient un produit populaire avec des variations mineures. La 5.2 vise les applications qui trompent l'utilisateur sur ce que fait vraiment le logiciel. Aucune de ces règles n'est nouvelle. C'est le volume des soumissions qui s'y heurtent qui l'est.

Apple n'a pas publié de chiffres. D'après ce que le FT a reconstitué, l'App Review voit déferler des vagues de soumissions qui échouent visiblement aux mêmes contrôles, de la même manière : des interfaces qui paraissent soignées sur les captures d'écran mais s'effondrent au premier lancement, des fonctionnalités « IA » qui se résument à un appel modèle enrobé d'une UI, des fiches qui reprennent le nom et l'icône d'une application populaire avec un produit à moitié implémenté. Les examinateurs n'ont pas besoin de chercher loin.

Pourquoi les applications vibe-coded échouent à cet examen

Le vibe coding excelle sur les quatre-vingts premiers pour cent d'un produit. Écran de connexion, vue liste, page de paramètres, parcours d'onboarding — le modèle en a vu des milliers, et il en échafaude un en quelques minutes. Là où il déraille, c'est sur les vingt derniers pour cent : le travail que personne n'a envie de spécifier et que le modèle n'a aucune raison de proposer spontanément.

Ces vingt derniers pour cent, c'est exactement ce qu'un examinateur repère en premier. Le clavier qui masque le champ de saisie. L'appel réseau qui se fige sans timeout. L'état vide livré avec du texte de remplissage. L'autorisation que l'application demande sans en avoir réellement besoin, parce que le modèle l'a copiée depuis un template qui, lui, en avait besoin.

Quelques motifs récurrents dans les rejets :

• De fines surcouches d'un LLM sans fonctionnalité propre — l'appel IA est le produit, et il n'y a pas grand-chose autour.
• Des clones visuels d'applications populaires dont la logique sous-jacente est à moitié finie ou entièrement absente.
• Des fiches « IA X » — éditeur photo IA, agenda IA, to-do IA — où la partie IA se réduit à un appel d'API et où le reste est cassé.
• Des autorisations, des entitlements et des inclusions de SDK repris par mimétisme dont le développeur n'a pas réellement besoin, parce que le modèle les a glissés par template.

Aucun de ces modes d'échec n'est nouveau. L'App Review attrape les mêmes choses depuis quinze ans. Ce qui est nouveau, c'est le coût dérisoire de production, ce qui en fait arriver beaucoup plus d'un coup, ce qui durcit l'examen en compensation. La barre monte parce que le plancher est tombé.

La leçon, c'est le risque de plateforme

Apple est l'exemple le plus visible parce qu'Apple contrôle le seul canal de distribution sérieux pour le logiciel iPhone. La même dynamique existe partout où il y a un gardien — Play Store, Chrome Web Store, GPT Store, marketplace d'applications Shopify, partout où un produit a besoin de l'autorisation d'un tiers pour atteindre ses utilisateurs. Les règles changent rarement. Quand elles changent, elles changent pour tout le monde dans votre catégorie en même temps.

Pour quiconque livre du logiciel assisté par IA, l'implication pratique n'est pas d'arrêter d'utiliser ces outils. C'est de garder en tête que « je l'ai construit en un week-end » et « c'est un produit qui survit à un processus d'examen » sont deux affirmations distinctes, et de planifier la seconde dès le départ.

En pratique, cela signifie être précis sur ce que le produit fait pour l'utilisateur — « propulsé par l'IA » est un mot marketing, pas une proposition de valeur. Cela signifie investir dans les parties où les outils de vibe coding sont les plus faibles, qui sont aussi celles auxquelles les examinateurs prêtent le plus d'attention. Cela signifie lire les directives applicables avant la soumission, pas après réception de l'e-mail de rejet. Et cela signifie ne pas miser toute l'entreprise sur un seul canal de distribution, parce que ce canal finira tôt ou tard par modifier ses règles.

Le développement assisté par IA ne ralentit pas. La barre pour livrer quelque chose va continuer de baisser. La barre pour livrer quelque chose qui survit à un examen — et à un vrai utilisateur — va dans l'autre sens. Les deux peuvent être vraies simultanément. C'est l'écart qu'il vaut la peine d'anticiper.