Disponibilité, continuité de service et reprise après incident de LogsCord

Version 1.1 — 12 août 2026

LogsCord est conçu pour conserver et rendre interrogeables des événements pouvant être importants pour l'administration, la modération et l'investigation d'un serveur Discord.

La continuité du service ne consiste donc pas uniquement à maintenir un site Web accessible. Elle implique également de préserver l'intégrité des événements collectés, de limiter les pertes de données, de restaurer les composants dans un ordre cohérent et d'éviter qu'une reprise après incident ne réintroduise des données qui avaient précédemment été supprimées ou rectifiées.

Ce document décrit les principes généraux appliqués par LogsCord en matière de disponibilité, de maintenance, de déploiement, de continuité, de sauvegarde, de reprise après incident et de communication opérationnelle.

Les engagements contractuels propres à une offre, notamment un pourcentage de disponibilité, un objectif de reprise, un délai de communication ou une éventuelle compensation, sont exclusivement ceux définis dans l'offre, le SLA ou le contrat applicable.

1. Niveaux de service

LogsCord distingue les services fournis en Best Effort de ceux bénéficiant d'engagements contractuels de disponibilité ou de reprise.

L'offre gratuite ne comporte aucune garantie contractuelle de disponibilité, de résolution, de RTO ou de RPO. Elle reste soumise aux mesures générales de sécurité et de protection des données. Les engagements Pro et Enterprise sont exclusivement ceux de l'offre, du SLA ou du contrat applicable ; ils déterminent notamment les objectifs, la priorité de reprise et les éventuels mécanismes renforcés.

1.1. Tarifs et évolution des garanties

Les offres, leurs tarifs et les garanties associées sont présentés sur logscord.com/pricing. Le bon de commande, le SLA ou le contrat accepté par le client prévaut lorsqu'il prévoit des conditions particulières.

LogsCord peut faire évoluer une garantie pour l'avenir lorsqu'un motif légitime le justifie, notamment une évolution technique importante, une modification d'une dépendance essentielle, une exigence de sécurité ou de droit, ou l'impossibilité durable de maintenir l'offre dans les conditions annoncées.

Lorsqu'une garantie ne peut plus raisonnablement être maintenue pendant une période engagée, LogsCord peut proposer une solution ou une offre de remplacement. À défaut d'accord, et lorsque le contrat et le droit applicable le permettent, LogsCord peut mettre fin au service concerné pour un motif légitime, avec un préavis raisonnable et le remboursement au prorata de la période payée restant à courir. Les droits, crédits ou recours déjà nés avant la date d'effet de la modification restent applicables.

Une mesure urgente nécessaire à la sécurité, à l'intégrité des données ou au respect du droit peut être appliquée sans attendre le préavis normal. Elle ne permet pas de réduire rétroactivement une garantie ni de supprimer un droit déjà acquis.

Pour les consommateurs, ces règles s'appliquent sous réserve des dispositions impératives, notamment de l'article L. 224-25-26 du Code de la consommation lorsqu'une modification entre dans son champ, ainsi que de l'article R. 212-1 relatif aux clauses abusives.

2. Statut public et historique des incidents

La page status.logscord.com, accessible sans authentification, publie les perturbations qualifiées, les interruptions et les maintenances. Une alarme brute, un contrôle isolé en échec ou un faux positif n'est publié comme incident que si un impact réel est établi.

Les événements restent dans l'historique après le retour à la normale. Une correction ultérieure des horaires, de la durée ou de la qualification reste identifiable.

2.1. États publiés

L'état global résulte de l'état des composants nécessaires au service. Une panne secondaire ne rend pas nécessairement toute la plateforme indisponible. À l'inverse, un site Web accessible ne suffit pas à considérer la collecte, la recherche et le temps réel comme opérationnels.

2.2. Composants suivis

2.3. Rapport de transparence

Le rapport distingue ce qui a réellement affecté le service de ce qui est retenu dans un SLA :

Les durées observée et éligible sont cumulées sur la période applicable. Les informations susceptibles de compromettre la sécurité, la confidentialité ou les données d'un client ne sont pas publiées.

3. Mesure de la disponibilité

3.1. Contrôles et qualification

LogsCord combine des contrôles externes et des signaux internes : état des shards Discord, réception des événements, progression de l'ingestion, erreurs d'écriture, ClickHouse, API et temps réel. Un site ou un endpoint répondant avec un code HTTP 200 ne suffit pas à déclarer l'ensemble du service disponible.

