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 à Strasbourg (284 677 habitants), dans le Grand Est, 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.
Tout le monde ne jure que par les smartphones aujourd'hui.
C'est vrai, la majorité des utilisateurs naviguent sur leur téléphone. Mais le mobile ne résout pas tout. Surtout pas quand on travaille sérieusement.
À Strasbourg, vos comptables, vos designers et vos chefs d'entrepôt ne font pas leur métier sur un écran de six pouces. Ils ont besoin d'un grand écran. D'un vrai clavier. D'une puissance de calcul qui ne fond pas au soleil.
Le point essentiel : le bureau représente encore une part importante du trafic web. Et dans le monde de l'entreprise, ce chiffre explose.
Le web et le bureau ne répondent pas au même besoin. Un site est ouvert à tous, accessible partout, et suffit tant qu'il s'agit de consulter et de saisir. Un logiciel installé sert quand le travail est long, les fichiers lourds, le réseau incertain, ou quand il faut parler à du matériel. Le critère n'est pas la modernité : c'est l'usage réel.
On me pose souvent la question. Pourquoi faire un développement application desktop Strasbourg alors qu'on peut faire un site web ? Ce n'est pas le même usage. Un site web, c'est un restaurant ouvert à tous. C'est génial pour accueillir du public à Strasbourg. Mais le serveur du restaurant (votre API) doit faire des allers-retours constants avec la cuisine (votre base de données). Une application bureau Strasbourg, c'est avoir la cuisine directement dans votre salon. C'est fait pour le traitement de données lourdes. Les applications de bureau d'entreprise traitent 10 à 100 fois plus de données que les applications mobiles. Vous avez besoin d'imprimer des étiquettes en série ? De brancher un lecteur de code-barres USB ? De manipuler des modèles 3D complexes ? Le web va ramer. Le desktop va voler. Le facteur le plus important est l'accès au matériel de l'ordinateur. Le navigateur web bloque cet accès par sécurité. Le logiciel de bureau, lui, a les clés de la maison.
Le point essentiel : le prix dépend de la complexité technique sous le capot, pas du nombre de pages.
Je ne suis pas juste un développeur. Je suis aussi celui qui va vous dire quand une fonctionnalité est une mauvaise idée.
En 12 ans d'expérience, j'ai vu trop de projets échouer à cause d'applications trop compliquées. Mon approche depuis Cannes ? On simplifie. Je travaille avec des startups et des PME pour construire des applications iOS et Android qui vont droit au but.
Je suis votre partenaire produit. Si une idée ne sert pas vos utilisateurs, je vous le dirai. En résumé :
Une application strasbourgeoise s'adresse souvent à des utilisateurs français et allemands, et ce ne sont pas les mêmes utilisateurs avec un dictionnaire entre eux. Le prestataire à chercher est celui qui refuse d'en faire la moyenne : il pose les questions d'usage avant de traduire quoi que ce soit.
Ces questions en valent la peine parce qu'elles changent des écrans, pas des mots. Sur quel ton on s'adresse à l'utilisateur — le vouvoiement allemand n'est pas un détail de politesse, il fixe le registre de toute l'interface. Quels moyens de paiement vos utilisateurs allemands s'attendent à trouver, qui ne sont pas forcément ceux de vos utilisateurs français. Comment une adresse, une date et un numéro de téléphone s'écrivent de chaque côté.
Rien de tout cela ne se règle en fin de projet par une passe de traduction. Ce sont des décisions de conception, et les prendre au départ coûte quelques jours contre plusieurs semaines de reprise.
Le test qui tranche est simple : faites essayer la maquette à un germanophone réel avant la première ligne de code. Dix minutes, et vous saurez si le projet est bilingue ou seulement traduit.
Strasbourg travaille des deux côtés de la frontière, et cela se voit dans les projets : bilinguisme français-allemand dès la première version, parfois une contrainte réglementaire européenne, et des utilisateurs qui changent de langue en cours de route. Prévoir cela au départ coûte quelques jours ; l'ajouter après coûte une refonte.
L'allemand est la langue qui casse le plus d'interfaces, et ce n'est pas une plaisanterie de développeur. Les mots composés allemands sont longs : un bouton qui affiche « Paramètres » sur trois centimètres affiche parfois quelque chose de deux fois plus large en allemand, et le texte déborde, se coupe, ou pousse le reste de l'écran hors du cadre. La seule parade fiable est de concevoir chaque écran pour la version la plus longue du texte dès la maquette, et de tester dans les deux langues à chaque étape plutôt qu'une fois à la fin.
Le changement de langue en cours d'usage est l'autre détail que peu de gens anticipent. Un utilisateur strasbourgeois peut très bien installer l'application en français puis basculer en allemand pour montrer un écran à un collègue. Si le changement oblige à redémarrer l'application, à se reconnecter, ou s'il perd le formulaire à moitié rempli, l'expérience est mauvaise. Cela se prévoit dans la façon dont l'application charge ses textes, et c'est presque gratuit si on y pense avant.
Le bilinguisme a un coût qu'on oublie systématiquement au chiffrage : les textes qui ne sont pas de l'interface. Conditions d'utilisation, politique de confidentialité, formulaires de consentement, e-mails automatiques, messages d'erreur du serveur, fiche du store. Une application franco-allemande a besoin de tout cela dans les deux langues, et ce sont précisément les textes qu'on écrit en dernier, dans l'urgence, souvent la veille de la soumission. Les prévoir dès le début coûte quelques heures ; les traduire en catastrophe coûte un report de publication, parce qu'une politique de confidentialité approximative se refuse à la validation.
Strasbourg abrite aussi des institutions européennes et un tissu de sous-traitants qui travaillent pour elles, ce qui apporte une exigence documentaire supérieure à la moyenne. Sur ces projets, ce qui prend du temps n'est pas le développement mais la validation : plusieurs interlocuteurs, des délais de réponse longs, et des demandes de traçabilité sur les décisions. Je le prends en compte dans le planning en livrant par petits morceaux validables, plutôt qu'en promettant une grande version dans six mois qui restera bloquée en revue.
Sur un projet bilingue, le premier mois sert à décider ce que veut dire « bilingue » ici. La réponse n'est pas la même selon que vos deux publics font la même chose dans l'application ou deux choses différentes.
Un projet se juge à ce qu'il produit, pas à ce qu'il promet. Toutes les deux semaines, vous recevez une version installable sur votre téléphone et une note écrite de ce qui a changé. C'est la seule protection réelle contre le silence de six mois.
La version est parfois très incomplète, et c'est voulu. Une application partielle qu'on peut ouvrir dit la vérité sur l'avancement ; un pourcentage dans un tableau de suivi ne dit rien du tout, et personne ne sait le contredire.
La note fait quelques lignes : ce qui est fait, ce qui a bougé par rapport à ce qui était prévu, et ce sur quoi j'attends une réponse de votre part. Ce dernier point est celui qui fait gagner le plus de temps, parce qu'une question posée par écrit se traite entre deux réunions.
Vous n'avez rien à installer de compliqué : un lien, et l'application arrive sur votre appareil. Vous pouvez la faire essayer à qui vous voulez dans votre entreprise dans le Grand Est, sans me demander.
Et si une version manque, vous le voyez tout de suite. C'est le but.
Un processus transparent, itératif, et sans surprise. Vous voyez l'application grandir chaque semaine.
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 Strasbourg.
En résumé : on ne construit pas tout. On construit ce dont vos utilisateurs ont vraiment besoin.
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.
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 à Strasbourg 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 construction et la reprise : quelle technologie, que faire d'un vieux logiciel, où vivent les données, faut-il passer par un store, que se passe-t-il quand le système fait une mise à jour majeure. La reprise d'un logiciel ancien est le cas le plus fréquent, et elle commence toujours par récupérer les données, pas par réécrire le code.
Un projet transfrontalier porte une contrainte de plus que les autres, et elle se règle mieux au début qu'à la fin.
En trente minutes, on peut décider si votre application est bilingue dès la première version ou si elle sort d'abord dans une seule langue — les deux réponses se défendent, mais il faut choisir consciemment. On regarde aussi ce que ça implique pour les textes qu'on oublie toujours : conditions d'utilisation, e-mails automatiques, fiche du store.
Sans engagement, et en français ou en anglais selon ce qui vous arrange.
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.