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.
Lyon est un véritable carrefour d'innovation en Auvergne-Rhône-Alpes.
Les idées fusent, les projets se montent, et la concurrence est rude. Quel que soit votre secteur d'activité, il y a de grandes chances que vos concurrents directs réfléchissent déjà à leur propre application mobile. Ou pire, qu'ils l'aient déjà lancée. 🚀
Dans un marché aussi dense, celui qui propose l'expérience la plus fluide gagne la partie.
En résumé : l'innovation n'est plus une option,
Beaucoup de porteurs de projet à Lyon perdent du temps à hésiter. Ils repoussent le développement de mois en mois. Mais le marché de votre pays n'attend pas.
Créer une application mobile, c'est assembler trois choses : ce que l'utilisateur voit et touche, un serveur qui garde et distribue les données quand plusieurs appareils doivent les partager, et les comptes qui permettent de publier sur les stores. Les mots techniques qu'on vous opposera recouvrent presque toujours l'une de ces trois briques. Aucune n'est optionnelle si l'application doit vivre.
Vous voulez lancer un projet numérique à Lyon. Vous rencontrez des développeurs, et soudain, ils vous parlent de frontend, de backend, d'API, de base de données.
Vous hochez la tête, mais en réalité, vous êtes perdu.
Oubliez le jargon technique. Construire une application mobile, c'est exactement comme ouvrir un restaurant en Auvergne-Rhône-Alpes. C'est une mécanique précise où chaque élément a un rôle vital.
Imaginons votre application comme ce fameux restaurant.
Le frontend, c'est la salle à manger. C'est la décoration, les tables, la présentation du menu, la musique d'ambiance. C'est l'application que vos utilisateurs téléchargent sur leur téléphone. Ce frontend doit être beau, accueillant et respecter des standards stricts, comme les Human Interface Guidelines d'Apple. Si la salle est laide, le client ne rentre pas.
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.
Travailler à distance ne pose pas de problème de qualité, il pose un problème d'organisation. La réponse tient en trois habitudes : un canal direct où vous m'écrivez sans passer par personne, une version installable toutes les deux semaines, et une note écrite après chaque décision. C'est ce qui remplace le fait d'être dans le même bureau, et ça fonctionne mieux que des réunions longues.
Vous n'avez pas besoin d'être dans le même bureau pour construire une excellente application.
Aujourd'hui, l'économie numérique de Lyon fonctionne sans frontières. Mais pour que le travail à distance soit efficace, il faut une organisation militaire. Le chaos technique coûte très cher.
L'avantage clé de mon approche, c'est la transparence absolue. Voici comment nous allons collaborer, même si des centaines ou des milliers de kilomètres nous séparent.
Commençons par les outils. Pas de boîtes noires avec moi.
Un site qui reçoit l'essentiel de son trafic depuis un téléphone et n'y enregistre presque aucune réservation n'a pas un problème de visibilité : il a un problème de parcours. Le cas se règle rarement en ajoutant des fonctionnalités. Il se règle en retirant des étapes entre le moment où quelqu'un arrive et celui où il peut réserver.
Rien ne vaut un exemple concret pour comprendre. Voici l'histoire d'une entreprise de services bien implantée.
Cette entreprise avait un site web classique. Les statistiques montraient que beaucoup de leur trafic provenait des téléphones portables. C'est énorme. Mais il y avait un problème de taille. Ils n'enregistraient absolument aucune réservation depuis ces appareils.
Leurs clients essayaient de prendre rendez-vous, se perdaient sur le site mobile, et abandonnaient.
Si le prix est votre seul critère, nous ne sommes probablement pas faits pour travailler ensemble, et il vaut mieux le dire tout de suite. Une application peu chère l'est rarement au total : un code écrit sans structure devient impossible à modifier, et la deuxième version coûte alors plus que la première. Ce que vous achetez, c'est la possibilité de faire évoluer l'application après le lancement.
Sur les ventes faites dans l'application, Apple et Google prélèvent entre 15 % et 30 % selon votre chiffre d'affaires annuel et le programme auquel vous êtes éligible. Ce calcul se fait avant de fixer vos prix, pas après le lancement.
Si le prix est votre seul et unique critère pour choisir un développeur à Lyon, nous ne sommes probablement pas faits pour travailler ensemble.
Ce n'est pas de l'arrogance. C'est de l'honnêteté.
Parlons de la vraie valeur des choses en France.
Santé, tourisme et commerce en ligne posent trois contraintes différentes à une même application. La santé impose l'hébergement certifié et le mode hors ligne. Le tourisme impose la rapidité et l'absence d'inscription pour un visiteur de passage. Le commerce impose un tunnel d'achat court. Le point commun : chacune de ces contraintes se décide avant la première maquette, pas après.
Le secteur de la santé ne pardonne aucune erreur. Créer une application médicale pour des patients ou des médecins en Auvergne-Rhône-Alpes, ce n'est pas juste coder une belle interface. C'est construire un coffre-fort numérique.
Il faut gérer le suivi des patients, la prise de rendez-vous, les rappels de médicaments et la messagerie sécurisée. Le respect absolu du RGPD et des directives de la CNIL est non négociable. On intègre donc des systèmes d'authentification biométrique stricts.
Ces questions portent sur la relation de travail plutôt que sur la technique : comment on communique, comment on paie, ce qui se passe si le résultat ne convient pas. Le fonctionnement est simple — un canal direct avec moi, une version installable toutes les deux semaines, un acompte à la commande puis un paiement mensuel qui suit l'avancement.
Notre collaboration se fait à une grande partie à distance via des appels vidéo. Travailler en distanciel est devenu la norme d'efficacité absolue. Fini les pertes de temps dans les transports. Pour les projets de grande envergure dépassant un certain budget, je peux me déplacer à Lyon pour animer des ateliers de lancement en personne. Mais au quotidien, nous communiquons via votre canal préféré (WhatsApp, Slack ou email), nous validons les designs ensemble, et nous faisons nos revues de projet via Google Meet, WhatsApp ou Telegram. C'est plus rapide, plus direct et beaucoup plus économique pour tout le monde.
Ce n'est absolument pas obligatoire. En réalité, je préfère largement commencer par un simple appel vidéo de quinze minutes. Beaucoup de clients passent des mois à rédiger des cahiers des charges de cinquante pages qui deviennent obsolètes dès la deuxième semaine de développement. Le facteur le plus important est de définir le problème principal que vous voulez résoudre en Auvergne-Rhône-Alpes. Ensuite, nous construisons ce cahier des charges ensemble, de manière agile, en nous basant sur les besoins réels des utilisateurs et non sur des théories.
J'ai livré plus de quinze projets d'envergure dans des secteurs très variés : la santé, le tourisme, l'e-commerce, la logistique et l'éducation. Même si je n'ai pas encore travaillé spécifiquement dans votre micro-niche, les principes fondamentaux de la création d'une application mobile sont totalement universels. Les standards de qualité restent les mêmes. Ce qui change, c'est votre logique d'affaires locale. Mon rôle est de comprendre cette logique métier lors de notre appel de découverte et de la traduire en une solution technique imparable pour vos clients.
Le paiement est divisé en trois étapes claires, sans aucune surprise. Généralement, c'est un acompte au démarrage pour bloquer le planning, une tranche au milieu du développement quand je vous livre une première version testable, et le solde à la livraison finale sur les stores. Pour les très gros projets de plusieurs mois, je lisse les paiements mensuellement. Tout est détaillé par écrit dans le devis initial, et je ne facture jamais d'heures cachées pour des petits ajustements de dernière minute.
Les démonstrations hebdomadaires rendent cette situation pratiquement impossible. Vous ne découvrez pas le produit fini six mois après la signature. Tous les quinze jours, je vous montre une version fonctionnelle. Vous donnez vos retours depuis Lyon, et je corrige le tir immédiatement. Si nous partons dans la mauvaise direction, nous le savons au bout de sept jours, pas à la fin de l'année. De plus, si lors de notre premier appel, je sens que vos attentes sont techniquement irréalisables, je vous le dirai honnêtement. Mieux vaut refuser un projet que de décevoir.
Oui, je reprends des projets développés par d'autres prestataires ou des équipes offshore. La première étape incontournable est un audit technique d'une semaine. On regarde sous le capot. Ensuite, je dresse un plan d'action strict : nous corrigeons d'abord les bugs critiques qui font fuir vos utilisateurs, nous consolidons l'architecture technique, puis seulement nous ajoutons vos nouvelles fonctionnalités. C'est souvent beaucoup plus rentable pour votre entreprise en France que de tout jeter pour recommencer à zéro.
Nous utilisons des canaux directs, asynchrones et sans friction. Pour les questions rapides au quotidien, c'est Slack. Vous pouvez m'écrire quand une idée vous vient. Pour valider l'interface visuelle, nous examinons les maquettes ensemble : vous laissez vos commentaires directement sur les écrans dessinés. Pour le code, tout est hébergé sur GitHub de manière transparente. Enfin, nous faisons un point d'étape vidéo en direct de trente minutes chaque semaine. Je m'adapte aux outils avec lesquels vos équipes à Lyon sont déjà à l'aise. L'objectif est l'efficacité absolue.
Je suis basé sur le fuseau horaire d'Europe centrale (CET) à Cannes. Pour mes clients européens, je suis pleinement disponible aux heures de bureau classiques, entre 10h et 18h. Si vous êtes situé sur un autre continent, je m'adapte avec souplesse. Pour les clients dans des fuseaux horaires proches, nous travaillons en temps réel total. Pour les clients plus éloignés, je m'adapte avec des horaires flexibles et des vidéos de mise à jour enregistrées. Mon temps de réponse moyen en semaine est toujours inférieur à quatre heures, où que vous soyez.
Oui, je propose des contrats mensuels ou annuels sur mesure. Ces contrats incluent les mises à jour obligatoires d'Apple et Google, la réparation des bugs silencieux et la surveillance des performances en direct. C'est le seul moyen de protéger votre investissement. Les statistiques le prouvent, la plupart des utilisateurs désinstallent une app après un seul plantage technique. Nous pouvons aussi y inclure une banque d'heures dédiée à la création de nouvelles petites fonctionnalités. Le coût tourne généralement autour de sensiblement du devis initial par an.
La première erreur est de vouloir construire trop de fonctionnalités d'un coup. Les données montrent qu’une grande partie des fonctionnalités sont ignorées par les utilisateurs. Commencez toujours léger. La deuxième erreur est de choisir son prestataire uniquement sur le prix. Un développement low-cost vous coûtera trois fois plus cher quand il faudra tout refaire à cause d'une architecture défaillante. La troisième erreur est de croire qu'une application est finie une fois publiée. L'absence de maintenance tue les meilleurs projets. Mon travail est de vous éviter ces trois pièges.
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.