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 sur l'App Store et Google Play.
En résumé : pour votre projet à Toulouse (486 828 habitants), en Occitanie, 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 à Toulouse 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 à Toulouse.
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.
Le point essentiel : le prix dépend de la complexité technique sous le capot, pas du nombre de pages.
Je vous dirai la vérité, même quand elle est inconfortable. C'est la promesse que je fais à tous mes clients depuis Cannes.
Créer une application iOS ou Android demande du temps et de l'argent. Alors, pas de langue de bois entre nous. Avec 12 ans d'expérience au compteur, si votre cahier des charges part dans tous les sens, je vous freine.
Le facteur le plus important : je suis là pour que votre investissement serve réellement vos utilisateurs. C'est comme ça qu'on fait de grandes applications.
Dans l'aéronautique et le spatial toulousains, vos propres clients vous imposent des règles, et ces règles retombent sur vos prestataires. Avant même de parler de l'application, il faut donc savoir si celui qui va l'écrire peut signer ce que vous devez lui faire signer. C'est la question qui élimine, et elle se pose au premier appel.
En pratique, ça tient en quelques documents : un accord de confidentialité, une attestation d'assurance responsabilité civile professionnelle, parfois un questionnaire de sécurité de plusieurs dizaines de lignes, et de plus en plus souvent une clause sur le lieu d'hébergement du code et des données. Je traite ça comme du travail normal, pas comme une formalité qu'on repousse à la signature.
Il y a une limite, et je préfère la donner avant que vous ne perdiez du temps. Je suis une entreprise individuelle, pas une structure certifiée. Si votre donneur d'ordre exige un fournisseur portant une certification qualité formelle, je ne rentre pas dans le cadre, quelle que soit la qualité du travail.
Quand le cadre passe, en revanche, une petite structure a un avantage concret : il n'y a personne à qui déléguer, donc personne chez qui l'information puisse se perdre en route.
À Toulouse, une bonne partie des demandes vient de l'aéronautique et de ses sous-traitants, avec les contraintes qui vont avec : traçabilité, usage hors ligne, et des utilisateurs qui portent des gants. Ce sont des projets où l'ergonomie compte plus que l'esthétique, et où une bonne application se reconnaît au nombre de gestes qu'elle vous épargne.
Les gants changent tout, et c'est le genre de détail qu'on découvre trop tard quand personne n'est allé voir. Un doigt ganté est imprécis : les boutons doivent être nettement plus grands que ce que recommandent les guides d'Apple et de Google, les listes doivent avoir de l'espace entre les lignes, et un menu déroulant devient inutilisable. Certains gants ne fonctionnent tout simplement pas sur un écran capacitif, ce qui veut dire que l'application doit rester pilotable avec un stylet ou une seule main nue. Ces décisions se prennent au moment de la maquette, pas après.
La traçabilité est l'autre contrainte structurante. Dans un contexte aéronautique, une saisie n'est pas seulement une donnée : c'est un enregistrement qui devra peut-être être produit dans un audit des années plus tard, avec qui l'a saisie, quand, et sur quel appareil. Cela interdit certaines facilités de développement — on ne supprime pas une ligne, on l'invalide en gardant l'historique — et cela impose de réfléchir à la synchronisation autrement : si deux personnes modifient la même fiche hors ligne, il faut une règle explicite pour trancher, pas le dernier qui gagne par hasard.
L'autre détail de terrain, aussi banal et aussi coûteux que les gants : le téléphone n'appartient souvent à personne. Dans un atelier, un même appareil passe de main en main d'une équipe à l'autre, et une application qui suppose « un utilisateur = un téléphone » se retrouve à attribuer les saisies de l'équipe du soir à celui du matin. Il faut donc une identification rapide en début de poste — assez rapide pour que personne ne la contourne — et une déconnexion qui ne perde pas le travail en cours. C'est une décision d'architecture, pas un écran à ajouter après coup.
Toulouse a aussi un écosystème spatial et un pôle santé importants, et un vrai vivier de développeurs sortant de l'INSA ou de l'ENSEEIHT. Cela veut dire que si vous me sollicitez, c'est souvent que vous avez déjà pesé l'option du recrutement. C'est une conversation que j'ai volontiers : sur un projet à horizon long avec un produit qui devient le cœur de votre activité, recruter est souvent le bon choix, et je préfère vous le dire que prendre une mission qui aurait dû être un poste.
Sur un projet industriel, le premier mois sert à régler ce qui bloque : le cadre contractuel d'abord, les conditions réelles d'usage ensuite. Un projet qui commence à coder avant d'avoir vu l'atelier se refait entièrement au troisième mois.
C'est souvent là qu'on découvre que le lecteur de code-barres se comporte comme un clavier et change tout le formulaire de saisie.
Un projet iOS commence par le cadrage, pas par le design : on décide ce que l'application fait avant de décider à quoi elle ressemble. Viennent ensuite les maquettes, validées avant tout développement, puis les versions installables, puis la soumission à Apple. L'ordre compte, parce que revenir sur une décision de cadrage après le développement coûte dix fois plus cher qu'avant.
Créer une application, c'est comme construire une maison à Toulouse.
On ne commence pas par peindre les murs avant d'avoir fait les fondations.
L'avantage clé de ma méthode, c'est la transparence.
Étape 1 : Le cadrage.
On définit exactement ce que l'application va faire. On liste les fonctionnalités. Et surtout, on anticipe les exigences d'Apple.
Étape 2 : Le compte développeur.
C'est le moment de demander votre numéro DUNS si vous ne l'avez pas. Ça prend du temps, on le fait tout de suite.
Étape 3 : Le développement en Swift.
Je code l'application brique par brique.
Vous n'attendez pas six mois dans le noir. Je vous donne accès à TestFlight très vite.
Un processus transparent, itératif, et sans surprise. Vous voyez l'application grandir chaque semaine.
É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.
En résumé : on ne construit pas tout. On construit ce dont vos utilisateurs ont vraiment besoin.
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 à Toulouse.
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 à Toulouse, 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.
Un projet industriel se joue sur des détails de terrain que personne ne pense à écrire : les gants, le téléphone partagé entre deux équipes, le hangar sans réseau.
Trente minutes suffisent à en sortir assez pour savoir si le projet tient debout. On regarde qui va s'en servir, dans quelles conditions, et ce que votre donneur d'ordre exigera en matière de traçabilité — parce que ça, c'est de l'architecture, pas un écran qu'on ajoute après coup.
Et si l'échange conclut qu'il vaut mieux recruter que sous-traiter, je vous le dirai franchement.
En 30 minutes, vous saurez exactement par où commencer. Sans engagement. Sans jargon technique.
Réservez un appel gratuit →
30 minutes pour démarrer votre projet
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.