Documents juridiques

English version

Damvia Annexe hébergement maintenance et modules

Dans ce document
  1. 1. Fiche de service obligatoire
  2. 2. Répartition des responsabilités
  3. 3. Données sources et copies techniques
  4. 4. Maintenance et support
  5. 5. Capacité et dépendances
  6. 6. Réversibilité et inventaire des données
  7. 7. Organisation de la sortie

Version du 5 octobre 2026. Applicable aux commandes qui la désignent expressément.

1. Fiche de service obligatoire

Avant la mise en production, les parties complètent et acceptent la fiche suivante. Toute rubrique non applicable est marquée « sans objet » ; une donnée inconnue ne vaut pas engagement de service.

Le service géré ne démarre pas avec une fiche vide sur les lieux de traitement, les responsabilités de sauvegarde, le support ou la sécurité. Sauf dérogation expressément acceptée, les paramètres standard ci-dessous s’appliquent aux nouvelles commandes d’instances entièrement gérées ; ils sont vérifiés et repris dans la fiche avant activation. Ils ne décrivent pas une configuration déjà déployée chez tous les clients. Aucun « 99,9 % » ni support « 24/7 » ne résulte du seul abonnement.

2. Répartition des responsabilités

Pour une instance entièrement gérée, le Prestataire configure et maintient le système et l’application dans le périmètre commandé, administre les accès techniques, applique les correctifs pertinents, réalise les sauvegardes convenues et pilote la restauration. Le Client administre les comptes métier, droits d’accès, contenus, licences de ressources et systèmes qu’il contrôle. Les accès privilégiés du Client, s’ils sont autorisés, et les conséquences de ses interventions sont documentés.

Pour une installation sur une infrastructure souscrite directement par le Client, la fiche précise qui contrôle le compte hébergeur, le système, le réseau, les sauvegardes, les certificats et les mises à jour. Une prestation d’installation seule ne crée pas une prestation permanente d’exploitation. Le Prestataire reste responsable des tâches qu’il a effectivement acceptées.

Le Prestataire peut faire évoluer l’infrastructure pour des raisons de sécurité, performance ou exploitation sans dégrader substantiellement les caractéristiques convenues. Il informe préalablement le Client des changements significatifs. Tout changement de sous-traitant, de pays de traitement ou d’accès reste soumis au DPA ; cette faculté technique ne dispense pas des informations, autorisations et garanties requises.

Le nombre d’instances et environnements gérés est fixé au Bon de commande. Un changement de domaine ou l’ajout d’un alias pointant vers la même instance ne constitue pas à lui seul une nouvelle instance facturable ; les travaux techniques éventuels sont convenus séparément. Une instance supplémentaire nécessite une commande distincte. Le titulaire des noms de domaine conserve la responsabilité de leur renouvellement, sauf mandat exprès d’administration confié au Prestataire.

3. Données sources et copies techniques

Damvia se connecte aux sources cloud autorisées et peut conserver des copies d’originaux, des aperçus, des archives de téléchargement, des métadonnées et des contenus éditoriaux dans des stockages applicatifs. La conservation des fichiers sources chez le Client n’exclut donc pas l’existence d’autres copies.

Le Client préserve ses sources cloud et leurs propres sauvegardes. Les sauvegardes de l’instance couvrent, selon la fiche, PostgreSQL, les fichiers du stockage principal, les éléments nécessaires du stockage d’assets, la configuration et les éléments de version nécessaires à la restauration. Reconnecter un stockage cloud ne recrée pas à lui seul les utilisateurs, droits, pages ou données des modules. Une synchronisation n’est pas une sauvegarde indépendante.

Pour une instance entièrement gérée standard, une sauvegarde cohérente de la base PostgreSQL, de la configuration nécessaire à la reprise et des fichiers présents dans les stockages applicatifs est programmée au moins une fois par vingt-quatre heures. Les copies quotidiennes sont conservées sept jours et une copie hebdomadaire est conservée sur quatre semaines, aucune copie standard n’excédant vingt-huit jours. Le stockage de sauvegarde est séparé du serveur de production, avec accès restreint et chiffrement des transferts et des sauvegardes au repos. Les pays et l’entité de stockage sont renseignés avant activation ; les sauvegardes standard sont hébergées dans l’Espace économique européen. Il ne s’agit pas d’une garantie de séparation géographique entre centres de données.

