Récapitulation et examen final

Dix modules pour passer d'un modèle Keras à une application mobile qui tient dans 2,1 Mo et diagnostique une maladie de plante en 40 ms sur Galaxy A15, sans réseau. Voici le cours condensé, puis les fils qui le traversent, puis l'examen.

Le cours d'un coup d'œil

Module	L'essentiel à retenir
1. Contraintes	Six budgets à chiffrer avant tout code ; la latence perçue compte, pas la latence brute ; percentiles, pas moyenne
2. Conversion	Le prétraitement doit vivre dans le modèle ; les métadonnées évitent des correspondances hardcodées ; SELECT_TF_OPS coûte plusieurs Mo
3. Post-training	Trois recettes : plage dynamique (gain gratuit), int8 complet (le compromis par défaut, exige un jeu représentatif), float16 (pour GPU)
4. QAT	Simule la perte de quantification pendant l'entraînement ; utile quand la perte post-training dépasse un seuil métier ou sur les petits modèles
5. Élagage	Ne réduit que la taille compressée de l'APK, pas le .tflite ; planification progressive obligatoire ; ordre : élaguer → QAT → convertir
6. Interprète et délégués	num_threads=4 est le premier gain gratuit ; le repli sur CPU est silencieux ; choisir le délégué au démarrage sur mesure
7. Android	noCompress "tflite" dans Gradle ; interprète créé une fois ; inférence hors du fil principal ; Task Library pour les cas standard
8. iOS	CoreMLDelegate() peut être nil ; NSCameraUsageDescription explicite ; le Neural Engine s'active à partir de l'A12
9. Mesure	Échauffement obligatoire ; p50/p95/p99, jamais la moyenne ; contrôle thermique change tout après 30 s d'usage soutenu
10. Projet	Tableau des variantes qui trace chaque décision ; test à froid sans réseau ; mise à jour par Firebase avec repli

Les fils qui traversent le cours

Le prétraitement est le premier bogue de production, à toutes les étapes. Le module 2 impose de le mettre dans le modèle, le module 3 insiste sur le type d'entrée (uint8 vs float32), le module 7 le limite au redimensionnement, le module 10 le teste de bout en bout. Chaque fois qu'une transformation vit dans le script d'entraînement mais pas dans l'artefact exporté, c'est une divergence silencieuse qui n'est jamais détectée par une exception, seulement par une dégradation d'exactitude en production. Le test décisif reste le même : le .tflite accepte-t-il exactement ce que l'application enverra ?

Le silence est le pire diagnostic possible. Un int8 avec un jeu représentatif biaisé produit un modèle qui sature, sans erreur (module 3). Un délégué qui ne peut pas exécuter une opération se replie sur CPU sans prévenir (module 6). Un modèle téléchargé qui ne se charge pas remplace silencieusement par le fichier embarqué (module 10). Aucun de ces cas ne produit un journal d'erreur. La discipline est de mesurer après, pas seulement d'espérer que « ça compile ».

La latence n'est pas une moyenne, l'énergie n'est pas une inférence isolée. Les modules 6 et 9 insistent sur les percentiles ; le module 1 et le module 9 sur le contrôle thermique. Un modèle qui satisfait 90 % du temps est un modèle qui fait tomber une inférence sur dix en dehors du budget. Un modèle qui tient 30 ms en pointe et 80 ms sous charge continue n'est pas le même modèle selon l'usage réel.

Le tableau des variantes est l'outil qui remplace les préférences par des décisions. Chaque module l'a rempli, ligne après ligne : taille, latence par appareil, exactitude. À la fin, le choix se lit — 2,1 Mo, int8 QAT avec élagage 60 %, NNAPI/Core ML — et se défend en revue. Un ingénieur qui saute cette étape et « choisit son intuition » ne saura pas expliquer pourquoi la variante A a été retenue plutôt que la variante B.

LiteRT est le nouveau nom, TensorFlow Lite reste le nom usuel. Le renommage de 2024 n'a rien changé aux binaires, aux paquets Android/iOS, ni à l'API publique. Un cours qui parle de LiteRT et un cours qui parle de TensorFlow Lite parlent aujourd'hui de la même chose ; la migration concerne surtout la documentation et les nouveaux dépôts, pas le code existant.

L'examen final

L'examen comporte 40 questions couvrant les dix modules : cadrage des budgets sur mobile (mémoire, latence perçue, énergie, confidentialité), conversion avec TFLiteConverter et gestion des opérateurs non supportés, trois recettes de quantification post-training et rôle du jeu représentatif, choix entre QAT et post-training selon le seuil métier, effet réel de l'élagage sur la taille du fichier compressé, choix et repli de délégués matériels, intégration Android (Task Library, CameraX, cycle de vie de l'interprète), intégration iOS (délégué Core ML, permissions caméra), mesure par percentiles et rôle de l'échauffement, tableau des compromis sur un projet complet.

Plusieurs questions présentent des situations à diagnostiquer : un modèle converti qui produit des prédictions dégradées mais aucune erreur, une latence GPU pire qu'en CPU pur, un .tflite de la même taille malgré 60 % d'élagage, une exactitude qui chute après une seconde conversion, un téléphone d'entrée de gamme qui passe le budget en pointe mais le rate en usage soutenu. C'est le jugement qui est évalué, pas la mémorisation des signatures d'API.

En cas de réussite, votre attestation d'achèvement est délivrée immédiatement ; son numéro est vérifiable par tout tiers sur la plateforme.

Avant de commencer

Pour chaque ligne du tableau récapitulatif ci-dessus, demandez-vous « quel symptôme verrais-je si je me trompais ici ? ». Si vous savez expliquer pourquoi un .tflite élagué à 60 % ne rétrécit pas sans compression, pourquoi un délégué GPU peut être plus lent qu'un CPU pur, et pourquoi la première inférence n'est pas la bonne mesure de latence, vous êtes prêt. Bonne chance !

Examen final

Prêt à valider ce cours ?

40 questions tirées au hasard dans la banque du cours · seuil de réussite 70 % · certificat PDF vérifiable délivré immédiatement en cas de réussite.

Commencer l'examen

Connexion à votre compte InSkillML et abonnement actif requis. Vous pouvez aussi lancer l'examen depuis Mes cours.