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.
Votre application dépend de code que vous n'avez pas écrit.
Une application moderne s'appuie sur des bibliothèques et des services extérieurs : l'envoi des notifications, le paiement, les cartes, la connexion, la mesure d'audience. Chacun est maintenu par quelqu'un d'autre, avec son propre calendrier, ses propres changements de règles, et parfois sa propre fin de vie.
C'est là que casse une application qu'on croyait tranquille. Le code n'a pas bougé, l'entreprise de Montpellier n'a rien demandé, et pourtant la connexion ne fonctionne plus parce qu'un service extérieur a changé sa façon de faire.
Suivre ces dépendances est une part du travail de maintenance qu'on voit rarement venir, et qu'on paie toujours.
Une maintenance n'est pas une réserve d'heures dans laquelle on pioche. C'est une surveillance en continu, un délai de réponse convenu à l'avance, et un point régulier où l'on décide ensemble de ce qui se corrige maintenant et de ce qui attend. Sans ces trois éléments, la maintenance devient une facture qu'on subit.
La surveillance tourne toute seule. Les plantages remontent automatiquement, avec l'appareil, la version du système et l'endroit exact où l'application s'est arrêtée. C'est ce qui permet de découvrir un problème avant que vos utilisateurs à Montpellier n'aient à le signaler — et la plupart ne le signalent jamais, ils désinstallent.
Le délai de réponse est écrit dans le contrat, et il n'est pas le même pour tout. Une application qui ne se lance plus se traite le jour même. Un affichage de travers peut attendre la prochaine version.
Le point régulier, enfin, est celui qu'on saute quand tout va bien, et c'est une erreur. C'est là qu'on regarde ce qui vient : la version du système qui sort à l'automne, la bibliothèque qui ne sera plus maintenue, le service extérieur qui change ses règles. Anticiper coûte quelques heures ; réagir coûte une version d'urgence.
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 qui plante et dont la note s'effondre n'a presque jamais un seul problème : elle en a plusieurs, dont deux ou trois font l'essentiel des plantages. C'est pour ça que la première étape est la mesure et non la réécriture. Corriger les quelques causes majoritaires ramène la stabilité, et la note remonte ensuite d'elle-même.
Il y a un an, une entreprise locale d'Occitanie m'a contacté en urgence. Leur application plantait plusieurs fois par jour. La note sur les stores était tombée très bas. Les avis négatifs pleuvaient et le PDG était à deux doigts de débrancher purement et simplement le projet.
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 tournent sur des appareils partagés et souvent anciens, ce qui rend la maintenance moins spectaculaire et plus constante. Les problèmes viennent rarement d'un bug franc : ils viennent d'une version du système qui change une autorisation, ou d'un appareil trop vieux pour la dernière bibliothèque.
La survie d'une application sur le long terme dépend de sa capacité à encaisser les usages spécifiques de son secteur à Montpellier.
L'optimisation du contenu est vitale. Les vidéos de cours et les documents lourds peuvent faire exploser le poids de l'application avec le temps. Je surveille la performance du streaming vidéo et la fiabilité du téléchargement hors-ligne pour les étudiants d'Occitanie. Le système de notifications aux parents doit également rester parfaitement synchronisé à chaque mise à jour OS.
Ces questions portent sur le fonctionnement au quotidien : reprendre le code de quelqu'un d'autre, travailler à distance, joindre quelqu'un le week-end, tenir un pic de saison. Reprendre une application existante commence toujours par un audit — je la reconstruis depuis le dépôt, sans aide. Le temps que ça prend est déjà une réponse sur l'état du code.
C'est mon quotidien. Beaucoup de mes clients arrivent avec un code existant. Je ne juge pas le travail passé, je l'audite, je le documente, je le stabilise. C'est une opération chirurgicale pour remettre le projet sur les rails.
Oui, beaucoup de mon activité est gérée à distance avec des clients dans tout le pays. Le code est sur le cloud, les outils de monitoring aussi. On se synchronise en visio, de façon bien plus efficace qu'en réunion physique.
Pour les clients bénéficiant du niveau Premium avec SLA prioritaire, les alertes Crashlytics me parviennent en direct 7j/7. S'il y a un crash bloquant les revenus, je me connecte et je déploie un hotfix immédiat.
Directement et sans intermédiaire. Pas de chef de projet qui fait barrage. Vous avez accès à un outil de suivi partagé (Trello/Jira), et nous faisons un point mensuel stratégique. La communication est claire et sans jargon technique.
L'avantage clé : je garantis la transparence absolue. Vous avez un accès direct aux outils de monitoring. S'il y a un bug de régression causé par une de mes mises à jour, je le corrige immédiatement à mes frais.
La sécurité logicielle demande de l'engagement, mais je ne prends pas mes clients en otage. On fonctionne généralement sur des engagements annuels avec des bilans trimestriels pour ajuster le volume d'heures aux besoins réels d'Occitanie.
Je regarde les données brutes : temps d'ouverture de l'application, temps de réponse de la base de données, taux d'utilisateurs sans crash (qui doit rester le plus haut possible). C'est mathématique et indiscutable.
Je suis expert natif (Swift/Kotlin) et Flutter. Pour Flutter, c'est un grand oui. Pour React Native ou les technologies hybrides web (Cordova, Ionic), je vous réorienterai vers des confrères spécialisés pour garantir la meilleure qualité.
Un audit profond prend entre 3 et 5 jours ouvrés selon la taille de l'application. Je livre un rapport écrit détaillé qui classe les urgences en trois catégories : rouge (sécurité/crash), orange (performance) et vert (détails UX).
On anticipe. Si vous faites du e-commerce avant Noël, on fait des tests de charge en novembre. On optimise les requêtes serveurs et on gèle les mises à jour non essentielles pour garantir une stabilité sans faille pendant le pic.
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.