Les sauvegardes n’incluent pas les fichiers conservés exclusivement dans les services cloud du Client, ni leurs historiques, sauf commande expresse. Les copies locales présentes dans l’application sont incluses. L’objectif de perte maximale de données (RPO) est de vingt-quatre heures depuis la dernière sauvegarde réussie pour ce périmètre ; il suppose la disponibilité d’une copie exploitable et n’est pas une garantie d’absence de perte. Les échecs génèrent une alerte automatique examinée pendant les horaires de support. Une vérification technique automatique des tâches est quotidienne. Un premier test de restauration est effectué avant production puis un test représentatif de la base, de la configuration et d’un échantillon de fichiers au moins chaque trimestre ; sa date, son périmètre et son résultat sont consignés. Une restauration complète de tous les fichiers ou un plan de secours multirégion requiert un périmètre distinct expressément convenu. Les sauvegardes standard sont incluses dans le service géré et ne créent pas un supplément de stockage non annoncé.

4. Maintenance et support

La maintenance corrective porte sur les anomalies reproductibles des versions et modules maintenus, dans l’environnement convenu. Le Prestataire peut fournir un correctif, une mise à jour ou un contournement raisonnable. Les évolutions fonctionnelles, nouveaux modules, formations supplémentaires, modifications non autorisées, reconstructions après interventions du Client et changements majeurs d’API tiers sont hors forfait, sauf inclusion expresse. Une analyse ou intervention supplémentaire payante requiert un devis accepté.

Le Prestataire annonce les maintenances planifiées susceptibles d’interrompre le service au moins deux jours ouvrés à l’avance, avec leur plage et durée estimée, et privilégie une intervention de moins de deux heures pendant les horaires de support. Cette durée est un objectif de planification, pas un plafond absolu ; une opération plus longue est annoncée et coordonnée. Une correction urgente de sécurité peut être appliquée sans préavis complet, avec information dès que possible. Avant une migration, le Prestataire vérifie la compatibilité du périmètre commandé et prévoit une sauvegarde ou un mécanisme de retour arrière adapté. Les mises à jour modifiant sensiblement le périmètre sont convenues avec le Client.

Un objectif de prise en charge mesure le temps avant examen d’une demande, pas le temps garanti de résolution. Tout SLA chiffré doit préciser la période de mesure, le point de mesure, les exclusions limitées et justifiées, les crédits, leur plafond et le recours en cas de défaillance répétée. Un éventuel crédit ne constitue pas un recours exclusif lorsque la loi s’y oppose.

Le support standard est assuré par email, du lundi au vendredi de 9 h à 18 h, heure de Paris, hors jours fériés français. Le canal est celui du Bon de commande ; à défaut, [email protected] reçoit et oriente les demandes. Deux interlocuteurs habilités du Client centralisent les tickets. Une demande comprend l’instance, l’impact, les étapes de reproduction, les heures constatées et les éléments disponibles, sans secret dans le corps du message. Une notification hors horaires est enregistrée mais le décompte commence à la prochaine ouverture ; un jour ouvré de support correspond à neuf heures de couverture. La qualification ne doit pas retarder artificiellement la prise en charge.

Pour une priorité 1 nécessitant une restauration, l’objectif de rétablissement (RTO) est de deux jours ouvrés de support à compter du signalement suffisamment exploitable, en utilisant une sauvegarde valide, les accès disponibles et une infrastructure de remplacement mobilisable. Le rétablissement peut être provisoire ou limité aux fonctions essentielles. Cet objectif ne garantit pas la correction définitive d’un défaut ni la restauration instantanée d’un stockage volumineux. Les dépendances ou impossibilités sont expliquées, une estimation actualisée et un contournement sont recherchés. Les obligations d’alerte et d’assistance urgente du DPA restent applicables sans attendre ces délais.

Le service est destiné à rester accessible en continu, sous réserve des maintenances et incidents, mais le forfait standard ne comprend ni équipe dédiée, ni astreinte humaine de nuit, de week-end ou de jour férié, ni taux de disponibilité garanti ou crédits automatiques. Un support renforcé ou un SLA garanti exige une capacité d’exploitation effectivement disponible et un accord distinct. Les objectifs ci-dessus sont des engagements de diligence mesurables, pas une exclusion de responsabilité ni des délais laissés au seul choix du Prestataire. Les droits en cas de manquement substantiel restent ceux des CGV.

