Mickael Romaniello
30 minutes, sans slides, rien à préparer.
Mickael Romaniello
30 minutes, sans slides, rien à préparer.
Un seul interlocuteur, du concept à la publication. 12 ans d'expérience. 15+ applications livrées.
En résumé : je construis des applications iOS et Android pour des clients à Montpellier (290 053 habitants) et partout en Occitanie. Un seul interlocuteur, 12 ans d'expérience, livraison du concept à la publication en 8 à 16 semaines.
Sur iPhone, votre calendrier n'est pas tout à fait le vôtre.
Apple publie une version majeure d'iOS chaque automne, et ses utilisateurs l'installent vite — beaucoup plus vite que sur les autres plateformes. En quelques semaines, l'essentiel de votre public à Montpellier est passé au nouveau système.
C'est une bonne nouvelle : vous n'avez pas à supporter éternellement de vieilles versions. C'en est une moins bonne si personne ne s'en occupe, parce que chaque version change quelque chose — une autorisation qui se demande autrement, un composant d'interface qui se dessine différemment, une règle du store qui se durcit.
Une application iOS se prévoit donc sur deux calendriers : le vôtre, et celui d'Apple.
« Une application iOS » ne désigne pas une seule chose. L'iPhone est le point de départ, mais la même base peut servir sur iPad, sur Mac et, dans une moindre mesure, sur Apple Watch. Chaque appareil ajouté a un coût réel, et la question se tranche au cadrage plutôt qu'en cours de route.
L'iPad n'est pas un grand iPhone. L'écran change la mise en page, l'application peut se retrouver affichée à côté d'une autre, et certains usages n'ont de sens que là — remplir un formulaire long, annoter un document, montrer quelque chose à un client à Montpellier.
Le Mac est le cas le plus rentable quand il se justifie : une bonne partie du travail est déjà faite, et l'application peut tourner sur ordinateur avec des ajustements plutôt qu'une réécriture. Encore faut-il l'avoir prévu.
La Watch est un cas à part. Elle ne convient qu'à des usages très courts — un coup d'œil, une validation, une notification qu'on peut traiter sans sortir son téléphone. Y porter une application entière ne marche jamais.
Mon conseil au départ est presque toujours le même : l'iPhone seul, bien fait, et le reste quand l'usage le réclame.
Plus de 15 applications livrées. Des startups qui ont trouvé leur marché. Des PME qui ont fluidifié leur travail.
En 12 ans, j'ai vu ce qui fonctionne et ce qui plante sur iOS et Android. Depuis Cannes, je ne vous promets pas la lune. Je vous promets des résultats. Mon travail est de construire des outils solides que vos utilisateurs vont réellement adopter.
L'avantage clé, c'est l'impact de votre application sur la vraie vie. On regarde ensemble comment faire grandir votre projet de manière intelligente et rentable ?
C'est la difficulté d'un premier projet, et elle est réelle : vous devez choisir quelqu'un dont vous ne pouvez pas évaluer le travail. La bonne nouvelle, c'est qu'une prestation se vérifie sans lire une ligne de code. Cinq points suffisent, et ils sont tous observables par vous.
Une version installable toutes les deux semaines, même incomplète, sur votre propre téléphone. Le dépôt de code à votre nom dès le premier jour, pas à la livraison. Un fichier qui explique comment reconstruire l'application, pour qu'un autre développeur puisse reprendre. Une note écrite après chaque décision, pour qu'on ne se dispute pas dans six mois sur ce qui avait été dit. Et une démonstration sur votre appareil plutôt qu'une vidéo.
Aucun de ces cinq points ne demande de compétence technique de votre part. Tous les cinq sont refusés, poliment, par les prestataires qui ont quelque chose à cacher.
Si l'un d'eux manque dans une proposition que vous avez reçue, demandez pourquoi. La réponse vous apprendra plus que le devis.
Montpellier est une ville jeune, avec beaucoup de premiers projets et peu de budget de départ. C'est exactement le cas où il faut savoir dire non : une application qui fait une seule chose correctement se lance en deux mois, tandis qu'une qui en fait cinq à moitié ne se lance jamais. On commence par retirer, pas par ajouter.
Retirer est plus difficile qu'il n'y paraît, parce que chaque fonction qu'on enlève ressemble à un renoncement. La bonne question n'est pas « est-ce que ce serait bien », presque tout serait bien. La bonne question est : « si cette fonction n'existe pas, est-ce que quelqu'un utilise quand même l'application ? » Si la réponse est oui, elle attend. Une messagerie interne, un système de parrainage, des notifications personnalisées, un tableau de statistiques : ce sont presque toujours des fonctions de version deux, écrites après avoir vu comment les gens se servent vraiment de la version une.
L'avantage d'un budget contraint, quand on l'assume, c'est qu'il force des décisions saines. Il pousse à sortir vite, donc à apprendre vite. Il interdit de développer six mois dans le vide en s'imaginant ce que veulent les utilisateurs. Et il oriente vers des choix techniques simples, qui sont aussi les moins chers à maintenir — un projet dont la facture d'infrastructure est de quelques dizaines d'euros par mois peut attendre son public sans vous ruiner, ce qui n'est pas vrai d'une architecture surdimensionnée dès le premier jour.
Le budget contraint a en revanche un angle mort, et c'est celui qui fait le plus de dégâts ici : la première version n'est pas la dépense totale. iOS sort une version majeure chaque septembre, Android chaque année, et chacune casse quelque chose — une permission qui change de forme, une bibliothèque qui n'est plus signée, un écran qui se décale. Une application qu'on laisse tranquille dix-huit mois finit par ne plus se lancer, et la remettre debout coûte plus cher que de l'avoir suivie. Sur un premier projet, le bon calcul n'est pas « combien pour sortir » mais « combien pour sortir et tenir un an ». Je préfère réduire le périmètre de la version une et garder de quoi passer septembre.
Montpellier a un écosystème santé et une grosse population étudiante, et cela produit deux profils très différents. Les projets santé arrivent avec des contraintes lourdes qu'il faut chiffrer honnêtement dès le début, notamment sur l'hébergement des données. Les projets étudiants arrivent avec de l'énergie, une idée et un calendrier scolaire. Dans les deux cas, mon rôle utile est le même : dire ce qui est réellement faisable avec ce que vous avez, et ne pas vendre le reste.
Sur un premier projet avec un budget serré, le premier mois décide de tout : ce qu'on retire maintenant est ce qui permet de sortir. On ne commence pas par concevoir, on commence par couper.
Ce qu'on n'a pas construit reste écrit quelque part. On y revient quand des utilisateurs réels le réclament — et ils réclament rarement ce qu'on avait prévu.
Le jour de la publication n'est pas la fin du projet, c'est le premier jour où l'application rencontre de vrais utilisateurs. La suite se prépare avant, pas après : sans elle, les premiers retours arrivent et personne n'est là pour y répondre.
La première semaine, on surveille. Pas les téléchargements — les plantages, les écrans où les gens s'arrêtent, les endroits où ils reviennent en arrière. Un rapport de plantage vaut mille suppositions, et les trois premiers jours en apprennent plus que trois mois de réunions.
La deuxième semaine, on corrige ce que ces retours ont montré, et on publie une mise à jour. Elle est presque toujours nécessaire, et ce n'est pas un échec : aucune première version ne survit intacte au contact de son public à Montpellier.
Ensuite le rythme ralentit, mais ne s'arrête pas. Apple sort une version majeure d'iOS chaque automne, Google une d'Android chaque année, et chacune casse quelque chose — une autorisation qui change de forme, une bibliothèque qui n'est plus signée, un écran qui se décale.
On décide ensemble du niveau de suivi avant le lancement, pas au premier incident.
Une application de santé sur iOS a un avantage rare : le système fournit déjà un cadre pour les données de santé et leur partage avec la montre. Cela évite d'inventer un stockage à soi, et ça déplace la difficulté ailleurs — vers les autorisations demandées à l'utilisateur et vers l'hébergement des données côté serveur, qui, lui, n'est pas fourni.
Le secteur de la santé demande une rigueur absolue.
Voici un cas qui revient souvent : une application de suivi médical connectée.
Sur iOS, la santé a son propre écosystème : HealthKit.
Le but était de synchroniser les données de l'Apple Watch (rythme cardiaque, sommeil) avec une interface patient simple et sécurisée.
L'avantage clé ici, c'est la protection des données proposée par Apple.
Nous avons construit une architecture totalement native en Swift.
Le développement n'est pas la seule dépense d'une application, et les autres reviennent tous les ans. Les connaître avant de signer change la façon dont vous dimensionnez le projet — et évite la mauvaise surprise du douzième mois, qui est toujours la plus mal reçue.
Publier coûte de l'argent aux deux endroits. Le programme développeur d'Apple se renouvelle chaque année ; le compte développeur Google Play se paie une fois, à l'inscription. Ces comptes doivent être à votre nom, pas au mien : c'est votre application, et un compte au nom du prestataire est le piège le plus courant du secteur.
Viennent ensuite l'hébergement et les services que l'application consomme. Sur un projet de Montpellier qui démarre, la facture est modeste — mais elle tombe tous les mois, et elle grandit avec le nombre d'utilisateurs.
Si vous vendez dans l'application, Apple et Google prélèvent entre 15 % et 30 % selon votre chiffre d'affaires et le programme auquel vous êtes éligible. Ça se calcule avant de fixer vos prix, pas après.
Voyage haut de gamme, outils professionnels et services à la demande ont un point commun : leurs utilisateurs paient. Sur ces marchés, une application iOS bien faite rentabilise plus vite qu'une couverture large et approximative. Le bon ordre est presque toujours iOS d'abord, Android quand le modèle est validé.
Certains business modèles s'accordent naturellement avec l'univers Apple.
En résumé, voici pourquoi ces secteurs privilégient l'iPhone.
Une clientèle qui voyage avec un budget conséquent possède souvent un iPhone.
L'interface native iOS permet d'offrir une expérience de réservation fluide, des notifications riches avec des images, et une géolocalisation ultra-précise.
Apple traite 100 000+ soumissions par semaine, et les applications de voyage fluides sont toujours mises en avant.
La continuité entre le Mac, l'iPad et l'iPhone est la grande force d'Apple.
Si vous créez un outil de productivité pour les entreprises à Montpellier, l'application iOS est la porte d'entrée.
Ces questions arbitrent entre des options : natif ou hybride, abonnement ou achat, quel outil d'interface, quel niveau de maintenance après la publication. Le critère de décision est le même partout — ce que vous devrez pouvoir modifier dans un an. Le natif coûte un peu plus au départ et beaucoup moins quand l'application vit longtemps.
Pour un rendu premium, le natif est roi. L'avantage clé, c'est l'expérience utilisateur qui sera toujours supérieure avec les technologies d'Apple par rapport à un outil hybride.
Non, TestFlight est gratuit. Il est inclus dans votre abonnement de développeur Apple à un abonnement annuel.
près d’une soumission sur quatre est rejetée. Souvent pour des bugs non traités, un manque de valeur, ou le non-respect des règles de paiement d'Apple.
Oui, si vous souhaitez que l'application s'affiche au nom de votre entreprise de Montpellier sur le Store. Si vous publiez en nom propre, il n'est pas nécessaire.
Bien sûr. C'est même recommandé. En moyenne, les utilisateurs iOS dépensent davantage dans les applications que les utilisateurs Android. L'écosystème s'y prête parfaitement.
Cela dépend de la complexité. Une V1 simple peut prendre 4 à 8 semaines de code, plus le temps incompressible de création de compte et de validation par Apple.
Oui. iOS évolue chaque année en septembre. Il faut s'assurer que votre code reste compatible avec les nouvelles règles et les nouveaux iPhone.
C'est l'outil fourni par Apple pour dessiner les écrans. C'est ce qui nous permet de coder rapidement des interfaces magnifiques et réactives.
Oui, mais Apple exige que l'on justifie très clairement à l'utilisateur pourquoi nous en avons besoin. C'est une question de logique et de respect de la vie privée.
C'est exigeant. Apple traite 100 000+ soumissions par semaine. C'est pour cela que je gère cette étape pour vous, pour garantir un lancement réussi à Montpellier.
Un premier projet se plante rarement sur la technique. Il se plante sur le périmètre : trop de fonctions, pas assez de budget pour aller au bout, et rien qui sorte.
Trente minutes suffisent à retirer ce qui peut attendre. On passe chaque idée au même filtre : si cette fonction n'existe pas, est-ce que quelqu'un utilise quand même l'application ? Ce qui survit à ce tri, c'est votre version une, et elle est presque toujours plus petite et plus rapide à sortir que ce que vous imaginiez.
On regarde aussi le budget de la deuxième année, pas seulement celui du lancement.
En 30 minutes, vous saurez exactement par où commencer.
Réservez un appel gratuit →30 minutes pour démarrer votre projet
Réservez un appel gratuit →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.