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 à Montpellier (290 053 habitants) et partout en Occitanie. Un seul interlocuteur, 12 ans d'expérience, livraison du concept à la publication en 8 à 16 semaines.
Un logiciel de bureau pose une question que le web ne pose jamais : comment arrive-t-il sur les machines ?
Sur un site, vous publiez et tout le monde a la nouvelle version dans la seconde. Sur un poste de travail, il faut installer, signer l'application pour que le système accepte de la lancer, et prévoir comment les mises à jour parviendront aux ordinateurs de vos équipes à Montpellier — parfois derrière un pare-feu, parfois sans droits d'administrateur.
Ce n'est pas compliqué, mais ça se décide au début. Un logiciel excellent que personne n'arrive à installer ne sert à rien, et c'est le genre de mur qu'on découvre la semaine du déploiement.
Un logiciel de bureau vise un système d'exploitation, et les deux ne demandent pas le même travail. Le cœur du logiciel se partage ; ce qui diffère, c'est la façon dont il s'installe, se signe et se met à jour. Viser les deux ne double pas le budget, mais ce n'est pas gratuit non plus.
Sur Mac, une application doit être signée et validée par Apple avant que le système accepte de l'ouvrir. Sans cette étape, vos utilisateurs voient un avertissement inquiétant et beaucoup n'iront pas plus loin. C'est une formalité, mais elle demande un compte développeur et un peu de temps à chaque version.
Sur Windows, le sujet est différent : l'installateur, les droits d'administration, et souvent la politique de sécurité de l'entreprise, qui peut bloquer un logiciel qu'elle ne connaît pas. Dans une structure de Montpellier avec un service informatique, c'est cette conversation-là qui décide du calendrier.
La bonne façon de trancher est simple : regardez ce qu'il y a sur les bureaux de ceux qui vont s'en servir. Commencer par le système majoritaire et ajouter l'autre ensuite coûte moins cher que de viser large tout de suite.
Plus de 15 applications livrées. Des startups qui ont trouvé leur marché. Des PME qui ont fluidifié leur travail.
En 12 ans, j'ai vu ce qui fonctionne et ce qui plante sur iOS et Android. Depuis Cannes, je ne vous promets pas la lune. Je vous promets des résultats. Mon travail est de construire des outils solides que vos utilisateurs vont réellement adopter.
L'avantage clé, c'est l'impact de votre application sur la vraie vie. On regarde ensemble comment faire grandir votre projet de manière intelligente et rentable ?
C'est la difficulté d'un premier projet, et elle est réelle : vous devez choisir quelqu'un dont vous ne pouvez pas évaluer le travail. La bonne nouvelle, c'est qu'une prestation se vérifie sans lire une ligne de code. Cinq points suffisent, et ils sont tous observables par vous.
Une version installable toutes les deux semaines, même incomplète, sur votre propre téléphone. Le dépôt de code à votre nom dès le premier jour, pas à la livraison. Un fichier qui explique comment reconstruire l'application, pour qu'un autre développeur puisse reprendre. Une note écrite après chaque décision, pour qu'on ne se dispute pas dans six mois sur ce qui avait été dit. Et une démonstration sur votre appareil plutôt qu'une vidéo.
Aucun de ces cinq points ne demande de compétence technique de votre part. Tous les cinq sont refusés, poliment, par les prestataires qui ont quelque chose à cacher.
Si l'un d'eux manque dans une proposition que vous avez reçue, demandez pourquoi. La réponse vous apprendra plus que le devis.
Montpellier est une ville jeune, avec beaucoup de premiers projets et peu de budget de départ. C'est exactement le cas où il faut savoir dire non : une application qui fait une seule chose correctement se lance en deux mois, tandis qu'une qui en fait cinq à moitié ne se lance jamais. On commence par retirer, pas par ajouter.
Retirer est plus difficile qu'il n'y paraît, parce que chaque fonction qu'on enlève ressemble à un renoncement. La bonne question n'est pas « est-ce que ce serait bien », presque tout serait bien. La bonne question est : « si cette fonction n'existe pas, est-ce que quelqu'un utilise quand même l'application ? » Si la réponse est oui, elle attend. Une messagerie interne, un système de parrainage, des notifications personnalisées, un tableau de statistiques : ce sont presque toujours des fonctions de version deux, écrites après avoir vu comment les gens se servent vraiment de la version une.
L'avantage d'un budget contraint, quand on l'assume, c'est qu'il force des décisions saines. Il pousse à sortir vite, donc à apprendre vite. Il interdit de développer six mois dans le vide en s'imaginant ce que veulent les utilisateurs. Et il oriente vers des choix techniques simples, qui sont aussi les moins chers à maintenir — un projet dont la facture d'infrastructure est de quelques dizaines d'euros par mois peut attendre son public sans vous ruiner, ce qui n'est pas vrai d'une architecture surdimensionnée dès le premier jour.
Le budget contraint a en revanche un angle mort, et c'est celui qui fait le plus de dégâts ici : la première version n'est pas la dépense totale. iOS sort une version majeure chaque septembre, Android chaque année, et chacune casse quelque chose — une permission qui change de forme, une bibliothèque qui n'est plus signée, un écran qui se décale. Une application qu'on laisse tranquille dix-huit mois finit par ne plus se lancer, et la remettre debout coûte plus cher que de l'avoir suivie. Sur un premier projet, le bon calcul n'est pas « combien pour sortir » mais « combien pour sortir et tenir un an ». Je préfère réduire le périmètre de la version une et garder de quoi passer septembre.
Montpellier a un écosystème santé et une grosse population étudiante, et cela produit deux profils très différents. Les projets santé arrivent avec des contraintes lourdes qu'il faut chiffrer honnêtement dès le début, notamment sur l'hébergement des données. Les projets étudiants arrivent avec de l'énergie, une idée et un calendrier scolaire. Dans les deux cas, mon rôle utile est le même : dire ce qui est réellement faisable avec ce que vous avez, et ne pas vendre le reste.
Sur un premier projet avec un budget serré, le premier mois décide de tout : ce qu'on retire maintenant est ce qui permet de sortir. On ne commence pas par concevoir, on commence par couper.
Ce qu'on n'a pas construit reste écrit quelque part. On y revient quand des utilisateurs réels le réclament — et ils réclament rarement ce qu'on avait prévu.
Le jour de la publication n'est pas la fin du projet, c'est le premier jour où l'application rencontre de vrais utilisateurs. La suite se prépare avant, pas après : sans elle, les premiers retours arrivent et personne n'est là pour y répondre.
La première semaine, on surveille. Pas les téléchargements — les plantages, les écrans où les gens s'arrêtent, les endroits où ils reviennent en arrière. Un rapport de plantage vaut mille suppositions, et les trois premiers jours en apprennent plus que trois mois de réunions.
La deuxième semaine, on corrige ce que ces retours ont montré, et on publie une mise à jour. Elle est presque toujours nécessaire, et ce n'est pas un échec : aucune première version ne survit intacte au contact de son public à Montpellier.
Ensuite le rythme ralentit, mais ne s'arrête pas. Apple sort une version majeure d'iOS chaque automne, Google une d'Android chaque année, et chacune casse quelque chose — une autorisation qui change de forme, une bibliothèque qui n'est plus signée, un écran qui se décale.
On décide ensemble du niveau de suivi avant le lancement, pas au premier incident.
Un tableur partagé qui gère une activité finit toujours par casser sur les trois mêmes points : plusieurs personnes ne peuvent pas y écrire en même temps, les versions circulent par courriel sans qu'on sache laquelle fait foi, et les formules ne sont plus comprises par personne. Un logiciel règle les deux premiers presque gratuitement ; le troisième est le vrai travail.
C'est l'histoire classique d'une belle PME. Leur gestion commerciale tournait entièrement sur un fichier Excel partagé. Au début, c'était pratique.
Et puis ils sont passés à trente employés. Le fichier était devenu énorme. Il mettait plusieurs minutes à s'ouvrir. Dès que deux personnes modifiaient une cellule en même temps, le fichier corrompait tout. Ils m'ont contacté pour un développement application desktop Montpellier.
Le développement n'est pas la seule dépense d'une application, et les autres reviennent tous les ans. Les connaître avant de signer change la façon dont vous dimensionnez le projet — et évite la mauvaise surprise du douzième mois, qui est toujours la plus mal reçue.
Publier coûte de l'argent aux deux endroits. Le programme développeur d'Apple se renouvelle chaque année ; le compte développeur Google Play se paie une fois, à l'inscription. Ces comptes doivent être à votre nom, pas au mien : c'est votre application, et un compte au nom du prestataire est le piège le plus courant du secteur.
Viennent ensuite l'hébergement et les services que l'application consomme. Sur un projet de Montpellier qui démarre, la facture est modeste — mais elle tombe tous les mois, et elle grandit avec le nombre d'utilisateurs.
Si vous vendez dans l'application, Apple et Google prélèvent entre 15 % et 30 % selon votre chiffre d'affaires et le programme auquel vous êtes éligible. Ça se calcule avant de fixer vos prix, pas après.
Quand un client attend au comptoir, la vitesse n'est pas un confort. Un logiciel installé démarre sans réseau, répond sans latence, et continue de fonctionner quand la connexion tombe. Pour un point de vente ou un atelier, c'est la différence entre une file qui avance et une journée perdue.
À Montpellier, quand un client attend au comptoir, vous n'avez pas le temps de regarder une roue de chargement tourner. Certains secteurs vivent ou meurent par leur temps de réponse.
Ces questions portent sur la vie du logiciel dans l'entreprise : le déploiement sur toutes les machines, la connexion aux outils en ligne existants, la sécurité, le travail hors ligne, et les frais récurrents. Le point qui décide le plus souvent du calendrier n'est pas technique : c'est la politique de sécurité de votre service informatique.
Un premier projet se plante rarement sur la technique. Il se plante sur le périmètre : trop de fonctions, pas assez de budget pour aller au bout, et rien qui sorte.
Trente minutes suffisent à retirer ce qui peut attendre. On passe chaque idée au même filtre : si cette fonction n'existe pas, est-ce que quelqu'un utilise quand même l'application ? Ce qui survit à ce tri, c'est votre version une, et elle est presque toujours plus petite et plus rapide à sortir que ce que vous imaginiez.
On regarde aussi le budget de la deuxième année, pas seulement celui du lancement.
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.