Sauvegarde et panne système : votre ERP redémarre, mais que deviennent vos flux entre applications ?

Les sauvegardes applicatives, qu'elles soient menées par vos équipes ou par vos prestataires, permettent de retrouver l'usage de vos outils critiques après un incident. Ce risque est concret puisqu'en 2025, 40 % des structures matures dotées d'une équipe sécurité ont déclaré un incident majeur. Mais une fois les applications remises en route, les connexions entre elles (mappings, scripts d'interfaçage, configuration du middleware, webhooks, fichiers en attente) restent très souvent cassées. La préparation de crise et de reprise est un sujet déjà cadré, avec sa méthodologie propre. Y intégrer les flux inter-applicatifs de l'entreprise détermine si le retour à la normale est réel, ou seulement partiel.

Avant la panne : qui décide, qui fait quoi

C'est dans ce temps que l'essentiel se joue : une réponse improvisée à une panne amplifie le stress et peut aggraver les dégâts.

Cellule de crise et rôles définis à l'avance

Trois rôles sont à définir avant l'incident :

• un décideur qui arbitre les priorités,
• un contact technique (interne ou prestataire) capable d'agir,
• un porte-parole pour la communication interne et externe.

Dans une gouvernance collégiale sans hiérarchie formelle, ce premier rôle peut poser problème : personne n'a mandat pour trancher seul, et la décision se négocie pendant que le système reste indisponible.

Un rôle mérite aussi une attention particulière : la personne qui connaît le détail des flux entre applications. Elle a souvent construit l'interfaçage elle-même, au fil du temps, sans que ce savoir soit documenté ailleurs. Si elle n'est pas jointe, ou pas disponible, la restauration de l'application ne suffit pas à relancer les flux.

Sur ce point, même les organisations les mieux équipées ont elles aussi une marge de progression : le même baromètre CESIN indique que 62 % des organisations interrogées réalisent des exercices de crise réguliers, ce qui signifie que 38 % ne testent jamais leurs procédures, alors qu'elles disposent d'une fonction sécurité dédiée. Pour les organisations moins préparées, ce chiffre donne un ordre de grandeur du travail restant.

Le plan est-il accessible si le système qui le contient tombe ?

Un plan de reprise stocké uniquement dans l'outil qui vient de tomber ne sert à rien. La même logique s'applique à la documentation des flux : si le détail d'un mapping ou d'une configuration de synchronisation n'existe que dans la tête d'une personne ou dans un fichier hébergé sur le système en panne, ce savoir est indisponible au moment précis où il devient nécessaire.

Mesurer le risque avant qu'il ne se matérialise

Comme pour les applications critiques, estimer une probabilité d'incident et un impact métier, flux par flux, a plus de valeur avant la panne qu'après.

Une fois cette estimation faite, trois décisions sont possibles :

• accepter le risque tel quel si le coût d'une protection dépasse l'impact potentiel,
• le réduire en renforçant sauvegarde et tests de restauration,
• ou le transférer via une assurance cyber ou une clause contractuelle avec le prestataire.

La surprise vient souvent de l'absence de choix explicite : par défaut, une organisation accepte le risque sans l'avoir décidé.

Détecter et qualifier

Une panne se détecte vite : un utilisateur ne peut plus se connecter. Un dysfonctionnement applicatif ou une panne de flux se détecte beaucoup plus lentement. Deux applications peuvent chacune fonctionner normalement pendant que l'échange entre elles s'est arrêté silencieusement. Le signal remonte souvent plusieurs jours plus tard, à la clôture ou au rapprochement, sous forme d'écart inexpliqué entre deux systèmes.

Sans surveillance ni seuil de déclenchement, le moment où l'on active le plan de reprise se négocie dans l'urgence plutôt que de suivre une procédure établie.

Une sauvegarde existe-t-elle réellement ?

Que couvre la sauvegarde en place ? Les données de l'application, très probablement. Sa configuration, parfois. La configuration des flux qui la connectent aux autres (mappings, jobs de synchronisation, paramétrage du middleware ou de l'ESB) l'est plus rarement. Ces éléments d'interfaçage ont souvent été construits en interne, en dehors du périmètre couvert par la sauvegarde standard d'un éditeur SaaS.

La question concrète à se poser est : si l'ERP est restauré demain matin, qui reconfigure le flux vers la comptabilité, et à partir de quelle documentation ?

Cette sauvegarde fonctionne-t-elle ?

Un test de restauration qui vérifie seulement que l'application redémarre ne prouve rien sur les flux. Le test complet consiste à restaurer, puis à vérifier qu'une donnée créée dans une application se propage toujours correctement vers les autres. C'est ce deuxième temps qui manque le plus souvent.

RTO : combien de temps pour remonter le système ?

Le RTO (temps de reprise) affiché par un éditeur ou un hébergeur couvre l'application seule. Le RTO réel, celui que vit le métier, inclut le temps de reconfiguration des flux — porté, dans le meilleur des cas, par une seule personne qui a construit l'interfaçage à l'origine. Si cette personne est indisponible, le RTO technique et le RTO métier peuvent diverger de plusieurs jours.