Le Prestataire maintient la version déployée et les composants commandés dans l’environnement documenté, puis organise les mises à jour nécessaires. Sauf urgence de sécurité ou contrainte de tiers impossible à anticiper, une fin de support d’une version ou un changement incompatible d’API documentée est annoncé au moins quatre-vingt-dix jours à l’avance, avec une voie de migration. Le maintien du périmètre déjà commandé ne crée pas de nouvelle licence payante. Les API non documentées ne font pas l’objet d’une garantie de stabilité. Le Client utilise un navigateur récent encore maintenu par son éditeur, protège ses postes et sa connexion et suit les prérequis communiqués avant commande. Une fonctionnalité expérimentale ou bêta n’est activée que sur accord exprès, avec limites et précautions documentées ; elle ne remplace pas sans accord une fonction de production commandée.

En cas de panne de l’hébergeur ou d’une dépendance externe, le Prestataire recherche l’origine, ouvre ou suit les demandes auprès du fournisseur compétent, informe le Client de l’impact connu et étudie un contournement ou une reprise raisonnable dans le périmètre commandé. Il conserve les éléments de suivi utiles, notamment avis d’incident, tickets, horaires et démarches. Les délais annoncés par le tiers sont communiqués comme des estimations de ce tiers, sans être présentés comme une garantie propre de Damvia. Le diagnostic, les points d’information et les opérations de reprise incluses ne deviennent pas des prestations supplémentaires du seul fait de la panne ; une architecture renforcée hors commande nécessite un accord distinct.

Seul le décompte de l’objectif de restauration peut être prolongé de la durée documentée pendant laquelle une cause exclusivement externe empêche effectivement l’opération et ne peut être raisonnablement évitée ou contournée dans le périmètre convenu. Cette durée, son motif et l’estimation actualisée sont communiqués au Client. Une panne générale ne suspend pas les opérations encore réalisables, la première réponse, le diagnostic, l’information ou les alertes et obligations du DPA. Le décompte reprend dès la levée de l’obstacle. Cette adaptation ne s’applique pas au retard causé ou aggravé par le Prestataire, notamment défaut de paiement de l’hébergeur, mauvaise configuration, sauvegardes non réalisées ou défaut de diligence. Elle ne supprime pas les recours pour manquement, les obligations essentielles ni les règles de force majeure des CGV.

Le forfait standard ne comprend pas de bascule automatique vers un autre hébergeur, de redondance entre plusieurs centres de données ou de plan de continuité multirégion. Un stockage de sauvegarde distinct du serveur peut rester chez le même hébergeur et être affecté par une panne commune ; il ne vaut pas une infrastructure de secours indépendante. Les mesures réellement choisies sont documentées dans la fiche. Une reprise sur une autre infrastructure est étudiée lorsque la panne se prolonge, sous réserve de sauvegardes accessibles, de ressources disponibles et des règles de sécurité, de sous-traitance et de localisation du DPA. L’absence de redondance expressément non commandée ne dispense pas des sauvegardes et mesures de sécurité effectivement convenues.

5. Capacité et dépendances

Les caractéristiques et quotas proviennent de la fiche. Le Prestataire alerte le Client avant un dépassement prévisible et propose un ajustement. Une mention « utilisateurs illimités » ne crée pas un quota caché ; elle signifie l’absence de facturation par utilisateur dans l’enveloppe de ressources convenue. Aucune réduction d’un engagement « illimité » déjà accepté n’est implicite. Une saturation ou un abus peut justifier des mesures proportionnées, expliquées, pour préserver la sécurité et la continuité.

Pour les nouvelles formules hébergées standard, Growth comprend au plus cent comptes utilisateurs actifs autorisés à se connecter, administrateurs et invités disposant d’un compte inclus. Les comptes désactivés et visiteurs anonymes d’un lien public ne sont pas comptés ; les identifiants sont individuels et ne sont pas partagés pour contourner la limite. Enterprise et Premium n’ont pas de plafond numérique d’utilisateurs ni de supplément par utilisateur. Une évolution de Growth au-delà de cent comptes nécessite un changement de formule ou un accord écrit, sans facturation automatique. Ces conditions commerciales du service géré ne restreignent pas le socle libre auto-hébergé et ne modifient pas les commandes existantes. Les limites d’API, de trafic ou de charge technique réellement nécessaires sont indiquées avant commande ou convenues en cours de contrat ; l’absence de quota d’utilisateurs ne garantit pas une capacité CPU, mémoire ou réseau infinie.

Le fonctionnement des intégrations dépend des autorisations, quotas et disponibilités de leurs fournisseurs. Le Prestataire ne garantit pas les décisions futures d’un tiers mais conserve ses engagements de diagnostic, d’information et de maintenance convenus.

