Créer une application mobile native avec Cadrant (sans la friction habituelle)

Faire une application mobile « pour de vrai » a longtemps voulu dire deux choses pénibles : écrire du code natif que peu de gens maîtrisent, et survivre au labyrinthe administratif d'Apple et de Google — certificats de signature, profils de provisioning, identifiants d'app, fiches store. La plupart des AI app builders contournent ce mur d'une manière simple : ils n'en font pas une vraie app du tout. Ils emballent votre site web dans une WebView et appellent ça « mobile ». Cadrant prend le chemin inverse : générer une vraie application mobile native, puis automatiser toutes les étapes de friction jusqu'à la soumission sur le store. Voici comment, et pourquoi la différence compte.

Le workflow Cadrant en trois étapes

L'idée directrice est de garder le même geste que pour le web — vous décrivez ce que vous voulez en langage naturel — mais d'aboutir à un binaire iOS et Android natif, publiable sur les stores. Concrètement, le parcours tient en trois temps.

1. Générer le code React Native

Vous créez un projet mobile dans Cadrant, vous sélectionnez l'onglet « Mobile » plutôt que « Web », et vous décrivez votre application : écrans, navigation, formulaires, logique. Cadrant génère du code React Native — pas une page web déguisée, mais de vrais composants natifs. Le rendu est natif : listes qui défilent à 60 fps, transitions système, accès au clavier, gestes tactiles. Et comme pour le web, le code reste le vôtre : vous pouvez l'inspecter, l'itérer prompt après prompt, et le faire évoluer sans repartir de zéro.

L'avantage de React Native ici n'est pas idéologique : c'est qu'une seule base de code produit à la fois iOS et Android, tout en restant de vrais composants natifs. Vous gardez la productivité d'un langage de haut niveau sans payer la taxe « web emballé » dont on parle plus bas.

2. Prévisualiser instantanément avec Expo Go

Avant même de penser au store, vous voulez voir l'app tourner sur un vrai téléphone. Cadrant s'appuie sur Expo Go pour ça : vous lancez le serveur de preview depuis le projet, un QR code s'affiche, vous le scannez avec l'app Expo Go sur votre iPhone ou Android, et votre application s'ouvre — sur votre appareil, en conditions réelles.

• Pas de Xcode, pas d'Android Studio, pas de câble USB, pas de simulateur à configurer.
• Vous testez la vraie navigation, les vrais gestes tactiles, le vrai clavier — pas une simulation dans un onglet de navigateur.
• La boucle est immédiate : vous prompttez une modification, et vous la voyez sur le téléphone que vous tenez en main.

Cette étape paraît anodine mais elle change tout pour un fondateur non-technique : valider l'ergonomie mobile « dans la main » avant d'investir une minute dans la publication, c'est ce qui évite de découvrir les problèmes une fois l'app soumise.

3. Builder et soumettre sur le store — la friction automatisée

C'est l'étape où la plupart des projets mobiles s'enlisent, et c'est là que Cadrant fait le gros du travail à votre place. Publier sur l'App Store demande normalement de jongler avec une série d'objets techniques que personne n'a envie d'apprendre : un certificat de distribution, un profil de provisioning App Store, un bundle identifier, la création de l'enregistrement de l'app sur App Store Connect, puis la compilation en mode production et l'upload du build. Chacune de ces étapes est une source classique d'échec et d'heures perdues.

Dans Cadrant, c'est un parcours guidé en quatre étapes depuis l'aperçu du projet mobile :

• Connexion Apple : vous vous connectez avec votre compte Apple Developer. Le mot de passe n'est jamais stocké — l'échange passe par le protocole SRP (Secure Remote Password), qui ne transmet qu'une preuve cryptographique à Apple.
• Détails de l'app : vous donnez le nom affiché et l'icône (1024×1024). Cadrant crée l'enregistrement sur App Store Connect et associe automatiquement un bundle identifier à votre projet.
• Certificat : Cadrant provisionne automatiquement le certificat de distribution iOS et le profil de provisioning App Store. Vous n'ouvrez jamais le portail développeur Apple pour les créer à la main.
• Publication : Cadrant compile l'app iOS en production et envoie le build sur votre App Store Connect. Comptez 20 à 45 minutes, suivis dans le journal d'activité.

Point important : l'app est publiée sous votre propre compte Apple Developer, jamais sous celui de Cadrant. Vous restez propriétaire de l'app sur le store. Une fois le build reçu, vous reprenez la main dans App Store Connect (ou TestFlight pour tester) pour finaliser la fiche — description, captures, confidentialité — et soumettre à la revue Apple. Tout ce qui est purement technique et frustrant — certificats, profils, signature, compilation — a été absorbé par la plateforme.

Pendant ce temps, chez les concurrents : la WebView

