Mickael Romaniello
30 minutes, sans slides, rien à préparer.
Mickael Romaniello
30 minutes, sans slides, rien à préparer.
Du concept à la publication. Un expert dédié, 12 ans d'expérience.
En résumé : création d'application mobile à Nice (342 669 habitants), c'est un projet piloté par un expert senior — pas une agence. Communication directe, code livré, publication sur l'App Store et Google Play en quelques semaines.
Les questions qui reviennent le plus sur un premier projet portent sur le calendrier, le budget, les deux plateformes et la publication. Aucune ne se répond dans le vide : ce qui fixe le tout, c'est le périmètre — le nombre d'écrans, la présence d'un serveur et de comptes utilisateurs, et le choix de viser une plateforme ou deux. Un appel de cadrage suffit à le savoir.
Il faut compter entre huit et seize semaines pour la majorité des projets. Une application simple avec quelques écrans peut être en ligne en deux mois. Pour une plateforme complexe avec des paiements et des bases de données lourdes, on dépasse souvent les quatre mois. Ce délai dépend de vos fonctionnalités, pas de votre localisation géographique. Cependant, si nous partageons des horaires compatibles, la communication est fluide. Pas de délai d'attente de vingt-quatre heures pour une simple question. C'est une question de logique : un flux de travail continu accélère toujours la date de lancement.
Le budget dépend entièrement de la complexité technique sous le capot. Une application simple avec quelques écrans ne demande pas le même investissement qu'un système avec paiements, comptes utilisateurs et synchronisation en temps réel. N'oubliez pas la maintenance, qui représente une part importante du budget total chaque année. Le prix n'est pas dicté par le nombre de pages, mais par la mécanique invisible. Chaque projet est unique. L'avantage clé est que nous définissons ce budget ensemble lors d'un appel de 30 minutes, sans aucune surprise en fin de parcours.
Ce n'est pas une obligation absolue. Vous devez commencer par la plateforme où se trouvent vos clients. En général, les utilisateurs iOS dépensent deux fois plus d'argent dans les applications, mais Android domine largement le marché mondial. Si vous voulez être partout sans doubler la facture, la technologie hybride Flutter est la solution idéale. Elle permet de coder une seule fois et de publier sur les deux écosystèmes. Vous réduisez sensiblement les coûts tout en couvrant l'intégralité de votre audience.
Je gère l'intégralité du processus de publication pour vous. C'est un véritable parcours du combattant. Chez Apple, la validation prend de vingt-quatre heures à une semaine. Chez Google, il faut désormais un panel de vingt testeurs obligatoires pendant quatorze jours consécutifs avant le lancement public. Les statistiques prouvent que près d’une soumission sur quatre est rejetée. Un simple bouton mal placé suffit pour être refusé. Je connais parfaitement leurs règles strictes, ce qui vous évite des semaines de frustration et garantit une mise en ligne sereine.
Chaque projet inclut une garantie totale de trois mois après la mise en ligne sur les stores. Si un bug technique lié au développement initial apparaît pendant cette période, je le corrige immédiatement sans aucun coût supplémentaire. Dès le premier jour, j'active des outils de surveillance comme Crashlytics. Je suis alerté à la seconde où un plantage survient sur le téléphone d'un utilisateur. Je ne vous abandonne pas dans la nature avec le code source. C'est une question de confiance, mon objectif est que votre produit soit parfaitement stable.
Absolument, je travaille avec des porteurs de projet partout à distance, y compris dans votre région. Je suis basé à Cannes, mais la distance n'a plus aucune importance aujourd'hui. Nous collaborons via des appels vidéo hebdomadaires, des canaux de discussion instantanée et des outils de partage d'écrans. Vous voyez l'avancement de votre application chaque semaine. Travailler avec un développeur indépendant situé ailleurs vous permet souvent d'obtenir un niveau d'expertise très pointu sans avoir à supporter les coûts structurels énormes d'une grande agence locale.
J'utilise Swift pour iOS, Kotlin pour Android et Flutter pour le développement hybride multiplateforme. Pour le moteur invisible, je m'appuie sur Firebase ou des API REST robustes. Je ne suis pas un intégrateur qui utilise un seul outil par défaut. Le choix technologique dépend exclusivement de vos besoins commerciaux. Si votre application nécessite des performances extrêmes en 3D, nous irons vers du natif pur. Si vous voulez tester le marché rapidement avec un budget maîtrisé, Flutter sera parfait. Je m'adapte à votre réalité économique.
La maintenance est vitale car Apple et Google imposent quatre à six mises à jour de leurs systèmes par an. Si votre application n'est pas mise à jour, elle finit par planter, puis elle est purement et simplement supprimée des magasins. La maintenance comprend la correction des bugs invisibles, les patchs de sécurité et la compatibilité avec les nouveaux téléphones de l'année. C'est exactement comme l'entretien de votre voiture. Prévoyez toujours un budget annuel de sensiblement du coût de création. Une application non maintenue est une application morte.
Oui, vous avez un accès total et transparent à chaque étape du chantier. Fini les prestataires qui disparaissent pendant six mois. Nous utilisons un tableau de bord partagé où vous voyez exactement sur quelle tâche je travaille. Vous avez accès aux maquettes design en direct. Vous pouvez même consulter le code source. Surtout, nous faisons une démonstration vidéo toutes les deux semaines. Vous installez la version en cours de travail sur votre propre téléphone et vous la testez physiquement. Vous gardez le contrôle absolu.
Je signe systématiquement un accord de confidentialité avant même notre premier appel d'exploration. Dans le monde de la technologie, les idées ne valent malheureusement pas grand-chose. C'est l'exécution qui fait toute la différence. Sachant qu’une grande partie des fonctionnalités imaginées ne sont jamais utilisées par le public final, le vrai danger n'est pas qu'on vous vole votre idée. Le vrai danger est de la coder de travers ou de mal la lancer. Concentrons-nous sur la qualité de l'exécution.
342 669 habitants vivent à Nice.
Et si vous regardez autour de vous dans la rue, dans les cafés, dans les transports de Provence-Alpes-Côte d'Azur, vous ferez un constat très simple. Tout le monde a les yeux rivés sur son smartphone.
Ce n'est plus une simple tendance. C'est la norme absolue de votre pays.
Aujourd'hui, l’essentiel du trafic web mondial provient des appareils mobiles. Et ce chiffre ne fait qu'augmenter. Pourtant, de nombreuses entreprises à Nice continuent de fonctionner avec de simples sites web, souvent lents et mal adaptés aux petits écrans.
Spoiler : si le chargement dépasse trois secondes, l'utilisateur s'en va. Il clique. Il quitte. Il oublie. 📱
Une application ne se fabrique pas en écrivant du code au hasard. L'ordre est toujours le même : cadrer ce qu'elle doit faire, dessiner les écrans et les faire valider, développer par tranches essayables, puis publier. Chaque étape produit quelque chose que vous pouvez juger — un document, une maquette cliquable, une version installable — et jamais une promesse.
Comment fabrique-t-on concrètement une application à Nice ? Ce n'est pas un développeur enfermé dans une cave qui tape du code au hasard. C'est un processus industriel, créatif et rigoureux.
Si vous voulez que votre projet survive en Provence-Alpes-Côte d'Azur, il faut respecter quatre grandes étapes de fabrication.
Voici comment ça se passe vraiment.
La première étape, c'est la validation du concept. Quel problème précis votre application résout-elle ? Pour qui ? Il faut pouvoir répondre en une seule phrase. Si c'est trop vague, c'est mauvais signe. Spoiler : vouloir faire un couteau suisse est une erreur mortelle. Sachant qu’une grande partie des fonctionnalités d'une application ne sont jamais utilisées, nous allons élaguer votre idée pour ne garder que la valeur pure.
À Nice, l'utilisateur final est très souvent quelqu'un de passage : il reste quelques jours, il ne connaît pas votre marque, et il n'a aucune raison de créer un compte. Ça devrait décider du choix du prestataire — il vous faut quelqu'un qui se batte pour retirer des étapes, pas pour en ajouter.
Trois décisions en découlent, et elles se prennent avant la première maquette. L'application doit montrer quelque chose d'utile avant de demander quoi que ce soit : pas d'inscription en écran d'accueil, le compte arrive plus tard, quand il sert à quelque chose. Un QR code sur une table ou un comptoir doit ouvrir directement le bon écran, pas la page d'accueil. Et il faut une version web pour ceux qui n'installeront jamais rien, parce qu'ils sont plus nombreux qu'on ne l'imagine.
Installer une application est un engagement. Sur quatre jours, cet engagement est mince, et chaque écran ajouté avant la valeur en perd une partie.
Je travaille à une trentaine de kilomètres. Sur ce genre de projet, aller voir l'endroit où les gens sortiront leur téléphone vaut deux réunions.
Nice est à une trentaine de kilomètres de Cannes, où je travaille. C'est la seule ville de cette page où je peux être chez vous dans la matinée et rentrer déjeuner, et sur un premier projet ça vaut plus qu'on ne le croit : une heure autour d'une table remplace trois visioconférences et évite les malentendus qui se paient deux mois plus tard. Le reste du travail se fait à distance comme partout ailleurs — mais le démarrage est plus rapide quand on s'est vu, et ici il ne coûte qu'un aller-retour en train.
Nice mélange tourisme, immobilier et santé, trois secteurs où l'application est souvent saisonnière ou réglementée. La saisonnalité change le calendrier : mieux vaut livrer en février pour la saison qu'en juin. Le réglementé change le budget, parce que l'hébergement des données de santé ne se choisit pas au dernier moment.
Le calendrier saisonnier mérite d'être pris au sérieux, parce qu'il ne pardonne pas. Une application touristique qui sort en juillet a raté l'année : les visiteurs de la saison sont déjà arrivés avec leurs habitudes, et vous découvrirez vos bugs sur vos vrais utilisateurs au pire moment. Un projet visant l'été doit être en test au printemps, ce qui veut dire commencer à l'automne précédent. Quand quelqu'un m'appelle en mai pour l'été, je le dis franchement : on vise l'année suivante, ou on réduit tellement le périmètre que ce qui sort tient vraiment debout.
L'immobilier apporte une contrainte différente, celle des photos. Une application immobilière vit sur ses images, et les images sont ce qui rend une application lente. Des photos de plusieurs mégaoctets chargées à pleine résolution sur une liste de vingt biens font une application qui rame et un forfait mobile qui fond. Le travail utile est invisible : redimensionner côté serveur, charger progressivement, mettre en cache correctement. C'est peu spectaculaire et c'est ce qui fait la différence entre une application qu'on garde et une qu'on désinstalle.
Enfin, Nice reçoit une clientèle internationale toute l'année, et une application locale qui n'existe qu'en français se prive d'une partie de son public. Ce n'est pas nécessairement un problème — selon votre marché, l'anglais seul en plus peut suffire — mais c'est un arbitrage à faire consciemment plutôt qu'à subir, parce qu'ajouter une langue après coup coûte plus cher que de prévoir la place dès le début.
Quand l'application s'adresse à quelqu'un de passage, le premier mois se passe à retirer des étapes. On mesure ce qui sépare l'ouverture de l'application du moment où elle sert enfin à quelque chose, et on raccourcit.
Je suis à trente kilomètres : ce test-là, je viens le faire avec vous.
Un projet se déroule en quatre temps : un cadrage qui décide de ce qui entre dans la première version, des maquettes que vous manipulez avant qu'une ligne de code existe, un développement livré par tranches installables, puis la publication. Ce qui compte n'est pas le nombre d'étapes mais leur rythme.
Quatre étapes, dans cet ordre :
Hériter d'une application développée au moins-disant coûte presque toujours plus cher que de l'avoir bien faite. Le motif est constant : pas de documentation, pas de tests, un code que personne ne peut reprendre, et des plantages quotidiens qui font tomber la note du store. La réparation commence par un audit, pas par une réécriture.
Parfois, le pire ennemi d'un projet, c'est une fausse bonne affaire. Le cas suivant revient assez souvent pour être décrit : une entreprise technologique en pleine panique.
Ils avaient hérité d'une application mobile développée par une équipe offshore très bon marché. Le résultat ? L'application plantait plusieurs fois par jour.
La note sur les stores était tombée très bas. Les utilisateurs laissaient des avis désastreux quotidiennement. Le PDG était prêt à tout jeter à la poubelle.
Si le prix est votre seul critère, nous ne sommes probablement pas faits pour travailler ensemble, et il vaut mieux le dire tout de suite. Une application peu chère l'est rarement au total : un code écrit sans structure devient impossible à modifier, et la deuxième version coûte alors plus que la première. Ce que vous achetez, c'est la possibilité de faire évoluer l'application après le lancement.
Sur les ventes faites dans l'application, Apple et Google prélèvent entre 15 % et 30 % selon votre chiffre d'affaires annuel et le programme auquel vous êtes éligible. Ce calcul se fait avant de fixer vos prix, pas après le lancement.
Si le prix est votre seul et unique critère pour choisir un développeur à Nice, nous ne sommes probablement pas faits pour travailler ensemble.
Ce n'est pas de l'arrogance. C'est de l'honnêteté.
Parlons de la vraie valeur des choses en France.
Dans le transport, le mode hors ligne n'est pas une option de confort, c'est l'architecture. Entrepôts, sous-sols et routes de campagne coupent le réseau, et une application qui suppose une connexion permanente ne tient pas une journée. Deux décisions suivent : la règle qui tranche les modifications concurrentes, et la façon dont la preuve de livraison est conservée.
Dans le transport, le mode hors ligne n'est pas une option de confort : c'est l'architecture. Un entrepôt métallique, un sous-sol, une zone portuaire ou une route de campagne coupent le réseau, et une application qui suppose une connexion permanente ne survit pas à sa première journée réelle.
On construit donc l'inverse : tout fonctionne sans réseau, et la synchronisation se fait seule dès qu'il y a du signal — sans bouton à presser, parce qu'un bouton à presser finit toujours par ne pas l'être.
Certains de mes clients travaillent avec moi depuis des années. Pourquoi ? Parce que je ne disparais pas dans la nature une fois l'application iOS ou Android publiée.
Basé à Cannes, j'accompagne mes clients sur la durée. Pendant mes 12 ans de carrière, j'ai compris que la sortie d'une app n'est que le début de l'histoire. Il faut l'améliorer, la maintenir, écouter les utilisateurs.
Le facteur le plus important est ce suivi rigoureux. Je suis là pour vous suivre dans la durée, comme un vrai partenaire.
Nice est la ville la plus proche de mon bureau : on peut se voir avant même de parler d'argent.
Trente minutes, en visioconférence ou autour d'une table selon ce qui vous arrange. On regarde votre calendrier avant tout le reste, parce qu'ici c'est lui qui commande : viser une saison veut dire commencer à l'automne précédent, et un projet lancé au printemps pour l'été est un projet qui sortira l'année suivante.
Mieux vaut l'entendre en septembre qu'en mai.
30 minutes pour démarrer
Réserver →La plupart de mes projets se déroulent à distance, et en pratique cela change peu de choses. Nous échangeons en visioconférence dès que vous en avez besoin, pas uniquement aux grandes étapes, et vous pouvez me poser vos questions à tout moment pendant le projet — je réponds toujours.
Une fois que nous travaillons ensemble, un déplacement sur place peut tout à fait être organisé si votre projet le justifie. Les frais de déplacement sont alors chiffrés à part, en amont et sans surprise.