Concepts fondamentaux du deploiement IA
Qu'est-ce que le deploiement ML ?
Du notebook a la production
La plupart des projets de machine learning commencent dans un notebook Jupyter — un bac a sable confortable ou les scientifiques de donnees explorent les donnees, entrainent des modeles et evaluent les resultats. Mais un notebook n'est pas un produit. Le deploiement est le processus de transformation d'un modele entraine en un service fiable avec lequel de vrais utilisateurs peuvent interagir.
L'analogie du pont
Pensez au developpement de modeles comme a la conception d'un pont sur papier — vous calculez les capacites de charge, choisissez les materiaux et simulez la resistance au vent. Le deploiement consiste a construire reellement le pont pour que des milliers de voitures puissent le traverser en toute securite chaque jour.
| Developpement (Conception) | Deploiement (Construction) |
|---|---|
| Fonctionne sur des donnees d'echantillon | Gere des donnees du monde reel |
| Tourne sur votre portable | Tourne sur des serveurs 24h/24 |
| Tolere les erreurs et les reprises | Doit etre tolerant aux pannes |
| Un seul utilisateur (vous) | Des milliers d'utilisateurs simultanement |
| La vitesse importe peu | La latence est critique |
| Execution manuelle | Pipeline automatise |
80% des projets ML n'arrivent jamais en production. L'ecart entre un notebook fonctionnel et un service en production est l'endroit ou la plupart des projets echouent. Ce cours vous apprend a franchir cet ecart.
Developpement vs Deploiement
Deux mentalites differentes
| Aspect | Developpement | Deploiement |
|---|---|---|
| Objectif | Maximiser la precision | Maximiser la fiabilite + precision |
| Donnees | Jeux de donnees statiques (CSV, Parquet) | Flux de donnees en temps reel |
| Qualite du code | "Ca marche" suffit | Doit etre teste, documente, maintenable |
| Environnement | Machine locale, notebooks | Serveurs, conteneurs, cloud |
| Versionnement | Peut-etre Git pour le code | Versionnement du code + modele + donnees |
| Surveillance | Evaluation manuelle | Alertes automatisees et tableaux de bord |
| Gestion des erreurs | Instructions print | Journalisation structuree, degradation gracieuse |
| Reproductibilite | "Ca marchait sur ma machine" | Doit fonctionner partout, a chaque fois |
Le cycle de vie MLOps
Qu'est-ce que MLOps ?
MLOps (Machine Learning Operations) est l'ensemble des pratiques qui combine le ML, le DevOps et l'ingenierie de donnees pour deployer et maintenir les systemes ML en production de maniere fiable et efficace.
Pensez-y comme l'equivalent ML du DevOps pour les logiciels traditionnels.
Niveaux de maturite MLOps
| Niveau | Nom | Description | Exemple |
|---|---|---|---|
| 0 | Pas de MLOps | Processus manuel, pilote par des scripts | Execution de notebooks a la main |
| 1 | DevOps mais pas MLOps | CI/CD automatise pour le code, ML manuel | Git + tests, mais entrainement manuel du modele |
| 2 | Entrainement automatise | Pipeline d'entrainement automatise | Reentrainement planifie avec de nouvelles donnees |
| 3 | Deploiement automatise | CI/CD pour les modeles | Deploiement auto si les metriques depassent le seuil |
| 4 | MLOps complet | Tout automatise + surveillance | Pipeline complet avec detection de derive |
Dans ce cours, nous visons a vous amener au Niveau 2-3 — vous construirez des pipelines d'entrainement et de deploiement automatises avec des tests rigoureux.
Definition du perimetre
Pourquoi definir le perimetre en premier ?
Avant d'ecrire une seule ligne de code, vous devez clairement definir ce que votre modele fera, qui l'utilisera et comment il sera accessible. Sans un perimetre clair, les projets explosent en complexite et ne sont jamais livres.
Le cahier des charges
Un cahier des charges est un court document (1-2 pages) qui repond a ces questions critiques :
| Question | Exemple de reponse |
|---|---|
| Quel probleme le modele resout-il ? | Predire le desabonnement client dans les 30 jours |
| Qui est l'utilisateur final ? | Equipe de succes client via un tableau de bord web |
| Quelles donnees sont necessaires ? | Journaux d'activite client, historique d'abonnement |
| Quelle est l'entree attendue ? | JSON avec customer_id et activite recente |
| Quelle est la sortie attendue ? | Probabilite de desabonnement (0-1) et niveau de risque |
| Quelle latence est acceptable ? | Moins de 200ms par prediction |
| A quelle frequence le modele est-il reentraine ? | Chaque semaine avec de nouvelles donnees |
| Quelle est la metrique de succes ? | AUC-ROC > 0.85, precision > 0.80 |
Limites du perimetre
Les etudiants essaient souvent de construire "le systeme parfait" des le premier jour. Commencez avec un Modele Minimum Viable (MVM) — un modele fonctionnel derriere une API simple. Vous pourrez toujours ajouter de la complexite plus tard.
Preparation a la production
La checklist de production
Un modele est pret pour la production lorsqu'il repond a ces criteres :
| Categorie | Exigence | Statut |
|---|---|---|
| Code | Le code est sous controle de version (Git) | ☐ |
| Code | Les dependances sont fixees (requirements.txt) | ☐ |
| Code | Le code passe le linting et le formatage | ☐ |
| Modele | Le modele est serialise (pickle/joblib/ONNX) | ☐ |
| Modele | La version du modele est suivie | ☐ |
| Tests | Les tests unitaires passent | ☐ |
| Tests | Les tests d'integration passent | ☐ |
| API | Les endpoints sont documentes (Swagger) | ☐ |
| API | La gestion des erreurs est implementee | ☐ |
| Surveillance | La journalisation est configuree | ☐ |
| Surveillance | Un endpoint de verification de sante existe | ☐ |
L'analogie de l'inspection de restaurant
Imaginez une inspection de restaurant avant le jour d'ouverture :
- Qualite du code = Proprete de la cuisine
- Tests = Verifications de securite alimentaire
- Documentation = Menu et etiquettes d'allergenes
- Surveillance = Detecteurs de fumee et registres de temperature
- Gestion des erreurs = Sorties de secours et trousses de premiers soins
Vous n'ouvririez pas un restaurant sans passer l'inspection. Ne deployez pas un modele sans passer votre checklist de production.
Dependances de donnees
Les donnees sont le carburant
Un modele n'est aussi bon que ses donnees. En production, les problemes de donnees sont la cause n°1 des defaillances de modeles — pas les bugs de code, pas les problemes d'infrastructure.
Derive des donnees
La derive des donnees (data drift) se produit lorsque les proprietes statistiques des donnees d'entree changent au fil du temps, causant une degradation des performances du modele.
| Type de derive | Description | Exemple |
|---|---|---|
| Derive des donnees | La distribution des entrees change | Nouvelle demographie client apres une campagne marketing |
| Derive de concept | La relation entre entree et sortie change | Le COVID a modifie les habitudes d'achat |
| Derive des labels | La distribution de la variable cible change | Les schemas de fraude evoluent avec de nouvelles techniques |
Un modele de score de credit entraine sur des donnees de 2019 a mal performe pendant le COVID-19 car les habitudes de depenses (les donnees d'entree) ont change radicalement. Les niveaux de revenus, les comportements de paiement et les categories de depenses ont tous change — c'est un cas typique de derive des donnees et de derive de concept survenant simultanement.
Feature Stores
Un feature store est un repertoire centralise pour stocker, gerer et servir les features ML. Il assure que les memes features utilisees pendant l'entrainement sont disponibles au moment de la prediction.
| Sans Feature Store | Avec Feature Store |
|---|---|
| Features calculees differemment en entrainement vs en service | Meme calcul de features partout |
| Code de features duplique entre les equipes | Source unique de verite |
| Pas de versionnement des features | Lignage et versionnement complets |
| Transformations de donnees incoherentes | Coherence garantie |
Pipelines de donnees
Un pipeline de donnees automatise le flux de donnees de la source au modele :
Voir le pipeline de donnees
Planification de l'infrastructure
CPU vs GPU
| Critere | CPU | GPU |
|---|---|---|
| Ideal pour | ML classique (sklearn, XGBoost) | Deep learning (PyTorch, TensorFlow) |
| Cout | Plus bas ($) | Plus eleve ($$$) |
| Vitesse d'inference | Plus lente pour les grands modeles | Beaucoup plus rapide pour les reseaux de neurones |
| Disponibilite | Toujours disponible | Peut necessiter une reservation |
| Utilisation typique | Donnees tabulaires, petits modeles | Images, NLP, grands transformers |
Si votre modele est un modele scikit-learn (Random Forest, Regression Logistique, etc.), le CPU est suffisant. Le GPU n'est necessaire que pour les modeles de deep learning avec des millions de parametres.
Cloud vs Sur site
| Facteur | Cloud | Sur site |
|---|---|---|
| Temps de mise en place | Minutes | Semaines/mois |
| Cout initial | Aucun (paiement a l'usage) | Tres eleve |
| Evolutivite | Instantanee | Limitee par le materiel |
| Maintenance | Le fournisseur s'en charge | Votre responsabilite |
| Controle des donnees | Centres de donnees du fournisseur | Vos installations |
| Conformite | Peut avoir des restrictions | Controle total |
Conteneurs
Les conteneurs Docker empaquettent votre application et toutes ses dependances dans une seule unite portable. Cela resout le fameux probleme "ca marche sur ma machine".
Patrons de deploiement
Batch vs Temps reel
L'analogie du restaurant
- Prediction par lots = Un buffet. La cuisine prepare tous les plats a l'avance. Les clients se servent eux-memes. Efficace pour les grands volumes, mais les plats ne sont pas faits sur commande.
- Prediction en temps reel = Service a la carte. Chaque plat est prepare a la commande. Frais et personnalise, mais plus lent pour les grands groupes.
| Aspect | Batch | Temps reel |
|---|---|---|
| Latence | Minutes a heures | Millisecondes a secondes |
| Debit | Tres eleve | Plus faible par requete |
| Infrastructure | Jobs planifies (Cron, Airflow) | Serveur API (FastAPI, Flask) |
| Cas d'usage | Recommandations par email, rapports | Detection de fraude, chatbots |
| Cout | Plus bas (execution hors pointe) | Plus eleve (toujours en marche) |
| Fraicheur | Obsolete (quelques heures) | Temps reel |
Mode shadow
En mode shadow, le nouveau modele recoit le trafic de production mais ses predictions ne sont pas montrees aux utilisateurs. Au lieu de cela, les predictions sont enregistrees et comparees avec le modele existant.
Voir le patron de deploiement shadow
Le mode shadow est ideal lorsque vous voulez tester un nouveau modele sur de vraies donnees de production sans aucun risque pour les utilisateurs. C'est la strategie de deploiement la plus sure.
Deploiement canari
Dans un deploiement canari, vous acheminez progressivement un petit pourcentage du trafic vers le nouveau modele tout en surveillant les problemes.
Le processus est progressif : 5% → 10% → 25% → 50% → 100%. A tout moment, si des problemes sont detectes, vous effectuez un retour en arriere a 0%.
Deploiement bleu-vert
Dans un deploiement bleu-vert, vous maintenez deux environnements de production identiques. A tout moment, l'un est "actif" (Bleu) et l'autre est "en attente" (Vert).
Comparaison des patrons de deploiement
| Patron | Risque | Complexite | Vitesse de retour arriere | Ideal pour |
|---|---|---|---|---|
| Direct (Big Bang) | 🔴 Eleve | Faible | Lent | Petits projets, non critique |
| Shadow | 🟢 Aucun | Moyen | Instantane (pas en production) | Validation de nouveaux modeles |
| Canari | 🟡 Faible | Moyen | Rapide | Construction progressive de la confiance |
| Bleu-Vert | 🟡 Faible | Eleve | Instantane | Zero temps d'arret requis |
| Test A/B | 🟡 Faible | Eleve | Rapide | Comparaison de variantes de modeles |
Versionnement de modeles
Pourquoi versionner les modeles ?
Tout comme vous versionnez le code avec Git, vous devez versionner vos modeles. Sans versionnement :
- Vous ne pouvez pas reproduire les resultats passes
- Vous ne pouvez pas revenir a un modele precedent
- Vous ne savez pas quel modele est en production
- Le debogage devient impossible
Quoi versionner
| Artefact | Outil | Exemple |
|---|---|---|
| Code | Git | git commit -m "Add feature engineering" |
| Modele | MLflow / Registre de modeles | model_v2.1.0.pkl |
| Donnees | DVC / Versionnement de donnees | training_data_2024-01.csv |
| Configuration | Git (YAML/JSON) | hyperparameters.yaml |
| Environnement | Docker / requirements.txt | Dockerfile, requirements.txt |
Versionnement semantique pour les modeles
Appliquez le versionnement semantique (MAJEUR.MINEUR.CORRECTIF) aux modeles :
| Changement de version | Quand | Exemple |
|---|---|---|
| MAJEUR (v1 → v2) | Changement incompatible : nouvelles features, format de sortie different | Passage de binaire a multi-classe |
| MINEUR (v1.0 → v1.1) | Amelioration : reentraine avec plus de donnees, nouvel algorithme | Meilleure precision apres reentrainement |
| CORRECTIF (v1.0.0 → v1.0.1) | Correction de bug : etape de pretraitement corrigee | Correction d'un bug de normalisation |
Resume
Carte des concepts cles
Points cles a retenir
| # | Concept | A retenir |
|---|---|---|
| 1 | Deploiement ≠ Developpement | Competences, outils et mentalite differents requis |
| 2 | MLOps | Pratiques pour un ML fiable en production |
| 3 | Le perimetre d'abord | Definissez ce que vous construisez avant d'ecrire du code |
| 4 | Derive des donnees | Votre modele se degradera avec le temps — planifiez-le |
| 5 | Patrons de deploiement | Choisissez en fonction de la tolerance au risque et des exigences |
| 6 | Versionnez tout | Code, modele, donnees, configuration, environnement |
Dans la section suivante, nous approfondirons la planification de l'infrastructure — la configuration des environnements Python, des conteneurs Docker et la comprehension des services cloud pour le deploiement IA.