Quand un développeur vous dit que son framework est « performant », il parle de benchmarks. De millisecondes de rendu. De frames par seconde. Ce sont des métriques importantes — mais elles ne sont presque jamais la raison pour laquelle vos utilisateurs désinstallent votre app.
Le vrai débat sur la performance, celui qui devrait avoir lieu entre un fondateur et son développeur, n'est pas technique. Il est stratégique. Je vais vous expliquer pourquoi.
Ce que « performance » veut vraiment dire pour vos utilisateurs
Demandez à quelqu'un pourquoi il a désinstallé une app. Vous entendrez rarement « le FPS était insuffisant ». Vous entendrez surtout :
- « Elle mettait trop de temps à charger »
- « Je ne trouvais pas ce que je cherchais »
- « Elle plantait sans raison »
- « La batterie se vidait trop vite »
La performance perçue n'est pas la même chose que la performance mesurée. Un écran qui affiche un squelette de chargement en 50ms paraît plus rapide qu'un écran qui affiche son contenu réel en 400ms. Ce n'est pas rationnel — mais c'est humain.
Flutter, React Native, natif : la vraie question
Ce débat revient systématiquement. Voici la position honnête, sans marketing.
Le développement natif (Swift / Kotlin)
C'est la performance maximale. Vous utilisez les APIs directes du système. Pour des jeux, des apps AR/VR, ou des apps qui exploitent des capteurs spécifiques, c'est le bon choix. Le coût : deux bases de code séparées (iOS et Android), ce qui double le budget et le délai.
React Native
Populaire, large communauté, adopté par Facebook et Airbnb. Mais il souffre d'un problème structurel : le « bridge » entre JavaScript et le code natif. Pour des animations complexes ou des interactions très fluides, ce pont crée des latences visibles. Meta travaille à corriger ça avec la New Architecture, mais c'est encore en transition.
Flutter
C'est mon choix chez ZUHD Studio, et pas par défaut. Flutter ne passe pas par un bridge. Son moteur de rendu (Skia, puis Impeller) dessine directement les pixels à l'écran, ce qui lui permet d'atteindre 60 à 120 FPS de manière constante. Pour des apps métier avec des interfaces riches et des animations, il n'y a pas de compromis visible pour l'utilisateur.
Les vraies questions à poser à votre développeur
Voici ce que vous devriez demander, plutôt que de vous perdre dans des benchmarks :
« Comment vous gérez les états de chargement ? »
Bonne réponse : skeleton screens, optimistic UI, pas d'écrans blancs. Mauvaise réponse : un spinner qui tourne.
« Comment vous gérez les erreurs réseau ? »
Bonne réponse : retry automatique, messages clairs, cache local. Mauvaise réponse : « on affiche une erreur ».
« Comment vous testez la performance sur les appareils anciens ? »
L'iPhone 16 Pro ne représente pas vos utilisateurs. Ce qui compte, c'est que ça tourne correctement sur un appareil de 3 à 4 ans.
La vraie optimisation, c'est le design
La plupart des problèmes de performance perçue ne se résolvent pas dans le code — ils se résolvent dans le design. Une navigation plus claire, moins d'infos par écran, des actions plus évidentes : tout ça rend une app « plus rapide » dans la tête de l'utilisateur, indépendamment des FPS réels.
C'est pour ça que chez ZUHD Studio, design et développement ne sont pas deux phases séparées. Chaque décision de design est prise avec les contraintes de performance en tête, et chaque décision technique est prise avec l'expérience utilisateur en tête.
Si vous voulez voir comment ça se traduit en pratique, mon article sur ce qu'il faut clarifier avant de coder explique le lien direct entre cadrage et performance perçue.
Vous voulez une app réellement performante ?
Pas juste en benchmarks, mais dans les mains de vos utilisateurs. 30 minutes pour voir comment on peut cadrer votre projet.
Réserver mon appel