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é : création d'application mobile à Liège (197 355 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.
Liège est un véritable carrefour d'innovation en Wallonie.
Les idées fusent, les projets se montent, et la concurrence est rude. Quel que soit votre secteur d'activité, il y a de grandes chances que vos concurrents directs réfléchissent déjà à leur propre application mobile. Ou pire, qu'ils l'aient déjà lancée. 🚀
Dans un marché aussi dense, celui qui propose l'expérience la plus fluide gagne la partie.
En résumé : l'innovation n'est plus une option,
Beaucoup de porteurs de projet à Liège perdent du temps à hésiter. Ils repoussent le développement de mois en mois. Mais le marché de votre pays n'attend pas.
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 à Liège ? 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 en Wallonie, 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.
Mon rôle premier est de protéger votre budget. Saviez-vous qu’une grande partie des fonctionnalités d'une application ne sont jamais utilisées ?
Depuis Cannes, j'aide mes clients à éviter ce gaspillage énorme. Avec 12 ans d'expérience sur iOS et Android, je sais où l'argent doit aller. On coupe le superflu pour se concentrer sur ce qui apporte une vraie valeur à votre cible.
L'avantage clé : une application qui sort vite, qui teste le marché, et qui coûte le juste prix. Construisons d'abord l'essentiel.
Liège a une tradition industrielle et logistique forte, et les applications qu'on y demande servent souvent à remplacer du papier sur le terrain. La contrainte principale n'est ni le design ni la performance : c'est le réseau. Une application de terrain doit fonctionner dans un entrepôt sans signal, puis se synchroniser toute seule.
« Fonctionner hors ligne » est une phrase que tout le monde emploie et qui recouvre plusieurs niveaux très différents de difficulté. Le niveau facile, c'est consulter : on télécharge les données à l'avance et on les lit sans réseau. Le niveau difficile, c'est modifier : deux personnes changent la même fiche chacune de leur côté, et quand le réseau revient il faut décider laquelle gagne. Il n'y a pas de réponse universelle à cette question, elle dépend de votre métier, et c'est une des rares décisions que je refuse de prendre seul.
Le remplacement du papier a aussi une dimension humaine qu'on sous-estime toujours. Le carnet fonctionnait ; il ne tombe pas en panne de batterie, il ne demande pas de mot de passe et il ne fait pas de mise à jour à un mauvais moment. Une application qui remplace du papier doit donc être franchement meilleure, pas équivalente, sinon elle sera contournée dans le mois. En pratique, cela veut dire viser moins de gestes que le papier pour la tâche la plus fréquente, et accepter d'être plus lent sur les cas rares.
Sur ces projets, le matériel décide d'une bonne part de l'ergonomie. Un téléphone durci avec un lecteur de codes-barres intégré ne se programme pas comme un appareil photo : le scanner se comporte souvent comme un clavier, il envoie la valeur puis un retour chariot, et l'application doit être conçue pour ça — champ toujours prêt, pas de fenêtre qui vole le focus, retour sonore parce que l'écran n'est pas regardé. Scanner avec l'appareil photo marche pour un usage occasionnel, et devient pénible à la centième lecture d'une journée.
Liège est par ailleurs un nœud logistique européen important, avec son aéroport de fret et son port fluvial, et les projets qui en viennent touchent souvent au suivi de marchandises. Ce sont des applications où l'horodatage et l'identité de l'appareil comptent autant que la donnée saisie, parce qu'elles servent de preuve en cas de litige. Cela impose de conserver un historique complet plutôt que d'écraser les valeurs, et c'est une décision d'architecture, pas une option qu'on ajoute plus tard.
L'économie de Liège é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 Wallonie. 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 à Liège 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 Liège veulent pouvoir commander, réserver, ou s'informer en un clic depuis leur canapé ou dans les transports.
Le travail ne s'arrête pas à la publication. Une application vit sur des systèmes qui bougent : iOS et Android sortent chacun une version majeure par an, et une application non maintenue finit par être retirée des stores. Invent Better prévoit cette suite dès le devis, plutôt que de la présenter comme un imprévu six mois après le lancement.
Il y a un mythe tenace dans notre métier. Celui qui consiste à croire que le travail s'arrête le jour de la publication sur les stores.
Vous appuyez sur le bouton, l'application est disponible à Liège, on sable le champagne, et l'équipe de développement disparaît dans la nature pour passer au client suivant.
C'est la pire chose qui puisse arriver à votre projet.
Une application mobile, ce n'est pas un tableau qu'on accroche au mur et qu'on ne touche plus jamais. C'est un organisme vivant.
Le jour de la publication n'est pas la fin du projet, c'est le premier jour où l'application rencontre de vrais utilisateurs. La suite se prépare avant, pas après : sans elle, les premiers retours arrivent et personne n'est là pour y répondre.
La première semaine, on surveille. Pas les téléchargements — les plantages, les écrans où les gens s'arrêtent, les endroits où ils reviennent en arrière. Un rapport de plantage vaut mille suppositions, et les trois premiers jours en apprennent plus que trois mois de réunions.
La deuxième semaine, on corrige ce que ces retours ont montré, et on publie une mise à jour. Elle est presque toujours nécessaire, et ce n'est pas un échec : aucune première version ne survit intacte au contact de son public à Liège.
Ensuite le rythme ralentit, mais ne s'arrête pas. Apple sort une version majeure d'iOS chaque automne, Google une d'Android chaque année, et chacune casse quelque chose — une autorisation qui change de forme, une bibliothèque qui n'est plus signée, un écran qui se décale.
On décide ensemble du niveau de suivi avant le lancement, pas au premier incident.
Un site qui reçoit l'essentiel de son trafic depuis un téléphone et n'y enregistre presque aucune réservation n'a pas un problème de visibilité : il a un problème de parcours. Le cas se règle rarement en ajoutant des fonctionnalités. Il se règle en retirant des étapes entre le moment où quelqu'un arrive et celui où il peut réserver.
Rien ne vaut un exemple concret pour comprendre. Voici l'histoire d'une entreprise de services bien implantée.
Cette entreprise avait un site web classique. Les statistiques montraient que beaucoup de leur trafic provenait des téléphones portables. C'est énorme. Mais il y avait un problème de taille. Ils n'enregistraient absolument aucune réservation depuis ces appareils.
Leurs clients essayaient de prendre rendez-vous, se perdaient sur le site mobile, et abandonnaient.
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 :
Dans le transport, le mode hors ligne n'est pas une option de confort, c'est l'architecture. Entrepôts, sous-sols et routes de campagne coupent le réseau, et une application qui suppose une connexion permanente ne tient pas une journée. Deux décisions suivent : la règle qui tranche les modifications concurrentes, et la façon dont la preuve de livraison est conservée.
Dans le transport, le mode hors ligne n'est pas une option de confort : c'est l'architecture. Un entrepôt métallique, un sous-sol, une zone portuaire ou une route de campagne coupent le réseau, et une application qui suppose une connexion permanente ne survit pas à sa première journée réelle.
On construit donc l'inverse : tout fonctionne sans réseau, et la synchronisation se fait seule dès qu'il y a du signal — sans bouton à presser, parce qu'un bouton à presser finit toujours par ne pas l'être.
Ces questions portent toutes sur la même inquiétude : que se passe-t-il si ça tourne mal. La réponse tient à la façon dont le projet est monté. Le dépôt de code et les comptes des stores sont à votre nom dès le premier jour, donc rien ne dépend de ma présence. Un refus d'Apple est une étape ordinaire, pas une impasse : on corrige, on resoumet.
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 indique avoir examiné 7,77 millions de soumissions en 2024 et en avoir rejeté 1,93 million, soit près d'une sur quatre (rapport de transparence App Store 2024). 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 depuis 2013, 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.
Pendant que vous hésitez, vos concurrents à Liège avancent.
Le monde du mobile va vite. Très vite. Aujourd'hui, l’essentiel du trafic web mondial provient des mobiles. Si vous repoussez sans cesse la création de votre application, d'autres prendront votre place en Wallonie.
Mais attention, il ne faut pas confondre vitesse et précipitation. Lancer une application instable est la pire des stratégies.
En résumé : il faut faire vite, mais il faut surtout faire bien. ⏳
En 30 minutes, vous saurez par où commencer. Sans engagement.
Réservez un appel gratuit →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.