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) en 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 une idée d'application.
On se pose. On respire.
Si votre cible à Strasbourg cherche le haut de gamme, le choix de la plateforme n'est pas un détail.
Le facteur le plus important, c'est de savoir où se trouve la valeur.
Les utilisateurs iOS dépensent 2x plus in-app que les utilisateurs Android.
L'écosystème Apple attire une clientèle habituée à payer pour la qualité, les abonnements et les services premium.
Si vous voulez créer une app iPhone à Strasbourg qui génère des revenus solides, vous devez viser l'App Store.
Mais attention, on ne rentre pas chez Apple comme dans un moulin.
Lancer une application coûte de l'argent et du temps.
Faut-il lancer sur iOS et Android en même temps? Ou commencer par iOS?
Si vous avez un budget serré à Strasbourg, commencer par iOS est souvent le meilleur choix.
Le facteur le plus important est la rentabilité.
Les utilisateurs iOS dépensent 2x plus in-app que les utilisateurs Android.
Ils sont plus enclins à payer pour des abonnements, des services premium et des achats intégrés.
En développant d'abord sur iPhone, on valide votre modèle économique plus rapidement.
De plus, l'écosystème matériel est maîtrisé.
Il y a une poignée de modèles d'iPhone récents.
Cela réduit considérablement le temps de développement et de test par rapport à Android et ses milliers de modèles.
On peut se concentrer sur l'essentiel: la valeur pour l'utilisateur.
Une interface claire, des performances optimales, zéro bug.
Une fois que l'application iOS cartonne à Strasbourg et que les revenus rentrent, on utilise ce budget pour financer sereinement la version Android.
Spoiler: c'est la stratégie qu'ont suivie Instagram et Clubhouse à leurs débuts.
Le développement iOS, c'est concevoir le produit parfait pour la clientèle la plus exigeante, avant de l'adapter au reste du monde.
Le point essentiel : le prix dépend de la complexité technique sous le capot, pas du nombre de pages.
Je construis des applications mobiles comme un artisan construit une maison. Avec des fondations solides.
J'exerce ce métier depuis 12 ans depuis Cannes, en concevant des applications iOS et Android faites pour durer. Je refuse le travail bâclé. L'avantage clé de cette méthode ? Votre application ne s'effondrera pas à la première mise à jour d'Apple ou de Google.
Je crée des outils propres, faciles à maintenir et prêts à évoluer avec votre PME ou votre startup. Un travail fait avec soin, c'est un investissement rentable sur le long terme.
Vous lancez votre projet à Strasbourg.
Et vous vous demandez sûrement avec qui travailler pour concevoir votre application mobile.
C'est la première grande décision. Certains pensent que pour réussir, il faut absolument une grande agence au coin de la rue. D'autres croient qu'il faut sous-traiter à l'équipe la moins chère possible à l'étranger.
Les deux options ont de sérieux inconvénients.
Une grosse agence va assigner votre projet à un développeur junior que vous n'avez jamais rencontré. Une équipe offshore va vous livrer du code illisible, avec trois semaines de retard, sans aucune responsabilité.
Le facteur le plus important dans la réussite d'une application, ce n'est pas seulement le code. C'est la communication.
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.
Invent Better commence par retirer, pas par ajouter. Une application qui fait une seule chose correctement se lance en deux mois; une qui en fait cinq à moitié ne se lance jamais. Sachant que une grande partie des fonctionnalités prévues à l'avance ne sont jamais utilisées, la question utile n'est pas « est-ce que ce serait bien » mais « est-ce que quelqu'un utilise l'application sans ça ».
Faire tourner une application sur iOS demande de la précision.
L'avantage clé de développer en natif, c'est l'accès total aux capacités du téléphone.
Pas d'intermédiaire. Pas de ralentissement.
Le moteur principal, c'est Swift.
Un langage de programmation robuste qui garantit des performances maximales.
Couplé à SwiftUI, nous construisons l'interface de votre projet à Strasbourg.
C'est ce qui donne ce côté magique aux applications Apple: les transitions douces, les boutons qui réagissent instantanément.
Si votre application rame, l'utilisateur la supprime.
Il clique. Il quitte. Il oublie.
C'est pourquoi je privilégie toujours les outils fournis directement par Apple.
Publier une application chez Apple demande d'anticiper leurs règles strictes.
Spoiler: on ne découvre pas les contraintes à la fin du projet.
Le point essentiel, c'est de préparer le terrain dès le départ.
D'abord, la conception.
On valide ensemble que votre idée respecte les guidelines d'Apple pour votre cible à Strasbourg.
Ensuite, les démarches administratives.
Il vous faut un compte Apple Developer. Et un numéro DUNS pour l'ouvrir au nom de votre entreprise.
Pendant que l'administration tourne, je développe.
C'est la phase de code intensif en Swift et SwiftUI.
Très vite, on passe sur TestFlight.
C'est l'application d'Apple qui permet d'installer des versions de test sur votre propre téléphone.
On peut même inviter vos premiers testeurs à Strasbourg pour récolter leurs avis avant la sortie.
Puis vient l'étape de l'App Store Connect.
C'est le tableau de bord où l'on configure votre fiche App Store.
Il faut renseigner avec une précision chirurgicale les étiquettes de confidentialité (ce que l'app traque ou non).
Enfin, la soumission.
Un processus transparent, itératif, et sans surprise. Vous voyez l'application grandir chaque semaine.
Un client dans le domaine du fitness voulait créer une application premium sur abonnement.
Son modèle économique reposait entièrement sur la conversion des utilisateurs gratuits en payants.
En résumé, l'écosystème Apple était la cible parfaite.
Pourquoi? Parce que les utilisateurs iOS dépensent 2x plus in-app que les utilisateurs Android.
Nous avons construit l'application autour d'une intégration parfaite d'Apple Pay et de StoreKit.
Si l'écran de paiement fait peur, l'utilisateur s'en va.
Il clique. Il quitte. Il oublie.
Nous avons rendu l'abonnement aussi simple qu'un double clic sur le bouton latéral de l'iPhone avec Face ID.
Cependant, Apple scrute les abonnements à la loupe lors de la validation.
Apple traite 100 000+ soumissions par semaine et rejette sans pitié les applications dont les conditions tarifaires sont floues.
En résumé : on ne construit pas tout. On construit ce dont vos utilisateurs ont vraiment besoin.
Une application iOS native coûte généralement sensiblement de plus qu'un équivalent web ou hybride. La raison tient aux exigences d'Apple: ses règles de design demandent du soin sur chaque écran, chaque bouton et chaque animation, et la revue de l'App Store refuse ce qui ne s'y conforme pas. Ce surcoût achète surtout moins de risque de refus.
C'est la question que tout le monde se pose à Strasbourg.
Soyons clairs: une application iOS native coûte généralement sensiblement plus cher qu'une application web ou hybride.
Pourquoi?
Le facteur le plus important, c'est le niveau d'exigence d'Apple.
Les règles de design d'Apple imposent un soin particulier à chaque écran, chaque bouton, chaque animation.
On ne peut pas faire d'à-peu-près.
Ensuite, il y a la préparation pour le Store.
près d’une soumission sur quatre est rejetée.
Il ne s'agit pas juste de coder une application.
Le facteur le plus important, c'est d'utiliser les forces du téléphone pour votre business.
L'iPad et l'iPhone sont les écrans de lecture par excellence.
Si vous proposez du contenu exclusif, les utilisateurs iOS dépensent 2x plus in-app que les utilisateurs Android.
Vendre des abonnements via le système natif d'Apple est le meilleur moyen de fidéliser des lecteurs à Strasbourg.
L'iPhone possède les meilleurs capteurs de réalité augmentée du marché (ARKit).
Placer un meuble virtuel dans un salon, ou faire visiter un appartement en 3D devient incroyablement fluide.
C'est un effet waouh garanti pour vos clients.
Les pass Apple Wallet sont magiques.
Le client achète son billet, et il se retrouve directement dans son application Wallet, avec un QR code prêt à être scanné à l'entrée de votre événement à Strasbourg.
Plus besoin de fouiller dans ses mails.
On simplifie la vie de l'utilisateur au maximum.
Une condition et trois critères. La condition, c'est la fréquence : une application vit sur un écran d'accueil, et une icône ouverte une fois par an ne se rembourse jamais. Si vos clients reviennent chaque semaine, il suffit ensuite d'un critère sur trois — l'application se sert du téléphone lui-même, elle doit fonctionner sans réseau, ou elle a une raison légitime de vous rappeler. Sinon, un site fait le même travail pour moins cher, et je vous le dirai.
Une idée d'application ne se brevette pas en tant que telle ; ce qui se protège, c'est le nom — une marque déposée — et le code, protégé par le droit d'auteur dès son écriture. En pratique, le risque n'est presque jamais le vol : c'est de mettre six mois à sortir pendant qu'un autre sort en deux. Si le sujet vous inquiète, un accord de confidentialité se signe avant le premier appel, sans difficulté.
Non, et c'est même plus sain de commencer sans. Le cadrage porte sur ce que fait l'application et pour qui ; l'habillage vient après, et il vient mieux quand on sait déjà quels écrans existent. Si vous avez déjà une identité, on s'en sert. Sinon, la première version peut être sobre et lisible — ce qui n'est pas un pis-aller : beaucoup d'applications gagneraient à le rester.
Oui, et c'est souvent la meilleure dépense du projet. Des maquettes cliquables qu'on met entre les mains de dix personnes révèlent en une semaine ce qu'un développement de trois mois révélerait trop tard. On voit où les gens hésitent, ce qu'ils ne trouvent pas, ce dont ils se fichent. C'est aussi ce qui permet de retirer des fonctions avant de les payer plutôt qu'après.
Oui, toujours, et c'est un point sur lequel je ne transige pas. Les deux comptes sont payants et se créent au nom de votre entreprise ; je travaille dessus avec un accès délégué. Une application publiée sous le compte d'un prestataire est une application que vous ne contrôlez pas : vous ne pouvez ni la mettre à jour ni la transférer sans lui. La création prend un peu de temps côté Apple, autant s'y prendre tôt.
Le plus tard possible. Un écran d'inscription en ouverture est la première cause d'abandon : la personne n'a encore rien vu et vous lui demandez déjà quelque chose. La bonne règle est de laisser essayer, puis de demander un compte au moment où il devient utile — pour retrouver ses données sur un autre appareil, pour payer, pour être reconnu. La plupart des applications gagnent des utilisateurs juste en déplaçant cet écran.
La règle simple : ne collectez que ce dont vous vous servez vraiment, dites-le clairement, et laissez la personne revenir en arrière. Concrètement, ça veut dire une politique de confidentialité lisible, un consentement demandé au bon moment plutôt qu'en bloc au démarrage, et un moyen de supprimer son compte depuis l'application — Apple l'exige. Les fiches de confidentialité des deux stores doivent aussi correspondre à la réalité de ce que fait l'application.
Oui, et il y a une règle à connaître avant de bâtir un modèle économique dessus : tout ce qui est consommé dans l'application passe par le système de paiement d'Apple ou de Google, qui prélève une commission. Vendre un service consommé ailleurs — une prestation physique, une commande livrée — se paie normalement. La différence n'est pas anecdotique, elle change le prix que vous devez afficher.
Rien. Pas de cahier des charges, pas de présentation, pas de budget arrêté. Trente minutes suffisent si vous pouvez répondre à deux questions : qui va s'en servir, et qu'est-ce que ça leur fait gagner. Si vous avez déjà des captures d'écran d'applications qui vous plaisent, prenez-les — montrer ce qu'on aime est plus rapide que le décrire. Le reste, c'est mon travail de le poser.
Trois signaux, et je les dis pendant l'appel plutôt qu'au troisième mois. Si personne dans l'équipe ne pourra répondre à mes questions pendant le projet, ça n'avancera pas. Si le budget couvre le développement mais rien de l'année suivante, l'application mourra doucement. Et si l'objectif est de rassurer un investisseur plutôt que de servir un utilisateur, une maquette coûte cent fois moins cher et fait le même effet.
Prêt à lancer votre application à Strasbourg?
Vous avez l'idée. Vous connaissez votre marché dans la Grand Est. Maintenant, il faut passer à l'action.
Mais pas n'importe comment. L'avantage clé de travailler ensemble, c'est la clarté. Je ne vous vendrai pas de fonctionnalités inutiles. Je ne vous ferai pas de grandes promesses sans lendemain.
On se pose. On respire.
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.