~/teaching · machine learning · référence

Le manuel de l'expert data et IA : cadrer, s'outiller, modéliser, déployer, observer

Un deck de référence qui suit un projet de la première question jusqu'au tableau de bord en production.

Sitraka Forler, Centrale Méditerranée

Révision 16 octobre 2026 · environ 20 minutes

Résumé

C'est le manuel de référence du cours de Machine Learning de Centrale Méditerranée (option DDEFI, 2026-2027). Ce n'est pas une séance : c'est le deck que les élèves gardent ouvert pendant qu'ils construisent, et qui rassemble en un seul endroit ce que les autres decks dispersent. Ses cinq grandes parties suivent la vie d'un vrai projet data et IA en entreprise : écrire le cadrage, choisir ses outils, modéliser en partant du candidat le plus simple, déployer un modèle et une application, puis les observer. Ce que la production apprend (dérive, latence, coût) revient modifier le cadrage.

Chaque partie est concrète. Le cahier des charges tient en six lignes. La boîte à outils couvre huit familles, de Python et Git jusqu'à Airflow, Spark, Kafka, Docker, Kubernetes et les piles d'observabilité, avec pour chaque outil la licence lue dans son dépôt officiel et une alternative libre quand l'outil est commercial. Dix-sept fiches de modèles, une slide chacune, vont de la moyenne jusqu'à la génération augmentée par la recherche. La partie déploiement assemble un notebook, un service FastAPI, une page Streamlit, des tests, l'intégration continue et un conteneur. La partie observabilité compare Datadog, la pile Elastic, Grafana avec Prometheus, et OpenTelemetry.

Après lecture, on sait cadrer un projet en une page, défendre un choix d'outils et de trois modèles de complexité croissante, livrer un petit service que quelqu'un d'autre peut appeler, et dire ce qu'on surveillerait sur son tableau de bord. Il s'achève sur vingt autres sujets de projet, la plupart en finance, chacun adossé à un jeu de données ouvert dont on a vérifié le producteur, l'adresse et les conditions d'usage.

Les slides

Le manuel de l'expert data et IA : cadrer, outiller, modéliser, déployer, observer

Référence. 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

Comment utiliser le manuel. La carte des parties et la boucle qu'elles forment : cadrer, s'outiller, modéliser, déployer, observer, puis recommencer.
Le cahier des charges. Un gabarit en six lignes, un exemple rempli sur le défaut des PME, les questions au commanditaire et les erreurs classiques.
La boîte à outils. Huit familles d'outils avec une fiche chacune : ce qu'est l'outil, quand s'en servir, sa licence et une alternative libre.
Le B.A.-BA des modèles. Dix-sept fiches sur un même gabarit, des modèles naïfs jusqu'aux transformers et au RAG, puis lequel choisir.
Déployer un modèle et une application. Du notebook au script, à l'API, à l'interface, aux tests, à la CI, à Docker, aux versions figées, aux secrets et à l'hébergement gratuit.
Observer. Journaux, métriques et traces ; Datadog, Elastic, Grafana et OpenTelemetry ; ce qu'on surveille sur un modèle ; un projet d'analyse de journaux.
Les équipes. Comment les équipes du cours se répartissent le travail entre des rôles données, modèle et relecture qui tournent.
Vingt projets de plus. Treize sujets de finance et sept en data et IA, chacun avec un jeu de données ouvert vérifié et ses conditions d'usage.

Le cahier des charges : six lignes avant tout code

Avant d'écrire du code, on écrit six phrases : la décision que sert le modèle, ce qu'il prédit, comment on mesure le succès, ce qui est interdit, les données et le plan.

