Du concept à la publication. Un expert dédié, 12 ans d'expérience.
En résumé : développement application android à 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 ce qui fait qu'une application Android tient dans la durée : la batterie, les autorisations, les blocages d'interface, le formulaire de sécurité des données exigé par Google, et les appareils sur lesquels on teste vraiment. Ce sont des sujets d'ingénierie plus que de conception, et ce sont eux qui décident de la note laissée sur le store.
Pour un projet initial propre (MVP), comptez entre 2 et 4 mois de travail. Il faut faire les choses bien pour le marché de Québec.
C'est un document obligatoire sur le Google Play Store. Il explique aux utilisateurs de la région Québec quelles données vous récoltez et pourquoi. Je le remplis avec vous.
En optimisant le code. Des tâches de fond mal gérées vident la batterie, et l'utilisateur supprime l'application. On se pose, on réfléchit à l'architecture.
Oui, l'API de Google permet de bloquer l'usage si l'utilisateur de Québec a une version trop ancienne. Très pratique pour la sécurité.
La règle d'or : expliquer la valeur, puis demander. Si on demande accès à la caméra sans raison à l'ouverture, l'utilisateur du Canada refuse.
C'est quand l'application fige. C'est perçu comme un bug. Le point essentiel est d'optimiser la vitesse pour éviter que l'écran ne bloque.
Oui, les deux langages cohabitent. Si vous avez une vieille application à Québec, on peut l'améliorer progressivement en Kotlin.
J'intègre le design. Si vous n'avez pas de designer UI/UX, je collabore avec des experts qui créeront les écrans pour vous.
J'utilise des appareils physiques (Samsung, Pixel, Xiaomi) et des émulateurs couvrant un large spectre de tailles d'écrans.
Contactez-moi en bas de cette page. On organise un appel pour valider que votre idée tient la route techniquement.
Android n'est pas un téléphone. C'est des milliers de téléphones différents.
C'est ce qui fait sa force — vos clients à Québec en ont un, quel que soit leur budget — et c'est ce qui rend le travail différent d'iOS. Un même écran doit tenir sur un petit appareil d'entrée de gamme comme sur une grande tablette, avec des versions du système qui vont de l'ancienne à la toute dernière.
Chaque fabricant ajoute par-dessus sa propre couche, qui change la gestion de la batterie, les notifications et parfois le clavier. Une application qui n'a été essayée que sur un seul modèle se comporte autrement chez la moitié de ses utilisateurs.
C'est la première chose qu'on cadre : sur quels appareils réels votre application doit tenir debout.
Commencer par Android ou par iOS dépend de deux choses : où sont vos utilisateurs, et quel est votre budget. Android donne accès au parc le plus large, notamment sur les appareils d'entreprise et les téléphones d'entrée de gamme. iOS concentre les utilisateurs qui dépensent le plus. Il n'y a pas de bonne réponse générale, seulement une bonne réponse pour votre marché.
Souvent, on me demande s'il faut commencer par iOS ou par Android pour un projet à Québec.
La réponse dépend de votre cible et de votre budget.
L'avantage clé d'Android, c'est sa portée massive.
Surtout dans les marchés émergents ou pour le grand public.
Mais il y a une différence fondamentale avec Apple.
Apple contrôle tout. Ils ont une vingtaine de modèles d'iPhone en circulation. C'est facile à tester.
Android, c'est le grand ouest.
Google indique qu'il y a plus de 24 000 modèles d'appareils Android actifs.
Certains ont des écrans minuscules. D'autres tournent sur des versions Android vieilles de cinq ans.
Cette fragmentation rend les tests beaucoup plus complexes et coûteux.
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.
Quand une entreprise vend bien sur le web et mal sur mobile, la cause est presque toujours la lenteur avant d'être l'ergonomie. Une application native charge ses données autrement qu'une page web : elle garde en mémoire ce qui ne change pas, précharge la suite, et fonctionne encore quand le réseau faiblit. C'est ce que le site adaptatif ne sait pas faire.
Récemment, j'ai accompagné une entreprise de e-commerce qui voulait relancer ses ventes locales à Québec.
Leur site web marchait bien. Mais sur mobile, c'était la catastrophe.
La plupart des utilisateurs abandonnent une navigation si le chargement dépasse 3 secondes.
Il leur fallait une application Android native pour fidéliser leur clientèle de la région Québec.
En résumé, l'objectif était simple : rendre l'achat ultra-rapide.
Nous avons développé l'application en Kotlin.
Une application Android coûte généralement moins cher que son équivalent iOS. La raison est pratique plutôt que technique : les outils de développement de Google sont gratuits et plus souples, et le compte développeur Play se paie une seule fois au lieu d'être annuel. C'est le périmètre de votre application qui fixe le montant ; la plateforme ne le déplace qu'à la marge.
Le compte Google Play Console coûte 25 $, une seule fois, à l'inscription. C'est la dépense fixe la plus faible des deux plateformes — le programme développeur d'Apple, lui, se renouvelle à 99 € chaque année.
Je ne vais pas vous mentir. Créer une bonne application Android à Québec représente un investissement.
Souvent, on constate que le développement Android coûte sensiblement moins cher que son équivalent iOS.
Pourquoi ?
Parce que les outils de développement fournis par Google sont gratuits et souvent plus souples.
Les applications grand public, l'immobilier et l'éducation cherchent la portée avant la marge. Android donne accès à la plus grande partie du parc mondial, et ses outils de diffusion permettent d'ouvrir progressivement — quelques testeurs, puis un groupe fermé, puis le public. C'est ce qui rend un premier lancement moins risqué.
Chaque domaine a ses problématiques. Android possède souvent la réponse technique appropriée pour votre entreprise à Québec.
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.