Récapitulation et examen final

Dix modules pour passer de « pip install streamlit » à un tableau de bord de scoring de résiliation déployé, sécurisé et utilisable par une équipe commerciale. Voici le cours condensé, les fils qui le traversent, puis l'examen.

Le cours d'un coup d'œil

Module	L'essentiel à retenir
1. Premiers pas et exécution	Script réexécuté du haut à chaque interaction ; set_page_config doit être la première ligne Streamlit
2. Composants	Une dizaine de composants suffit ; delta_color="inverse" évite d'annoncer une mauvaise nouvelle en vert
3. Mise en page	Cinq conteneurs : colonnes, onglets, expandeurs, conteneurs libres, barre latérale ; les onglets n'économisent pas le calcul
4. Graphiques et tableaux	Natifs pour le rapide, Plotly pour l'interactif, Altair pour le statistique ; use_container_width=True presque toujours
5. Cache	cache_data copie, cache_resource partage ; un modèle mis en cache par cache_data est un contresens
6. État et formulaires	session_state fait persister ; un form diffère les réexécutions jusqu'à la soumission
7. Téléversement et téléchargement	Valider avant de traiter, st.stop() en cas d'erreur ; la limite par défaut est 200 Mo
8. Appel de modèle	timeout obligatoire sur toute requête HTTP ; cache_resource autour de joblib.load
9. Thème et ergonomie	Quatre couleurs dans config.toml suffisent ; une seule action principale par écran
10. Déploiement et accès	Secrets dans .streamlit/secrets.toml, jamais dans le code ; hmac.compare_digest pour un mot de passe

Les fils qui traversent le cours

Le modèle d'exécution explique presque tout. À chaque interaction, le script est relancé du haut. C'est cette seule idée qui explique pourquoi un compteur naïf reste à 1, pourquoi un score disparaît quand on touche un curseur, pourquoi il faut un cache pour ne pas relire un modèle à chaque clic, pourquoi les formulaires existent, pourquoi les onglets ne réduisent pas le calcul. Comprendre ce mécanisme, c'est disposer d'un modèle mental qui rend les autres modules déductibles plutôt que mémorisables.

Ce qui persiste, ce qui se recalcule. Le cache et l'état de session sont deux réponses à la même question — que faire durer d'une exécution à l'autre. Le cache concerne les résultats de fonctions, partagés entre sessions, et sert la performance. L'état de session concerne les valeurs de l'utilisateur courant, isolées par session, et sert l'ergonomie. Confondre les deux mène soit à des recalculs inutiles, soit à des contaminations entre utilisateurs.

Les entrées non maîtrisées se valident avant de servir. Un fichier téléversé, un appel HTTP, un formulaire soumis sont trois portes ouvertes sur des données que l'application n'a pas produites. Chaque module qui touche à l'une de ces portes rappelle la même règle : valider explicitement, arrêter proprement en cas d'échec, afficher un message utile. Les applications qui traînent des bogues difficiles à diagnostiquer sont presque toujours celles qui ont sauté cette étape.

Le développement s'arrête à la mise en ligne, pas avant. Un tableau de bord qui vit seulement sur un portable n'est pas un livrable. Les secrets, le thème, le contrôle d'accès et les limites de concurrence ne sont pas des embellissements de fin de projet : ce sont les éléments qui font qu'une application est adoptée ou rejetée. Le module 10 s'intègre à la conception dès le premier jour, pas au dernier.

L'examen final

L'examen comporte 40 questions couvrant les dix modules du cours : modèle d'exécution et conséquences pratiques, choix des composants de saisie et d'affichage, structure d'une page en colonnes et onglets, choix de la bonne famille de graphique, différence entre cache_data et cache_resource et pièges d'invalidation, usage correct de session_state et des formulaires, validation d'un fichier téléversé et scoring en lot, appel de modèle local ou distant avec gestion des erreurs, thème et ergonomie, et enfin déploiement et contrôle d'accès.

Plusieurs questions présentent des situations à diagnostiquer : un compteur qui reste bloqué à 1, un modèle rechargé à chaque clic, un score qui disparaît, une clé d'API qui figure dans un commit, une API qui pend l'application. C'est le jugement qui est évalué, pas la récitation de signatures de fonctions.

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

Reprenez le tableau ci-dessus et, pour chaque ligne, demandez-vous « comment verrais-je que je me trompe ici ? ». Si vous savez dire pourquoi un compteur naïf reste à 1, pourquoi un modèle passé à cache_data recopie de la mémoire pour rien, pourquoi un timeout sur requests.post est non négociable, et où se met un mot de passe qu'on n'a pas envie de retrouver sur GitHub, 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.