Sait-on remonter le système à tout moment, ou seulement si cette personne répond au téléphone ?

RPO : jusqu'à quel point dans le temps la restauration nous ramène-t-elle ?

Le RPO (perte de données maximale acceptable) de l'application et celui des flux peuvent également diverger. Une application restaurée à J-1 peut ensuite recevoir un flux resynchronisé depuis une base plus ancienne encore, créant des incohérences entre systèmes plutôt qu'une simple perte de données homogène.

Et les messages en transit au moment de la panne ?

Une facture en cours d'envoi vers la comptabilité, un webhook qui n'a pas confirmé sa réception : ce qui circulait entre deux applications au moment précis de l'incident pose une question distincte de la sauvegarde. Ce contenu est-il perdu, mis en file d'attente pour un rejeu automatique une fois le système revenu, ou faut-il l'identifier et le renvoyer manuellement ? Sans réponse connue à l'avance, cette vérification se fait et s'oublie dans l'urgence de la remise en route.

Pendant l'indisponibilité

Côté IT

Constater l'ampleur réelle de la panne, isoler ce qui doit l'être, éviter les actions correctives non coordonnées qui compliquent le diagnostic. Lancer la procédure de restauration documentée. Puis, avant de déclarer l'incident résolu, vérifier explicitement l'état des flux entre applications.

Côté métier

Un mode dégradé identifié à l'avance permet de basculer certaines tâches sur un support manuel temporaire. À ne pas négliger : consigner ce qui est saisi manuellement pendant l'indisponibilité, pour pouvoir le rapprocher une fois les flux automatiques rétablis, sans double saisie ni perte à la reprise.

Après l'incident

1. Mesurer l'impact : durée réelle d'indisponibilité, données perdues, mais aussi flux restés interrompus après le retour de l'application : quels rapprochements devront être refaits manuellement.
2. Identifier : la cause racine, pas seulement le symptôme visible.
3. Remédier : corriger dans l'urgence pour repartir.
4. Réparer : traiter la cause pour que l'incident ne se reproduise pas à l'identique, flux compris.
5. Apprendre : mettre à jour le plan de reprise et les cibles de RTO/RPO à la lumière de ce qui vient de se passer, en incluant la documentation des flux nouvellement découverts.

La communication, fil rouge de la chronologie

À la qualification

Le porte-parole désigné en amont communique dès que l'incident est qualifié.

Dès le confinement

Une information courte part avant même d'avoir mesuré l'impact complet : ce qui est su, ce qui est en cours, l'heure du prochain point. Le silence inquiète souvent plus que la panne elle-même.

Pendant l'indisponibilité

Des points d'étape réguliers, à intervalle annoncé.

À la sortie de crise

Un bilan factuel : ce qui a été perdu, ce qui a changé, ce qui a été mis à jour dans le plan pour la prochaine fois.

Ce que révèle ce diagnostic

Ces questions font partie du périmètre d'un diagnostic de flux inter-applicatifs : cartographie des connexions entre vos applications, identification des points de rupture, priorisation des risques. Elles complètent un audit de sauvegarde classique sur le point qu'il couvre le moins souvent : les flux entre applications, condition d'un plan de reprise réel et pas seulement partiel.

À lire aussi : Automatiser les flux pour sécuriser le temps, les coûts et la fiabilité → · 5 signaux que vos applications ne se parlent plus →

Questions fréquentes

Notre prestataire nous garantit des sauvegardes régulières. Est-ce suffisant pour couvrir nos flux entre applications ?

Une sauvegarde standard couvre les données de l'application, parfois sa configuration. La configuration des flux qui la connectent aux autres (mappings, jobs de synchronisation, paramétrage du middleware, webhooks) est rarement dans ce périmètre. Ces éléments ont souvent été construits en interne, en dehors de la sauvegarde de l'éditeur SaaS. La question concrète : si votre ERP est restauré demain matin, qui reconfigure le flux vers la comptabilité, et à partir de quelle documentation ?

Comment savoir si notre test de restauration couvre vraiment les flux inter-applicatifs ?

Un test de restauration qui vérifie seulement que l'application redémarre ne prouve rien sur les flux. Le test complet consiste à restaurer l'application, puis à vérifier qu'une donnée créée dans une application se propage correctement vers les autres. C'est ce deuxième temps qui manque dans la quasi-totalité des exercices de reprise.

Pourquoi le RTO de notre hébergeur ne correspond-il pas à notre temps réel de reprise ?

Le RTO affiché par un éditeur ou un hébergeur couvre l'application seule. Le RTO réel inclut le temps de reconfiguration des flux, porté, dans le meilleur des cas, par une seule personne qui a construit l'interfaçage à l'origine. Si cette personne est indisponible, le RTO technique et le RTO métier peuvent diverger de plusieurs jours.