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.
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 à Genève 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 emballer un site web dans une application. C'est utiliser les outils du système pour obtenir une application qui démarre vite, fonctionne sans réseau et respecte les habitudes de la plateforme. La différence ne se voit pas sur une capture d'écran ; elle se voit à l'usage, au bout de quelques jours.
Beaucoup pensent qu'une application, c'est juste un site web mis dans une boîte.
C'est faux.
Développer pour Android, c'est utiliser les outils natifs de Google pour créer une expérience parfaite.
Aujourd'hui, le langage recommandé par Google s'appelle Kotlin. Il a remplacé Java.
C'est un langage moderne, rapide et sûr.
Pour l'interface, on utilise Jetpack Compose. Et on suit les règles visuelles strictes dictées par le Material Design de Google.
Le facteur le plus important, c'est de comprendre que le monde Android est un écosystème ouvert.
Contrairement au jardin fermé d'Apple, Android offre une liberté immense.
Vous avez accès à une infinité de matériels différents. Vous pouvez personnaliser le système en profondeur.
Vous pouvez même distribuer votre application en dehors du store officiel de Google si besoin.
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.
Je n'utilise pas de technologies obscures qui seront abandonnées dans deux ans.
J'utilise le standard de l'industrie, dicté par developer.android.com.
Le point essentiel, c'est la pérennité de votre code.
Voici ce que j'utilise sous le capot de votre application à Genève :
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 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 Genève.
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.
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.
Les outils internes, la santé et la restauration ont une raison commune de commencer par Android : le parc est fourni par l'entreprise, et il est presque toujours Android. Ces projets se déploient souvent sans passer par le store public, ce qui supprime le délai de revue et permet de corriger le jour même.
Certains secteurs d'activité ont tout à gagner à privilégier une stratégie Android native à Genève.
Ces questions portent sur la diffusion et la sécurité : ouvrir progressivement plutôt que d'un coup, distribuer hors du store, couvrir la voiture ou la télévision, suivre les performances après le lancement. Le point important est qu'Android permet de sortir par étapes — quelques testeurs, un groupe fermé, puis le public — et que c'est la meilleure protection contre une mauvaise version.
Souvent, oui, de sensiblement. Les outils de dev sont gratuits. Mais attention, la fragmentation des appareils à Genève peut augmenter le temps de test.
C'est un déploiement progressif. On lance d'abord l'application à la plupart des utilisateurs de Suisse. S'il n'y a pas de crash majeur remonté par Crashlytics, on augmente. C'est une question de logique et de sécurité.
Oui, c'est une excellente façon de garder votre application visible pour vos utilisateurs dans la région Genève.
Oui, c'est l'avantage clé d'Android. On peut installer une application via un simple fichier (APK). Idéal pour des outils internes à Genève.
L'essentiel de mon expertise est sur mobile et tablette. Mais l'architecture de base permet d'envisager ces extensions à terme.
J'utilise des outils comme Proguard pour masquer le code, et je sécurise toutes les communications avec vos serveurs de Genève.
Moins qu'Apple (beaucoup de rejets au premier envoi chez la pomme). Mais leurs règles sur la vie privée sont devenues très strictes.
Centrale. On applique le Material Design 3. L'application s'adaptera même aux couleurs du système de l'utilisateur.
Nous utilisons Google Analytics for Firebase et la Google Play Console pour analyser les usages à Genève.
Oui, je suis indépendant. Vous parlez directement au technicien qui code votre projet pour Genève. Pas d'intermédiaire.
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.