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 à Paris (2 165 423 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 portent toutes sur la même inquiétude : que se passe-t-il si ça tourne mal. La réponse tient à la façon dont le projet est monté. Le dépôt de code et les comptes des stores sont à votre nom dès le premier jour, donc rien ne dépend de ma présence. Un refus d'Apple est une étape ordinaire, pas une impasse : on corrige, on resoumet.
C'est la question qu'on ne pose pas à un indépendant et qu'on devrait poser en premier. Ma réponse tient en trois choses concrètes : le code est sur un dépôt à votre nom depuis le premier jour, les décisions sont écrites plutôt que gardées en tête, et les accès aux stores sont les vôtres. Un autre développeur peut reprendre sans moi. Ce n'est pas une promesse, c'est une organisation — et c'est vérifiable dès la première semaine.
À vous, entièrement, et dès le début plutôt qu'à la fin. Le dépôt est ouvert à votre nom, vous y avez accès pendant le développement, et vous n'avez rien à réclamer au moment de la livraison. Ça vaut aussi pour les maquettes et les comptes de stores. Le seul cas où ça se discute, c'est si vous voulez réutiliser une brique que j'ai écrite ailleurs — je le dis avant de l'utiliser, pas après.
On corrige et on resoumet, et c'est compris dans le projet. Un refus n'est pas un accident rare : Apple indique avoir examiné 7,77 millions de soumissions en 2024 et en avoir rejeté 1,93 million, soit près d'une sur quatre (rapport de transparence App Store 2024). Apple vérifie des dizaines de points, et les motifs les plus fréquents sont prévisibles — un compte de test qui ne fonctionne pas, une permission demandée sans explication, une fonction annoncée qui n'existe pas encore. Je les traite avant de soumettre, ce qui ne garantit rien mais évite l'essentiel. Vous n'avez pas à gérer l'échange avec le validateur.
Oui, et il faut le savoir avant de bâtir dessus. Apple et Google peuvent retirer une application qui enfreint leurs règles, et ils changent ces règles régulièrement. Les retraits brutaux touchent surtout des applications qui collectent des données sans le dire, copient une marque, ou n'ont pas été mises à jour depuis longtemps. C'est aussi pourquoi une présence web reste utile à côté : elle, personne ne peut vous la retirer.
Elle continue de fonctionner, et vous gardez tout ce qu'il faut pour la faire vivre : le code, les accès, les clés de signature, la documentation. Je fais une passation écrite plutôt qu'un simple transfert de fichiers — ce qui a été construit, pourquoi, où sont les pièges. C'est une demi-journée de travail qui évite des semaines de rétro-ingénierie à celui qui reprend, et je préfère qu'on se quitte comme ça.
Avant tout chiffrage, il faut une liste : le dépôt de code, les comptes App Store Connect et Google Play — à votre nom, pas à celui du prestataire —, la clé de signature Android, les accès à l'hébergement et à la base de données. La clé de signature est la pièce critique : sans elle, l'application ne peut plus être mise à jour, elle doit être republiée sous un autre identifiant et vous repartez de zéro en installations.
Là où vous décidez, et c'est une décision à prendre tôt parce qu'elle est coûteuse à défaire. Pour la plupart des projets, un hébergeur européen suffit et simplifie le RGPD. Pour des données de santé, l'hébergement doit être certifié, ce qui restreint le choix et pèse sur le budget — mieux vaut l'apprendre au premier appel qu'au moment de la mise en ligne. Dans tous les cas, les accès sont à votre nom.
Je le sais avant que vous receviez l'avis. Un outil de suivi des plantages remonte l'erreur avec l'appareil, la version du système et l'endroit exact du code — sans donnée personnelle. Sans ça, on découvre les bugs par les commentaires du store, c'est-à-dire trop tard et en public. C'est une des rares choses que je mets en place systématiquement, même sur un petit projet, parce que ça ne coûte presque rien et que ça change tout.
Côté code, oui : chaque version publiée est marquée, et on peut repartir de l'état exact d'une livraison. Côté stores, c'est plus nuancé — Google permet de suspendre le déploiement d'une version, Apple demande de publier une correction. La vraie protection est en amont : un déploiement progressif sur Android, une phase de test réelle, et des mises à jour assez petites pour qu'on sache ce qui a cassé.
Elle marche, puis elle se dégrade lentement, et un jour elle ne se lance plus. iOS sort une version majeure chaque septembre depuis 2013, Android chaque année, et chacune casse quelque chose. Une application laissée seule dix-huit mois demande souvent plus de travail à remettre debout que ce qu'aurait coûté son entretien. Vous pouvez arrêter — c'est votre choix et je ne vous ferai pas payer un abonnement pour rien — mais autant décider en le sachant.
Vous avez une idée d'application.
Si votre cible à Paris 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 à Paris 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 à Paris, 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.
À Paris, trouver un prestataire n'est pas le problème : il y en a des centaines. La vraie question est de savoir combien de personnes se glisseront entre ce que vous dites en réunion et ce qui finit dans le code. Avec moi, aucune. Vous parlez à celui qui écrit l'application, du premier appel jusqu'à la mise en ligne.
Les projets parisiens arrivent rarement sur une page blanche. Il y a déjà une charte graphique, un site, parfois une équipe design, souvent une direction des systèmes d'information. L'application ne remplace rien de tout ça : elle vient s'y brancher.
Ça change ce qu'il faut chercher chez un prestataire. Pas quelqu'un qui veut tout refaire à sa façon, mais quelqu'un qui accepte vos contraintes comme point de départ : reprendre votre système de design au lieu d'en inventer un, s'appuyer sur votre authentification existante plutôt que de créer une base de comptes parallèle, et remplir le questionnaire de sécurité que votre DSI enverra — parce qu'elle l'enverra.
Il reste une limite, et autant la poser tout de suite. Si votre DSI exige que le code vive sur son infrastructure, avec ses outils et ses procédures de revue, c'est faisable, mais ça déplace le calendrier et le devis. C'est la contrainte qui change le plus de choses, et c'est aussi celle qui se découvre le plus souvent trop tard.
Paris est le seul marché français où vous serez comparé à des studios de trente personnes avant même d'avoir parlé. Cela change la conversation : la question n'est plus « savez-vous faire », elle est « pourquoi vous plutôt qu'eux ». La réponse honnête, c'est qu'un studio vous facture une équipe et vous donne un chef de projet ; moi, vous avez la personne qui écrit le code. Sur un premier produit, cette différence se compte en semaines.
Elle se compte aussi en fidélité de l'information. Dans une agence, ce que vous dites en réunion est reformulé par un chef de projet, transmis à un lead technique, puis redécoupé en tickets pour des développeurs qui ne vous ont jamais entendu parler. À chaque étape, un peu d'intention se perd. Quand vous m'expliquez pourquoi un écran doit fonctionner d'une certaine façon, c'est la personne qui va l'écrire qui vous écoute, et qui peut vous répondre dans la même phrase que ça coûtera trois jours de plus ou que ça n'a pas de sens techniquement.
L'inverse est vrai aussi, et il faut l'entendre. Une personne seule ne remplace pas une équipe de trente. Je ne prends pas un projet qui a besoin de quatre développeurs en parallèle pour tenir une date, je ne fais pas de design d'interface au niveau d'un studio spécialisé, et si votre application doit sortir sur iOS, Android, web et télévision connectée en même temps, il vous faut autre chose que moi. Je le dis au premier rendez-vous plutôt qu'au troisième mois.
Sur la distance, autant être précis, parce que c'est la première objection et qu'elle est légitime. Nice–Paris est un vol d'une heure et demie avec plusieurs départs par jour : si un projet demande d'être dans la salle — un comité, un atelier de cadrage, une présentation à des investisseurs — j'y suis dans la matinée. Le reste du temps, un studio parisien travaille lui aussi par visioconférence avec ses clients parisiens, et personne ne s'en plaint. La vraie question n'est pas où je suis, c'est combien de personnes séparent votre phrase du code.
Le tissu parisien a une autre particularité : beaucoup de porteurs de projet y arrivent avec un investisseur ou un comité à convaincre, et le calendrier est dicté par une levée de fonds ou un salon. Dans ce cas, l'objectif n'est pas une application complète, c'est une démonstration qui tient debout devant quelqu'un qui n'aidera pas. On construit alors dans l'ordre inverse de l'habitude : les trois écrans que la personne en face verra, solides et rapides, et le reste en façade assumée.
Sur un projet parisien, le premier mois ne sert pas à coder : il sert à faire tomber les contraintes qui, découvertes en semaine dix, coûtent un trimestre. Trois semaines de cadrage, une de mise en route, et vous avez quelque chose d'installable avant la fin du mois.
À partir de là, une version toutes les deux semaines, sans exception.
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 en Île-de-France, sans me demander.
Et si une version manque, vous le voyez tout de suite. C'est le but.
Équiper des commerciaux d'une tablette pose un problème simple et souvent mal traité : ils travaillent chez le client, sans connexion garantie. L'application doit donc fonctionner entièrement hors ligne et synchroniser au retour. Le vrai sujet n'est pas l'affichage mais la règle qui tranche quand deux personnes ont modifié la même fiche chacune de leur côté.
Le B2B, ce n'est pas forcément que du web.
Le cas type : une entreprise industrielle qui veut équiper ses commerciaux sur le terrain.
Ils avaient tous des iPad fournis par l'entreprise.
Le point essentiel : il fallait une application robuste, capable de fonctionner sans connexion internet dans des entrepôts.
Oubliez les solutions web hybrides qui saccadent.
Nous sommes partis sur du développement iOS entièrement natif.
L'utilisation de Core Data a permis de stocker tout le catalogue produit en local sur l'iPad.
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 à Paris 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.
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 à Paris.
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.
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 avez un projet d'application à Paris, et probablement déjà deux ou trois propositions de studios sur le bureau.
Trente minutes suffisent à voir si ma façon de travailler correspond à la vôtre. On ne parlera pas de technologie : on regardera ce que l'application doit faire la première année, ce que votre DSI va exiger, et ce qui doit exister pour la démonstration que vous avez en tête.
Vous repartez avec un avis franc, y compris si cet avis est qu'un studio vous conviendra mieux. Sans engagement, et sans relance ensuite.
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.