5.4Déploiement & CI/CD (GitHub Actions, cloud)
L'essentiel en 30 secondes
- CI gardienne : à chaque push, checkout → install → ruff + pytest — le rouge bloque, le vert autorise.
- Livrer versionné : image Docker au registre ou plateforme connectée au dépôt — chaque mise en ligne est traçable.
- Prod sobre : secrets hors YAML, logs et /health, rollback testé — déployer, c'est pouvoir revenir.
Mini-cas filé — Nabil met en ligne à Alger
L'analyse conteneurisée de Nabil tourne bien — mais seulement sur les postes de l'équipe à Alger. Il la met en ligne : dépôt Git connecté, workflow GitHub Actions qui lance ruff et pytest à chaque push, image versionnée livrée sur une plateforme connectée au dépôt, logs et endpoint de santé en place. Dernier épisode des cas 5.1-5.3 — Nabil boucle du code pro à l'app vivante.
Dernier épisode des cas 5.1-5.3 — Nabil boucle conception, async et Docker avec la mise en production.
1. La CI : tester à chaque push
Le workflow GitHub Actions est le gardien : checkout → installer Python → pip install -r requirements → ruff + pytest. Chaque push est prouvé en minutes : le rouge bloque la fusion, le vert autorise. La CI n'est pas une option qu'on « mettra plus tard » — elle est en place dès le premier test. Nabil provoque volontairement un échec pour voir l'alerte : le jour où ça casse pour de vrai, il saura lire le rouge.
Le badge vert du README prouve l'exigence : style + tests à chaque changement, sans intervention humaine.
2. Livrer : image ou plateforme
Deux voies complémentaires. L'image Docker poussée au registre (voir 5.3) : traçable, reproductible, déployée où on veut. Ou la plateforme connectée au dépôt (type Render, Railway, Fly et équivalents) : chaque push vert met le site à jour automatiquement — simple pour débuter. Secrets en secrets du dépôt, jamais dans le YAML : la prod se configure, elle ne se code pas. Nabil compare les offres au moment de choisir (les formules évoluent) et vise la voie simple d'abord, le contrôle ensuite.
Dans les deux cas, chaque livraison est versionnée (tags, SHA) : on sait exactement quoi est en ligne.
3. Le minimum prod : logs, santé, rollback
Déployer = pouvoir revenir. Le minimum : logs structurés (logging), endpoint /health pour la supervision, versions pour revenir en arrière. Sans rollback testé, chaque mise en prod est un saut sans parachute. Nabil teste le retour avant le grand soir : le jour d'un incident, il restaure au lieu d'improviser — et fait valider le choix d'infrastructure et les accès par sa DSI avant d'exposer des données réelles.
Sans ce trio, on ne déploie pas : on parie.
🔎 Exemple concret — Le workflow de Nabil
Style + tests à chaque push, badge vert en preuve.
name: ci
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with: {python-version: "3.12"}
- run: pip install -r requirements.txt
- run: ruff check . && pytest -qLecture : style + tests à chaque push — le rouge bloque la fusion.
Leçon : le badge vert du README prouve l'exigence en continu.
Vocabulaire de la section
- Déploiement
- Rendre l'app accessible en ligne, hors de votre poste.
Exemple simple : L'analyse de Nabil quitte localhost pour une adresse publique.
Ce que ce n'est pas : un script qui ne tourne que sur son PC.
Réflexe : mon app est-elle joignable hors de mon poste ?
- CI
- Tester automatiquement chaque changement, dès le premier test.
Exemple simple : Chaque push de Nabil lance ruff et pytest.
Ce que ce n'est pas : des tests lancés à la main quand on y pense.
Réflexe : un push peut-il passer sans preuve ?
- Pipeline
- Suite d'étapes auto (tests, build, déploiement) déclenchée à chaque push.
Exemple simple : Le workflow de Nabil : installer, contrôler, tester.
Ce que ce n'est pas : une mise en ligne manuelle à coups de copier-coller.
Réflexe : ma livraison est-elle reproductible ?
- GitHub Actions
- Pipelines décrits en YAML versionné dans .github/workflows.
Exemple simple : Le fichier ci.yml de Nabil, relu comme du code.
Ce que ce n'est pas : un serveur mystérieux qui déploie on ne sait comment.
Réflexe : mon pipeline est-il versionné et relisible ?
- Rollback
- Revenir à la version précédente, testé avant le besoin.
Exemple simple : Nabil restaure la version précédente après un incident.
Ce que ce n'est pas : réparer en panique directement en prod.
Réflexe : ai-je testé mon retour en arrière ?
En pratique — Automatiser tests et déploiement
- Versionnez votre projet avec Git et poussez-le sur un dépôt GitHub (git init, add, commit, push).
- Créez un workflow GitHub Actions (.github/workflows/ci.yml) qui installe les dépendances et lance pytest à chaque push.
- Vérifiez dans l'onglet « Actions » que le pipeline s'exécute et passe au vert ; provoquez un échec de test pour voir l'alerte.
- Déployez l'application sur une plateforme cloud (Render/Railway) connectée au dépôt : chaque push met le site à jour automatiquement.
Script prêt à dire — annoncer la mise en ligne
« Notre analyse est prête à sortir de localhost : je mets la CI dès le premier test — ruff et pytest à chaque push, le rouge bloque. Je livre versionné via la plateforme connectée au dépôt, secrets en secrets du dépôt, logs et endpoint de santé en place, rollback testé. Avant d'exposer des données réelles, je fais valider l'infrastructure et les accès par la DSI. »
À dire au responsable pour faire valider la mise en ligne et le circuit DSI sur les données sensibles.
Modèle copier-coller — workflow CI Python générique
name: ci
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with: {python-version: "3.12"}
- run: pip install -r requirements.txt
- run: ruff check . && pytest -qSolo / petit budget
Nabil seul : le workflow minimal (ruff + pytest) suffit — la CI gratuite du dépôt garde la prod.
TPE / équipe réduite
Badge vert + rouge qui bloque la fusion : personne ne livre sans preuve, même pressé.
PME à Alger
Nabil fait valider hébergeur, accès et sauvegardes par la DSI à Alger avant d'exposer des données réelles.
Équipe qui démarre
Binôme : l'un écrit le workflow, l'autre vérifie secrets, /health et rollback ; revue avant la première prod.
✓ Bonnes pratiques
- CI dès le premier test : le vert autorise, le rouge bloque.
- Secrets en secrets du dépôt, jamais en clair dans le YAML.
- Rollback testé avant la prod : déployer, c'est pouvoir revenir.
✗ Pièges fréquents
- « On mettra la CI plus tard » (les régressions partent en silence).
- Secrets en clair dans le YAML versionné.
- Déployer sans retour possible ni supervision (/health, logs).
Points clés à retenir
- Le déploiement rend l'application accessible en ligne (cloud/PaaS).
- La CI/CD automatise tests et mise en ligne à chaque changement du code.
- GitHub Actions décrit les pipelines dans un fichier YAML versionné.
- Git/GitHub est le socle : versionnement, collaboration et déclencheur des pipelines.
Défi 48h — appliquez demain
Ajoutez le workflow ci-dessus à 1 dépôt : pousse-t-il au vert — et le rouge bloque-t-il après un échec provoqué ?
- Je peux expliquer CI vs CD en une phrase.
- Mon workflow teste à chaque push (vert prouvé).
- Je sais où vont les secrets (hors YAML).
Questions fréquentes
Qu'apporte la CI/CD par rapport à un déploiement manuel ?
Elle supprime les erreurs humaines et le temps perdu : à chaque modification, les tests s'exécutent automatiquement et, s'ils passent, l'application est mise en ligne sans intervention. On livre plus souvent, plus vite et plus sûrement — un standard des équipes modernes. Et le rouge qui bloque la fusion vaut tous les rappels à l'ordre.
Où héberger une application Python à moindre coût ?
Des plateformes connectées au dépôt (type Render, Railway, Fly et équivalents) proposent des paliers d'entrée et un déploiement automatique depuis GitHub : idéal pour débuter. Pour plus de contrôle, les grands clouds sont plus puissants mais plus complexes — à réserver aux besoins qui le justifient. Comparez les offres au moment de choisir (elles évoluent) et faites valider par la DSI avant d'exposer des données sensibles.
Que fait un pipeline CI/CD (ex. GitHub Actions) ?