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é : développement application ios à 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 arbitrent entre des options : natif ou hybride, abonnement ou achat, quel outil d'interface, quel niveau de maintenance après la publication. Le critère de décision est le même partout — ce que vous devrez pouvoir modifier dans un an. Le natif coûte un peu plus au départ et beaucoup moins quand l'application vit longtemps.
Pour un rendu premium, le natif est roi. L'avantage clé, c'est l'expérience utilisateur qui sera toujours supérieure avec les technologies d'Apple par rapport à un outil hybride.
Non, TestFlight est gratuit. Il est inclus dans votre abonnement de développeur Apple à un abonnement annuel.
près d’une soumission sur quatre est rejetée. Souvent pour des bugs non traités, un manque de valeur, ou le non-respect des règles de paiement d'Apple.
Oui, si vous souhaitez que l'application s'affiche au nom de votre entreprise de Québec sur le Store. Si vous publiez en nom propre, il n'est pas nécessaire.
Bien sûr. C'est même recommandé. En moyenne, les utilisateurs iOS dépensent davantage dans les applications que les utilisateurs Android. L'écosystème s'y prête parfaitement.
Cela dépend de la complexité. Une V1 simple peut prendre 4 à 8 semaines de code, plus le temps incompressible de création de compte et de validation par Apple.
Oui. iOS évolue chaque année en septembre. Il faut s'assurer que votre code reste compatible avec les nouvelles règles et les nouveaux iPhone.
C'est l'outil fourni par Apple pour dessiner les écrans. C'est ce qui nous permet de coder rapidement des interfaces magnifiques et réactives.
Oui, mais Apple exige que l'on justifie très clairement à l'utilisateur pourquoi nous en avons besoin. C'est une question de logique et de respect de la vie privée.
C'est exigeant. Apple traite 100 000+ soumissions par semaine. C'est pour cela que je gère cette étape pour vous, pour garantir un lancement réussi à Québec.
Sur iPhone, votre calendrier n'est pas tout à fait le vôtre.
Apple publie une version majeure d'iOS chaque automne, et ses utilisateurs l'installent vite — beaucoup plus vite que sur les autres plateformes. En quelques semaines, l'essentiel de votre public à Québec est passé au nouveau système.
C'est une bonne nouvelle : vous n'avez pas à supporter éternellement de vieilles versions. C'en est une moins bonne si personne ne s'en occupe, parce que chaque version change quelque chose — une autorisation qui se demande autrement, un composant d'interface qui se dessine différemment, une règle du store qui se durcit.
Une application iOS se prévoit donc sur deux calendriers : le vôtre, et celui d'Apple.
Lancer sur les deux plateformes en même temps double le coût de la première version sans doubler ce qu'on apprend. Avec un budget contraint, commencer par une seule plateforme — celle où sont vos utilisateurs — permet de valider le produit, puis de porter l'autre en sachant quoi construire. L'ordre inverse coûte deux fois plus cher pour la même leçon.
Lancer une application coûte de l'argent et du temps.
Faut-il lancer sur iOS et Android en même temps ? Ou commencer par iOS ?
Si vous avez un budget serré à Québec, commencer par iOS est souvent le meilleur choix.
Le facteur le plus important est la rentabilité.
En moyenne, les utilisateurs iOS dépensent davantage dans les applications que les utilisateurs Android.
Ils sont plus enclins à payer pour des abonnements, des services premium et des achats intégrés.
En développant d'abord sur iPhone, on valide votre modèle économique plus rapidement.
De plus, l'écosystème matériel est maîtrisé.
Il y a une poignée de modèles d'iPhone récents.
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.
Équiper des commerciaux d'une tablette pose un problème simple et souvent mal traité : ils travaillent chez le client, sans connexion garantie. L'application doit donc fonctionner entièrement hors ligne et synchroniser au retour. Le vrai sujet n'est pas l'affichage mais la règle qui tranche quand deux personnes ont modifié la même fiche chacune de leur côté.
Le B2B, ce n'est pas forcément que du web.
Le cas type : une entreprise industrielle qui veut équiper ses commerciaux sur le terrain.
Ils avaient tous des iPad fournis par l'entreprise.
Le point essentiel : il fallait une application robuste, capable de fonctionner sans connexion internet dans des entrepôts.
Oubliez les solutions web hybrides qui saccadent.
Nous sommes partis sur du développement iOS entièrement natif.
L'utilisation de Core Data a permis de stocker tout le catalogue produit en local sur l'iPad.
Une application iOS native coûte plus cher qu'un équivalent web ou hybride. La raison tient aux exigences d'Apple : ses règles de design demandent du soin sur chaque écran, chaque bouton et chaque animation, et la revue de l'App Store refuse ce qui ne s'y conforme pas. Ce surcoût achète surtout moins de risque de refus.
Publier sur l'App Store suppose un programme développeur Apple à 99 € par an, renouvelable. Apple indique dans son rapport de transparence 2024 avoir examiné 7,77 millions de soumissions et en avoir rejeté 1,93 million — près d'une sur quatre.
C'est la question que tout le monde se pose à Québec.
Soyons clairs : une application iOS native coûte plus cher qu'une application web ou hybride.
Pourquoi ?
Le facteur le plus important, c'est le niveau d'exigence d'Apple.
Les règles de design d'Apple imposent un soin particulier à chaque écran, chaque bouton, chaque animation.
On ne peut pas faire d'à-peu-près.
Voyage haut de gamme, outils professionnels et services à la demande ont un point commun : leurs utilisateurs paient. Sur ces marchés, une application iOS bien faite rentabilise plus vite qu'une couverture large et approximative. Le bon ordre est presque toujours iOS d'abord, Android quand le modèle est validé.
Certains business modèles s'accordent naturellement avec l'univers Apple.
En résumé, voici pourquoi ces secteurs privilégient l'iPhone.
Une clientèle qui voyage avec un budget conséquent possède souvent un iPhone.
L'interface native iOS permet d'offrir une expérience de réservation fluide, des notifications riches avec des images, et une géolocalisation ultra-précise.
Apple traite 100 000+ soumissions par semaine, et les applications de voyage fluides sont toujours mises en avant.
La continuité entre le Mac, l'iPad et l'iPhone est la grande force d'Apple.
Si vous créez un outil de productivité pour les entreprises à Québec, l'application iOS est la porte d'entrée.
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.