~/teaching · machine learning · outils, mercredi 14 octobre 2026

Kaggle, GitHub et Python : les comptes, le travail avec Git et le dépôt d'un projet de machine learning

S'entraîner sur Kaggle, rendre sur GitHub, écrire en Python, une mise en place courte et pratique avant le premier modèle.

Sitraka Forler, Centrale Méditerranée

Révision 16 octobre 2026 · environ 17 minutes

Résumé

Ce deck se place entre l'introduction et la première séance mathématique du cours de Machine Learning de Centrale Méditerranée (option DDEFI, 2026-2027). Ce n'est pas un cours de Git. Son but est plus étroit et plus concret, chaque étudiant repart avec un compte Kaggle, un compte GitHub, un Python qui fonctionne et une idée précise de ce que contiendra le dépôt du projet final.

Le principe directeur est la reproductibilité (reproducibility). Un projet de machine learning n'est pas un fichier envoyé par e-mail : c'est un dépôt public que quelqu'un d'autre peut lire, relancer sur une machine vierge et juger. Kaggle fournit des données propres, une machine gratuite et un classement honnête pour s'exercer. GitHub garde le code, son historique et les échanges de l'équipe. Python, avec pandas, scikit-learn et XGBoost, est la langue commune.

Après cette lecture, vous saurez entrer dans une compétition Kaggle et comprendre sa métrique, dérouler le cycle Git de chaque jour, travailler à trois avec des branches et des pull requests, garder secrets et gros fichiers hors du dépôt, et organiser un projet pour qu'une seule commande reconstruise tous les résultats.

Les slides

Kaggle, GitHub, Python : vos outils, vos comptes, votre dépôt

Outils, mercredi 14 octobre 2026. Machine Learning, Centrale Méditerranée, option DDEFI, 2026-2027.

Ouvrir les slides (mot de passe donné par l'enseignant)

Le deck lui-même est chiffré pour les élèves du cours ; cette page le résume pour tous.

La page du cours · L'attention et le transformer, pas à pas

Plan du deck

Pourquoi ces outils. Le projet final vit dans un dépôt public, qui sert aussi de ligne de CV vérifiable.
Kaggle. Le compte, l'anatomie d'une compétition, les deux compétitions bonus, les notebooks hébergés, les deux classements et les cours courts.
Télécharger depuis le terminal. Le client en ligne de commande, et pourquoi son jeton est un secret.
Git et GitHub. L'outil et le site, les dix mots du vocabulaire, le graphe des commits et le compte.
Travailler à trois. Le dépôt de l'équipe, le cycle quotidien, une branche par tâche, la relecture, les conflits et les notebooks sous Git.
Le dépôt du projet. Ce qu'on ne commit jamais, l'arborescence, le README, le cahier des charges, les batchs, les issues et la page en ligne.
Python. Les cinq bibliothèques du cours, trois niveaux de départ et trois façons de l'installer.
À faire maintenant. Une liste, en salle, le soir même, puis avant le lendemain matin.

Pourquoi tout le projet vit dans un dépôt public

Un projet qui ne tourne que sur l'ordinateur de son auteur ne prouve rien ; le livrable, c'est un dépôt public que n'importe qui peut relancer, et qui montre votre travail.

Les trois outils ont trois rôles distincts. Kaggle est la salle d'entraînement : des données déjà nettoyées, une machine hébergée, un classement pour se mesurer aux autres. GitHub est à la fois le chantier et la vitrine : le code, tout son historique, les relectures et, à la fin, la livraison complète. Python est la langue que tout le monde écrit, quel que soit son point de départ. Les trois sont gratuits.

Le projet final se rend sous la forme de l'adresse d'un dépôt (repository) public, pas d'une pièce jointe. Ce dépôt contient cinq choses : un cahier des charges (scope document) écrit avant le code, des modules Python lisibles plutôt qu'un notebook géant, des scripts qui relancent tout, la présentation (PDF et source), et une petite interface web où l'on saisit un cas et où le modèle répond. Un projet de mi-parcours sur un jeu de données UCI suit la même structure et sert de gabarit.

Un dépôt public est aussi une ligne de CV qui se vérifie. Le rapport Octoverse de GitHub (octobre 2025) comptait plus de 180 millions de développeurs, 36 millions de nouveaux comptes sur la seule année 2025 et environ 630 millions de dépôts, avec 2,6 millions de contributeurs Python. Un recruteur qui ouvre votre dépôt y passe en général deux minutes et cherche ce que chercherait tout lecteur exigeant :

un README qui dit en quelques lignes ce que fait le projet et comment le lancer ;
un historique régulier, dont les messages de commit expliquent pourquoi, pas seulement « fix » ;
quelques tests et une commande qui les lance ;
des résultats honnêtes et chiffrés, avec la méthode d'évaluation ;
aucun secret, aucune donnée personnelle, aucun fichier énorme.

Remarque (Pourquoi une équipe de trois). Trois, c'est la taille d'une petite équipe de livraison en entreprise, une personne écrit, une relit, une parle au client, et les rôles tournent. Au-delà, quelqu'un finit par disparaître derrière les autres (l'effet Ringelmann vu en introduction). Écrire le guide du dépôt pour deux coéquipiers est le moyen le plus rapide de l'apprendre soi-même.

