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 à Bruxelles (185 103 habitants), en région bruxelloise, 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.
Vous avez un projet d'application mobile à Bruxelles.
Et vous vous posez la question fatidique. iOS ou Android ?
Regardons les chiffres. Android détient la plupart des parts de marché mondial.
C'est gigantesque.
Sur les 185 103 habitants de Bruxelles, la grande majorité a un smartphone Android dans la poche.
Si vos clients sont sur Android, vous n'avez pas le choix. Vous devez y être.
Mais attention. Faire une application Android, ce n'est pas juste cocher une case.
C'est un écosystème avec ses propres règles. Ses propres standards de design.
Le facteur le plus important est de créer une expérience fluide, peu importe la marque du téléphone.
Commencer par Android ou par iOS dépend de deux choses : où sont vos utilisateurs, et quel est votre budget. Android donne accès au parc le plus large, notamment sur les appareils d'entreprise et les téléphones d'entrée de gamme. iOS concentre les utilisateurs qui dépensent le plus. Il n'y a pas de bonne réponse générale, seulement une bonne réponse pour votre marché.
Souvent, on me demande s'il faut commencer par iOS ou par Android pour un projet à Bruxelles.
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.
Certains de mes clients travaillent avec moi depuis des années. Pourquoi ? Parce que je ne disparais pas dans la nature une fois l'application iOS ou Android publiée.
Basé à Cannes, j'accompagne mes clients sur la durée. Pendant mes 12 ans de carrière, j'ai compris que la sortie d'une app n'est que le début de l'histoire. Il faut l'améliorer, la maintenir, écouter les utilisateurs.
Le facteur le plus important est ce suivi rigoureux. Je suis là pour vous suivre dans la durée, comme un vrai partenaire.
L'économie de Bruxelles é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 en région bruxelloise. 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 à Bruxelles 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 en Belgique, le constat est exactement le même. Les habitants de Bruxelles veulent pouvoir commander, réserver, ou s'informer en un clic depuis leur canapé ou dans les transports.
Bruxelles impose le bilinguisme presque par défaut, et souvent le trilinguisme si vous visez aussi la Flandre. Ce n'est pas qu'une affaire de traduction : les textes changent de longueur, les écrans bougent, et une interface pensée en français casse en néerlandais. On construit donc les écrans pour le texte le plus long dès le premier jour.
Le bilinguisme bruxellois a une particularité qui le distingue d'un simple projet multilingue : les deux langues coexistent dans le même lieu, souvent dans la même entreprise et parfois dans la même réunion. Cela veut dire qu'on ne peut pas décider de la langue une fois pour toutes au premier lancement et l'oublier. Un utilisateur doit pouvoir basculer à tout moment, l'application doit se souvenir de son choix, et les documents qu'elle génère — un devis, un reçu, une notification — doivent sortir dans la bonne langue sans qu'on ait à y penser.
Il y a aussi une dimension qui n'est pas technique et qu'il vaut mieux nommer : à Bruxelles, la langue n'est jamais neutre. Une application dont la version néerlandaise est visiblement une traduction bâclée du français envoie un message, et ce message coûte des utilisateurs. Je fais traduire par quelqu'un dont c'est la langue plutôt que de m'en remettre à un outil automatique, et je prévois ce coût dans le devis au lieu de le découvrir à la fin.
Un détail de publication propre à la Belgique, et qui se règle mal après coup : les stores n'ont qu'un pays « Belgique », mais ils affichent la fiche dans la langue de l'appareil. Une application publiée avec une seule description se présente donc en français à un utilisateur néerlandophone, ou l'inverse, dès le premier écran — celui où se décide l'installation. Fournir les deux fiches ne coûte presque rien au moment de la soumission ; les ajouter plus tard veut dire refaire les captures d'écran, qui portent du texte elles aussi.
Bruxelles concentre par ailleurs les institutions européennes et tout ce qui gravite autour : représentations, fédérations professionnelles, cabinets de conseil. Ces organisations ont des cycles de décision longs et plusieurs personnes à convaincre, ce qui rend inutile de promettre une grande livraison dans six mois. Je préfère livrer toutes les deux semaines quelque chose d'installable, même partiel : cela donne à vos interlocuteurs de quoi se prononcer sur du concret, et cela évite de découvrir un désaccord de fond au dernier moment.
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 à Bruxelles :
La règle qui structure tout un projet Android tient en une phrase : on ne code pas six mois sans rien mettre entre des mains réelles. Le périmètre est fixé d'abord, en coupant ce qui peut attendre. Ensuite le développement avance par tranches, chacune installable sur un vrai téléphone. Chaque version essayée corrige une hypothèse ; chaque mois sans version en accumule.
La pire erreur, c'est de coder pendant 6 mois sans jamais rien tester en conditions réelles. Voici comment on travaille ensemble pour lancer votre application à Bruxelles.
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.
Quand une entreprise vend bien sur le web et mal sur mobile, la cause est presque toujours la lenteur avant d'être l'ergonomie. Une application native charge ses données autrement qu'une page web : elle garde en mémoire ce qui ne change pas, précharge la suite, et fonctionne encore quand le réseau faiblit. C'est ce que le site adaptatif ne sait pas faire.
Récemment, j'ai accompagné une entreprise de e-commerce qui voulait relancer ses ventes locales à Bruxelles.
Leur site web marchait bien. Mais sur mobile, c'était la catastrophe.
La plupart des utilisateurs abandonnent une navigation si le chargement dépasse 3 secondes.
Il leur fallait une application Android native pour fidéliser leur clientèle de la région Bruxelles-Capitale.
En résumé, l'objectif était simple : rendre l'achat ultra-rapide.
Nous avons développé l'application en Kotlin.
Je ne donne pas de fourchette avant le cadrage, parce qu'un prix annoncé avant de savoir ce qu'on construit est un chiffre inventé. En revanche, la mécanique, elle, se dit dès le premier appel : trente pour cent à la commande, le reste réparti par mois sur la durée du projet. Vous payez au rythme où le travail avance.
Deux dépenses tombent en plus du développement, et elles reviennent : le programme développeur d'Apple à 99 € par an, et le compte Google Play Console à 25 $ une fois. Les deux se prennent à votre nom, pas au mien.
Sur un projet court, d'un mois ou deux, le découpage est plus simple : la moitié au démarrage, la moitié à la livraison. Sur un projet qui court sur plusieurs mois, la mensualisation protège les deux côtés — vous ne financez jamais du travail qui n'a pas été fait, et je ne travaille jamais trois mois avant de facturer.
Dans le commerce, une application ne remplace pas la caisse : elle s'y branche. Ce qui décide de la faisabilité, c'est donc l'existence d'une interface ouverte sur votre logiciel de caisse ou de stock. Les usages qui marchent se comptent en gestes économisés, pas en fonctionnalités : consulter un stock depuis le rayon, encaisser une commande, scanner une étiquette.
Dans le commerce, une application ne remplace jamais la caisse : elle vient s'y brancher. C'est ce qui décide de la faisabilité, et la question se pose au premier rendez-vous — votre logiciel de caisse ou votre gestion de stock ouvre-t-il une interface, et à quelles conditions votre éditeur l'ouvre-t-il à un tiers ?
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 Bruxelles.
C'est un document obligatoire sur le Google Play Store. Il explique aux utilisateurs de la région Bruxelles-Capitale 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 Bruxelles 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 Belgique 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 à Bruxelles, 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.
Prêt à lancer votre application à Bruxelles ?
Vous avez l'idée. Vous connaissez votre marché en région bruxelloise. 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.
Une bonne application, c'est faire juste ce qu'il faut, et le faire bien. Sachant qu’une grande partie des fonctionnalités d'une application ne sont jamais utilisées, inutile de s'éparpiller. C'est une question de logique : concentrons-nous sur l'essentiel pour vos futurs utilisateurs de Bruxelles.
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.