Des plateformes comme Base44 et Lovable sont excellentes pour générer des applications web. Mais quand il s'agit de « faire une application mobile native », leur réponse n'est généralement pas une app native : c'est une WebView. Techniquement, une WebView est un navigateur sans barre d'adresse, encapsulé dans une coquille d'app (souvent via Capacitor ou un wrapper équivalent). L'utilisateur installe une icône sur son écran d'accueil, mais ce qu'il lance, c'est votre site web affiché en plein écran. C'est rapide à produire — et c'est précisément le problème : ce n'est pas une vraie app, c'est un site web déguisé.

Ce qui ne marche pas bien avec une WebView

• Le risque de rejet App Store. La guideline 4.2 d'Apple rejette régulièrement les apps qui ne sont « qu'un site web reconditionné » et qui n'apportent pas de fonctionnalité native. Beaucoup d'équipes découvrent ça après avoir tout construit : l'app est refusée à la revue, et il n'y a pas de correctif simple.
• Pas d'accès réel aux API natives. Notifications push fiables, biométrie (Face ID / Touch ID), caméra, contacts, Bluetooth, stockage hors-ligne, paiements in-app : tout cela est limité, instable ou inaccessible depuis une WebView. Or ce sont souvent les fonctions qui justifient d'avoir une app plutôt qu'un site.
• Une sensation « pas tout à fait native ». Défilement qui accroche, latence au tap, transitions qui ne suivent pas les conventions du système, clavier qui masque les champs : ce sont des détails individuellement mineurs qui, mis bout à bout, font dire à l'utilisateur « ça fait bizarre » — sans qu'il sache pourquoi.
• La dépendance au réseau. Une WebView charge du contenu distant. Connexion lente ou coupée, et l'app affiche une page blanche ou tourne dans le vide. Une app native peut être pensée pour fonctionner hors-ligne ; une coquille web, beaucoup moins.
• Les performances. Les listes longues, les animations, le rendu de gros volumes de données sont nettement moins fluides en WebView qu'en natif. L'écart se voit surtout sur les appareils d'entrée de gamme — c'est-à-dire une grande partie de vos utilisateurs réels.
• Une présence store « de seconde zone ». Même publiée, une app WebView se distingue : moins bien notée, plus exposée aux mises à jour des stores qui durcissent les règles, et plus difficile à faire évoluer vers du vrai natif ensuite.

En résumé, la WebView optimise pour la démo — « regarde, mon app est sur le téléphone ! » — et reporte tous les vrais coûts à plus tard : le rejet à la revue, les fonctions qu'on ne peut pas livrer, et les utilisateurs qui sentent que quelque chose cloche.

Natif vs WebView : le tableau de décision

• Rendu : natif réel (Cadrant) vs page web en plein écran (WebView).
• API natives — push, biométrie, caméra, offline : disponibles (Cadrant) vs limitées ou absentes (WebView).
• Risque guideline 4.2 d'Apple : faible (Cadrant) vs récurrent (WebView).
• Publication store : automatisée bout en bout, sous votre compte (Cadrant) vs à votre charge, et fragile (la plupart des outils web).
• Performances sur appareils modestes : fluides (Cadrant) vs en retrait (WebView).

Pourquoi Cadrant est la solution simple

La promesse de Cadrant n'est pas « du natif, mais c'est compliqué » : c'est « du natif, aussi simple que de décrire votre app ». Vous gardez la facilité d'un outil par prompt — le même que pour le web — mais sans le compromis de la WebView. Vous obtenez du code React Native que vous possédez, une preview immédiate sur votre propre téléphone via Expo Go, et une publication sur l'App Store où certificats, profils et compilation sont automatisés pour vous, sous votre compte Apple Developer.

Pour une équipe non-technique, c'est la différence entre « avoir une icône sur l'écran d'accueil » et « avoir une vraie application que les stores acceptent et que les utilisateurs trouvent bonne ». Si votre objectif est une app que vous comptez faire grandir — notifications, hors-ligne, fonctions natives, présence durable sur les stores — partir d'une base native dès le départ vous évite de tout reconstruire le jour où la WebView atteint son plafond.

Questions fréquentes

Faut-il savoir coder pour publier une app native avec Cadrant ? Non. Vous décrivez l'app en langage naturel, vous la prévisualisez dans Expo Go, et le parcours de publication guidé en quatre étapes prend en charge la partie technique (certificat, profil, build, upload).

Ai-je besoin d'un compte Apple Developer ? Oui, pour publier sur l'App Store, l'inscription au Apple Developer Program (abonnement annuel) est obligatoire — c'est une exigence d'Apple, pas de Cadrant. L'app est ensuite publiée sous votre compte.

Une WebView peut-elle être rejetée par l'App Store ? Oui, c'est un motif de refus courant au titre de la guideline 4.2 d'Apple, surtout quand l'app n'ajoute pas de fonctionnalité native par rapport au site web.

Puis-je tester avant de publier ? Oui : Expo Go pour la preview pendant le développement, et TestFlight pour distribuer le build à des testeurs avant la soumission publique.

Le code m'appartient-il ? Oui. Comme pour les projets web Cadrant, le code React Native généré reste le vôtre, et l'app est publiée sur votre propre compte développeur — pas celui de la plateforme.