TMA Flutter Maroc : choisir le bon prestataire en 2026

Une application Flutter livrée il y a dix-huit mois a déjà vu passer environ six versions stables du SDK. Flutter publie en moyenne une release stable par trimestre, Dart suit le même rythme, et chacune de ces montées déplace quelque chose : une API dépréciée qui disparaît, un comportement de rendu qui change, une contrainte de version qui bloque un package. Pendant ce temps, Google Play et l’App Store ont relevé leurs exigences de build au moins une fois.

C’est pour cette raison que tant de PME marocaines se retrouvent avec une application qui fonctionne encore sur les téléphones des utilisateurs mais qui ne compile plus sur la machine du prestataire suivant. Le code n’a pas bougé. Tout ce qui l’entoure a bougé.

Si votre app a été développée par un freelance ou une petite structure aujourd’hui injoignable, la vraie question n’est pas de savoir s’il faut tout refaire. Un code Flutter de deux ou trois ans se reprend presque toujours. Encore faut-il un prestataire qui sait par où commencer.

Ce qui casse dans une app Flutter n’est pas ce qui casse dans une app native

Dans une application native, la surface d’instabilité est assez lisible : le langage (Swift ou Kotlin), le SDK de la plateforme, quelques bibliothèques. Quand Apple change une API, vous le lisez dans les notes de version d’Xcode et vous corrigez.

Flutter ajoute deux couches par-dessus. Le SDK Flutter et le langage Dart évoluent sur leur propre calendrier, indépendamment d’Apple et de Google. Et presque toutes les fonctions qui touchent au téléphone (caméra, notifications, biométrie, paiement, géolocalisation, stockage sécurisé) passent par un package communautaire de pub.dev qui enveloppe lui-même du code natif. Vous héritez donc du calendrier d’Apple, de celui de Google, de celui de Flutter et de celui de plusieurs dizaines de mainteneurs bénévoles. Ce n’est pas un argument contre Flutter, qui reste souvent le bon choix pour une PME qui veut deux plateformes avec une seule équipe, comme nous l’expliquons dans notre guide de décision entre application native et Flutter. Mais la maintenance demande une compétence supplémentaire : savoir à quel étage de cet empilement se situe la panne.

Chaque version stable du SDK déplace quelque chose

Sur le papier, une mise à jour SDK Flutter est indolore. En pratique, les dépréciations ont une durée de vie limitée : une API marquée obsolète finit par être retirée, et si vous avez sauté quatre versions, vous récupérez la suppression sans avoir jamais vu l’avertissement.

Quelques ruptures bien documentées, pour donner une idée du genre de travail que ça représente :

• Material 3 devenu le thème par défaut : l’apparence de tous vos composants change sans qu’une ligne de votre code bouge.
• WillPopScope remplacé par PopScope pour la gestion du bouton retour, avec un comportement différent sur les formulaires à confirmation.
• La déclaration du plugin Gradle côté Android passée en mode déclaratif, ce qui invalide les fichiers de build générés par les anciennes versions de Flutter.
• Les contraintes de version Dart dans le pubspec, qui arrêtent net la compilation dès que le SDK installé sort de l’intervalle déclaré.

La conséquence est simple : on ne passe pas de Flutter 3.3 à la dernière version en une commande. Un prestataire qui sait faire avance par paliers, remonte version par version et vérifie la compilation et les écrans critiques à chaque étape. Il fixe aussi la version de Flutter du projet, avec fvm ou un équivalent, pour que deux développeurs ne compilent pas avec deux SDK différents. Si personne ne vous parle de ça en avant-vente, notez-le.

pub.dev : la dette que personne ne surveille

Ouvrez le fichier pubspec.yaml de votre application. Vous y trouverez probablement entre vingt et cinquante dépendances directes, et plusieurs fois plus de dépendances transitives. Chacune est maintenue par quelqu’un qui ne vous connaît pas et qui n’a aucune obligation envers vous.

La commande flutter pub outdated donne en une minute l’état réel du parc : ce qui est en retard d’une version mineure, ce qui est en retard d’une majeure, et ce qui n’est plus résoluble du tout. Sur pub.dev, chaque package affiche sa date de dernière publication et, le cas échéant, un bandeau « discontinued ». Les mauvaises nouvelles sont presque toujours là.

Les packages les plus risqués sont ceux qui enveloppent un SDK natif : webview, notifications locales, gestion des permissions, lecteurs de QR et surtout passerelles de paiement. Un wrapper abandonné autour d’un SDK de paiement qui continue d’évoluer de son côté, c’est une impasse datée. Il faudra soit changer de package, soit écrire le pont natif à la main, et les deux options se chiffrent. Autre indicateur utile : la présence d’un bloc dependency_overrides. C’est parfois légitime et temporaire, mais c’est souvent la trace d’un conflit de versions contourné plutôt que résolu, qui ressortira à la première montée de SDK.

