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 dédié.
En résumé : je construis des applications iOS et Android pour des clients à Marseille (870 018 habitants) et partout en Provence-Alpes-Côte d'Azur. Un seul interlocuteur, 12 ans d'expérience, livraison du concept à la publication en 8 à 16 semaines.
Vous avez un problème avec votre application actuelle ? Note en chute libre ? Lenteurs inexpliquées ? Il clique. Il quitte. Il oublie.
C'est le pire scénario. Et c'est exactement là que j'interviens. Fort de 12 ans d'expérience, j'aide les entreprises depuis Cannes à sauver leurs projets iOS et Android mal engagés. Je fais le diagnostic, on identifie ce qui bloque, et on répare pour offrir une expérience enfin fluide à vos utilisateurs.
En résumé : ne laissez pas un mauvais départ gâcher votre idée. On corrige le tir ensemble.
Je vois ça tous les jours.
À Marseille, de nombreuses entreprises gèrent encore leurs processus critiques avec de vieux fichiers Excel. Ou avec des logiciels qui datent des années 2000. Ça tient avec du scotch.
Et un jour, ça casse. Le logiciel plante. Les données sont perdues. Et là, c'est la panique.
L'avantage clé du développement application desktop Marseille moderne, c'est de sécuriser votre avenir. Vous avez construit votre business dans la région de Provence-Alpes-Côte d'Azur sur ces outils. Mais il est temps de changer de moteur.
Moderniser un vieux logiciel n'est pas le réécrire. C'est d'abord récupérer les données et comprendre les règles métier qui y sont enfouies, souvent nulle part ailleurs que dans le code. Ensuite seulement vient l'interface. Un projet de modernisation qui commence par le graphisme se termine par la découverte, tardive, qu'une règle essentielle avait été oubliée.
C'est un classique. Une entreprise florissante à Marseille. Mais en coulisses, tout tourne sur un logiciel créé en 1998. Du Visual Basic 6, du Delphi, ou une base de données Access géante.
Qu'est-ce que le développement application desktop Marseille dans ce cas ? C'est de la rénovation extrême.
L'objectif n'est pas de perturber vos employés. Ils ont leurs habitudes. Leurs raccourcis clavier. Le point essentiel : on va changer le moteur sans changer la carrosserie.
On extrait les données. On recrée une interface claire avec un développeur logiciel Marseille expérimenté. Mais on garde la logique métier qui fait tourner votre entreprise depuis des années dans la région Provence-Alpes-Côte d'Azur.
Pourquoi faire ça ? Parce qu'un jour, Windows fera une mise à jour et votre vieux logiciel ne s'ouvrira plus. Et là, votre production s'arrête. La plupart des utilisateurs abandonnent si un temps de chargement dépasse 3 secondes, imaginez s'ils ne peuvent même pas ouvrir l'outil. Anticiper, c'est survivre.
Marseille a une économie de port et de PME familiales, et beaucoup de projets mobiles y naissent d'un besoin logistique très concret plutôt que d'une idée de startup. C'est un bon point de départ : quand l'application doit résoudre un problème que vous vivez tous les jours, le cahier des charges s'écrit tout seul et la première version est utilisable en quelques semaines.
Deux heures de train séparent Cannes de Marseille, et c'est ce qui rend le paragraphe précédent autre chose qu'une figure de style : aller regarder quelqu'un travailler une matinée est un aller-retour dans la journée, pas une expédition à budgéter. Sur un projet de terrain, c'est la dépense la plus rentable du cadrage — une heure passée dans un entrepôt m'apprend ce que trois réunions ne diront pas, parce que personne ne pense à décrire ce qu'il fait sans y penser.
Ces projets-là ont un avantage rare : l'utilisateur, c'est vous, ou quelqu'un dans le bureau d'à côté. On n'a pas besoin d'imaginer ce que ferait un client hypothétique, on peut aller le regarder travailler pendant une heure. C'est la chose la plus utile que je puisse faire au début d'un projet de terrain, et cela révèle presque toujours quelque chose que personne n'avait pensé à me dire — un geste, un document papier qui traîne, une étape qu'on fait de tête et qui n'apparaît dans aucun processus écrit.
Le port impose ses propres contraintes. Les zones portuaires et les entrepôts sont des trous de réseau, et les hangars métalliques bloquent le signal aussi bien qu'une cave. Une application de suivi qui suppose une connexion permanente ne survit pas à sa première journée réelle. On construit donc l'inverse : tout fonctionne hors ligne, les données s'accumulent sur le téléphone, et la synchronisation se fait toute seule dès qu'il y a du réseau, sans que l'utilisateur ait à y penser ni à appuyer sur un bouton.
Marseille a aussi beaucoup d'échanges avec le Maghreb et l'Italie, et cela ressort dans les projets : une clientèle qui ne lit pas toujours le français, des adresses qui ne rentrent pas dans un formulaire français, des numéros de téléphone étrangers qu'un champ trop strict refuse. Ce sont de petits détails, mais chacun perd des utilisateurs à l'inscription, et ils coûtent quelques heures au début contre plusieurs jours à corriger après le lancement.
À Marseille, la plupart des entreprises qui me contactent ont trois options en tête : un étudiant en informatique pour quelques milliers d'euros, une agence pour dix fois plus, ou un indépendant. Les trois se défendent, mais pas sur le même projet. Voici comment je fais la différence, y compris quand elle ne joue pas en ma faveur.
L'étudiant est un bon choix quand l'outil reste à l'intérieur de l'entreprise, qu'il ne passe pas par les stores, qu'il ne touche pas de données personnelles, et que si l'application s'arrête un lundi matin, personne n'est bloqué. Beaucoup de premiers outils entrent dans cette case, et le dire coûte peu.
Ça devient un mauvais choix dès qu'un de ces quatre points saute. Une publication sur l'App Store engage des comptes, des certificats et des renouvellements annuels. Des données clients engagent votre responsabilité, pas celle de l'auteur du code. Et une application dont dépend le travail quotidien de vos équipes a besoin de quelqu'un qui réponde au mois d'août.
L'agence, elle, se justifie quand il faut plusieurs personnes en parallèle pour tenir une date. Si ce n'est pas votre cas, l'essentiel de la facture paie des couches intermédiaires.
Sur un projet de terrain, le premier mois commence par une matinée sur place. Regarder quelqu'un travailler une heure apprend ce que trois réunions ne diront pas, parce que personne ne pense à décrire ce qu'il fait sans y penser.
Si cette personne continue à s'en servir sans qu'on le lui demande, le projet est bon. Sinon, on a perdu un mois au lieu de six.
Concevoir pour un ordinateur n'est pas agrandir une application mobile. L'utilisateur a un clavier, une souris précise et souvent deux écrans ; il veut des raccourcis, de la densité d'information et la possibilité de faire plusieurs choses à la fois. Une interface pensée pour le pouce devient lente et frustrante sur un poste de travail, même si elle est jolie.
Créer un logiciel sur mesure Marseille, ce n'est pas faire une grosse application mobile. La logique est totalement différente.
Sur mobile, on navigue avec le pouce. Sur bureau, on a dix doigts sur un clavier et une souris ultra-précise. L'utilisateur veut aller vite.
Mon processus de conception est focalisé sur la productivité de vos équipes à Marseille :
- Raccourcis clavier : Chaque action fréquente doit pouvoir se faire sans toucher la souris. - Densité d'information : Sur un écran de 27 pouces, on peut afficher beaucoup de données. Mais il faut que ça reste lisible. - Multifenêtrage : Permettre à vos collaborateurs de travailler sur plusieurs dossiers clients en même temps.
Un poste de pilotage en production ne peut pas dépendre d'internet. Si le réseau tombe et que l'outil s'arrête, c'est la ligne qui s'arrête. Un logiciel installé continue de fonctionner, conserve ses mesures et se resynchronise plus tard. C'est la raison pour laquelle certains métiers ne passeront jamais au tout en ligne.
Le cas type en industrie : un tableau de bord pour les opérateurs sur ligne de production. L'usine tourne 24 heures sur 24. La connexion internet de la zone industrielle de Marseille est instable.
Une application web était impossible. Si le réseau coupe, l'usine s'arrête. Il fallait du développement application desktop Marseille. Une solution "offline-first".
Je ne donne pas de fourchette avant le cadrage, parce qu'un prix annoncé avant de savoir ce qu'on construit est un chiffre inventé. En revanche, la mécanique, elle, se dit dès le premier appel : trente pour cent à la commande, le reste réparti par mois sur la durée du projet. Vous payez au rythme où le travail avance.
Deux dépenses tombent en plus du développement, et elles reviennent : le programme développeur d'Apple à 99 € par an, et le compte Google Play Console à 25 $ une fois. Les deux se prennent à votre nom, pas au mien.
Sur un projet court, d'un mois ou deux, le découpage est plus simple : la moitié au démarrage, la moitié à la livraison. Sur un projet qui court sur plusieurs mois, la mensualisation protège les deux côtés — vous ne financez jamais du travail qui n'a pas été fait, et je ne travaille jamais trois mois avant de facturer.
Dans le commerce, une application ne remplace pas la caisse : elle s'y branche. Ce qui décide de la faisabilité, c'est donc l'existence d'une interface ouverte sur votre logiciel de caisse ou de stock. Les usages qui marchent se comptent en gestes économisés, pas en fonctionnalités : consulter un stock depuis le rayon, encaisser une commande, scanner une étiquette.
Dans le commerce, une application ne remplace jamais la caisse : elle vient s'y brancher. C'est ce qui décide de la faisabilité, et la question se pose au premier rendez-vous — votre logiciel de caisse ou votre gestion de stock ouvre-t-il une interface, et à quelles conditions votre éditeur l'ouvre-t-il à un tiers ?
Avant la première ligne de code, quatre choses se décident : faut-il vraiment une application ou un site suffit-il, à quel nom sont ouverts les comptes développeur, quelles données personnelles l'application va traiter, et ce qui entre dans la première version. Le logo et la charte graphique peuvent attendre. Ces quatre points-là, non : ils changent l'architecture et le budget.
Une condition et trois critères. La condition, c'est la fréquence : une application vit sur un écran d'accueil, et une icône ouverte une fois par an ne se rembourse jamais. Si vos clients reviennent chaque semaine, il suffit ensuite d'un critère sur trois — l'application se sert du téléphone lui-même, elle doit fonctionner sans réseau, ou elle a une raison légitime de vous rappeler. Sinon, un site fait le même travail pour moins cher, et je vous le dirai.
Une idée d'application ne se brevette pas en tant que telle ; ce qui se protège, c'est le nom — une marque déposée — et le code, protégé par le droit d'auteur dès son écriture. En pratique, le risque n'est presque jamais le vol : c'est de mettre six mois à sortir pendant qu'un autre sort en deux. Si le sujet vous inquiète, un accord de confidentialité se signe avant le premier appel, sans difficulté.
Non, et c'est même plus sain de commencer sans. Le cadrage porte sur ce que fait l'application et pour qui ; l'habillage vient après, et il vient mieux quand on sait déjà quels écrans existent. Si vous avez déjà une identité, on s'en sert. Sinon, la première version peut être sobre et lisible — ce qui n'est pas un pis-aller : beaucoup d'applications gagneraient à le rester.
Oui, et c'est souvent la meilleure dépense du projet. Des maquettes cliquables qu'on met entre les mains de dix personnes révèlent en une semaine ce qu'un développement de trois mois révélerait trop tard. On voit où les gens hésitent, ce qu'ils ne trouvent pas, ce dont ils se fichent. C'est aussi ce qui permet de retirer des fonctions avant de les payer plutôt qu'après.
Oui, toujours, et c'est un point sur lequel je ne transige pas. Les deux comptes sont payants — 99 € par an chez Apple, renouvelables, et 25 $ une seule fois chez Google Play — et se créent au nom de votre entreprise ; je travaille dessus avec un accès délégué. Une application publiée sous le compte d'un prestataire est une application que vous ne contrôlez pas : vous ne pouvez ni la mettre à jour ni la transférer sans lui. La création prend un peu de temps côté Apple, autant s'y prendre tôt.
Le plus tard possible. Un écran d'inscription en ouverture est la première cause d'abandon : la personne n'a encore rien vu et vous lui demandez déjà quelque chose. La bonne règle est de laisser essayer, puis de demander un compte au moment où il devient utile — pour retrouver ses données sur un autre appareil, pour payer, pour être reconnu. La plupart des applications gagnent des utilisateurs juste en déplaçant cet écran.
La règle simple : ne collectez que ce dont vous vous servez vraiment, dites-le clairement, et laissez la personne revenir en arrière. Concrètement, ça veut dire une politique de confidentialité lisible, un consentement demandé au bon moment plutôt qu'en bloc au démarrage, et un moyen de supprimer son compte depuis l'application — Apple l'exige. Les fiches de confidentialité des deux stores doivent aussi correspondre à la réalité de ce que fait l'application.
Oui, et il y a une règle à connaître avant de bâtir un modèle économique dessus : tout ce qui est consommé dans l'application passe par le système de paiement d'Apple ou de Google, qui prélève entre 15 % et 30 % selon votre chiffre d'affaires annuel. Vendre un service consommé ailleurs — une prestation physique, une commande livrée — se paie normalement. La différence n'est pas anecdotique, elle change le prix que vous devez afficher.
Rien. Pas de cahier des charges, pas de présentation, pas de budget arrêté. Trente minutes suffisent si vous pouvez répondre à deux questions : qui va s'en servir, et qu'est-ce que ça leur fait gagner. Si vous avez déjà des captures d'écran d'applications qui vous plaisent, prenez-les — montrer ce qu'on aime est plus rapide que le décrire. Le reste, c'est mon travail de le poser.
Trois signaux, et je les dis pendant l'appel plutôt qu'au troisième mois. Si personne dans l'équipe ne pourra répondre à mes questions pendant le projet, ça n'avancera pas. Si le budget couvre le développement mais rien de l'année suivante, l'application mourra doucement. Et si l'objectif est de rassurer un investisseur plutôt que de servir un utilisateur, une maquette coûte cent fois moins cher et fait le même effet.
Vous avez un besoin concret plutôt qu'une idée d'application : quelque chose que vous faites tous les jours à la main et qui vous coûte des heures.
C'est le meilleur point de départ possible, et trente minutes suffisent souvent à savoir si ça vaut le coup. On regarde le geste réel — le papier qui traîne, l'appel passé deux fois, la double saisie du soir — et on estime ce qu'une première version devrait couvrir. Souvent moins que vous ne pensez.
Marseille est à deux heures de Cannes : si le projet avance, je viens regarder sur place plutôt que de deviner.
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.