Mickael Romaniello
30 minutes, sans slides, rien à préparer.
Mickael Romaniello
30 minutes, sans slides, rien à préparer.
Du concept à la publication. Un expert dédié, 12 ans d'expérience.
En résumé : création d'application mobile à Lausanne (139 111 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.
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 à Lausanne 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 dans le canton de Vaud. 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 Lausanne, 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 Suisse 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 à Lausanne 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.
Vous êtes basé à Lausanne et vous avez une idée d'application mobile.
C'est le scénario classique. L'enthousiasme est à son maximum. Vous imaginez déjà votre logo sur les écrans d'accueil de tout le monde dans le canton de Vaud.
Le chemin entre une idée sur un bout de papier et une application publiée sur les stores est long. Très long.
Spoiler : la grande majorité des projets d'applications n'atteignent jamais la rentabilité. Pas parce que l'idée de départ était mauvaise, mais parce que l'exécution était brouillonne.
Une application ne se fabrique pas en écrivant du code au hasard. L'ordre est toujours le même : cadrer ce qu'elle doit faire, dessiner les écrans et les faire valider, développer par tranches essayables, puis publier. Chaque étape produit quelque chose que vous pouvez juger — un document, une maquette cliquable, une version installable — et jamais une promesse.
Comment fabrique-t-on concrètement une application à Lausanne ? Ce n'est pas un développeur enfermé dans une cave qui tape du code au hasard. C'est un processus industriel, créatif et rigoureux.
Si vous voulez que votre projet survive dans le canton de Vaud, il faut respecter quatre grandes étapes de fabrication.
Voici comment ça se passe vraiment.
La première étape, c'est la validation du concept. Quel problème précis votre application résout-elle ? Pour qui ? Il faut pouvoir répondre en une seule phrase. Si c'est trop vague, c'est mauvais signe. Spoiler : vouloir faire un couteau suisse est une erreur mortelle. Sachant qu’une grande partie des fonctionnalités d'une application ne sont jamais utilisées, nous allons élaguer votre idée pour ne garder que la valeur pure.
La peur numéro un, quand on lance un projet d'application, c'est de perdre le contrôle : on signe un devis, on confie son idée, et on n'entend plus rien pendant trois mois. Le fonctionnement décrit ici existe pour que ça n'arrive pas.
Trois règles, les mêmes sur chaque projet :
Vous testez l'application sur votre téléphone toutes les deux semaines.
Lausanne vit beaucoup autour de l'EPFL et des projets qui en sortent, et les demandes y sont souvent très techniques mais jeunes côté produit. Le travail utile n'est alors pas d'écrire du code : c'est de choisir les trois écrans qui prouvent que l'idée tient, et de laisser tout le reste pour plus tard.
Les projets issus de la recherche ont un profil reconnaissable. La partie difficile — l'algorithme, le modèle, le traitement du signal — est déjà résolue et souvent brillamment. Ce qui manque est tout ce qu'il y a autour : comment un utilisateur arrive dessus, ce qu'il comprend en dix secondes, ce qui se passe quand ça ne marche pas. C'est frustrant à entendre quand on a passé deux ans sur le cœur technique, mais c'est là que se joue l'adoption, et c'est en général là que je suis le plus utile.
Une conséquence pratique : sur ces projets, je conseille presque toujours de ne pas construire l'application complète tout de suite. Un démonstrateur qui fait une seule chose, bien, sur un seul système d'exploitation, montré à vingt vraies personnes, apprend plus en trois semaines qu'un développement de six mois. Et il coûte une fraction du prix, ce qui compte quand le financement vient d'une bourse ou d'un premier tour et qu'il faut montrer quelque chose avant le suivant.
Une question à régler avant la première ligne de code sur un projet issu d'un laboratoire : à qui appartient quoi. Le travail de recherche a souvent été financé par l'institution, parfois publié, parfois déjà lié à une convention de spin-off. Le code que j'écris par-dessus, lui, vous appartient — mais il repose sur une brique dont les droits ne sont pas toujours clairs. Ça se démêle en une conversation au départ, et ça devient très coûteux à démêler quand un investisseur pose la question au moment de la levée.
Lausanne partage avec Genève les contraintes suisses sur les données, et un projet issu du milieu académique ajoute souvent les siennes : données de recherche, parfois données de santé, parfois participants dont le consentement a été recueilli dans un cadre précis. Ces contraintes ne sont pas négociables et il vaut mieux les poser sur la table au premier rendez-vous, parce qu'elles déterminent où l'application a le droit d'envoyer quoi, et donc son architecture entière.
Une application peut être développée vite et pour peu cher. Ce qui coûte, c'est la suite : un code écrit sans structure devient impossible à modifier, et la moindre évolution demande de tout reprendre. Invent Better facture le travail qui rend la deuxième version possible — des tests, une architecture lisible, et un code qu'un autre développeur peut reprendre.
Il est tout à fait possible de développer une application très vite et pour vraiment pas cher.
Il suffit d'ignorer les règles de base, de copier-coller des morceaux de code trouvés sur internet, et de croiser les doigts pour que ça tienne. Le jour de la présentation à Lausanne, l'application aura l'air de fonctionner.
Mais le vernis va craquer très rapidement.
Dès que vous aurez plus de dix utilisateurs en même temps, le système va ralentir. Sur mobile, la patience est très courte. Et la lenteur, c'est perçu comme un bug.
Pire, l'application va planter en pleine nuit. Et là, l'utilisateur ne pardonne pas.
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 dans le canton de Vaud, sans me demander.
Et si une version manque, vous le voyez tout de suite. C'est le but.
Hériter d'une application développée au moins-disant coûte presque toujours plus cher que de l'avoir bien faite. Le motif est constant : pas de documentation, pas de tests, un code que personne ne peut reprendre, et des plantages quotidiens qui font tomber la note du store. La réparation commence par un audit, pas par une réécriture.
Parfois, le pire ennemi d'un projet, c'est une fausse bonne affaire. Le cas suivant revient assez souvent pour être décrit : une entreprise technologique en pleine panique.
Ils avaient hérité d'une application mobile développée par une équipe offshore très bon marché. Le résultat ? L'application plantait plusieurs fois par jour.
La note sur les stores était tombée très bas. Les utilisateurs laissaient des avis désastreux quotidiennement. Le PDG était prêt à tout jeter à la poubelle.
Il n'existe pas de prix unique pour une application mobile. Ce qui fixe le montant, c'est le périmètre : le nombre d'écrans, la nécessité d'un serveur et de comptes utilisateurs, et le fait de viser une plateforme ou deux. Un appel de cadrage donne une fourchette réelle.
Trois facteurs fixent le budget, plus deux dépenses fixes :
Éducation, restauration et logistique se ressemblent sur un point : l'application est utilisée debout, vite, souvent avec une seule main. Le cours se regarde dans les transports, la commande se prend au comptoir, la livraison se valide sur le quai. Chacune impose le mode hors ligne et une interface qui pardonne les gestes approximatifs.
Le marché mondial de l'apprentissage en ligne est en croissance chaque année. Et pour cause, les étudiants et les professionnels du canton de Vaud veulent se former partout, tout le temps.
Une bonne plateforme d'e-learning sur mobile, ce n'est pas juste des vidéos posées en vrac. C'est la possibilité de télécharger ces cours pour les regarder dans le métro de Lausanne sans utiliser son forfait de données.
Je construis des applications mobiles comme un artisan construit une maison. Avec des fondations solides.
J'exerce ce métier depuis 12 ans depuis Cannes, en concevant des applications iOS et Android faites pour durer. Je refuse le travail bâclé. L'avantage clé de cette méthode ? Votre application ne s'effondrera pas à la première mise à jour d'Apple ou de Google.
Je crée des outils propres, faciles à maintenir et prêts à évoluer avec votre PME ou votre startup. Un travail fait avec soin, c'est un investissement rentable sur le long terme.
Prêt à lancer votre application à Lausanne ?
Vous avez l'idée. Vous connaissez votre marché dans le canton de Vaud. Maintenant, il faut passer à l'action.
Mais pas n'importe comment. L'avantage clé de travailler ensemble, c'est la clarté. Je ne vous vendrai pas de fonctionnalités inutiles. Je ne vous ferai pas de grandes promesses sans lendemain.
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.