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.
Avant de parler d'application, une question vaut la peine d'être posée : est-ce qu'il vous en faut une ?
Beaucoup de projets à Montpellier n'ont pas besoin d'être installés. Un site qui marche bien sur téléphone fait souvent le même travail, coûte moins cher, et ne demande à personne d'aller chercher quoi que ce soit dans un store.
L'application se justifie quand il faut fonctionner sans réseau, utiliser l'appareil photo ou la position en continu, envoyer des notifications, ou quand vos utilisateurs reviennent plusieurs fois par semaine. Si rien de tout ça n'est vrai, je le dis au premier appel.
Quand elle se justifie, en revanche, elle fait des choses qu'aucun site ne fera. C'est de ça que parle cette page.
Une application n'est pas seulement le fichier qu'on installe. Ce que vous achetez, c'est un ensemble de choses qui doivent toutes être à votre nom : le code, les comptes des stores, les clés qui permettent de publier, les maquettes et la documentation. Il suffit qu'une seule manque pour que vous ne soyez plus libre de changer de prestataire.
Le code d'abord. Il vit dans un dépôt qui vous appartient dès le premier jour, pas à la livraison. Vous y voyez l'avancement en temps réel, et n'importe quel développeur peut le reprendre.
Les comptes ensuite, et c'est le piège le plus courant du secteur. Le compte App Store Connect et le compte Google Play doivent être ouverts au nom de votre entreprise à Montpellier, avec vos identifiants. Quand ils sont au nom du prestataire, votre application ne vous appartient plus vraiment.
Les clés de signature, enfin. Ce sont elles qui prouvent aux stores qu'une mise à jour vient bien de vous. Sans la clé d'origine, une application Android ne peut plus être mise à jour : il faut la republier sous un autre identifiant, et vous perdez vos installations et vos avis.
Le reste — maquettes, textes des fiches, documentation — se transmet aussi. Une prestation qui ne prévoit pas ça vous laisse un logiciel sans les clés.
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.
Un site qui reçoit l'essentiel de son trafic depuis un téléphone et n'y enregistre presque aucune réservation n'a pas un problème de visibilité : il a un problème de parcours. Le cas se règle rarement en ajoutant des fonctionnalités. Il se règle en retirant des étapes entre le moment où quelqu'un arrive et celui où il peut réserver.
Rien ne vaut un exemple concret pour comprendre. Voici l'histoire d'une entreprise de services bien implantée.
Cette entreprise avait un site web classique. Les statistiques montraient que beaucoup de leur trafic provenait des téléphones portables. C'est énorme. Mais il y avait un problème de taille. Ils n'enregistraient absolument aucune réservation depuis ces appareils.
Leurs clients essayaient de prendre rendez-vous, se perdaient sur le site mobile, et abandonnaient.
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.
Éducation, restauration et logistique se ressemblent sur un point : l'application est utilisée debout, vite, souvent avec une seule main. Le cours se regarde dans les transports, la commande se prend au comptoir, la livraison se valide sur le quai. Chacune impose le mode hors ligne et une interface qui pardonne les gestes approximatifs.
Le marché mondial de l'apprentissage en ligne est en croissance chaque année. Et pour cause, les étudiants et les professionnels d'Occitanie veulent se former partout, tout le temps.
Une bonne plateforme d'e-learning sur mobile, ce n'est pas juste des vidéos posées en vrac. C'est la possibilité de télécharger ces cours pour les regarder dans le métro de Montpellier sans utiliser son forfait de données.
Ces questions portent sur la relation de travail plutôt que sur la technique : comment on communique, comment on paie, ce qui se passe si le résultat ne convient pas. Le fonctionnement est simple — un canal direct avec moi, une version installable toutes les deux semaines, un acompte à la commande puis un paiement mensuel qui suit l'avancement.
Notre collaboration se fait à une grande partie à distance via des appels vidéo. Travailler en distanciel est devenu la norme d'efficacité absolue. Fini les pertes de temps dans les transports. Pour les projets de grande envergure dépassant un certain budget, je peux me déplacer à Montpellier pour animer des ateliers de lancement en personne. Mais au quotidien, nous communiquons via votre canal préféré (WhatsApp, Slack ou email), nous validons les designs ensemble, et nous faisons nos revues de projet via Google Meet, WhatsApp ou Telegram. C'est plus rapide, plus direct et beaucoup plus économique pour tout le monde.
Ce n'est absolument pas obligatoire. En réalité, je préfère largement commencer par un simple appel vidéo de quinze minutes. Beaucoup de clients passent des mois à rédiger des cahiers des charges de cinquante pages qui deviennent obsolètes dès la deuxième semaine de développement. Le facteur le plus important est de définir le problème principal que vous voulez résoudre en Occitanie. Ensuite, nous construisons ce cahier des charges ensemble, de manière agile, en nous basant sur les besoins réels des utilisateurs et non sur des théories.
J'ai livré plus de quinze projets d'envergure dans des secteurs très variés : la santé, le tourisme, l'e-commerce, la logistique et l'éducation. Même si je n'ai pas encore travaillé spécifiquement dans votre micro-niche, les principes fondamentaux de la création d'une application mobile sont totalement universels. Les standards de qualité restent les mêmes. Ce qui change, c'est votre logique d'affaires locale. Mon rôle est de comprendre cette logique métier lors de notre appel de découverte et de la traduire en une solution technique imparable pour vos clients.
Le paiement est divisé en trois étapes claires, sans aucune surprise. Généralement, c'est un acompte au démarrage pour bloquer le planning, une tranche au milieu du développement quand je vous livre une première version testable, et le solde à la livraison finale sur les stores. Pour les très gros projets de plusieurs mois, je lisse les paiements mensuellement. Tout est détaillé par écrit dans le devis initial, et je ne facture jamais d'heures cachées pour des petits ajustements de dernière minute.
Les démonstrations hebdomadaires rendent cette situation pratiquement impossible. Vous ne découvrez pas le produit fini six mois après la signature. Tous les quinze jours, je vous montre une version fonctionnelle. Vous donnez vos retours depuis Montpellier, et je corrige le tir immédiatement. Si nous partons dans la mauvaise direction, nous le savons au bout de sept jours, pas à la fin de l'année. De plus, si lors de notre premier appel, je sens que vos attentes sont techniquement irréalisables, je vous le dirai honnêtement. Mieux vaut refuser un projet que de décevoir.
Oui, je reprends des projets développés par d'autres prestataires ou des équipes offshore. La première étape incontournable est un audit technique d'une semaine. On regarde sous le capot. Ensuite, je dresse un plan d'action strict : nous corrigeons d'abord les bugs critiques qui font fuir vos utilisateurs, nous consolidons l'architecture technique, puis seulement nous ajoutons vos nouvelles fonctionnalités. C'est souvent beaucoup plus rentable pour votre entreprise en France que de tout jeter pour recommencer à zéro.
Nous utilisons des canaux directs, asynchrones et sans friction. Pour les questions rapides au quotidien, c'est Slack. Vous pouvez m'écrire quand une idée vous vient. Pour valider l'interface visuelle, nous examinons les maquettes ensemble : vous laissez vos commentaires directement sur les écrans dessinés. Pour le code, tout est hébergé sur GitHub de manière transparente. Enfin, nous faisons un point d'étape vidéo en direct de trente minutes chaque semaine. Je m'adapte aux outils avec lesquels vos équipes à Montpellier sont déjà à l'aise. L'objectif est l'efficacité absolue.
Je suis basé sur le fuseau horaire d'Europe centrale (CET) à Cannes. Pour mes clients européens, je suis pleinement disponible aux heures de bureau classiques, entre 10h et 18h. Si vous êtes situé sur un autre continent, je m'adapte avec souplesse. Pour les clients dans des fuseaux horaires proches, nous travaillons en temps réel total. Pour les clients plus éloignés, je m'adapte avec des horaires flexibles et des vidéos de mise à jour enregistrées. Mon temps de réponse moyen en semaine est toujours inférieur à quatre heures, où que vous soyez.
Oui, je propose des contrats mensuels ou annuels sur mesure. Ces contrats incluent les mises à jour obligatoires d'Apple et Google, la réparation des bugs silencieux et la surveillance des performances en direct. C'est le seul moyen de protéger votre investissement. Les statistiques le prouvent, la plupart des utilisateurs désinstallent une app après un seul plantage technique. Nous pouvons aussi y inclure une banque d'heures dédiée à la création de nouvelles petites fonctionnalités. Le coût tourne généralement autour de sensiblement du devis initial par an.
La première erreur est de vouloir construire trop de fonctionnalités d'un coup. Les données montrent qu’une grande partie des fonctionnalités sont ignorées par les utilisateurs. Commencez toujours léger. La deuxième erreur est de choisir son prestataire uniquement sur le prix. Un développement low-cost vous coûtera trois fois plus cher quand il faudra tout refaire à cause d'une architecture défaillante. La troisième erreur est de croire qu'une application est finie une fois publiée. L'absence de maintenance tue les meilleurs projets. Mon travail est de vous éviter ces trois pièges.
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.