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.
Android n'est pas un téléphone. C'est des milliers de téléphones différents.
C'est ce qui fait sa force — vos clients à Bordeaux en ont un, quel que soit leur budget — et c'est ce qui rend le travail différent d'iOS. Un même écran doit tenir sur un petit appareil d'entrée de gamme comme sur une grande tablette, avec des versions du système qui vont de l'ancienne à la toute dernière.
Chaque fabricant ajoute par-dessus sa propre couche, qui change la gestion de la batterie, les notifications et parfois le clavier. Une application qui n'a été essayée que sur un seul modèle se comporte autrement chez la moitié de ses utilisateurs.
C'est la première chose qu'on cadre : sur quels appareils réels votre application doit tenir debout.
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 à Bordeaux.
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.
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.
Une grande idée se construit en la réduisant d'abord. La première version Android ne garde que le parcours principal, celui sans lequel l'application ne sert à rien. Le reste est écrit quelque part et attend d'être réclamé par de vrais utilisateurs — qui réclament rarement ce qu'on avait prévu. Sortir tôt coûte moins cher que deviner longtemps.
Vous avez une idée énorme pour disrupter votre marché à Bordeaux.
C'est super. Maintenant, on va réduire cette idée.
Pourquoi ?
Parce qu’une grande partie des fonctionnalités d'une application ne sont jamais utilisées.
En résumé, on va créer un Produit Minimum Viable (MVP).
On va se concentrer sur l'unique fonctionnalité qui apporte vraiment de la valeur à l'utilisateur de France.
On développe cette V1 rapidement.
Ensuite, on l'envoie aux 20 testeurs imposés par les règles de Google Play pour les nouveaux comptes.
Ces 14 jours de tests obligatoires ne sont pas une contrainte. C'est une opportunité.
Une application grand public sur Android doit tenir sur des appareils de toutes marques et de tous prix, pas seulement sur le téléphone du développeur. C'est la contrainte qui structure le projet : choisir les appareils réels à couvrir, et tester dessus. Une application essayée sur un seul modèle se comporte autrement chez une bonne partie de ses utilisateurs.
Prenons un exemple concret.
Un client m'a contacté pour créer une application de réservation de services à domicile, ciblant spécifiquement la région Nouvelle-Aquitaine.
Le problème initial ? L'application devait cibler le grand public.
Et le grand public, ça utilise de l'Android. De toutes les marques. De tous les prix.
Le facteur le plus important était de gérer la terrible fragmentation d'Android.
L'application devait être aussi fluide sur un Xiaomi bas de gamme vieux de cinq ans que sur le dernier Samsung Galaxy S.
Une application Android coûte généralement moins cher que son équivalent iOS. La raison est pratique plutôt que technique : les outils de développement de Google sont gratuits et plus souples, et le compte développeur Play se paie une seule fois au lieu d'être annuel. C'est le périmètre de votre application qui fixe le montant ; la plateforme ne le déplace qu'à la marge.
Le compte Google Play Console coûte 25 $, une seule fois, à l'inscription. C'est la dépense fixe la plus faible des deux plateformes — le programme développeur d'Apple, lui, se renouvelle à 99 € chaque année.
Je ne vais pas vous mentir. Créer une bonne application Android à Bordeaux représente un investissement.
Souvent, on constate que le développement Android coûte sensiblement moins cher que son équivalent iOS.
Pourquoi ?
Parce que les outils de développement fournis par Google sont gratuits et souvent plus souples.
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.