SLA

Service Level Agreement (SLA)

SaaS software solution – Healthcare sector

Effective date: 1 July 2026

ARTICLE 1 – PURPOSE

This Service Level Agreement (SLA) defines the service commitments applicable to the Take-QAIR® software solution provided by MELTOD HEALTH as SaaS.

It notably specifies:

  • Service availability levels;

  • Performance commitments;

  • Incident management procedures;

  • Response and resolution times;

  • Backup and business recovery mechanisms;

  • Security and service continuity commitments.

This SLA is a contractual annex to the General Terms of Sale.

ARTICLE 2 – SCOPE OF THE SERVICE

The service covered by this SLA includes:

  • Access to the SaaS platform;

  • Application services;

  • Databases;

  • API interfaces;

  • Cloud hosting infrastructure;

  • Security and monitoring services;

  • Technical support.

The following are not included in the scope:

  • The Customer’s equipment;

  • Public internet networks;

  • Third-party services integrated by the Customer.

ARTICLE 3 – SERVICE AVAILABILITY

3.1 Availability target

The Publisher commits to an annual availability target of: 99.9%

This target corresponds to a theoretical maximum downtime of:

8 hours and 45 minutes per year

3.2 Calculation method

Availability is calculated using the following formula:

Availability = (Total time – unplanned downtime) / Total time

3.3 Exclusions

The following are not counted in the calculation:

  • Scheduled maintenance;

  • Interruptions due to force majeure;

  • Incidents related to external network infrastructure;

  • Unavailability caused by the Customer.

ARTICLE 4 – MAINTENANCE

4.1 Corrective maintenance

Corrective maintenance aims to fix anomalies affecting the normal operation of the platform.

Fixes are carried out according to the criticality level of the incident.

4.2 Evolutive maintenance

The Publisher may deploy:

  • Functional improvements;

  • Technical optimizations;

  • Security patches.

These updates may be deployed without significant interruption of the service.

4.3 Scheduled maintenance

Planned maintenance is generally carried out:

  • Outside working hours;

  • After prior notice to the Customer where possible.

ARTICLE 5 – TECHNICAL SUPPORT

5.1 Access to support

Technical support can be reached through:

  • Email;

  • Ticketing platform;

  • Dedicated support interface.

5.2 Standard support hours

Monday to Friday
09:00 – 18:00 (Paris time), excluding public holidays.

Extended support levels may be defined contractually.

ARTICLE 6 – INCIDENT CLASSIFICATION

Incidents are classified into four criticality levels.

LevelDescription
P1 – CriticalTotal unavailability of the service or major impact preventing any use
P2 – MajorEssential function severely degraded
P3 – ModerateSecondary function affected
P4 – MinorMinor incident or request for assistance

ARTICLE 7 – RESPONSE TIMES

PriorityResponse timeResolution target
P1 – Critical1 working hour4 hours
P2 – Major4 working hours24 hours
P3 – Moderate1 working day3 working days
P4 – Minor2 working daysAs planned

The times indicated are service objectives.

ARTICLE 8 – SUPERVISION AND MONITORING

The Publisher implements monitoring systems that make it possible to:

  • Automatically detect incidents;

  • Monitor the availability of the platform;

  • Check application performance;

  • Generate alerts in the event of an anomaly.

Monitoring systems may include:

  • Infrastructure monitoring;

  • Application monitoring;

  • Analysis of technical logs.

ARTICLE 9 – DATA BACKUP

The Publisher sets up regular data backup mechanisms to ensure data protection.

Backups are:

  • Automated;

  • Stored in secure environments;

  • Retained for periods suited to operational requirements.

ARTICLE 10 – BUSINESS CONTINUITY AND RECOVERY PLAN

To ensure the resilience of the service, the Publisher implements:

  • A Business Continuity Plan (BCP);

  • A Disaster Recovery Plan (DRP).

10.1 RTO – Recovery Time Objective

Maximum service recovery objective:

4 hours

10.2 RPO – Recovery Point Objective

Maximum acceptable data loss:

15 minutes

These objectives may change depending on the technical architecture of the service.

ARTICLE 11 – SERVICE SECURITY

The Publisher implements appropriate security measures, in particular:

  • Encryption of communications;

  • Secure access management;

  • Access logging;

  • Control of administrator access;

  • Regular security audits.

Where the platform processes health data, the requirements relating to certified Health Data Hosting (HDS) are applied.

ARTICLE 12 – CUSTOMER RESPONSIBILITIES

The Customer undertakes to:

  • Report incidents through the support channels;

  • Provide the information needed to diagnose them;

  • Use the platform in accordance with its documentation.

The Customer is responsible for:

  • Its IT equipment;

  • The security of its access;

  • The quality of the data entered.

ARTICLE 13 – SLA LIMITATIONS

The commitments of this SLA do not apply where the incident results from:

  • Non-compliant use of the platform;

  • An unauthorized modification;

  • A malfunction of third-party services;

  • A case of force majeure.

ARTICLE 14 – CHANGES TO THE SLA

The Publisher may change this SLA to take account of:

  • Technical developments;

  • Improvements to the platform;

  • Regulatory changes.

Any substantial change will be notified to the Customer.

Scroll to Top