Retour au sommaire.

Kaggle : compétitions, métriques et les deux classements

Une compétition Kaggle donne des données d'apprentissage avec les réponses, des données de test sans, une métrique et un classement ; celui qui compte reste caché jusqu'à la fin.

Kaggle est né en 2010 comme place de marché pour des concours de prédiction, et Google l'a racheté en mars 2017 en y ajoutant des notebooks hébergés avec GPU. Son compteur affichait plus de 34 millions de membres le 11 octobre 2026. Chaque page de compétition a les mêmes parties : une présentation (problème, métrique, format de soumission), les données (train.csv avec la cible, test.csv sans, et un exemple de soumission), les notebooks publics, le classement et le règlement, qui fixe un nombre de soumissions par jour.

Titanic, une classification mesurée par l'exactitude

La compétition Titanic demande quels passagers ont survécu : 891 passagers étiquetés pour apprendre, 418 à prédire, et un CSV à deux colonnes (PassengerId,Survived) à soumettre. La métrique est l'exactitude (accuracy), la part de bonnes réponses. Le fichier de référence fourni par Kaggle, qui prédit simplement que toutes les femmes survivent, obtient déjà 0,766 ; un modèle honnête se situe vers 0,78 à 0,80.

\text{exactitude} = \frac{1}{n}\sum_{i=1}^{n} \mathbf{1}\{\hat y_i = y_i\}

(1)

House Prices, une régression mesurée sur le logarithme

House Prices reprend le jeu de données d'Ames (Iowa) construit par Dean De Cock (Journal of Statistics Education, 2011) pour remplacer l'ancien Boston housing : 1 460 maisons pour apprendre, 1 459 à prédire, 79 variables, et des valeurs manquantes qui ont un sens (pas de garage, pas de piscine). La métrique est la racine de l'erreur quadratique moyenne entre les logarithmes des prix prédits et observés : elle mesure donc une erreur relative.

\text{RMSE}_{\log} = \sqrt{\frac{1}{n}\sum_{i=1}^{n}\left(\log \hat y_i - \log y_i\right)^2}

(2)

**Tableau 1 :** Pourquoi le logarithme compte, trois maisons d'illustration. Surestimer de 10 % coûte autant sur une maison bon marché que sur une maison chère, alors que l'erreur au carré en dollars serait seize fois plus grande sur la seconde.
Maison	Prix observé	Prix prédit	Erreur en dollars	Erreur en log
A	100 000	110 000	+10 000	+0,095
B	400 000	440 000	+40 000	+0,095
C	200 000	180 000	-20 000	-0,105

Sur ces trois maisons, la métrique vaut $\sqrt{(0.095^2 + 0.095^2 + 0.105^2)/3} \approx 0.099$ . Pour se repérer, le deck donne des ordres de grandeur sur la vraie compétition : prédire la moyenne donne environ 0,40, une régression linéaire propre environ 0,15, un ensemble d'arbres bien réglé environ 0,12. Cette échelle, un modèle de référence (baseline) naïf, un modèle meilleur, puis un modèle lourd, comparés sur les mêmes données jamais vues, est le fil de tout le cours.

Classement public et classement privé

Le jeu de test est coupé en deux. La part publique est notée après chaque soumission ; la part privée n'est révélée qu'à la clôture. Régler sans fin son modèle sur le classement public (public leaderboard), c'est surapprendre sur quelques centaines de lignes, et le classement privé le sanctionne. La seule défense est une validation interne, construite sur les données d'apprentissage. Sur le Titanic, des scores parfaits de 1,000 existent parce que la liste des passagers est publique : c'est une fuite de données (data leakage), pas un modèle, et le cours apprend à la reconnaître dès la séance 2.

