Mickael Romaniello
30 minutes, sans slides, rien à préparer.
Mickael Romaniello
30 minutes, sans slides, rien à préparer.
Un seul interlocuteur, du concept à la publication. 12 ans d'expérience. 15+ applications livrées.
En résumé : je construis des applications iOS et Android pour des clients à Bordeaux (257 068 habitants) et partout en Nouvelle-Aquitaine. Un seul interlocuteur, 12 ans d'expérience, livraison du concept à la publication en 8 à 16 semaines.
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 à Bordeaux 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.
Lancer sur les deux plateformes en même temps double le coût de la première version sans doubler ce qu'on apprend. Avec un budget contraint, commencer par une seule plateforme — celle où sont vos utilisateurs — permet de valider le produit, puis de porter l'autre en sachant quoi construire. L'ordre inverse coûte deux fois plus cher pour la même leçon.
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é à Bordeaux, commencer par iOS est souvent le meilleur choix.
Le facteur le plus important est la rentabilité.
En moyenne, les utilisateurs iOS dépensent davantage dans les applications 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.
Basé à Cannes, je travaille avec des clients partout en France et à l'international. Mais la distance ne change rien à mon niveau d'implication.
Depuis 12 ans, je crée des applications iOS et Android pour des PME et des startups en privilégiant le contact humain. Je m'imprègne de vos projets comme si c'étaient les miens. Vous avez mon numéro direct, on s'appelle quand c'est nécessaire, et on avance ensemble.
Le facteur le plus important pour réussir une application naît d'abord d'une bonne relation humaine. C'est l'essence même de mon approche.
Pour une activité bordelaise liée au vin, au tourisme ou à l'événementiel, l'année se décide sur quelques semaines. La bonne question à poser à un prestataire n'est donc pas son tarif, c'est sa disponibilité pendant votre saison. Un devis moins cher qui ne répond pas un samedi de juillet vous coûte bien davantage.
Ma réponse tient en trois règles, et je m'y tiens. On gèle les nouveautés deux semaines avant l'ouverture de votre saison : rien de neuf ne part en production juste avant le moment où tout doit marcher. Pendant la saison, on ne fait que corriger, avec un délai de réponse convenu à l'avance et écrit dans le devis. Après, on reprend le développement.
Ces règles ne tiennent que parce que je prends peu de projets en même temps. C'est l'arbitrage d'un indépendant : moins de clients, mais joignable au moment où ça compte. Une structure qui accepte tout ne peut pas promettre ça, et elle le sait.
Si votre activité n'a pas de pic de saison, ce paragraphe ne vous concerne pas — et tant mieux, ça simplifie le calendrier.
J'ai travaillé depuis Bordeaux pendant des années avant de m'installer à Cannes, et c'est la seule ville de cette liste dont je connais le tissu de l'intérieur. Concrètement, ça veut dire qu'on gagne la première demi-heure : je n'ai pas besoin qu'on m'explique ce qu'est la Bastide, pourquoi une entreprise des Chartrons ne fonctionne pas comme une entreprise de la rive droite, ni à quoi ressemble le calendrier d'une maison de négoce.
L'économie locale oriente le type de demandes, et j'en reçois surtout deux familles. Des applications de service pour une clientèle de passage — vin, tourisme, événementiel — et des outils internes pour des entreprises qui ont grandi plus vite que leurs logiciels. Les premières vivent sur la simplicité : un visiteur n'installe pas une application qui réclame un compte avant de montrer quoi que ce soit. Les secondes vivent sur la fiabilité, parce que si l'outil tombe, l'équipe s'arrête et ça se compte en heures perdues, pas en tickets.
La distance n'est plus un problème depuis longtemps, mais elle change une chose et il faut le dire : le cadrage. À distance, on décrit une application avec des mots et chacun se fait son image ; en face à face, on dessine sur une feuille et on voit tout de suite qu'on ne parlait pas du même écran. Je compense en travaillant sur des maquettes que vous manipulez très tôt, avant qu'une ligne de code soit écrite — c'est la feuille de papier, en plus précis. Et si le projet le justifie, je monte pour le lancement.
Sur la deuxième famille, celle des outils internes, il y a un cas qui revient si souvent qu'il vaut la peine d'être décrit : le tableur devenu ingérable. Il a très bien marché pendant des années, et il casse toujours sur les trois mêmes points — plusieurs personnes qui veulent écrire en même temps, des versions qui circulent par courriel sans qu'on sache laquelle fait foi, et des formules que plus personne dans l'entreprise ne sait expliquer. Une application règle les deux premiers presque gratuitement. Le troisième est le vrai travail, parce qu'il faut d'abord retrouver ce que le tableur faisait vraiment, et ça se fait avec la personne qui s'en sert, pas avec le fichier.
Sur l'argent, je ne donne pas de fourchette dans le vide, parce qu'un prix annoncé avant le cadrage est un chiffre inventé. Ce que je peux dire dès le premier appel, c'est comment ça se passe : trente minutes gratuites, puis un devis avec ce qui est dedans et ce qui n'y est pas. 30 % à la commande, le reste réparti par mois sur la durée du projet. Vous payez au rythme où le travail avance.
Quand un outil interne remplace un fichier devenu ingérable, le premier mois ne sert pas à concevoir l'application : il sert à retrouver ce que le fichier faisait vraiment. C'est presque toujours plus que ce qui est écrit dedans.
Les améliorations viennent après la bascule, quand l'usage réel les désigne.
La plupart des refus de l'App Store viennent de règles connues à l'avance et ignorées jusqu'au dernier moment — un paiement qui contourne le système d'Apple, une fonctionnalité inaccessible au relecteur, une déclaration de confidentialité incomplète. Le processus consiste donc à intégrer ces règles au cahier des charges plutôt qu'à les traiter comme une formalité de fin de projet.
Beaucoup de projets d'applications échouent à la porte de l'App Store.
Apple est sévère.
Le facteur le plus important pour réussir, c'est de comprendre leurs attentes.
Dès le début de notre collaboration à Bordeaux, on intègre les règles d'Apple dans votre cahier des charges.
Pas d'achats externes cachés. Pas de spam de notifications. Pas de tracking sans consentement.
Une fois les bases saines, le développement commence.
Je code en itérations. Cela veut dire que toutes les deux semaines, vous voyez le projet avancer.
Comment ? Via TestFlight.
Vous ouvrez TestFlight sur votre iPhone, vous téléchargez la mise à jour, et vous testez chez vous à Bordeaux.
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.
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 à Bordeaux.
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.
Dans le commerce, une application ne remplace pas la caisse : elle s'y branche. Ce qui décide de la faisabilité, c'est donc l'existence d'une interface ouverte sur votre logiciel de caisse ou de stock. Les usages qui marchent se comptent en gestes économisés, pas en fonctionnalités : consulter un stock depuis le rayon, encaisser une commande, scanner une étiquette.
Dans le commerce, une application ne remplace jamais la caisse : elle vient s'y brancher. C'est ce qui décide de la faisabilité, et la question se pose au premier rendez-vous — votre logiciel de caisse ou votre gestion de stock ouvre-t-il une interface, et à quelles conditions votre éditeur l'ouvre-t-il à un tiers ?
Une application n'a pas toujours besoin d'un serveur : tout dépend de si elle doit partager des données entre plusieurs appareils. Elle doit en revanche presque toujours prévoir l'absence de réseau, parce que le réseau manque plus souvent qu'on ne le croit. Le reste — appareil photo, position, notifications, connexion à un logiciel existant — est possible, sous réserve d'autorisations que l'utilisateur peut refuser.
Pas toujours, et c'est une bonne nouvelle pour le budget. Une application qui ne fait vivre que les données de son utilisateur — une liste, un suivi, un calcul — peut tout garder sur le téléphone et ne rien coûter en fonctionnement. Dès qu'il faut partager entre plusieurs personnes, synchroniser entre deux appareils, ou que vous devez voir les données de votre côté, il faut un serveur, et c'est une ligne de coût qui revient chaque mois.
Ça dépend entièrement de ce qu'on a décidé au départ, et c'est un des rares choix qu'on ne peut pas repousser. Une application peut garder ses données sur l'appareil, laisser travailler, puis se synchroniser dès que le réseau revient — sans que l'utilisateur appuie sur quoi que ce soit. C'est indispensable dès qu'on travaille en entrepôt, en sous-sol, en déplacement. Rajouté après coup, ça revient souvent à réécrire la moitié de l'application.
On choisit une limite, et ce choix a un prix. Supporter des versions anciennes du système veut dire tester davantage et se priver de certaines possibilités. On regarde qui sont vos utilisateurs : une application grand public et un outil interne déployé sur un parc connu n'ont pas la même réponse. La limite se relève ensuite, quand les statistiques d'usage montrent que plus personne n'est resté derrière.
Ça compte plus qu'on ne le croit, parce qu'une application volumineuse se fait désinstaller la première quand la mémoire manque. L'essentiel du poids vient rarement du code : ce sont les images et les polices embarquées. Charger les images depuis le serveur plutôt que les livrer dans l'application, et les servir à la bonne taille, suffit souvent à diviser le poids par deux. C'est du travail invisible et c'est celui qui garde l'application installée.
Techniquement, l'envoi ne coûte presque rien. Ce qui coûte, c'est ce qu'il faut autour : un serveur pour décider quoi envoyer à qui et quand, et un réglage fin pour ne pas devenir intrusif. C'est aussi le mécanisme le plus facile à gâcher — une notification inutile est la première cause de désinstallation, et une application désinstallée ne revient pas. On en envoie peu et on les rend utiles, ou on n'en envoie pas.
Oui, avec l'autorisation de l'utilisateur, et la façon de la demander compte autant que la fonction. Une permission réclamée au premier lancement, sans contexte, est refusée dans une grande partie des cas — et une fois refusée, elle est pénible à récupérer. Demandée au moment où la personne comprend pourquoi, elle est accordée. Apple exige d'ailleurs une explication écrite pour chaque permission, et un texte vague fait refuser l'application.
Par les stores, et pas instantanément : Apple et Google vérifient chaque version avant publication, et les téléphones se mettent à jour au rythme de leurs réglages. Il faut donc prévoir qu'une partie de vos utilisateurs restera plusieurs semaines sur une version ancienne. C'est pourquoi le serveur doit continuer à parler aux versions précédentes, et pourquoi on évite les changements qui cassent tout d'un coup.
Souvent, oui, et tout dépend d'une chose : votre éditeur fournit-il une interface d'accès documentée. Si oui, c'est du travail normal. S'il n'en fournit pas, ou s'il la facture au module, ou s'il refuse de l'ouvrir à un tiers, aucune application ne contournera ça proprement — les contournements existent et cassent à la première mise à jour de l'éditeur. C'est une question à poser à votre fournisseur avant de me poser la vôtre.
Un site peut s'installer sur l'écran d'accueil, fonctionner hors réseau et se lancer en plein écran, sans passer par un store. C'est une vraie troisième réponse, et elle est sous-conseillée parce qu'elle rapporte moins à qui la propose. Ses limites : les notifications restent bridées sur iPhone, l'accès aux capteurs est partiel, et vous n'êtes pas présent dans les stores — ce qui compte si vos clients vous y cherchent.
Seulement si vous avez un public dans une autre langue — et alors, il faut le prévoir dès la conception plutôt que l'ajouter. Ce n'est pas la traduction qui coûte, c'est la place : l'allemand allonge les libellés de moitié et fait déborder les boutons dessinés pour le français. Prévoir la place dès le départ ne coûte rien ; refaire les écrans après coup coûte plusieurs jours. Les textes légaux et la fiche du store comptent aussi.
J'ai travaillé depuis Bordeaux pendant des années. C'est la ville dont je connais le mieux le fonctionnement, et ça se sent dès le premier appel : on ne perd pas la demi-heure d'explication du contexte.
Trente minutes, sans engagement. On regarde ce que fait déjà votre outil actuel, ce qui casse, et ce qu'une application y changerait réellement — parfois la réponse est « pas grand-chose », et il vaut mieux l'entendre maintenant.
En 30 minutes, vous saurez exactement par où commencer.
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.