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 à Strasbourg (284 677 habitants), dans le Grand Est, 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.
Vous avez une idée d'application.
Si votre cible à Strasbourg 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 à Strasbourg 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 à Strasbourg, 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.
Le point essentiel : le prix dépend de la complexité technique sous le capot, pas du nombre de pages.
Je ne suis pas juste un développeur. Je suis aussi celui qui va vous dire quand une fonctionnalité est une mauvaise idée.
En 12 ans d'expérience, j'ai vu trop de projets échouer à cause d'applications trop compliquées. Mon approche depuis Cannes ? On simplifie. Je travaille avec des startups et des PME pour construire des applications iOS et Android qui vont droit au but.
Je suis votre partenaire produit. Si une idée ne sert pas vos utilisateurs, je vous le dirai. En résumé :
Une application strasbourgeoise s'adresse souvent à des utilisateurs français et allemands, et ce ne sont pas les mêmes utilisateurs avec un dictionnaire entre eux. Le prestataire à chercher est celui qui refuse d'en faire la moyenne : il pose les questions d'usage avant de traduire quoi que ce soit.
Ces questions en valent la peine parce qu'elles changent des écrans, pas des mots. Sur quel ton on s'adresse à l'utilisateur — le vouvoiement allemand n'est pas un détail de politesse, il fixe le registre de toute l'interface. Quels moyens de paiement vos utilisateurs allemands s'attendent à trouver, qui ne sont pas forcément ceux de vos utilisateurs français. Comment une adresse, une date et un numéro de téléphone s'écrivent de chaque côté.
Rien de tout cela ne se règle en fin de projet par une passe de traduction. Ce sont des décisions de conception, et les prendre au départ coûte quelques jours contre plusieurs semaines de reprise.
Le test qui tranche est simple : faites essayer la maquette à un germanophone réel avant la première ligne de code. Dix minutes, et vous saurez si le projet est bilingue ou seulement traduit.
Strasbourg travaille des deux côtés de la frontière, et cela se voit dans les projets : bilinguisme français-allemand dès la première version, parfois une contrainte réglementaire européenne, et des utilisateurs qui changent de langue en cours de route. Prévoir cela au départ coûte quelques jours ; l'ajouter après coûte une refonte.
L'allemand est la langue qui casse le plus d'interfaces, et ce n'est pas une plaisanterie de développeur. Les mots composés allemands sont longs : un bouton qui affiche « Paramètres » sur trois centimètres affiche parfois quelque chose de deux fois plus large en allemand, et le texte déborde, se coupe, ou pousse le reste de l'écran hors du cadre. La seule parade fiable est de concevoir chaque écran pour la version la plus longue du texte dès la maquette, et de tester dans les deux langues à chaque étape plutôt qu'une fois à la fin.
Le changement de langue en cours d'usage est l'autre détail que peu de gens anticipent. Un utilisateur strasbourgeois peut très bien installer l'application en français puis basculer en allemand pour montrer un écran à un collègue. Si le changement oblige à redémarrer l'application, à se reconnecter, ou s'il perd le formulaire à moitié rempli, l'expérience est mauvaise. Cela se prévoit dans la façon dont l'application charge ses textes, et c'est presque gratuit si on y pense avant.
Le bilinguisme a un coût qu'on oublie systématiquement au chiffrage : les textes qui ne sont pas de l'interface. Conditions d'utilisation, politique de confidentialité, formulaires de consentement, e-mails automatiques, messages d'erreur du serveur, fiche du store. Une application franco-allemande a besoin de tout cela dans les deux langues, et ce sont précisément les textes qu'on écrit en dernier, dans l'urgence, souvent la veille de la soumission. Les prévoir dès le début coûte quelques heures ; les traduire en catastrophe coûte un report de publication, parce qu'une politique de confidentialité approximative se refuse à la validation.
Strasbourg abrite aussi des institutions européennes et un tissu de sous-traitants qui travaillent pour elles, ce qui apporte une exigence documentaire supérieure à la moyenne. Sur ces projets, ce qui prend du temps n'est pas le développement mais la validation : plusieurs interlocuteurs, des délais de réponse longs, et des demandes de traçabilité sur les décisions. Je le prends en compte dans le planning en livrant par petits morceaux validables, plutôt qu'en promettant une grande version dans six mois qui restera bloquée en revue.
Sur un projet bilingue, le premier mois sert à décider ce que veut dire « bilingue » ici. La réponse n'est pas la même selon que vos deux publics font la même chose dans l'application ou deux choses différentes.
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 Grand Est, sans me demander.
Et si une version manque, vous le voyez tout de suite. C'est le but.
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.
Je ne donne pas de fourchette avant le cadrage, parce qu'un prix annoncé avant de savoir ce qu'on construit est un chiffre inventé. En revanche, la mécanique, elle, se dit dès le premier appel : trente pour cent à la commande, le reste réparti par mois sur la durée du projet. Vous payez au rythme où le travail avance.
Deux dépenses tombent en plus du développement, et elles reviennent : le programme développeur d'Apple à 99 € par an, et le compte Google Play Console à 25 $ une fois. Les deux se prennent à votre nom, pas au mien.
Sur un projet court, d'un mois ou deux, le découpage est plus simple : la moitié au démarrage, la moitié à la livraison. Sur un projet qui court sur plusieurs mois, la mensualisation protège les deux côtés — vous ne financez jamais du travail qui n'a pas été fait, et je ne travaille jamais trois mois avant de facturer.
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 à Strasbourg, l'iPhone est indispensable.
Apple Pay permet à l'utilisateur de payer en un regard avec Face ID.
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 à Strasbourg, 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.
Un projet transfrontalier porte une contrainte de plus que les autres, et elle se règle mieux au début qu'à la fin.
En trente minutes, on peut décider si votre application est bilingue dès la première version ou si elle sort d'abord dans une seule langue — les deux réponses se défendent, mais il faut choisir consciemment. On regarde aussi ce que ça implique pour les textes qu'on oublie toujours : conditions d'utilisation, e-mails automatiques, fiche du store.
Sans engagement, et en français ou en anglais selon ce qui vous arrange.
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.