Accord de niveau de service (SLA)
La plateforme Take-QAIR® :
ARTICLE 1 – OBJET
Le présent Accord de Niveau de Service (Service Level Agreement – SLA) définit les engagements de service applicables à la solution logicielle Take-QAIR® fournie par MELTOD HEALTH en mode SaaS.
Il précise notamment :
Les niveaux de disponibilité du service ;
Les engagements de performance ;
Les procédures de gestion des incidents ;
Les délais d’intervention et de résolution ;
Les mécanismes de sauvegarde et de reprise d’activité ;
Les engagements de sécurité et de continuité de service.
Le présent SLA constitue une annexe contractuelle aux Conditions Générales de Vente.
ARTICLE 2 – PÉRIMÈTRE DU SERVICE
Le service couvert par le présent SLA comprend :
L’accès à la plateforme SaaS ;
Les services applicatifs ;
Les bases de données ;
Les interfaces API ;
L’infrastructure d’hébergement cloud ;
Les services de sécurité et de supervision ;
Le support technique.
Ne sont pas inclus dans le périmètre :
Les équipements du Client ;
Les réseaux internet publics ;
Les services tiers intégrés par le Client.
ARTICLE 3 – DISPONIBILITÉ DU SERVICE
3.1 Objectif de disponibilité
L’Éditeur s’engage à un objectif de disponibilité annuel de : 99,9 %
Cet objectif correspond à un maximum théorique d’indisponibilité de :
8 heures et 45 minutes par an
3.2 Méthode de calcul
La disponibilité est calculée selon la formule suivante :
Disponibilité = (Total du temps – temps d’indisponibilité non planifié) / Total du temps
3.3 Exclusions
Ne sont pas comptabilisées dans le calcul :
Les maintenances programmées ;
Les interruptions dues à un cas de force majeure ;
Les incidents liés aux infrastructures réseau externes ;
Les indisponibilités causées par le Client.
ARTICLE 4 – MAINTENANCE
4.1 Maintenance corrective
La maintenance corrective vise à corriger les anomalies affectant le fonctionnement normal de la plateforme.
Les corrections sont réalisées en fonction du niveau de criticité de l’incident.
4.2 Maintenance évolutive
L’Éditeur peut déployer :
Des améliorations fonctionnelles ;
Des optimisations techniques ;
Des correctifs de sécurité.
Ces mises à jour peuvent être déployées sans interruption significative du service.
4.3 Maintenance programmée
Les maintenances planifiées sont généralement réalisées :
En dehors des heures ouvrées ;
Après information préalable du Client lorsque cela est possible.
ARTICLE 5 – SUPPORT TECHNIQUE
5.1 Accès au support
Le support technique est accessible par :
Email ;
Plateforme de ticketing ;
Interface de support dédiée.
5.2 Horaires de support standard
Lundi au vendredi
09h00 – 18h00 (heure de Paris) hors jours fériés.
Des niveaux de support étendus peuvent être définis contractuellement.
ARTICLE 6 – CLASSIFICATION DES INCIDENTS
Les incidents sont classés selon quatre niveaux de criticité.
| Niveau | Description |
|---|---|
| P1 – Critique | Indisponibilité totale du service ou impact majeur empêchant toute utilisation |
| P2 – Majeur | Fonction essentielle fortement dégradée |
| P3 – Modéré | Fonction secondaire affectée |
| P4 – Mineur | Incident mineur ou demande d’assistance |
ARTICLE 7 – DÉLAIS DE TRAITEMENT
| Priorité | Délai de prise en charge | Objectif de résolution |
|---|---|---|
| P1 – Critique | 1 heure ouvrée | 4 heures |
| P2 – Majeur | 4 heures ouvrées | 24 heures |
| P3 – Modéré | 1 jour ouvré | 3 jours ouvrés |
| P4 – Mineur | 2 jours ouvrés | Selon planification |
Les délais indiqués correspondent à des objectifs de service.
ARTICLE 8 – SUPERVISION ET MONITORING
L’Éditeur met en œuvre des systèmes de surveillance permettant de :
Détecter automatiquement les incidents ;
Surveiller la disponibilité de la plateforme ;
Contrôler les performances applicatives ;
Générer des alertes en cas d’anomalie.
Les systèmes de monitoring peuvent inclure :
Surveillance de l’infrastructure ;
Monitoring applicatif ;
Analyse des journaux techniques.
ARTICLE 9 – SAUVEGARDE DES DONNÉES
L’Éditeur met en place des mécanismes de sauvegarde régulière des données afin d’assurer leur protection.
Les sauvegardes sont :
Automatisées ;
Stockées sur des environnements sécurisés ;
Conservées selon des durées adaptées aux exigences opérationnelles.
ARTICLE 10 – PLAN DE CONTINUITÉ ET DE REPRISE
Afin d’assurer la résilience du service, l’Éditeur met en œuvre :
Un Plan de Continuité d’Activité (PCA) ;
Un Plan de Reprise d’Activité (PRA).
10.1 RTO – Recovery Time Objective
Objectif maximal de reprise du service :
4 heures
10.2 RPO – Recovery Point Objective
Perte maximale de données acceptable :
15 minutes
Ces objectifs peuvent évoluer selon l’architecture technique du service.
ARTICLE 11 – SÉCURITÉ DU SERVICE
L’Éditeur met en œuvre des mesures de sécurité adaptées, notamment :
Chiffrement des communications ;
Gestion sécurisée des accès ;
Journalisation des accès ;
Contrôle des accès administrateurs ;
Audits de sécurité réguliers.
Lorsque la plateforme traite des données de santé, les exigences relatives à l’hébergement certifié Hébergement de Données de Santé (HDS) sont appliquées.
ARTICLE 12 – RESPONSABILITÉS DU CLIENT
Le Client s’engage à :
Signaler les incidents via les canaux de support ;
Fournir les informations nécessaires à leur diagnostic ;
Utiliser la plateforme conformément à sa documentation.
Le Client est responsable :
De ses équipements informatiques ;
De la sécurité de ses accès ;
De la qualité des données saisies.
ARTICLE 13 – LIMITATIONS DU SLA
Les engagements du présent SLA ne s’appliquent pas lorsque l’incident résulte :
D’une utilisation non conforme de la plateforme ;
D’une modification non autorisée ;
D’un dysfonctionnement de services tiers ;
D’un cas de force majeure.
ARTICLE 14 – ÉVOLUTION DU SLA
L’Éditeur peut faire évoluer le présent SLA afin de tenir compte :
Des évolutions techniques ;
Des améliorations de la plateforme ;
Des évolutions réglementaires.
Toute modification substantielle sera notifiée au Client.