From 993934d88404f32868eedfc4729f7a2e12719826 Mon Sep 17 00:00:00 2001
From: BerengereC <160597217+BerengereC@users.noreply.github.com>
Date: Tue, 21 Jan 2025 10:59:49 +0100
Subject: [PATCH] Update docs/adr/0056-migrate-down.md

Co-authored-by: LEGO Technix <109212476+lego-technix@users.noreply.github.com>
---
 docs/adr/0056-migrate-down.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/docs/adr/0056-migrate-down.md b/docs/adr/0056-migrate-down.md
index 5c0ab6cf6fb..b83a02503fb 100644
--- a/docs/adr/0056-migrate-down.md
+++ b/docs/adr/0056-migrate-down.md
@@ -7,7 +7,8 @@ Date : 2024-12-19
 Draft
 
 ## Contexte
-
+Dans tout ce document, les migrations évoquées sont des migrations ayant vocation à changer le schéma des bases de données et des données impactées le cas échéant. 
+Toute modification de données pour des besoins autres que l'évolution des schémas des bases de données (reprise de données, backfill, etc.) doivent faire l'objet de scripts en dehors des migrations. 
 Nous souhaitons clarifier les procédures de rollback sur l'environnement production (retour en arrière de version classiquement).
 Même si nous préférons privilégier l'application d'un patch en production pour résoudre un incident, il peut être nécessaire de faire un rollback de version, selon la nature de l'incident.
 Dans le contexte actuel, l'application d'un patch est une opération longue (25 minutes minimum). Une semi-automatisation permettrait d'amoindrir ce délai et de préférer cette solution au rollback de version dans certains cas.