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, du concept à la publication.
En résumé : pour votre projet à Lyon (515 695 habitants), en Auvergne-Rhône-Alpes, vous travaillez directement avec moi, pas un intermédiaire. 12 ans d'expérience, 15+ applications livrées, et un processus transparent de A à Z.
iOS et Android publient 4 à 6 mises à jour système par an.
Chacune de ces mises à jour peut casser votre application du jour au lendemain.
Un tunnel de paiement qui fonctionnait parfaitement hier s'arrête brusquement parce qu'Apple a modifié une API de sécurité. Un écran de connexion devient inutilisable sur le dernier Samsung. Sans maintenance régulière, votre application devient techniquement obsolète en quelques mois à Lyon.
Et ce n'est pas le pire.
Si vous laissez votre code prendre la poussière, vous risquez l'expulsion pure et simple.
Les App Store Review Guidelines autorisent Apple à supprimer les applications qui n'ont pas été mises à jour depuis trop longtemps. Tout votre investissement initial disparaît en un clic.
La maintenance d'une application recouvre trois choses différentes : corriger ce qui casse, suivre les changements des systèmes qui l'entourent, et faire évoluer le produit. Les deux premières ne sont pas optionnelles — sans elles, l'application finit par ne plus se lancer. La troisième se décide, se chiffre et se planifie séparément.
Oubliez le code une minute. Reprenons l'analogie de la voiture pour bien comprendre l'enjeu à Lyon.
La vidange, ce sont les correctifs de sécurité. Vous ne voyez pas l'huile propre quand vous conduisez. Cela ne rend pas la voiture plus rapide. Mais si vous ne le faites pas, le moteur serre au milieu de l'autoroute. Dans une app, c'est ce qui protège les données de vos utilisateurs.
Le changement de pneus, ce sont les mises à jour de compatibilité OS. Quand Apple ou Google sortent une nouvelle version majeure de leur système, les routes changent. Si votre application garde ses vieux pneus, elle va déraper. Il faut adapter le code pour qu'il continue de rouler droit.
Il y a 12 ans, je lançais ma toute première application mobile. Depuis, les téléphones ont changé, mais mon métier est resté le même : transformer des idées en outils concrets.
Depuis mon bureau à Cannes, j'accompagne des entrepreneurs et des PME pour concevoir des applications iOS et Android qui ont un vrai sens. Je ne code pas juste pour coder. Je cherche à comprendre votre métier, vos utilisateurs et vos vrais besoins.
Mon objectif est simple. Créer une application que les gens auront envie d'utiliser tous les jours. Le point essentiel : on construit pour eux, pas pour nous. On en parle ?
À Lyon, beaucoup d'entreprises qui me contactent ont déjà une DSI ou un développeur interne. La bonne question n'est donc pas « qui fait tout », mais « qui fait quoi ». Je prends la partie mobile, votre équipe garde ce qu'elle connaît, et on écrit la frontière entre les deux avant de commencer.
Cette frontière tient en trois lignes. Vos serveurs et vos règles métier restent chez vous. L'application et la couche qui lui parle sont de mon côté. Et on se met d'accord dès la première semaine sur ce que chacun attend de l'autre — par écrit, pas oralement, parce que c'est exactement là que les projets à deux équipes se perdent.
Le deuxième critère compte autant et il est rarement posé : est-ce que votre équipe pourra reprendre le projet quand je ne serai plus là ? C'est le but, pas un accident. Le code est volontairement ennuyeux, parce que les astuces brillantes coûtent cher à relire. Le dépôt est à votre nom dès le premier jour, et il contient de quoi reconstruire l'application sans moi.
Un outil métier vit dix ans. Le prestataire qui l'a écrit, rarement. Un projet qui ne survit pas au départ de son auteur n'est pas terminé, il est en sursis.
Lyon est la ville française où je rencontre le plus d'entreprises qui ont déjà un logiciel métier et veulent le prolonger sur mobile. Ce n'est pas le même travail qu'une application partant de zéro : l'essentiel se joue sur l'API existante et sur ce qu'on accepte de ne pas porter. On commence toujours par cette liste-là, avant de dessiner le moindre écran.
La raison pour laquelle cette liste passe en premier est simple : une application mobile qui essaie de reproduire tout un logiciel de gestion échoue toujours. L'écran fait six pouces, l'utilisateur est debout, il a une main libre et trente secondes. Ce qui marche sur mobile, c'est trois ou quatre actions faites cinquante fois par jour — pointer une intervention, valider une livraison, consulter une fiche client, photographier un document. Le reste reste sur le poste de travail, et c'est très bien.
Le vrai risque technique n'est presque jamais l'application. C'est l'API. Beaucoup de logiciels métier ont une interface qui a été écrite pour un site web interne, sur un réseau d'entreprise rapide, avec des réponses énormes parce que la bande passante ne coûtait rien. Branchée sur un téléphone en 4G dans un parking souterrain, la même interface met huit secondes à répondre et l'application paraît cassée alors qu'elle fonctionne parfaitement. La première semaine d'un projet lyonnais part souvent là-dedans : mesurer ce que l'existant renvoie vraiment, et décider ce qu'on adapte côté serveur plutôt que de bricoler côté mobile.
Une question à poser avant tout le reste, et qui décide souvent du projet : à qui appartient l'accès à ce logiciel métier ? Si l'éditeur fournit une API documentée, tout va bien. S'il n'en fournit pas, ou s'il la facture au module, ou s'il refuse de l'ouvrir à un tiers, aucune application mobile ne contournera ça proprement — et les contournements existent, mais ils cassent à la première mise à jour de l'éditeur. Je pose la question au premier appel plutôt qu'au deuxième mois, parce que la réponse change le budget, le calendrier, et parfois la décision de faire ou non.
Lyon a aussi une forte présence de la santé et de la chimie, deux secteurs où l'hébergement des données n'est pas un choix libre. Si vos données relèvent de la santé, elles doivent être chez un hébergeur certifié, et cela se décide avant la première ligne de code, pas au moment de la mise en production. Je pose la question au premier rendez-vous, parce que la réponse change l'architecture entière.
Quand l'application se branche sur un logiciel existant, le premier mois se joue sur le serveur, pas sur l'écran. On mesure d'abord ce que l'existant renvoie vraiment, parce que c'est ça qui décide de ce qui est faisable — et du budget.
Et votre équipe a accès au dépôt depuis le premier jour, pas à la livraison.
Le cas le plus fréquent n'est pas la maintenance d'une application que j'ai écrite, c'est la reprise de celle de quelqu'un d'autre. Elle commence toujours par un audit : je reconstruis l'application depuis le dépôt, sans aide. Le temps que ça prend est déjà une réponse sur l'état du code, et il décide de ce qui se garde, se répare ou se réécrit.
Le scénario le plus fréquent à Lyon est la reprise de code. Vous avez fait construire une application par un autre développeur ou une agence, et aujourd'hui, vous êtes seul avec un produit instable.
Je ne juge pas le passé, je sécurise l'avenir. Voici la méthode de reprise :
L'Audit : C'est comme un docteur qui ausculte un patient pour la première fois. Je passe le code au crible, je vérifie l'architecture, j'analyse les données de crash et les notes sur les stores.
Une application qui plante et dont la note s'effondre n'a presque jamais un seul problème : elle en a plusieurs, dont deux ou trois font l'essentiel des plantages. C'est pour ça que la première étape est la mesure et non la réécriture. Corriger les quelques causes majoritaires ramène la stabilité, et la note remonte ensuite d'elle-même.
Il y a un an, une entreprise locale d'Auvergne-Rhône-Alpes m'a contacté en urgence. Leur application plantait plusieurs fois par jour. La note sur les stores était tombée très bas. Les avis négatifs pleuvaient et le PDG était à deux doigts de débrancher purement et simplement le projet.
La maintenance se chiffre plus facilement au regard du coût de l'inaction. Que vous coûte une journée d'indisponibilité ? Si le paiement plante, c'est du chiffre d'affaires perdu sec. Une application non maintenue perd aussi sa compatibilité à chaque version annuelle d'iOS et d'Android, et finit par être retirée des stores.
Une application non maintenue finit par être retirée : Google Play impose aux applications de viser une version récente d'Android pour rester visibles dans le store, et Apple appliqu’une règle équivalente sur les applications restées longtemps sans mise à jour.
Je refuse de parler de la maintenance comme d'un "coût". C'est un investissement défensif massif pour votre entreprise à Lyon.
Pour le comprendre, il faut regarder le prix exorbitant de l'inaction technique :
Santé, hôtellerie et commerce n'ont pas les mêmes urgences. En santé, une panne touche un dossier patient et se traite dans l'heure. En hôtellerie, elle tombe en pleine saison, quand personne n'a le temps. En commerce, elle se compte en paniers abandonnés. Le délai de réponse se fixe donc secteur par secteur, avant l'incident.
Chaque domaine a ses propres urgences techniques. Maintenir une application e-commerce ne demande pas les mêmes réflexes que maintenir une application médicale à Lyon.
L'erreur n'est pas permise. Les audits RGPD et CNIL doivent être anticipés en permanence. La sécurité des données patients exige des tests de pénétration réguliers pour s'assurer que l'architecture backend reste imperméable. Je maintiens également les fonctionnalités vitales comme le mode hors-ligne, indispensable pour les praticiens en déplacement dans les zones rurales d'Auvergne-Rhône-Alpes.
Ces questions portent sur le fonctionnement au quotidien : reprendre le code de quelqu'un d'autre, travailler à distance, joindre quelqu'un le week-end, tenir un pic de saison. Reprendre une application existante commence toujours par un audit — je la reconstruis depuis le dépôt, sans aide. Le temps que ça prend est déjà une réponse sur l'état du code.
C'est mon quotidien. Beaucoup de mes clients arrivent avec un code existant. Je ne juge pas le travail passé, je l'audite, je le documente, je le stabilise. C'est une opération chirurgicale pour remettre le projet sur les rails.
Oui, beaucoup de mon activité est gérée à distance avec des clients dans tout le pays. Le code est sur le cloud, les outils de monitoring aussi. On se synchronise en visio, de façon bien plus efficace qu'en réunion physique.
Pour les clients bénéficiant du niveau Premium avec SLA prioritaire, les alertes Crashlytics me parviennent en direct 7j/7. S'il y a un crash bloquant les revenus, je me connecte et je déploie un hotfix immédiat.
Directement et sans intermédiaire. Pas de chef de projet qui fait barrage. Vous avez accès à un outil de suivi partagé (Trello/Jira), et nous faisons un point mensuel stratégique. La communication est claire et sans jargon technique.
L'avantage clé : je garantis la transparence absolue. Vous avez un accès direct aux outils de monitoring. S'il y a un bug de régression causé par une de mes mises à jour, je le corrige immédiatement à mes frais.
La sécurité logicielle demande de l'engagement, mais je ne prends pas mes clients en otage. On fonctionne généralement sur des engagements annuels avec des bilans trimestriels pour ajuster le volume d'heures aux besoins réels d'Auvergne-Rhône-Alpes.
Je regarde les données brutes : temps d'ouverture de l'application, temps de réponse de la base de données, taux d'utilisateurs sans crash (qui doit rester le plus haut possible). C'est mathématique et indiscutable.
Je suis expert natif (Swift/Kotlin) et Flutter. Pour Flutter, c'est un grand oui. Pour React Native ou les technologies hybrides web (Cordova, Ionic), je vous réorienterai vers des confrères spécialisés pour garantir la meilleure qualité.
Un audit profond prend entre 3 et 5 jours ouvrés selon la taille de l'application. Je livre un rapport écrit détaillé qui classe les urgences en trois catégories : rouge (sécurité/crash), orange (performance) et vert (détails UX).
On anticipe. Si vous faites du e-commerce avant Noël, on fait des tests de charge en novembre. On optimise les requêtes serveurs et on gèle les mises à jour non essentielles pour garantir une stabilité sans faille pendant le pic.
Un projet mobile lyonnais commence presque toujours par la même question, et elle n'est pas technique : qu'est-ce qu'on ne met pas dans l'application ?
En trente minutes, on peut y répondre assez précisément. On regarde ce que vos utilisateurs font debout, une main prise, en trente secondes — c'est ça qui va sur le téléphone, et le reste peut rester sur le poste de travail. On repère aussi tout de suite si votre logiciel existant peut être branché ou non, parce que c'est ce qui décide du budget.
Sans engagement. Si la conclusion est que vous n'avez pas besoin d'une application, je vous le dirai aussi.
En 30 minutes, vous saurez exactement par où commencer. Sans engagement. Sans jargon technique.
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.