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 à Genève (203 856 habitants), 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.
Sur iPhone, votre calendrier n'est pas tout à fait le vôtre.
Apple publie une version majeure d'iOS chaque automne, et ses utilisateurs l'installent vite — beaucoup plus vite que sur les autres plateformes. En quelques semaines, l'essentiel de votre public à Genève est passé au nouveau système.
C'est une bonne nouvelle : vous n'avez pas à supporter éternellement de vieilles versions. C'en est une moins bonne si personne ne s'en occupe, parce que chaque version change quelque chose — une autorisation qui se demande autrement, un composant d'interface qui se dessine différemment, une règle du store qui se durcit.
Une application iOS se prévoit donc sur deux calendriers : le vôtre, et celui d'Apple.
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 à Genève.
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.
Le point essentiel : le prix dépend de la complexité technique sous le capot, pas du nombre de pages.
Mon rôle premier est de protéger votre budget. Saviez-vous qu’une grande partie des fonctionnalités d'une application ne sont jamais utilisées ?
Depuis Cannes, j'aide mes clients à éviter ce gaspillage énorme. Avec 12 ans d'expérience sur iOS et Android, je sais où l'argent doit aller. On coupe le superflu pour se concentrer sur ce qui apporte une vraie valeur à votre cible.
L'avantage clé : une application qui sort vite, qui teste le marché, et qui coûte le juste prix. Construisons d'abord l'essentiel.
Vous lancez votre projet à Genève.
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.
Genève est une ville d'organisations internationales et de finance, où l'application doit souvent passer une revue de sécurité avant d'exister. Autant le savoir dès le début : cela oriente le choix de l'hébergement, la façon de stocker les données et le temps à prévoir. Découvrir cette exigence au moment de livrer, c'est perdre un trimestre.
Ce que demande concrètement une revue de sécurité varie, mais quelques questions reviennent presque toujours : où sont physiquement stockées les données, qui y a accès, comment elles sont chiffrées au repos et en transit, comment les accès sont révoqués quand quelqu'un part, et ce qui se passe si un téléphone est perdu. Aucune de ces questions n'est difficile si l'architecture a été pensée pour y répondre. Toutes deviennent coûteuses si l'application a été écrite d'abord et auditée ensuite.
La localisation des données mérite une mention particulière, parce que la Suisse n'est pas dans l'Union européenne et a sa propre loi sur la protection des données, révisée récemment. Selon votre secteur et vos clients, l'hébergement en Suisse peut être une exigence ferme plutôt qu'une préférence. Cela change le choix du fournisseur, parfois le coût mensuel, et cela se décide avant d'écrire la première ligne — migrer une base de données d'un pays à un autre après le lancement est faisable mais désagréable.
Une revue de sécurité réclame des documents autant que du code, et c'est ce qui surprend le plus. On demande en général un schéma des flux de données, la liste nominative des services tiers utilisés et de ce qu'ils voient, la politique de conservation, et la procédure prévue en cas de fuite. Rien de tout cela ne s'improvise à la fin. Je le prépare pendant le développement plutôt qu'après, parce qu'un dossier réuni en catastrophe fait perdre plus de temps à la revue que le développement lui-même.
Genève a aussi un coût du travail élevé et un vivier de développeurs très demandé, ce qui explique une bonne partie des sollicitations que j'y reçois. Travailler avec quelqu'un basé en France sur un projet genevois est courant et fonctionne bien : même fuseau horaire, même langue, aucune contrainte de déplacement pour l'essentiel du travail. Il faut simplement traiter dès le devis les questions de facturation transfrontalière et de TVA, plutôt que de les découvrir à la première facture.
Avec Invent Better, la personne qui comprend votre projet est celle qui l'écrit. Pas de commercial, pas de chef de projet intermédiaire, pas de transmission entre trois équipes. Vous parlez au développeur, du premier appel jusqu'à la mise en ligne. Sur un premier produit, où l'essentiel se décide dans les six premières semaines, cette proximité vaut plusieurs semaines de calendrier.
On ne bricole pas une application iOS.
Pour offrir une expérience fluide à vos utilisateurs de Genève, il faut utiliser les bons outils.
En résumé, voici ce qu'il se passe sous le capot.
Je développe principalement en Swift.
C'est le langage moderne créé par Apple pour remplacer l'ancien Objective-C.
C'est rapide, sécurisé, et ça évite de nombreux crashs.
Pour construire vos écrans, j'utilise SwiftUI.
C'est l'avenir du design chez Apple.
Cela permet de créer des interfaces animées et réactives qui s'adaptent parfaitement à toutes les tailles d'iPhone et d'iPad.
Pour le stockage des données de vos utilisateurs à Genève, j'intègre Core Data ou CloudKit.
Le jour de la publication n'est pas la fin du projet, c'est le premier jour où l'application rencontre de vrais utilisateurs. La suite se prépare avant, pas après : sans elle, les premiers retours arrivent et personne n'est là pour y répondre.
La première semaine, on surveille. Pas les téléchargements — les plantages, les écrans où les gens s'arrêtent, les endroits où ils reviennent en arrière. Un rapport de plantage vaut mille suppositions, et les trois premiers jours en apprennent plus que trois mois de réunions.
La deuxième semaine, on corrige ce que ces retours ont montré, et on publie une mise à jour. Elle est presque toujours nécessaire, et ce n'est pas un échec : aucune première version ne survit intacte au contact de son public à Genève.
Ensuite le rythme ralentit, mais ne s'arrête pas. Apple sort une version majeure d'iOS chaque automne, Google une d'Android chaque année, et chacune casse quelque chose — une autorisation qui change de forme, une bibliothèque qui n'est plus signée, un écran qui se décale.
On décide ensemble du niveau de suivi avant le lancement, pas au premier incident.
Un processus transparent, itératif, et sans surprise. Vous voyez l'application grandir chaque semaine.
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.
En résumé : on ne construit pas tout. On construit ce dont vos utilisateurs ont vraiment besoin.
Le développement n'est pas la seule dépense d'une application, et les autres reviennent tous les ans. Les connaître avant de signer change la façon dont vous dimensionnez le projet — et évite la mauvaise surprise du douzième mois, qui est toujours la plus mal reçue.
Publier coûte de l'argent aux deux endroits. Le programme développeur d'Apple se renouvelle chaque année ; le compte développeur Google Play se paie une fois, à l'inscription. Ces comptes doivent être à votre nom, pas au mien : c'est votre application, et un compte au nom du prestataire est le piège le plus courant du secteur.
Viennent ensuite l'hébergement et les services que l'application consomme. Sur un projet de Genève qui démarre, la facture est modeste — mais elle tombe tous les mois, et elle grandit avec le nombre d'utilisateurs.
Si vous vendez dans l'application, Apple et Google prélèvent entre 15 % et 30 % selon votre chiffre d'affaires et le programme auquel vous êtes éligible. Ça se calcule avant de fixer vos prix, pas après.
Presse, immobilier et événementiel vivent sur l'image et sur l'instant. Ces trois secteurs demandent un affichage rapide de contenus lourds et une notification qui arrive au bon moment. iOS y aide par la régularité de son parc : peu de modèles, peu de versions du système, donc un comportement prévisible.
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 en moyenne davantage dans les applications que les utilisateurs Android.
Vendre des abonnements via le système natif d'Apple est le meilleur moyen de fidéliser des lecteurs à Genève.
L'iPhone possède les meilleurs capteurs de réalité augmentée du marché (ARKit).
Ces questions tournent autour d'une même idée : Apple filtre, et ce filtre est plutôt une bonne nouvelle. Le soin apporté à l'interface, la clarté des règles et le passage par un test avant publication écartent la plupart des applications bâclées. Un rejet n'est pas un échec : il arrive à tout le monde, il est motivé, et il se corrige.
Parce que les utilisateurs iPhone ont l'habitude de l'excellence. Si l'application ne respecte pas les règles d'Apple, il clique. Il quitte. Il oublie.
Oui. Apple traite 100 000+ soumissions par semaine avec des validateurs humains qui chassent les bugs et les interfaces confuses.
Vous pouvez inviter jusqu'à 10 000 testeurs externes via TestFlight avant même que l'application ne soit publique sur le Store.
Le point essentiel, c'est la performance. Le natif garantit la meilleure fluidité et l’accès à tous les composants de l’iPhone (appareil photo, Face ID, etc.).
Je peux auditer l'ancien code, mais pour l'avenir de votre entreprise à Genève, la norme est désormais de tout migrer vers Swift.
Il faut en faire la demande en ligne. C'est gratuit, mais les délais varient de quelques jours à un mois. Nous le ferons dès le premier jour du projet.
L'écosystème Apple est reconnu comme l'un des plus sûrs. Le code natif en Swift élimine d'emblée beaucoup de failles de sécurité courantes.
Oui. Les utilisateurs iOS dépensent en moyenne davantage dans les applications que les utilisateurs Android.
Pas de panique. On lit le rapport du validateur, on corrige le problème (souvent une simple ligne dans la description), et on resoumet.
Oui. L'application vous appartient. Elle sera publiée sur votre propre compte développeur Apple, pas sur le mien.
Pendant que vous hésitez, vos concurrents à Genève avancent.
Le monde du mobile va vite. Très vite. Aujourd'hui, l’essentiel du trafic web mondial provient des mobiles. Si vous repoussez sans cesse la création de votre application, d'autres prendront votre place dans le canton de Genève.
Mais attention, il ne faut pas confondre vitesse et précipitation. Lancer une application instable est la pire des stratégies.
En résumé : il faut faire vite, mais il faut surtout faire bien. ⏳
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.