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 avez un projet d'application mobile à Strasbourg.
Et vous vous posez la question fatidique. iOS ou Android ?
Regardons les chiffres. Android détient la plupart des parts de marché mondial.
C'est gigantesque.
Sur les 284 677 habitants de Strasbourg, la grande majorité a un smartphone Android dans la poche.
Si vos clients sont sur Android, vous n'avez pas le choix. Vous devez y être.
Mais attention. Faire une application Android, ce n'est pas juste cocher une case.
C'est un écosystème avec ses propres règles. Ses propres standards de design.
Le facteur le plus important est de créer une expérience fluide, peu importe la marque du téléphone.
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.
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.
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 Grand Est.
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.
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.
Le commerce, le transport et le tourisme sont trois secteurs où Android domine le parc réel — appareils d'entreprise, terminaux partagés, téléphones d'entrée de gamme. Ce n'est pas une préférence de goût : c'est ce qu'il y a dans les mains des utilisateurs. Cela change les priorités techniques, à commencer par la tenue sur de petits appareils anciens.
Ces questions portent sur la diffusion et la sécurité : ouvrir progressivement plutôt que d'un coup, distribuer hors du store, couvrir la voiture ou la télévision, suivre les performances après le lancement. Le point important est qu'Android permet de sortir par étapes — quelques testeurs, un groupe fermé, puis le public — et que c'est la meilleure protection contre une mauvaise version.
Souvent, oui, de sensiblement. Les outils de dev sont gratuits. Mais attention, la fragmentation des appareils à Strasbourg peut augmenter le temps de test.
C'est un déploiement progressif. On lance d'abord l'application à la plupart des utilisateurs de France. S'il n'y a pas de crash majeur remonté par Crashlytics, on augmente. C'est une question de logique et de sécurité.
Oui, c'est une excellente façon de garder votre application visible pour vos utilisateurs dans la région Grand Est.
Oui, c'est l'avantage clé d'Android. On peut installer une application via un simple fichier (APK). Idéal pour des outils internes à Strasbourg.
L'essentiel de mon expertise est sur mobile et tablette. Mais l'architecture de base permet d'envisager ces extensions à terme.
J'utilise des outils comme Proguard pour masquer le code, et je sécurise toutes les communications avec vos serveurs de Strasbourg.
Moins qu'Apple (beaucoup de rejets au premier envoi chez la pomme). Mais leurs règles sur la vie privée sont devenues très strictes.
Centrale. On applique le Material Design 3. L'application s'adaptera même aux couleurs du système de l'utilisateur.
Nous utilisons Google Analytics for Firebase et la Google Play Console pour analyser les usages à Strasbourg.
Oui, je suis indépendant. Vous parlez directement au technicien qui code votre projet pour Strasbourg. Pas d'intermédiaire.
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.