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 à Bruxelles (185 103 habitants), en région bruxelloise, 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 à Bruxelles 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.
Ce qui arrive à une application sans maintenance suit un scénario régulier. Les premiers mois, rien ne se voit. Puis une version du système change une autorisation, une bibliothèque cesse d'être signée, un service extérieur modifie ses règles. Au bout d'un an et demi environ, l'application ne se lance plus, et la remettre debout coûte plus cher que de l'avoir suivie.
Pour comprendre la maintenance, regardons simplement ce qui se passe quand on décide de ne pas en faire à Bruxelles.
Mois 1 à 3 : Tout semble parfait. L'application est en ligne sur l'App Store, les téléchargements arrivent. Vous vous dites que vous avez économisé un budget de maintenance inutile. Personne ne se plaint.
Mois 4 à 6 : Android sort une mise à jour majeure du système. Soudainement, votre écran de création de compte se fige sur les téléphones récents. Les utilisateurs ne disent rien, mais les premiers avis 1 étoile apparaissent. Votre note à Bruxelles passe de 4.8 à 4.1. Vous perdez de futurs téléchargements chaque jour.
Certains de mes clients travaillent avec moi depuis des années. Pourquoi ? Parce que je ne disparais pas dans la nature une fois l'application iOS ou Android publiée.
Basé à Cannes, j'accompagne mes clients sur la durée. Pendant mes 12 ans de carrière, j'ai compris que la sortie d'une app n'est que le début de l'histoire. Il faut l'améliorer, la maintenir, écouter les utilisateurs.
Le facteur le plus important est ce suivi rigoureux. Je suis là pour vous suivre dans la durée, comme un vrai partenaire.
L'économie de Bruxelles évolue vite. Très vite.
Les entreprises locales ne peuvent plus se contenter d'un simple site web vieillissant. La transformation numérique est partout en région bruxelloise. Et le mobile est devenu le centre de cette transformation. 🚀
En résumé : vos clients vivent avec leur téléphone dans la main.
C'est une réalité incontournable, l’essentiel du trafic web mondial provient des mobiles. Si votre entreprise à Bruxelles n'est pas facilement accessible sur leur écran d'accueil, elle n'existe presque plus aux yeux d'une grande partie du public.
J'accompagne les sociétés pour créer cette présence vitale. En France, des initiatives comme la France Num poussent d'ailleurs activement les TPE et PME à s'adapter aux nouveaux usages.
Ailleurs en Belgique, le constat est exactement le même. Les habitants de Bruxelles veulent pouvoir commander, réserver, ou s'informer en un clic depuis leur canapé ou dans les transports.
Bruxelles impose le bilinguisme presque par défaut, et souvent le trilinguisme si vous visez aussi la Flandre. Ce n'est pas qu'une affaire de traduction : les textes changent de longueur, les écrans bougent, et une interface pensée en français casse en néerlandais. On construit donc les écrans pour le texte le plus long dès le premier jour.
Le bilinguisme bruxellois a une particularité qui le distingue d'un simple projet multilingue : les deux langues coexistent dans le même lieu, souvent dans la même entreprise et parfois dans la même réunion. Cela veut dire qu'on ne peut pas décider de la langue une fois pour toutes au premier lancement et l'oublier. Un utilisateur doit pouvoir basculer à tout moment, l'application doit se souvenir de son choix, et les documents qu'elle génère — un devis, un reçu, une notification — doivent sortir dans la bonne langue sans qu'on ait à y penser.
Il y a aussi une dimension qui n'est pas technique et qu'il vaut mieux nommer : à Bruxelles, la langue n'est jamais neutre. Une application dont la version néerlandaise est visiblement une traduction bâclée du français envoie un message, et ce message coûte des utilisateurs. Je fais traduire par quelqu'un dont c'est la langue plutôt que de m'en remettre à un outil automatique, et je prévois ce coût dans le devis au lieu de le découvrir à la fin.
Un détail de publication propre à la Belgique, et qui se règle mal après coup : les stores n'ont qu'un pays « Belgique », mais ils affichent la fiche dans la langue de l'appareil. Une application publiée avec une seule description se présente donc en français à un utilisateur néerlandophone, ou l'inverse, dès le premier écran — celui où se décide l'installation. Fournir les deux fiches ne coûte presque rien au moment de la soumission ; les ajouter plus tard veut dire refaire les captures d'écran, qui portent du texte elles aussi.
Bruxelles concentre par ailleurs les institutions européennes et tout ce qui gravite autour : représentations, fédérations professionnelles, cabinets de conseil. Ces organisations ont des cycles de décision longs et plusieurs personnes à convaincre, ce qui rend inutile de promettre une grande livraison dans six mois. Je préfère livrer toutes les deux semaines quelque chose d'installable, même partiel : cela donne à vos interlocuteurs de quoi se prononcer sur du concret, et cela évite de découvrir un désaccord de fond au dernier moment.
Avec Invent Better, la personne qui comprend votre projet est celle qui l'écrit. Pas de commercial, pas de chef de projet intermédiaire, pas de transmission entre trois équipes. Vous parlez au développeur, du premier appel jusqu'à la mise en ligne. Sur un premier produit, où l'essentiel se décide dans les six premières semaines, cette proximité vaut plusieurs semaines de calendrier.
Pour bien maintenir une application à Bruxelles, il ne suffit pas d'attendre qu'un client vous appelle en criant. Il faut des capteurs de santé professionnels.
Une maintenance bien menée est régulière et ennuyeuse, c'est son intérêt. La première semaine sert à l'état des lieux et à l'installation de la surveillance des plantages. Ensuite le rythme s'installe : les incidents remontent automatiquement, les correctifs partent selon une priorité convenue, et un point régulier décide de ce qui attend.
Semaine 1, l'état des lieux : j'analyse l'application, j'installe la surveillance des plantages, je documente la base de code et je dresse la liste des problèmes immédiats.
Le cycle mensuel s'organise ensuite de la même façon :
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 à Bruxelles 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 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 ?
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 de la région bruxelloise.
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.
Prêt à lancer votre application à Bruxelles ?
Vous avez l'idée. Vous connaissez votre marché en région bruxelloise. Maintenant, il faut passer à l'action.
Mais pas n'importe comment. L'avantage clé de travailler ensemble, c'est la clarté. Je ne vous vendrai pas de fonctionnalités inutiles. Je ne vous ferai pas de grandes promesses sans lendemain.
Une bonne application, c'est faire juste ce qu'il faut, et le faire bien. Sachant qu’une grande partie des fonctionnalités d'une application ne sont jamais utilisées, inutile de s'éparpiller. C'est une question de logique : concentrons-nous sur l'essentiel pour vos futurs utilisateurs de Bruxelles.
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.