Les migrations sont la façon dont Django propage les modifications que vous apportez à vos modèles (ajout d'un champ, création d'un modèle) dans le schéma de base de données — ce sont des fichiers de modification de base de données générés automatiquement et contrôlés en version. Vous modifiez les modèles en Python ; les migrations gardent la base de données synchronisée.
python manage.py makemigrations
python manage.py migrate
makemigrations détecte les modifications des modèles et génère un fichier de migration ; migrate applique les migrations en attente à la base de données réelle. Vous écrivez du Python (modifications des modèles), et Django génère et exécute le SQL.
# migrations/0002_article_views.py (auto-generated)
class Migration(migrations.Migration):
dependencies = [("blog", "0001_initial")] # ordering — depends on the previous one
operations = [
migrations.AddField( # the change
model_name="article",
name="views",
field=models.IntegerField(default=0),
),
]
Les migrations sont validées dans le contrôle de version, ainsi l'historique du schéma de base de données est suivi aux côtés du code. Chaque développeur et chaque environnement applique les mêmes migrations pour atteindre le même schéma — reproductible et cohérent.
✓ Schema changes are version-controlled (tracked with the code, reviewable in PRs)
✓ Reproducible — every dev/staging/production DB gets the same schema by running migrate
✓ No manual, error-prone SQL — Django generates the correct ALTER statements
✓ Reversible — many migrations can be rolled back (migrate <app> <previous>)
✓ Team-friendly — schema changes flow through the normal code-review process
python manage.py showmigrations # see which migrations are applied/pending
python manage.py sqlmigrate blog 0002 # preview the SQL a migration will run
python manage.py makemigrations --empty # a blank migration for custom/data changes
python manage.py migrate blog 0001 # roll BACK to a previous migration
Migrations can also transform DATA (e.g. populate a new field, backfill values)
via RunPython operations — useful when a schema change needs accompanying data changes.
Les migrations sont essentielles pour travailler avec la couche de base de données de Django — elles résolvent le problème critique de maintenir le schéma de base de données synchronisé avec vos modèles Python de manière sûre, reproductible et conviviale pour l'équipe.
Les comprendre est une connaissance fondamentale quotidienne : le flux de travail makemigrations → migrate est la façon dont chaque modification de schéma se produit (vous modifiez les modèles, Django génère et applique le SQL), donc vous ne pouvez pas développer une application Django pilotée par les données sans cela.
La valeur clé est que les migrations rendent les modifications de schéma contrôlées en version (suivi aux côtés du code, examinables dans les demandes de tirage), reproductibles (chaque environnement — la machine de chaque développeur, la mise en scène, la production — atteint le schéma identique en exécutant les mêmes migrations), et sûres (Django génère du SQL correct, souvent réversible, au lieu des instructions ALTER TABLE manuelles sujettes aux erreurs).
Cela élimine toute une catégorie de problèmes autour de la dérive de schéma, des environnements incohérents et des modifications manuelles de base de données risquées.
Connaître le flux de travail, le fait que les migrations sont validées dans le contrôle de source, comment les inspecter et les annuler, et qu'elles peuvent également gérer les transformations de données (remplissage de données/migration de données, pas seulement du schéma) est nécessaire pour tout projet Django réel.
Les migrations sont la façon dont les équipes Django font évoluer leur schéma de base de données de manière collaborative et fiable au cours de la vie d'un projet, ce qui rend ce matériel essentiel et incontournable.