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.
En résumé : pour votre projet à Lyon (515 695 habitants), en Auvergne-Rhône-Alpes, 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.
Google Play héberge plus de 2 millions d'applications.
Comment la vôtre va-t-elle sortir du lot à Lyon ?
Ce n'est pas avec un design moyen ou des bugs à répétition.
Les utilisateurs sont impitoyables.
Une application qui rame, et c'est la désinstallation immédiate.
L'avantage clé d'un développeur expert, c'est la maîtrise totale de cet environnement chaotique.
Android, c'est des milliers de tailles d'écrans différentes. Des processeurs qui varient du tout au tout.
Créer une application de développement Android à Lyon demande de la rigueur.
Il faut connaître les règles de Google. Les contraintes de la batterie. Les permissions toujours plus strictes.
Je m'occupe de tout ça pour vous.
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.
Il y a 12 ans, je lançais ma toute première application mobile. Depuis, les téléphones ont changé, mais mon métier est resté le même : transformer des idées en outils concrets.
Depuis mon bureau à Cannes, j'accompagne des entrepreneurs et des PME pour concevoir des applications iOS et Android qui ont un vrai sens. Je ne code pas juste pour coder. Je cherche à comprendre votre métier, vos utilisateurs et vos vrais besoins.
Mon objectif est simple. Créer une application que les gens auront envie d'utiliser tous les jours. Le point essentiel : on construit pour eux, pas pour nous. On en parle ?
À Lyon, beaucoup d'entreprises qui me contactent ont déjà une DSI ou un développeur interne. La bonne question n'est donc pas « qui fait tout », mais « qui fait quoi ». Je prends la partie mobile, votre équipe garde ce qu'elle connaît, et on écrit la frontière entre les deux avant de commencer.
Cette frontière tient en trois lignes. Vos serveurs et vos règles métier restent chez vous. L'application et la couche qui lui parle sont de mon côté. Et on se met d'accord dès la première semaine sur ce que chacun attend de l'autre — par écrit, pas oralement, parce que c'est exactement là que les projets à deux équipes se perdent.
Le deuxième critère compte autant et il est rarement posé : est-ce que votre équipe pourra reprendre le projet quand je ne serai plus là ? C'est le but, pas un accident. Le code est volontairement ennuyeux, parce que les astuces brillantes coûtent cher à relire. Le dépôt est à votre nom dès le premier jour, et il contient de quoi reconstruire l'application sans moi.
Un outil métier vit dix ans. Le prestataire qui l'a écrit, rarement. Un projet qui ne survit pas au départ de son auteur n'est pas terminé, il est en sursis.
Lyon est la ville française où je rencontre le plus d'entreprises qui ont déjà un logiciel métier et veulent le prolonger sur mobile. Ce n'est pas le même travail qu'une application partant de zéro : l'essentiel se joue sur l'API existante et sur ce qu'on accepte de ne pas porter. On commence toujours par cette liste-là, avant de dessiner le moindre écran.
La raison pour laquelle cette liste passe en premier est simple : une application mobile qui essaie de reproduire tout un logiciel de gestion échoue toujours. L'écran fait six pouces, l'utilisateur est debout, il a une main libre et trente secondes. Ce qui marche sur mobile, c'est trois ou quatre actions faites cinquante fois par jour — pointer une intervention, valider une livraison, consulter une fiche client, photographier un document. Le reste reste sur le poste de travail, et c'est très bien.
Le vrai risque technique n'est presque jamais l'application. C'est l'API. Beaucoup de logiciels métier ont une interface qui a été écrite pour un site web interne, sur un réseau d'entreprise rapide, avec des réponses énormes parce que la bande passante ne coûtait rien. Branchée sur un téléphone en 4G dans un parking souterrain, la même interface met huit secondes à répondre et l'application paraît cassée alors qu'elle fonctionne parfaitement. La première semaine d'un projet lyonnais part souvent là-dedans : mesurer ce que l'existant renvoie vraiment, et décider ce qu'on adapte côté serveur plutôt que de bricoler côté mobile.
Une question à poser avant tout le reste, et qui décide souvent du projet : à qui appartient l'accès à ce logiciel métier ? Si l'éditeur fournit une API documentée, tout va bien. S'il n'en fournit pas, ou s'il la facture au module, ou s'il refuse de l'ouvrir à un tiers, aucune application mobile ne contournera ça proprement — et les contournements existent, mais ils cassent à la première mise à jour de l'éditeur. Je pose la question au premier appel plutôt qu'au deuxième mois, parce que la réponse change le budget, le calendrier, et parfois la décision de faire ou non.
Lyon a aussi une forte présence de la santé et de la chimie, deux secteurs où l'hébergement des données n'est pas un choix libre. Si vos données relèvent de la santé, elles doivent être chez un hébergeur certifié, et cela se décide avant la première ligne de code, pas au moment de la mise en production. Je pose la question au premier rendez-vous, parce que la réponse change l'architecture entière.
Quand l'application se branche sur un logiciel existant, le premier mois se joue sur le serveur, pas sur l'écran. On mesure d'abord ce que l'existant renvoie vraiment, parce que c'est ça qui décide de ce qui est faisable — et du budget.
Et votre équipe a accès au dépôt depuis le premier jour, pas à la livraison.
Le travail à distance repose sur l'écrit plutôt que sur la réunion. Vous recevez une version installable toutes les deux semaines et un compte rendu de ce qui a changé ; les questions se traitent dans votre outil habituel, quand chacun est disponible. Cette façon de faire supprime les réunions de trois heures sans supprimer l'information — c'est même l'inverse, tout reste écrit et consultable.
Je travaille avec des clients partout, de la France jusqu'au Canada.
Peu importe que vous soyez basé à Lyon ou ailleurs, la méthode est la même.
L'avantage clé, c'est la communication asynchrone et transparente.
Pas besoin de réunions de trois heures qui ne mènent à rien.
On utilise des outils comme Slack, Trello ou Jira. Vous voyez exactement où j'en suis.
Chaque semaine, vous recevez une mise à jour sur votre téléphone Android.
Vous testez la nouvelle fonctionnalité directement depuis votre bureau à Lyon.
S'il y a un comportement bizarre sur un certain modèle de Samsung, vous me le signalez et je le corrige.
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 Auvergne-Rhône-Alpes.
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.
Considérez un budget Android comme une ligne de croissance plutôt que comme une dépense, parce que c'est ainsi qu'il se comporte. Quelqu'un sur internet vous codera quelque chose pour presque rien, et ce sera lent, peu sûr et impossible à faire évoluer. La vraie comparaison n'est pas un devis contre un autre, mais le coût de le construire deux fois contre une seule.
Sur les achats faits dans l'application, Google prélève 15 % sur le premier million de dollars de chiffre d'affaires annuel, puis 30 % au-delà. Le barème est publié par Google Play et s'applique à tous les éditeurs.
Quand on parle budget pour une application Android à Lyon, il faut changer de perspective.
Ce n'est pas une dépense. C'est un outil de croissance.
Vous pouvez trouver quelqu'un sur internet qui va vous coder un truc pour presque rien.
Spoiler : ça va être une catastrophe technique. Les termites dans une maison.
Le commerce, le transport et le tourisme sont trois secteurs où Android domine le parc réel — appareils d'entreprise, terminaux partagés, téléphones d'entrée de gamme. Ce n'est pas une préférence de goût : c'est ce qu'il y a dans les mains des utilisateurs. Cela change les priorités techniques, à commencer par la tenue sur de petits appareils anciens.
Ces questions portent sur ce qui fait qu'une application Android tient dans la durée : la batterie, les autorisations, les blocages d'interface, le formulaire de sécurité des données exigé par Google, et les appareils sur lesquels on teste vraiment. Ce sont des sujets d'ingénierie plus que de conception, et ce sont eux qui décident de la note laissée sur le store.
Pour un projet initial propre (MVP), comptez entre 2 et 4 mois de travail. Il faut faire les choses bien pour le marché de Lyon.
C'est un document obligatoire sur le Google Play Store. Il explique aux utilisateurs de la région Auvergne-Rhône-Alpes quelles données vous récoltez et pourquoi. Je le remplis avec vous.
En optimisant le code. Des tâches de fond mal gérées vident la batterie, et l'utilisateur supprime l'application. On se pose, on réfléchit à l'architecture.
Oui, l'API de Google permet de bloquer l'usage si l'utilisateur de Lyon a une version trop ancienne. Très pratique pour la sécurité.
La règle d'or : expliquer la valeur, puis demander. Si on demande accès à la caméra sans raison à l'ouverture, l'utilisateur de France refuse.
C'est quand l'application fige. C'est perçu comme un bug. Le point essentiel est d'optimiser la vitesse pour éviter que l'écran ne bloque.
Oui, les deux langages cohabitent. Si vous avez une vieille application à Lyon, on peut l'améliorer progressivement en Kotlin.
J'intègre le design. Si vous n'avez pas de designer UI/UX, je collabore avec des experts qui créeront les écrans pour vous.
J'utilise des appareils physiques (Samsung, Pixel, Xiaomi) et des émulateurs couvrant un large spectre de tailles d'écrans.
Contactez-moi en bas de cette page. On organise un appel pour valider que votre idée tient la route techniquement.
Un projet mobile lyonnais commence presque toujours par la même question, et elle n'est pas technique : qu'est-ce qu'on ne met pas dans l'application ?
En trente minutes, on peut y répondre assez précisément. On regarde ce que vos utilisateurs font debout, une main prise, en trente secondes — c'est ça qui va sur le téléphone, et le reste peut rester sur le poste de travail. On repère aussi tout de suite si votre logiciel existant peut être branché ou non, parce que c'est ce qui décide du budget.
Sans engagement. Si la conclusion est que vous n'avez pas besoin d'une application, je vous le dirai aussi.
En 30 minutes, vous saurez exactement par où commencer. Sans engagement. Sans jargon technique.
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.