Planification de l'infrastructure pour l'IA
Pourquoi l'infrastructure est importante
L'analogie de la fondation
L'infrastructure pour le deploiement IA est comme la fondation d'un batiment. L'architecture la plus belle est inutile si la fondation est fragile. De meme, le modele le plus precis est sans valeur s'il ne peut pas fonctionner de maniere fiable en production.
Environnements virtuels Python
Le probleme : l'enfer des dependances
Imaginez que vous avez deux projets :
- Le Projet A necessite
scikit-learn==1.2.0 - Le Projet B necessite
scikit-learn==1.4.0
Si les deux utilisent le Python de votre systeme, installer une version casse l'autre. C'est ce qu'on appelle l'enfer des dependances.
La solution : les environnements virtuels
Un environnement virtuel est une installation Python isolee. Chaque projet obtient son propre ensemble de paquets sans interferer avec les autres.
venv — L'option integree
venv est inclus avec Python et c'est l'option la plus simple :
# Creer un environnement virtuel
python -m venv .venv
# L'activer (Windows)
.venv\Scripts\activate
# L'activer (macOS/Linux)
source .venv/bin/activate
# Votre terminal affiche l'environnement actif
(.venv) $ python --version
Python 3.11.5
# Installer des paquets de maniere isolee
(.venv) $ pip install scikit-learn pandas fastapi
# Desactiver quand c'est fini
(.venv) $ deactivate
conda — L'option science des donnees
Conda est un gestionnaire de paquets populaire en science des donnees. Il gere a la fois les paquets Python et les dependances au niveau systeme (comme CUDA pour les GPU).
# Creer un environnement conda
conda create -n ml-project python=3.11
# L'activer
conda activate ml-project
# Installer des paquets (peut mixer conda et pip)
conda install scikit-learn pandas
pip install fastapi
# Exporter l'environnement
conda env export > environment.yml
# Recreer a partir du fichier
conda env create -f environment.yml
venv vs conda
| Fonctionnalite | venv | conda |
|---|---|---|
| Installation | Integre (Python 3.3+) | Necessite Anaconda/Miniconda |
| Source des paquets | PyPI uniquement | Canaux Conda + PyPI |
| Dependances non-Python | Ne peut pas gerer | Peut gerer (CUDA, librairies C) |
| Vitesse | Rapide | Plus lent (resolution des dependances) |
| Reproductibilite | requirements.txt | environment.yml |
| Espace disque | Leger | Plus lourd |
| Ideal pour | Apps web, APIs, CI/CD | Science des donnees, projets GPU |
Nous utilisons venv + pip tout au long de ce cours. C'est plus simple, plus rapide et suffisant pour notre flux de deploiement axe sur les APIs. Utilisez conda si vous avez besoin de support GPU ou de librairies scientifiques complexes.
Gestion des dependances
requirements.txt — Fixer les versions
Un fichier requirements.txt liste toutes les dependances de votre projet avec des versions fixees pour la reproductibilite :
# Core ML
scikit-learn==1.4.2
pandas==2.2.0
numpy==1.26.4
joblib==1.3.2
# API Framework
fastapi==0.109.0
uvicorn==0.27.0
pydantic==2.5.3
# Testing
pytest==8.0.0
httpx==0.26.0
# Explainability
shap==0.44.1
lime==0.2.0.1
N'utilisez jamais pip install scikit-learn sans version dans votre fichier de dependances. Une dependance non fixee signifie que votre projet pourrait casser demain si une nouvelle version est publiee.
Generer le requirements.txt
# Option 1 : Geler tous les paquets installes
pip freeze > requirements.txt
# Option 2 : Utiliser pipreqs (seulement les imports du projet)
pip install pipreqs
pipreqs . --force
# Installer a partir du requirements
pip install -r requirements.txt
Le patron du fichier verrou
Pour une reproductibilite plus stricte, les outils modernes creent des fichiers verrous qui fixent chaque sous-dependance :
| Outil | Fichier de config | Fichier verrou |
|---|---|---|
| pip | requirements.txt | requirements.txt (manuellement) |
| pip-tools | requirements.in | requirements.txt (compile) |
| Poetry | pyproject.toml | poetry.lock |
| Pipenv | Pipfile | Pipfile.lock |
# Utiliser pip-tools pour une meilleure gestion des dependances
pip install pip-tools
# Ecrivez vos dependances directes dans requirements.in
# Puis compilez le fichier verrou complet :
pip-compile requirements.in --output-file requirements.txt
Les bases de Docker pour le ML
Qu'est-ce que Docker ?
Docker empaquette votre application, ses dependances et le systeme d'exploitation dans un seul conteneur — une unite legere, portable et autosuffisante.
L'analogie du conteneur maritime
Avant les conteneurs maritimes standardises, chaque port avait des grues, camions et entrepots differents. L'expedition etait chaotique et lente. Le conteneur standardise a revolutionne le commerce mondial.
Docker fait la meme chose pour les logiciels :
| Conteneur maritime | Conteneur Docker |
|---|---|
| Taille standard compatible avec tout navire/camion/grue | Fonctionne sur toute machine avec Docker |
| Le contenu est isole et scelle | L'application est isolee du systeme hote |
| Empilable et composable | Plusieurs conteneurs fonctionnent ensemble |
| Reutilisable dans le monde entier | La meme image tourne en dev/staging/prod |
Dockerfile pour un projet ML
Un Dockerfile est une recette pour construire une image de conteneur :
# Start from a Python base image
FROM python:3.11-slim
# Set working directory
WORKDIR /app
# Copy and install dependencies first (better caching)
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# Copy the application code
COPY . .
# Expose the API port
EXPOSE 8000
# Start the FastAPI server
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]
Commandes Docker essentielles
# Construire une image
docker build -t my-ml-api:v1.0 .
# Lancer un conteneur
docker run -p 8000:8000 my-ml-api:v1.0
# Lancer en arriere-plan
docker run -d -p 8000:8000 --name ml-api my-ml-api:v1.0
# Verifier les conteneurs en cours
docker ps
# Voir les logs
docker logs ml-api
# Arreter un conteneur
docker stop ml-api
Cache des couches Docker
Docker construit les images en couches. Chaque instruction dans le Dockerfile cree une couche. Si une couche n'a pas change, Docker reutilise la version en cache.
Copiez toujours requirements.txt et installez les dependances avant de copier votre code. De cette facon, Docker ne reinstalle les paquets que lorsque les dependances changent reellement, pas lorsque vous modifiez un fichier Python.
.dockerignore
Tout comme .gitignore, un fichier .dockerignore exclut les fichiers inutiles du contexte de construction Docker :
__pycache__
*.pyc
.git
.venv
.env
*.ipynb_checkpoints
data/raw/
notebooks/
.pytest_cache
Considerations GPU vs CPU
Quand avez-vous besoin d'un GPU ?
Comparaison des couts
| Type d'instance | vCPUs | RAM | GPU | Prix/heure (approx.) | Cas d'usage |
|---|---|---|---|---|---|
| t3.medium | 2 | 4 Go | Aucun | 0,04 $ | Modeles sklearn simples |
| c5.xlarge | 4 | 8 Go | Aucun | 0,17 $ | XGBoost, modeles riches en features |
| g4dn.xlarge | 4 | 16 Go | 1x T4 | 0,53 $ | Inference PyTorch |
| p3.2xlarge | 8 | 61 Go | 1x V100 | 3,06 $ | Entrainement de modeles deep learning |
| p4d.24xlarge | 96 | 1152 Go | 8x A100 | 32,77 $ | Grands modeles de langage |
Une instance GPU peut couter 10 a 100 fois plus qu'une instance CPU. Commencez toujours par le CPU et ne passez au GPU que si les exigences de latence le demandent. Pour ce cours, les instances CPU sont suffisantes.
Entrainement vs Inference
| Phase | Besoins en calcul | Duree | Strategie de cout |
|---|---|---|---|
| Entrainement | Eleves (souvent GPU) | Heures a jours | Utiliser des instances spot (60-90% d'economies) |
| Inference | Plus faibles (souvent CPU OK) | Continu | Utiliser des instances reservees ou serverless |
Services cloud pour le ML
Les trois grands
Comparaison des services cloud
| Fonctionnalite | AWS SageMaker | GCP Vertex AI | Azure ML |
|---|---|---|---|
| Notebooks | SageMaker Studio | Vertex Workbench | Azure ML Studio |
| Entrainement | Training Jobs | Custom Training | Training Pipelines |
| Deploiement | Endpoints | Endpoints | Managed Endpoints |
| AutoML | Autopilot | AutoML | AutoML |
| MLOps | Pipelines | Pipelines | Designer + Pipelines |
| Conteneurs | ECR + ECS/EKS | GCR + GKE/Cloud Run | ACR + ACI/AKS |
| Serverless | Lambda | Cloud Functions | Azure Functions |
| Tarification | Paiement a l'usage | Paiement a l'usage | Paiement a l'usage |
Options de deploiement plus simples
Pour les projets collegiaux et les petits services, vous n'avez pas besoin de toute la puissance de SageMaker ou Vertex AI :
| Plateforme | Ideal pour | Offre gratuite | Complexite |
|---|---|---|---|
| Render | Hebergement d'API simple | 750 heures/mois | ⭐ Tres faible |
| Railway | Apps Python + BD | 5 $/mois de credit | ⭐ Tres faible |
| Fly.io | Conteneurs Docker | 3 VMs partagees | ⭐⭐ Faible |
| AWS Lambda | Fonctions serverless | 1M requetes/mois | ⭐⭐ Faible |
| Google Cloud Run | APIs basees sur conteneurs | 2M requetes/mois | ⭐⭐ Faible |
| Heroku | Applications full-stack | Plan Eco 5 $/mois | ⭐⭐ Faible |
Nous utiliserons le developpement local (FastAPI + uvicorn) pour la plupart des labs. Pour le projet final, vous pourrez optionnellement deployer sur une plateforme cloud.
Les bases du CI/CD pour le ML
Qu'est-ce que le CI/CD ?
CI/CD signifie Integration Continue / Deploiement Continu. Il automatise le processus de test et de deploiement des modifications de code.
Voir le pipeline CI/CD
L'analogie de la chaine de montage
Le CI/CD est comme une chaine de montage automobile :
- CI = Controles qualite a chaque station (tests unitaires, linting, construction)
- CD = La voiture sort de la chaine et est livree au concessionnaire (deploiement)
Sans CI/CD, c'est comme construire chaque voiture a la main et la conduire manuellement chez le client.
CI/CD pour le ML — Qu'est-ce qui est different ?
Le CI/CD traditionnel teste le code. Le CI/CD ML doit aussi tester les donnees et les modeles :
| CI/CD traditionnel | CI/CD ML |
|---|---|
| Les tests unitaires passent ? | Les tests unitaires passent ? |
| Le code compile ? | Le code compile ? |
| — | La validation des donnees passe ? |
| — | Les metriques du modele au-dessus du seuil ? |
| — | Pas de derive des donnees detectee ? |
| — | La taille du modele dans les limites ? |
| Deployer l'application | Deployer le modele + l'application |
Exemple : GitHub Actions pour le ML
name: ML Pipeline
on:
push:
branches: [main]
jobs:
test-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: '3.11'
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install -r requirements.txt
- name: Run tests
run: pytest tests/ -v
- name: Check model metrics
run: python scripts/validate_model.py
- name: Build Docker image
run: docker build -t ml-api:latest .
Reproductibilite de l'environnement
La pyramide de la reproductibilite
Checklist minimale de reproductibilite
| Fichier | Objectif | Requis ? |
|---|---|---|
requirements.txt | Dependances Python avec versions | ✅ Oui |
Dockerfile | Definition complete de l'environnement | ✅ Oui (pour le deploiement) |
.dockerignore | Exclure les fichiers inutiles | ✅ Oui |
.gitignore | Exclure les fichiers generes de Git | ✅ Oui |
README.md | Instructions de configuration et d'execution | ✅ Oui |
pyproject.toml | Metadonnees du projet et configuration des outils | Recommande |
.env.example | Modele pour les variables d'environnement | Recommande |
Makefile | Raccourcis pour les commandes courantes | Optionnel |
Structure de projet standard
ml-project/
├── app/
│ ├── __init__.py
│ ├── main.py # Application FastAPI
│ ├── model.py # Chargement du modele et prediction
│ └── schemas.py # Modeles de requete/reponse Pydantic
├── models/
│ └── model_v1.0.0.pkl # Modele serialise
├── data/
│ ├── raw/ # Donnees originales (gitignore)
│ └── processed/ # Donnees nettoyees
├── tests/
│ ├── __init__.py
│ ├── test_api.py # Tests des endpoints API
│ └── test_model.py # Tests de prediction du modele
├── notebooks/
│ └── exploration.ipynb # Exploration des donnees (gitignore en prod)
├── scripts/
│ └── train.py # Script d'entrainement
├── .gitignore
├── .dockerignore
├── Dockerfile
├── requirements.txt
├── README.md
└── pyproject.toml
Chaque lab de ce cours suit cette structure de projet. Vous la construirez progressivement — en commencant par la configuration de l'environnement dans le TP1, en ajoutant le modele au Module 2, l'API au Module 3, et les tests au Module 5.
Resume
Arbre de decision pour l'infrastructure
Points cles a retenir
| # | Concept | A retenir |
|---|---|---|
| 1 | Environnements virtuels | Toujours isoler les dependances du projet |
| 2 | Fixer les versions | requirements.txt avec des versions exactes |
| 3 | Docker | Tout empaqueter pour la reproductibilite |
| 4 | CPU d'abord | N'utiliser le GPU que si le deep learning l'exige |
| 5 | Options cloud | Plateformes simples (Render, Cloud Run) pour les petits projets |
| 6 | CI/CD | Automatiser les tests et le deploiement |
| 7 | Structure de projet | Suivre les conventions pour la maintenabilite |
Dans le TP1, vous mettrez ces concepts en pratique en configurant votre environnement de projet a partir de zero — creation d'un environnement virtuel, installation des dependances et construction de la structure de projet standard.