Il y a des projets qui partent d'une idée sur Figma. Paviga est parti d'un prototype sur Lovable. L'app existait déjà, dans sa version "web-only". Paul, le fondateur, un ami (que je remercie pour sa confiance) avait utilisé Lovable.dev pour générer une base solide -gestion de véhicules, suivi des dépenses, rappels, simulation, PDF. L'interface était propre, la logique métier pensée. Mais c'était une app web, coincée dans un navigateur. L'objectif : en faire une vraie app mobile, iOS et Android, avec une expérience native.
Reprendre la base en main
10 → 17 mars
Migration Supabase
L'ancien projet tournait sur une instance Supabase qui n'était plus la bonne -elle appartenait à Lovable. On a migré les données, reconstruit les tables, réécrit les scripts d'import. Pas glamour, mais indispensable.
Auth robuste
Le système de connexion existait mais n'était pas pensé pour le mobile. On a ajouté le flux OTP pour la récupération de compte, réglé les problèmes de clavier Android qui masquait les champs, fixé le comportement du bouton retour natif.
Layout desktop
L'app devant aussi fonctionner dans un navigateur sur ordinateur, on a adapté le layout pour qu'il soit propre sur grand écran : contenu centré, drawers contraints, nouvelle page d'auth avec tabs, Google OAuth activé.
Android natif
18 → 24 mars
Capacitor était déjà dans les dépendances. Il a fallu le faire fonctionner correctement.
Android d'abord
Configuration de l'identifiant d'application, correction du flux de connexion OAuth, gestion du bouton retour Android, fix du clavier qui remontait le contenu.
Google Sign-In natif Android
Le plus délicat. Trouver le bon plugin compatible (certains sont abandonnés, d'autres cassés), brancher Google Cloud Console, faire accepter les tokens Google natifs à Supabase. Sur Android, le bouton Google ouvre bien le picker natif de l'OS.
Swipe navigation
Un hook useSwipeTabs pour naviguer entre les onglets principaux avec un geste horizontal, à la façon des apps natives. Avec détection de direction pour les transitions de page via Framer Motion.
iOS, le vrai défi
25 → 27 mars
iOS, c'est un autre monde. Les règles sont différentes, WebKit a ses propres bugs, et chaque petit détail compte.
Setup Xcode
Certificats, identifiants, configuration déclarée côté Apple. Un script automatisé pour builder et préparer chaque nouvelle version -une seule commande avant chaque archive.
Expérience native iOS
C'est là que le travail de fond commence :
Google Sign-In iOS natif
Différent d'Android -la configuration et la séquence d'appels ne sont pas les mêmes. Une fois que c'est bon : plus de navigateur qui s'ouvre, plus de redirect. L'utilisateur voit le picker natif iOS et c'est tout.
UX login en 2 étapes
Sur iOS, le clavier masque les champs si les deux sont visibles simultanément. On a séparé email (étape 1) et mot de passe (étape 2) -avec détection focus/blur pour adapter la mise en page.
Détails qui font la différence
Swipe vers le bas pour fermer la galerie photos plein écran, comme dans l'app Photos d'Apple. Status bar qui change de couleur selon le thème clair/sombre de l'app.
27 mars -Premier TestFlightPremier upload sur App Store Connect. Build signé, archivé, distribué via TestFlight. L'app tourne sur un iPhone réel, sans fil, installée proprement.
Publication sur les stores
La partie qu'on voit rarement dans les post-mortems mais qui prend autant de soin que le développement : tout ce qui se passe entre "l'app tourne sur mon iPhone" et "l'app est disponible pour tout le monde".
App Store Connect
Fiche produit complète : titre, sous-titre, description, mots-clés (500 caractères -chaque mot compte pour l'ASO). Captures d'écran aux formats requis : 6,7" iPhone 16 Pro Max et 5,5" iPhone 8 Plus obligatoires. Privacy policy hébergée. Age rating déclaré. Chiffrement export compliance confirmé. Catégorie : Finances.
Google Play Console
Même discipline côté Android : feature graphic 1024×500, icône adaptative 512×512, captures en format Pixel. Déclaration des permissions (caméra, stockage). Fiche de confidentialité. La review Google est plus rapide -quelques heures pour un compte développeur vérifié.
Google Cloud Platform -OAuth en prod
Le Google Sign-In qui fonctionne en dev ne fonctionne pas forcément en prod -les clés de signature changent. Un détail qui peut bloquer le lancement si on s'en aperçoit trop tard. On s'en est aperçu à temps.
La review Apple
On prépare les notes de review : credentials de compte de test fonctionnel, description des flux principaux, explication du chiffrement. L'app part en review le 28 mars au soir. Résultat : approuvée sans demande de modification. 24h de délai, zéro aller-retour.
Ce moment où tu tapes "Paviga" dans la recherche App Store et que tu la trouves -c'est un truc à part. C'est là que 18 jours de dev prennent tout leur sens.
De la soumission à la publication
Soumettre sur les stores, c'est la fin du dev -pas la fin du boulot. Ce qu'on ne compte pas souvent dans les timelines, c'est tout ce qui se passe entre "submitted for review" et "available on the App Store".
Bêta fermée Android · 14 jours, 12 testeurs
Google Play impose un test fermé d'au moins 14 jours avec 12 testeurs actifs minimum avant d'autoriser l'accès à la production. Pas un obstacle -une vraie opportunité. 12 testeurs, deux semaines de retours réels, quelques correctifs intégrés en cours de route. L'app arrive en prod avec déjà un peu de vécu.
Conformité iOS
La review Apple a identifié des points à traiter : formulations dans les captures d'écran, libellés de permissions à normaliser, mention de la politique de confidentialité dans l'app. Un aller-retour classique -préparé, géré, corrigé. Rien de bloquant si on l'anticipe.
En attente de validationLes deux apps sont soumises sur l'App Store et le Google Play. Bêta Android en cours avec 12 testeurs, conformité iOS en traitement. La version web SaaS est déjà en ligne sur app.paviga.fr. On met à jour dès que c'est live.
Une app complète, trois plateformes
En 18 jours de développement effectif. Sans refaire l'app from scratch -en partant de ce qui existait, en migrant proprement, et en ajoutant couche par couche ce qui fait une vraie expérience native.
Présence web & image de marque
Une app sur les stores, c'est bien. Une app que les gens trouvent, comprennent et ont envie de télécharger -c'est mieux. Après la publication, le travail a continué côté web.
Landing page & early access
Une landing page dédiée, mise en place pour accueillir les premiers visiteurs. CTA activé pour recueillir les inscriptions en early access -premier point de contact entre Paviga et ses futurs utilisateurs.
Blog intégré avec backoffice
Un blog complet intégré directement à la landing : liste d'articles, pages article avec image de couverture, mise en page propre et lisible. Dans le dashboard, un éditeur dédié avec scheduling de publication et score SEO en temps réel -pour que le client puisse publier du contenu en toute autonomie, sans toucher à une ligne de code.
Dashboard & stats
Suivi de métriques non nominatives directement dans le dashboard : nombre d'inscrits, de véhicules enregistrés, de photos uploadées. Des indicateurs simples pour mesurer la croissance sans complexifier la stack analytics.
SEO & indexation
Google Search Console connecté, sitemap dynamique généré automatiquement à chaque nouvel article. Données structurées JSON-LD (Schema.org) dans le <head> -invisibles pour les visiteurs, lues par Google pour comprendre ce qu'est la page, pas juste ce qu'elle dit. Les bases techniques sont là pour que le contenu soit indexé correctement dès la publication.
Une base solide pour la suiteLanding, blog, stats, SEO -c'est à nourrir et à optimiser dans le temps. Mais le socle est là : Paviga a maintenant tout ce qu'il faut pour consolider son image de marque et grandir de façon autonome.
Lovable génère une base propre et fonctionnelle. Mais passer d'un prototype web à une app store-ready, ça demande une autre discipline : comprendre les contraintes de chaque plateforme, traiter les edge cases que les générateurs ne voient pas, et avoir quelqu'un qui connaît le vrai comportement d'iOS et Android en conditions réelles.
Le code n'est pas parfait. Il y a des patches, des workarounds, des trucs qui fonctionnent sans qu'on sache exactement pourquoi au premier abord. C'est normal. L'objectif, c'est que ça tourne. Et ça tourne; sur trois plateformes, en 18 jours.
C'est exactement ce genre de travail que je fais chez Small Ideas Factory.