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 à Nantes (314 138 habitants), dans les Pays de la Loire, 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.
Publier une app, c’est une part du travail seulement. La maintenir, c’est tout le reste.
La plupart des entreprises à Nantes célèbrent le lancement de leur application sur les stores.
Et après ? Plus rien.
Le code pourrit lentement. Personne ne regarde les rapports de crash. Personne n'anticipe quand une nouvelle version d'iOS ou d'Android change les règles du jeu.
L'application qui devait faire décoller votre business devient un poids lourd à traîner.
Vous venez d'acheter une voiture neuve. Si vous ne faites jamais la vidange, le moteur va casser en deux ans. Pour une application mobile, c'est exactement la même chose.
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 à Nantes.
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.
Mon rôle premier est de protéger votre budget. Saviez-vous qu’une grande partie des fonctionnalités d'une application ne sont jamais utilisées ?
Depuis Cannes, j'aide mes clients à éviter ce gaspillage énorme. Avec 12 ans d'expérience sur iOS et Android, je sais où l'argent doit aller. On coupe le superflu pour se concentrer sur ce qui apporte une vraie valeur à votre cible.
L'avantage clé : une application qui sort vite, qui teste le marché, et qui coûte le juste prix. Construisons d'abord l'essentiel.
À Nantes, le milieu est assez dense pour qu'un prestataire soit vérifiable en quelques appels, et autant s'en servir. Trois demandes suffisent à séparer ceux qui livrent de ceux qui présentent bien. Je vous encourage à me les poser autant qu'aux autres.
Un : deux clients que vous pouvez appeler vous-même, pas une citation sur un site. Ce qu'il faut leur demander n'est pas « êtes-vous content » mais « qu'est-ce qui s'est mal passé, et comment ça a été réglé ». Tous les projets ont un moment difficile, et la réponse à cette question dit à peu près tout.
Deux : une application publiée que vous pouvez installer et utiliser dix minutes. Pas une capture d'écran, pas une vidéo de démonstration. L'application, sur votre téléphone.
Trois : qui a écrit le code de cette application. Dans beaucoup de portfolios, la réponse honnête est « une équipe qui n'est plus là ».
De mon côté, je réponds aux trois, et j'ajoute volontiers le projet qui s'est mal terminé et pourquoi. C'est en général plus instructif que les autres.
Nantes a un vrai tissu numérique et beaucoup de créateurs qui ont déjà travaillé avec une agence. C'est confortable : vous savez ce qui vous a déplu la dernière fois, et on peut construire à partir de là. Les demandes que j'y reçois sont souvent les plus précises de toutes, et un cahier des charges précis fait gagner un mois.
Ce que les gens ont mal vécu se répète d'ailleurs beaucoup d'une fois sur l'autre, et cela vaut la peine d'être nommé. Trois reproches reviennent : ne jamais savoir où en était le projet entre deux points d'étape, découvrir en fin de parcours que ce qui avait été validé oralement n'avait pas été noté, et se retrouver avec un code que personne d'autre ne peut reprendre. Les deux premiers se règlent par une version installable toutes les deux semaines, même incomplète, et par un compte rendu écrit après chaque décision. Le troisième se règle en vous donnant l'accès au dépôt depuis le premier jour.
Le fait d'avoir déjà travaillé avec un prestataire change aussi la nature de la première réunion. On ne passe pas la moitié du temps à expliquer ce qu'est une recette, un environnement de test ou une soumission au store. On peut aller directement aux arbitrages qui comptent : ce qui entre dans la première version, ce qui attend, et où placer l'argent quand il faut choisir entre plus de fonctions et une meilleure finition.
Quand on reprend après quelqu'un d'autre, la première tâche n'est pas technique, elle est administrative, et c'est celle qui bloque le plus de projets : récupérer ce qui vous appartient. Le dépôt de code, les comptes App Store Connect et Google Play — à votre nom, pas à celui du prestataire —, les clés de signature, les accès à l'hébergement, les maquettes. Sans la clé de signature d'origine, une application Android ne peut plus être mise à jour, elle doit être republiée sous un autre identifiant et vous perdez vos installations. Je demande cette liste avant de chiffrer quoi que ce soit.
Nantes a par ailleurs une forte concentration d'entreprises de l'économie sociale et solidaire et du secteur culturel, et ces projets ont un profil budgétaire particulier : financement par subvention, calendrier calé sur un exercice, et souvent une obligation de rendre des comptes sur l'usage des fonds. Cela m'oblige à découper autrement, en jalons livrables et facturables qui correspondent à quelque chose de montrable, plutôt qu'en une grosse facture à la fin.
Quand un projet reprend après quelqu'un d'autre, le premier mois ne commence pas par du code. Il commence par récupérer ce qui vous appartient, puis par savoir honnêtement dans quel état est l'existant.
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 à Nantes.
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.
Une prise en main commence par un audit, et l'audit trouve régulièrement ce que personne ne cherchait — des mots de passe stockés en clair, une clé d'accès laissée dans le code, une bibliothèque abandonnée depuis des années. Ces défauts ne se voient pas à l'usage : l'application fonctionne parfaitement jusqu'au jour où quelqu'un s'y intéresse.
La maintenance préventive, c'est ce qui vous évite de faire la une des journaux locaux à Nantes pour les mauvaises raisons.
Lors d'une prise en main, un audit de routine révèle parfois quelque chose d'inquiétant. Une application développée quelques années plus tôt par une agence depuis disparue peut très bien stocker les mots de passe de ses utilisateurs en clair dans sa base locale.
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 transport, le mode hors ligne n'est pas une option de confort, c'est l'architecture. Entrepôts, sous-sols et routes de campagne coupent le réseau, et une application qui suppose une connexion permanente ne tient pas une journée. Deux décisions suivent : la règle qui tranche les modifications concurrentes, et la façon dont la preuve de livraison est conservée.
Dans le transport, le mode hors ligne n'est pas une option de confort : c'est l'architecture. Un entrepôt métallique, un sous-sol, une zone portuaire ou une route de campagne coupent le réseau, et une application qui suppose une connexion permanente ne survit pas à sa première journée réelle.
On construit donc l'inverse : tout fonctionne sans réseau, et la synchronisation se fait seule dès qu'il y a du signal — sans bouton à presser, parce qu'un bouton à presser finit toujours par ne pas l'être.
Ces questions portent sur le contenu d'un contrat de maintenance. Ce qu'il couvre tient en trois choses : une surveillance qui remonte les plantages toute seule, un délai de correction convenu à l'avance et différent selon la gravité, et un point régulier où l'on décide de ce qui se corrige maintenant. Les nouvelles fonctionnalités se traitent à part.
Il comprend la sérénité technique. Plus concrètement, on parle de correctifs de bugs, de mises à jour de compatibilité pour les nouveaux iOS/Android, et d'une surveillance proactive (Crashlytics). C'est le socle pour que votre projet survive.
En cas de bug bloquant (ex : crash au paiement), l'intervention se compte en heures. J'isole le problème et pousse la mise à jour sur les stores dans la journée. Apple et Google prennent ensuite le relais pour la validation.
Oui, les outils automatisés veillent en permanence. Si l'application s'effondre un dimanche soir dans les Pays de la Loire, le système remonte les logs instantanément. Je suis alerté avant même que vos utilisateurs ne s'en plaignent.
On commence toujours par un audit profond. Je lis le code, je repère la dette technique, les failles et les urgences. Ensuite, on fait un sprint de stabilisation. On ne construit rien de nouveau tant que les fondations tremblent.
Le point essentiel : Apple et Google sortent 4 à 6 mises à jour majeures par an. Vous devez suivre ce rythme sous peine de voir votre application devenir obsolète ou être retirée par l'App Store Review Guidelines.
C'est exactement pour ça que la maintenance existe. On l'anticipe via les versions bêtas des OS. Si la casse survient quand même en production, je déploie un correctif en urgence pour vos utilisateurs.
J'utilise des outils professionnels comme Sentry et Firebase Crashlytics. Ces sondes silencieuses m'indiquent précisément quelle ligne de code a lâché et sur quel appareil, sans que l'utilisateur n'ait rien à faire.
Bien sûr. La confiance exige de la transparence. Vous recevez un compte rendu vulgarisé : nombre de crashs évités, correctifs appliqués, temps de chargement, et prévisions pour les évolutions du mois suivant.
C'est ce qu'on appelle la maintenance évolutive. Selon le niveau de notre collaboration, on réserve un quota d'heures mensuelles pour faire grandir l'application et répondre aux nouvelles demandes de vos utilisateurs.
C'est très simple, vous êtes propriétaire de votre code et de vos accès (Apple, Google, Firebase). Si vous souhaitez arrêter, je vous remets une documentation à jour et vous êtes libre.
Si vous avez déjà travaillé avec un prestataire, vous savez ce que vous ne voulez plus revivre. C'est un excellent point de départ pour un premier échange.
En trente minutes, on fait deux choses. On liste ce qui vous appartient et qu'il faut récupérer — dépôt de code, comptes App Store et Google Play à votre nom, clés de signature — parce que sans ça aucun chiffrage n'a de sens. Puis on regarde ce qui reste réellement à construire.
Sans engagement, et sans relance commerciale ensuite.
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.