Vibe-coding : ce que les équipes dev doivent savoir

Ce qui s'est passé

Jeudi dernier, Apple a retiré une application appelée Anything de l'App Store. Anything permettait à ses utilisateurs de créer et de prévisualiser des apps mobiles sur leur iPhone à partir de commandes en langage naturel, sans aucune compétence en programmation. L'app avait levé 11 millions de dollars pour une valorisation de 100 millions, et ses utilisateurs auraient publié des milliers d'applications via la plateforme.

La raison du retrait ? La règle 2.5.2, la même qu'Apple utilise depuis le début du mois pour sévir contre cette catégorie d'apps. Cette règle stipule que les applications doivent être « autonomes » et ne peuvent pas « télécharger, installer ou exécuter du code qui introduit ou modifie des fonctionnalités de l'application ». Début mars, Apple avait déjà bloqué les mises à jour de deux autres plateformes de vibe-coding, Replit et Vibecode, en invoquant la même règle.

Ce qui rend la situation d'Anything particulièrement délicate : le développeur avait pourtant essayé de se conformer aux règles. Après le signalement d'Apple, le cofondateur d'Anything avait soumis une mise à jour déplaçant les aperçus d'applications dans un navigateur web plutôt que de les afficher directement dans l'app. Apple a rejeté la mise à jour et retiré l'application dans son intégralité. Entre-temps, des applications similaires restent disponibles sur le Store. Apple n'a pas expliqué cette incohérence.

Ce n'est pas vraiment une histoire d'application

Soyons clairs sur ce qui se passe ici. Apple ne dit pas « non » au développement assisté par IA. Leur propre Xcode intègre désormais des fonctionnalités de codage par IA. Ce qu'Apple dit, c'est : vous n'avez pas le droit de construire un mini-environnement d'exécution à l'intérieur d'une app iOS pour générer et exécuter du code non vérifié directement sur l'appareil. Cela court-circuite l'intégralité du processus d'App Review, et du point de vue d'Apple, c'est la ligne rouge.

Je pense qu'Apple a raison de la tracer, même si l'application de cette règle paraît incohérente et la communication laisse à désirer.

Dans nos développements natifs iOS et Android, nous avons essuyé des rejets à l'App Review plus de fois qu'il m'est possible de les compter. Les règles ont toujours été strictes, mais aussi quelque peu opaques. On apprend à lire entre les lignes au fil des soumissions. Ce qui change aujourd'hui, c'est la vitesse à laquelle toute une nouvelle catégorie d'apps — les outils de vibe-coding — s'est heurtée à une règle rédigée bien avant que quiconque imagine ce type d'usage. Apple est clairement en train de définir son approche au cas par cas, application par application.

C'est inconfortable pour les startups prises entre deux feux, mais c'est aussi la réalité de construire sur la plateforme de quelqu'un d'autre.

Le vrai problème dont personne ne veut parler

Voilà ce qui me dérange dans l'engouement général pour le vibe-coding — et cela va bien au-delà du conflit avec l'App Store.

Une récente enquête menée auprès de 700 ingénieurs révèle que 69 % des développeurs qui utilisent très fréquemment des outils de codage par IA signalent des problèmes de déploiement « toujours, presque toujours ou fréquemment » lorsque du code généré par IA est en jeu. Parmi les utilisateurs les plus intensifs, 22 % des déploiements se soldent par un rollback, un hotfix ou un incident impactant les clients. Et 53 % font état de davantage de vulnérabilités de sécurité depuis l'adoption de ces outils.

On ne parle donc pas seulement d'Apple jouant les gardiens. On parle d'un déluge de code produit plus vite que quiconque ne peut correctement le réviser, le tester ou le déployer. Les taux de succès sur la branche principale sont tombés à 70,8 %, leur plus bas niveau en cinq ans. Le goulot d'étranglement n'est plus l'écriture du code. C'est tout ce qui vient après.

Imaginez maintenant cette dynamique appliquée à des personnes sans aucune expérience en développement, créant des apps via des commandes en langage naturel pour les publier sur l'App Store. Le problème de contrôle qualité empire de façon exponentielle.

Lorsque nous développons des applications cloud-native pour des clients entreprises — notamment dans des secteurs réglementés comme la santé et la finance — nous consacrons autant de temps à nos pipelines CI/CD et à nos tests automatisés qu'au code applicatif lui-même. Nous avons vu de nos propres yeux ce qui arrive quand la vélocité de déploiement dépasse les garde-fous en place. Le résultat est rarement beau, et peu importe que le code ait été écrit par un humain ou une IA.

