Surveillance
Les composants critiques peuvent faire l’objet d’une surveillance technique et d’alertes.
La présente Politique décrit les mesures mises en œuvre par KUPYDE afin d’assurer la disponibilité raisonnable de ses services, d’organiser les opérations de maintenance et de gérer les interruptions.
Elle précise également les principes de continuité, de sauvegarde, de reprise, de communication et de dépendance à l’égard des prestataires techniques.
Aucun système informatique ne peut garantir une disponibilité permanente. KUPYDE met en œuvre des mesures raisonnables afin de réduire les interruptions, limiter leurs conséquences et restaurer les services.
Les composants critiques peuvent faire l’objet d’une surveillance technique et d’alertes.
Les interventions planifiées sont organisées afin de limiter leur impact sur les Utilisateurs.
Les données essentielles peuvent être sauvegardées et restaurées selon des procédures contrôlées.
Les services critiques font l’objet de mesures de reprise et de priorisation.
La présente Politique définit les principes appliqués par KUPYDE pour assurer la disponibilité raisonnable de ses sites, applications, API, systèmes de paiement et fonctionnalités.
Elle décrit l’organisation des maintenances, les mesures de continuité, les sauvegardes, les procédures de reprise et les communications en cas d’interruption.
Elle complète les Conditions Générales d’Utilisation, la Politique de sécurité, la Politique de gestion des incidents et les Conditions des API.
Cette Politique s’applique aux services exploités directement par KUPYDE ainsi qu’aux composants techniques nécessaires à leur fonctionnement.
Elle couvre notamment les interfaces publiques, espaces utilisateurs, bases de données, services de fichiers, systèmes d’authentification, API et outils administratifs.
Les services fournis par des tiers restent également soumis à leurs propres niveaux de service, contraintes et interruptions.
| Terme | Définition |
|---|---|
| Disponibilité | Capacité d’un service à être accessible et utilisable pendant une période déterminée. |
| Maintenance planifiée | Intervention annoncée destinée à corriger, mettre à jour ou améliorer un système. |
| Maintenance urgente | Intervention nécessaire sans délai normal de préavis afin de protéger la sécurité ou la stabilité. |
| Continuité | Capacité à maintenir ou restaurer les fonctions prioritaires après une perturbation. |
| RTO | Objectif indicatif concernant le délai de rétablissement d’un service. |
| RPO | Objectif indicatif concernant la quantité maximale de données susceptible de devoir être reconstruite après un incident. |
KUPYDE met en œuvre des moyens raisonnables et proportionnés afin de maintenir ses services disponibles et sécurisés.
La disponibilité dépend notamment des réseaux, fournisseurs cloud, prestataires de paiement, systèmes de communication et équipements utilisés.
Sauf engagement contractuel particulier, les objectifs internes ne constituent pas une garantie absolue ni une obligation de résultat.
KUPYDE peut définir des objectifs internes de disponibilité différents selon la criticité de chaque service.
Les objectifs peuvent exclure les maintenances annoncées, événements de force majeure, pannes de tiers et interruptions causées par un Utilisateur.
Un objectif de disponibilité chiffré n’est opposable que lorsqu’il figure expressément dans un contrat ou un niveau de service applicable.
La disponibilité peut être mesurée au moyen de contrôles techniques, journaux, sondes, métriques applicatives et tests synthétiques.
Une dégradation partielle peut être distinguée d’une indisponibilité complète lorsqu’une fonctionnalité essentielle reste accessible.
Les mesures réalisées par les systèmes KUPYDE constituent la référence technique, sous réserve d’une erreur démontrée.
Les composants critiques peuvent être surveillés afin d’identifier des erreurs, ralentissements, saturations ou indisponibilités.
Les seuils et alertes sont adaptés à la criticité du service et peuvent évoluer selon l’utilisation observée.
Une alerte déclenche une vérification et, lorsque cela est nécessaire, l’ouverture d’un incident.
KUPYDE peut organiser des maintenances planifiées afin d’appliquer des mises à jour, migrations, correctifs ou améliorations.
Lorsque cela est raisonnablement possible, les opérations sont réalisées pendant les périodes de faible activité.
Une maintenance peut affecter tout ou partie des services pendant une durée limitée.
Les maintenances susceptibles de provoquer une interruption significative peuvent être annoncées par le site, l’application, le portail développeur ou courrier électronique.
L’avis peut préciser les services concernés, la fenêtre prévue et l’impact attendu.
Le préavis peut être réduit lorsque les circonstances techniques, de sécurité ou les contraintes d’un prestataire l’exigent.
KUPYDE peut intervenir sans préavis lorsqu’une faille, une compromission, un risque de perte de données ou une défaillance critique le justifie.
Une fonctionnalité peut être temporairement désactivée afin de protéger les Utilisateurs, les données ou l’intégrité des transactions.
Une information est publiée après le début de l’intervention lorsque cela est possible et approprié.
Les changements importants doivent être testés, documentés et approuvés selon leur niveau de risque.
Lorsque cela est techniquement possible, un plan de retour arrière ou une solution de remplacement est préparé.
Un changement peut être interrompu ou annulé lorsque ses effets sont incompatibles avec la sécurité ou la stabilité attendue.
KUPYDE identifie les fonctions dont l’interruption présente les conséquences les plus importantes pour les Utilisateurs, les paiements ou la sécurité.
La priorité de restauration peut notamment concerner l’authentification, les comptes, les transactions, les mécanismes de signalement et les fonctions administratives essentielles.
Les fonctionnalités secondaires peuvent être restaurées après les services critiques.
Des objectifs de reprise peuvent être définis selon la criticité, les dépendances, les volumes et les ressources disponibles.
Les valeurs RTO et RPO sont des objectifs opérationnels et non des garanties, sauf engagement contractuel explicite.
Les objectifs sont réévalués lors d’une évolution majeure de l’architecture ou des services.
La reprise peut nécessiter la restauration d’une sauvegarde, le déploiement d’un environnement sain, la reconfiguration de services ou la rotation de secrets.
Les opérations sont réalisées dans un ordre permettant de protéger l’intégrité, la sécurité et la cohérence des données.
Un service restauré peut rester temporairement limité pendant les contrôles et rapprochements nécessaires.
KUPYDE peut proposer un fonctionnement limité lorsqu’un service complet ne peut pas être restauré immédiatement.
Certaines opérations peuvent être mises en lecture seule, retardées, mises en file ou temporairement désactivées.
Le mode dégradé vise à maintenir les fonctions essentielles sans compromettre la sécurité ni la cohérence des opérations.
Les données et configurations considérées comme nécessaires à la continuité peuvent être intégrées dans les mécanismes de sauvegarde.
Les fichiers temporaires, caches, données reproductibles ou contenus exclus par conception peuvent ne pas être sauvegardés.
Le périmètre et la fréquence sont déterminés selon la criticité et les besoins de reprise.
Les sauvegardes sont protégées au moyen de contrôles adaptés à la sensibilité des informations conservées.
Les mesures peuvent comprendre le chiffrement, la séparation des accès, l’isolation logique et la limitation des droits de suppression.
Les informations d’accès aux sauvegardes ne doivent pas être exposées dans les journaux ou dépôts de code.
Les procédures de restauration sont testées périodiquement selon la criticité et les ressources disponibles.
Les tests vérifient notamment l’accessibilité, l’intégrité, les délais et les dépendances nécessaires.
Les écarts constatés donnent lieu à des actions correctives ou à une révision des objectifs.
Une sauvegarde ne garantit pas que toute donnée individuelle pourra être restaurée dans son état exact.
Une suppression, une corruption, une synchronisation ou une transaction récente peut ne pas être intégralement représentée dans le dernier point disponible.
Les sauvegardes ne remplacent pas les mécanismes transactionnels, journaux et rapprochements nécessaires au fonctionnement de la plateforme.
Une interruption significative peut entraîner l’ouverture d’un incident conformément à la Politique de gestion des incidents de sécurité.
L’incident est qualifié selon son impact, son étendue, sa durée, les données concernées et les services affectés.
Les actions de confinement, diagnostic, restauration et surveillance sont consignées dans le dossier correspondant.
KUPYDE peut informer les Utilisateurs d’une interruption au moyen d’une page d’état, d’un message intégré, d’un courrier électronique ou d’un autre canal approprié.
Les communications peuvent indiquer les services concernés, l’impact connu, les mesures prises et l’état général du rétablissement.
Une estimation de rétablissement constitue une prévision et peut évoluer au cours de l’analyse.
Les opérations initiées pendant une interruption peuvent être mises en attente, rejetées ou traitées après le rétablissement.
Les paiements, remboursements, versements et mouvements de Credits font l’objet de contrôles de rapprochement.
L’Utilisateur ne doit pas répéter une opération financière avant d’avoir vérifié son état afin d’éviter un double traitement.
Une interruption significative peut donner lieu à une analyse de sa cause, de sa durée, de ses conséquences et de l’efficacité de la réponse.
Des mesures correctives peuvent être définies afin de réduire la probabilité ou l’impact d’un incident similaire.
KUPYDE peut publier un résumé lorsque cela est utile et ne compromet pas la sécurité ou la confidentialité.
Le fonctionnement de KUPYDE peut dépendre de prestataires d’hébergement, de réseau, de paiement, de messagerie, de vérification et de distribution.
Une interruption d’un prestataire peut affecter une fonctionnalité même lorsque les systèmes propres à KUPYDE restent disponibles.
KUPYDE ne contrôle pas l’ensemble des infrastructures et délais d’intervention de ces prestataires.
Les prestataires critiques peuvent être évalués selon leur sécurité, disponibilité, localisation, capacité de reprise et engagements contractuels.
Les contrats peuvent préciser les niveaux de service, notifications d’incident, sauvegardes, réversibilité et coopération.
L’évaluation est adaptée à la criticité et aux données confiées au prestataire.
Des solutions alternatives peuvent être prévues lorsqu’une dépendance présente un risque important et qu’une duplication est raisonnablement possible.
Toutefois, une redondance complète de chaque fournisseur ou fonctionnalité n’est pas systématiquement possible ou proportionnée.
Les solutions de remplacement peuvent offrir des fonctionnalités ou délais différents du service principal.
Les responsabilités relatives à l’exploitation, la maintenance, la sécurité, les sauvegardes et la communication doivent être attribuées.
Les équipes techniques assurent la surveillance et la reprise, tandis que la direction définit les priorités et ressources nécessaires.
Les rôles d’urgence, contacts et règles d’escalade sont documentés et régulièrement actualisés.
KUPYDE peut organiser des exercices techniques ou organisationnels portant sur une panne, une perte de données, un prestataire indisponible ou une compromission.
Les tests peuvent couvrir la restauration, la communication, l’escalade et le fonctionnement en mode dégradé.
Les résultats sont documentés et donnent lieu aux améliorations jugées nécessaires.
Sous réserve des règles impératives, KUPYDE ne répond pas des interruptions résultant d’un événement extérieur raisonnablement incontrôlable.
L’Utilisateur demeure responsable de ses propres équipements, connexions, sauvegardes locales et procédures internes.
Les limitations de responsabilité applicables figurent dans les Conditions Générales ou les contrats particuliers.
KUPYDE peut modifier la présente Politique afin de tenir compte d’une évolution technique, contractuelle, réglementaire ou organisationnelle.
Les modifications importantes peuvent être communiquées par le Centre juridique ou un autre canal approprié.
| Support général | support@kupyde.com |
|---|---|
| Incident technique | operations@kupyde.com |
| Sécurité | security@kupyde.com |
| Développeurs et API | developers@kupyde.com |
| Adresse postale | [À COMPLÉTER — adresse de l’entité exploitante] |
| Service | Criticité | Objectif de disponibilité | RTO | RPO |
|---|---|---|---|---|
| Authentification | Critique | À définir | À définir | À définir |
| Transactions et Credits | Critique | À définir | À définir | À définir |
| Publications et contenus | Élevée | À définir | À définir | À définir |
| Messagerie | Élevée | À définir | À définir | À définir |
| API | Variable | Selon l’offre applicable | À définir | À définir |
| Exigence | Implémentation recommandée |
|---|---|
| État des services |
ServiceStatus,
ServiceComponent,
OperationalState
|
| Health checks |
AddHealthChecks(),
MapHealthChecks(),
IHealthCheck
|
| Maintenance |
MaintenanceWindow,
StartsAtUtc,
EndsAtUtc,
AffectedServices
|
| Mode maintenance |
MaintenanceModeMiddleware,
IMaintenanceStateService
|
| Incident de disponibilité |
AvailabilityIncident,
Severity,
StartedAtUtc,
ResolvedAtUtc
|
| Mises à jour publiques |
StatusPageUpdate,
Message,
PublishedAtUtc
|
| Objectifs de reprise |
ContinuityObjective,
RtoMinutes,
RpoMinutes
|
| Sauvegardes |
BackupExecution,
BackupType,
StorageLocation,
CompletedAtUtc
|
| Tests de restauration |
RestoreTest,
Result,
Duration,
TestedAtUtc
|
| Résilience HTTP |
Microsoft.Extensions.Http.Resilience,
AddStandardResilienceHandler()
|
| Tâches différées |
BackgroundService,
Channel<T>,
file durable ou système de messages selon la criticité.
|
| Observabilité |
OpenTelemetry,
ActivitySource,
Meter,
ILogger
|