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 dédié.
En résumé : je construis des applications iOS et Android pour des clients à Luxembourg (128,514 habitants) et partout. Un seul interlocuteur, 12 ans d'expérience, livraison du concept à la publication en 8 à 16 semaines.
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 ?
Google Play héberge plus de 2 millions d'applications.
Comment la vôtre va-t-elle sortir du lot à Luxembourg?
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 à Luxembourg 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.
Souvent, on me demande s'il faut commencer par iOS ou par Android pour un projet à Luxembourg.
La réponse dépend de votre cible et de votre budget.
L'avantage clé d'Android, c'est sa portée massive.
Surtout dans les marchés émergents ou pour le grand public.
Mais il y a une différence fondamentale avec Apple.
Apple contrôle tout. Ils ont une vingtaine de modèles d'iPhone en circulation. C'est facile à tester.
Android, c'est le grand ouest.
Google indique qu'il y a plus de 24 000 modèles d'appareils Android actifs.
Certains ont des écrans minuscules. D'autres tournent sur des versions Android vieilles de cinq ans.
Cette fragmentation rend les tests beaucoup plus complexes et coûteux.
Il faut s'assurer que l'application ne plante pas sur un téléphone bas de gamme vieux de quatre ans, tout en exploitant la puissance du dernier Samsung Galaxy.
Cependant, Android est souvent le meilleur choix pour démarrer si vous faites du B2B dans la région Luxembourg.
Par exemple, pour équiper vos livreurs ou vos techniciens sur le terrain avec des tablettes durcies peu coûteuses.
Dans ce cas, l'écosystème ouvert d'Android est imbattable.
Luxembourg est petit, riche et très réglementé, et la plupart des projets mobiles y touchent de près ou de loin à la finance. Cela veut dire une revue de conformité, des exigences de traçabilité, et une tolérance nulle pour un bug d'affichage sur un montant. On développe plus lentement et on teste beaucoup plus.
Le bug d'affichage sur un montant est l'exemple que je donne toujours, parce qu'il illustre bien la différence de culture. Sur une application grand public, un chiffre arrondi de travers est un défaut mineur qu'on corrige à la prochaine version. Sur une application financière, c'est une perte de confiance immédiate et parfois un problème réglementaire. La parade est technique et connue — on ne stocke jamais de l'argent dans un nombre à virgule flottante, on travaille en unités entières — mais elle doit être posée au début, parce que la corriger après veut dire migrer les données existantes.
La traçabilité impose sa propre discipline. Dans un contexte réglementé, il faut souvent pouvoir répondre des mois plus tard à la question « qui a fait quoi, quand, depuis quel appareil ». Cela veut dire un journal d'événements qui ne s'efface pas, des modifications qui s'ajoutent au lieu d'écraser, et une politique de conservation décidée à l'avance plutôt qu'improvisée. C'est du travail invisible pour l'utilisateur et c'est une part réelle du budget.
Le multilinguisme luxembourgeois est le dernier point, et il est moins simple qu'il n'y paraît. Français, allemand, luxembourgeois et anglais coexistent selon les contextes et les publics. Il est rare qu'un projet ait besoin des quatre, mais il est fréquent qu'il en faille trois, et il est essentiel de décider lesquelles au départ : la place réservée aux textes dans les écrans dépend de la langue la plus longue, et l'allemand gagne presque toujours ce concours.
L'économie de Luxembourg évolue vite. Très vite.
Les entreprises locales ne peuvent plus se contenter d'un simple site web vieillissant. La transformation numérique est partout dans la Luxembourg. Et le mobile est devenu le centre de cette transformation. 🚀
En résumé: vos clients vivent avec leur téléphone dans la main.
C'est une réalité incontournable, l’essentiel du trafic web mondial provient des mobiles. Si votre entreprise à Luxembourg n'est pas facilement accessible sur leur écran d'accueil, elle n'existe presque plus aux yeux d'une grande partie du public.
J'accompagne les sociétés pour créer cette présence vitale. En France, des initiatives comme la France Num poussent d'ailleurs activement les TPE et PME à s'adapter aux nouveaux usages.
Ailleurs dans votre Luxembourg, le constat est exactement le même. Les habitants de Luxembourg veulent pouvoir commander, réserver, ou s'informer en un clic depuis leur canapé ou dans les transports.
Chez Invent Better, vous recevez une version installable toutes les deux semaines, même incomplète. C'est la différence entre suivre un projet et attendre un projet. Vous avez accès au dépôt de code depuis le premier jour, et chaque décision est écrite plutôt que retenue de mémoire. Un désaccord se découvre au bout de deux semaines, pas à la recette finale.
Le développement informatique est souvent perçu comme une boîte noire angoissante.
Dans beaucoup de projets, vous signez un cahier des charges, vous payez un acompte important, et vous attendez. Pendant des mois, vous n'avez que de vagues nouvelles. Des promesses par email. Des "faites-nous confiance, ça avance".
Et le jour de la grande démonstration finale à Luxembourg... c'est la douche froide. Le produit ne ressemble pas à ce que vous aviez en tête. Mais il est trop tard, et le budget est épuisé.
Le facteur le plus important: avec moi, la boîte noire n'existe pas. Tout est ouvert, tout est transparent.
La pire erreur, c'est de coder pendant 6 mois sans jamais rien tester en conditions réelles.
On se pose. On respire.
Voici comment on travaille ensemble pour lancer votre application à Luxembourg.
D'abord, on définit le périmètre. On coupe tout ce qui ne sert à rien. On garde l'essentiel.
Ensuite, je développe. Je vous livre des versions de test régulièrement sur votre téléphone.
Mais l'étape cruciale sur Android, c'est la publication sur le Google Play Store.
Ce n'est plus un bouton magique.
Google demande désormais à ce que 20 testeurs différents utilisent votre application pendant 14 jours consécutifs avant de pouvoir la rendre publique.
Le facteur le plus important est d'anticiper ce délai.
Pendant cette phase, on remplit le formulaire de sécurité des données. On prouve à Google que votre application respecte la vie privée.
Une fois validée, on ne la lance pas à beaucoup d’un coup.
On fait ce qu'on appelle un "Staged Rollout".
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 Luxembourg.
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.
L'application devait être aussi fluide sur un Xiaomi bas de gamme vieux de cinq ans que sur le dernier Samsung Galaxy S.
J'ai reconstruit l'interface avec Jetpack Compose, le nouvel outil de design de Google.
Le résultat ? Un code beaucoup plus léger et robuste.
Nous avons lancé l'application à Luxembourg via un déploiement progressif (Staged Rollout) sur la Google Play Console.
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.
Quand on parle budget pour une application Android à Luxembourg, 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.
L'application va ramer sur la moitié des téléphones de vos clients de Luxembourg. Les bugs vont s'accumuler. Vous perdrez votre crédibilité.
C'est la question qu'on ne pose pas à un indépendant et qu'on devrait poser en premier. Ma réponse tient en trois choses concrètes : le code est sur un dépôt à votre nom depuis le premier jour, les décisions sont écrites plutôt que gardées en tête, et les accès aux stores sont les vôtres. Un autre développeur peut reprendre sans moi. Ce n'est pas une promesse, c'est une organisation — et c'est vérifiable dès la première semaine.
À vous, entièrement, et dès le début plutôt qu'à la fin. Le dépôt est ouvert à votre nom, vous y avez accès pendant le développement, et vous n'avez rien à réclamer au moment de la livraison. Ça vaut aussi pour les maquettes et les comptes de stores. Le seul cas où ça se discute, c'est si vous voulez réutiliser une brique que j'ai écrite ailleurs — je le dis avant de l'utiliser, pas après.
On corrige et on resoumet, et c'est compris dans le projet. Un refus n'est pas un accident rare : Apple vérifie des dizaines de points, et les motifs les plus fréquents sont prévisibles — un compte de test qui ne fonctionne pas, une permission demandée sans explication, une fonction annoncée qui n'existe pas encore. Je les traite avant de soumettre, ce qui ne garantit rien mais évite l'essentiel. Vous n'avez pas à gérer l'échange avec le validateur.
Oui, et il faut le savoir avant de bâtir dessus. Apple et Google peuvent retirer une application qui enfreint leurs règles, et ils changent ces règles régulièrement. Les retraits brutaux touchent surtout des applications qui collectent des données sans le dire, copient une marque, ou n'ont pas été mises à jour depuis longtemps. C'est aussi pourquoi une présence web reste utile à côté : elle, personne ne peut vous la retirer.
Elle continue de fonctionner, et vous gardez tout ce qu'il faut pour la faire vivre : le code, les accès, les clés de signature, la documentation. Je fais une passation écrite plutôt qu'un simple transfert de fichiers — ce qui a été construit, pourquoi, où sont les pièges. C'est une demi-journée de travail qui évite des semaines de rétro-ingénierie à celui qui reprend, et je préfère qu'on se quitte comme ça.
Avant tout chiffrage, il faut une liste : le dépôt de code, les comptes App Store Connect et Google Play — à votre nom, pas à celui du prestataire —, la clé de signature Android, les accès à l'hébergement et à la base de données. La clé de signature est la pièce critique : sans elle, l'application ne peut plus être mise à jour, elle doit être republiée sous un autre identifiant et vous repartez de zéro en installations.
Là où vous décidez, et c'est une décision à prendre tôt parce qu'elle est coûteuse à défaire. Pour la plupart des projets, un hébergeur européen suffit et simplifie le RGPD. Pour des données de santé, l'hébergement doit être certifié, ce qui restreint le choix et pèse sur le budget — mieux vaut l'apprendre au premier appel qu'au moment de la mise en ligne. Dans tous les cas, les accès sont à votre nom.
Je le sais avant que vous receviez l'avis. Un outil de suivi des plantages remonte l'erreur avec l'appareil, la version du système et l'endroit exact du code — sans donnée personnelle. Sans ça, on découvre les bugs par les commentaires du store, c'est-à-dire trop tard et en public. C'est une des rares choses que je mets en place systématiquement, même sur un petit projet, parce que ça ne coûte presque rien et que ça change tout.
Côté code, oui : chaque version publiée est marquée, et on peut repartir de l'état exact d'une livraison. Côté stores, c'est plus nuancé — Google permet de suspendre le déploiement d'une version, Apple demande de publier une correction. La vraie protection est en amont : un déploiement progressif sur Android, une phase de test réelle, et des mises à jour assez petites pour qu'on sache ce qui a cassé.
Elle marche, puis elle se dégrade lentement, et un jour elle ne se lance plus. iOS sort une version majeure chaque septembre, Android chaque année, et chacune casse quelque chose. Une application laissée seule dix-huit mois demande souvent plus de travail à remettre debout que ce qu'aurait coûté son entretien. Vous pouvez arrêter — c'est votre choix et je ne vous ferai pas payer un abonnement pour rien — mais autant décider en le sachant.
Prêt à lancer votre application à Luxembourg?
Vous avez l'idée. Vous connaissez votre marché dans la Luxembourg. 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.
On se pose. On respire.
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.