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.
Avant de parler d'application, une question vaut la peine d'être posée : est-ce qu'il vous en faut une ?
Beaucoup de projets à Bordeaux n'ont pas besoin d'être installés. Un site qui marche bien sur téléphone fait souvent le même travail, coûte moins cher, et ne demande à personne d'aller chercher quoi que ce soit dans un store.
L'application se justifie quand il faut fonctionner sans réseau, utiliser l'appareil photo ou la position en continu, envoyer des notifications, ou quand vos utilisateurs reviennent plusieurs fois par semaine. Si rien de tout ça n'est vrai, je le dis au premier appel.
Quand elle se justifie, en revanche, elle fait des choses qu'aucun site ne fera. C'est de ça que parle cette page.
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 à Bordeaux, sans vous faire payer une Ferrari s'il vous faut une citadine fiable.
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.
Un projet ne construit jamais tout ce qui a été imaginé, et c'est volontaire. On commence par une première version réduite à ce qui rend l'application utile sans le reste. Le filtre est simple : si une fonction n'existe pas, est-ce que quelqu'un utilise quand même l'application ? Ce qui survit à ce tri sort vite et vous apprend ce que six mois de développement à l'aveugle n'auraient pas dit.
Si vous voulez que votre projet réussisse à Bordeaux, il faut accepter une réalité très contre-intuitive : on ne développe jamais tout ce qu'on a imaginé.
On commence toujours, sans aucune exception, par un Produit Minimum Viable. Le fameux MVP.
C'est quoi un MVP ?
C'est la version la plus petite, la plus simple et la plus directe de votre idée. C'est l'essence même de votre solution. Pourquoi faire cela pour votre entreprise en Nouvelle-Aquitaine ? Parce que les statistiques sont cruelles. Actuellement, une grande partie des fonctionnalités d'une application ne sont absolument jamais utilisées par le public.
Un site qui reçoit l'essentiel de son trafic depuis un téléphone et n'y enregistre presque aucune réservation n'a pas un problème de visibilité : il a un problème de parcours. Le cas se règle rarement en ajoutant des fonctionnalités. Il se règle en retirant des étapes entre le moment où quelqu'un arrive et celui où il peut réserver.
Rien ne vaut un exemple concret pour comprendre. Voici l'histoire d'une entreprise de services bien implantée.
Cette entreprise avait un site web classique. Les statistiques montraient que beaucoup de leur trafic provenait des téléphones portables. C'est énorme. Mais il y avait un problème de taille. Ils n'enregistraient absolument aucune réservation depuis ces appareils.
Leurs clients essayaient de prendre rendez-vous, se perdaient sur le site mobile, et abandonnaient.
Il n'existe pas de prix unique pour une application mobile. Ce qui fixe le montant, c'est le périmètre : le nombre d'écrans, la nécessité d'un serveur et de comptes utilisateurs, et le fait de viser une plateforme ou deux. Un appel de cadrage donne une fourchette réelle.
Trois facteurs fixent le budget, plus deux dépenses fixes :
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.