Mickael Romaniello
30 minutes, sans slides, rien à préparer.
Mickael Romaniello
30 minutes, sans slides, rien à préparer.
12 ans d'expérience. 15+ applications livrées. Un seul interlocuteur, du concept à la publication.
En résumé : pour votre projet à Namur (112 128 habitants), en Wallonie, vous travaillez directement avec moi, pas un intermédiaire. 12 ans d'expérience, 15+ applications livrées, et un processus transparent de A à Z.
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 à Namur 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.
« Une application iOS » ne désigne pas une seule chose. L'iPhone est le point de départ, mais la même base peut servir sur iPad, sur Mac et, dans une moindre mesure, sur Apple Watch. Chaque appareil ajouté a un coût réel, et la question se tranche au cadrage plutôt qu'en cours de route.
L'iPad n'est pas un grand iPhone. L'écran change la mise en page, l'application peut se retrouver affichée à côté d'une autre, et certains usages n'ont de sens que là — remplir un formulaire long, annoter un document, montrer quelque chose à un client à Namur.
Le Mac est le cas le plus rentable quand il se justifie : une bonne partie du travail est déjà faite, et l'application peut tourner sur ordinateur avec des ajustements plutôt qu'une réécriture. Encore faut-il l'avoir prévu.
La Watch est un cas à part. Elle ne convient qu'à des usages très courts — un coup d'œil, une validation, une notification qu'on peut traiter sans sortir son téléphone. Y porter une application entière ne marche jamais.
Mon conseil au départ est presque toujours le même : l'iPhone seul, bien fait, et le reste quand l'usage le réclame.
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.
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.
Namur est une ville administrative, et beaucoup de demandes y viennent du secteur public ou para-public. Cela change le rythme : les décisions passent par plusieurs personnes, les délais sont plus longs, et il vaut mieux livrer par petits morceaux validables que promettre une grande version pour dans six mois.
Le découpage n'est pas qu'une question de confort, c'est ce qui protège le projet. Quand une validation demande trois semaines et implique quatre personnes, un projet construit en une seule grande livraison finale accumule les malentendus sans jamais les révéler, jusqu'au jour de la recette où tout sort d'un coup. Livrer une version installable toutes les deux ou trois semaines transforme ce risque en série de petites corrections, chacune peu coûteuse parce qu'elle porte sur du travail encore récent.
Le secteur public apporte aussi une exigence d'accessibilité que le privé ignore souvent. Une application destinée à des citoyens doit pouvoir être utilisée par quelqu'un qui grossit les textes, qui navigue avec un lecteur d'écran, ou qui distingue mal certaines couleurs. Ce n'est ni difficile ni très coûteux quand on y pense dès la conception : contrastes suffisants, libellés lisibles par un lecteur d'écran, zones tactiles assez grandes. Cela devient cher quand il faut reprendre une interface terminée.
Une clause revient dans presque tous les marchés publics et mérite d'être lue avant de signer : la réversibilité. L'administration exige de pouvoir confier la suite à un autre prestataire, et donc de disposer du code, de la documentation et des accès sous une forme exploitable. C'est exactement ce que je livre par défaut, marché public ou pas — dépôt à votre nom, décisions écrites, passation en fin de projet. La différence, ici, c'est que c'est contractuel et que ça se vérifie.
Un dernier point pratique sur les marchés publics : les délais de paiement y sont longs et le formalisme est lourd. Je le prends en compte plutôt que de m'en plaindre, en calant la facturation sur des jalons clairs et en fournissant des livrables qui correspondent à quelque chose de montrable et de vérifiable. Cela évite les discussions désagréables et cela donne à votre service comptable des pièces qui tiennent la route.
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 à Namur, 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.
La plupart des refus de l'App Store viennent de règles connues à l'avance et ignorées jusqu'au dernier moment — un paiement qui contourne le système d'Apple, une fonctionnalité inaccessible au relecteur, une déclaration de confidentialité incomplète. Le processus consiste donc à intégrer ces règles au cahier des charges plutôt qu'à les traiter comme une formalité de fin de projet.
Beaucoup de projets d'applications échouent à la porte de l'App Store.
Apple est sévère.
Le facteur le plus important pour réussir, c'est de comprendre leurs attentes.
Dès le début de notre collaboration à Namur, on intègre les règles d'Apple dans votre cahier des charges.
Pas d'achats externes cachés. Pas de spam de notifications. Pas de tracking sans consentement.
Une fois les bases saines, le développement commence.
Je code en itérations. Cela veut dire que toutes les deux semaines, vous voyez le projet avancer.
Comment ? Via TestFlight.
Vous ouvrez TestFlight sur votre iPhone, vous téléchargez la mise à jour, et vous testez chez vous à Namur.
Une application vendue par abonnement se joue sur le passage du gratuit au payant, et ce passage est encadré par Apple : le paiement doit se faire par son système, et la commission prélevée se situe entre 15 % et 30 % selon votre chiffre d'affaires. Ce calcul se fait avant de fixer vos prix, pas après le lancement.
Prenons un cas fréquent : une application de fitness vendue sur abonnement.
Son modèle économique reposait entièrement sur la conversion des utilisateurs gratuits en payants.
En résumé, l'écosystème Apple était la cible parfaite.
Pourquoi ? Parce que les utilisateurs iOS dépensent en moyenne davantage dans les applications que les utilisateurs Android.
Nous avons construit l'application autour d'une intégration parfaite d'Apple Pay et de StoreKit.
Si l'écran de paiement fait peur, l'utilisateur s'en va.
Il clique. Il quitte. Il oublie.
Le développement n'est pas la seule dépense d'une application, et les autres reviennent tous les ans. Les connaître avant de signer change la façon dont vous dimensionnez le projet — et évite la mauvaise surprise du douzième mois, qui est toujours la plus mal reçue.
Publier coûte de l'argent aux deux endroits. Le programme développeur d'Apple se renouvelle chaque année ; le compte développeur Google Play se paie une fois, à l'inscription. Ces comptes doivent être à votre nom, pas au mien : c'est votre application, et un compte au nom du prestataire est le piège le plus courant du secteur.
Viennent ensuite l'hébergement et les services que l'application consomme. Sur un projet de Namur qui démarre, la facture est modeste — mais elle tombe tous les mois, et elle grandit avec le nombre d'utilisateurs.
Si vous vendez dans l'application, Apple et Google prélèvent entre 15 % et 30 % selon votre chiffre d'affaires et le programme auquel vous êtes éligible. Ça se calcule avant de fixer vos prix, pas aprè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 à Namur, l'application iOS est la porte d'entrée.
Une application n'a pas toujours besoin d'un serveur : tout dépend de si elle doit partager des données entre plusieurs appareils. Elle doit en revanche presque toujours prévoir l'absence de réseau, parce que le réseau manque plus souvent qu'on ne le croit. Le reste — appareil photo, position, notifications, connexion à un logiciel existant — est possible, sous réserve d'autorisations que l'utilisateur peut refuser.
Pas toujours, et c'est une bonne nouvelle pour le budget. Une application qui ne fait vivre que les données de son utilisateur — une liste, un suivi, un calcul — peut tout garder sur le téléphone et ne rien coûter en fonctionnement. Dès qu'il faut partager entre plusieurs personnes, synchroniser entre deux appareils, ou que vous devez voir les données de votre côté, il faut un serveur, et c'est une ligne de coût qui revient chaque mois.
Ça dépend entièrement de ce qu'on a décidé au départ, et c'est un des rares choix qu'on ne peut pas repousser. Une application peut garder ses données sur l'appareil, laisser travailler, puis se synchroniser dès que le réseau revient — sans que l'utilisateur appuie sur quoi que ce soit. C'est indispensable dès qu'on travaille en entrepôt, en sous-sol, en déplacement. Rajouté après coup, ça revient souvent à réécrire la moitié de l'application.
On choisit une limite, et ce choix a un prix. Supporter des versions anciennes du système veut dire tester davantage et se priver de certaines possibilités. On regarde qui sont vos utilisateurs : une application grand public et un outil interne déployé sur un parc connu n'ont pas la même réponse. La limite se relève ensuite, quand les statistiques d'usage montrent que plus personne n'est resté derrière.
Ça compte plus qu'on ne le croit, parce qu'une application volumineuse se fait désinstaller la première quand la mémoire manque. L'essentiel du poids vient rarement du code : ce sont les images et les polices embarquées. Charger les images depuis le serveur plutôt que les livrer dans l'application, et les servir à la bonne taille, suffit souvent à diviser le poids par deux. C'est du travail invisible et c'est celui qui garde l'application installée.
Techniquement, l'envoi ne coûte presque rien. Ce qui coûte, c'est ce qu'il faut autour : un serveur pour décider quoi envoyer à qui et quand, et un réglage fin pour ne pas devenir intrusif. C'est aussi le mécanisme le plus facile à gâcher — une notification inutile est la première cause de désinstallation, et une application désinstallée ne revient pas. On en envoie peu et on les rend utiles, ou on n'en envoie pas.
Oui, avec l'autorisation de l'utilisateur, et la façon de la demander compte autant que la fonction. Une permission réclamée au premier lancement, sans contexte, est refusée dans une grande partie des cas — et une fois refusée, elle est pénible à récupérer. Demandée au moment où la personne comprend pourquoi, elle est accordée. Apple exige d'ailleurs une explication écrite pour chaque permission, et un texte vague fait refuser l'application.
Par les stores, et pas instantanément : Apple et Google vérifient chaque version avant publication, et les téléphones se mettent à jour au rythme de leurs réglages. Il faut donc prévoir qu'une partie de vos utilisateurs restera plusieurs semaines sur une version ancienne. C'est pourquoi le serveur doit continuer à parler aux versions précédentes, et pourquoi on évite les changements qui cassent tout d'un coup.
Souvent, oui, et tout dépend d'une chose : votre éditeur fournit-il une interface d'accès documentée. Si oui, c'est du travail normal. S'il n'en fournit pas, ou s'il la facture au module, ou s'il refuse de l'ouvrir à un tiers, aucune application ne contournera ça proprement — les contournements existent et cassent à la première mise à jour de l'éditeur. C'est une question à poser à votre fournisseur avant de me poser la vôtre.
Un site peut s'installer sur l'écran d'accueil, fonctionner hors réseau et se lancer en plein écran, sans passer par un store. C'est une vraie troisième réponse, et elle est sous-conseillée parce qu'elle rapporte moins à qui la propose. Ses limites : les notifications restent bridées sur iPhone, l'accès aux capteurs est partiel, et vous n'êtes pas présent dans les stores — ce qui compte si vos clients vous y cherchent.
Seulement si vous avez un public dans une autre langue — et alors, il faut le prévoir dès la conception plutôt que l'ajouter. Ce n'est pas la traduction qui coûte, c'est la place : l'allemand allonge les libellés de moitié et fait déborder les boutons dessinés pour le français. Prévoir la place dès le départ ne coûte rien ; refaire les écrans après coup coûte plusieurs jours. Les textes légaux et la fiche du store comptent aussi.
Pendant que vous hésitez, vos concurrents à Namur 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 en Wallonie.
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. ⏳
En 30 minutes, vous saurez exactement par où commencer. Sans engagement. Sans jargon technique.
Réservez un appel gratuit →
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.