Un utilisateur supprime un enregistrement dans une application et, quelques heures plus tard, le retrouve parce qu’une autre application l’a synchronisé. Il ne s’agit généralement pas d’un simple problème de « suppression », mais d’un désaccord entre systèmes sur l’action effectuée, sa signification et les systèmes qui doivent la respecter. Pour le résoudre, il faut convenir de règles métier et d’intégration avant de connecter les applications.
La question pratique n’est pas seulement de savoir comment synchroniser les suppressions entre systèmes. Il faut aussi décider si l’enregistrement doit disparaître, être masqué, être conservé à des fins d’audit ou rester disponible pour des processus en cours. Cet article distingue ces décisions et propose des critères pour les transmettre, éviter les restaurations involontaires et traiter les exceptions.
Pourquoi une suppression locale n’est pas toujours répercutée dans les systèmes connectés
Une intégration peut transmettre les créations et les modifications sans transmettre les suppressions. Par exemple, si elle interroge périodiquement les enregistrements disponibles et n’envoie que ceux qu’elle trouve, un enregistrement absent de la source ne génère pas nécessairement de message à destination. Pour le système destinataire, cette absence peut signifier qu’il n’a jamais reçu l’enregistrement, que la requête a échoué ou que l’enregistrement a été supprimé. Sans règle explicite, il ne peut pas savoir de quel cas il s’agit.
Le problème se pose aussi lorsqu’une application conserve l’enregistrement et qu’une autre le supprime physiquement. Si la synchronisation suivante republie l’enregistrement conservé, le système destinataire peut le recréer. Une logique fondée sur la « dernière mise à jour » ne suffit pas toujours non plus : la suppression peut ne comporter ni horodatage ni version permettant de la comparer aux modifications reçues.
Avant de concevoir la solution, identifiez les applications qui peuvent créer, modifier ou retirer l’enregistrement, celle qui fait autorité pour chaque donnée et ce que signifie son indisponibilité. Dans une synchronisation bidirectionnelle, il faut également décider quoi faire si une application supprime un enregistrement pendant qu’une autre le modifie. Sans cette décision, le système ne peut pas résoudre le conflit de manière fiable.
Supprimer, archiver et désactiver sont des actions différentes
- Suppression physique : l’enregistrement est retiré de la structure active du système. Il peut devenir inaccessible aux fonctions courantes, même si les sauvegardes, journaux techniques ou politiques de conservation obéissent à leurs propres règles. Ne partez pas du principe que cette action efface automatiquement toute trace.
- Archivage : l’enregistrement est conservé, mais retiré des activités quotidiennes, par exemple des vues par défaut. Cette option est utile lorsqu’il faut consulter l’historique ou préserver le contexte. Il faut préciser si les systèmes connectés reçoivent un état « archivé » ou cessent simplement de l’afficher.
- Désactivation : l’enregistrement est conservé, mais ne participe plus à une opération. Un produit désactivé peut rester associé à des commandes antérieures, sans être proposé pour de nouvelles ventes. La définition précise dépend du processus : « inactif » n’a pas de sens universel.
Il est également utile de distinguer une suppression demandée d’une correction. Si un utilisateur a supprimé un enregistrement par erreur, sa restauration peut être appropriée ; s’il s’agit d’une suppression définitive, le rétablir par synchronisation constitue une défaillance. Modélisez ces actions séparément lorsqu’elles entraînent des différences en matière d’autorisations, de conservation ou d’activité opérationnelle.
Choisir la signification en fonction du processus métier
Commencez par examiner les conséquences observables plutôt que les fonctions disponibles dans une interface. Demandez-vous ce que chaque équipe et chaque système devrait pouvoir faire après l’action. Peut-on encore créer une nouvelle opération à partir de cet enregistrement ? Doit-il rester visible dans les recherches historiques ? Des factures, commandes, dossiers ou rapports en dépendent-ils ? Les réponses peuvent mener à des décisions différentes selon le type d’enregistrement.
En règle générale, choisissez la désactivation lorsque l’enregistrement reste une référence valide, mais ne doit plus déclencher de nouvelles opérations ; l’archivage lorsqu’il faut le conserver tout en le retirant de l’activité courante ; et la suppression physique uniquement lorsque les règles applicables et les dépendances autorisent son retrait. Il ne s’agit pas d’une hiérarchie obligatoire : la décision doit correspondre aux besoins métier, aux exigences de conservation et aux fonctions réelles des systèmes.
Documentez la règle de manière vérifiable. Au lieu d’écrire « synchroniser la suppression », précisez quelle action la déclenche, quels systèmes la reçoivent, quel comportement change dans chacun et si l’action peut être annulée. Définissez également l’autorité : si un seul système peut décider de la suppression, les modifications apportées dans les autres ne devraient pas réactiver l’enregistrement sans action autorisée.
Quel signal transmettre par l’intégration
L’intégration a besoin d’une représentation sans ambiguïté. Une possibilité consiste à transmettre un événement de suppression au moment où l’action se produit. Une autre consiste à envoyer un état explicite, tel que actif, archivé ou désactivé, à chaque échange pertinent. Il est également possible d’utiliser un indicateur de suppression qui conserve l’enregistrement et permet de le reconnaître lors des synchronisations ultérieures.
Le choix dépend du fonctionnement de l’échange. Les événements communiquent le changement au moment où il survient, mais les systèmes doivent gérer les nouvelles tentatives, les doublons et les messages reçus dans le désordre. Un état explicite facilite la comparaison de l’état actuel, mais suppose que les requêtes incluent les enregistrements inactifs ou leurs indicateurs de suppression. Si la source omet simplement un enregistrement supprimé, le destinataire ne dispose pas d’un signal suffisant pour distinguer une suppression d’une absence temporaire.
Quel que soit le mécanisme, définissez un identifiant stable pour relier l’enregistrement entre les systèmes, l’état ou le type d’action, la date ou la version du changement et le système source. Le destinataire devrait pouvoir traiter plusieurs fois le même signal sans produire de résultats contradictoires. Si les applications ont des états différents, établissez une correspondance explicite ; ne supposez pas que « archivé » dans l’une signifie « supprimé » dans l’autre.
Comment éviter qu’une synchronisation ne rétablisse des enregistrements
La principale mesure de protection consiste à conserver et à propager l’information de suppression assez longtemps pour que les autres systèmes la reçoivent. Si l’enregistrement est physiquement supprimé à la source avant que l’intégration ne le détecte, la seule preuve de son existence peut disparaître. Un indicateur de suppression ou un événement conservé jusqu’à confirmation de sa propagation évite de dépendre de cette absence.
Le système destinataire doit reconnaître la suppression comme un état, et non comme une instruction temporaire qui disparaît après traitement. S’il reçoit ensuite une ancienne copie marquée comme active, il lui faut une règle de priorité : par exemple, comparer les versions ou les dates de modification et rejeter les données antérieures. Lorsque la restauration est autorisée, exigez une action de réactivation explicite et autorisée, plutôt que de la déduire d’une mise à jour ordinaire.
Prévoyez aussi la reprise après une interruption. Une synchronisation qui redémarre doit pouvoir repérer les changements survenus pendant son arrêt. Définissez comment les signaux sont réémis, comment identifier les messages déjà appliqués et comment examiner les erreurs. Un rapport sur les suppressions en attente et des alertes concernant les enregistrements recréés permettent de détecter le problème avant qu’il ne devienne un écart difficile à retracer.
Références, processus en cours et exceptions
Un enregistrement peut être lié à d’autres données qu’il faut conserver : une commande, une transaction, un dossier d’assistance ou un historique des modifications. Sa suppression physique peut rompre une référence ou empêcher de comprendre une opération passée. Dans ces cas, le système destinataire peut devoir conserver une version minimale ou marquer l’enregistrement comme indisponible pour de nouvelles opérations. La décision doit respecter les politiques applicables et les capacités de chaque système, sans supposer qu’ils gèrent tous les suppressions de la même façon.
Examinez séparément les enregistrements associés à un processus en cours. Si une demande est déjà approuvée, si un produit figure dans une commande ou si une tâche est en cours lorsqu’un enregistrement est désactivé, faut-il annuler le processus, le terminer ou le conserver sans autoriser de nouvelles opérations ? Une règle générale peut ne pas suffire : définissez quel processus prévaut et qui peut trancher l’exception. Si une application n’autorise pas la suppression, attribuez-lui un état de retrait compatible et précisez quelles données elle conserve et qui peut les consulter.
Les corrections nécessitent un parcours distinct. Une suppression erronée peut devoir être annulée, mais la réactivation d’un enregistrement ne devrait pas effacer l’historique de la suppression ni masquer la personne qui a pris la décision. Distinguer « corriger une suppression », « restaurer » et « réactiver » aide à conserver une piste d’audit compréhensible et à éviter qu’un processus automatique ne rouvre des enregistrements par accident.
Liste de contrôle avant le lancement
- Définissez le périmètre : identifiez les types d’enregistrements, les systèmes participants et les actions susceptibles de déclencher une suppression.
- Convenez des significations : précisez ce que supprimer, archiver et désactiver implique pour chaque processus métier.
- Attribuez les responsabilités : déterminez qui peut supprimer et qui peut restaurer ou réactiver.
- Concevez le signal : choisissez un événement, un état ou un indicateur de suppression, puis définissez les identifiants, les versions et le traitement des doublons.
- Protégez les dépendances : vérifiez les références, l’historique, les processus en cours et les systèmes qui n’autorisent pas la suppression.
- Testez les scénarios défavorables : incluez les messages répétés, les interruptions de synchronisation, les modifications simultanées, les anciennes données et les restaurations autorisées.
- Préparez le suivi : convenez de la façon d’examiner les suppressions en attente, les erreurs, les recréations et les écarts, ainsi que des personnes chargées de répondre à chaque alerte.
La bonne décision n’est pas toujours de supprimer. Elle consiste à transmettre une intention métier claire, à conserver les informations nécessaires et à faire en sorte que tous les systèmes connectés l’interprètent de manière cohérente. Si la règle peut être exprimée sous forme d’états, de responsabilités, d’exceptions et de tests observables, une synchronisation aura beaucoup moins de chances de transformer une suppression en création inattendue.