La fiche précise l’unité de stockage retenue (Go/To décimaux ou Gio/Tio), les catégories comptabilisées, le mode et la période de mesure, le seuil d’alerte, le volume inclus et le tarif unitaire de dépassement lorsqu’il est commandé. Les originaux, aperçus, archives temporaires et sauvegardes ne sont pas facturés comme une même catégorie sans précision préalable. À défaut de prix de dépassement accepté, un complément de facturation requiert un accord écrit ; une alerte de capacité ne vaut pas acceptation d’un supplément.

6. Réversibilité et inventaire des données

Sur demande du contact habilité, le Prestataire fournit un inventaire et un export standard sécurisé comprenant les contenus du Client disponibles dans l’instance, métadonnées, fiches produits, collections, pages, paramètres propres au Client, données métier des modules et journaux exportables le concernant, sous réserve des droits de tiers et de la sécurité. Les formats prévus sont PostgreSQL pour la base, JSON ou CSV pour les données structurées lorsque pertinent, fichiers dans leur format disponible et documentation de schéma/configuration nécessaire à leur interprétation. Le Bon de commande précise les formats réellement disponibles par module et le périmètre technique avant signature.

L’export exclut les secrets internes du Prestataire, les données d’autres clients et le code propriétaire ; cette exclusion ne permet pas de retenir les données métier ou les métadonnées nécessaires à leur réutilisation. Les secrets propres au Client sont transférés par un canal approprié ou remplacés. L’export personnel d’un compte utilisateur ne remplace pas l’export complet d’une instance ; ce dernier peut nécessiter une intervention technique.

Un export standard de fin de contrat et la documentation existante sont inclus. L’assistance supplémentaire librement demandée, telle qu’une refonte fonctionnelle chez le prestataire destinataire, fait l’objet d’un devis, sans requalifier en prestation payante une opération de changement que la loi impose gratuitement.

7. Organisation de la sortie

Le Client peut demander un changement de prestataire ou un retour sur sa propre infrastructure par écrit, en indiquant le destinataire et la date souhaitée. Par défaut, le préavis de déclenchement est de trente jours et la période de transition ne dépasse pas trente jours calendaires après ce préavis. Le service est maintenu pendant la transition convenue, avec coopération raisonnable des parties et du destinataire, protection des données et continuité appropriée. La demande de changement vaut notification de fin des services affectés à l’achèvement réussi de la transition ; le Prestataire confirme la date et les conséquences financières par écrit. Les redevances ordinaires restent dues pour le service effectivement fourni et toute indemnité distincte doit respecter les CGV/CGS et le droit applicable.

Lorsque le chapitre VI du règlement (UE) 2023/2854 s’applique, ces délais s’interprètent conformément à ses exigences. Si la transition standard est techniquement irréalisable, le Prestataire en expose les motifs au Client dans les quatorze jours ouvrables suivant la demande et indique un délai alternatif n’excédant pas sept mois ; le Client conserve son droit de prolonger une fois la transition pour la durée qu’il estime appropriée à ses besoins. Les autres modalités impératives plus favorables s’appliquent.

Les données restent récupérables pendant au moins trente jours après la fin de la transition. Après ce délai, ou plus tôt sur instruction écrite compatible avec les obligations légales, les données de production sont effacées dans les trente jours ; les copies de sauvegarde expirent selon la rotation convenue au DPA, sans dépasser quatre-vingt-dix jours après l’effacement de production. Elles restent isolées et ne sont utilisées que pour restauration nécessaire ou obligation légale ; toute restauration réapplique les demandes d’effacement. Une attestation est fournie sur demande.

Aucun frais de changement imposé par le règlement précité n’est facturé à compter du 12 janvier 2027. Avant cette date, d’éventuels frais légalement admissibles doivent être annoncés avant contrat et ne peuvent dépasser les coûts directement liés au changement ; le présent contrat inclut déjà l’export standard. Les frais de résiliation anticipée, les redevances ordinaires et les services supplémentaires sont distingués et ne doivent pas contourner cette règle.

Une instance dédiée ou configurée n’est pas présumée exemptée. Une éventuelle dérogation propre aux services majoritairement développés pour un client ne peut être invoquée que si ses conditions légales sont vérifiées et l’information requise remise avant contrat ; elle n’écarte que les obligations visées par la loi. Les droits sur le socle open source restent indépendants de ces règles de sortie.

Après remise et reprise effective sur l’infrastructure du Client ou d’un nouveau prestataire, ce dernier assume les opérations d’hébergement, de maintenance, de sécurité et de conformité qui lui sont transférées. Le Prestataire sortant ne fournit plus de service continu hors prestation convenue, sans être déchargé de ses manquements antérieurs, de ses obligations de transition ou de toute responsabilité légalement maintenue.