Le manuel commence par le cadrage parce qu'un modèle qui ne sert aucune décision est inutile, aussi précis soit-il. Le gabarit compte six lignes d'une phrase chacune : la décision (qui agit sur la prédiction, et ce que coûte chaque type d'erreur), la cible (ce qu'on prédit, à quel horizon, et quand la vérité devient connue), la métrique (celle qui reflète la décision, avec un seuil d'utilité), les garde-fous (variables interdites, personnes protégées, fuite de données (data leakage)), les données (source, licence, période, manques) et le plan (trois modèles, jalons, qui fait quoi). Une ligne qui ne tient pas en une phrase signale qu'on n'a pas encore compris le problème.

Il en découle un filtre pratique : si une équipe ne peut pas remplir la ligne données cette semaine, avec une adresse et une licence, elle change de sujet plutôt que de modèle. Le document vit dans le dépôt, en Markdown, et ne change que par une demande de fusion (pull request) : son historique montre comment la compréhension de l'équipe a mûri. Un journal de décisions daté l'accompagne.

L'exemple rempli : le défaut des PME françaises

Décision. Le chargé d'affaires examine d'abord les 5 % de PME les plus risquées ; une fausse alerte coûte un examen, un défaut manqué coûte une perte.
Cible. Une procédure collective publiée au BODACC dans les douze mois suivant la date de notation, qui sert de pivot : chaque variable doit être connue ce jour-là.
Métrique. PR-AUC, rappel dans les 5 % du haut et coût attendu par dossier, parce que la classe est rare et le budget d'examen fixe.
Garde-fous et données. Aucune donnée sur les dirigeants, personnes physiques ; le BODACC et le répertoire Sirene sur data.gouv.fr, sous Licence Ouverte 2.0 ; une coupe par date.
Plan. Le taux de défaut par secteur comme modèle naïf, puis la régression logistique, puis LightGBM.

Six questions traduisent le même gabarit dans la langue du commanditaire (sponsor) : que ferez-vous autrement avec la prédiction, que coûte chaque erreur, quand saurez-vous la vérité, que faites-vous aujourd'hui sans modèle, qui a le droit de voir les données, et qu'est-ce qui compterait comme un échec. La quatrième donne gratuitement le modèle de référence (baseline) ; la sixième fixe le seuil d'utilité avant tout résultat, pour qu'il ne glisse pas vers le score obtenu.

Remarque (Six erreurs qui reviennent). Une cible floue, une métrique qui flatte une classe rare (l'exactitude sur la fraude), des variables venues du futur, une coupe aléatoire de données datées, un score sans modèle naïf pour lui donner une échelle, et un jeu republié sans sa licence. Une AUC de 0,78 ne dit pas grand-chose seule ; mise face au score de la règle actuelle, elle devient un argument.

Retour au sommaire.

La boîte à outils : huit familles, un outil par couche

Un expert data et IA travaille avec une pile d'outils, du portable jusqu'au nuage, et un projet d'élève n'a besoin que d'un outil simple par couche.

La boîte à outils se dessine comme des couches posées les unes sur les autres, à lire de bas en haut : le poste de travail (Python, VS Code, Jupyter, Git, GitHub, Linux, Docker), les données (PostgreSQL, DuckDB, SQLite, pandas, Polars, Spark, Kafka, le format Parquet), l'orchestration (Airflow, dbt, Prefect, LangGraph, MCP), les modèles (NumPy, scikit-learn, XGBoost, LightGBM, PyTorch, TensorFlow, Hugging Face, MLflow), le service (FastAPI, uvicorn, Streamlit, Gradio, Nginx), l'infrastructure (Kubernetes, Terraform, les grands nuages, deux hébergeurs français, GitHub Actions) et l'observabilité (observability). L'IA générative est une colonne qui traverse toutes les couches : elle aide à écrire du code, à extraire des champs d'un texte, à résumer un incident ou à piloter un agent.

**Tableau 1 :** Ce que demande chaque couche dans un projet du cours, et ce qu'ajoutent les grandes entreprises.
Couche	Suffisant pour un projet du cours	Courant à grande échelle
Données	DuckDB ou pandas sur des fichiers Parquet	Spark sur une grappe, Kafka pour les flux d'événements, PostgreSQL derrière une application
Orchestration	une tâche cron ou un workflow GitHub Actions planifié	Airflow dès que plusieurs tâches dépendantes demandent reprises et historique
Modèles	scikit-learn, puis XGBoost ou LightGBM ; MLflow en option	PyTorch et des modèles pré-entraînés Hugging Face sur GPU
Service	FastAPI lancé par uvicorn, plus une page Streamlit	Nginx devant, pour le HTTPS et la répartition de charge
Infrastructure	Docker, GitHub Actions et un hébergeur gratuit	Kubernetes et Terraform sur un nuage
Observabilité	Prometheus et Grafana en local	Datadog, ou une pile Elastic ou Grafana hébergée

Chaque fiche distingue la licence du logiciel et le prix du service. En apprentissage automatique, les bibliothèques sont libres ; le coût est dans les machines et les données. Quelques licences méritent l'attention : Terraform est passé en 2023 sous Business Source License, qui n'est pas une licence libre, et le fork communautaire OpenTofu est resté sous MPL 2.0 ; Elasticsearch laisse le choix entre AGPL v3, SSPL et Elastic License, tandis qu'OpenSearch reste sous Apache 2.0 ; Docker Desktop a ses propres conditions commerciales, distinctes du moteur Docker, libre. Aucun prix ni quota gratuit n'est recopié, parce qu'ils changent : le deck dit de les lire sur la page officielle le jour de l'inscription, et de poser une alerte de budget avant de démarrer la moindre machine dans un nuage.

Kubernetes et Spark sont présentés pour ce qu'ils sont : des outils pour un fort trafic ou des données qui dépassent une machine, à connaître pour un entretien, pas à installer pour un projet de trois mois. Construit deux fois, le même projet coûte soit du temps d'installation (logiciels libres sur un portable), soit une facture qui grandit avec l'usage (services hébergés). Les grappes et la fiabilité des sites sont traitées dans la note data engineering et cloud.

Retour au sommaire.

Airflow, et l'orchestration d'agents à modèles de langue

Un orchestrateur lance les tâches dans le bon ordre et au bon moment, relance celles qui échouent et garde la mémoire de chaque exécution, que les tâches déplacent des données ou appellent un modèle de langue.

Airflow décrit une chaîne de traitement comme un graphe orienté acyclique (directed acyclic graph, DAG) : des tâches et leurs dépendances. Il lance le graphe selon une planification, enregistre l'état et les journaux de chaque tâche pour chaque exécution, relance une tâche en échec selon une règle, puis alerte l'équipe. Planifier, cron sait le faire ; ce qui fait la valeur d'Airflow, c'est cette mémoire, qui permet de voir quelle tâche a échoué, quel jour, et de rejouer une date passée par rattrapage (backfill) sans tout relancer.

La même mécanique fait tourner des agents. Un agent en entreprise est le plus souvent une chaîne d'appels à un modèle de langue, avec des consignes précises, placée entre des étapes ordinaires. L'exemple du deck est une veille de presse pour une banque : collecter les articles, les résumer, classer chacun comme risque ou non, vérifier la sortie par des règles et un modèle juge, attendre la validation d'un analyste, publier le matin. Pour Airflow, chaque appel n'est qu'une fonction Python, et l'orchestrateur apporte ce qui manque aux scripts d'agents écrits à la main : des reprises sur les erreurs du fournisseur, un journal de chaque appel pour l'audit, le coût par tâche, et une étape humaine explicite avant toute action irréversible.

Remarque (Airflow, LangGraph, MCP). Airflow orchestre la journée ; LangGraph orchestre une conversation, sous forme de graphe d'états où le modèle peut boucler sur des appels d'outils, l'état étant sauvegardé à chaque nœud ; MCP, le Model Context Protocol publié par Anthropic en novembre 2024, est une façon ouverte d'exposer des outils (une base, un dépôt) à tout client compatible. Un projet peut employer les trois ; l'idée à garder est que l'accès d'un agent aux données est un contrat explicite, limité et journalisé.

Retour au sommaire.

Dix-sept fiches de modèles, du simple au profond

Chaque modèle reçoit la même fiche d'une page : l'idée en une phrase, la formule, un croquis, quand l'employer, les réglages qui comptent et la fonction à importer.

Les fiches se rangent en trois étages. Simple : la moyenne ou la dernière valeur (persistance), les moindres carrés ordinaires (ordinary least squares, OLS), la régression logistique (logistic regression), les k plus proches voisins, le classifieur bayésien naïf. Intermédiaire : l'arbre de décision, la forêt aléatoire, le gradient boosting et XGBoost, les SVM à noyaux, l'ACP, k-means. Profond : le perceptron multicouche, les réseaux convolutifs et récurrents, le transformer, le grand modèle de langage, puis l'ajustement fin et le RAG. La moitié gauche d'une fiche dit ce qu'il faut comprendre, la moitié droite ce qu'il faut savoir faire. Quelques formules portent l'essentiel du cours :

\hat\beta = (X^{\T} X)^{-1} X^{\T} y

(1)

P(y=1\mid x) = \sigma(x^{\T}\beta) = \frac{1}{1+e^{-x^{\T}\beta}}

(2)

F_m(x) = F_{m-1}(x) + \eta\, h_m(x)

(3)

\mathrm{Attention}(Q,K,V) = \softmax\!\left(\frac{QK^{\T}}{\sqrt{d}}\right) V

(4)

Les moindres carrés projettent $y$ sur l'espace engendré par les colonnes de $X$ (voir la note sur les moindres carrés) ; la régression logistique fait passer un score linéaire dans une courbe en S et c'est le modèle des grilles de score bancaires, avec un seuil fixé d'après le coût des erreurs plutôt que laissé à 0,5. Le boosting ajoute en série de petits arbres, chacun ajusté sur ce que les précédents ont manqué, pondérés par un pas d'apprentissage $\eta$ ; on laisse l'arrêt précoce sur un jeu de validation choisir le nombre d'arbres. L'attention laisse chaque mot construire sa représentation à partir de tous les autres, ce que l'article sur l'attention dérive pas à pas.

Sur des tables de taille moyenne, les arbres boostés battent encore le plus souvent les réseaux de neurones ; un MLP entre dans la comparaison comme un candidat de plus, sous la même règle.
Un modèle de langue produit un texte plausible, pas un texte vrai : on l'emploie là où la sortie se vérifie, comme extraire un montant imprimé sur le document.
La génération augmentée par la recherche (retrieval-augmented generation, RAG) va chercher les passages les plus proches par similarité cosinus des plongements et ne touche pas aux poids ; l'ajustement fin (fine-tuning), ou LoRA, une correction de petit rang $W' = W + BA$ , modifie le modèle. Le RAG pour un savoir qui change, l'ajustement fin pour un comportement.

Retour au sommaire.

Quel modèle choisir : naïf, meilleur, lourd

Chaque projet compare trois modèles de complexité croissante, et ne monte d'une marche que si le gain dépasse le bruit.

Le point de départ dépend des données et de la tâche, pas de la mode. Pour chaque type de problème, le manuel propose un candidat par marche : un modèle naïf qui donne l'échelle, un meilleur modèle simple et défendable devant un comité, et un modèle lourd qui teste si la complexité paie. L'enjeu est une comparaison loyale, pas une victoire du modèle lourd : une seule coupe, une seule métrique, une seule période de test pour les trois. Le panorama des modèles donne la version longue de ce tableau.

**Tableau 2 :** Le point de départ d'un praticien pour chaque type de problème.
Problème	Naïf	Meilleur	Lourd
Cible oui/non sur une table	taux de base	régression logistique	XGBoost ou LightGBM
Montant sur une table	la moyenne	OLS ou ridge	LightGBM
Série temporelle	dernière valeur ou même saison	ridge sur retards, ARIMA	boosting sur retards
Textes courts étiquetés	classe la plus fréquente	TF-IDF et régression logistique	un transformer ajusté
Questions sur des documents	recherche par mots-clés BM25	RAG	RAG avec reclassement
Images	classe la plus fréquente	CNN pré-entraîné figé et tête logistique	un CNN ajusté
Sans étiquettes	une règle métier	k-means, ACP	forêt d'isolement, auto-encodeur

Les projets d'IA générative gardent les trois marches à condition de partager une mesure : un jeu de référence de questions ou de documents étiquetés par l'équipe et figé avant le premier essai, une grille écrite à l'avance, et un coût en euros et en secondes par requête, car un modèle meilleur de deux points et dix fois plus cher n'est pas forcément le bon. Le calcul du deck montre pourquoi la taille du jeu de référence compte.

Exemple chiffré : la précision d'un taux mesuré sur 50 questions

Taux observé. Un modèle répond juste à 40 des 50 questions de référence, donc $\hat p = 0.80$ .
Erreur-type. $\sqrt{0.80 \times 0.20 / 50} = \sqrt{0.0032} \approx 0.0566$ .
Demi-largeur à 95 %. Avec l'approximation normale, $1.96 \times 0.0566 \approx 0.111$ , soit environ 11 points de part et d'autre.
Lecture. L'intervalle va d'environ 69 % à 91 % : un concurrent à 84 % sur le même jeu ne s'en distingue pas. On le dit, ou on agrandit le jeu.

Retour au sommaire.

Déployer un modèle et une application

Déployer, c'est faire d'un notebook un petit service que tout le monde peut appeler : un script qui entraîne, une API qui prédit, une page pour les humains et un robot qui vérifie tout à chaque changement.

L'architecture est la même pour toutes les équipes ; seuls le modèle et l'interface changent. Côté développeur, on explore dans un notebook, on déplace le code qui marche dans src/ avec ses tests, on ouvre une demande de fusion, et GitHub Actions vérifie le style, lance les tests et construit l'image. Côté hébergeur, une API sert le modèle et une interface l'appelle. Les secrets restent hors du dépôt ; l'observabilité surveille l'API en marche.

Pas à pas

Du notebook au script. Chaque étape devient une fonction avec des arguments, et une seule commande réentraîne en écrivant le fichier du modèle et un fichier de métriques ; personne ne recopie un chiffre à la main, et la même graine donne le même résultat.
Du script à l'API. FastAPI charge le modèle enregistré une seule fois au démarrage et ne réentraîne jamais ; une classe pydantic sert de contrat d'entrée, si bien qu'une requête hors domaine est refusée par une erreur 422 avant d'atteindre le modèle ; la page /docs offre de quoi tester.
De l'API à l'interface. Une page Streamlit appelle l'API au lieu de charger le modèle, pour que les humains et les machines voient les mêmes prédictions ; l'adresse de l'API vient d'une variable d'environnement, et un avertissement visible dit ce que le score n'est pas.
Les tests. Trois tests valent mieux que zéro : le service répond, une probabilité reste entre 0 et 1, une entrée absurde est rejetée. Le plus précieux vérifie que le modèle servi prédit exactement comme le modèle évalué, sur quelques lignes fixes.
L'intégration continue. Un court workflow YAML relance installation, lint, tests et construction Docker sur une machine vierge à chaque push et à chaque demande de fusion.
Conteneur et versions. Un Dockerfile installe les dépendances figées avant de copier le code, pour que le cache survive aux changements de code ; des versions exactes garantissent que le calcul de mars est celui de novembre.
Secrets et hébergement. Les clés d'API vivent dans un fichier .env local ignoré par Git et dans les variables de l'hébergeur ; une clé poussée, même brièvement, se révoque chez le fournisseur, car l'effacer dans un commit suivant la laisse dans l'historique. Les hébergeurs gratuits conviennent à une démo, mais une instance endormie doit être réveillée avant de présenter.

Le deck insiste : qui dit application dit logiciel, donc cinq pratiques minimales s'imposent. Le lint avec ruff, les tests en intégration continue (continuous integration, CI), pas de fusion sans relecture, une étiquette git par jalon avec des dépendances figées, et un journal de décisions daté. L'IA générative accélère l'écriture d'un squelette d'API, d'un test ou d'un Dockerfile, mais elle se trompe avec aplomb (un paquet qui n'existe pas, une fuite cachée dans une étape de préparation, une clé en clair) ; le temps gagné ne compte que si quelqu'un qui comprend le code le relit, et chaque équipe déclare son usage. Le service de prédiction et la dérive sont développés dans la note réseaux de neurones et dérive, et la mise en service (deployment) d'un conteneur (container) passe par les variables d'environnement (environment variables) pour tout ce qui ne doit pas être écrit dans le code.

Retour au sommaire.

Observer : journaux, métriques, traces, et ce qu'on surveille sur un modèle

Observer une application, c'est savoir qu'elle ralentit, échoue ou dérive avant qu'un utilisateur ne s'en plaigne, à partir de trois signaux : journaux, métriques et traces.

Les journaux (logs) disent ce qui s'est passé, événement par événement, et ne servent que s'ils sont structurés : une ligne JSON par événement, avec des champs nommés (route, statut, durée, version du modèle, sortie), jamais de donnée personnelle en clair. Les métriques (metrics) comptent et mesurent dans le temps et déclenchent les alertes ; un histogramme des durées permet de calculer des quantiles, comme la latence au 95e centile. Les traces suivent une requête à travers les services et montrent où le temps est passé, découpé en segments (spans).

**Tableau 3 :** Trois réponses au même besoin, telles que le deck les compare.
	Datadog	Pile Elastic	Pile Grafana
Où ça tourne	hébergé par l'éditeur	chez soi ou Elastic Cloud	chez soi ou Grafana Cloud
Journaux, métriques, traces	agent, gestion des journaux, APM	Elasticsearch, Metricbeat, Elastic APM	Loki, Prometheus, Tempo ou Jaeger
Écrans	tableaux de bord intégrés	Kibana	Grafana
Point fort	tout d'un coup, vite branché	recherche plein texte sur d'énormes volumes	libre, léger et répandu

Datadog, fondé en 2010 à New York par deux centraliens, vend du temps : on installe son agent, et tableaux de bord, alertes et traces apparaissent. Elasticsearch range les journaux dans un index inversé (pour chaque mot, la liste des lignes qui le contiennent), si bien qu'une recherche devient une intersection de listes. Prometheus fait l'inverse de la plupart des outils : il vient lire la page /metrics de chaque service à intervalle fixe et garde des séries temporelles étiquetées, interrogées en PromQL ; Grafana les affiche à côté des journaux de Loki. OpenTelemetry, projet de la Cloud Native Computing Foundation, normalise la production et le transport des trois signaux (le protocole OTLP, à travers un Collector) : on instrumente une fois, et l'on peut passer d'une pile locale à un service payant sans toucher au code. Le montage recommandé pour le cours est la pile Grafana sous Docker Compose.

Un modèle ajoute ses propres indicateurs à la latence, au taux d'erreur et au volume : la dérive (drift) des entrées, mesurée par le PSI de chaque variable sans attendre les étiquettes, la distribution des scores en sortie, la qualité réelle (AUC, calibration) une fois la vérité arrivée, parfois des mois plus tard, et, pour les appels à un modèle de langue, les jetons d'entrée et de sortie de chaque requête convertis en coût quotidien. Les seuils du deck sont des exemples, comme un PSI au-dessus de 0,25 issu de la pratique du score de crédit, et chaque alerte a un responsable et une action. C'est cela, la surveillance (monitoring) : instrumenter un service FastAPI demande un compteur, un histogramme, une route /metrics et une ligne de journal JSON par prédiction, avec la version du modèle.

La partie se termine en renversant les rôles : un modèle qui observe une application. Avec Loghub (laboratoire LogPAI, Université chinoise de Hong Kong), dont le jeu HDFS_v1 compte 11 175 629 lignes de journaux sur 38,7 heures d'après le README du dépôt lu le 12 octobre 2026, les élèves réduisent chaque ligne à un gabarit (l'algorithme Drain), puis comparent une règle sur les mots d'erreur, une forêt d'isolement (isolation forest) sur les comptes de gabarits, et un modèle de séquence ou un modèle de langue. Un modèle de langue résume ensuite chaque incident détecté pour l'ingénieur d'astreinte, qui décide toujours ; les résumés sont jugés face à une trentaine rédigés à la main, avec une grille fixée d'avance. Loghub n'est libre que pour la recherche et l'enseignement, en citant l'article.

