Exemple de BIA – comment prioriser les processus critiques, RTO et RPO

Par Mallbutiken · Données vérifiées le 30 septembre 2026 · Environ 8 minutes de lecture

Une analyse d'impact sur l'activité (BIA) n'est utile que lorsqu'elle débouche sur des priorités. L'analyse doit aider l'organisation à comprendre quels processus doivent être rétablis en priorité, comment les conséquences s'aggravent avec le temps, quelles dépendances sont critiques et quels objectifs de rétablissement sont réellement nécessaires.

L'exemple ci-dessous est illustratif. Le RTO, le RPO et la durée d'interruption tolérable ne doivent pas être copiés tels quels. Les valeurs doivent être déterminées en fonction de votre activité, des exigences légales, des engagements clients, de la technique et des conséquences réelles.

Exemple : une petite entreprise de commerce en ligne et de services

Supposons que l'entreprise vende des produits numériques et physiques en ligne. L'activité dépend de la boutique en ligne, du paiement, du service client, de la gestion des commandes, de la comptabilité et de plusieurs services SaaS externes. La direction veut savoir ce qui doit fonctionner en priorité après une interruption informatique majeure.

Pour chaque activité, le responsable du processus est interrogé sur les conséquences après, par exemple, 2 heures, 8 heures, 24 heures, 3 jours et 1 semaine. Les conséquences sont évaluées en termes de finances, client, juridique/conformité, exploitation, réputation et sécurité.

Exemple de BIA simplifié

Processus Conséquence importante Priorité RTO exemple RPO exemple
Paiement & Checkout Perte de ventes et impossibilité pour les clients de finaliser leurs achats 1 4 heures 15 minutes
Gestion des commandes Arrêt des livraisons et accumulation des files d'attente 2 8 heures 1 heure
Service client Délais de réponse accrus et hausse des réclamations 3 24 heures 4 heures
Rapports financiers Retards, mais impact direct limité sur les clients 4 72 heures 24 heures

Le tableau n'est que le résultat final du raisonnement. L'essentiel est de comprendre pourquoi le checkout est passé avant le service client et quelles hypothèses sous-tendent le RTO/RPO.

Évaluer l'évolution des conséquences dans le temps

Un processus n'est pas automatiquement "critique" simplement parce qu'il est important au quotidien. Le BIA doit poser la question de savoir quand la conséquence devient inacceptable. Une interruption de deux heures peut être gérable, tandis qu'une journée entière peut entraîner des conséquences économiques ou juridiques majeures.

Documentez donc les seuils. Exemple : après quatre heures, la perte de revenus devient significative ; après huit heures, une promesse client est rompue ; après une journée, des files d'attente manuelles ingérables apparaissent. Cela donne une base réelle aux objectifs de continuité.

Distinguer la tolérance maximale et les objectifs de rétablissement

