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 à Lille (232 741 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.
Lille est un véritable carrefour d'innovation dans les Hauts-de-France.
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 à Lille perdent du temps à hésiter. Ils repoussent le développement de mois en mois. Mais le marché de votre pays n'attend pas.
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 à Lille, sans vous faire payer une Ferrari s'il vous faut une citadine fiable.
Pas d'agence. Pas de commercial. Pas de chef de projet entre nous deux.
Quand vous travaillez avec moi, vous parlez directement à la personne qui construit votre application. Depuis 12 ans, je gère la création d'applications iOS et Android de A à Z depuis mon bureau à Cannes. Ça veut dire plus de réactivité, moins de blabla, et aucune mauvaise surprise sur la facture.
Le point essentiel : on gagne un temps fou. Je vous conseille, je conçois, et je développe avec une transparence totale. C'est aussi simple que ça.
Lille est proche de Bruxelles et de Londres, et beaucoup de projets lillois visent d'emblée plusieurs pays. Cela déplace les priorités : la gestion des langues et des devises n'est plus une option de la version deux, elle fait partie des fondations, sinon il faut tout reprendre au moment où ça commence à marcher.
Le piège n'est pas la traduction, qui est la partie facile. Le piège, ce sont les hypothèses qu'on prend sans s'en rendre compte quand on écrit une application pour un seul pays. Un code postal à cinq chiffres, alors que les codes britanniques sont alphanumériques et les belges à quatre. Un numéro de téléphone qui commence par zéro. Une date écrite jour/mois qui devient fausse et non pas illisible pour un lecteur américain. Un prix stocké en centimes d'euro dans une colonne qui n'a pas de champ pour la devise. Chacune de ces hypothèses est invisible tant que vous restez en France, et chacune est une reprise de base de données une fois que vous avez des utilisateurs.
L'autre conséquence est réglementaire. Vendre à des particuliers dans plusieurs pays européens change la façon dont la TVA doit être calculée et affichée, et le Royaume-Uni n'est plus dans l'Union, ce qui ajoute son propre jeu de règles. Je ne suis pas comptable et je ne prétendrai pas l'être, mais je sais que ces règles se traduisent dans le code par un champ de plus et une logique de calcul qu'il vaut mieux prévoir dès le départ que greffer après.
Vendre dans plusieurs pays veut aussi dire tenir plusieurs fiches de stores, et c'est un travail récurrent que personne ne chiffre au départ. Chaque pays où l'application est disponible a sa description, ses captures d'écran, ses mots-clés, et ses avis auxquels il faut répondre dans la bonne langue. Trois pays, ce sont trois fiches à maintenir à chaque mise à jour, pas une traduite trois fois. Ce n'est pas une raison de renoncer, c'est une raison de décider consciemment sur combien de marchés on ouvre en version une — souvent un seul, celui où vous avez déjà des clients.
Sur le plan pratique, Lille a un avantage que peu de villes françaises ont : vous êtes à une heure de Bruxelles en train, à moins de deux de Paris, et à un peu plus de deux de Londres. Si le projet demande de rencontrer des utilisateurs dans plusieurs pays, ces trajets-là sont faisables dans la journée, et cela change ce qu'on peut se permettre de vérifier en vrai plutôt que de supposer.
Beaucoup de projets lillois viennent d'une entité régionale d'un groupe : l'équipe qui a le besoin n'est pas celle qui signe. Ça ne change rien à ce qu'il faut construire, mais tout à la façon de le montrer. Le prestataire utile ici est celui qui produit vite quelque chose d'installable, pas un dossier.
La raison est simple. Un document de spécifications se lit d'une manière différente par chaque personne de la chaîne de validation, et personne ne s'aperçoit du désaccord avant la livraison. Une application qu'on installe sur son propre téléphone ne laisse aucune place au malentendu : soit elle fait la chose, soit elle ne la fait pas.
On travaille donc dans cet ordre. Des maquettes cliquables dès les premières semaines, envoyées par lien, sans rien à installer. Puis une version testable toutes les deux semaines, que vous pouvez faire circuler jusqu'au siège. Chaque validation porte sur quelque chose que quelqu'un a vu fonctionner.
Ça a un effet secondaire utile quand la décision remonte : vous n'avez pas à défendre mon travail avec mes mots. Vous envoyez un lien.
Quand la validation remonte au siège, le premier mois vise une seule chose : avoir quelque chose à montrer avant la première réunion de comité. Un lien qu'on ouvre vaut mieux qu'un document qu'on interprète.
Ensuite, une version toutes les deux semaines, que vous pouvez faire remonter sans moi.
Un projet ne construit jamais tout ce qui a été imaginé, et c'est volontaire. On commence par une première version réduite à ce qui rend l'application utile sans le reste. Le filtre est simple : si une fonction n'existe pas, est-ce que quelqu'un utilise quand même l'application ? Ce qui survit à ce tri sort vite et vous apprend ce que six mois de développement à l'aveugle n'auraient pas dit.
Si vous voulez que votre projet réussisse à Lille, il faut accepter une réalité très contre-intuitive : on ne développe jamais tout ce qu'on a imaginé.
On commence toujours, sans aucune exception, par un Produit Minimum Viable. Le fameux MVP.
C'est quoi un MVP ?
C'est la version la plus petite, la plus simple et la plus directe de votre idée. C'est l'essence même de votre solution. Pourquoi faire cela pour votre entreprise dans les Hauts-de-France ? Parce que les statistiques sont cruelles. Actuellement, une grande partie des fonctionnalités d'une application ne sont absolument jamais utilisées par le public.
Hériter d'une application développée au moins-disant coûte presque toujours plus cher que de l'avoir bien faite. Le motif est constant : pas de documentation, pas de tests, un code que personne ne peut reprendre, et des plantages quotidiens qui font tomber la note du store. La réparation commence par un audit, pas par une réécriture.
Parfois, le pire ennemi d'un projet, c'est une fausse bonne affaire. Le cas suivant revient assez souvent pour être décrit : une entreprise technologique en pleine panique.
Ils avaient hérité d'une application mobile développée par une équipe offshore très bon marché. Le résultat ? L'application plantait plusieurs fois par jour.
La note sur les stores était tombée très bas. Les utilisateurs laissaient des avis désastreux quotidiennement. Le PDG était prêt à tout jeter à la poubelle.
Le développement n'est pas la seule dépense d'une application, et les autres reviennent tous les ans. Les connaître avant de signer change la façon dont vous dimensionnez le projet — et évite la mauvaise surprise du douzième mois, qui est toujours la plus mal reçue.
Publier coûte de l'argent aux deux endroits. Le programme développeur d'Apple se renouvelle chaque année ; le compte développeur Google Play se paie une fois, à l'inscription. Ces comptes doivent être à votre nom, pas au mien : c'est votre application, et un compte au nom du prestataire est le piège le plus courant du secteur.
Viennent ensuite l'hébergement et les services que l'application consomme. Sur un projet de Lille qui démarre, la facture est modeste — mais elle tombe tous les mois, et elle grandit avec le nombre d'utilisateurs.
Si vous vendez dans l'application, Apple et Google prélèvent entre 15 % et 30 % selon votre chiffre d'affaires et le programme auquel vous êtes éligible. Ça se calcule avant de fixer vos prix, pas après.
Immobilier, finance et événementiel partagent une exigence rare : l'information doit arriver au bon moment, pas seulement être exacte. Une alerte immobilière en retard ne vaut rien, un solde bancaire approximatif non plus, un programme d'événement périmé encore moins. Ces secteurs se construisent donc autour de la notification et de la fraîcheur des données.
Le marché immobilier à Lille est ultra-compétitif. Si un client potentiel rate une belle affaire parce que votre site mobile ramait, il ira chez votre concurrent.
Une bonne application immobilière, c'est l'outil qui prévient l'acheteur avant tout le monde. On met en place des alertes push géolocalisées dès qu'un nouveau bien correspond à ses critères dans les Hauts-de-France.
Ces questions comparent des options : indépendant ou agence, natif ou hybride, première version réduite ou produit complet. Le critère utile est toujours le même — ce que vous pourrez changer ensuite. Une application peu chère qui ne peut pas évoluer coûte plus cher à la deuxième version qu'une application bien construite à la première.
Vous n'avez qu'un seul interlocuteur direct du début à la fin du projet. Dans une grande agence, vous payez le salaire du commercial, du chef de projet, du directeur artistique, et enfin du développeur junior qui va réellement écrire le code. Avec un freelance expérimenté, il n'y a aucun intermédiaire. Je conçois, je dessine, je code et je publie. Les décisions sont prises rapidement en visio. Cela réduit considérablement vos frais généraux tout en garantissant que la personne qui comprend vos enjeux commerciaux est bien celle qui tape sur le clavier.
Le natif est codé spécifiquement pour un seul système, avec Swift pour Apple ou Kotlin pour Google. L'hybride utilise un langage commun, comme Flutter, pour générer deux applications à partir d'un seul code. Le natif offre les performances maximales pour des jeux ou des outils très lourds. Mais soyons clairs, l'hybride couvre aujourd'hui la plupart des besoins commerciaux avec une qualité indiscernable pour l'utilisateur final. L'avantage clé de l'hybride est financier : vous divisez presque par deux le temps de développement de votre projet en France.
La maintenance représente une part essentielle du budget global de votre application. Elle couvre les mises à jour obligatoires des systèmes iOS et Android, la correction des failles de sécurité, et l'ajustement aux nouveaux formats d'écrans. La plupart des utilisateurs fuient si le chargement dépasse trois secondes. Sans maintenance, votre app ralentit puis meurt. Le montant exact dépend de la taille et de la complexité de votre projet. On en discute ensemble lors de notre premier appel.
Un audit technique complet dure exactement une semaine. Vous me donnez l'accès à votre code source et à vos statistiques de plantage. J'épluche chaque ligne de code. J'analyse l'architecture, la sécurité, et les métriques de performance. À la fin de cette semaine, je vous remets un rapport détaillé et incisif. Vous y trouverez la liste des bugs critiques à corriger d'urgence, des recommandations d'amélioration, et un devis de réparation. C'est l'outil indispensable pour savoir si l'on peut sauver votre application ou s'il faut tout reconstruire.
C'est exactement ma méthode de travail et la stratégie la plus recommandée. Sachant qu’une grande partie des fonctionnalités planifiées à l'avance ne sont jamais utilisées, vouloir tout faire d'un coup est suicidaire. Nous lançons un Produit Minimum Viable (MVP) avec seulement les trois à cinq fonctions vitales en huit à dix semaines. Ensuite, nous analysons comment vos utilisateurs interagissent avec le produit. Nous itérons sur des données réelles, pas sur des suppositions. C'est ainsi qu'on construit un leader sur son marché.
Les délais varient de vingt-quatre heures chez Apple à quatorze jours incompressibles chez Google. Apple examine votre code très manuellement pour vérifier le respect de leurs directives esthétiques et techniques. Google impose maintenant à toutes les nouvelles applications d'être testées par vingt personnes différentes pendant deux semaines consécutives avant d'autoriser la publication finale. Attention, pendant les périodes de fêtes, ces délais peuvent tripler. Je m'occupe d'anticiper ces contraintes pour que votre lancement dans les Hauts-de-France se passe exactement à la date prévue.
L'ASO (App Store Optimization) est le référencement naturel spécifique aux magasins d'applications. C'est ce qui vous rend visible. Nous optimisons le titre, le sous-titre, les mots-clés cachés et nous créons des captures d'écran percutantes. Surtout, nous mettons en place des stratégies pour récolter des avis positifs. Les statistiques sont formelles : La plupart des utilisateurs lisent les avis avant de lancer un téléchargement. Une mauvaise note vous condamne à l'invisibilité. Je vous accompagne sur cette partie vitale pour que votre application soit trouvée facilement.
Oui, si vos utilisateurs risquent de perdre le réseau dans un sous-sol, dans les transports ou lors d'un voyage à l'étranger. Le mode hors-ligne stocke les informations essentielles dans le téléphone et les synchronise silencieusement dès que le réseau revient. Il faut l'anticiper. L'avantage clé est une expérience sans friction, mais l'ajouter après le lancement coûte trois à cinq fois plus cher que de le prévoir dès l'architecture initiale. Discutons de la réalité du terrain de vos utilisateurs pour prendre la bonne décision.
Je m'occupe de l'intégralité du processus de mise à jour pour vous. Chaque nouvelle version doit repasser par l'examen minutieux d'Apple et de Google. Il faut prévoir un minimum de quatre à six mises à jour sérieuses par an. Chaque version inclut la correction des petits défauts signalés par les utilisateurs, l'ajout progressif de vos nouvelles idées, et l'ajustement aux nouvelles règles de confidentialité de France. Il clique. Il quitte. Il oublie. Pour garder votre audience, l'application doit toujours être impeccable et vivante.
Un site web responsive s'adapte visuellement à la taille de l'écran, mais une application mobile s'installe physiquement au cœur du téléphone. Les différences majeures sont colossales. Une application permet d'envoyer des notifications push, de fonctionner hors-ligne, d'utiliser la reconnaissance faciale pour se connecter, et d'accéder à l'appareil photo ou au GPS de manière ultra-fluide. Si vous voulez juste diffuser de l'information, un site suffit. Si vous voulez créer une interaction quotidienne et rapide, il vous faut une application.
Si votre projet vise plusieurs pays — et à Lille, c'est souvent le cas dès le départ — la question la plus rentable à régler tôt est celle du périmètre.
En trente minutes, on peut décider sur combien de marchés vous ouvrez la première version, quelles hypothèses françaises il faut retirer du code avant qu'elles ne coûtent une reprise de base de données, et ce que la validation au siège implique pour le calendrier.
Vous repartez avec une réponse utilisable même si on ne travaille pas ensemble.
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.