Des applications Flutter à partir d'un seul code.

Flutter n'enveloppe pas les composants d'interface de la plateforme. Il dessine lui-même chaque pixel, avec son propre moteur de rendu, et Dart compile en amont vers du code machine natif. Cette seule décision d'architecture explique la plupart des forces de Flutter et l'ensemble de ses faiblesses : elle mérite d'être comprise avant de le choisir.

• Cohérence du design : un écran est identique sur les deux plateformes et sur un vieil appareil Android, parce que c'est le framework qui l'a dessiné et non le système d'exploitation.
• Interfaces sur mesure : l'animation, le mouvement et un design très marqué sont du travail ordinaire en Flutter, et non un combat contre les contrôles de la plateforme.
• Une équipe, un langage, un jeu de tests pour iOS et Android, avec un hot reload qui garde la boucle de conception assez courte pour itérer avec un designer dans la pièce.
• Des performances prévisibles pour le type d'application que la plupart des entreprises font construire : listes, formulaires, médias, graphiques, appels API.
• Il va au-delà du téléphone — les cibles web, desktop et embarqué existent — ce qui compte pour un produit qui aura peut-être besoin plus tard d'une borne ou d'un outil interne sur poste.

C'est un choix mature plutôt qu'un pari. Google construit ses propres produits avec, de grandes applications grand public tournent dessus, et le rythme des versions est assez régulier pour être planifié.

• Quand le produit dépend d'un SDK fournisseur qui n'existe que pour Swift et Kotlin et que le plugin communautaire n'est plus maintenu. Vous pouvez écrire la passerelle, mais vous maintenez désormais une passerelle.
• Quand l'application est surtout une surface du système d'exploitation : widgets d'écran d'accueil, activités en direct, applications de montre, extensions de partage. Ces éléments s'écrivent en natif quel que soit le framework de l'application principale.
• Quand l'exigence est de ressembler exactement à la plateforme, sur chaque contrôle, pour toujours. Les widgets Cupertino de Flutter imitent iOS ; ils ne changent pas le jour où Apple change.
• Quand votre équipe est de culture React et maintiendra l'application elle-même. Le meilleur framework est celui que vos gens savent garder en vie.
• Quand la taille d'installation est une contrainte dure sur un marché d'appareils d'entrée de gamme et de données mobiles chères. Flutter embarque un moteur avant d'embarquer votre premier écran.

Nous le disons ouvertement parce que l'alternative est pire. Une agence qui recommande le même framework pour tous les projets vous parle d'elle-même, pas de votre produit.

Partager un code supprime du travail réellement dupliqué. L'interface, la gestion d'état, les modèles, la validation, la couche API et la plupart des tests sont écrits une seule fois. C'est le gros d'une application, et c'est toute la raison d'être du cross-platform.

Cela ne rend pas la seconde plateforme gratuite, et quiconque prétend le contraire n'en a jamais publié une. Ce qui reste spécifique à chaque plateforme :

• Les permissions, l'exécution en arrière-plan et le comportement des notifications diffèrent, et chacune demande sa propre configuration et ses propres tests.
• La présence sur les stores est dupliquée : deux comptes, deux revues, deux jeux de visuels, deux calendriers de publication.
• La configuration native vit dans les projets iOS et Android — signature, entitlements, manifestes, fichiers d'association pour les liens profonds.
• Certains plugins se comportent différemment selon la plateforme, et quelques bugs n'apparaissent que sur l'une des deux.
• Les tests se font sur les deux. Un code partagé n'est pas un appareil partagé.

Le résumé honnête : un seul code rend deux plateformes nettement moins chères que deux développements natifs, et nettement plus chères qu'une seule. Nous estimons sur cette base, et l'estimation change quand le périmètre change — par écrit, avant que le travail ne commence, jamais en silence.

Une réécriture est la façon la plus coûteuse de réparer une application : la première question est donc de savoir si l'application existante est réellement le problème. Si deux codes natifs ont divergé, que chaque fonctionnalité est construite deux fois et que la moitié du budget passe à les maintenir alignés, alors un code Flutter unique est une vraie réponse. Si l'application semble lente parce que le backend est lent, changer de framework front ne change strictement rien.

Deux façons de procéder

Progressive : Flutter est ajouté à l'application existante et reprend une zone à la fois, si bien que les utilisateurs continuent de recevoir des versions et que le risque reste contenu. Cela coûte plus cher en plomberie — deux systèmes de build, une navigation qui traverse la frontière, un design system partagé — et c'est en général le bon choix pour une application avec de vrais utilisateurs et un vrai chiffre d'affaires.

Refonte complète : moins chère par fonctionnalité et plus simple à raisonner, et c'est le bon choix quand l'application existante est petite, non documentée, ou bâtie sur une technologie que plus personne ne maintient. Le piège est le périmètre. Une refonte devient discrètement une redéfinition du design, et elle prend alors deux fois plus longtemps que l'estimation acceptée par tout le monde.

Ce que nous regardons avant de recommander l'une ou l'autre

