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 sur l'App Store et Google Play.
En résumé : pour votre projet à Strasbourg (284 677 habitants), dans le Grand Est, 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 à Strasbourg 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.
Il existe trois formes de maintenance et elles ne se remplacent pas. La corrective traite les bugs signalés ou détectés. L'adaptative suit les versions d'iOS et d'Android, les bibliothèques et les services extérieurs qui changent sans vous prévenir. L'évolutive ajoute des fonctionnalités. Un contrat qui ne couvre que la première laisse passer ce qui casse le plus souvent.
Une application mobile est un produit vivant. Dès qu'on arrête de s'en occuper, la dette technique s'accumule — au début on ne voit rien, à la fin tout s'effondre.
Le point essentiel : le prix dépend de la complexité technique sous le capot, pas du nombre de pages.
Je ne suis pas juste un développeur. Je suis aussi celui qui va vous dire quand une fonctionnalité est une mauvaise idée.
En 12 ans d'expérience, j'ai vu trop de projets échouer à cause d'applications trop compliquées. Mon approche depuis Cannes ? On simplifie. Je travaille avec des startups et des PME pour construire des applications iOS et Android qui vont droit au but.
Je suis votre partenaire produit. Si une idée ne sert pas vos utilisateurs, je vous le dirai. En résumé :
Une application strasbourgeoise s'adresse souvent à des utilisateurs français et allemands, et ce ne sont pas les mêmes utilisateurs avec un dictionnaire entre eux. Le prestataire à chercher est celui qui refuse d'en faire la moyenne : il pose les questions d'usage avant de traduire quoi que ce soit.
Ces questions en valent la peine parce qu'elles changent des écrans, pas des mots. Sur quel ton on s'adresse à l'utilisateur — le vouvoiement allemand n'est pas un détail de politesse, il fixe le registre de toute l'interface. Quels moyens de paiement vos utilisateurs allemands s'attendent à trouver, qui ne sont pas forcément ceux de vos utilisateurs français. Comment une adresse, une date et un numéro de téléphone s'écrivent de chaque côté.
Rien de tout cela ne se règle en fin de projet par une passe de traduction. Ce sont des décisions de conception, et les prendre au départ coûte quelques jours contre plusieurs semaines de reprise.
Le test qui tranche est simple : faites essayer la maquette à un germanophone réel avant la première ligne de code. Dix minutes, et vous saurez si le projet est bilingue ou seulement traduit.
Strasbourg travaille des deux côtés de la frontière, et cela se voit dans les projets : bilinguisme français-allemand dès la première version, parfois une contrainte réglementaire européenne, et des utilisateurs qui changent de langue en cours de route. Prévoir cela au départ coûte quelques jours ; l'ajouter après coûte une refonte.
L'allemand est la langue qui casse le plus d'interfaces, et ce n'est pas une plaisanterie de développeur. Les mots composés allemands sont longs : un bouton qui affiche « Paramètres » sur trois centimètres affiche parfois quelque chose de deux fois plus large en allemand, et le texte déborde, se coupe, ou pousse le reste de l'écran hors du cadre. La seule parade fiable est de concevoir chaque écran pour la version la plus longue du texte dès la maquette, et de tester dans les deux langues à chaque étape plutôt qu'une fois à la fin.
Le changement de langue en cours d'usage est l'autre détail que peu de gens anticipent. Un utilisateur strasbourgeois peut très bien installer l'application en français puis basculer en allemand pour montrer un écran à un collègue. Si le changement oblige à redémarrer l'application, à se reconnecter, ou s'il perd le formulaire à moitié rempli, l'expérience est mauvaise. Cela se prévoit dans la façon dont l'application charge ses textes, et c'est presque gratuit si on y pense avant.
Le bilinguisme a un coût qu'on oublie systématiquement au chiffrage : les textes qui ne sont pas de l'interface. Conditions d'utilisation, politique de confidentialité, formulaires de consentement, e-mails automatiques, messages d'erreur du serveur, fiche du store. Une application franco-allemande a besoin de tout cela dans les deux langues, et ce sont précisément les textes qu'on écrit en dernier, dans l'urgence, souvent la veille de la soumission. Les prévoir dès le début coûte quelques heures ; les traduire en catastrophe coûte un report de publication, parce qu'une politique de confidentialité approximative se refuse à la validation.
Strasbourg abrite aussi des institutions européennes et un tissu de sous-traitants qui travaillent pour elles, ce qui apporte une exigence documentaire supérieure à la moyenne. Sur ces projets, ce qui prend du temps n'est pas le développement mais la validation : plusieurs interlocuteurs, des délais de réponse longs, et des demandes de traçabilité sur les décisions. Je le prends en compte dans le planning en livrant par petits morceaux validables, plutôt qu'en promettant une grande version dans six mois qui restera bloquée en revue.
Sur un projet bilingue, le premier mois sert à décider ce que veut dire « bilingue » ici. La réponse n'est pas la même selon que vos deux publics font la même chose dans l'application ou deux choses différentes.
Un projet se juge à ce qu'il produit, pas à ce qu'il promet. Toutes les deux semaines, vous recevez une version installable sur votre téléphone et une note écrite de ce qui a changé. C'est la seule protection réelle contre le silence de six mois.
La version est parfois très incomplète, et c'est voulu. Une application partielle qu'on peut ouvrir dit la vérité sur l'avancement ; un pourcentage dans un tableau de suivi ne dit rien du tout, et personne ne sait le contredire.
La note fait quelques lignes : ce qui est fait, ce qui a bougé par rapport à ce qui était prévu, et ce sur quoi j'attends une réponse de votre part. Ce dernier point est celui qui fait gagner le plus de temps, parce qu'une question posée par écrit se traite entre deux réunions.
Vous n'avez rien à installer de compliqué : un lien, et l'application arrive sur votre appareil. Vous pouvez la faire essayer à qui vous voulez dans votre entreprise dans le Grand Est, sans me demander.
Et si une version manque, vous le voyez tout de suite. C'est le but.
Un processus transparent, itératif, et sans surprise. Vous voyez l'application grandir chaque semaine.
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 du Grand Est 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.
En résumé : on ne construit pas tout. On construit ce dont vos utilisateurs ont vraiment besoin.
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.
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 à Strasbourg.
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 du Grand Est.
Ces questions demandent la même chose de plusieurs façons : à quoi sert la maintenance. La réponse est que les systèmes changent chaque année et que l'application, elle, ne change pas toute seule. Une application laissée tranquille dix-huit mois finit par ne plus se lancer, et la remettre debout coûte plus cher que de l'avoir suivie.
Parce que le logiciel pourrit avec le temps. Les téléphones évoluent, les systèmes changent. Sans maintenance, votre application accumule des bugs invisibles. À la fin, les utilisateurs fuient et l'investissement initial part en fumée.
L'expulsion. L'App Store et Google Play font régulièrement le ménage. Une application non mise à jour pendant plus d'un an risque la suppression pour protéger les utilisateurs. Tout simplement.
Oui. Apple et Android imposent de nouvelles règles de sécurité et de nouveaux formats d'écrans très régulièrement. Si vous ne mettez pas à jour le code de base, des écrans blancs vont apparaître sur les nouveaux téléphones du Grand Est.
Le point essentiel : La plupart des gens désinstallent après un bug technique. En tuant les bugs pro-activement, on évite les avis 1 étoile. Et on intègre régulièrement les suggestions des utilisateurs pour viser les 5 étoiles.
Le ROI, c'est l'argent que vous ne perdez pas. C'est éviter une fuite de données RGPD, conserver l'argent investi dans la création, et ne pas perdre les ventes générées par une application qui fonctionne 24h/24.
Oui, si les fondations techniques ne sont pas totalement détruites. Un audit permet de trancher. En corrigeant les beaucoup de bugs qui causent la plupart des abandons, on ressuscite souvent un projet donné pour mort.
Pas de magie, que de l'industriel. Google Crashlytics pour les alertes de crash, Sentry pour remonter le fil des erreurs, et des pipelines d'intégration continue (CI/CD) pour déployer sans erreurs humaines.
C'est de la maintenance préventive. Je surveille les bibliothèques open source utilisées par l'application. Dès qu'une vulnérabilité est rendue publique (CVE), je patche le code et je pousse une mise à jour d'urgence.
L'audit profond d'une base de code prend des jours et ne peut pas être gratuit. En revanche, un premier échange de 30 minutes pour évaluer la surface du problème sur les stores, c'est offert et très instructif.
La maintenance soigne et renforce l'existant. La refonte, c'est raser la maison pour en construire une nouvelle. On ne passe à la refonte que quand la dette technique rend la maintenance plus coûteuse que le neuf.
Un projet transfrontalier porte une contrainte de plus que les autres, et elle se règle mieux au début qu'à la fin.
En trente minutes, on peut décider si votre application est bilingue dès la première version ou si elle sort d'abord dans une seule langue — les deux réponses se défendent, mais il faut choisir consciemment. On regarde aussi ce que ça implique pour les textes qu'on oublie toujours : conditions d'utilisation, e-mails automatiques, fiche du store.
Sans engagement, et en français ou en anglais selon ce qui vous arrange.
En 30 minutes, vous saurez exactement par où commencer. Sans engagement. Sans jargon technique.
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.