Ce que cela signifie pour les équipes qui développent sur iOS

Si vous développez un outil qui génère ou exécute du code sur iOS, vous devez prendre cela au sérieux. Apple a tracé une ligne claire, même si elle ne l'applique pas encore de façon uniforme. Quelques points concrets à retenir :

Premièrement, ne construisez pas votre modèle sur l'hypothèse qu'Apple vous laissera exécuter du code généré à l'intérieur d'une app iOS. La règle 2.5.2 est ancienne, bien établie, et Apple est clairement prête à la faire respecter. Si votre architecture nécessite l'exécution de code sur l'appareil, il vous faut un plan B.

Deuxièmement, si vous utilisez des outils de vibe-coding pour créer des apps destinées à l'App Store, sachez que le processus de review d'Apple n'a pas été conçu pour ce volume. Selon plusieurs témoignages, ces outils ont contribué à une hausse des soumissions et à des délais d'approbation plus longs. Prévoyez du temps supplémentaire et attendez-vous à davantage de scrutin.

Troisièmement — et cela vaut que vous utilisiez des outils IA ou non — investissez dans votre pipeline. Modèles standardisés, analyse de sécurité automatisée, feature flags, rollbacks automatiques. Les données sont claires : les équipes qui livrent du code assisté par IA sans ces fondations constatent plus d'incidents, pas moins. Dans notre travail PHP et Docker avec des clients entreprises, le schéma est identique : la vitesse sans garde-fous engendre des problèmes coûteux.

L'angle sécurité

Dans nos missions de tests d'intrusion, nous commençons à observer un nouveau schéma : du code généré par IA qui compile, passe le linting, et contient pourtant des vulnérabilités exploitables. Le code paraît propre en surface. Il suit les conventions. Mais il ne tient pas compte du contexte de sécurité spécifique de l'application pour laquelle il a été écrit.

Un rapport décrivait une fintech ayant intégré du code généré par IA sans révision, et s'étant fait exploiter une injection SQL en moins de 48 heures. Une leçon à 1,2 million de dollars sur la différence entre « ça fonctionne » et « c'est sécurisé ».

Les outils de codage par IA sont entraînés sur des dépôts de code historiques. Ils n'ont pas conscience en temps réel des CVE. Ils suggéreront volontiers un pattern utilisant une version de bibliothèque vulnérable, parce que c'est ce qui apparaissait le plus fréquemment dans leurs données d'entraînement. C'est quelque chose auquel nous pensons constamment lorsque nous configurons Cloudflare ou que nous auditons la posture de sécurité cloud de nos clients : la surface d'attaque ne rétrécit pas, et le code généré par IA crée de nouveaux angles morts.

Où tout cela nous mène

Apple va probablement formaliser une politique plus claire pour les apps de vibe-coding, tôt ou tard. L'approche actuelle au cas par cas n'est pas tenable, et l'incohérence — une app retirée alors que des applications quasi identiques restent en ligne — finira par susciter des contestations juridiques.

Mais je ne pense pas qu'Apple ouvrira la porte à l'exécution de code non restreinte sur l'appareil. Le processus d'App Review est l'une des rares choses qui différencient encore iOS en tant que plateforme. Qu'on l'aime ou non, cette couche de vérification explique en partie pourquoi les clients entreprises font confiance à iOS pour leurs applications sensibles. Dans notre travail sur les apps de santé et d'IoT, cette confiance a beaucoup de valeur.

La question plus intéressante est de savoir ce qui va se passer sur le web, où il n'y a pas de gardien. Les apps web vibe-codées ne font face à aucun équivalent de l'App Review. Les contrôles qualité et sécurité dépendent entièrement de l'équipe de développement. Pour les entreprises qui font appel à des agences ou des freelances pour créer des apps web avec des outils IA, la charge de vigilance vous incombe.

Si ce défi vous parle — que ce soit pour gérer la politique de l'App Store pour une app native ou pour vous assurer que votre pipeline de développement peut soutenir le rythme du codage assisté par IA — parlons-en. Nous sommes dans les tranchées sur ces sujets à travers le web, le mobile et la sécurité depuis un bon moment, et la conversation en vaut toujours la peine.