• Quelle part de l'application est réellement spécifique à une plateforme, par opposition à des écrans, des formulaires et des appels API.
• Si le backend et l'API sont assez stables pour construire dessus, ou s'ils font partie du problème.
• Quelles dépendances natives existent aujourd'hui, et si chacune a un équivalent Flutter maintenu.
• Si l'application actuelle a des tests. Sans eux, la parité fonctionnelle est une affaire d'opinion.
• Qui maintiendra le résultat, et dans quel langage.

La réponse revient par écrit, avec le raisonnement et avec l'hypothèse de ne rien faire incluse. Une réécriture que personne ne peut justifier sur le papier est une réécriture que l'on regrette.

Flutter peut atteindre tout ce que la plateforme sait faire. La seule question est de savoir qui écrit la passerelle. Les method channels font passer des messages typés entre Dart et Swift ou Kotlin. Pigeon génère ce code répétitif à partir d'un schéma, ce qui élimine toute une catégorie d'incohérences à l'exécution entre les deux côtés. Et dart:ffi appelle directement des bibliothèques C et C++, sans canal du tout, ce qui est en général la bonne voie vers un SDK natif existant écrit en C.

Notre façon de traiter les plugins

La plupart des besoins sont déjà couverts par un package, et en choisir un est une décision de maintenance plutôt qu'un résultat de recherche. Avant qu'une dépendance n'entre, nous regardons la date de sa dernière version, si elle supporte correctement la version actuelle de Flutter et les deux plateformes, la façon dont les tickets ouverts sont traités, et la difficulté qu'il y aurait à la remplacer. Un package populaire mais abandonné vaut moins qu'un petit package maintenu.

Là où rien de convenable n'existe, nous écrivons le plugin — fédéré quand le comportement diffère réellement selon la plateforme — et il vit dans votre dépôt, testé sur les deux, pour que personne n'ait à le désosser dans un an.

Une application Flutter embarque son moteur : le plancher d'une application installée est donc plus haut que celui de son équivalent natif. En Europe, c'est en général sans conséquence. Sur les marchés où le stockage et les données mobiles coûtent de l'argent, c'est une contrainte réelle — et elle se gère en grande partie.

• Publier des builds par architecture. Un Android App Bundle ne sert à chaque appareil que le code dont il a besoin.
• Les polices d'icônes et les ressources inutilisées sont élaguées dans les builds de release ; ce qui gonfle réellement un paquet, ce sont les grandes images et les médias embarqués.
• Le chargement différé peut sortir de l'installation initiale les parties d'une application Android rarement utilisées.
• Auditer les dépendances pour leur poids, et pas seulement pour leurs fonctionnalités.

Les performances en pratique

Les saccades dans une application Flutter viennent rarement du framework. C'est presque toujours du travail sur le thread d'interface qui devrait se trouver ailleurs : décoder des images en pleine résolution, reconstruire un arbre entier parce que l'état est placé trop haut, analyser une grosse charge JSON de façon synchrone au lieu de le faire dans un isolate, ou construire tous les éléments d'une liste plutôt que les seuls éléments visibles. Nous profilons en mode release sur un téléphone Android de milieu de gamme plutôt que sur le dernier iPhone, parce que c'est là que le problème se trouve.

Flutter compile vers le web et vers le desktop, et les deux fonctionnent. Aucun des deux n'est gratuit, et les choisir pour la mauvaise raison est une bonne façon d'enliser un projet.

Flutter web

La page est un canevas que le framework peint. Cela en fait une manière raisonnable de livrer un tableau de bord interne ou un outil d'administration derrière une authentification, en réutilisant le code de l'application. C'est un mauvais choix pour tout ce qui doit être trouvé par un moteur de recherche ou lu par un robot d'indexation : le téléchargement initial est lourd, le HTML contient peu de chose, et le texte ne se comporte pas comme dans un document. Si une page doit se positionner, construisez-la en Next.js et laissez Flutter s'occuper de l'application.

Desktop

Les builds Windows, macOS et Linux sont bien réels et utiles pour des outils internes. Chacun apporte son propre empaquetage, sa signature de code, sa notarisation et son mécanisme de mise à jour — ce qui constitue un projet distinct avec son propre budget, et non une case à cocher dans la configuration du build.

• Des tests unitaires pour la logique métier, là où les bugs coûtent le plus cher et où les tests coûtent le moins.
• Des tests de widgets pour les écrans et leurs états — chargement, vide, erreur, rempli — parce que ce sont ces états qui partent cassés en production.
• Des tests d'intégration pour les parcours qui ne doivent jamais casser : connexion, paiement, action centrale du produit.
• Des golden tests là où une régression visuelle aurait de vraies conséquences.
• Le tout en CI sur chaque pull request, avec des builds distribués automatiquement aux testeurs.

L'architecture sert le même objectif. La logique métier se tient à l'écart des widgets, la gestion d'état est un choix unique appliqué avec constance — Riverpod ou BLoC, décidé une fois et écrit noir sur blanc plutôt que mélangé écran par écran — et l'accès à la plateforme est placé derrière des interfaces pour pouvoir être simulé dans un test. Flutter lui-même avance vite : mettre à niveau le SDK et ses dépendances est donc un travail planifié, fait par petits pas, au lieu d'un saut de plusieurs versions le jour où quelque chose y oblige.