Les organisations utilisent parfois des termes comme MTPD (Durée maximale d'interruption tolérable) pour désigner le point où la conséquence n'est plus acceptable. Le RTO doit, en pratique, être fixé avec une marge suffisante avant cette limite, car le rétablissement ne doit jamais être planifié à la toute dernière minute.

RTO et RPO – les utiliser correctement

Le RTO (Recovery Time Objective) décrit l'objectif de délai pour rétablir le service ou le processus après une interruption. Le RPO (Recovery Point Objective) décrit la durée maximale de perte de données acceptable lors du rétablissement.

Si le checkout a un RTO de 4 heures mais que la solution technique nécessite 12 heures pour être restaurée, il existe un écart. Le BIA a alors mis en évidence un risque qui doit être géré par une meilleure redondance, un rétablissement plus rapide, une procédure de secours ou une révision de l'objectif commercial.

Si le RPO est de 15 minutes mais que la sauvegarde n'est effectuée qu'une fois par jour, le même type d'écart existe. Le RPO n'est donc pas un souhait que l'on peut inscrire dans un plan sans support technique.

Cartographier les personnes, les systèmes et les fournisseurs

Pour chaque processus critique, le BIA doit identifier les dépendances. Il peut s'agir de :

  • personnel clé et effectifs minimaux,
  • locaux et équipements,
  • systèmes de gestion et intégrations,
  • services d'identité et de connexion,
  • données et documentation,
  • téléphonie et communication,
  • fournisseurs et sous-traitants critiques,
  • électricité, réseau et autres infrastructures.

Il est fréquent qu'un service « secondaire » se révèle être un point de défaillance unique (single point of failure). Par exemple, le fournisseur d'identité : le commerce en ligne peut être techniquement opérationnel, mais le personnel ne pourra pas l'administrer si le SSO est hors service.

Comment traduire les résultats du BIA dans le plan de continuité

Le BIA répond à la question de savoir ce qui doit être priorisé. Le plan de continuité répond à la question de savoir comment l'activité doit se poursuivre et être rétablie.

Pour les processus à haute priorité, le plan doit donc indiquer les critères d'activation, les responsabilités, les procédures de secours, les listes de contacts, l'escalade fournisseur, l'ordre de rétablissement, la communication et les modalités de retour à la normale. Lisez ce qu'un plan de continuité devrait contenir.

Si le service technique est acheté en mode SaaS, les objectifs de rétablissement doivent en outre être comparés au SLA du fournisseur. Consultez le guide sur les SLA, RTO et RPO.

Erreurs courantes dans le travail de BIA

  • Tous les processus deviennent critiques. Dans ce cas, l'analyse n'a pas priorisé.
  • Le RTO est fixé par l'informatique seule. L'objectif doit reposer sur les besoins de l'activité, puis être testé par rapport à la capacité technique.
  • Le RPO n'a aucun lien avec les données. Différents volumes de données peuvent nécessiter des tolérances différentes.
  • Les dépendances sont ignorées. Surtout l'identité, les intégrations et les fournisseurs externes.
  • Personne n'est responsable des résultats. Chaque processus critique nécessite un propriétaire responsable.
  • Le BIA n'est jamais mis à jour. De nouveaux systèmes, produits et fournisseurs peuvent modifier les priorités.

Check-list pour votre propre BIA

  • Lister les activités de l'entreprise et leurs responsables.
  • Évaluer les conséquences selon plusieurs intervalles de temps.
  • Identifier le moment où la conséquence devient inacceptable.
  • Prioriser les processus selon l'ordre de rétablissement.
  • Fixer des objectifs RTO et RPO préliminaires.
  • Cartographier le personnel, les systèmes, les données et les fournisseurs.
  • Comparer les objectifs avec la capacité réelle de rétablissement.
  • Documenter les écarts et les mesures à prendre.
  • Transférer les résultats dans le plan de continuité.
  • Tester et réévaluer après des changements majeurs.
Modèle de plan de continuité et BIA avec Word, PDF et Excel

Besoin d'un BIA et d'un plan de continuité dans le même flux de travail ?

Le modèle de Plan de continuité + BIA 2026 de Mallbutiken combine analyse, priorisation et planification de la continuité dans des fichiers Word, PDF et Excel. Prix en boutique : 249 SEK.

Voir Plan de continuité + BIA

Questions fréquentes

Le RTO est-il la même chose que la durée d'interruption maximale tolérable ?

Non. Le RTO est un objectif de rétablissement. La durée maximale tolérable décrit une limite de tolérance externe. L'objectif de rétablissement doit normalement être fixé plus tôt.

Tous les processus doivent-ils avoir un RPO ?

Le RPO est surtout pertinent là où le rétablissement des données est un élément central. Pour les processus manuels, d'autres mesures de rétablissement peuvent être plus utiles.

À quelle fréquence le BIA doit-il être mis à jour ?

Il n'existe pas d'intervalle universel. Procédez à une revue régulière et réévaluez également lorsque des systèmes critiques, des fournisseurs, des processus ou des exigences changent.

Retour au blog