Mickael Romaniello
30 minutes, sans slides, rien à préparer.
Mickael Romaniello
30 minutes, sans slides, rien à préparer.
12 ans d'expérience. 15+ applications livrées. Un seul interlocuteur dédié.
En résumé : maintenance application mobile à Monaco (39 242 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.
Votre application plante et personne ne vous le dit.
Vous pensez que tout va bien parce que votre boîte de réception de support client est vide à Monaco.
Spoiler : c'est une très mauvaise nouvelle.
La réalité, c'est que la plupart des utilisateurs qui rencontrent un bug ne le signalent jamais. Ils ne cherchent pas votre formulaire de contact. Ils suppriment l'application et passent à autre chose.
Pendant ce temps, vos concurrents à Monaco qui maintiennent activement leurs applications vous volent vos utilisateurs. Et le plus effrayant dans tout ça ? Vous ne vous en rendez même pas compte.
Sans outils de surveillance et sans maintenance, vous pilotez un avion les yeux bandés.
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 à Monaco 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.
Pas d'agence. Pas de commercial. Pas de chef de projet entre nous deux.
Quand vous travaillez avec moi, vous parlez directement à la personne qui construit votre application. Depuis 12 ans, je gère la création d'applications iOS et Android de A à Z depuis mon bureau à Cannes. Ça veut dire plus de réactivité, moins de blabla, et aucune mauvaise surprise sur la facture.
Le point essentiel : on gagne un temps fou. Je vous conseille, je conçois, et je développe avec une transparence totale. C'est aussi simple que ça.
Monaco est un marché minuscule et très exigeant, où l'application est souvent un service de plus offert à une clientèle qui en a déjà beaucoup. La barre est donc haute sur la finition : une animation qui saccade ou un texte mal aligné se remarque immédiatement, et coûte plus cher en crédibilité qu'en temps de développement.
Cette exigence de finition change la répartition du budget. Sur un projet ordinaire, on met l'essentiel de l'effort sur les fonctions et on soigne l'apparence avec ce qui reste. Sur un projet monégasque, l'équilibre s'inverse : moins de fonctions, mieux exécutées. Une application qui fait trois choses de façon irréprochable sert mieux ce marché qu'une qui en fait dix correctement, et cela se décide au moment du cadrage, pas à la fin quand il n'y a plus de temps.
La taille du marché a une conséquence directe sur le modèle économique, et il vaut mieux la regarder en face. Avec une population de quelques dizaines de milliers d'habitants, une application grand public purement monégasque n'atteindra jamais un volume qui rentabilise un développement mobile. Les projets qui tiennent sont donc d'un autre type : un outil pour une clientèle à forte valeur, une extension de service pour une entreprise établie, ou une application conçue dès le départ pour rayonner au-delà de la Principauté, sur la Côte d'Azur et l'Italie voisine.
Il faut enfin compter avec le calendrier des événements. Une application liée à la vie monégasque ne connaît pas une saison douce mais quelques pics très concentrés, où tout se joue sur peu de jours. Deux conséquences pratiques : l'infrastructure doit tenir une charge sans rapport avec sa moyenne annuelle, et l'application doit rester utilisable quand le réseau mobile sature — ce qui arrive précisément là où la foule est dense. Ça se prépare, ça se teste avant, et ça ne se corrige pas pendant.
La discrétion est le dernier trait spécifique. Une partie de la clientèle locale attend qu'une application n'expose pas ses données à des tiers, ne réclame pas d'autorisations dont elle n'a pas besoin, et ne dépende pas d'une constellation de services d'analyse et de publicité. Techniquement, cela veut dire moins de bibliothèques externes, des permissions demandées au moment où on s'en sert plutôt qu'au lancement, et une politique de confidentialité qui décrit ce que fait réellement l'application.
L'économie de Monaco évolue vite. Très vite.
Les entreprises locales ne peuvent plus se contenter d'un simple site web vieillissant. La transformation numérique est partout à Monaco. Et le mobile est devenu le centre de cette transformation. 🚀
En résumé : vos clients vivent avec leur téléphone dans la main.
C'est une réalité incontournable, l’essentiel du trafic web mondial provient des mobiles. Si votre entreprise à Monaco n'est pas facilement accessible sur leur écran d'accueil, elle n'existe presque plus aux yeux d'une grande partie du public.
J'accompagne les sociétés pour créer cette présence vitale. En France, des initiatives comme la France Num poussent d'ailleurs activement les TPE et PME à s'adapter aux nouveaux usages.
Ailleurs à Monaco, le constat est exactement le même. Les habitants de Monaco veulent pouvoir commander, réserver, ou s'informer en un clic depuis leur canapé ou dans les transports.
Avec Invent Better, la personne qui comprend votre projet est celle qui l'écrit. Pas de commercial, pas de chef de projet intermédiaire, pas de transmission entre trois équipes. Vous parlez au développeur, du premier appel jusqu'à la mise en ligne. Sur un premier produit, où l'essentiel se décide dans les six premières semaines, cette proximité vaut plusieurs semaines de calendrier.
Pour bien maintenir une application à Monaco, il ne suffit pas d'attendre qu'un client vous appelle en criant. Il faut des capteurs de santé professionnels.
Un projet se juge à ce qu'il produit, pas à ce qu'il promet. Toutes les deux semaines, vous recevez une version installable sur votre téléphone et une note écrite de ce qui a changé. C'est la seule protection réelle contre le silence de six mois.
La version est parfois très incomplète, et c'est voulu. Une application partielle qu'on peut ouvrir dit la vérité sur l'avancement ; un pourcentage dans un tableau de suivi ne dit rien du tout, et personne ne sait le contredire.
La note fait quelques lignes : ce qui est fait, ce qui a bougé par rapport à ce qui était prévu, et ce sur quoi j'attends une réponse de votre part. Ce dernier point est celui qui fait gagner le plus de temps, parce qu'une question posée par écrit se traite entre deux réunions.
Vous n'avez rien à installer de compliqué : un lien, et l'application arrive sur votre appareil. Vous pouvez la faire essayer à qui vous voulez dans votre entreprise à Monaco, sans me demander.
Et si une version manque, vous le voyez tout de suite. C'est le but.
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 de Monaco 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 Monaco 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 à Monaco.
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 de Monaco. Le système de notifications aux parents doit également rester parfaitement synchronisé à chaque mise à jour OS.
Ces questions portent toutes sur la même inquiétude : que se passe-t-il si ça tourne mal. La réponse tient à la façon dont le projet est monté. Le dépôt de code et les comptes des stores sont à votre nom dès le premier jour, donc rien ne dépend de ma présence. Un refus d'Apple est une étape ordinaire, pas une impasse : on corrige, on resoumet.
C'est la question qu'on ne pose pas à un indépendant et qu'on devrait poser en premier. Ma réponse tient en trois choses concrètes : le code est sur un dépôt à votre nom depuis le premier jour, les décisions sont écrites plutôt que gardées en tête, et les accès aux stores sont les vôtres. Un autre développeur peut reprendre sans moi. Ce n'est pas une promesse, c'est une organisation — et c'est vérifiable dès la première semaine.
À vous, entièrement, et dès le début plutôt qu'à la fin. Le dépôt est ouvert à votre nom, vous y avez accès pendant le développement, et vous n'avez rien à réclamer au moment de la livraison. Ça vaut aussi pour les maquettes et les comptes de stores. Le seul cas où ça se discute, c'est si vous voulez réutiliser une brique que j'ai écrite ailleurs — je le dis avant de l'utiliser, pas après.
On corrige et on resoumet, et c'est compris dans le projet. Un refus n'est pas un accident rare : Apple indique avoir examiné 7,77 millions de soumissions en 2024 et en avoir rejeté 1,93 million, soit près d'une sur quatre (rapport de transparence App Store 2024). Apple vérifie des dizaines de points, et les motifs les plus fréquents sont prévisibles — un compte de test qui ne fonctionne pas, une permission demandée sans explication, une fonction annoncée qui n'existe pas encore. Je les traite avant de soumettre, ce qui ne garantit rien mais évite l'essentiel. Vous n'avez pas à gérer l'échange avec le validateur.
Oui, et il faut le savoir avant de bâtir dessus. Apple et Google peuvent retirer une application qui enfreint leurs règles, et ils changent ces règles régulièrement. Les retraits brutaux touchent surtout des applications qui collectent des données sans le dire, copient une marque, ou n'ont pas été mises à jour depuis longtemps. C'est aussi pourquoi une présence web reste utile à côté : elle, personne ne peut vous la retirer.
Elle continue de fonctionner, et vous gardez tout ce qu'il faut pour la faire vivre : le code, les accès, les clés de signature, la documentation. Je fais une passation écrite plutôt qu'un simple transfert de fichiers — ce qui a été construit, pourquoi, où sont les pièges. C'est une demi-journée de travail qui évite des semaines de rétro-ingénierie à celui qui reprend, et je préfère qu'on se quitte comme ça.
Avant tout chiffrage, il faut une liste : le dépôt de code, les comptes App Store Connect et Google Play — à votre nom, pas à celui du prestataire —, la clé de signature Android, les accès à l'hébergement et à la base de données. La clé de signature est la pièce critique : sans elle, l'application ne peut plus être mise à jour, elle doit être republiée sous un autre identifiant et vous repartez de zéro en installations.
Là où vous décidez, et c'est une décision à prendre tôt parce qu'elle est coûteuse à défaire. Pour la plupart des projets, un hébergeur européen suffit et simplifie le RGPD. Pour des données de santé, l'hébergement doit être certifié, ce qui restreint le choix et pèse sur le budget — mieux vaut l'apprendre au premier appel qu'au moment de la mise en ligne. Dans tous les cas, les accès sont à votre nom.
Je le sais avant que vous receviez l'avis. Un outil de suivi des plantages remonte l'erreur avec l'appareil, la version du système et l'endroit exact du code — sans donnée personnelle. Sans ça, on découvre les bugs par les commentaires du store, c'est-à-dire trop tard et en public. C'est une des rares choses que je mets en place systématiquement, même sur un petit projet, parce que ça ne coûte presque rien et que ça change tout.
Côté code, oui : chaque version publiée est marquée, et on peut repartir de l'état exact d'une livraison. Côté stores, c'est plus nuancé — Google permet de suspendre le déploiement d'une version, Apple demande de publier une correction. La vraie protection est en amont : un déploiement progressif sur Android, une phase de test réelle, et des mises à jour assez petites pour qu'on sache ce qui a cassé.
Elle marche, puis elle se dégrade lentement, et un jour elle ne se lance plus. iOS sort une version majeure chaque septembre depuis 2013, Android chaque année, et chacune casse quelque chose. Une application laissée seule dix-huit mois demande souvent plus de travail à remettre debout que ce qu'aurait coûté son entretien. Vous pouvez arrêter — c'est votre choix et je ne vous ferai pas payer un abonnement pour rien — mais autant décider en le sachant.
Pendant que vous hésitez, vos concurrents à Monaco avancent.
Le monde du mobile va vite. Très vite. Aujourd'hui, l’essentiel du trafic web mondial provient des mobiles. Si vous repoussez sans cesse la création de votre application, d'autres prendront votre place à Monaco.
Mais attention, il ne faut pas confondre vitesse et précipitation. Lancer une application instable est la pire des stratégies.
En résumé : il faut faire vite, mais il faut surtout faire bien. ⏳
En 30 minutes, vous saurez par où commencer. Sans engagement.
Réservez un appel gratuit →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.