Rollback en production : séparer le retour du code de celui des données

Un rollback ne remet pas nécessairement une application dans son état précédent : le code et les données ne se restaurent pas toujours de la même manière. Pour préparer une mise en production, une PME a donc intérêt à décider séparément comment revenir sur le changement logiciel et comment traiter les données déjà modifiées.

Dans son retour sur la mise en production, l’équipe d’AXOPEN recommande de tester sérieusement avec le métier et de prévenir les personnes concernées avant le déploiement, afin de pouvoir relier un problème à la bascule.

Elle distingue aussi le retour sur le code, présenté comme facile, de celui sur les données, jugé beaucoup moins simple. Ce constat donne un bon point de départ à une décision souvent trop résumée à « on fera un rollback si besoin ».

Premier choix : le problème vient-il du changement livré ?

Avant de prévoir une marche arrière, définissez ce qui déclenchera la décision. Il peut s’agir d’un parcours métier qui ne fonctionne plus, d’une donnée incorrecte ou d’un traitement qui ne se termine pas comme attendu. Les seuils et les signaux doivent dépendre de l’application : mieux vaut préciser les scénarios importants pour l’entreprise que reprendre des critères génériques sans savoir s’ils correspondent à son activité.

Si le défaut n’est pas relié au changement, revenir immédiatement au code précédent risque de ne pas résoudre le problème. Si le lien est plausible, la décision suivante dépend de ce qui a déjà changé côté données :

• Aucune donnée métier n’a été modifiée par la nouvelle version : étudier un retour du code, en vérifiant que la version précédente peut toujours fonctionner avec l’environnement actuel.
• Des données ont été créées ou transformées : préciser ce qu’elles sont devenues et si l’ancienne version sait encore les lire. Le retour du code ne répond pas, à lui seul, à cette question.
• La situation n’est pas claire : suspendre les actions qui pourraient aggraver l’écart, puis demander une décision conjointe des responsables technique et métier à partir des éléments observables.

Cette séparation évite de confondre deux décisions : « faut-il retirer le code ? » et « que faut-il faire des données déjà touchées ? »

Deuxième choix : quelle stratégie pour les données ?

Pour chaque modification de données liée à la mise en production, demandez à l’équipe de décrire le chemin de retour, plutôt que de vous contenter d’une mention « rollback prévu ». Une migration peut-elle être annulée ? Les données créées depuis la bascule doivent-elles être conservées ? L’ancienne version peut-elle les interpréter ? Si la réponse dépend du cas, quels cas ont été testés ?

AXOPEN souligne que le retour arrière sur les données est moins simple que celui sur le code, et recommande de préparer le rollback, de fixer une limite de temps et de tenir compte de la volumétrie. L’équipe avertit également qu’un volume qui passe en recette peut bloquer en production. Ces points ne donnent pas une procédure universelle : ils indiquent ce que le plan de mise en production doit éclaircir.

Selon le changement, les options à examiner peuvent être de restaurer un état antérieur, de corriger les données vers l’avant, ou de conserver le code livré tout en désactivant le parcours qui pose problème. Ce sont des pistes à valider pour l’application concernée, pas des solutions interchangeables. Pour chacune, demandez les conséquences métier, les prérequis, la personne autorisée à décider et la preuve que l’action a fonctionné.

Si le code peut revenir en arrière, qui décide et jusqu’à quand ?

Un retour du code n’est utile que si l’équipe sait dans quelles conditions le déclencher. Avant le déploiement, les responsables concernés peuvent s’accorder sur les points suivants :

• le changement concerné et les parcours métier à vérifier après sa mise en production ;
• les signaux qui conduisent à poursuivre, à suspendre ou à revenir en arrière ;
• la personne qui prend la décision technique et celle qui confirme l’impact métier ;
• la durée pendant laquelle le retour reste réaliste, notamment si des données ont déjà évolué ;
• les actions à éviter pendant l’analyse d’un incident et le canal pour prévenir les personnes concernées.

Fixer une limite de temps, comme le recommande AXOPEN, oblige à traiter explicitement la question des données qui continuent d’évoluer après le déploiement. La durée ne se choisit pas au hasard : elle doit correspondre au temps nécessaire pour observer les parcours utiles et décider avec les personnes responsables.

Le volume de recette suffit-il à représenter la production ?

Pas nécessairement. Un scénario réussi sur un petit jeu de données ne démontre pas à lui seul que le traitement se comportera de la même façon avec les volumes attendus. AXOPEN attire précisément l’attention sur ce décalage possible entre recette et production. Pour réduire cette incertitude, demandez quel volume a été essayé, ce qui n’a pas été couvert et comment l’équipe surveillera le traitement pendant la bascule. Ne présentez pas un essai limité comme la preuve d’un comportement garanti.

Cette vérification concerne aussi la durée de l’opération et la possibilité de l’interrompre proprement. Si l’essai représentatif n’est pas réalisable avant le déploiement, nommez cette limite et adaptez la décision : par exemple, réduire le périmètre de la bascule ou prévoir un arrêt avant que des données supplémentaires ne rendent le retour plus délicat.

Le plan à demander avant de lancer la bascule

Pour rendre ces arbitrages utilisables, formalisez un document court qui relie le symptôme à l’action et à son responsable. Le cadrage des critères d’acceptation aide à définir ce qui doit être vérifié ; un runbook d’incident utilisable peut ensuite préciser les actions à mener si un problème survient.

1. Décrire les changements livrés au code et aux données, ainsi que les parcours métier concernés.
2. Indiquer les vérifications réalisées, les volumes couverts et les limites de ces essais.
3. Séparer les options de retour du code des options de traitement des données, avec leurs prérequis et leurs risques métier.
4. Nommer les responsables de la décision, les signaux de poursuite ou d’arrêt et la limite de temps convenue.
5. Préciser comment les personnes concernées seront informées et quelles preuves seront conservées après la décision.

La bonne question n’est donc pas seulement « peut-on revenir à la version précédente ? », mais « que restera-t-il à traiter si le code revient, alors que les données ont déjà changé ? ». Si l’équipe ne peut pas répondre clairement, le plan de mise en production n’est pas encore assez précis pour engager ce retour en confiance.