L'essentiel sur la migration Cordova / Ionic vers Flutter
Le constat est sans appel : Apache Cordova accumule les vulnérabilités non corrigées. Le dernier release majeur (Cordova 12) date de 2023, et l'écosystème de plugins — la raison d'être de Cordova — se dégrade mois après mois. Sur les 2 600 plugins Cordova référencés sur npm, moins de 18 % ont reçu une mise à jour dans les 12 derniers mois (source : analyse npm registry, avril 2026). PhoneGap a été officiellement abandonné par Adobe en 2020. Ionic/Capacitor est un wrapper plus moderne, mais il repose toujours sur une WebView pour le rendu — avec les limitations inhérentes : performances plafonnées à 30-40 fps sur les animations complexes, accès natif médiatisé par des plugins JavaScript, cold start entre 2 et 4 secondes sur les devices Android mid-range. Continuer à maintenir une app Cordova/Ionic en 2026, c'est investir du budget dans une dette technique qui s'aggrave chaque trimestre.
Flutter 3.x règle le problème à la racine. Au lieu de wrapper du HTML/CSS/JS dans une WebView, Flutter compile du Dart en code machine natif ARM64 (iOS) et x86_64/ARM (Android) via son moteur de rendu Impeller. Il n'y a pas de pont JavaScript-natif, pas de WebView, pas de DOM. Chaque pixel est rendu directement par le GPU. Le résultat est mesurable : 60 fps constants, cold start sous 800 ms, consommation mémoire 40 à 50 % inférieure à une application Cordova équivalente. L'écosystème pub.dev (40 000+ packages Dart) couvre la quasi-totalité des fonctionnalités accessibles via les plugins Cordova — caméra, géolocalisation, stockage local, push notifications, Bluetooth, NFC, biométrie — avec des API typées, null-safe, et maintenues activement.
La méthode Nehos de migration Cordova vers Flutter. On ne fait pas de big bang. La migration est progressive, structurée en 4 phases : (1) Audit technique de l'app Cordova existante — inventaire des plugins, cartographie des dépendances, évaluation de la dette technique, mesure des performances actuelles. (2) Mapping plugins — correspondance systématique entre chaque plugin Cordova utilisé et le package Dart Flutter équivalent, avec identification des plugins sans équivalent (nécessitant un développement custom via platform channels). (3) Réécriture par modules — migration écran par écran, en commençant par les parcours critiques (plus utilisés, plus impactants sur le business). (4) Bascule progressive — tests de non-régression, validation utilisateurs, publication sur stores, décommissionnement de l'ancienne app. Durée typique : 3 à 9 mois selon le nombre d'écrans et la complexité des plugins.
Budget : 1,5 k€ HT pour la migration d'une app simple (8-15 écrans, plugins standards), jusqu'à partir de 19 k€ HT pour une app complexe (30+ écrans, plugins custom, offline-first, intégrations tierces multiples). L'audit initial (5 jours, à partir de 873 € HT) est déductible du projet si engagement dans les 45 jours.
Migration 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. Résultat mesuré sur nos projets : cold start divisé par 2.5, consommation RAM réduite de 45 %, taille de bundle en baisse de 40 %. Budget : 1,5 k€ HT selon la complexité de l'application source.
Adapté à toute taille de structure
#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 : sur les 2 600 plugins Cordova référencés sur npm, notre analyse interne (scan automatisé npm registry, avril 2026) montre que 82 % n'ont pas été mis à jour depuis plus de 12 mois. 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 18 et Android 15. Le plugin cordova-plugin-inappbrowser présente des vulnérabilités XSS documentées non patchées depuis 2024. 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 mesurable : sur notre benchmark interne (application de référence identique, 20 écrans, liste de 5 000 items, animations de transition, appels API REST), les résultats sur Samsung Galaxy A54 :
- Cold start : Cordova 3.4 s vs Flutter 820 ms (-76 %)
- Frame time P99 (scroll liste) : Cordova/Ionic 28 ms vs Flutter 7 ms
- RAM consommée après 10 min d'usage actif : Cordova 287 MB vs Flutter 158 MB (-45 %)
- Taille APK release : Cordova 32 MB vs Flutter 19 MB (-41 %)
Ces chiffres ne sont pas des benchmarks de laboratoire optimisés pour la démo. Ce sont des mesures sur une application métier réaliste, avec de la logique business, des appels réseau, et du stockage local.
#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
On a migré 6 applications Cordova/Ionic vers Flutter depuis 2024. Voici la méthodologie qui fonctionne.
#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).
Notre expérience sur 6 migrations : en moyenne, 70 % des plugins sont des remplacements directs, 20 % nécessitent une adaptation, et 10 % nécessitent un développement custom. Ce sont ces 10 % 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. Le temps moyen de résolution d'un build cassé Cordova chez nos clients : 4 heures.
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 80 % 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 mesurés sur nos 6 migrations Cordova/Ionic vers Flutter, moyennés.
Performances utilisateur : cold start réduit de 65 % en moyenne (de 3.1 s à 1.1 s), fluidité scroll et animations passée de 30-40 fps à 60 fps constants, consommation RAM réduite de 42 % en moyenne. Taille application : APK/IPA réduit de 35 à 45 % (suppression de la WebView et des assets web embarqués). Stabilité : crash rate post-migration réduit de 78 % en moyenne (suppression des crashes liés aux plugins Cordova obsolètes). Coût de maintenance : temps de maintenance corrective réduit de 55 % à 6 mois post-migration (fin des incompatibilités de plugins, builds stables, tests automatisés). Satisfaction utilisateur : NPS moyen en hausse de +18 points sur les applications métier B2B (mesuré à 3 mois post-migration).
Ces chiffres ne sont pas des projections marketing. Ce sont des mesures réalisées en conditions réelles sur des applications B2B en production.
#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 — 1,5 k€ HT
Trois fourchettes selon la complexité de l'application source.
Migration app simple — 1,5 k€ HT, 3 à 4 mois. Application Cordova/Ionic de 8-15 écrans, plugins standards (caméra, GPS, push, stockage local), pas de mode offline complexe, pas d'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 — 35 à 511 k€ HT, 4 à 6 mois. Application de 15-25 écrans, 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 — 13,5 k€ HT, 6 à 9 mois. Application de 25-40+ écrans, 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. Inclut un accompagnement post-migration de 3 mois.
L'audit initial (5 jours, à partir de 873 € HT) est déductible du budget projet si engagement dans les 45 jours. Estimation précise en 30 minutes : Prendre RDV migration Cordova.