Les notebooks Kaggle sont des sessions Jupyter hébergées, avec les données déjà montées et un quota hebdomadaire de GPU ; « Copy & Edit » garde le lien vers l'original, la façon loyale de partir du travail des autres. Kaggle Learn ajoute quatre cours gratuits et courts, environ seize heures au total.

Retour au sommaire.

Git n'est pas GitHub : l'outil, le site et dix mots

Git est un programme sur votre ordinateur qui enregistre chaque état d'un projet ; GitHub est un site qui héberge ces enregistrements et ajoute ce qu'il faut pour travailler en équipe.

Linus Torvalds a écrit Git en avril 2005 pour le noyau Linux, après que l'outil utilisé jusque-là a perdu sa licence gratuite. Git tourne en local, hors ligne, sans compte : il enregistre qui a changé quoi, quand et pourquoi. GitHub, lancé en 2008 et racheté par Microsoft en 2018, héberge des dépôts Git et y ajoute pull requests, issues, relectures, pages web et actions automatiques. GitLab, Codeberg et Bitbucket font un travail voisin ; le cours utilise GitHub.

Le problème que Git résout est connu de quiconque a partagé un dossier : model_v2_final.ipynb, model_v2_final_REAL.ipynb, et personne ne sait quelle version marche ni qui a changé la métrique. Sous Git, il y a un seul fichier et une liste d'états datés et signés, chacun avec une ligne qui dit ce qui a changé et pourquoi. Tout état peut être rouvert, comparé au précédent ou proprement annulé.

**Tableau 2 :** Le vocabulaire qui suffit pour lire n'importe quel tutoriel Git. Les mots anglais restent en anglais, car ce sont les noms des commandes et des menus.
Mot	Sens
dépôt (repository)	le dossier du projet avec tout son historique
commit	un état enregistré, avec un auteur, une date et un message
branche (branch)	un fil de développement séparé du fil principal, appelé `main`
fusion (merge)	intégrer le travail d'une branche dans une autre
pull request	la proposition, sur GitHub, d'intégrer une branche, soumise à la relecture
clone	une copie locale d'un dépôt distant
push / pull	envoyer ses commits vers GitHub / récupérer ceux des coéquipiers
fork	votre propre copie, sur votre compte, d'un dépôt qui appartient à un autre
issue	un ticket numéroté (tâche, bogue ou question) confié à une personne
README	la page d'accueil du dépôt, écrite en Markdown

Imaginez le graphe des commits, le temps allant de gauche à droite. Sur main : l'initialisation, le cahier des charges, le modèle de référence. Une branche (branch) part essayer un modèle plus lourd et revient par une fusion (merge), une fois la pull request relue par un coéquipier. Une étiquette (tag) peut marquer le commit livré. La règle d'équipe qui en découle est simple : `main` doit toujours fonctionner ; tout ce qui est incertain se fait sur une branche.

Choisissez le nom d'utilisateur GitHub avec soin, car il figurera dans l'adresse de chaque projet et sur votre CV, et activez la double authentification en rangeant les codes de secours en lieu sûr.

Retour au sommaire.

Le cycle quotidien, une branche par tâche, et les conflits

Chaque jour de travail suit les mêmes quatre gestes, pull, modifier, commit, push, et chaque tâche vit sur sa propre branche jusqu'à ce qu'un coéquipier l'ait relue.

Un membre de l'équipe crée le dépôt, public dès le premier jour, avec un nom court en minuscules et tirets, un README, le modèle .gitignore Python et une licence, puis invite les autres comme collaborateurs. La licence est l'étape oubliée : sans elle, un dépôt public est « tous droits réservés », lisible mais pas réutilisable. MIT est le choix le plus simple pour un projet étudiant.

Les quatre gestes du quotidien

Pull. Récupérer ce que les coéquipiers ont poussé avant de toucher à quoi que ce soit ; la plupart des ennuis de débutant viennent d'un pull oublié.
Modifier et vérifier. Changer une seule chose, puis lancer git status pour voir exactement ce qui a bougé.
Commit. N'ajouter que les fichiers qui vont ensemble et écrire un message qui dit pourquoi, pas seulement quoi.
Push. Mettre le commit en ligne pour que les autres puissent s'appuyer dessus.

