Récapitulatif et examen final
Dix modules pour transformer une fonction Python en démonstration publique cliquable depuis un lien Hugging Face. Voici le cours condensé, puis les fils qui le traversent, une comparaison avec Streamlit et les modalités de l'examen final.
Le cours d'un coup d'œil
| Module | L'essentiel à retenir |
|---|---|
| 1. Interface | gr.Interface(fn, inputs, outputs) en dix lignes ; title, description, article dès le premier lancement |
| 2. Composants | type de gr.Image (numpy, pil, filepath) et gr.Audio (couple fréquence + tableau) est un contrat, pas un détail |
| 3. Blocks | Trois étapes : déclarer, disposer, brancher ; gr.State conserve par session, jamais par utilisateur global |
| 4. Chat | gr.ChatInterface(fn, type="messages") en deux lignes ; consigne système fixe rôle, langue, longueur, comportement en cas de doute |
| 5. Diffusion | Un générateur (yield) déclenche la diffusion ; rendre la réponse accumulée, pas le seul nouveau fragment |
| 6. Exemples | Choisir un cas typique, un cas limite, un hors domaine ; cache_examples=True pour modèle déterministe, jamais pour API payante |
| 7. File d'attente | default_concurrency_limit : 1-2 pour GPU, 20+ pour API distante ; max_size refuse explicitement |
| 8. Partage temporaire | share=True = tunnel 72 h ; auth par HTTP Basic ; ne pas dépasser cette portée sans un vrai hébergement |
| 9. Space Hugging Face | Trois fichiers (app.py, requirements.txt, README.md) ; secrets dans Settings, jamais dans le code ; /data/ pour la persistance |
| 10. Projet | Assistant complet avec diffusion, retours (.like), coût (include_usage), limites affichées dans le README.md |
Les fils qui traversent le cours
Le type Python reçu par votre fonction est un contrat. C'est vrai des composants d'entrée (gr.Image(type="pil") livre du PIL, type="numpy" livre un tableau), c'est vrai des composants de sortie (gr.Label attend un dictionnaire probabilité par étiquette), c'est vrai de l'historique dans gr.ChatInterface (liste de dictionnaires en mode messages, liste de tuples en mode tuples). La moitié des erreurs des débutants se règle en lisant précisément ce que le composant transmet et ce qu'il attend.
La perception vaut la performance. Les modules 5 (diffusion) et 7 (file d'attente) partagent la même idée : la latence médiane ne suffit pas à mesurer la qualité, ce qui compte est ce que l'utilisateur voit. Un flux de réponse jeton par jeton et une position d'attente affichée transforment une expérience mauvaise en expérience acceptable, sans changer d'un iota le temps réel de calcul. Cet arbitrage est plus fondamental que toute optimisation micro du code.
Les secrets ne sont jamais dans le code. C'est répété au module 4 (variable d'environnement), au module 8 (auth basic sur un lien partagé), au module 9 (Repository secrets d'un Space), au module 10 (os.environ en tête de app.py). Un git push malencontreux qui expose une clé d'API se paie en factures frauduleuses le lendemain. Cette discipline n'est pas de la paranoïa, c'est un coût zéro qui évite un incident coûteux.
Une démonstration honnête est plus efficace qu'une démonstration marketing. Les exemples du module 6 doivent inclure un cas limite ; les limites du module 10 (hallucination, coupure de connaissance, latence, coût, oubli) doivent être affichées dans le README.md. Un utilisateur qui découvre les limites au premier essai devient utilisateur régulier ; un utilisateur qui les découvre plus tard, en croyant la démonstration parfaite, la déserte définitivement.
Gradio contre Streamlit (cours 38)
Les deux bibliothèques ont un objectif proche — construire une interface web depuis Python — et une philosophie très différente. Streamlit est un framework applicatif : le script est réexécut é du haut en bas à chaque interaction, l'état est reconstruit à chaque fois, et le développeur pense en termes de « widgets qui déclenchent une réexécution ». Gradio est une bibliothèque de démonstrations : la fonction est appelée en réponse à un événement précis, l'état reste hors de la fonction, et le développeur pense en termes de « fonction Python que je vais exposer ».
| Critère | Gradio | Streamlit |
|---|---|---|
| Cas d'usage naturel | Démonstration d'un modèle IA | Tableau de bord de données |
| Fonction cible | Une fonction avec des entrées et une sortie | Un script complet |
| Composant chatbot natif | Oui (gr.ChatInterface) | Non (à construire) |
| Diffusion progressive | Native via générateurs Python | Possible via st.write_stream |
| Déploiement gratuit | Spaces Hugging Face intégré | Streamlit Community Cloud |
| Interface publique standard | Plutôt neutre, sobre | Plutôt épuré, cadré |
| Interactivité fine (lignes, colonnes) | gr.Blocks verbeux mais expressif | Native mais moins riche |
| État persistant | gr.State par session, /data/ sur Space | st.session_state par session |
En pratique : pour montrer un modèle avec entrée-sortie, Gradio gagne d'une longueur. Pour construire un tableau de bord d'exploration de données avec plusieurs filtres et graphiques, Streamlit est plus naturel. Le choix est donc dicté par le cas d'usage, pas par la préférence de bibliothèque.
Arbre de décision : quel outil pour quelle démo
- Un modèle, une entrée, une sortie →
gr.Interface(module 1) - Un modèle, entrées ou sorties multiples avec mise en page →
gr.Blocks(module 3) - Un assistant conversationnel →
gr.ChatInterface(module 4) - Une génération longue → générateur avec
yield(module 5) - Une démonstration à charge modérée →
demo.queue()avec limite adaptée (module 7) - Montrer 3 h à des collègues →
share=Trueavecauth(module 8) - Rester en ligne 24/7 avec URL stable → Space Hugging Face (module 9)
- Modèle GPU à trafic modéré → Space avec Zero GPU (module 9)
- Collecter des retours utilisateurs →
chatbot.likevers/data/(module 10)
L'examen final
L'examen comporte 40 questions couvrant les dix modules : traduction d'une fonction en gr.Interface, choix de composants et compréhension du type reçu, construction d'un gr.Blocks avec lignes, colonnes et événements, assemblage d'un gr.ChatInterface avec consigne système, activation de la diffusion progressive par générateurs, choix et mise en cache d'exemples, réglage de la file d'attente et de la concurrence, portée et limites du lien de partage temporaire, publication sur un espace Hugging Face avec secrets et matériel, et diagnostic d'une démonstration en production.
Plusieurs questions présentent des situations à diagnostiquer : une image reçue en NumPy alors que le modèle attend du PIL, un générateur qui rend le fragment courant au lieu de la réponse accumulée, une consigne système absente qui produit des réponses en anglais, une file d'attente à concurrence 4 qui divise la latence par deux au lieu de la préserver, un share=True sans auth qui expose une clé d'API. C'est le jugement qui est évalué, pas la récitation des noms de paramètres.
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.
Reprenez l'arbre de décision ci-dessus et, pour chaque ligne, demandez-vous « comment expliquerais-je ce choix à un collègue ? ». Si vous savez dire pourquoi la diffusion ne réduit pas la latence réelle, pourquoi cache_examples=True est mauvais sur une API payante, pourquoi une clé d'API ne va jamais dans un git push, et pourquoi une démonstration honnête sur ses limites est plus efficace qu'une démonstration marketing, 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'examenConnexion à votre compte InSkillML et abonnement actif requis. Vous pouvez aussi lancer l'examen depuis Mes cours.