Mickael Romaniello, le développeur qui construit les applications Mickael Romaniello 30 minutes, sans slides, rien à préparer.

Développement application desktop à Montréal

Du concept à la publication. Un expert dédié, 12 ans d'expérience.

iOS & Android12 ans d'expérienceBasé en France
RÉSERVER UN APPEL →

En résumé : développement application desktop à Montréal (1 762 949 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.

Questions fréquentes

Avant la première ligne de code, quatre choses se décident : faut-il vraiment une application ou un site suffit-il, à quel nom sont ouverts les comptes développeur, quelles données personnelles l'application va traiter, et ce qui entre dans la première version. Le logo et la charte graphique peuvent attendre. Ces quatre points-là, non : ils changent l'architecture et le budget.

Comment savoir si j'ai besoin d'une application ou d'un site ?

Une condition et trois critères. La condition, c'est la fréquence : une application vit sur un écran d'accueil, et une icône ouverte une fois par an ne se rembourse jamais. Si vos clients reviennent chaque semaine, il suffit ensuite d'un critère sur trois — l'application se sert du téléphone lui-même, elle doit fonctionner sans réseau, ou elle a une raison légitime de vous rappeler. Sinon, un site fait le même travail pour moins cher, et je vous le dirai.

Faut-il protéger l'idée avant d'en parler ?

Une idée d'application ne se brevette pas en tant que telle ; ce qui se protège, c'est le nom — une marque déposée — et le code, protégé par le droit d'auteur dès son écriture. En pratique, le risque n'est presque jamais le vol : c'est de mettre six mois à sortir pendant qu'un autre sort en deux. Si le sujet vous inquiète, un accord de confidentialité se signe avant le premier appel, sans difficulté.

Dois-je avoir un logo et une charte graphique pour démarrer ?

Non, et c'est même plus sain de commencer sans. Le cadrage porte sur ce que fait l'application et pour qui ; l'habillage vient après, et il vient mieux quand on sait déjà quels écrans existent. Si vous avez déjà une identité, on s'en sert. Sinon, la première version peut être sobre et lisible — ce qui n'est pas un pis-aller : beaucoup d'applications gagneraient à le rester.

Peut-on tester l'idée avant de payer un développement complet ?

Oui, et c'est souvent la meilleure dépense du projet. Des maquettes cliquables qu'on met entre les mains de dix personnes révèlent en une semaine ce qu'un développement de trois mois révélerait trop tard. On voit où les gens hésitent, ce qu'ils ne trouvent pas, ce dont ils se fichent. C'est aussi ce qui permet de retirer des fonctions avant de les payer plutôt qu'après.

Les comptes développeur Apple et Google doivent-ils être à mon nom ?

Oui, toujours, et c'est un point sur lequel je ne transige pas. Les deux comptes sont payants — 99 € par an chez Apple, renouvelables, et 25 $ une seule fois chez Google Play — et se créent au nom de votre entreprise ; je travaille dessus avec un accès délégué. Une application publiée sous le compte d'un prestataire est une application que vous ne contrôlez pas : vous ne pouvez ni la mettre à jour ni la transférer sans lui. La création prend un peu de temps côté Apple, autant s'y prendre tôt.

Faut-il obliger l'utilisateur à créer un compte ?

Le plus tard possible. Un écran d'inscription en ouverture est la première cause d'abandon : la personne n'a encore rien vu et vous lui demandez déjà quelque chose. La bonne règle est de laisser essayer, puis de demander un compte au moment où il devient utile — pour retrouver ses données sur un autre appareil, pour payer, pour être reconnu. La plupart des applications gagnent des utilisateurs juste en déplaçant cet écran.

Comment gérer le RGPD dans une application mobile ?

La règle simple : ne collectez que ce dont vous vous servez vraiment, dites-le clairement, et laissez la personne revenir en arrière. Concrètement, ça veut dire une politique de confidentialité lisible, un consentement demandé au bon moment plutôt qu'en bloc au démarrage, et un moyen de supprimer son compte depuis l'application — Apple l'exige. Les fiches de confidentialité des deux stores doivent aussi correspondre à la réalité de ce que fait l'application.

Peut-on vendre des abonnements dans l'application ?

Oui, et il y a une règle à connaître avant de bâtir un modèle économique dessus : tout ce qui est consommé dans l'application passe par le système de paiement d'Apple ou de Google, qui prélève entre 15 % et 30 % selon votre chiffre d'affaires annuel. Vendre un service consommé ailleurs — une prestation physique, une commande livrée — se paie normalement. La différence n'est pas anecdotique, elle change le prix que vous devez afficher.

Que faut-il préparer avant le premier appel ?

Rien. Pas de cahier des charges, pas de présentation, pas de budget arrêté. Trente minutes suffisent si vous pouvez répondre à deux questions : qui va s'en servir, et qu'est-ce que ça leur fait gagner. Si vous avez déjà des captures d'écran d'applications qui vous plaisent, prenez-les — montrer ce qu'on aime est plus rapide que le décrire. Le reste, c'est mon travail de le poser.

Comment savoir si ce n'est pas le bon moment ?

Trois signaux, et je les dis pendant l'appel plutôt qu'au troisième mois. Si personne dans l'équipe ne pourra répondre à mes questions pendant le projet, ça n'avancera pas. Si le budget couvre le développement mais rien de l'année suivante, l'application mourra doucement. Et si l'objectif est de rassurer un investisseur plutôt que de servir un utilisateur, une maquette coûte cent fois moins cher et fait le même effet.

Le mobile ne résout pas tout

Tout le monde ne jure que par les smartphones aujourd'hui.

C'est vrai, la majorité des utilisateurs naviguent sur leur téléphone. Mais le mobile ne résout pas tout. Surtout pas quand on travaille sérieusement.

À Montréal, vos comptables, vos designers et vos chefs d'entrepôt ne font pas leur métier sur un écran de six pouces. Ils ont besoin d'un grand écran. D'un vrai clavier. D'une puissance de calcul qui ne fond pas au soleil.

Le point essentiel : le bureau représente encore une part importante du trafic web. Et dans le monde de l'entreprise, ce chiffre explose.

Qu'est-ce que le développement desktop ?

Un logiciel de bureau s'installe sur l'ordinateur plutôt que de s'ouvrir dans un navigateur. Ce choix donne accès au disque, à la mémoire et au matériel de la machine, et permet de continuer à travailler sans internet. En échange, il faut organiser l'installation, la signature du logiciel et l'arrivée des mises à jour — trois sujets que le web ne pose pas.

C'est la création de logiciels qui s'installent directement sur votre ordinateur. Mac ou Windows.

Il y a plusieurs façons de construire une application bureau Montréal. Et c'est un peu comme choisir un véhicule.

D'abord, il y a le natif. Pour les ordinateurs Apple, on utilise Swift. Vous pouvez lire les recommandations sur les Human Interface Guidelines d'Apple. C'est comme acheter une voiture de sport pensée uniquement pour les routes de Montréal. C'est ultra rapide, parfaitement intégré, mais ça ne roule que sur Mac.

Pour Microsoft, c'est C\# et.NET. La machine de guerre classique pour les entreprises.

Mickael
Mickael Romaniello
Ingénieur Mobile
12+ans 15+proj. 4.8

Pourquoi choisir un expert à Montréal ?

L'économie de Montréal é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 au Québec. 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 à Montréal 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 au Canada, le constat est exactement le même. Les habitants de Montréal veulent pouvoir commander, réserver, ou s'informer en un clic depuis leur canapé ou dans les transports.

Travailler avec Montréal

Montréal est le meilleur des deux mondes pour moi : on travaille en français, et le décalage de six heures joue en votre faveur plutôt que contre vous. Vous m'envoyez vos retours en fin de journée, je travaille pendant votre nuit, et vous retrouvez une nouvelle version en ouvrant votre ordinateur. Sur un projet de plusieurs mois, cela change le rythme.

Il faut nommer la contrepartie, parce qu'elle existe. Six heures de décalage veulent dire que nos journées se chevauchent d'environ trois heures : votre matin, ma fin d'après-midi. C'est suffisant pour un point hebdomadaire et pour régler une question bloquante le jour même, ce n'est pas suffisant pour un projet qui a besoin de conversation continue. Si le vôtre en a besoin, je vous le dirai avant de commencer plutôt qu'après, parce que le mauvais choix coûte un mois à tout le monde.

Le français québécois mérite qu'on s'y arrête. Traduire une application française pour le marché québécois n'est pas rien : le vocabulaire technique diffère, certaines tournures sonnent étrangères, et l'anglicisme qui passe à Paris peut détonner à Montréal. Je pars du principe que les textes doivent être relus par quelqu'un d'ici avant publication, et je prévois ce temps-là. Une application dont la langue sonne importée perd une partie de sa crédibilité avant même qu'on regarde ce qu'elle fait.

Si l'application encaisse de l'argent, deux choses se décident tôt. Les prix des stores fonctionnent par paliers, pas en montants libres : le prix affiché en dollars canadiens ne sera pas la conversion exacte de votre prix en euros, et mieux vaut choisir le palier que le subir. Et la fiscalité canadienne se joue à deux niveaux, fédéral et provincial, ce qui ne change pas le code mais change ce que vous devez afficher et déclarer. Pour un abonnement vendu dans l'application, le store s'en charge ; pour une prestation livrée ailleurs, non.

Sur le plan réglementaire, le Québec a ses propres règles en matière de langue et de protection des renseignements personnels, plus strictes que la moyenne nord-américaine. Elles ont des conséquences concrètes sur une application : consentements explicites, information claire sur ce qui est collecté, et une interface disponible en français. Je ne donne pas de conseil juridique, mais je conçois en partant du principe que ces exigences s'appliquent, ce qui coûte beaucoup moins cher que de les découvrir après le lancement.

Pourquoi Invent Better ?

Une application peut être développée vite et pour peu cher. Ce qui coûte, c'est la suite : un code écrit sans structure devient impossible à modifier, et la moindre évolution demande de tout reprendre. Invent Better facture le travail qui rend la deuxième version possible — des tests, une architecture lisible, et un code qu'un autre développeur peut reprendre.

Il est tout à fait possible de développer une application très vite et pour vraiment pas cher.

Il suffit d'ignorer les règles de base, de copier-coller des morceaux de code trouvés sur internet, et de croiser les doigts pour que ça tienne. Le jour de la présentation à Montréal, l'application aura l'air de fonctionner.

Mais le vernis va craquer très rapidement.

Dès que vous aurez plus de dix utilisateurs en même temps, le système va ralentir. Sur mobile, la patience est très courte. Et la lenteur, c'est perçu comme un bug.

Pire, l'application va planter en pleine nuit. Et là, l'utilisateur ne pardonne pas.

Le rythme : ce que vous recevez toutes les deux semaines

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 au Québec, sans me demander.

Et si une version manque, vous le voyez tout de suite. C'est le but.

« Un cas concret vaut mieux que mille promesses. »

Étude de cas : Contrôle d'usine en temps réel

Un poste de pilotage en production ne peut pas dépendre d'internet. Si le réseau tombe et que l'outil s'arrête, c'est la ligne qui s'arrête. Un logiciel installé continue de fonctionner, conserve ses mesures et se resynchronise plus tard. C'est la raison pour laquelle certains métiers ne passeront jamais au tout en ligne.

Le cas type en industrie : un tableau de bord pour les opérateurs sur ligne de production. L'usine tourne 24 heures sur 24. La connexion internet de la zone industrielle de Montréal est instable.

Une application web était impossible. Si le réseau coupe, l'usine s'arrête. Il fallait du développement application desktop Montréal. Une solution "offline-first".

Le vrai coût d'un logiciel sur mesure

La meilleure question est celle du coût de votre outil actuel. Un salarié qui passe deux heures par jour à recopier des données entre trois logiciels lents représente un coût, tout comme le fichier de suivi qui plante et perd une matinée de travail. Face à cela, un logiciel sur mesure est souvent comparé au mauvais chiffre : le devis, plutôt que l'existant.

Le coût qui revient chaque année n'est pas le développement : ce sont les versions majeures des systèmes. Windows et macOS en publient chacun une par an, et chacune peut demander une adaptation.

Le bureau au service de la conception et de la santé

La conception et la santé partagent une exigence que le web tient mal : travailler sur des fichiers volumineux, en local, sans dépendre de la qualité de la connexion. Un logiciel installé accède au disque, à la mémoire et au matériel de la machine — c'est ce qui sépare un outil de production d'une interface de consultation.

Le web a ses limites quand on touche à l'image haute définition ou aux données ultra-protégées. C'est pour cela que de nombreux secteurs à Montréal privilégient le développement application desktop Montréal.

Mickael
Mickael Romaniello
Ingénieur Produit Mobile — Cannes, France

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.

Pendant que vous hésitez, vos concurrents à Montréal 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. ⏳

Prêt à commencer ?

30 minutes. Sans engagement. Sans jargon.

RÉSERVER UN APPEL GRATUIT →

30 minutes pour démarrer

Réserver →

À propos de l'auteur

Mickael Romaniello — Ingénieur produit mobile basé dans le Sud de la France. 12 ans d'expérience en développement d'applications iOS, Android et desktop. Plus de 15 projets livrés pour des startups, ETI et grands comptes. LinkedIn.

Dernière mise à jour:

Standards et références

Apple Human Interface Guidelines · Google Material Design · web.dev (Google) · MDN Web Docs · OWASP Mobile Top 10