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 à Lyon (515 695 habitants), en Auvergne-Rhône-Alpes, 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.
Parfois, le cloud n'est pas la solution.
Vous avez besoin de traiter des fichiers gigantesques. De vous connecter à des machines industrielles. Ou de travailler même quand internet coupe.
C'est la force du développement application desktop Lyon. La puissance brute.
Contrairement au web, un logiciel sur mesure Lyon accède directement au processeur de votre ordinateur. Aux imprimantes locales. Aux scanners. À l'équipement de votre usine dans le secteur de Lyon.
En résumé : une application native ne dépend pas de votre connexion wifi. Elle est toujours là. Toujours rapide.
Si vous avez besoin de performance absolue, de sécurité locale et d'intégration matérielle, le choix est vite fait. Faisons tourner vos opérations avec un outil pensé pour vos machines.
Un logiciel de bureau s'installe sur l'ordinateur plutôt que de s'ouvrir dans un navigateur. Ce choix donne accès au disque, à la mémoire et au matériel de la machine, et permet de continuer à travailler sans internet. En échange, il faut organiser l'installation, la signature du logiciel et l'arrivée des mises à jour — trois sujets que le web ne pose pas.
C'est la création de logiciels qui s'installent directement sur votre ordinateur. Mac ou Windows.
Il y a plusieurs façons de construire une application bureau Lyon. Et c'est un peu comme choisir un véhicule.
D'abord, il y a le natif. Pour les ordinateurs Apple, on utilise Swift. Vous pouvez lire les recommandations sur les Human Interface Guidelines d'Apple. C'est comme acheter une voiture de sport pensée uniquement pour les routes de Lyon. C'est ultra rapide, parfaitement intégré, mais ça ne roule que sur Mac.
Pour Microsoft, c'est C\# et.NET. La machine de guerre classique pour les entreprises.
Ensuite, il y a le multiplateforme. Des outils comme Electron ou Flutter Desktop. C'est l'équivalent d'un SUV passe-partout. On écrit le code une seule fois, et le logiciel tourne sur Mac, Windows et Linux.
Il y a 12 ans, je lançais ma toute première application mobile. Depuis, les téléphones ont changé, mais mon métier est resté le même : transformer des idées en outils concrets.
Depuis mon bureau à Cannes, j'accompagne des entrepreneurs et des PME pour concevoir des applications iOS et Android qui ont un vrai sens. Je ne code pas juste pour coder. Je cherche à comprendre votre métier, vos utilisateurs et vos vrais besoins.
Mon objectif est simple. Créer une application que les gens auront envie d'utiliser tous les jours. Le point essentiel : on construit pour eux, pas pour nous. On en parle ?
À Lyon, beaucoup d'entreprises qui me contactent ont déjà une DSI ou un développeur interne. La bonne question n'est donc pas « qui fait tout », mais « qui fait quoi ». Je prends la partie mobile, votre équipe garde ce qu'elle connaît, et on écrit la frontière entre les deux avant de commencer.
Cette frontière tient en trois lignes. Vos serveurs et vos règles métier restent chez vous. L'application et la couche qui lui parle sont de mon côté. Et on se met d'accord dès la première semaine sur ce que chacun attend de l'autre — par écrit, pas oralement, parce que c'est exactement là que les projets à deux équipes se perdent.
Le deuxième critère compte autant et il est rarement posé : est-ce que votre équipe pourra reprendre le projet quand je ne serai plus là ? C'est le but, pas un accident. Le code est volontairement ennuyeux, parce que les astuces brillantes coûtent cher à relire. Le dépôt est à votre nom dès le premier jour, et il contient de quoi reconstruire l'application sans moi.
Un outil métier vit dix ans. Le prestataire qui l'a écrit, rarement. Un projet qui ne survit pas au départ de son auteur n'est pas terminé, il est en sursis.
Lyon est la ville française où je rencontre le plus d'entreprises qui ont déjà un logiciel métier et veulent le prolonger sur mobile. Ce n'est pas le même travail qu'une application partant de zéro : l'essentiel se joue sur l'API existante et sur ce qu'on accepte de ne pas porter. On commence toujours par cette liste-là, avant de dessiner le moindre écran.
La raison pour laquelle cette liste passe en premier est simple : une application mobile qui essaie de reproduire tout un logiciel de gestion échoue toujours. L'écran fait six pouces, l'utilisateur est debout, il a une main libre et trente secondes. Ce qui marche sur mobile, c'est trois ou quatre actions faites cinquante fois par jour — pointer une intervention, valider une livraison, consulter une fiche client, photographier un document. Le reste reste sur le poste de travail, et c'est très bien.
Le vrai risque technique n'est presque jamais l'application. C'est l'API. Beaucoup de logiciels métier ont une interface qui a été écrite pour un site web interne, sur un réseau d'entreprise rapide, avec des réponses énormes parce que la bande passante ne coûtait rien. Branchée sur un téléphone en 4G dans un parking souterrain, la même interface met huit secondes à répondre et l'application paraît cassée alors qu'elle fonctionne parfaitement. La première semaine d'un projet lyonnais part souvent là-dedans : mesurer ce que l'existant renvoie vraiment, et décider ce qu'on adapte côté serveur plutôt que de bricoler côté mobile.
Une question à poser avant tout le reste, et qui décide souvent du projet : à qui appartient l'accès à ce logiciel métier ? Si l'éditeur fournit une API documentée, tout va bien. S'il n'en fournit pas, ou s'il la facture au module, ou s'il refuse de l'ouvrir à un tiers, aucune application mobile ne contournera ça proprement — et les contournements existent, mais ils cassent à la première mise à jour de l'éditeur. Je pose la question au premier appel plutôt qu'au deuxième mois, parce que la réponse change le budget, le calendrier, et parfois la décision de faire ou non.
Lyon a aussi une forte présence de la santé et de la chimie, deux secteurs où l'hébergement des données n'est pas un choix libre. Si vos données relèvent de la santé, elles doivent être chez un hébergeur certifié, et cela se décide avant la première ligne de code, pas au moment de la mise en production. Je pose la question au premier rendez-vous, parce que la réponse change l'architecture entière.
Quand l'application se branche sur un logiciel existant, le premier mois se joue sur le serveur, pas sur l'écran. On mesure d'abord ce que l'existant renvoie vraiment, parce que c'est ça qui décide de ce qui est faisable — et du budget.
Et votre équipe a accès au dépôt depuis le premier jour, pas à la livraison.
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 Lyon, 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 à Lyon :
- 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 tableur partagé qui gère une activité finit toujours par casser sur les trois mêmes points : plusieurs personnes ne peuvent pas y écrire en même temps, les versions circulent par courriel sans qu'on sache laquelle fait foi, et les formules ne sont plus comprises par personne. Un logiciel règle les deux premiers presque gratuitement ; le troisième est le vrai travail.
C'est l'histoire classique d'une belle PME. Leur gestion commerciale tournait entièrement sur un fichier Excel partagé. Au début, c'était pratique.
Et puis ils sont passés à trente employés. Le fichier était devenu énorme. Il mettait plusieurs minutes à s'ouvrir. Dès que deux personnes modifiaient une cellule en même temps, le fichier corrompait tout. Ils m'ont contacté pour un développement application desktop Lyon.
La meilleure question est celle du coût de votre outil actuel. Un salarié qui passe deux heures par jour à recopier des données entre trois logiciels lents représente un coût, tout comme le fichier de suivi qui plante et perd une matinée de travail. Face à cela, un logiciel sur mesure est souvent comparé au mauvais chiffre : le devis, plutôt que l'existant.
Le coût qui revient chaque année n'est pas le développement : ce sont les versions majeures des systèmes. Windows et macOS en publient chacun une par an, et chacune peut demander une adaptation.
Certains métiers ne tiennent pas sur un téléphone. Traitement de gros fichiers, connexion à des machines, saisie longue sur deux écrans : ce sont des usages de poste de travail, et les forcer sur mobile produit un outil que personne n'utilise. Le logiciel de bureau reste le bon choix quand le travail se fait assis, longtemps, sur un grand écran.
Il y a des métiers à Lyon où le téléphone ne suffit pas. La souris et le clavier restent les rois de la productivité.
Je crée des logiciels de bureau pour les industries lourdes.
Ces questions portent sur la vie du logiciel dans l'entreprise : le déploiement sur toutes les machines, la connexion aux outils en ligne existants, la sécurité, le travail hors ligne, et les frais récurrents. Le point qui décide le plus souvent du calendrier n'est pas technique : c'est la politique de sécurité de votre service informatique.
Un projet mobile lyonnais commence presque toujours par la même question, et elle n'est pas technique : qu'est-ce qu'on ne met pas dans l'application ?
En trente minutes, on peut y répondre assez précisément. On regarde ce que vos utilisateurs font debout, une main prise, en trente secondes — c'est ça qui va sur le téléphone, et le reste peut rester sur le poste de travail. On repère aussi tout de suite si votre logiciel existant peut être branché ou non, parce que c'est ce qui décide du budget.
Sans engagement. Si la conclusion est que vous n'avez pas besoin d'une application, je vous le dirai aussi.
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.