Edge AI Offline-First : Déployer des Modèles Complets Sous 10 MB sur Mobile

La plupart des applications mobiles dépendent d’une connexion Internet constante. Déployer l’IA directement sur l’appareil, offline-first et sous 10 MB, est désormais viable en production. Ce guide enseigne quantization, pruning, distillation, frameworks mobiles et architecture sync, avec exemples de Sarvam Edge (speech multilingue) et FLEXI (wearable ultra-efficace).

• 10 MB est le point d’équilibre pour fonctionner offline sur 95 % des téléphones
• Quantization INT8 réduit la taille de 75 % en moyenne avec pruning structuré pour un ratio 10x
• CoreML pour iOS, TFLite pour Android, ONNX Runtime Mobile pour cross-platform
• Architecture offline-first nécessite stockage local et synchronisation avec résolution de conflits
• Sarvam Edge et FLEXI démontrent viabilité production avec contraintes extrêmes

Pourquoi Cibler Moins de 10 MB ?

Les contraintes justifiant cette limite stricte sont rarement explicitées, mais réelles. Un téléphone de gamme moyenne affiche 3–4 GB de RAM théorique, mais une application n’en récupère que 100–500 MB en pratique. Une montre connectée propose 512 MB ou moins. Un modèle de 200 MB réduit d’autant l’espace disponible pour données utilisateur, cache et services système — un coût caché insupportable à l’usage.

Un modèle de 50 MB prend 1–2 secondes à charger en RAM au lancement. Tolérable pour vidéo, intolérable pour reconnaissance vocale instantanée. À chaque fermeture ou réouverture de l’application, ce modèle se recharge ; la batterie s’épuise progressivement.

10 MB est le point d’équilibre où une application critique fonctionne offline sur 95 % des téléphones en circulation, et où la batterie reste utilisable plus de 12 heures même avec inférence continue.

Sarvam Edge : Speech Recognition Multilingue

Lancé le 14 février 2026 par Sarvam AI, Sarvam Edge atteint 294 MB — déjà un exploit pour reconnaissance vocale. Il supportent 10 langues indiennes et surpassent Google Cloud STT sur ces langues en accuracy.

Pourquoi 294 MB ? La parole implique analyse spectrale haute fréquence, vocabulaires multiples et accents régionaux, modèles phonétiques complexes. Limitation : 80 % des indiens utilisent des téléphones <₹15,000 (~$180) ; Sarvam Edge reste hors portée pour la masse. Enseignement : multilingue offline exige souvent >10 MB ; c’est un trade-off accepté quand l’enjeu justifie.

FLEXI : Wearable Ultra-Efficace

FLEXI (janvier 2026, recherche Tsinghua/Peking) est une puce IA flexible, plus fine qu’un cheveu, résistant à 40 000+ cycles de flexion. Elle consomme <1 % de l'énergie des puces rigides. Application : monitoring santé (arythmies 99,2%, activité 97,4%). Implication cruciale : données sensibles sur-device = privacy par défaut, zéro transmission. Enseignement : l’ultra-basse énergie nécessite quantization extrême et pruning agressif.

Les Trois Piliers de la Compression : Quantization, Pruning, Distillation

Avant framework ou architecture, vous devez réduire votre modèle. Ces trois techniques forment l’épine dorsale.

Quantization : Réduire la Précision Numérique

Un modèle entraîné utilise des nombres flottants 32 bits : chaque poids occupe 4 bytes. Réduire à 8 bits entiers (INT8) divise l’espace par 4. Réduire à 4 bits (INT4) le divise par 8. La perte d’accuracy ? Minimale si bien exécutée.

TensorFlow et PyTorch fournissent des outils pour quantization post-training : mesurer l’étendue des poids et activations, créer une table de mappage, puis compresser. Un modèle Keras d’origine 12,52 MB, après quantization INT8 dans TensorFlow Lite : 0,60 MB — ratio 20x, avec accuracy préservée.

Si la perte d’accuracy dépasse le tolérable, utilisez Quantization-Aware Training (QAT) : réentraînez le modèle en simulant la quantization. Le modèle apprend à compenser les écarts de précision. Coût : 2–3x le temps d’entraînement standard. Résultat : accuracy bien supérieure, pour un surcoût acceptable.

Pruning : Supprimer les Poids Inutiles

Pendant entraînement, un réseau apprend des milliers de connexions ; beaucoup sont redondantes : poids proches de zéro, neurones dupliqués. Le pruning magnitude-based supprime tous les poids dont la valeur absolue reste sous un seuil (typiquement 30–50% des plus petits). Le modèle reste précis, mais la matrice devient très creuse, comprimable avec gzip. Résultat documenté : réduction facteur 10, sans perte majeure.

