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 êtes basé à Bruxelles 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 en région bruxelloise.
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.
Le vocabulaire du métier cache une réalité simple. Le natif désigne une application écrite avec les outils officiels d'Apple et de Google. L'hybride désigne un code unique adapté aux deux. Le back-end désigne le serveur, et l'API la façon dont l'application lui parle. Ce qui compte pour vous n'est pas le mot mais la conséquence : le coût, la vitesse et ce que vous pourrez modifier ensuite.
Trois façons de construire, trois conséquences :
Mon rôle est de vous guider vers celui qui correspond à vos ambitions à Bruxelles, sans vous faire payer une Ferrari s'il vous faut une citadine fiable.
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.
Vous avez un projet à Bruxelles. Et vous vous demandez avec quels outils nous allons construire votre application.
Le jargon informatique peut faire peur.
Je ne vais pas vous inonder de termes techniques incompréhensibles. Mon rôle est de choisir le meilleur moteur pour votre projet en région bruxelloise.
Voici les technologies que j'utilise au quotidien, expliquées simplement. 🛠️
Un projet se déroule en quatre temps : un cadrage qui décide de ce qui entre dans la première version, des maquettes que vous manipulez avant qu'une ligne de code existe, un développement livré par tranches installables, puis la publication. Ce qui compte n'est pas le nombre d'étapes mais leur rythme.
Quatre étapes, dans cet ordre :
Un site adaptatif n'est pas une application, et la différence se voit sur le tunnel d'achat : trop d'étapes, boutons trop petits, chargement lent, numéro de carte à ressaisir à chaque commande. Chacun de ces points perd des clients séparément. Les corriger un à un vaut mieux qu'une refonte complète, parce qu'on mesure alors ce qui a servi.
Imaginez une entreprise de vente en ligne bien connue. Cette marque possédait un site web dit responsive, censé s'adapter aux téléphones.
Leur trafic mobile représentait beaucoup de leurs visites totales. C'était leur vitrine principale sur mobile. Mais le taux de conversion sur mobile était très inférieur à celui de l'ordinateur. Ils perdaient littéralement de l'argent chaque jour.
Le problème était évident. Le tunnel d'achat était un enfer de friction.
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 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 à Bruxelles 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 région bruxelloise. 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 Bruxelles, 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 Belgique 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 à Bruxelles 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.
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.