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é : développement application android à 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.
Google Play héberge plus de 2 millions d'applications.
Comment la vôtre va-t-elle sortir du lot à Liège ?
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 à Liège 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.
Un projet Android suit un cycle complet, pas seulement une phase de code. On commence par le design, en appliquant les conventions du système pour que l'utilisateur n'ait rien à apprendre. Puis le développement, par tranches installables. Puis les tests sur de vrais appareils. Puis la publication, progressive. Chaque étape peut renvoyer à la précédente, et c'est normal.
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.
Une application grand public sur Android doit tenir sur des appareils de toutes marques et de tous prix, pas seulement sur le téléphone du développeur. C'est la contrainte qui structure le projet : choisir les appareils réels à couvrir, et tester dessus. Une application essayée sur un seul modèle se comporte autrement chez une bonne partie de ses utilisateurs.
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 Wallonie.
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.
Une application Android coûte généralement moins cher que son équivalent iOS. La raison est pratique plutôt que technique : les outils de développement de Google sont gratuits et plus souples, et le compte développeur Play se paie une seule fois au lieu d'être annuel. C'est le périmètre de votre application qui fixe le montant ; la plateforme ne le déplace qu'à la marge.
Le compte Google Play Console coûte 25 $, une seule fois, à l'inscription. C'est la dépense fixe la plus faible des deux plateformes — le programme développeur d'Apple, lui, se renouvelle à 99 € chaque année.
Je ne vais pas vous mentir. Créer une bonne application Android à Liège représente un investissement.
Souvent, on constate que le développement Android coûte sensiblement moins cher que son équivalent iOS.
Pourquoi ?
Parce que les outils de développement fournis par Google sont gratuits et souvent plus souples.
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.