Le pruning structuré élimine des canaux ou filtres entiers au lieu de poids individuels. Bénéfice : compatibilité GPU mobile. Ordre d’application : pruning avant quantization. Pourquoi ? Quantization change la distribution des poids ; pruner après tue le calibrage.

Knowledge Distillation : Le Modèle Étudiant

Vous avez un grand modèle entraîné (le « professeur »). Créez un petit modèle (l’« étudiant »), et entraînez-le à imiter les sorties du professeur. DistilBERT en est l’exemple célèbre : 40 % de la taille de BERT, 97 % de sa performance.

La distillation prend du temps, mais une fois terminée, vous avez un modèle petit et robuste. Utilisez-la si vous partez d’un modèle pré-entraîné large et disposez de budget GPU.

Ordre d’application : Quantization post-training (rapide) → évaluation accuracy. Si acceptable, passez au framework. Si non, appliquez QAT ou pruning structuré. Pour ultra-petit (<10 MB), utilisez la cascade complète : pruning + quantization + distillation.

Choisir le Framework : iOS, Android, Cross-Platform

Votre modèle comprimé doit fonctionner sur l’appareil. Le choix dépend plateforme cible et flexibilité.

CoreML pour iOS

Apple CoreML est intégré nativement iOS. Exécution extrêmement rapide sur A-series et M-series, intégration transparente Vision et Sound Analysis, compilation automatique pour hardware disponible. Limitation : verrouillage écosystème Apple, pas de support simple Android/web. Conversion : PyTorch → ONNX → TensorFlow Lite → outil Apple (coremltools), environ 30 lignes Python.

TensorFlow Lite pour Android

Google TensorFlow Lite est conçu spécifiquement mobile. Choix par défaut Android, accélération GPU via NNAPI et Qualcomm Hexagon DSP, écosystème immense et documentation excellente. Limitation : principalement optimisé Android, version iOS plus lente.

ONNX Runtime Mobile pour Cross-Platform

Microsoft ONNX Runtime Mobile est open-source et multiplateforme. Convertir une fois en ONNX, compiler pour n’importe quelle plateforme (Android, iOS, embarqué, serveur edge). Flexibilité immense. Compromis : légèrement moins performant qu’une solution native, mais la flexibilité compense largement.

Critère	CoreML	TFLite	ONNX Runtime
Performance	Excellente (Apple Silicon)	Très bonne	Bonne
Plateforme	iOS uniquement	Android principal	Cross-platform
Verrouillage fournisseur	Élevé	Modéré	Bas
Courbe apprentissage	Douce	Douce	Moyenne
Latence inférence	<10 ms souvent	10–30 ms	15–40 ms

Architecture Offline-First : Stockage Local + Synchronisation

Votre modèle tourne sur l’appareil. Désormais, stockez les données localement et synchronisez à reconnexion.

Stockage Local

iOS : Core Data (abstraction, réseau natif) ou SQLite (contrôle bas niveau).

Android : Room (wrapper SQLite, type-safe) ou SQLite brut.

Cross-plateforme : WatermelonDB, RxDB, Drift.

Préférez une abstraction pour éviter bugs concurrence. Performance SQLite moderne : ~1 000 requêtes/seconde sans problème.

Stratégie de Synchronisation : Change Log

Offline, l’app crée ou modifie données localement. À reconnexion, pousse changements au serveur. Chaque changement local est enregistré dans une file. À reconnexion, bouclez sur la file et appliquez chaque changement.

Une stratégie alternative, timestamp-based sync, stocke le timestamp de la dernière synchronisation. À reconnexion, fetch du serveur tous les changements depuis `lastSyncTime`, fusionnez avec les changements locaux, poussez les changements locaux, mettez à jour `lastSyncTime`. Cas d’usage : données fortement changeantes. Exigence : résolution conflits sophistiquée.

Résolution de Conflits

Vous modifiez un champ offline ; entre-temps, le serveur change ce champ aussi. Qui gagne ?

Last-Write-Wins (LWW) : le changement le plus récent gagne. Simple, souvent suffisant.

Server-Wins : le serveur a toujours raison. Sûr pour données critiques.

CRDT (Conflict-free Replicated Data Types) : structure de données résolvant automatiquement conflits sans arbitrage central. Exemple : Yjs (open-source). Complexe mais puissant pour collaboration temps-réel.

Mises à Jour Optimistes

N’attendez pas le serveur. À création locale, assignez ID temporaire et montrez immédiatement à l’utilisateur. Synchronisez en arrière-plan. Si échec, affichez erreur et proposez retry.

Test Offline Avant Déploiement

Beaucoup d’apps cassent instantanément sans connexion.

Simulation Réseau

Android : Configuration émulateur (Simulate throttle).

iOS : Network Link Conditioner (tool Apple, gratuit).

Trois états à tester : entièrement offline, latence élevée (1–5 secondes), perte paquets (10–30 %).

