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, du concept à la publication sur l'App Store et Google Play.
En résumé : pour votre projet à Genève (203 856 habitants), vous travaillez directement avec moi, pas un intermédiaire. 12 ans d'expérience, 15+ applications livrées, et un processus transparent de A à Z.
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 Genève 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.
La maintenance d'une application recouvre trois choses différentes : corriger ce qui casse, suivre les changements des systèmes qui l'entourent, et faire évoluer le produit. Les deux premières ne sont pas optionnelles — sans elles, l'application finit par ne plus se lancer. La troisième se décide, se chiffre et se planifie séparément.
Oubliez le code une minute. Reprenons l'analogie de la voiture pour bien comprendre l'enjeu à Genève.
La vidange, ce sont les correctifs de sécurité. Vous ne voyez pas l'huile propre quand vous conduisez. Cela ne rend pas la voiture plus rapide. Mais si vous ne le faites pas, le moteur serre au milieu de l'autoroute. Dans une app, c'est ce qui protège les données de vos utilisateurs.
Le changement de pneus, ce sont les mises à jour de compatibilité OS. Quand Apple ou Google sortent une nouvelle version majeure de leur système, les routes changent. Si votre application garde ses vieux pneus, elle va déraper. Il faut adapter le code pour qu'il continue de rouler droit.
Le point essentiel : le prix dépend de la complexité technique sous le capot, pas du nombre de pages.
Mon rôle premier est de protéger votre budget. Saviez-vous qu’une grande partie des fonctionnalités d'une application ne sont jamais utilisées ?
Depuis Cannes, j'aide mes clients à éviter ce gaspillage énorme. Avec 12 ans d'expérience sur iOS et Android, je sais où l'argent doit aller. On coupe le superflu pour se concentrer sur ce qui apporte une vraie valeur à votre cible.
L'avantage clé : une application qui sort vite, qui teste le marché, et qui coûte le juste prix. Construisons d'abord l'essentiel.
Vous lancez votre projet à Genève.
Et vous vous demandez sûrement avec qui travailler pour concevoir votre application mobile.
C'est la première grande décision. Certains pensent que pour réussir, il faut absolument une grande agence au coin de la rue. D'autres croient qu'il faut sous-traiter à l'équipe la moins chère possible à l'étranger.
Les deux options ont de sérieux inconvénients.
Une grosse agence va assigner votre projet à un développeur junior que vous n'avez jamais rencontré. Une équipe offshore va vous livrer du code illisible, avec trois semaines de retard, sans aucune responsabilité.
Le facteur le plus important dans la réussite d'une application, ce n'est pas seulement le code. C'est la communication.
Genève est une ville d'organisations internationales et de finance, où l'application doit souvent passer une revue de sécurité avant d'exister. Autant le savoir dès le début : cela oriente le choix de l'hébergement, la façon de stocker les données et le temps à prévoir. Découvrir cette exigence au moment de livrer, c'est perdre un trimestre.
Ce que demande concrètement une revue de sécurité varie, mais quelques questions reviennent presque toujours : où sont physiquement stockées les données, qui y a accès, comment elles sont chiffrées au repos et en transit, comment les accès sont révoqués quand quelqu'un part, et ce qui se passe si un téléphone est perdu. Aucune de ces questions n'est difficile si l'architecture a été pensée pour y répondre. Toutes deviennent coûteuses si l'application a été écrite d'abord et auditée ensuite.
La localisation des données mérite une mention particulière, parce que la Suisse n'est pas dans l'Union européenne et a sa propre loi sur la protection des données, révisée récemment. Selon votre secteur et vos clients, l'hébergement en Suisse peut être une exigence ferme plutôt qu'une préférence. Cela change le choix du fournisseur, parfois le coût mensuel, et cela se décide avant d'écrire la première ligne — migrer une base de données d'un pays à un autre après le lancement est faisable mais désagréable.
Une revue de sécurité réclame des documents autant que du code, et c'est ce qui surprend le plus. On demande en général un schéma des flux de données, la liste nominative des services tiers utilisés et de ce qu'ils voient, la politique de conservation, et la procédure prévue en cas de fuite. Rien de tout cela ne s'improvise à la fin. Je le prépare pendant le développement plutôt qu'après, parce qu'un dossier réuni en catastrophe fait perdre plus de temps à la revue que le développement lui-même.
Genève a aussi un coût du travail élevé et un vivier de développeurs très demandé, ce qui explique une bonne partie des sollicitations que j'y reçois. Travailler avec quelqu'un basé en France sur un projet genevois est courant et fonctionne bien : même fuseau horaire, même langue, aucune contrainte de déplacement pour l'essentiel du travail. Il faut simplement traiter dès le devis les questions de facturation transfrontalière et de TVA, plutôt que de les découvrir à la première facture.
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 à Genève, il ne suffit pas d'attendre qu'un client vous appelle en criant. Il faut des capteurs de santé professionnels.
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 à Genève.
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 processus transparent, itératif, et sans surprise. Vous voyez l'application grandir chaque semaine.
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 du canton de Genève 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.
En résumé : on ne construit pas tout. On construit ce dont vos utilisateurs ont vraiment besoin.
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 Genève 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.
Immobilier, finance et événementiel supportent mal l'à-peu-près : une donnée périmée y vaut une donnée fausse. La maintenance de ces applications porte moins sur les plantages que sur la fraîcheur — la synchronisation qui décroche en silence, le flux extérieur qui change de format, la notification qui n'est plus délivrée.
Les enjeux de disponibilité et de précision varient énormément d'un marché à l'autre. Voici comment je sécurise les applications critiques de ces secteurs à Genève.
La vitesse d'affichage des photos et vidéos est la clé. L'application devient lourde si elle est mal maintenue. Je veille à la fluidité des galeries, à la précision millimétrique de la géolocalisation des biens sur la carte du canton de Genève, et à la stabilité parfaite des intégrations avec votre CRM immobilier existant. Une annonce qui ne s'affiche pas, c'est une vente perdue.
Ces questions demandent la même chose de plusieurs façons : à quoi sert la maintenance. La réponse est que les systèmes changent chaque année et que l'application, elle, ne change pas toute seule. Une application laissée tranquille dix-huit mois finit par ne plus se lancer, et la remettre debout coûte plus cher que de l'avoir suivie.
Parce que le logiciel pourrit avec le temps. Les téléphones évoluent, les systèmes changent. Sans maintenance, votre application accumule des bugs invisibles. À la fin, les utilisateurs fuient et l'investissement initial part en fumée.
L'expulsion. L'App Store et Google Play font régulièrement le ménage. Une application non mise à jour pendant plus d'un an risque la suppression pour protéger les utilisateurs. Tout simplement.
Oui. Apple et Android imposent de nouvelles règles de sécurité et de nouveaux formats d'écrans très régulièrement. Si vous ne mettez pas à jour le code de base, des écrans blancs vont apparaître sur les nouveaux téléphones du canton de Genève.
Le point essentiel : La plupart des gens désinstallent après un bug technique. En tuant les bugs pro-activement, on évite les avis 1 étoile. Et on intègre régulièrement les suggestions des utilisateurs pour viser les 5 étoiles.
Le ROI, c'est l'argent que vous ne perdez pas. C'est éviter une fuite de données RGPD, conserver l'argent investi dans la création, et ne pas perdre les ventes générées par une application qui fonctionne 24h/24.
Oui, si les fondations techniques ne sont pas totalement détruites. Un audit permet de trancher. En corrigeant les beaucoup de bugs qui causent la plupart des abandons, on ressuscite souvent un projet donné pour mort.
Pas de magie, que de l'industriel. Google Crashlytics pour les alertes de crash, Sentry pour remonter le fil des erreurs, et des pipelines d'intégration continue (CI/CD) pour déployer sans erreurs humaines.
C'est de la maintenance préventive. Je surveille les bibliothèques open source utilisées par l'application. Dès qu'une vulnérabilité est rendue publique (CVE), je patche le code et je pousse une mise à jour d'urgence.
L'audit profond d'une base de code prend des jours et ne peut pas être gratuit. En revanche, un premier échange de 30 minutes pour évaluer la surface du problème sur les stores, c'est offert et très instructif.
La maintenance soigne et renforce l'existant. La refonte, c'est raser la maison pour en construire une nouvelle. On ne passe à la refonte que quand la dette technique rend la maintenance plus coûteuse que le neuf.
Pendant que vous hésitez, vos concurrents à Genève 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 dans le canton de Genève.
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 exactement par où commencer. Sans engagement. Sans jargon technique.
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.