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 une idée d'application.
Si votre cible à Bruxelles cherche le haut de gamme, le choix de la plateforme n'est pas un détail.
Le facteur le plus important, c'est de savoir où se trouve la valeur.
En moyenne, les utilisateurs iOS dépensent davantage dans les applications que les utilisateurs Android.
L'écosystème Apple attire une clientèle habituée à payer pour la qualité, les abonnements et les services premium.
Si vous voulez créer une app iPhone à Bruxelles qui génère des revenus solides, vous devez viser l'App Store.
Mais attention, on ne rentre pas chez Apple comme dans un moulin.
Il faut respecter leurs règles. Leurs standards de design. Leurs exigences techniques.
Lancer sur les deux plateformes en même temps double le coût de la première version sans doubler ce qu'on apprend. Avec un budget contraint, commencer par une seule plateforme — celle où sont vos utilisateurs — permet de valider le produit, puis de porter l'autre en sachant quoi construire. L'ordre inverse coûte deux fois plus cher pour la même leçon.
Lancer une application coûte de l'argent et du temps.
Faut-il lancer sur iOS et Android en même temps ? Ou commencer par iOS ?
Si vous avez un budget serré à Bruxelles, commencer par iOS est souvent le meilleur choix.
Le facteur le plus important est la rentabilité.
En moyenne, les utilisateurs iOS dépensent davantage dans les applications que les utilisateurs Android.
Ils sont plus enclins à payer pour des abonnements, des services premium et des achats intégrés.
En développant d'abord sur iPhone, on valide votre modèle économique plus rapidement.
De plus, l'écosystème matériel est maîtrisé.
Il y a une poignée de modèles d'iPhone récents.
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.
On ne bricole pas une application iOS.
Pour offrir une expérience fluide à vos utilisateurs de Bruxelles, il faut utiliser les bons outils.
En résumé, voici ce qu'il se passe sous le capot.
Je développe principalement en Swift.
C'est le langage moderne créé par Apple pour remplacer l'ancien Objective-C.
C'est rapide, sécurisé, et ça évite de nombreux crashs.
Pour construire vos écrans, j'utilise SwiftUI.
C'est l'avenir du design chez Apple.
Cela permet de créer des interfaces animées et réactives qui s'adaptent parfaitement à toutes les tailles d'iPhone et d'iPad.
Pour le stockage des données de vos utilisateurs à Bruxelles, j'intègre Core Data ou CloudKit.
Un projet iOS commence par le cadrage, pas par le design : on décide ce que l'application fait avant de décider à quoi elle ressemble. Viennent ensuite les maquettes, validées avant tout développement, puis les versions installables, puis la soumission à Apple. L'ordre compte, parce que revenir sur une décision de cadrage après le développement coûte dix fois plus cher qu'avant.
Créer une application, c'est comme construire une maison à Bruxelles.
On ne commence pas par peindre les murs avant d'avoir fait les fondations.
L'avantage clé de ma méthode, c'est la transparence.
Étape 1 : Le cadrage.
On définit exactement ce que l'application va faire. On liste les fonctionnalités. Et surtout, on anticipe les exigences d'Apple.
Étape 2 : Le compte développeur.
C'est le moment de demander votre numéro DUNS si vous ne l'avez pas. Ça prend du temps, on le fait tout de suite.
Étape 3 : Le développement en Swift.
Je code l'application brique par brique.
Vous n'attendez pas six mois dans le noir. Je vous donne accès à TestFlight très vite.
Équiper des commerciaux d'une tablette pose un problème simple et souvent mal traité : ils travaillent chez le client, sans connexion garantie. L'application doit donc fonctionner entièrement hors ligne et synchroniser au retour. Le vrai sujet n'est pas l'affichage mais la règle qui tranche quand deux personnes ont modifié la même fiche chacune de leur côté.
Le B2B, ce n'est pas forcément que du web.
Le cas type : une entreprise industrielle qui veut équiper ses commerciaux sur le terrain.
Ils avaient tous des iPad fournis par l'entreprise.
Le point essentiel : il fallait une application robuste, capable de fonctionner sans connexion internet dans des entrepôts.
Oubliez les solutions web hybrides qui saccadent.
Nous sommes partis sur du développement iOS entièrement natif.
L'utilisation de Core Data a permis de stocker tout le catalogue produit en local sur l'iPad.
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 arbitrent entre des options : natif ou hybride, abonnement ou achat, quel outil d'interface, quel niveau de maintenance après la publication. Le critère de décision est le même partout — ce que vous devrez pouvoir modifier dans un an. Le natif coûte un peu plus au départ et beaucoup moins quand l'application vit longtemps.
Pour un rendu premium, le natif est roi. L'avantage clé, c'est l'expérience utilisateur qui sera toujours supérieure avec les technologies d'Apple par rapport à un outil hybride.
Non, TestFlight est gratuit. Il est inclus dans votre abonnement de développeur Apple à un abonnement annuel.
près d’une soumission sur quatre est rejetée. Souvent pour des bugs non traités, un manque de valeur, ou le non-respect des règles de paiement d'Apple.
Oui, si vous souhaitez que l'application s'affiche au nom de votre entreprise de Bruxelles sur le Store. Si vous publiez en nom propre, il n'est pas nécessaire.
Bien sûr. C'est même recommandé. En moyenne, les utilisateurs iOS dépensent davantage dans les applications que les utilisateurs Android. L'écosystème s'y prête parfaitement.
Cela dépend de la complexité. Une V1 simple peut prendre 4 à 8 semaines de code, plus le temps incompressible de création de compte et de validation par Apple.
Oui. iOS évolue chaque année en septembre. Il faut s'assurer que votre code reste compatible avec les nouvelles règles et les nouveaux iPhone.
C'est l'outil fourni par Apple pour dessiner les écrans. C'est ce qui nous permet de coder rapidement des interfaces magnifiques et réactives.
Oui, mais Apple exige que l'on justifie très clairement à l'utilisateur pourquoi nous en avons besoin. C'est une question de logique et de respect de la vie privée.
C'est exigeant. Apple traite 100 000+ soumissions par semaine. C'est pour cela que je gère cette étape pour vous, pour garantir un lancement réussi à Bruxelles.
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.