Une anomalie doit être corroborée avant d'être qualifiée d'indisponibilité. Cette fenêtre de confirmation écarte les faux positifs ; ce n'est pas une période de grâce. Lorsqu'un impact est confirmé, le début est replacé au premier instant fiable établi par les contrôles, les journaux ou une autre source disponible.

La supervision porte sur l'état technique des composants et des flux de traitement, et non sur le suivi individuel des utilisateurs Discord. Les événements transmis par le Gateway Discord sont pris en charge et enregistrés dès leur réception. La fréquence des contrôles de disponibilité et la précision des mesures peuvent varier selon les composants surveillés.

3.2. Règles de calcul

Exemple : si la supervision établit un début à 14:02, confirme l'alerte à 14:05 et que l'incident est publié à 14:08, la mesure commence à 14:02.

3.3. Formule

Pour la période applicable :

textDisponibilité =
(Temps éligible - Temps d'indisponibilité éligible)
-------------------------------------------------- × 100
                 Temps éligible

Seules les exclusions prévues par le SLA sont retirées du temps éligible. Les incidents ne sont pas arrondis séparément et une maintenance ne peut pas être exclue rétroactivement par un simple changement de qualification. À titre d'exemple, 30 minutes d'indisponibilité éligible sur un mois de 30 jours correspondent à environ 99,9306 % de disponibilité.

3.4. Mesure par composant et par client

LogsCord évite de masquer une panne fonctionnelle derrière une moyenne globale. La collecte, l'API, la recherche, le dashboard et le temps réel peuvent être mesurés séparément.

Une panne limitée à un shard, un tenant, une instance ou une partition peut être présentée comme Partial Outage. Pour un SLA individuel, son impact est pris en compte pour le client concerné même si le reste de la plateforme est resté opérationnel.

Une dégradation de performance n'est pas automatiquement équivalente à une indisponibilité complète. À l'inverse, un composant joignable mais incapable d'assurer sa fonction principale peut être considéré comme indisponible.

3.5. Cadre juridique

Il n'existe pas de pourcentage, de cadence de supervision ou de période de grâce imposé de manière générale à tous les SaaS. L'article 32 du RGPD exige des mesures de disponibilité, de résilience, de reprise et de test adaptées au risque, sans fixer un SLA universel. Le considérant 34 du règlement d'exécution (UE) 2024/2690 et l'article 3 du règlement délégué (UE) 2024/1772, dans leurs champs respectifs, retiennent également une mesure depuis l'interruption réelle ou la trace fiable la plus ancienne.

Pour les consommateurs, l'article L. 224-25-14 du Code de la consommation protège notamment la continuité attendue d'un service numérique. Le SLA et ses exclusions ne remplacent jamais les garanties légales impératives. Toute dérogation applicable à un consommateur doit respecter les conditions d'information et d'acceptation prévues par ce texte ainsi que les règles relatives aux clauses abusives.

4. Disponibilité et intégrité

LogsCord distingue :

• la disponibilité, c'est-à-dire la capacité d'un utilisateur autorisé à accéder à une fonction ;
• la durabilité, c'est-à-dire la capacité à conserver ou reconstruire les données qui doivent encore exister ;
• l'intégrité, c'est-à-dire la cohérence et la fiabilité de l'état présenté.

Un service peut être temporairement inaccessible sans perte de données. À l'inverse, un service peut répondre tout en présentant un risque d'intégrité nécessitant son arrêt préventif.

Lorsqu'il existe un conflit entre disponibilité immédiate et intégrité, LogsCord peut réduire ou interrompre temporairement l'accès. Une interruption contrôlée est préférable à la poursuite d'un traitement susceptible d'aggraver une corruption.

5. Architecture de continuité et modes dégradés

mermaidflowchart LR
    Discord["Discord Gateway"] --> Collectors["Collecteurs shardés"]
    Collectors --> Storage["ClickHouse<br/>stockage durable"]
    Collectors --> Broker["Message Broker<br/>temps réel"]
    Storage --> API["API LogsCord"]
    Broker --> API
    API --> Client["Dashboard et clients autorisés"]

La séparation entre stockage durable et temps réel permet qu'une interruption du broker ou du SSE n'implique pas nécessairement l'arrêt de la collecte persistante. De même, une interface indisponible ne signifie pas automatiquement que les traitements de fond sont arrêtés.

6. Dépendances externes

Un incident tiers n'est exclu que si sa causalité est suffisamment établie, si LogsCord n'y a pas contribué et si les mesures raisonnables de limitation et de reprise ont été appliquées. Seules la durée et les fonctions directement affectées sont retirées du SLA. En cas de causes mixtes, la part qui ne peut pas être isolée reste éligible.

Restent notamment imputables à LogsCord les erreurs de code ou de configuration, la mauvaise gestion des jetons ou des reconnexions, l'échec d'une redondance promise et la prolongation de l'indisponibilité après le rétablissement du fournisseur.

Tous les impacts réels demeurent visibles dans la disponibilité observée et sur la page de statut, avec leur cause et leur traitement contractuel. Une exclusion de SLA ne constitue pas automatiquement un cas de force majeure au sens de l'article 1218 du Code civil et ne supprime pas les garanties légales impératives.

6.1. Reprise et choix des fournisseurs

Un second fournisseur cloud actif n'est pas exigé de manière générale. Le niveau de continuité doit rester proportionné aux risques et aux engagements annoncés. Selon l'offre et l'architecture, le plan de reprise peut combiner réplication, sauvegardes séparées, reconstruction automatisée, restauration dans un autre environnement et tests périodiques.

Lorsque le règlement d'exécution (UE) 2024/2690 est applicable, il prévoit notamment un plan de continuité et de rétablissement, des sauvegardes, une redondance appropriée et l'examen de la diversification des fournisseurs lorsqu'elle est pertinente. Il n'impose pas systématiquement une architecture multicloud.

Les conditions développeur de Discord précisent que Discord ne garantit pas que ses API soient ininterrompues ou exemptes d'erreurs.

7. Gestion des changements et déploiements

Une modification de production suit des validations proportionnées à son risque.

mermaidflowchart LR
    Dev["Développement"] --> Automated["Tests automatisés"]
    Automated --> Integration["Tests d'intégration"]
    Integration --> Build["Build de déploiement"]
    Build --> Validation["Environnement de validation"]
    Validation --> Progressive["Déploiement progressif"]
    Progressive --> Observe["Surveillance"]
    Observe -->|Conforme| General["Déploiement général"]
    Observe -->|Anomalie| Rollback["Arrêt ou rollback"]

Les migrations destructives ne sont pas traitées comme de simples mises à jour applicatives. Lorsque cela est raisonnablement possible, une période de compatibilité est conservée avant la suppression définitive d'une structure ancienne.

8. Maintenance

Une maintenance planifiée n'est exclue d'un calcul contractuel que si le SLA le prévoit et si les conditions correspondantes sont respectées. Les maintenances exécutées sont publiées et conservées dans l'historique de la page de statut, avec leur impact réel lorsqu'il existe.

9. Gestion et communication des incidents

Un incident peut être détecté par la supervision, les métriques internes, les alertes de sécurité, les fournisseurs, le support ou le signalement d'un utilisateur.

mermaidflowchart LR
    Detect["Détection"] --> Qualify["Qualification"]
    Qualify --> Contain["Confinement"]
    Contain --> Stabilize["Stabilisation"]
    Stabilize --> Restore["Restauration"]
    Restore --> Verify["Vérification"]
    Verify --> Service["Retour au service"]
    Service --> Review["Analyse post-incident"]

Lorsqu'une cause reste active, elle est raisonnablement contenue avant la restauration. Remettre en service un composant sans traiter la cause pourrait reproduire l'incident.

9.1. Chronologie publique

Un incident significatif peut suivre les états Investigating, Identified, Monitoring et Resolved. Les mises à jour indiquent, selon les informations disponibles, l'impact, les composants affectés, l'évolution et la résolution. Une hypothèse n'est pas présentée comme une cause définitive et aucun détail compromettant la sécurité, la confidentialité ou les données d'un client n'est publié.

9.2. Analyse post-incident

Pour les incidents importants, LogsCord peut publier ou communiquer une analyse adaptée à leur gravité : événement, impact, durée, mécanismes ayant limité l'incident, étapes de restauration et mesures réduisant le risque de récurrence.

Le retour du service ne signifie pas nécessairement que l'incident est clos. La surveillance, les contrôles d'intégrité et l'analyse peuvent continuer après le rétablissement.

Une indisponibilité n'est pas nécessairement une violation de données personnelles. Une violation peut aussi survenir sans indisponibilité visible. Les incidents impliquant des données personnelles sont traités conformément à la Politique de confidentialité et au DPA applicables.

10. Sauvegardes et reprise des données

Le détail cryptographique et les contrôles de restauration sont décrits dans la documentation Sécurité, architecture et résilience.

La réplication et la sauvegarde répondent à des risques différents. Un replica sain peut permettre la continuité après la perte d'un nœud ; il ne protège pas nécessairement contre une corruption logique ou une suppression propagée.

10.1. Validation des sauvegardes

LogsCord ne considère pas une sauvegarde comme fiable du seul fait que sa création s'est terminée sans erreur. Les restaurations complètes et les chaînes incrémentales sont testées dans un environnement isolé et comparées pour un même watermark logique.

mermaidflowchart TB
    Watermark["Watermark commun"]
    Watermark --> Full["Sauvegarde complète"]
    Watermark --> Incremental["Chaîne incrémentale"]
    Full --> RestoreA["Restauration A"]
    Incremental --> RestoreB["Restauration B"]
    RestoreA --> Compare["Comparaison logique"]
    RestoreB --> Compare
    Compare --> Result["Validation ou investigation"]

Les contrôles peuvent comprendre le nombre de lignes, les partitions, les bornes d'événements, les volumes par période, les schémas, les métadonnées et des empreintes déterministes.

10.2. Restauration et confidentialité

mermaidflowchart LR
    Backup["Sauvegarde"] --> Decrypt["Déchiffrement"]
    Decrypt --> Restore["Restauration isolée"]
    Restore --> Replay["Replay des effacements<br/>et rectifications"]
    Replay --> Integrity["Contrôles d'intégrité"]
    Integrity --> Permissions["Contrôle des permissions<br/>et de la connectivité"]
    Permissions --> Promote["Remise à disposition"]

Une sauvegarde antérieure peut contenir une donnée effacée ou rectifiée depuis sa création. Les opérations de confidentialité applicables sont donc rejouées avant toute remise à disposition afin qu'une restauration ne réintroduise pas silencieusement un état devenu incorrect.

11. Priorité de reprise

La première priorité est la stabilisation de l'infrastructure commune. Une restauration client ne doit pas être engagée sur un composant partagé encore instable ou susceptible de corrompre à nouveau les données.

L'ordre concret peut aussi dépendre de l'étendue de l'incident, du risque de perte ou de corruption, des dépendances, du nombre de clients concernés et de la possibilité de mener plusieurs restaurations en parallèle.

La priorité commerciale ne permet jamais de contourner une étape nécessaire à la sécurité ou à l'intégrité.

12. Objectifs de reprise

Les valeurs applicables aux offres Pro et Enterprise sont définies dans leur offre, leur SLA ou leur contrat. Aucun RTO ou RPO universel n'est annoncé dans ce document, car une valeur unique serait incorrecte pour des architectures différentes. Les services gratuits n'en bénéficient pas contractuellement.

La fréquence des sauvegardes n'est pas, à elle seule, un RPO ou un RTO. Une sauvegarde quotidienne ne garantit pas une restauration en moins de 24 heures, tandis que d'autres mécanismes peuvent parfois préserver un état plus récent qu'une sauvegarde périodique.

13. Tests périodiques de continuité

Les tests détaillés des sauvegardes sont décrits à la section 10. La continuité couvre également les scénarios suivants :

Le plan est réévalué après une évolution significative du stockage, de la réplication, du fournisseur, du KMS, des sauvegardes ou du pipeline d'ingestion.

14. Responsabilités des clients

Les exploitants de serveurs doivent notamment :

• conserver des administrateurs habilités ;
• maintenir les permissions nécessaires aux fonctionnalités activées ;
• ne pas supprimer volontairement un accès nécessaire tout en attendant le même fonctionnement ;
• protéger les exports qu'ils téléchargent ;
• maintenir leurs coordonnées de service lorsque leur offre prévoit des communications opérationnelles.

Les sauvegardes LogsCord protègent les données nécessaires au fonctionnement de LogsCord. Elles ne constituent pas une sauvegarde générale de Discord, de toutes les configurations du serveur ou des contenus situés hors du périmètre du service.

15. Documents associés et prévalence contractuelle

Le présent document complète notamment :

• les Conditions d'utilisation de LogsCord ;
• la Politique de confidentialité ;
• la documentation Sécurité, architecture et résilience ;
• le DPA applicable ;
• les SLA ou engagements spécifiques des offres Pro et Enterprise.

En cas de contradiction concernant un engagement contractuel de disponibilité, de reprise ou de compensation, le SLA, l'offre ou le contrat spécifique applicable au client prévaut sur cette description générale.

Pour toute question ou tout signalement relatif à la sécurité, contactez [email protected] et consultez le fichier security.txt.

Les documents et manuels publics de LogsCord sont disponibles dans le dépôt LogsCord/logscord-manuals.