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 sur l'App Store et Google Play.
En résumé : pour votre projet à Strasbourg (284 677 habitants), dans le Grand Est, 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é à Strasbourg 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 dans le Grand Est.
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.
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 à Strasbourg ? 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 dans le Grand Est, 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.
Le point essentiel : le prix dépend de la complexité technique sous le capot, pas du nombre de pages.
Je ne suis pas juste un développeur. Je suis aussi celui qui va vous dire quand une fonctionnalité est une mauvaise idée.
En 12 ans d'expérience, j'ai vu trop de projets échouer à cause d'applications trop compliquées. Mon approche depuis Cannes ? On simplifie. Je travaille avec des startups et des PME pour construire des applications iOS et Android qui vont droit au but.
Je suis votre partenaire produit. Si une idée ne sert pas vos utilisateurs, je vous le dirai. En résumé :
Une application strasbourgeoise s'adresse souvent à des utilisateurs français et allemands, et ce ne sont pas les mêmes utilisateurs avec un dictionnaire entre eux. Le prestataire à chercher est celui qui refuse d'en faire la moyenne : il pose les questions d'usage avant de traduire quoi que ce soit.
Ces questions en valent la peine parce qu'elles changent des écrans, pas des mots. Sur quel ton on s'adresse à l'utilisateur — le vouvoiement allemand n'est pas un détail de politesse, il fixe le registre de toute l'interface. Quels moyens de paiement vos utilisateurs allemands s'attendent à trouver, qui ne sont pas forcément ceux de vos utilisateurs français. Comment une adresse, une date et un numéro de téléphone s'écrivent de chaque côté.
Rien de tout cela ne se règle en fin de projet par une passe de traduction. Ce sont des décisions de conception, et les prendre au départ coûte quelques jours contre plusieurs semaines de reprise.
Le test qui tranche est simple : faites essayer la maquette à un germanophone réel avant la première ligne de code. Dix minutes, et vous saurez si le projet est bilingue ou seulement traduit.
Strasbourg travaille des deux côtés de la frontière, et cela se voit dans les projets : bilinguisme français-allemand dès la première version, parfois une contrainte réglementaire européenne, et des utilisateurs qui changent de langue en cours de route. Prévoir cela au départ coûte quelques jours ; l'ajouter après coûte une refonte.
L'allemand est la langue qui casse le plus d'interfaces, et ce n'est pas une plaisanterie de développeur. Les mots composés allemands sont longs : un bouton qui affiche « Paramètres » sur trois centimètres affiche parfois quelque chose de deux fois plus large en allemand, et le texte déborde, se coupe, ou pousse le reste de l'écran hors du cadre. La seule parade fiable est de concevoir chaque écran pour la version la plus longue du texte dès la maquette, et de tester dans les deux langues à chaque étape plutôt qu'une fois à la fin.
Le changement de langue en cours d'usage est l'autre détail que peu de gens anticipent. Un utilisateur strasbourgeois peut très bien installer l'application en français puis basculer en allemand pour montrer un écran à un collègue. Si le changement oblige à redémarrer l'application, à se reconnecter, ou s'il perd le formulaire à moitié rempli, l'expérience est mauvaise. Cela se prévoit dans la façon dont l'application charge ses textes, et c'est presque gratuit si on y pense avant.
Le bilinguisme a un coût qu'on oublie systématiquement au chiffrage : les textes qui ne sont pas de l'interface. Conditions d'utilisation, politique de confidentialité, formulaires de consentement, e-mails automatiques, messages d'erreur du serveur, fiche du store. Une application franco-allemande a besoin de tout cela dans les deux langues, et ce sont précisément les textes qu'on écrit en dernier, dans l'urgence, souvent la veille de la soumission. Les prévoir dès le début coûte quelques heures ; les traduire en catastrophe coûte un report de publication, parce qu'une politique de confidentialité approximative se refuse à la validation.
Strasbourg abrite aussi des institutions européennes et un tissu de sous-traitants qui travaillent pour elles, ce qui apporte une exigence documentaire supérieure à la moyenne. Sur ces projets, ce qui prend du temps n'est pas le développement mais la validation : plusieurs interlocuteurs, des délais de réponse longs, et des demandes de traçabilité sur les décisions. Je le prends en compte dans le planning en livrant par petits morceaux validables, plutôt qu'en promettant une grande version dans six mois qui restera bloquée en revue.
Sur un projet bilingue, le premier mois sert à décider ce que veut dire « bilingue » ici. La réponse n'est pas la même selon que vos deux publics font la même chose dans l'application ou deux choses différentes.
Un projet se juge à ce qu'il produit, pas à ce qu'il promet. Toutes les deux semaines, vous recevez une version installable sur votre téléphone et une note écrite de ce qui a changé. C'est la seule protection réelle contre le silence de six mois.
La version est parfois très incomplète, et c'est voulu. Une application partielle qu'on peut ouvrir dit la vérité sur l'avancement ; un pourcentage dans un tableau de suivi ne dit rien du tout, et personne ne sait le contredire.
La note fait quelques lignes : ce qui est fait, ce qui a bougé par rapport à ce qui était prévu, et ce sur quoi j'attends une réponse de votre part. Ce dernier point est celui qui fait gagner le plus de temps, parce qu'une question posée par écrit se traite entre deux réunions.
Vous n'avez rien à installer de compliqué : un lien, et l'application arrive sur votre appareil. Vous pouvez la faire essayer à qui vous voulez dans votre entreprise dans le Grand Est, sans me demander.
Et si une version manque, vous le voyez tout de suite. C'est le but.
Un processus transparent, itératif, et sans surprise. Vous voyez l'application grandir chaque semaine.
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.
En résumé : on ne construit pas tout. On construit ce dont vos utilisateurs ont vraiment besoin.
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.
Santé, tourisme et commerce en ligne posent trois contraintes différentes à une même application. La santé impose l'hébergement certifié et le mode hors ligne. Le tourisme impose la rapidité et l'absence d'inscription pour un visiteur de passage. Le commerce impose un tunnel d'achat court. Le point commun : chacune de ces contraintes se décide avant la première maquette, pas après.
Le secteur de la santé ne pardonne aucune erreur. Créer une application médicale pour des patients ou des médecins dans le Grand Est, ce n'est pas juste coder une belle interface. C'est construire un coffre-fort numérique.
Il faut gérer le suivi des patients, la prise de rendez-vous, les rappels de médicaments et la messagerie sécurisée. Le respect absolu du RGPD et des directives de la CNIL est non négociable. On intègre donc des systèmes d'authentification biométrique stricts.
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 le Grand Est 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.
Un projet transfrontalier porte une contrainte de plus que les autres, et elle se règle mieux au début qu'à la fin.
En trente minutes, on peut décider si votre application est bilingue dès la première version ou si elle sort d'abord dans une seule langue — les deux réponses se défendent, mais il faut choisir consciemment. On regarde aussi ce que ça implique pour les textes qu'on oublie toujours : conditions d'utilisation, e-mails automatiques, fiche du store.
Sans engagement, et en français ou en anglais selon ce qui vous arrange.
En 30 minutes, vous saurez exactement par où commencer. Sans engagement. Sans jargon technique.
Réservez un appel gratuit →
30 minutes pour démarrer votre projet
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.