Retour au sommaire.

À retenir

Cadrer avant de coder : six lignes d'une phrase (décision, cible, métrique, garde-fous, données, plan), versionnées dans le dépôt et modifiées par demande de fusion.
Un outil simple par couche suffit pour un projet ; Spark, Kafka et Kubernetes se comprennent, ils ne s'installent pas pour trois mois de travail.
La valeur d'Airflow est sa mémoire (historique, reprises, rattrapages), et le même DAG peut orchestrer des appels à un modèle de langue avec une étape humaine explicite.
Comparer un modèle naïf, un meilleur et un lourd sur la même coupe et la même métrique, et ne monter d'une marche que si le gain dépasse le bruit.
Déployer comme on écrit un logiciel : un script d'entraînement, une API avec un contrat d'entrée, une interface séparée, des tests en CI, un conteneur, des versions figées, des secrets hors de Git.
Observer par les journaux, les métriques et les traces ; pour un modèle, ajouter la dérive, la distribution des sorties, la qualité différée et le coût de chaque appel à un modèle de langue.
Lire licences et conditions avant de construire : plusieurs outils et jeux de données répandus sont à source disponible ou non commerciaux, pas libres.

Glossaire

Cahier des charges: Le cadrage d'un projet en une page et six lignes (décision, cible, métrique, garde-fous, données, plan), gardé dans le dépôt.
graphe orienté acyclique (directed acyclic graph, DAG): Des tâches et leurs dépendances, l'unité qu'Airflow planifie et exécute.
rattrapage (backfill): Rejouer les exécutions de dates passées d'une chaîne de traitement, par exemple après la correction d'un bogue, sans relancer le reste.
MCP: Model Context Protocol, protocole ouvert par lequel un serveur expose des outils et des ressources à un client à modèle de langue.
génération augmentée par la recherche (retrieval-augmented generation, RAG): Aller chercher les passages les plus pertinents et les donner à un modèle de langue, dont les poids ne changent pas.
modèle de référence (baseline): Le modèle naïf (moyenne, dernière valeur, règle actuelle) que tout autre modèle doit battre pour mériter sa place.
intégration continue (continuous integration, CI): Réinstaller, vérifier le style, tester et construire le projet automatiquement, sur une machine vierge, à chaque push.
conteneur (container): Une image qui contient une application et toutes ses dépendances, et qui tourne à l'identique sur un portable, en CI et chez l'hébergeur.
observabilité (observability): Pouvoir répondre, sans redéployer, à des questions sur un système en marche à partir de ses journaux, métriques et traces.
journaux (logs): Le récit d'une application, un événement par ligne, idéalement en JSON avec des champs nommés.
dérive (drift): Un changement des entrées, ou de leur lien avec la cible, après le déploiement, souvent mesuré par le PSI.
surveillance (monitoring): Les indicateurs, seuils, alertes et responsables qui disent si un service et son modèle fonctionnent encore comme prévu.

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.