Lorsqu'une solution mobile éprouvée repose sur une technologie en fin de vie, les équipes de développement font face à une décision difficile : comment moderniser la base technique sans mettre en péril l'exploitation courante ? Chez DATAflor, nous avons relevé exactement ce défi, et appris qu'un bon chemin de migration va parfois à l'encontre des tendances du moment.
Vue d'ensemble du projet
De mars à septembre 2025, nous avons travaillé avec DATAflor, fournisseur de référence pour la numérisation dans l'aménagement paysager et l'horticulture, afin de migrer leur application TIME de Xamarin.Forms vers .NET MAUI. Le défi particulier : la migration devait être réalisée sans aucune interruption du développement, tout en poursuivant en parallèle le développement de nouvelles fonctionnalités et la livraison de corrections de bugs.
L'équipe projet se composait de deux développeurs vensas travaillant en étroite collaboration avec un développeur DATAflor et le product owner DATAflor. Technologies utilisées : C#, pattern MVVM, SQLite pour la persistance locale, et bien sûr la migration de Xamarin.Forms vers .NET MAUI.
La situation de départ
La situation était claire : Xamarin.Forms avait atteint sa fin de support en mai 2024. En même temps, la pression augmentait avec les nouvelles versions d'Android et d'iOS. L'App Store et le Play Store exigeaient des target SDKs à jour, Google introduisait des exigences de taille de page de 16 KB, le tout sur une application en production servant une base d'utilisateurs à quatre chiffres.
Mais les défis techniques n'étaient qu'une partie de l'histoire. DATAflor exploite une solution Xamarin.Forms multi-projets mature, où plusieurs applications accèdent à des bibliothèques partagées. Le pattern MVVM était déjà bien établi, SQLite gérait la persistance locale des données, et les applications fonctionnaient sur divers form factors, sur iOS et Android, du smartphone à la tablette.
Typique pour ce type d'application : une utilisation intensive de fonctionnalités matérielles comme les lecteurs de codes-barres, les caméras et les gyromètres. Ces fonctions sont essentielles pour les processus métier des clients. L'échec, ou même une baisse de qualité, n'était pas une option.
La décision stratégique : conserver le multi-projets et prioriser les APIs matérielles
C'est là qu'est venue la première décision importante : alors que de nombreux projets de migration recommandent un passage vers une structure single-project, nous avons délibérément décidé de ne pas suivre cette voie. L'architecture multi-projets serait conservée.
Pourquoi ? Les avantages étaient évidents : l'équipe pouvait continuer à travailler dans une structure connue sans devoir lancer un refactoring big bang. Le développement parallèle de fonctionnalités restait possible, et chaque module applicatif pouvait être validé de manière incrémentale. Les risques liés aux merges et au pipeline de build restaient maîtrisables.
Autre point critique : la priorité donnée aux APIs matérielles. Les lecteurs de codes-barres et les caméras sont des fonctions cœur de l'application TIME. Nous avons décidé de les traiter tôt afin d'éviter des bloqueurs plus tard. En utilisant CommunityToolkit.MAUI, nous avons pu créer une interface unifiée couvrant Android et iOS. Il devenait ainsi possible de centraliser personnalisation et optimisation pour l'usage dans l'application TIME existante.
Nos règles de migration étaient clairement définies : continuer à utiliser le pattern MVVM éprouvé et ne moderniser que là où cela apportait une vraie valeur. Les abstractions existantes dans le code partagé devaient être conservées et améliorées si nécessaire. La migration devait progresser couche par couche, du code partagé à la persistance puis à l'UI. Et les fonctionnalités MAUI ne seraient utilisées que lorsqu'elles apporteraient un avantage clair.
Implémentation technique : couche par couche
La migration n'a pas été un sprint, mais un marathon réfléchi. Côté layout, nous avons dû équilibrer avec soin les différences de rendu entre MAUI et Xamarin.Forms. Pour la persistance, il était essentiel de migrer correctement les chemins SQLite et de garantir la stabilité des données.
Les lecteurs de codes-barres ont constitué un défi particulier. Avec le client, nous avons itéré sur plusieurs approches afin d'obtenir le meilleur résultat. L'intégration caméra nécessitait une interface unifiée pour Android et iOS sur la base de CommunityToolkit.MAUI, un investissement qui paierait plusieurs fois par la suite.
Des défis comme des problèmes de performance au scroll dans des listes sous Android ont été résolus par l'équipe DATAflor, avec notre soutien, de leur propre initiative. Les code reviews et les sessions de pair programming ont aidé à maintenir une qualité élevée et à diffuser les connaissances dans l'équipe.
Le résultat : non seulement une application migrée, mais une fondation pour toutes les futures applications DATAflor.
Une collaboration d'égal à égal
Un plan techniquement excellent ne fait que la moitié du travail. Ce qui compte, c'est la manière dont les équipes collaborent. Nous nous sommes appuyés sur des boucles de feedback courtes avec une communication directe via Microsoft Teams. Des alignements hebdomadaires assuraient la coordination, tandis que les deep dives techniques étaient traités ad hoc.
Cette approche était particulièrement importante parce que les fonctionnalités continuaient à être développées et les bugs corrigés en parallèle de la migration. Une stratégie de branching propre a permis d'éviter les conflits. C'est ainsi que nous avons pu relever ensemble des défis comme des exigences supplémentaires de l'Apple App Store ou du Google Play Store.
Ce que nous avons appris
Avec le recul, la décision de conserver l'architecture multi-projets s'est révélée absolument juste. Elle a réduit de manière significative les risques et les coûts d'une telle migration. Autre enseignement important : les APIs matérielles doivent être priorisées tôt pour éviter des bloqueurs plus tard.
Le rythme de communication a été décisif, notamment pendant le développement parallèle de fonctionnalités. Un accès partagé au système de contrôle de version et des workflows fiables sont essentiels. Les abstractions, comme nos services scanner et caméra, ont non seulement augmenté la réutilisabilité, mais aussi réduit les coûts de maintenance. Et de petits cycles incrémentaux de déploiement et de test ont maintenu un élan continu dans l'équipe.
Les résultats parlent d'eux-mêmes
Le projet a été réalisé dans le budget et les délais. L'application TIME est passée en production avec succès auprès d'une base d'utilisateurs à quatre chiffres. Mais le vrai succès réside dans la fondation créée : nous travaillons avec DATAflor depuis mi-2024. La fondation décrite ici ne profite pas seulement à l'application TIME. Les applications TEAM, PROJEKT et CONNECT ont déjà été fondamentalement migrées, et leurs releases sous .NET MAUI arrivent bientôt.
La stratégie retenue a aidé DATAflor à passer à une technologie moderne sans mettre en danger l'exploitation courante ni investir dans une restructuration de l'architecture projet.
Conclusion : contrôlé plutôt que radical
Cette migration le montre : parfois, le chemin le plus conservateur est aussi le plus durable. La migration contrôlée et incrémentale a permis de maintenir la productivité. La décision délibérée de ne pas passer à une architecture single-project a évité une complexité inutile et un effort supplémentaire.
Le résultat est une architecture pérenne, extensible, sur laquelle d'autres applications peuvent s'appuyer. Pour DATAflor, cela signifie : une technologie moderne sans interruption de production, et une base solide pour les années à venir.
Vous voulez voir le résultat par vous-même ? Vous trouverez DATAflor TIME pour Android et iOS ici.
Besoin d'aide ?
Vous préparez une migration de Xamarin.Forms vers .NET MAUI, mais vous ne savez pas comment minimiser les risques et structurer la migration ? Nous pouvons vous aider. Contactez-nous via notre page de contact et nous moderniserons ensemble votre application avec succès.
