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.
En résumé : pour votre projet à Lyon (515 695 habitants), en Auvergne-Rhône-Alpes, 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.
Regardez autour de vous dans une salle de réunion à Lyon.
Que posent les gens sur la table ?
Des iPhone.
Si vous ciblez des professionnels, des décideurs ou des cadres, l'écosystème Apple est incontournable.
En résumé, l'iPhone est souvent le terminal par défaut du monde professionnel.
L'environnement est sécurisé, fermé et contrôlé.
Créer une application iOS native, c'est s'assurer que votre produit s'intègre parfaitement dans le quotidien de ces utilisateurs.
C'est utiliser les codes visuels auxquels ils sont habitués.
Si votre interface est brouillonne, ils n'auront pas confiance en votre service.
Je vous aide à concevoir et développer une application iOS à Lyon qui respire le professionnalisme.
Une app qui répond instantanément, sans friction, et qui valorise votre image de marque.
Développer pour iOS, c'est accepter un cadre. Apple contrôle le matériel, le système et le store, ce qui a deux effets opposés : le comportement des appareils est prévisible et le travail de compatibilité s'en trouve réduit, mais les règles de publication sont strictes et non négociables. On construit donc avec ces règles en tête dès la conception.
Le développement iOS, ce n'est pas juste coder pour un téléphone différent.
C'est adopter une philosophie entière.
Celle d'Apple.
Apple contrôle tout. Le matériel (l'iPhone, l'iPad) et le logiciel (iOS).
Le point essentiel, c'est que ce contrôle strict est une immense force pour nous.
Contrairement à Android où il faut tester sur des milliers d'écrans différents, l'univers iOS est plus restreint.
Cela nous permet d'atteindre un niveau de finition exceptionnel pour chaque écran de votre application à Lyon.
Pour coder, nous utilisons les langages officiels : Swift et SwiftUI.
SwiftUI, c'est le standard moderne d'Apple. C'est propre, rapide et pensé pour créer des interfaces fluides.
Mais le code ne fait pas tout.
Une bonne app iOS doit respecter les Human Interface Guidelines d'Apple.
Il y a 12 ans, je lançais ma toute première application mobile. Depuis, les téléphones ont changé, mais mon métier est resté le même : transformer des idées en outils concrets.
Depuis mon bureau à Cannes, j'accompagne des entrepreneurs et des PME pour concevoir des applications iOS et Android qui ont un vrai sens. Je ne code pas juste pour coder. Je cherche à comprendre votre métier, vos utilisateurs et vos vrais besoins.
Mon objectif est simple. Créer une application que les gens auront envie d'utiliser tous les jours. Le point essentiel : on construit pour eux, pas pour nous. On en parle ?
À Lyon, beaucoup d'entreprises qui me contactent ont déjà une DSI ou un développeur interne. La bonne question n'est donc pas « qui fait tout », mais « qui fait quoi ». Je prends la partie mobile, votre équipe garde ce qu'elle connaît, et on écrit la frontière entre les deux avant de commencer.
Cette frontière tient en trois lignes. Vos serveurs et vos règles métier restent chez vous. L'application et la couche qui lui parle sont de mon côté. Et on se met d'accord dès la première semaine sur ce que chacun attend de l'autre — par écrit, pas oralement, parce que c'est exactement là que les projets à deux équipes se perdent.
Le deuxième critère compte autant et il est rarement posé : est-ce que votre équipe pourra reprendre le projet quand je ne serai plus là ? C'est le but, pas un accident. Le code est volontairement ennuyeux, parce que les astuces brillantes coûtent cher à relire. Le dépôt est à votre nom dès le premier jour, et il contient de quoi reconstruire l'application sans moi.
Un outil métier vit dix ans. Le prestataire qui l'a écrit, rarement. Un projet qui ne survit pas au départ de son auteur n'est pas terminé, il est en sursis.
Lyon est la ville française où je rencontre le plus d'entreprises qui ont déjà un logiciel métier et veulent le prolonger sur mobile. Ce n'est pas le même travail qu'une application partant de zéro : l'essentiel se joue sur l'API existante et sur ce qu'on accepte de ne pas porter. On commence toujours par cette liste-là, avant de dessiner le moindre écran.
La raison pour laquelle cette liste passe en premier est simple : une application mobile qui essaie de reproduire tout un logiciel de gestion échoue toujours. L'écran fait six pouces, l'utilisateur est debout, il a une main libre et trente secondes. Ce qui marche sur mobile, c'est trois ou quatre actions faites cinquante fois par jour — pointer une intervention, valider une livraison, consulter une fiche client, photographier un document. Le reste reste sur le poste de travail, et c'est très bien.
Le vrai risque technique n'est presque jamais l'application. C'est l'API. Beaucoup de logiciels métier ont une interface qui a été écrite pour un site web interne, sur un réseau d'entreprise rapide, avec des réponses énormes parce que la bande passante ne coûtait rien. Branchée sur un téléphone en 4G dans un parking souterrain, la même interface met huit secondes à répondre et l'application paraît cassée alors qu'elle fonctionne parfaitement. La première semaine d'un projet lyonnais part souvent là-dedans : mesurer ce que l'existant renvoie vraiment, et décider ce qu'on adapte côté serveur plutôt que de bricoler côté mobile.
Une question à poser avant tout le reste, et qui décide souvent du projet : à qui appartient l'accès à ce logiciel métier ? Si l'éditeur fournit une API documentée, tout va bien. S'il n'en fournit pas, ou s'il la facture au module, ou s'il refuse de l'ouvrir à un tiers, aucune application mobile ne contournera ça proprement — et les contournements existent, mais ils cassent à la première mise à jour de l'éditeur. Je pose la question au premier appel plutôt qu'au deuxième mois, parce que la réponse change le budget, le calendrier, et parfois la décision de faire ou non.
Lyon a aussi une forte présence de la santé et de la chimie, deux secteurs où l'hébergement des données n'est pas un choix libre. Si vos données relèvent de la santé, elles doivent être chez un hébergeur certifié, et cela se décide avant la première ligne de code, pas au moment de la mise en production. Je pose la question au premier rendez-vous, parce que la réponse change l'architecture entière.
Quand l'application se branche sur un logiciel existant, le premier mois se joue sur le serveur, pas sur l'écran. On mesure d'abord ce que l'existant renvoie vraiment, parce que c'est ça qui décide de ce qui est faisable — et du budget.
Et votre équipe a accès au dépôt depuis le premier jour, pas à la livraison.
Les règles d'Apple ne se découvrent pas à la fin. Elles entrent dans la conception dès les maquettes : ce qu'une application a le droit de demander à l'utilisateur, comment un abonnement doit être présenté, quelles données doivent être déclarées. Anticiper coûte quelques heures au départ ; découvrir une règle au moment de la soumission coûte un report de publication.
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 à Lyon.
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.
Une application de santé sur iOS a un avantage rare : le système fournit déjà un cadre pour les données de santé et leur partage avec la montre. Cela évite d'inventer un stockage à soi, et ça déplace la difficulté ailleurs — vers les autorisations demandées à l'utilisateur et vers l'hébergement des données côté serveur, qui, lui, n'est pas fourni.
Le secteur de la santé demande une rigueur absolue.
Voici un cas qui revient souvent : une application de suivi médical connectée.
Sur iOS, la santé a son propre écosystème : HealthKit.
Le but était de synchroniser les données de l'Apple Watch (rythme cardiaque, sommeil) avec une interface patient simple et sécurisée.
L'avantage clé ici, c'est la protection des données proposée par Apple.
Nous avons construit une architecture totalement native en Swift.
Les devis pour une application iPhone varient parfois du simple au triple, ce qui indique surtout qu'ils ne décrivent pas le même travail. Un prix très bas signifie en général ni réelle maîtrise de Swift, ni connaissance concrète de la revue App Store. Le coût d'un refus n'est pas le redéveloppement : c'est la date de lancement que vous manquez.
Sur les abonnements et achats faits dans l'application, Apple prélève 30 %, ramenés à 15 % pour les éditeurs réalisant moins d'un million de dollars par an, via son App Store Small Business Program.
Vous allez trouver des devis du simple au triple à Lyon pour une application iOS.
Si quelqu'un vous propose une application iPhone à un prix dérisoire, méfiez-vous.
Créer pour Apple demande une véritable expertise technique en Swift et une connaissance parfaite de l'App Store.
En résumé, on ne bidouille pas une application iOS.
Santé, commerce haut de gamme et finance se retrouvent sur iOS pour la même raison : leurs utilisateurs y sont, et ils dépensent. À cela s'ajoutent des garanties que la plateforme facilite — chiffrement du stockage, authentification biométrique, contrôle strict de ce qu'une application peut lire. Ce sont des arguments réglementaires autant que commerciaux.
Le choix de la plateforme dépend aussi de votre secteur d'activité.
L'avantage clé d'iOS, c'est qu'il propose des outils natifs puissants pour certaines industries.
C'est le domaine roi sur iPhone.
Avec HealthKit, l'application peut lire les pas, le rythme cardiaque ou le sommeil enregistrés par l'Apple Watch.
C'est un niveau d'intégration impossible à imiter ailleurs.
Mais attention, près d’une soumission sur quatre est rejetée et Apple est intraitable sur la gestion des données de santé.
Si vous vendez du haut de gamme à Lyon, l'iPhone est indispensable.
Apple Pay permet à l'utilisateur de payer en un regard avec Face ID.
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 Lyon 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 à Lyon.
Un projet mobile lyonnais commence presque toujours par la même question, et elle n'est pas technique : qu'est-ce qu'on ne met pas dans l'application ?
En trente minutes, on peut y répondre assez précisément. On regarde ce que vos utilisateurs font debout, une main prise, en trente secondes — c'est ça qui va sur le téléphone, et le reste peut rester sur le poste de travail. On repère aussi tout de suite si votre logiciel existant peut être branché ou non, parce que c'est ce qui décide du budget.
Sans engagement. Si la conclusion est que vous n'avez pas besoin d'une application, je vous le dirai aussi.
En 30 minutes, vous saurez exactement par où commencer. Sans engagement. Sans jargon technique.
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.