git pull                      # partir du dernier état de l'équipe
git status                    # ce qui a changé ici
git switch -c xgboost-model   # une branche par tâche
git add src/project/models.py
git commit -m "Ajout de XGBoost avec arrêt précoce"
git push -u origin xgboost-model   # puis ouvrir la pull request

Le panneau Source Control de VS Code, GitHub Desktop et Codespaces font les mêmes gestes avec des boutons, mais au moins une personne par équipe doit être à l'aise dans le terminal, là où tournent les scripts batch.

À trois, chaque tâche a sa branche. Une fois poussée, la branche devient une pull request avec une courte description : quoi, pourquoi, comment vérifier. Un coéquipier commente ligne à ligne, approuve, puis la branche est fusionnée et supprimée. C'est la revue de code (code review), le moment où l'équipe apprend le plus, parce que c'est là qu'elle se met d'accord sur ce qu'est un bon code et un bon résultat. Un historique où une seule personne a tout poussé raconte un projet à une personne, quelle que soit la liste des auteurs.

Remarque (Un conflit est une question, pas une panne). Quand deux branches modifient la même ligne, il y a conflit de fusion (merge conflict) : Git ne choisit pas. Il écrit les deux versions dans le fichier entre des marqueurs ; vous gardez la bonne, retirez les marqueurs et faites un commit. Pour en avoir peu : pull avant de commencer, push dès que ça marche, branches courtes, un fichier par sujet, réglages dans un fichier de configuration, et jamais deux personnes dans le même notebook le même jour.

Retour au sommaire.

Notebooks, secrets et gros fichiers : ce qui reste hors du dépôt

Un dépôt doit contenir de quoi reconstruire le projet, et rien de secret, de personnel, d'énorme ou de régénérable automatiquement.

Un notebook est un fichier JSON qui stocke ses sorties à côté du code : deux exécutions d'un code identique donnent deux fichiers différents, et les différences affichées par Git deviennent illisibles. Effacez les sorties avant chaque commit, laissez nbstripout le faire automatiquement, ou, mieux, déplacez le code qui compte dans des modules sous src/ et gardez le notebook pour l'exploration.

Les secrets : clés d'API, mots de passe, fichiers .env, le jeton Kaggle. Un secret poussé une fois reste dans l'historique même s'il est supprimé au commit suivant, et des robots ramassent ce genre de fuite en quelques minutes.
Les gros fichiers : GitHub prévient au-delà de 50 Mo et refuse les fichiers de plus de 100 Mo. Les données brutes sont décrites dans data/README.md et téléchargées par un script.
Les données personnelles : noms, adresses e-mail, identifiants clients, jamais dans un dépôt public, même « pour tester ».
Tout ce qui se régénère : environnement virtuel (virtual environment), caches, modèles entraînés, sorties de notebook.

Le fichier .gitignore liste les motifs que Git doit ignorer. Le modèle Python de GitHub couvre déjà environnements virtuels et caches ; un projet de données y ajoute le dossier des données brutes, les CSV, les modèles sérialisés, les journaux et les fichiers d'identifiants.

Le client Kaggle en ligne de commande (pip install kaggle) montre bien pourquoi c'est important. Il permet à un script de télécharger les données d'une compétition et de soumettre un fichier avec un message, un peu comme un commit, exactement ce dont les scripts du projet auront besoin. La connexion range un jeton d'accès (API token) dans ~/.kaggle/. Ce jeton est un mot de passe : il ne va jamais dans un dépôt, un notebook partagé ou un e-mail, et s'il fuit, on le révoque et on se reconnecte.

Retour au sommaire.

L'organisation d'un dépôt de projet reproductible

Un bon dépôt est rangé pour qu'un inconnu comprenne le projet en trente secondes, le lance en deux minutes et trouve chaque livrable là où son nom l'annonce.

projet-risque-credit/
  README.md          # quoi, pour qui, comment lancer, résultats
  docs/scope.md      # le cahier des charges
  docs/journal.md    # les décisions, datées
  data/README.md     # d'où viennent les données
  notebooks/         # exploration, sorties effacées
  src/project/       # data, features, models, evaluate
  batch/             # prepare, train, predict, evaluate
  app/               # l'interface web
  slides/  tests/  requirements.txt  config.yaml  LICENSE

