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.
870 018 habitants vivent à Marseille.
Et si vous regardez autour de vous dans la rue, dans les cafés, dans les transports de Provence-Alpes-Côte d'Azur, vous ferez un constat très simple. Tout le monde a les yeux rivés sur son smartphone.
Ce n'est plus une simple tendance. C'est la norme absolue de votre pays.
Aujourd'hui, l’essentiel du trafic web mondial provient des appareils mobiles. Et ce chiffre ne fait qu'augmenter. Pourtant, de nombreuses entreprises à Marseille continuent de fonctionner avec de simples sites web, souvent lents et mal adaptés aux petits écrans.
Spoiler : si le chargement dépasse trois secondes, l'utilisateur s'en va. Il clique. Il quitte. Il oublie. 📱
Le vocabulaire du métier cache une réalité simple. Le natif désigne une application écrite avec les outils officiels d'Apple et de Google. L'hybride désigne un code unique adapté aux deux. Le back-end désigne le serveur, et l'API la façon dont l'application lui parle. Ce qui compte pour vous n'est pas le mot mais la conséquence : le coût, la vitesse et ce que vous pourrez modifier ensuite.
Trois façons de construire, trois conséquences :
Mon rôle est de vous guider vers celui qui correspond à vos ambitions à Marseille, sans vous faire payer une Ferrari s'il vous faut une citadine fiable.
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.
Travailler à distance ne pose pas de problème de qualité, il pose un problème d'organisation. La réponse tient en trois habitudes : un canal direct où vous m'écrivez sans passer par personne, une version installable toutes les deux semaines, et une note écrite après chaque décision. C'est ce qui remplace le fait d'être dans le même bureau, et ça fonctionne mieux que des réunions longues.
Vous n'avez pas besoin d'être dans le même bureau pour construire une excellente application.
Aujourd'hui, l'économie numérique de Marseille fonctionne sans frontières. Mais pour que le travail à distance soit efficace, il faut une organisation militaire. Le chaos technique coûte très cher.
L'avantage clé de mon approche, c'est la transparence absolue. Voici comment nous allons collaborer, même si des centaines ou des milliers de kilomètres nous séparent.
Commençons par les outils. Pas de boîtes noires avec moi.
Hériter d'une application développée au moins-disant coûte presque toujours plus cher que de l'avoir bien faite. Le motif est constant : pas de documentation, pas de tests, un code que personne ne peut reprendre, et des plantages quotidiens qui font tomber la note du store. La réparation commence par un audit, pas par une réécriture.
Parfois, le pire ennemi d'un projet, c'est une fausse bonne affaire. Le cas suivant revient assez souvent pour être décrit : une entreprise technologique en pleine panique.
Ils avaient hérité d'une application mobile développée par une équipe offshore très bon marché. Le résultat ? L'application plantait plusieurs fois par jour.
La note sur les stores était tombée très bas. Les utilisateurs laissaient des avis désastreux quotidiennement. Le PDG était prêt à tout jeter à la poubelle.
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.