Mickael Romaniello
30 minutes, sans slides, rien à préparer.
Mickael Romaniello
30 minutes, sans slides, rien à préparer.
Du concept à la publication. Un expert dédié, 12 ans d'expérience.
En résumé : création d'application mobile à Québec (549 459 habitants), c'est un projet piloté par un expert senior — pas une agence. Communication directe, code livré, publication sur l'App Store et Google Play en quelques semaines.
Ces questions portent sur la relation de travail plutôt que sur la technique : comment on communique, comment on paie, ce qui se passe si le résultat ne convient pas. Le fonctionnement est simple — un canal direct avec moi, une version installable toutes les deux semaines, un acompte à la commande puis un paiement mensuel qui suit l'avancement.
Notre collaboration se fait à une grande partie à distance via des appels vidéo. Travailler en distanciel est devenu la norme d'efficacité absolue. Fini les pertes de temps dans les transports. Pour les projets de grande envergure dépassant un certain budget, je peux me déplacer à Québec pour animer des ateliers de lancement en personne. Mais au quotidien, nous communiquons via votre canal préféré (WhatsApp, Slack ou email), nous validons les designs ensemble, et nous faisons nos revues de projet via Google Meet, WhatsApp ou Telegram. C'est plus rapide, plus direct et beaucoup plus économique pour tout le monde.
Ce n'est absolument pas obligatoire. En réalité, je préfère largement commencer par un simple appel vidéo de quinze minutes. Beaucoup de clients passent des mois à rédiger des cahiers des charges de cinquante pages qui deviennent obsolètes dès la deuxième semaine de développement. Le facteur le plus important est de définir le problème principal que vous voulez résoudre au Québec. Ensuite, nous construisons ce cahier des charges ensemble, de manière agile, en nous basant sur les besoins réels des utilisateurs et non sur des théories.
J'ai livré plus de quinze projets d'envergure dans des secteurs très variés : la santé, le tourisme, l'e-commerce, la logistique et l'éducation. Même si je n'ai pas encore travaillé spécifiquement dans votre micro-niche, les principes fondamentaux de la création d'une application mobile sont totalement universels. Les standards de qualité restent les mêmes. Ce qui change, c'est votre logique d'affaires locale. Mon rôle est de comprendre cette logique métier lors de notre appel de découverte et de la traduire en une solution technique imparable pour vos clients.
Le paiement est divisé en trois étapes claires, sans aucune surprise. Généralement, c'est un acompte au démarrage pour bloquer le planning, une tranche au milieu du développement quand je vous livre une première version testable, et le solde à la livraison finale sur les stores. Pour les très gros projets de plusieurs mois, je lisse les paiements mensuellement. Tout est détaillé par écrit dans le devis initial, et je ne facture jamais d'heures cachées pour des petits ajustements de dernière minute.
Les démonstrations hebdomadaires rendent cette situation pratiquement impossible. Vous ne découvrez pas le produit fini six mois après la signature. Tous les quinze jours, je vous montre une version fonctionnelle. Vous donnez vos retours depuis Québec, et je corrige le tir immédiatement. Si nous partons dans la mauvaise direction, nous le savons au bout de sept jours, pas à la fin de l'année. De plus, si lors de notre premier appel, je sens que vos attentes sont techniquement irréalisables, je vous le dirai honnêtement. Mieux vaut refuser un projet que de décevoir.
Oui, je reprends des projets développés par d'autres prestataires ou des équipes offshore. La première étape incontournable est un audit technique d'une semaine. On regarde sous le capot. Ensuite, je dresse un plan d'action strict : nous corrigeons d'abord les bugs critiques qui font fuir vos utilisateurs, nous consolidons l'architecture technique, puis seulement nous ajoutons vos nouvelles fonctionnalités. C'est souvent beaucoup plus rentable pour votre entreprise au Canada que de tout jeter pour recommencer à zéro.
Nous utilisons des canaux directs, asynchrones et sans friction. Pour les questions rapides au quotidien, c'est Slack. Vous pouvez m'écrire quand une idée vous vient. Pour valider l'interface visuelle, nous examinons les maquettes ensemble : vous laissez vos commentaires directement sur les écrans dessinés. Pour le code, tout est hébergé sur GitHub de manière transparente. Enfin, nous faisons un point d'étape vidéo en direct de trente minutes chaque semaine. Je m'adapte aux outils avec lesquels vos équipes à Québec sont déjà à l'aise. L'objectif est l'efficacité absolue.
Je suis basé sur le fuseau horaire d'Europe centrale (CET) à Cannes. Pour mes clients européens, je suis pleinement disponible aux heures de bureau classiques, entre 10h et 18h. Si vous êtes situé sur un autre continent, je m'adapte avec souplesse. Pour les clients dans des fuseaux horaires proches, nous travaillons en temps réel total. Pour les clients plus éloignés, je m'adapte avec des horaires flexibles et des vidéos de mise à jour enregistrées. Mon temps de réponse moyen en semaine est toujours inférieur à quatre heures, où que vous soyez.
Oui, je propose des contrats mensuels ou annuels sur mesure. Ces contrats incluent les mises à jour obligatoires d'Apple et Google, la réparation des bugs silencieux et la surveillance des performances en direct. C'est le seul moyen de protéger votre investissement. Les statistiques le prouvent, la plupart des utilisateurs désinstallent une app après un seul plantage technique. Nous pouvons aussi y inclure une banque d'heures dédiée à la création de nouvelles petites fonctionnalités. Le coût tourne généralement autour de sensiblement du devis initial par an.
La première erreur est de vouloir construire trop de fonctionnalités d'un coup. Les données montrent qu’une grande partie des fonctionnalités sont ignorées par les utilisateurs. Commencez toujours léger. La deuxième erreur est de choisir son prestataire uniquement sur le prix. Un développement low-cost vous coûtera trois fois plus cher quand il faudra tout refaire à cause d'une architecture défaillante. La troisième erreur est de croire qu'une application est finie une fois publiée. L'absence de maintenance tue les meilleurs projets. Mon travail est de vous éviter ces trois pièges.
Avant de parler d'application, une question vaut la peine d'être posée : est-ce qu'il vous en faut une ?
Beaucoup de projets à Québec n'ont pas besoin d'être installés. Un site qui marche bien sur téléphone fait souvent le même travail, coûte moins cher, et ne demande à personne d'aller chercher quoi que ce soit dans un store.
L'application se justifie quand il faut fonctionner sans réseau, utiliser l'appareil photo ou la position en continu, envoyer des notifications, ou quand vos utilisateurs reviennent plusieurs fois par semaine. Si rien de tout ça n'est vrai, je le dis au premier appel.
Quand elle se justifie, en revanche, elle fait des choses qu'aucun site ne fera. C'est de ça que parle cette page.
Le vocabulaire du métier cache une réalité simple. Le natif désigne une application écrite avec les outils officiels d'Apple et de Google. L'hybride désigne un code unique adapté aux deux. Le back-end désigne le serveur, et l'API la façon dont l'application lui parle. Ce qui compte pour vous n'est pas le mot mais la conséquence : le coût, la vitesse et ce que vous pourrez modifier ensuite.
Trois façons de construire, trois conséquences :
Mon rôle est de vous guider vers celui qui correspond à vos ambitions à Québec, sans vous faire payer une Ferrari s'il vous faut une citadine fiable.
La peur numéro un, quand on lance un projet d'application, c'est de perdre le contrôle : on signe un devis, on confie son idée, et on n'entend plus rien pendant trois mois. Le fonctionnement décrit ici existe pour que ça n'arrive pas.
Trois règles, les mêmes sur chaque projet :
Vous testez l'application sur votre téléphone toutes les deux semaines.
Québec a un tissu de PME solide et une vraie exigence sur la langue : une application à moitié traduite s'y remarque tout de suite et se pardonne mal. Le français y est un critère de qualité, pas une case à cocher, ce qui me convient — j'écris les textes de l'application moi-même plutôt que de les faire passer par un traducteur automatique.
Écrire les textes soi-même change plus de choses qu'on ne l'imagine. Les mots d'une application ne sont pas de la décoration : un bouton mal nommé produit des erreurs d'usage, un message d'erreur vague produit des appels au support, et une phrase d'accueil confuse produit des désinstallations. Quand la personne qui écrit le code écrit aussi les libellés, elle peut ajuster l'un en fonction de l'autre — raccourcir un texte parce qu'il déborde, ou changer un écran parce qu'aucune formulation courte ne le rend clair.
Le tissu de PME donne aux projets de Québec un profil assez différent de celui de Montréal. Moins de startups, plus d'entreprises établies avec des processus qui fonctionnent déjà et qu'il s'agit de prolonger. Ces projets ont l'avantage d'avoir de vrais utilisateurs dès le premier jour, ce qui supprime la plus grosse incertitude d'un lancement. Ils ont l'inconvénient de devoir cohabiter avec l'existant : un logiciel de gestion, parfois ancien, dont il faut respecter les données et les habitudes.
Un mot sur les appareils, parce que le profil des PME le rend visible ici. Les équipes de terrain gardent leur téléphone longtemps, et une application qui ne fonctionne que sur les modèles récents laisse une partie du personnel de côté — celle qui en a le plus besoin. La version minimale du système à supporter est donc une vraie décision, pas un réglage par défaut : on regarde ce que les gens ont réellement en main avant de la fixer, et on la relève plus tard, quand les statistiques d'usage montrent que plus personne n'est resté derrière.
Le décalage horaire de six heures fonctionne ici comme à Montréal, et sur un projet de longue durée il est plutôt un avantage : vous relisez le matin ce qui a été fait pendant votre nuit, et vos commentaires partent au travail pendant que vous faites autre chose. Le rythme naturel devient une livraison par jour ouvré plutôt qu'une par semaine, ce qui laisse beaucoup moins de place aux malentendus qui s'installent.
Le travail ne s'arrête pas à la publication. Une application vit sur des systèmes qui bougent : iOS et Android sortent chacun une version majeure par an, et une application non maintenue finit par être retirée des stores. Invent Better prévoit cette suite dès le devis, plutôt que de la présenter comme un imprévu six mois après le lancement.
Il y a un mythe tenace dans notre métier. Celui qui consiste à croire que le travail s'arrête le jour de la publication sur les stores.
Vous appuyez sur le bouton, l'application est disponible à Québec, on sable le champagne, et l'équipe de développement disparaît dans la nature pour passer au client suivant.
C'est la pire chose qui puisse arriver à votre projet.
Une application mobile, ce n'est pas un tableau qu'on accroche au mur et qu'on ne touche plus jamais. C'est un organisme vivant.
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 à Québec.
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 site adaptatif n'est pas une application, et la différence se voit sur le tunnel d'achat : trop d'étapes, boutons trop petits, chargement lent, numéro de carte à ressaisir à chaque commande. Chacun de ces points perd des clients séparément. Les corriger un à un vaut mieux qu'une refonte complète, parce qu'on mesure alors ce qui a servi.
Imaginez une entreprise de vente en ligne bien connue. Cette marque possédait un site web dit responsive, censé s'adapter aux téléphones.
Leur trafic mobile représentait beaucoup de leurs visites totales. C'était leur vitrine principale sur mobile. Mais le taux de conversion sur mobile était très inférieur à celui de l'ordinateur. Ils perdaient littéralement de l'argent chaque jour.
Le problème était évident. Le tunnel d'achat était un enfer de friction.
Il n'existe pas de prix unique pour une application mobile. Ce qui fixe le montant, c'est le périmètre : le nombre d'écrans, la nécessité d'un serveur et de comptes utilisateurs, et le fait de viser une plateforme ou deux. Un appel de cadrage donne une fourchette réelle.
Trois facteurs fixent le budget, plus deux dépenses fixes :
Éducation, restauration et logistique se ressemblent sur un point : l'application est utilisée debout, vite, souvent avec une seule main. Le cours se regarde dans les transports, la commande se prend au comptoir, la livraison se valide sur le quai. Chacune impose le mode hors ligne et une interface qui pardonne les gestes approximatifs.
Le marché mondial de l'apprentissage en ligne est en croissance chaque année. Et pour cause, les étudiants et les professionnels du Québec veulent se former partout, tout le temps.
Une bonne plateforme d'e-learning sur mobile, ce n'est pas juste des vidéos posées en vrac. C'est la possibilité de télécharger ces cours pour les regarder dans le métro de Québec sans utiliser son forfait de données.
Je construis des applications mobiles comme un artisan construit une maison. Avec des fondations solides.
J'exerce ce métier depuis 12 ans depuis Cannes, en concevant des applications iOS et Android faites pour durer. Je refuse le travail bâclé. L'avantage clé de cette méthode ? Votre application ne s'effondrera pas à la première mise à jour d'Apple ou de Google.
Je crée des outils propres, faciles à maintenir et prêts à évoluer avec votre PME ou votre startup. Un travail fait avec soin, c'est un investissement rentable sur le long terme.
Pendant que vous hésitez, vos concurrents à Québec avancent.
Le monde du mobile va vite. Très vite. Aujourd'hui, l’essentiel du trafic web mondial provient des mobiles. Si vous repoussez sans cesse la création de votre application, d'autres prendront votre place au Québec.
Mais attention, il ne faut pas confondre vitesse et précipitation. Lancer une application instable est la pire des stratégies.
En résumé : il faut faire vite, mais il faut surtout faire bien. ⏳
30 minutes pour démarrer
Réserver →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.