Planification de reprise opérationnelle

Construire une séquence de reprise vérifiable à partir des dépendances et tâches tenues à jour, de ressources explicites, de simulations de panne et d’objectifs RTO/RPO.

Entrée

Résultat

La planification de reprise commence par des faits opérationnels tenus à jour : dépendances des processus, tâches, durées, ressources et objectifs horaires. L’IA sélectionne des passages substantiels de processus et de tâches à examiner. Le serveur calcule les processus aval affectés, une séquence respectant les capacités et les blocages non résolus. La fin prévue, la comparaison RTO et les preuves d’âge des sauvegardes restent distinctes d’une affirmation de reprise réussie.

Tes textes, pages et images sont traités sur nos propres serveurs dans l'UE. Centre de confiance

Essayer maintenant Tarifs

À qui cela s'adresse

Équipes de continuité opérationnelle et informatique préparant un exercice sur table à partir de procédures internes de reprise tenues à jour. Il ne s’agit pas d’un contrôleur d’incident en direct, d’un guide d’urgence médicale ou d’un planificateur d’évacuation. Les procédures internes approuvées et les spécialistes responsables restent nécessaires.

Utilisations typiques

Simuler la panne d’un processus et suivre ses processus dépendants.
Réduire les capacités ou marquer une ressource de reprise comme indisponible.
Comparer la fin prévue au RTO et l’âge fourni de la sauvegarde au RPO.
Mettre en évidence cycles de dépendance, tâches manquantes et travaux aval bloqués avant un exercice sur table.

Exemple

Entrée

Processus opérationnels et informatiques critiques: id,name,criticality,rto_minutes,rpo_minutes,backup_at,owner,description P1,Base de commandes,high,60,60,2026-11-03T08:30:00Z,Équipe bases de données,Restaurer la base de commandes maintenue avant de relancer la réception des commandes. P2,Réception des commandes,high,120,60,2026-11-03T08:30:00Z,Équipe services,La réception des commandes nécessite une base de commandes disponible. Dépendances tenues à jour: id,from,to,evidence L1,P1,P2,La réception des commandes lit et écrit dans la base de commandes. Tâches de reprise tenues à jour: id,process,sequence,duration_minutes,resource,units,instruction T1,P1,1,30,R1,1,Restaurer la sauvegarde approuvée de la base et consigner le résultat de validation. T2,P2,1,20,R1,1,Relancer le service maintenu de réception des commandes après vérification de la base. Ressources de reprise: id,name,capacity R1,Opérateur de reprise,1 ID des processus en panne simulée: P1 Heure de référence UTC explicite: 2026-11-03T09:00:00Z Horizon de planification en minutes: 480 Priorité de planification de la reprise: Criticité fournie Capacité disponible des ressources (%): 100 Marge de sécurité RTO en minutes: 0 Politique d’âge des sauvegardes: Avertir des lacunes de sauvegarde Filtre de criticité: Tous Nombre maximal de sélections à examiner: 10 Niveau de détail des citations: Détaillé Ordre d’affichage: Début planifié

Résultat

La tâche de base de données est prévue aux minutes 0–30 et la réception des commandes aux minutes 30–50 avec l’unique opérateur de reprise. Les deux fins prévues respectent les objectifs RTO fournis de 60 et 120 minutes. L’âge fourni de la sauvegarde est de 30 minutes face à un RPO de 60 minutes. Ces comparaisons de planification ne prouvent ni une sauvegarde exploitable ni une restauration réussie.

Un exemple fixe, raccourci. Les vrais résultats sont générés par l'IA : vérifie-les.

Prix et limites

Prix: généralement 1–3 crédits
Disponible avec: Gratuit, Avec forfait
Limite d'entrée: Une page avec jusqu'à 100 000 caractères HTML

Confidentialité

Traités sur nos propres serveurs dans l'UE (Pologne). Les entrées et les résultats sont supprimés après 7 jours (Gratuit) ou 30 jours (forfaits), ou immédiatement après que tu as vu le résultat si tu choisis de ne pas les stocker. Les images sont supprimées immédiatement après traitement.

Dans l'API

Nom de l'outil : recovery_plan. Crée une tâche avec POST /api/v1/jobs et récupère le résultat avec GET /api/v1/jobs/{id}. Tu trouveras ta clé API dans ton compte.

curl -X POST https://do4u.eu/api/v1/jobs \
  -H "Authorization: Bearer d4u_…" -H "Content-Type: application/json" \
  -d '{"tool": "recovery_plan", "url": "https://example.com/"}'

Documentation API complète →

Questions et réponses

Les tâches sont-elles exécutées ou générées librement ?

Non. Seules les instructions de tâches tenues à jour peuvent apparaître comme citations exactes. Le modèle ne peut pas ajouter de commande, tâche de reprise ou ressource. Rien n’est exécuté ni envoyé à un service externe.

Comment les dépendances et capacités sont-elles traitées ?

Un processus affecté attend que chaque prérequis affecté soit planifié. Ses tâches suivent l’ordre fourni. Les réservations respectent la capacité effective en unités entières et n’autorisent le travail parallèle que si cette capacité le permet. Cycles, tâches absentes et ressources irréalisables restent des blocages ; les travaux aval ne peuvent pas les contourner.

Respecter le RTO ou le RPO prouve-t-il la reprise ?

Non. Le RTO compare la fin estimée plus la marge explicite à un objectif fourni. Le RPO compare l’heure de référence à un horodatage de sauvegarde fourni. Aucun ne contrôle l’intégrité de la sauvegarde, la perte réelle de données ou la réussite de la restauration. Les prérequis non affectés sont supposés disponibles ; des dépendances incomplètes peuvent donc invalider le plan.

Est-ce que mon texte est stocké ?

Seulement le temps nécessaire : 7 jours en version gratuite, 30 jours avec un forfait – ou pas du tout si tu choisis de ne pas le stocker. Le traitement s'effectue sur nos propres serveurs dans l'UE (Pologne).

Puis-je utiliser le résultat immédiatement ?

Les résultats sont générés par l'IA. Merci de les lire avant de les publier ou de les envoyer.