Le README est souvent lu à la place de tout le reste. Quatre blocs suffisent : une phrase sur ce que le modèle prédit et pour qui ; les deux ou trois commandes pour le lancer, qui doivent marcher telles quelles sur une machine vierge ; un tableau de résultats qui compare le modèle naïf, le meilleur et le lourd sur des données jamais vues à l'entraînement ; les auteurs, la licence et les liens vers les slides et l'interface en ligne.

Le cahier des charges reporte dans le dépôt le cadrage de la première séance : la décision que sert le modèle, la cible définie en une phrase sans ambiguïté, la métrique qui mesure cette décision, les garde-fous (variables interdites, populations protégées, fuites), les données et leur provenance, et le plan. C'est une page Markdown versionnée, modifiée par pull request chaque fois que l'équipe change d'avis : son historique montre comment la compréhension du problème a mûri. Le cadrage lui-même est développé dans la note sur les moindres carrés et le cadrage.

Les batchs sont le cœur de la reproductibilité. Un notebook exécuté dans le désordre peut afficher des résultats que son code ne produit plus ; un script batch (batch script) s'exécute de haut en bas, toujours de la même façon, pour n'importe qui, y compris une machine la nuit. Quatre scripts (préparer, entraîner, prédire, évaluer) et une commande qui les enchaîne, comme make all ou un run.sh. Chaque réglage (chemin des données, graine aléatoire, seuil de décision, hyperparamètres) vit dans config.yaml : changer d'expérience ne demande jamais de toucher au code. La séance 4 construit cette chaîne sur un score de crédit ; voir le seuil de décision et le ML reproductible.

Les issues sont le tableau de bord de l'équipe : une issue numérotée par tâche, avec un responsable et un jalon (milestone), fermée automatiquement par un message de commit comme Fixes #17.

L'interface web se déploie depuis le dépôt sans frais : Streamlit Community Cloud par défaut, Hugging Face Spaces avec Gradio, ou GitHub Pages pour des pages statiques. Le minimum est un formulaire qui reçoit un cas et renvoie une prédiction avec sa confiance.

Un exemple complet de cette structure est le projet de score de défaut de crédit, et des idées de sujets sur données ouvertes sont réunies dans les projets de machine learning sur données ouvertes.

Retour au sommaire.

Python : les bibliothèques, votre point de départ, l'installation

Cinq bibliothèques couvrent tout le cours, et que vous n'ayez jamais codé ou soyez déjà à l'aise, un chemin court mène au premier jalon du projet.

Guido van Rossum a publié Python en février 1991. Il est devenu la langue commune de la donnée parce que toutes les bibliothèques qui comptent sont écrites pour lui et qu'un débutant peut le lire. Le cours en demande cinq : pandas pour les tableaux, NumPy pour les vecteurs et matrices, scikit-learn pour les modèles, la validation et les pipelines, Matplotlib (avec Seaborn par-dessus) pour les figures, et XGBoost pour le modèle lourd sur données tabulaires. Le code de chaque modèle du cours est réuni dans le code Python des modèles de machine learning.

Trois points de départ

Jamais codé. Commencer par des leçons Python courtes, dans le navigateur, sur des cas de finance (variables, boucles, fonctions, puis pandas), puis le cours Python de Kaggle ; compter une dizaine d'heures avant de s'attaquer au Titanic.
Un peu de Python. Aller directement au cours Pandas de Kaggle, puis au tutoriel officiel du Titanic, pour lire un CSV, le nettoyer et soumettre.
À l'aise. Suivre Intermediate Machine Learning (pipelines, validation croisée, XGBoost, fuites), construire tôt le modèle lourd, et aider le reste de l'équipe.

**Tableau 3 :** Trois façons d'avoir Python, à choisir dès la première semaine.
Option	Ce que c'est	Pour quoi	Installation
Kaggle ou Google Colab	Jupyter dans le navigateur, bibliothèques déjà là, GPU gratuit	les compétitions bonus, les premiers essais	aucune
GitHub Codespaces	VS Code dans le navigateur, sur le dépôt de l'équipe, Git intégré	le projet, sur un ordinateur faible	aucune
Miniconda et VS Code	Python sur votre machine, un environnement par projet	le projet et tous les postes qui suivront	environ 30 minutes, une fois

# un environnement par projet, pour que les versions ne se mélangent pas
conda create -n project python=3.12
conda activate project
pip install -r requirements.txt
python -c "import sklearn, pandas, xgboost"   # aucune erreur, tout est en place

