Apple bloque les mises à jour de Replit et Vibecode sur l'App Store à cause de leurs fonctions de vibe coding

Apple a temporairement suspendu la publication des mises à jour de plusieurs applications liées au vibe coding, dont Replit et Vibecode. D'après la description disponible de la situation, les griefs portent sur certaines fonctions que l'entreprise juge incompatibles avec les règles de l'App Store.

Ce qui s'est passé

Ce sont les nouvelles versions des applications qui ont été bloquées, et non l'idée même du développement mobile assisté par IA. La distinction compte : Apple n'a pas déclaré la guerre à tout le segment, mais elle a montré qu'elle examine de près le fonctionnement interne de ces produits.

Pour les services qui promettent de générer, d'exécuter et d'améliorer du code presque sans intervention de l'utilisateur, iOS est depuis longtemps une plateforme difficile, en raison de règles strictes sur l'exécution de code et sur la modification du comportement d'une appli après sa validation.

Replit et Vibecode sont devenus des exemples visibles parce que les deux services vendent l'idée de développer « depuis son téléphone, à partir d'une description ». L'utilisateur formule une tâche en langage naturel, obtient une ébauche de projet, puis peut modifier l'interface, la logique et la structure des fichiers. Pour le grand public, c'est cela, le vibe coding : moins d'ingénierie manuelle, plus de dialogue avec un modèle et d'itérations rapides.

L'affaire compte aussi parce que, pour ces plateformes, les clients mobiles ne sont plus un simple complément du web : ils font partie du tunnel d'acquisition principal. Sur iPhone, il est plus facile de montrer la magie du produit : on ouvre l'appli, on décrit une idée, on obtient un prototype. Si ce scénario précis entre en conflit avec les règles du store, les entreprises doivent refondre non seulement l'interface, mais toute la logique d'onboarding, de monétisation et de rétention des utilisateurs.

Où naît le conflit

La formulation exacte des griefs d'Apple n'est pas dévoilée dans la publication, mais la logique du conflit est claire. L'App Store se méfie historiquement des scénarios où une appli devient une coquille pour un environnement d'exécution externe, ou peut changer radicalement de fonctions après avoir été examinée par l'équipe de validation. Quand un outil d'IA ne se contente pas d'écrire du texte, mais assemble une interface, exécute du code, connecte des services tiers et affiche le résultat dans le client mobile, il pénètre sur un terrain où les règles d'Apple sont particulièrement strictes.

Le problème tient probablement moins à la génération de code en soi qu'au degré d'autonomie. Un assistant de chat qui propose un extrait de composant React, c'est une chose. Un produit qui, à partir d'une seule instruction, assemble une appli fonctionnelle, permet de la lancer et modifie le comportement du service presque en temps réel, c'en est une autre. Pour l'App Store, ce n'est plus un simple éditeur, mais potentiellement une nouvelle plateforme dans la plateforme, et Apple cherche traditionnellement à garder ces scénarios sous son contrôle total.

Pour ces produits, la zone à haut risque ressemble généralement à ceci :

• génération et exécution de code utilisateur directement depuis le client mobile
• modifications à distance du comportement de l'appli sans validation séparée de chaque nouvelle fonction
• accès à des interpréteurs, des outils de build ou des conteneurs externes cachés à la modération
• scénarios où l'IA crée de véritables mini-applis dans une coquille déjà publiée

Et ensuite

Le scénario le plus probable : les développeurs retireront les fonctions litigieuses ou les sortiront de l'appli iOS. Ils pourraient par exemple laisser sur l'App Store un client pour les discussions, la consultation des projets et l'édition de base, et transférer la génération complète, le déploiement ou l'exécution vers la version web. C'est un compromis typique sur les plateformes d'Apple : l'appli mobile devient une vitrine et une télécommande, tandis que les fonctions les plus sensibles vivent dans le navigateur, où les restrictions de l'App Store ne s'appliquent pas.

Pour les utilisateurs, cela signifie moins une perte du service qu'un rythme ralenti. Les nouvelles fonctions pourraient sortir d'abord dans le navigateur, sur ordinateur ou via TestFlight, et n'arriver sur l'App Store que plus tard, sous une forme allégée. Pour les entreprises elles-mêmes, le risque est plus élevé : le marché du vibe coding croît précisément grâce à la promesse « crée une appli en quelques minutes », et toute restriction de plateforme brise cet effet de simplicité sur lequel repose le tunnel de croissance.

Les startups qui bâtissent leur produit autour de l'UX mobile et d'un effet « wow » rapide subissent un coup supplémentaire. Si les scénarios critiques ne peuvent pas être légalement intégrés dans une appli iOS, il faudra expliquer à l'utilisateur pourquoi la « vraie magie » ne commence qu'après le passage au navigateur. Cela accroît la friction, réduit la conversion et creuse l'écart entre l'apparence du produit dans une vidéo promotionnelle et son fonctionnement sur un appareil réel.

Ce que cela signifie

Apple a montré qu'elle est prête à brider même des produits d'IA populaires s'ils s'approchent trop près de scénarios interdits sur iOS. Pour le marché, c'est un signal : l'avenir du vibe coding dépend non seulement de la qualité des modèles, mais aussi du soin avec lequel les services intégreront la génération de code, son exécution et sa publication dans les règles des grandes plateformes mobiles.