Du concept à la publication. Un expert dédié, 12 ans d'expérience.
En résumé : maintenance 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 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 du Québec.
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.
Votre application dépend de code que vous n'avez pas écrit.
Une application moderne s'appuie sur des bibliothèques et des services extérieurs : l'envoi des notifications, le paiement, les cartes, la connexion, la mesure d'audience. Chacun est maintenu par quelqu'un d'autre, avec son propre calendrier, ses propres changements de règles, et parfois sa propre fin de vie.
C'est là que casse une application qu'on croyait tranquille. Le code n'a pas bougé, l'entreprise de Québec n'a rien demandé, et pourtant la connexion ne fonctionne plus parce qu'un service extérieur a changé sa façon de faire.
Suivre ces dépendances est une part du travail de maintenance qu'on voit rarement venir, et qu'on paie toujours.
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 à Québec.
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 à Québec passe de 4.8 à 4.1. Vous perdez de futurs téléchargements chaque jour.
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.
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 à Québec 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 chiffre pas une maintenance sans avoir vu l'application, parce que la dette technique et le trafic diffèrent à chaque fois. Je travaille donc par niveaux. Le niveau essentiel couvre la surveillance, la correction des bugs critiques et la compatibilité avec chaque nouvelle version d'iOS et d'Android. Les niveaux supérieurs ajoutent des évolutions à rythme mensuel prévisible.
Le rythme est dicté par les plateformes : Apple publie une version majeure d'iOS chaque septembre depuis 2013, Google une version d'Android chaque année. Chacune peut changer une autorisation ou retirer une interface, sans que votre code ait bougé.
Je ne fais pas de devis standard sans voir le patient. Chaque application à Québec est unique, a une dette technique différente et un trafic différent. Mais voici comment je structure mes niveaux d'accompagnement.
Éducation, restauration et logistique tournent sur des appareils partagés et souvent anciens, ce qui rend la maintenance moins spectaculaire et plus constante. Les problèmes viennent rarement d'un bug franc : ils viennent d'une version du système qui change une autorisation, ou d'un appareil trop vieux pour la dernière bibliothèque.
La survie d'une application sur le long terme dépend de sa capacité à encaisser les usages spécifiques de son secteur à Québec.
L'optimisation du contenu est vitale. Les vidéos de cours et les documents lourds peuvent faire exploser le poids de l'application avec le temps. Je surveille la performance du streaming vidéo et la fiabilité du téléchargement hors-ligne pour les étudiants du Québec. Le système de notifications aux parents doit également rester parfaitement synchronisé à chaque mise à jour OS.
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.