Ce qui remonte des couches natives iOS et Android

Flutter ne vous dispense pas des règles des deux magasins. Google Play impose chaque année un niveau d’API cible minimum pour publier une mise à jour, et Apple exige régulièrement que les binaires soient compilés avec une version récente du SDK iOS. Les dates et les niveaux exacts changent : vérifiez-les dans la console Play et dans les annonces Apple Developer plutôt que de vous fier à un chiffre lu dans un article. Concrètement, ces exigences se traduisent par :

• une montée d’Android Gradle Plugin et de Kotlin, parfois du JDK utilisé par le projet ;
• une mise à jour d’Xcode, qui impose parfois une montée de macOS, donc parfois un Mac plus récent ;
• la régénération des pods iOS et la relecture des permissions déclarées dans Info.plist, qu’Apple examine à chaque soumission ;
• des changements de comportement Android (affichage bord à bord, contraintes mémoire) qui dégradent l’affichage réel sans produire la moindre erreur de compilation.

Reste le volet administratif, qui bloque plus de reprises que le code lui-même. Le compte Apple Developer (99 USD par an) et le compte Google Play (25 USD une fois) doivent être au nom de votre société, pas à celui du développeur parti. Le keystore de signature Android ne se régénère pas : si l’application est inscrite à Play App Signing vous pouvez demander une réinitialisation de la clé de téléversement, sinon vous perdez la possibilité de mettre à jour l’app existante. Ces points sont détaillés dans notre article sur la publication d’une application mobile au Maroc.

TMA Flutter Maroc : les fourchettes de prix en 2026

Le coût TMA mobile Maroc dépend moins du nombre d’écrans que de la dette accumulée et du niveau d’engagement demandé. Les fourchettes ci-dessous correspondent à ce qui se pratique sur le marché marocain en 2026, hors évolutions fonctionnelles facturées au projet.

• Veille et correctifs (surveillance des crashs, montées de SDK, conformité stores, aucune nouvelle fonctionnalité) : 2 500 à 6 000 MAD par mois pour une app simple.
• TMA standard avec SLA (délai de prise en charge contractuel, correctifs, petites évolutions, une à deux publications par trimestre) : 6 000 à 15 000 MAD par mois.
• Application critique (paiement en ligne, backend sur mesure, plusieurs apps, astreinte) : 15 000 à 35 000 MAD par mois, parfois plus.
• Audit de reprise initial : 8 000 à 25 000 MAD selon la taille du code et l’état de la documentation.
• Rattrapage de SDK couvrant deux ou trois ans de retard, facturé une fois : 20 000 à 60 000 MAD.

Les taux journaliers s’étalent largement, d’un freelance Flutter expérimenté à une agence structurée, et l’écart se paie surtout en continuité de service quand la personne qui connaît votre code tombe malade. Pour le cadrage général d’un budget, les postes de la maintenance d’application mobile au Maroc restent les mêmes, Flutter ou pas.

Généraliste mobile ou prestataire Flutter : ce qu’il faut vérifier avant de signer

Cinq questions suffisent généralement à savoir à qui vous parlez.

1. Quelle version de Flutter tourne dans votre intégration continue ? Un numéro précis, un fichier de version épinglé, un pipeline : tout vaut mieux que « la dernière ».
2. Montrez-moi une migration majeure que vous avez menée. Pas une app livrée de zéro : une app reprise, remise à jour depuis plusieurs versions de retard, avec le temps que ça a pris.
3. Qui chez vous lit du Kotlin et du Swift ? Une équipe Flutter incapable de descendre dans les dossiers android/ et ios/ ne corrigera pas la moitié des pannes réelles.
4. Comment traitez-vous un package abandonné ? La bonne réponse parle de fork maintenu, de remplacement évalué ou de pont natif écrit à la main.
5. Que se passe-t-il si nous partons ? Dépôt Git chez vous, comptes stores à votre nom, documentation de build à jour. Ces clauses figurent dans notre guide pour changer de prestataire IT au Maroc.

Un généraliste mobile sérieux fait très bien ce travail. Ce qui disqualifie un prestataire, ce n’est pas l’absence d’étiquette Flutter, c’est la proposition de repartir de zéro avant même d’avoir ouvert le code. Une réécriture complète coûte plusieurs fois le prix d’une remise à niveau, et vous repayez des fonctionnalités que vous possédez déjà.

