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.
Android n'est pas un téléphone. C'est des milliers de téléphones différents.
C'est ce qui fait sa force — vos clients à Montpellier en ont un, quel que soit leur budget — et c'est ce qui rend le travail différent d'iOS. Un même écran doit tenir sur un petit appareil d'entrée de gamme comme sur une grande tablette, avec des versions du système qui vont de l'ancienne à la toute dernière.
Chaque fabricant ajoute par-dessus sa propre couche, qui change la gestion de la batterie, les notifications et parfois le clavier. Une application qui n'a été essayée que sur un seul modèle se comporte autrement chez la moitié de ses utilisateurs.
C'est la première chose qu'on cadre : sur quels appareils réels votre application doit tenir debout.
Développer pour Android, ce n'est pas seulement écrire l'application : c'est aussi savoir comment elle arrive entre les mains des gens. Google Play permet de la diffuser par étapes — à une poignée de testeurs d'abord, puis à un groupe fermé, puis au public — et de n'ouvrir à tout le monde qu'une fois qu'on est sûr.
Cette progression change beaucoup de choses. Une nouvelle version peut d'abord ne partir qu'à une petite part de vos utilisateurs. Si les rapports d'erreur montent, on arrête la diffusion avant que le reste du public ne soit touché. Sur une application qui compte pour votre activité à Montpellier, c'est la différence entre un incident et une mauvaise journée.
Le test fermé sert à autre chose : faire essayer l'application à de vraies personnes, sur leurs propres téléphones, sans passer par une installation compliquée. C'est là qu'on découvre les problèmes qu'aucun émulateur ne montre — le clavier qui recouvre un champ, la notification qui n'arrive pas parce que le fabricant met l'application en veille.
Tout ça se prépare pendant le développement, pas la semaine de la sortie.
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 grand public sur Android doit tenir sur des appareils de toutes marques et de tous prix, pas seulement sur le téléphone du développeur. C'est la contrainte qui structure le projet : choisir les appareils réels à couvrir, et tester dessus. Une application essayée sur un seul modèle se comporte autrement chez une bonne partie de ses utilisateurs.
Prenons un exemple concret.
Un client m'a contacté pour créer une application de réservation de services à domicile, ciblant spécifiquement la région Occitanie.
Le problème initial ? L'application devait cibler le grand public.
Et le grand public, ça utilise de l'Android. De toutes les marques. De tous les prix.
Le facteur le plus important était de gérer la terrible fragmentation d'Android.
L'application devait être aussi fluide sur un Xiaomi bas de gamme vieux de cinq ans que sur le dernier Samsung Galaxy S.
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.
Les applications grand public, l'immobilier et l'éducation cherchent la portée avant la marge. Android donne accès à la plus grande partie du parc mondial, et ses outils de diffusion permettent d'ouvrir progressivement — quelques testeurs, puis un groupe fermé, puis le public. C'est ce qui rend un premier lancement moins risqué.
Chaque domaine a ses problématiques. Android possède souvent la réponse technique appropriée pour votre entreprise à Montpellier.
Ces questions portent sur ce qui fait qu'une application Android tient dans la durée : la batterie, les autorisations, les blocages d'interface, le formulaire de sécurité des données exigé par Google, et les appareils sur lesquels on teste vraiment. Ce sont des sujets d'ingénierie plus que de conception, et ce sont eux qui décident de la note laissée sur le store.
Pour un projet initial propre (MVP), comptez entre 2 et 4 mois de travail. Il faut faire les choses bien pour le marché de Montpellier.
C'est un document obligatoire sur le Google Play Store. Il explique aux utilisateurs de la région Occitanie quelles données vous récoltez et pourquoi. Je le remplis avec vous.
En optimisant le code. Des tâches de fond mal gérées vident la batterie, et l'utilisateur supprime l'application. On se pose, on réfléchit à l'architecture.
Oui, l'API de Google permet de bloquer l'usage si l'utilisateur de Montpellier a une version trop ancienne. Très pratique pour la sécurité.
La règle d'or : expliquer la valeur, puis demander. Si on demande accès à la caméra sans raison à l'ouverture, l'utilisateur de France refuse.
C'est quand l'application fige. C'est perçu comme un bug. Le point essentiel est d'optimiser la vitesse pour éviter que l'écran ne bloque.
Oui, les deux langages cohabitent. Si vous avez une vieille application à Montpellier, on peut l'améliorer progressivement en Kotlin.
J'intègre le design. Si vous n'avez pas de designer UI/UX, je collabore avec des experts qui créeront les écrans pour vous.
J'utilise des appareils physiques (Samsung, Pixel, Xiaomi) et des émulateurs couvrant un large spectre de tailles d'écrans.
Contactez-moi en bas de cette page. On organise un appel pour valider que votre idée tient la route techniquement.
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.