Profiling Batterie & Mémoire

iOS : Xcode Instruments (Energy Impact, Memory).

Android : Android Profiler.

Critères acceptables : modèle <10 MB inférence continue : <5–10 mAh/heure.

Test de Cohérence Offline-to-Sync

Cas critique : créez tâche offline, fermez app, reconnectez, rouvrez app. La tâche doit toujours exister, marquée « synced ». Cas avancé : créez 50 tâches offline, modifiez 20, supprimez 5, reconnectez avec conflit réseau. Vérifiez : aucune tâche perdue, ordre final cohérent.

Déploiement & Monitoring

Modèle en production : tracker accuracy, latence, consommation, crashes.

Versioning & Mises à Jour OTA

Les modèles dérivent avec le temps. Prévoir mise à jour sans app update (OTA). Gardez toujours 2–3 versions antérieures. Nouvelle version chute accuracy ou énergie ? Rollback en 1 minute.

Décision mise à jour : accuracy drift >2 %, feedback utilisateur négatif, crash rate >0,5 %.

Métriques Clés

Métrique	Cible	Notes
Latence inférence (p50, p95)	<50 ms, <100 ms	Sur device réel
Accuracy	Maintenir >98 %	Par segment utilisateur
Énergie	<10 mAh/1000 inférences	Wearable : <5
Crash rate	<0,5 % sessions	Monitorer OOM, timeouts
User feedback	Rating ≥4/5	Commentaires utilisateur

Dashboards recommandés : Datadog, AWS CloudWatch, Google Firebase.

Pièges Courants et Limitations

Quantization sans test rigoureux : résultat, accuracy silencieuse écrasée. Toujours valider sur device réel, pas émulateur.

Offline ≠ pas de synchronisation : les données doivent se synchroniser ; conflits arrivent. Planifier résolution conflits à l’avance.

Émulateur ≠ device réel : profiling batterie en émulateur c’est une illusion. Tester sur hardware réelle.

Sarvam Edge / FLEXI ≠ votre modèle : leurs optimisations sont domaine-spécifiques. Ne pas assumer transférabilité directe.

Contrats latence : si l’app promet <100 ms inférence, et quantization + device donne 150 ms, vous avez un problème. Tester tôt, itérer, ou accepter trade-off.

Checklist : De la Compression au Déploiement

• Quantization INT8 appliquée, perte accuracy <2 % sur benchmark.
• Pruning combiné si target <50 MB.
• Distillation si modèle pré-entraîné large disponible.
• Framework choisi (CoreML/TFLite/ONNX) et conversion validée.
• Local storage implémenté (Room/Core Data/SQLite).
• Sync strategy codée (change-log ou timestamp-based).
• Conflit resolution testée.
• Offline test complet (création, modification, sync).
• Battery profiling sur device réel : <10 % dégradation acceptable.
• Latence inférence <acceptable threshold pour UX.
• Monitoring dashboard configuré.
• Rollback plan écrit.
• Documentation architecture pour équipe.

Conclusion

Edge AI offline-first n’est pas science-fiction. Avec quantization ciblée, pruning intelligent, choix framework adapté et architecture sync soignée, vous pouvez déployer des modèles puissants sous 10 MB sur n’importe quel téléphone, avec ou sans internet.

Sarvam Edge et FLEXI prouvent que le faisable pousse les limites chaque trimestre. Mais là où ils excellent, speech multilingue et wearable ultra-basse puissance, les principes restent identiques : compression → conversion → test rigoureux → monitoring continu.

Commencez petit, mesurez réel, itérez. L’offline-first n’est plus une exception ; c’est l’attente utilisateur.

FAQ

Combien d'espace faut-il pour un modèle IA offline sur téléphone ?

10 MB est le seuil critique : assez petit pour 95 % des téléphones, assez grand pour supporter des tâches complexes (reconnaissance vocale, détection anomalies).

Quelle technique de compression réduit le plus la taille d'un modèle IA ?

La quantization INT8 réduit la taille de 75 % en moyenne ; associée au pruning structuré, vous atteindrez un ratio 10x sans perte majeure d’accuracy.

Quel framework choisir pour Edge AI multiplateforme : CoreML, TFLite ou ONNX ?

CoreML pour iOS pur (meilleure performance) ; TFLite pour Android ; ONNX Runtime Mobile pour cross-platform unifié.

Comment synchroniser les données offline vers le serveur sans perdre d'informations ?

Utilisez un change-log local ou timestamp-based sync avec résolution de conflits explicite (Last-Write-Wins, Server-Wins, ou CRDT).

Quelle est la consommation batterie acceptable pour l'inférence continue sur wearable ?

<10 mAh par heure ; FLEXI démontre <1 % de l'énergie des puces rigides classiques.