Si la dernière ligne passe sans erreur, tout est en place ; les versions figées dans requirements.txt permettent à une autre machine de reconstruire le même environnement.

Retour au sommaire.

À retenir

Chaque outil a son rôle (Kaggle pour l'entraînement, GitHub pour la livraison, Python pour le code), aucun ne coûte rien, et tous laissent une trace visible par un recruteur.
Un score Kaggle n'a de sens que face à une validation interne : on peut surapprendre le classement public, et un score parfait signale le plus souvent une fuite.
Git enregistre les états d'un projet, GitHub les héberge et ajoute pull requests, relectures et issues. Gardez main en état de marche et mettez tout ce qui est incertain sur une branche.
Le cycle quotidien : pull, modifier, commit avec un message qui dit pourquoi, push ; une branche par tâche et une pull request relue par branche.
Secrets, données personnelles, gros fichiers et sorties régénérables n'entrent jamais dans un dépôt, un jeton poussé reste dans l'historique.
Un projet reproductible a un README, un cahier des charges, des modules dans src/, des réglages dans un fichier de configuration et des batchs qui reconstruisent tout d'une commande sur une machine vierge.

Glossaire

dépôt (repository): Le dossier d'un projet avec tout son historique de versions, en local et le plus souvent sur GitHub.
branche (branch): Une ligne de travail parallèle ; main est la branche principale et doit toujours fonctionner.
fusion (merge): Le fait de ramener les commits d'une branche dans une autre.
revue de code (code review): La relecture d'une pull request par un coéquipier, ligne à ligne, avant la fusion.
conflit de fusion (merge conflict): Deux branches ont modifié les mêmes lignes, Git écrit les deux versions et une personne tranche.
classement public (public leaderboard): Le classement d'une compétition Kaggle calculé pendant le concours sur une partie du test, à distinguer du classement privé révélé à la clôture.
fuite de données (data leakage): Une information sur la réponse qui atteint le modèle à l'entraînement ou à la prédiction et gonfle le score sans vraie compétence.
jeton d'accès (API token): La clé qui authentifie un script auprès d'un service comme Kaggle, à traiter comme un mot de passe.
cahier des charges (scope document): Une page Markdown qui fixe la décision servie, la cible, la métrique, les garde-fous, les données et le plan.
script batch (batch script): Un script qui exécute une étape du début à la fin sans intervention, comme préparer, entraîner, prédire ou évaluer.
environnement virtuel (virtual environment): Un ensemble isolé de paquets Python propre à un projet, pour que les versions ne se mélangent pas entre projets.
modèle de référence (baseline): Le modèle raisonnable le plus simple, comme prédire la moyenne, auquel on compare tous les autres.
jalon (milestone): Une échéance du projet à laquelle on rattache des issues, pour voir d'un coup d'œil ce qui reste à faire.

Les autres fiches du cours

Un résumé public par deck, dans l'ordre du cours.

IntroductionHivers de l'IA, emploi et méthode
OutilsKaggle, GitHub, Python : les outils
Séance 1Cadrage de projet et moindres carrés
Séance 2Vraisemblance et régression logistique
Séance 3Descente de gradient, ridge et lasso
Séance 4Seuil de décision et ML reproductible
DevoirUn modèle de référence défendable
Séance 5Noyaux, SVM et arbres de décision
Séance 6Forêts, boosting, comparaison honnête
Séance 7SHAP, équité, ACP et partitionnement
DevoirUn modèle champion documenté
Séance 8Réseaux de neurones, dérive, prédiction conforme
DevoirUn projet de machine learning livré
Séance 9Soutenir un projet de machine learning
RéférenceProjet de score de défaut de crédit
RéférenceRendements boursiers : XGBoost et sentiment
RéférenceLe code Python de chaque modèle
RéférenceDeep learning, l'essentiel
RéférenceDonnées ouvertes et projets par secteur
RéférenceManuel de l'expert data et IA
RéférenceData engineering, SRE et cloud
RéférencePanorama des modèles de machine learning

Toutes les fiches, en liste de lecture

L'attention et le transformer, pas à pas

À propos de ces fiches

Écrites par l'enseignant à partir des slides du deck, comme un résumé public : les idées clés, les formules et un exemple calculé. Les exercices, leurs corrigés, les contrôles et la notation restent dans le deck, pour les élèves du cours.

Révision : 16 octobre 2026.