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 dédié.
En résumé : je construis des applications iOS et Android pour des clients à Marseille (870 018 habitants) et partout en Provence-Alpes-Côte d'Azur. Un seul interlocuteur, 12 ans d'expérience, livraison du concept à la publication en 8 à 16 semaines.
Vous avez un problème avec votre application actuelle ? Note en chute libre ? Lenteurs inexpliquées ? Il clique. Il quitte. Il oublie.
C'est le pire scénario. Et c'est exactement là que j'interviens. Fort de 12 ans d'expérience, j'aide les entreprises depuis Cannes à sauver leurs projets iOS et Android mal engagés. Je fais le diagnostic, on identifie ce qui bloque, et on répare pour offrir une expérience enfin fluide à vos utilisateurs.
En résumé : ne laissez pas un mauvais départ gâcher votre idée. On corrige le tir ensemble.
Regardez autour de vous dans les rues de Marseille.
Que voyez-vous dans les mains des gens ?
Des Samsung, des Xiaomi, des Google Pixel.
Android est partout. C'est le système d'exploitation le plus utilisé au monde.
Vos futurs clients passent en moyenne 4,8 heures par jour sur leur téléphone.
Le point essentiel, c'est que votre entreprise doit être là où se trouve l'attention.
Dans leur poche.
Mais lancer une application sur le Play Store n'est pas une promenade de santé.
Beaucoup d'entreprises de France pensent qu'il suffit d'avoir une bonne idée.
Spoiler : une bonne idée mal exécutée ne vaut rien.
Il clique. Il quitte. Il oublie.
Commencer par Android ou par iOS dépend de deux choses : où sont vos utilisateurs, et quel est votre budget. Android donne accès au parc le plus large, notamment sur les appareils d'entreprise et les téléphones d'entrée de gamme. iOS concentre les utilisateurs qui dépensent le plus. Il n'y a pas de bonne réponse générale, seulement une bonne réponse pour votre marché.
Souvent, on me demande s'il faut commencer par iOS ou par Android pour un projet à Marseille.
La réponse dépend de votre cible et de votre budget.
L'avantage clé d'Android, c'est sa portée massive.
Surtout dans les marchés émergents ou pour le grand public.
Mais il y a une différence fondamentale avec Apple.
Apple contrôle tout. Ils ont une vingtaine de modèles d'iPhone en circulation. C'est facile à tester.
Android, c'est le grand ouest.
Google indique qu'il y a plus de 24 000 modèles d'appareils Android actifs.
Certains ont des écrans minuscules. D'autres tournent sur des versions Android vieilles de cinq ans.
Cette fragmentation rend les tests beaucoup plus complexes et coûteux.
Marseille a une économie de port et de PME familiales, et beaucoup de projets mobiles y naissent d'un besoin logistique très concret plutôt que d'une idée de startup. C'est un bon point de départ : quand l'application doit résoudre un problème que vous vivez tous les jours, le cahier des charges s'écrit tout seul et la première version est utilisable en quelques semaines.
Deux heures de train séparent Cannes de Marseille, et c'est ce qui rend le paragraphe précédent autre chose qu'une figure de style : aller regarder quelqu'un travailler une matinée est un aller-retour dans la journée, pas une expédition à budgéter. Sur un projet de terrain, c'est la dépense la plus rentable du cadrage — une heure passée dans un entrepôt m'apprend ce que trois réunions ne diront pas, parce que personne ne pense à décrire ce qu'il fait sans y penser.
Ces projets-là ont un avantage rare : l'utilisateur, c'est vous, ou quelqu'un dans le bureau d'à côté. On n'a pas besoin d'imaginer ce que ferait un client hypothétique, on peut aller le regarder travailler pendant une heure. C'est la chose la plus utile que je puisse faire au début d'un projet de terrain, et cela révèle presque toujours quelque chose que personne n'avait pensé à me dire — un geste, un document papier qui traîne, une étape qu'on fait de tête et qui n'apparaît dans aucun processus écrit.
Le port impose ses propres contraintes. Les zones portuaires et les entrepôts sont des trous de réseau, et les hangars métalliques bloquent le signal aussi bien qu'une cave. Une application de suivi qui suppose une connexion permanente ne survit pas à sa première journée réelle. On construit donc l'inverse : tout fonctionne hors ligne, les données s'accumulent sur le téléphone, et la synchronisation se fait toute seule dès qu'il y a du réseau, sans que l'utilisateur ait à y penser ni à appuyer sur un bouton.
Marseille a aussi beaucoup d'échanges avec le Maghreb et l'Italie, et cela ressort dans les projets : une clientèle qui ne lit pas toujours le français, des adresses qui ne rentrent pas dans un formulaire français, des numéros de téléphone étrangers qu'un champ trop strict refuse. Ce sont de petits détails, mais chacun perd des utilisateurs à l'inscription, et ils coûtent quelques heures au début contre plusieurs jours à corriger après le lancement.
À Marseille, la plupart des entreprises qui me contactent ont trois options en tête : un étudiant en informatique pour quelques milliers d'euros, une agence pour dix fois plus, ou un indépendant. Les trois se défendent, mais pas sur le même projet. Voici comment je fais la différence, y compris quand elle ne joue pas en ma faveur.
L'étudiant est un bon choix quand l'outil reste à l'intérieur de l'entreprise, qu'il ne passe pas par les stores, qu'il ne touche pas de données personnelles, et que si l'application s'arrête un lundi matin, personne n'est bloqué. Beaucoup de premiers outils entrent dans cette case, et le dire coûte peu.
Ça devient un mauvais choix dès qu'un de ces quatre points saute. Une publication sur l'App Store engage des comptes, des certificats et des renouvellements annuels. Des données clients engagent votre responsabilité, pas celle de l'auteur du code. Et une application dont dépend le travail quotidien de vos équipes a besoin de quelqu'un qui réponde au mois d'août.
L'agence, elle, se justifie quand il faut plusieurs personnes en parallèle pour tenir une date. Si ce n'est pas votre cas, l'essentiel de la facture paie des couches intermédiaires.
Sur un projet de terrain, le premier mois commence par une matinée sur place. Regarder quelqu'un travailler une heure apprend ce que trois réunions ne diront pas, parce que personne ne pense à décrire ce qu'il fait sans y penser.
Si cette personne continue à s'en servir sans qu'on le lui demande, le projet est bon. Sinon, on a perdu un mois au lieu de six.
Le travail à distance repose sur l'écrit plutôt que sur la réunion. Vous recevez une version installable toutes les deux semaines et un compte rendu de ce qui a changé ; les questions se traitent dans votre outil habituel, quand chacun est disponible. Cette façon de faire supprime les réunions de trois heures sans supprimer l'information — c'est même l'inverse, tout reste écrit et consultable.
Je travaille avec des clients partout, de la France jusqu'au Canada.
Peu importe que vous soyez basé à Marseille ou ailleurs, la méthode est la même.
L'avantage clé, c'est la communication asynchrone et transparente.
Pas besoin de réunions de trois heures qui ne mènent à rien.
On utilise des outils comme Slack, Trello ou Jira. Vous voyez exactement où j'en suis.
Chaque semaine, vous recevez une mise à jour sur votre téléphone Android.
Vous testez la nouvelle fonctionnalité directement depuis votre bureau à Marseille.
S'il y a un comportement bizarre sur un certain modèle de Samsung, vous me le signalez et je le corrige.
Une application de terrain se juge sur ce qu'elle fait sans réseau. Les techniciens travaillent en sous-sol, dans des bâtiments métalliques, sur des zones mal couvertes : les relevés doivent s'enregistrer sur l'appareil et se synchroniser tout seuls plus tard. Cette décision se prend au début du projet, parce qu'elle change toute l'architecture.
Parfois, l'application Android n'est pas destinée au grand public.
J'ai travaillé pour une société d'intervention technique dont les équipes parcourent toute la région Provence-Alpes-Côte d'Azur.
Leurs techniciens avaient besoin d'un outil pour faire des relevés de données sur le terrain. Souvent dans des sous-sols à Marseille, là où il n'y a aucun réseau.
L'avantage clé d'Android ici, c'est le choix matériel.
Plutôt que d'acheter des iPad hors de prix, l'entreprise a acheté des tablettes Android durcies à bas coût. Parfaites pour les chantiers.
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.
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 ?
Avant la première ligne de code, quatre choses se décident : faut-il vraiment une application ou un site suffit-il, à quel nom sont ouverts les comptes développeur, quelles données personnelles l'application va traiter, et ce qui entre dans la première version. Le logo et la charte graphique peuvent attendre. Ces quatre points-là, non : ils changent l'architecture et le budget.
Une condition et trois critères. La condition, c'est la fréquence : une application vit sur un écran d'accueil, et une icône ouverte une fois par an ne se rembourse jamais. Si vos clients reviennent chaque semaine, il suffit ensuite d'un critère sur trois — l'application se sert du téléphone lui-même, elle doit fonctionner sans réseau, ou elle a une raison légitime de vous rappeler. Sinon, un site fait le même travail pour moins cher, et je vous le dirai.
Une idée d'application ne se brevette pas en tant que telle ; ce qui se protège, c'est le nom — une marque déposée — et le code, protégé par le droit d'auteur dès son écriture. En pratique, le risque n'est presque jamais le vol : c'est de mettre six mois à sortir pendant qu'un autre sort en deux. Si le sujet vous inquiète, un accord de confidentialité se signe avant le premier appel, sans difficulté.
Non, et c'est même plus sain de commencer sans. Le cadrage porte sur ce que fait l'application et pour qui ; l'habillage vient après, et il vient mieux quand on sait déjà quels écrans existent. Si vous avez déjà une identité, on s'en sert. Sinon, la première version peut être sobre et lisible — ce qui n'est pas un pis-aller : beaucoup d'applications gagneraient à le rester.
Oui, et c'est souvent la meilleure dépense du projet. Des maquettes cliquables qu'on met entre les mains de dix personnes révèlent en une semaine ce qu'un développement de trois mois révélerait trop tard. On voit où les gens hésitent, ce qu'ils ne trouvent pas, ce dont ils se fichent. C'est aussi ce qui permet de retirer des fonctions avant de les payer plutôt qu'après.
Oui, toujours, et c'est un point sur lequel je ne transige pas. Les deux comptes sont payants — 99 € par an chez Apple, renouvelables, et 25 $ une seule fois chez Google Play — et se créent au nom de votre entreprise ; je travaille dessus avec un accès délégué. Une application publiée sous le compte d'un prestataire est une application que vous ne contrôlez pas : vous ne pouvez ni la mettre à jour ni la transférer sans lui. La création prend un peu de temps côté Apple, autant s'y prendre tôt.
Le plus tard possible. Un écran d'inscription en ouverture est la première cause d'abandon : la personne n'a encore rien vu et vous lui demandez déjà quelque chose. La bonne règle est de laisser essayer, puis de demander un compte au moment où il devient utile — pour retrouver ses données sur un autre appareil, pour payer, pour être reconnu. La plupart des applications gagnent des utilisateurs juste en déplaçant cet écran.
La règle simple : ne collectez que ce dont vous vous servez vraiment, dites-le clairement, et laissez la personne revenir en arrière. Concrètement, ça veut dire une politique de confidentialité lisible, un consentement demandé au bon moment plutôt qu'en bloc au démarrage, et un moyen de supprimer son compte depuis l'application — Apple l'exige. Les fiches de confidentialité des deux stores doivent aussi correspondre à la réalité de ce que fait l'application.
Oui, et il y a une règle à connaître avant de bâtir un modèle économique dessus : tout ce qui est consommé dans l'application passe par le système de paiement d'Apple ou de Google, qui prélève entre 15 % et 30 % selon votre chiffre d'affaires annuel. Vendre un service consommé ailleurs — une prestation physique, une commande livrée — se paie normalement. La différence n'est pas anecdotique, elle change le prix que vous devez afficher.
Rien. Pas de cahier des charges, pas de présentation, pas de budget arrêté. Trente minutes suffisent si vous pouvez répondre à deux questions : qui va s'en servir, et qu'est-ce que ça leur fait gagner. Si vous avez déjà des captures d'écran d'applications qui vous plaisent, prenez-les — montrer ce qu'on aime est plus rapide que le décrire. Le reste, c'est mon travail de le poser.
Trois signaux, et je les dis pendant l'appel plutôt qu'au troisième mois. Si personne dans l'équipe ne pourra répondre à mes questions pendant le projet, ça n'avancera pas. Si le budget couvre le développement mais rien de l'année suivante, l'application mourra doucement. Et si l'objectif est de rassurer un investisseur plutôt que de servir un utilisateur, une maquette coûte cent fois moins cher et fait le même effet.
Vous avez un besoin concret plutôt qu'une idée d'application : quelque chose que vous faites tous les jours à la main et qui vous coûte des heures.
C'est le meilleur point de départ possible, et trente minutes suffisent souvent à savoir si ça vaut le coup. On regarde le geste réel — le papier qui traîne, l'appel passé deux fois, la double saisie du soir — et on estime ce qu'une première version devrait couvrir. Souvent moins que vous ne pensez.
Marseille est à deux heures de Cannes : si le projet avance, je viens regarder sur place plutôt que de deviner.
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.