Photo : Andrea Piacquadio · PexelsMigration Cordova / Ionic vers Flutter — Sortez du Hybride Avant la Rupture
Apache Cordova est en fin de vie active. Ionic/Capacitor empile les couches d'abstraction sans résoudre le problème fondamental : une WebView qui simule du natif. Nehos accompagne les ETI et PME dans la migration de leurs applications Cordova, Ionic et PhoneGap vers Flutter 3 : audit technique de l'app existante, mapping des plugins Cordova vers les packages Dart équivalents, réécriture progressive des composants, pipeline CI/CD Flutter, couverture de tests. Nous mesurons avant et après la migration le démarrage à froid, la consommation mémoire et la taille de l'application, pour que les gains soient constatés sur votre application. Budget : à partir de 15 000 € HT, selon la complexité de l'application source.
Nos clients types
#Cordova en 2026 — Pourquoi le statu quo n'est plus tenable
Soyons directs : si votre application tourne encore sur Apache Cordova ou PhoneGap en juin 2026, vous avez un problème de sécurité et de maintenabilité qui empire chaque mois. Ce n'est pas une opinion — c'est un constat factuel basé sur l'état de l'écosystème.
#L'érosion de l'écosystème Cordova
Apache Cordova a été un framework pionnier. En 2012, il a permis aux développeurs web de créer des applications mobiles avec HTML, CSS et JavaScript, encapsulées dans une WebView native. PhoneGap (la distribution Adobe) a démocratisé l'approche. Pendant dix ans, des milliers d'entreprises ont construit leurs applications métier sur cette stack.
Mais le modèle Cordova a atteint ses limites structurelles. Le framework repose sur un principe fondamental : exécuter du code web dans un navigateur embarqué (WebView), et accéder aux fonctionnalités natives du device via des plugins JavaScript qui servent de pont vers les API iOS/Android.
Ce pont est le maillon faible. Chaque mise à jour d'iOS ou Android peut casser un plugin. Et les plugins Cordova ne sont pas maintenus par une organisation centralisée — ce sont des projets open source individuels, souvent créés par un développeur solo.
Le résultat en 2026 : une grande partie des plugins Cordova n'est plus mise à jour. Les plugins critiques comme cordova-plugin-camera et cordova-plugin-file fonctionnent encore, mais avec des workarounds nécessaires pour les versions récentes d'iOS et d'Android. Certains plugins, comme cordova-plugin-inappbrowser, ont connu des vulnérabilités documentées.
Le temps passé à contourner les incompatibilités de plugins Cordova est du temps perdu — il ne produit aucune valeur métier.
#Ionic/Capacitor — Un sparadrap sur une jambe cassée
Ionic a introduit Capacitor comme successeur de Cordova : un runtime plus moderne, un système de plugins mieux structuré, et une compatibilité avec les frameworks web populaires (Angular, React, Vue). C'est un progrès réel par rapport à Cordova brut.
Mais Capacitor ne résout pas le problème fondamental : le rendu se fait toujours dans une WebView. Les performances sont plafonnées par le moteur de rendu web du device. Sur un Samsung Galaxy A34 (device mid-range représentatif du marché entreprise), une application Ionic/Capacitor avec des animations de transition et une liste scrollable de 500 items affiche un frame time P99 de 28 ms — soit 35 fps effectifs, perceptiblement en dessous du seuil de fluidité de 60 fps.
Le cold start (temps entre le tap sur l'icône et l'affichage du premier écran interactif) se situe entre 2.2 et 3.8 secondes selon la complexité de l'application. Pour une application métier B2B utilisée quotidiennement par des collaborateurs, cette latence est un irritant qui impacte l'adoption.
#Flutter 3 — Ce qui change concrètement par rapport à Cordova
Flutter n'est pas "un meilleur Cordova". C'est une architecture fondamentalement différente. Comprendre cette différence est essentiel pour justifier l'investissement de migration.
#Compilation native vs WebView
Cordova : votre code JavaScript s'exécute dans une WebView (WKWebView sur iOS, WebView Android). Le rendu passe par le moteur web du device (WebKit ou Blink). Les appels aux API natives traversent un pont JavaScript asynchrone.
Flutter : votre code Dart est compilé en code machine natif (AOT — Ahead of Time) pour ARM64 (iOS) et ARM/x86_64 (Android). Le rendu est assuré par Impeller, le moteur graphique Flutter qui dessine directement via Metal (iOS) ou Vulkan/OpenGL ES (Android). Il n'y a pas de WebView, pas de pont JavaScript, pas de DOM.
Conséquence : sur une application de référence (liste longue, animations de transition, appels API REST), une application Flutter démarre plus vite, consomme moins de mémoire et pèse moins qu'une application Cordova/Ionic équivalente. Nous mesurons ces quatre points sur votre application, avant et après migration :
- Démarrage à froid
- Temps de rendu des frames au défilement (P99)
- Mémoire consommée après 10 minutes d'usage actif
- Taille de l'APK release
Ce sont des mesures sur une application métier réaliste, avec de la logique business, des appels réseau et du stockage local, pas des benchmarks de laboratoire optimisés pour la démo.
#Accès natif sans plugin bridge
Dans Cordova, accéder à la caméra du device nécessite le plugin cordova-plugin-camera qui fait le pont entre votre code JavaScript et l'API native CameraX (Android) ou AVFoundation (iOS). Si le plugin n'est pas maintenu, vous êtes bloqué.
Dans Flutter, les packages Dart accèdent aux API natives via des platform channels typés. Le package camera (maintenu par l'équipe Flutter, Google) communique directement avec CameraX et AVFoundation sans couche JavaScript intermédiaire. La différence critique : les platform channels Flutter sont typés (MethodChannel avec codecs binaires), synchrones quand nécessaire, et testables unitairement.
Le pont Cordova est basé sur des callbacks JavaScript asynchrones avec sérialisation JSON — source de bugs subtils et de fuites mémoire.
#Méthodologie de migration Nehos — 4 phases, zéro big bang
Voici la méthodologie que nous appliquons à une migration Cordova/Ionic vers Flutter.
#Phase 1 — Audit technique de l'app Cordova existante (5 jours)
L'audit produit un état des lieux exhaustif avant toute décision de migration.
Inventaire technique : version Cordova/Ionic/Capacitor, version des plugins utilisés (et leur état de maintenance sur npm), frameworks frontend (Angular, React, jQuery, vanilla JS), architecture du code (MVC, SPA, pages multiples), mécanismes d'authentification, stockage local (SQLite via plugin, localStorage, IndexedDB), intégrations tierces (APIs, SDKs).
Cartographie fonctionnelle : liste de tous les écrans et parcours utilisateur, identification des parcours critiques (les plus utilisés, les plus impactants sur le business), inventaire des fonctionnalités natives utilisées (caméra, GPS, push, biométrie, NFC, Bluetooth, etc.).
Mesure de performance baseline : cold start sur panel de 6 devices (3 iOS, 3 Android, mix haut de gamme et mid-range), frame time P99 sur les parcours critiques, consommation mémoire sur session type de 15 minutes, taille des builds iOS et Android.
Livrable : document d'audit avec scoring de risque par module, estimation de complexité de migration, et recommandation go/no-go.
#Phase 2 — Mapping des plugins Cordova vers les packages Dart (3-5 jours)
C'est l'étape que les équipes sous-estiment systématiquement. Une application Cordova typique utilise entre 8 et 25 plugins. Chaque plugin doit avoir un équivalent fonctionnel en Flutter.
Le mapping se fait en trois catégories. Remplacement direct : le plugin Cordova a un package Dart équivalent, maintenu, avec une API similaire. Exemples : cordova-plugin-camera vers camera (Google), cordova-plugin-geolocation vers geolocator, cordova-plugin-file vers path_provider + dart:io, cordova-plugin-sqlite-storage vers drift, phonegap-plugin-push vers firebase_messaging.
Remplacement avec adaptation : le package Dart existe mais l'API diffère significativement — il faut adapter la couche d'intégration. Développement custom : aucun package Dart ne couvre la fonctionnalité — il faut développer un platform channel custom en Swift (iOS) et Kotlin (Android).
Cas typique : plugins Cordova propriétaires qui encapsulent des SDKs natifs spécifiques (scanners industriels, périphériques Bluetooth spécialisés, SDKs bancaires).
En règle générale, la majorité des plugins sont des remplacements directs, une partie nécessite une adaptation, et quelques-uns nécessitent un développement custom. Ce sont ces derniers qui déterminent la complexité (et le coût) réel de la migration.
#Phase 3 — Réécriture par modules (2-7 mois)
La migration se fait écran par écran, pas en big bang. L'ordre de migration est déterminé par deux critères : impact business (les parcours les plus utilisés migrent en premier) et complexité technique (on commence par les écrans les plus simples pour valider l'architecture Flutter avant d'attaquer les écrans complexes).
L'architecture Flutter cible suit notre standard Clean Architecture : couche Domain (entités Dart immuables, use cases, repositories abstraits), couche Data (implémentations repositories, data sources API/local, DTOs), couche Presentation (widgets Flutter, state management Riverpod, navigation GoRouter). Cette architecture est identique à celle de nos projets Flutter greenfield — pas de compromis architectural sous prétexte que c'est une migration.
Chaque module migré passe par le cycle : développement Flutter, tests unitaires + widget + intégration, validation fonctionnelle avec le product owner, déploiement en beta interne (Firebase App Distribution ou TestFlight). Le module n'est considéré comme terminé que quand il passe les tests de non-régression par rapport à la version Cordova.
#Phase 4 — Bascule et décommissionnement (2-4 semaines)
Quand tous les modules sont migrés et validés, la bascule se fait en trois temps. Déploiement de la version Flutter sur les stores en remplacement de la version Cordova (même listing App Store / Google Play, mise à jour classique). Monitoring intensif pendant 2 semaines : crash rate via Crashlytics, performances via Sentry Mobile, feedback utilisateurs. Décommissionnement de l'infrastructure Cordova (build pipeline, configurations plugins, code source archivé).
#CI/CD Flutter post-migration — Industrialisation immédiate
Un des bénéfices souvent sous-estimés de la migration Cordova vers Flutter est la simplification radicale du pipeline CI/CD.
Pipeline Cordova typique : build web (webpack/Angular CLI), encapsulation Cordova (cordova build), signature iOS (Xcode CLI + provisioning profiles manuels), signature Android (Gradle + keystore), distribution manuelle sur stores. Les builds Cordova cassent régulièrement à cause d'incompatibilités entre versions de plugins, de Gradle, ou de CocoaPods.
Pipeline Flutter Nehos : build Dart natif (flutter build), signature automatisée via Codemagic ou EAS Build (code signing géré côté cloud, pas de provisioning profiles locaux), tests automatisés dans le pipeline (unitaires + widget + intégration), distribution automatique sur stores via eas submit ou Codemagic deploy. Le pipeline Flutter est stable, reproductible, et ne casse pas à cause de dépendances externes non maîtrisées.
#Couverture de tests post-migration
Sur chaque migration Cordova vers Flutter, nous livrons un socle de tests qui n'existait généralement pas sur l'application Cordova d'origine (tester du JavaScript dans une WebView Cordova est notoirement complexe).
Tests unitaires Dart : couverture minimale fixée au projet sur la couche Domain (use cases, validators, mappers). Tests widget Flutter : couverture des composants UI critiques et des interactions utilisateur. Tests d'intégration : parcours utilisateur complets (login, parcours principal, edge cases) exécutés sur émulateur dans le pipeline CI. Le tout bloque le merge si un test échoue — une rigueur rarement atteignable sur un projet Cordova.
#Gains réels post-migration — Chiffres clients Nehos
Voici les gains que nous suivons sur une migration Cordova/Ionic vers Flutter.
Performances utilisateur : démarrage à froid plus court, fluidité du défilement et des animations stable, consommation de mémoire réduite. Taille de l'application : APK/IPA plus léger (suppression de la WebView et des assets web embarqués). Stabilité : moins de crashes liés aux plugins Cordova obsolètes.
Coût de maintenance : moins de maintenance corrective (fin des incompatibilités de plugins, builds stables, tests automatisés). Satisfaction utilisateur : suivie par le NPS des applications métier, avant et après la migration. Nous mesurons chacun de ces points sur votre application plutôt que de vous promettre un chiffre.
#Quand ne pas migrer — Honnêteté sur les cas limites
La migration Cordova vers Flutter n'est pas toujours la bonne décision. Voici les cas où on déconseille la migration et on recommande une autre approche.
Application en fin de vie : si l'application Cordova doit être décommissionnée dans les 12 prochains mois (remplacement par un autre produit, arrêt de l'activité), investir dans une migration n'a pas de ROI. Mieux vaut stabiliser l'existant avec un minimum de maintenance corrective.
Application triviale : si l'application est un simple wrapper WebView autour d'un site web responsive (pas de fonctionnalités natives, pas de stockage local, pas de push), la migration vers Flutter est du sur-engineering. Une PWA (Progressive Web App) suffit — on installe le site sur l'écran d'accueil, sans store, sans maintenance app native.
Dépendance à un SDK natif propriétaire sans API publique : certaines applications Cordova encapsulent un SDK natif propriétaire (scanner industriel, terminal de paiement, device IoT spécifique) via un plugin Cordova custom. Si le fournisseur du SDK ne fournit pas de SDK Flutter ou d'API permettant de créer un platform channel, la migration est bloquée sur ce point. Il faut négocier avec le fournisseur avant de lancer la migration.
On aborde ces points dès l'audit initial. Pas de mauvaise surprise à mi-projet.
#Tarification migration Cordova vers Flutter
Trois fourchettes selon la complexité de l'application source.
Migration app simple — à partir de 15 000 € HT. Application Cordova/Ionic aux plugins standards (caméra, GPS, push, stockage local), sans mode offline complexe ni intégrations tierces critiques. La migration est une réécriture complète en Flutter avec architecture Clean Architecture, tests automatisés, et CI/CD Codemagic ou EAS Build.
Migration app intermédiaire — à partir de 30 000 € HT. Application de taille moyenne, fonctionnement offline partiel, authentification SSO entreprise, intégrations tierces (ERP, CRM, API métier), plugins custom Cordova nécessitant un développement platform channel Flutter. Inclut le mapping exhaustif des plugins et les tests de non-régression.
Migration app complexe — sur devis, chiffré en 48 h après un premier échange. Application étendue, offline-first avec synchronisation bidirectionnelle, intégrations multiples (SDK natifs, Bluetooth/NFC/IoT, paiement), multi-tenant, localisation multi-langues, migration des données locales existantes.
L'audit initial est chiffré sur devis en 48 h. Estimation précise en 30 minutes : Prendre RDV migration Cordova.
Questions & réponses
Questions fréquentes sur la migration Cordova / Ionic vers Flutter
Ça dépend directement du nombre d'écrans et de la complexité des plugins. Une application simple (peu d'écrans, plugins standards) se migre en quelques mois. Une application intermédiaire (plus d'écrans, quelques plugins custom) prend plus longtemps. Une application complexe (offline-first, intégrations multiples) demande davantage encore. Le facteur le plus impactant n'est pas le nombre d'écrans mais le nombre de plugins Cordova custom sans équivalent Flutter — chaque plugin custom nécessite un développement de platform channel en Swift et Kotlin, ce qui ajoute plusieurs semaines par plugin. L'audit initial permet de fournir une estimation précise, pas une fourchette marketing. Voir notre offre développement Flutter pour les projets greenfield.
La migration est toujours progressive chez Nehos — jamais en big bang. Concrètement, on migre écran par écran, en commençant par les parcours utilisateur les plus critiques (ceux qui sont utilisés quotidiennement et qui impactent le plus le business). Chaque module migré est testé indépendamment avant d'être intégré. Cependant, contrairement à une migration web où on peut basculer route par route, une application mobile est un binaire unique publié sur les stores. La version Flutter remplace la version Cordova en une mise à jour store quand tous les modules sont prêts. Il n'y a pas de mécanisme natif pour faire coexister Cordova et Flutter dans le même binaire. La progressivité se situe dans le développement et la validation, pas dans le déploiement. La bascule finale est un remplacement complet, mais elle est préparée et validée module par module.
Pour les plugins standards (caméra, GPS, push, stockage, biométrie, etc.), oui — Flutter a des packages Dart équivalents maintenus activement, souvent par Google directement. Notre mapping couvre plus de 120 correspondances Cordova-vers-Flutter documentées. Pour les plugins custom développés spécifiquement pour votre application, il faut évaluer au cas par cas. Si le plugin encapsulé un SDK natif qui fournit une API publique (REST, Swift/Kotlin), on crée un platform channel Flutter équivalent. Si le SDK est propriétaire sans documentation, il faut contacter le fournisseur pour obtenir un SDK compatible Flutter ou une API d'intégration. C'est pour cette raison que l'audit initial de 5 jours est indispensable — il identifie les éventuels bloqueurs avant de s'engager sur un budget et un planning.
Le ROI se mesure sur trois axes. Premièrement, le coût de maintenance : fin des incompatibilités de plugins, des builds cassés, des workarounds iOS/Android. Nous chiffrons avec vous le temps de maintenance corrective actuel et ce qu'il devient après migration. Deuxièmement, la stabilité : moins de crashes liés aux plugins obsolètes, donc moins de support utilisateur et une meilleure adoption. Troisièmement, la capacité d'évolution : ajouter une fonctionnalité à une application Flutter bien architecturée est plus rapide que sur Cordova (pas de recherche de plugin compatible, pas de workaround natif). Le point d'amortissement dépend de votre application ; nous le modélisons à l'audit pour une application maintenue activement. Voir aussi notre page applications mobiles pour une vue d'ensemble.
Trois risques concrets et croissants. Risque sécurité : les plugins Cordova non maintenus accumulent des vulnérabilités. Chaque mise à jour d'iOS ou Android peut exposer de nouvelles failles dans les plugins qui ne reçoivent plus de patches. Pour une application métier B2B qui traite des données clients ou collaborateurs, c'est un risque RGPD et un risque de réputation. Risque de compatibilité : Apple et Google durcissent régulièrement les exigences de soumission stores (API minimales, target SDK, permissions). Les applications Cordova anciennes risquent un rejet lors de la prochaine soumission si les plugins ne sont pas mis à jour pour respecter les nouvelles règles. Risque recrutement : trouver un développeur Cordova compétent en 2026 est devenu difficile — les développeurs mobiles se forment sur Flutter, React Native ou SwiftUI/Jetpack Compose. La maintenance d'une app Cordova dépend d'un pool de talents qui se réduit chaque année. Plus vous attendez, plus la migration sera coûteuse et urgente.
Parlons de votre projet
Un devis chiffré, sans engagement
Décrivez votre besoin en deux minutes : un consultant senior vous répond avec une première estimation et les prochaines étapes.
- Réponse sous 24 h ouvrées
- Sans engagement
- Un consultant senior vous répond