L’audit de reprise, avant la première ligne de code

Personne ne devrait s’engager sur une TMA sans avoir compilé le projet lui-même. L’audit de reprise tient en général entre trois et dix jours ouvrés, et son déroulé est assez stable.

1. Cloner le dépôt sur une machine neuve et tenter un build Android puis un build iOS sans aide extérieure. Le temps nécessaire est la première mesure de l’état du projet.
2. Relever les versions (Flutter, Dart, AGP, Kotlin, JDK, cible de déploiement iOS) et l’écart avec ce qui est supporté aujourd’hui.
3. Lancer flutter pub outdated et flutter analyze, puis classer chaque dépendance : à jour, en retard, sans mainteneur.
4. Inspecter android/ et ios/ pour repérer ce qui a été modifié à la main par rapport aux gabarits générés.
5. Chercher les secrets en clair dans le dépôt, vérifier les fichiers de configuration Firebase, les certificats et le keystore.
6. Reconstituer la chaîne de publication et les accès réels aux comptes stores, au backend, au DNS.
7. Rendre une liste de risques hiérarchisée avec un plan à 90 jours chiffré, et ce qui peut attendre sans danger.

Ce livrable garde sa valeur même si vous confiez ensuite la TMA à quelqu’un d’autre. Il évite surtout la situation la plus fréquente : la maintenance démarre, la première mise à jour de store est refusée, et personne n’avait budgété les trois semaines de remise à niveau que ça demande.

CNDP : ce qui doit suivre quand la maintenance change de mains

Une application qui collecte un nom, un numéro de téléphone, une position ou un historique d’achat traite des données personnelles au sens de la loi 09-08. Changer de prestataire ne change pas qui est responsable de traitement : c’est vous. Au moment de la bascule, la déclaration auprès de la CNDP doit refléter la réalité, y compris l’identité du sous-traitant technique qui accède aux données. Les formulaires et la procédure évoluent, donc vérifiez l’état actuel sur le site de la CNDP plutôt que de recopier un modèle de 2022. Le contrat de TMA doit encadrer cet accès : finalité, durée, interdiction de copier la base de production vers un environnement de test non protégé, obligation de notification en cas d’incident.

Il y a enfin le ménage sur les accès de l’ancien prestataire : console Firebase, clés d’API, accès au backend, compte de test sur les stores. Tant qu’ils existent, le risque reste chez vous. Même logique pour les SDK tiers embarqués dans l’application (analytics, outil de crash, notifications push) : ils envoient des données hors du Maroc et doivent apparaître dans votre politique de confidentialité et dans la fiche store.

Questions fréquentes

Faut-il refaire une application Flutter de trois ans ?

Rarement. Un code écrit proprement se remet à niveau en deux à six semaines selon sa taille. La réécriture devient défendable quand l’architecture interdit toute évolution (logique métier dans les widgets, aucun test, gestion d’état incontrôlée) ou quand le besoin fonctionnel a lui-même changé.

Combien de temps faut-il pour reprendre un code Flutter sans documentation ?

Comptez l’audit, puis une période d’appropriation où l’équipe corrige de vraies anomalies au lieu de lire le code. Sur une application de taille moyenne, un prestataire est généralement autonome au bout de quatre à six semaines.

Le développeur initial a disparu avec le keystore Android, que faire ?

Si l’application est inscrite à Play App Signing, vous pouvez demander la réinitialisation de la clé de téléversement depuis la console Play et continuer à publier. Sinon, il faut republier sous un nouvel identifiant d’application, donc perdre les installations, les avis et la note. Vérifiez ce point avant toute négociation.

À quelle fréquence faut-il monter la version de Flutter ?

Une à deux fois par an convient à la plupart des applications de PME, en plus des correctifs de sécurité. L’objectif n’est pas d’être sur la dernière version, mais de ne jamais se retrouver à plus de deux versions majeures de retard.

Un forfait mensuel est-il nécessaire, ou peut-on payer à l’intervention ?

Le paiement à l’intervention fonctionne tant que rien d’urgent n’arrive. Le jour où une publication est refusée, la file d’attente du prestataire passe avant vous. Un forfait, même minimal, achète d’abord un délai de prise en charge.

Chez Arrowlancer, à Casablanca, notre équipe mobile reprend des applications Flutter et React Native existantes : audit de reprise d’abord, puis maintenance avec montées de SDK planifiées, suivi des packages et publications sur les deux stores. Le détail figure sur la page de nos services. Si votre application n’a plus de mainteneur, écrivez-nous via le formulaire de contact avec l’accès au dépôt et le nom sur le store : nous vous dirons ce qui se répare et ce qui se remplace.