Mickael Romaniello
30 minutes, sans slides, rien à préparer.
Mickael Romaniello
30 minutes, sans slides, rien à préparer.
Du concept à la publication. Un expert dédié, 12 ans d'expérience.
En résumé : développement application ios à Lausanne (139 111 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.
Ces questions arbitrent entre des options : natif ou hybride, abonnement ou achat, quel outil d'interface, quel niveau de maintenance après la publication. Le critère de décision est le même partout — ce que vous devrez pouvoir modifier dans un an. Le natif coûte un peu plus au départ et beaucoup moins quand l'application vit longtemps.
Pour un rendu premium, le natif est roi. L'avantage clé, c'est l'expérience utilisateur qui sera toujours supérieure avec les technologies d'Apple par rapport à un outil hybride.
Non, TestFlight est gratuit. Il est inclus dans votre abonnement de développeur Apple à un abonnement annuel.
près d’une soumission sur quatre est rejetée. Souvent pour des bugs non traités, un manque de valeur, ou le non-respect des règles de paiement d'Apple.
Oui, si vous souhaitez que l'application s'affiche au nom de votre entreprise de Lausanne sur le Store. Si vous publiez en nom propre, il n'est pas nécessaire.
Bien sûr. C'est même recommandé. En moyenne, les utilisateurs iOS dépensent davantage dans les applications que les utilisateurs Android. L'écosystème s'y prête parfaitement.
Cela dépend de la complexité. Une V1 simple peut prendre 4 à 8 semaines de code, plus le temps incompressible de création de compte et de validation par Apple.
Oui. iOS évolue chaque année en septembre. Il faut s'assurer que votre code reste compatible avec les nouvelles règles et les nouveaux iPhone.
C'est l'outil fourni par Apple pour dessiner les écrans. C'est ce qui nous permet de coder rapidement des interfaces magnifiques et réactives.
Oui, mais Apple exige que l'on justifie très clairement à l'utilisateur pourquoi nous en avons besoin. C'est une question de logique et de respect de la vie privée.
C'est exigeant. Apple traite 100 000+ soumissions par semaine. C'est pour cela que je gère cette étape pour vous, pour garantir un lancement réussi à Lausanne.
Vous avez une idée d'application.
Si votre cible à Lausanne 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.
En moyenne, les utilisateurs iOS dépensent davantage dans les applications 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 à Lausanne 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.
Il faut respecter leurs règles. Leurs standards de design. Leurs exigences techniques.
Publier sur l'App Store demande de passer une revue humaine, et c'est la partie que les projets sous-estiment. Les motifs de refus les plus fréquents sont connus à l'avance : un paiement qui contourne le système d'Apple, une fonctionnalité que le relecteur ne peut pas atteindre, une déclaration de confidentialité incomplète. Ce filtre écarte beaucoup d'applications bâclées, et c'est une bonne nouvelle pour les autres.
Tout le monde veut son application sur le store d'Apple.
Mais publier une application iOS, c'est un vrai parcours.
L'avantage clé de ce processus complexe, c'est qu'il filtre les mauvaises applications.
D'abord, il y a la création du compte développeur Apple. Et là, surprise.
Si vous êtes une entreprise à Lausanne, il vous faut un numéro DUNS.
Le DUNS, c'est la carte d'identité internationale de votre entreprise.
L'obtenir peut prendre entre 2 et 4 semaines. Mieux vaut le savoir dès le premier jour.
Ensuite, on code. Proprement. En respectant les règles.
Puis vient la phase de test avec TestFlight.
TestFlight, c'est la salle de répétition de votre application.
On peut inviter jusqu'à 10 000 testeurs avant la sortie officielle.
La peur numéro un, quand on lance un projet d'application, c'est de perdre le contrôle : on signe un devis, on confie son idée, et on n'entend plus rien pendant trois mois. Le fonctionnement décrit ici existe pour que ça n'arrive pas.
Trois règles, les mêmes sur chaque projet :
Vous testez l'application sur votre téléphone toutes les deux semaines.
Lausanne vit beaucoup autour de l'EPFL et des projets qui en sortent, et les demandes y sont souvent très techniques mais jeunes côté produit. Le travail utile n'est alors pas d'écrire du code : c'est de choisir les trois écrans qui prouvent que l'idée tient, et de laisser tout le reste pour plus tard.
Les projets issus de la recherche ont un profil reconnaissable. La partie difficile — l'algorithme, le modèle, le traitement du signal — est déjà résolue et souvent brillamment. Ce qui manque est tout ce qu'il y a autour : comment un utilisateur arrive dessus, ce qu'il comprend en dix secondes, ce qui se passe quand ça ne marche pas. C'est frustrant à entendre quand on a passé deux ans sur le cœur technique, mais c'est là que se joue l'adoption, et c'est en général là que je suis le plus utile.
Une conséquence pratique : sur ces projets, je conseille presque toujours de ne pas construire l'application complète tout de suite. Un démonstrateur qui fait une seule chose, bien, sur un seul système d'exploitation, montré à vingt vraies personnes, apprend plus en trois semaines qu'un développement de six mois. Et il coûte une fraction du prix, ce qui compte quand le financement vient d'une bourse ou d'un premier tour et qu'il faut montrer quelque chose avant le suivant.
Une question à régler avant la première ligne de code sur un projet issu d'un laboratoire : à qui appartient quoi. Le travail de recherche a souvent été financé par l'institution, parfois publié, parfois déjà lié à une convention de spin-off. Le code que j'écris par-dessus, lui, vous appartient — mais il repose sur une brique dont les droits ne sont pas toujours clairs. Ça se démêle en une conversation au départ, et ça devient très coûteux à démêler quand un investisseur pose la question au moment de la levée.
Lausanne partage avec Genève les contraintes suisses sur les données, et un projet issu du milieu académique ajoute souvent les siennes : données de recherche, parfois données de santé, parfois participants dont le consentement a été recueilli dans un cadre précis. Ces contraintes ne sont pas négociables et il vaut mieux les poser sur la table au premier rendez-vous, parce qu'elles déterminent où l'application a le droit d'envoyer quoi, et donc son architecture entière.
Une application peut être développée vite et pour peu cher. Ce qui coûte, c'est la suite : un code écrit sans structure devient impossible à modifier, et la moindre évolution demande de tout reprendre. Invent Better facture le travail qui rend la deuxième version possible — des tests, une architecture lisible, et un code qu'un autre développeur peut reprendre.
Il est tout à fait possible de développer une application très vite et pour vraiment pas cher.
Il suffit d'ignorer les règles de base, de copier-coller des morceaux de code trouvés sur internet, et de croiser les doigts pour que ça tienne. Le jour de la présentation à Lausanne, l'application aura l'air de fonctionner.
Mais le vernis va craquer très rapidement.
Dès que vous aurez plus de dix utilisateurs en même temps, le système va ralentir. Sur mobile, la patience est très courte. Et la lenteur, c'est perçu comme un bug.
Pire, l'application va planter en pleine nuit. Et là, l'utilisateur ne pardonne pas.
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 canton de Vaud, sans me demander.
Et si une version manque, vous le voyez tout de suite. C'est le but.
Une application vendue par abonnement se joue sur le passage du gratuit au payant, et ce passage est encadré par Apple : le paiement doit se faire par son système, et la commission prélevée se situe entre 15 % et 30 % selon votre chiffre d'affaires. Ce calcul se fait avant de fixer vos prix, pas après le lancement.
Prenons un cas fréquent : une application de fitness vendue 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 en moyenne davantage dans les applications 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.
Une application iOS native coûte plus cher 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.
Publier sur l'App Store suppose un programme développeur Apple à 99 € par an, renouvelable. Apple indique dans son rapport de transparence 2024 avoir examiné 7,77 millions de soumissions et en avoir rejeté 1,93 million — près d'une sur quatre.
C'est la question que tout le monde se pose à Lausanne.
Soyons clairs : une application iOS native coûte 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.
Voyage haut de gamme, outils professionnels et services à la demande ont un point commun : leurs utilisateurs paient. Sur ces marchés, une application iOS bien faite rentabilise plus vite qu'une couverture large et approximative. Le bon ordre est presque toujours iOS d'abord, Android quand le modèle est validé.
Certains business modèles s'accordent naturellement avec l'univers Apple.
En résumé, voici pourquoi ces secteurs privilégient l'iPhone.
Une clientèle qui voyage avec un budget conséquent possède souvent un iPhone.
L'interface native iOS permet d'offrir une expérience de réservation fluide, des notifications riches avec des images, et une géolocalisation ultra-précise.
Apple traite 100 000+ soumissions par semaine, et les applications de voyage fluides sont toujours mises en avant.
La continuité entre le Mac, l'iPad et l'iPhone est la grande force d'Apple.
Si vous créez un outil de productivité pour les entreprises à Lausanne, l'application iOS est la porte d'entrée.
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.
Prêt à lancer votre application à Lausanne ?
Vous avez l'idée. Vous connaissez votre marché dans le canton de Vaud. 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.
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.