Contrat SaaS – que doit contenir l'accord ? 12 points à réglementer

Par Mallbutiken · Données vérifiées le 1er octobre 2026 · Environ 9 minutes de lecture

Un bon contrat SaaS décrit bien plus que le simple droit d'utiliser un logiciel. Il doit définir clairement ce que comprend le service, quel niveau de disponibilité et de support est promis, comment les données client sont traitées, quelles exigences de sécurité s'appliquent, quelles sont les responsabilités des parties et comment le client peut récupérer ses données à la fin du contrat.

Qu'est-ce qu'un contrat SaaS ?

SaaS signifie Software as a Service (Logiciel en tant que service). Le client obtient normalement accès à un service logiciel via Internet au lieu d'acheter une copie traditionnelle du logiciel. Le contrat devient donc une combinaison de conditions commerciales, de droits d'utilisation, d'engagements de fonctionnement et de support, ainsi que de règles relatives aux données et à la sécurité.

Il n'existe pas de loi suédoise spécifique qui dicte seule l'apparence d'un contrat SaaS B2B. Le contenu concret du contrat est donc central. Le droit des contrats général s'applique, et selon le service, des réglementations sur la protection des données, le droit d'auteur, les règles de cybersécurité et des exigences sectorielles peuvent devenir pertinentes.

12 questions auxquelles un contrat SaaS doit répondre

1. Qu'est-ce qui est inclus dans le service ? Décrivez les modules, les fonctionnalités, le nombre d'utilisateurs, les intégrations, le stockage, l'implémentation et les limitations explicites.
2. Quand le service est-il considéré comme livré ? Si l'implémentation ou la migration est incluse, les jalons, les tests et les critères d'acceptation doivent être précisés.
3. Quel niveau de service s'applique ? Indiquez comment la disponibilité est mesurée, quelles sont les exceptions et ce qui se passe en cas d'écarts récurrents.
4. Comment fonctionne le support ? Définissez les canaux de contact, les horaires d'ouverture, les niveaux de priorité, le temps de réponse initial et l'escalade.
5. Qui a droit aux données client ? Distinguez les données du client du logiciel du fournisseur, des statistiques et des autres actifs immatériels.
6. Comment les données personnelles sont-elles traitées ? Déterminez les rôles et associez le DPA (Data Processing Agreement) approprié lorsque le fournisseur est un sous-traitant.
7. Quelles exigences de sécurité s'appliquent ? Rendez les exigences en matière d'accès, d'authentification multifacteur (MFA), de journalisation, de gestion des vulnérabilités, de sauvegarde et d'incidents faciles à suivre.
8. Des sous-traitants peuvent-ils être utilisés ? Précisez comment les sous-traitants critiques et les éventuels sous-sous-traitants sont gérés et comment les changements sont communiqués.
9. Comment le service peut-il être modifié ? Régulez les changements de version, les fonctionnalités supprimées et ce qui se passe si un changement affecte de manière significative l'utilisation par le client.
10. Comment fonctionnent le prix et l'ajustement des prix ? Indiquez la redevance de base, les frais basés sur l'utilisation, la surconsommation, l'indexation, le temps de consultation et quand les prix peuvent être modifiés.
11. Comment la responsabilité est-elle répartie ? Définissez les erreurs, la remédiation, les éventuels crédits de service, les types de dommages, les plafonds de responsabilité et les exceptions pertinentes.
12. Que se passe-t-il à la fin du contrat ? Déterminez à l'avance l'exportation, le support à la migration, la suppression, les délais et les coûts.

SLA : rendre le niveau de service mesurable

Une « haute disponibilité » est difficile à contrôler. Un accord de niveau de service (SLA) utile décrit ce qui est mesuré et comment. L'objectif de disponibilité doit être combiné avec des définitions pour la maintenance planifiée, les erreurs causées par le client et d'autres exceptions.

RTO et RPO sont souvent utilisés pour la restauration et la perte de données, mais les chiffres doivent être basés sur le service réel et les besoins du client. Approfondissez ce sujet dans le guide sur le SLA, la disponibilité, le RTO et le RPO.

RGPD : quand un accord de sous-traitance est-il nécessaire ?

Si le fournisseur SaaS traite des données personnelles pour le compte du client, l'article 28 du RGPD est central. Le traitement doit alors être régi par un contrat ou un autre acte juridique contraignant avec les tâches et obligations requises par l'article.

Commencez par la répartition des rôles. Le fournisseur n'est pas automatiquement un sous-traitant simplement parce que des données personnelles sont présentes dans le service. Lisez quand un accord de sous-traitance est nécessaire et ce qu'il doit contenir. Si des sous-sous-traitants ou des transferts vers des pays tiers sont impliqués, ces questions doivent également être gérées.

Séparez la question commerciale des données du rôle de protection des données

Le contrat doit également préciser ce que le client peut exporter et utiliser après la fin du contrat. La question commerciale du droit aux données client n'est pas identique à la question RGPD de la responsabilité du traitement des données personnelles et de la sous-traitance.

Sécurité : rédigez des exigences vérifiables

Adaptez l'annexe de sécurité en fonction de la sensibilité des données et de la criticité opérationnelle. Des exemples de domaines concrets sont la gestion des identités et des accès, l'authentification multifacteur (MFA), le chiffrement, la journalisation, la gestion des vulnérabilités et des correctifs, le développement sécurisé, la sauvegarde, la communication des incidents et la continuité.

Pour les entreprises soumises à la loi sur la cybersécurité, la chaîne d'approvisionnement est explicitement l'un des domaines sur lesquels les mesures de sécurité doivent au moins porter. Un contrat de fournisseur peut donc être un outil important pour poser des exigences et les suivre, mais le contrat ne remplace pas la propre gestion des risques. Lisez également le guide sur NIS2 et les exigences de sécurité dans les contrats de fournisseurs.

Planifiez la sortie quand la relation fonctionne encore

Il est souvent coûteux de commencer à discuter de l'exportation des données seulement lorsque les parties veulent se séparer. Régulez donc la sortie dès la conclusion du contrat.

• Quel format d'exportation le client obtient-il ?
• Les métadonnées, la configuration et les pièces jointes sont-elles incluses ?
• Pendant combien de temps l'exportation est-elle possible après la résiliation ?
• Le client peut-il utiliser une API pour la migration ?
• Quel support à la migration est inclus et combien coûte le travail supplémentaire ?
• Quand les données de production, les données de test et les copies sont-elles supprimées ?
• Le fournisseur peut-il fournir un certificat de suppression ?

Une bonne clause de sortie réduit le risque d'enfermement propriétaire et facilite la comparaison des fournisseurs avant même l'achat. Approfondissez ce domaine dans Sortie SaaS et migration de données – check-list contractuelle, qui passe en revue les formats d'exportation, l'API, les métadonnées, le support à la migration, la sauvegarde et la suppression.

Plafonds de responsabilité : liez le niveau au risque réel

Il n'existe pas de pourcentage universel qui convienne à toutes les entreprises SaaS. Un plafond de responsabilité raisonnable dépend notamment de la valeur du contrat, de la sensibilité des données, de la dépendance opérationnelle, des assurances et des dommages indirects possibles. Vérifiez également quels événements sont exclus du plafond et si la limitation de responsabilité interagit avec les crédits de service, la confidentialité, les données personnelles et la propriété intellectuelle.

L'article 36 de la loi sur les contrats donne la possibilité d'ajuster ou de laisser de côté des clauses contractuelles déraisonnables, mais ce n'est pas un substitut à la négociation d'une répartition des risques bien pensée dès le début.

Check-list avant signature

• La portée du service et toutes les exceptions importantes sont-elles documentées ?
• Les valeurs du SLA peuvent-elles être mesurées avec des données que les deux parties peuvent contrôler ?
• Les voies de support et d'incident sont-elles claires ?
• Les rôles relatifs aux données personnelles, les sous-sous-traitants et les flux internationaux ont-ils été évalués ?
• Les exigences de sécurité correspondent-elles au risque du service et aux éventuelles exigences sectorielles du client ?
• Les changements de prix et la surconsommation sont-ils prévisibles ?
• Les règles pour les fonctionnalités modifiées sont-elles claires ?
• Les plafonds de responsabilité et les exceptions ont-ils été choisis consciemment ?
• Les données du client peuvent-elles être exportées en pratique ?
• La résiliation, la suspension et la sortie sont-elles coordonnées ?

Besoin d'un dossier contractuel complet ?

Le contrat SaaS pour B2B de Mallbutiken contient le contrat principal et six annexes concernant notamment la spécification du service, le SLA, le DPA/RGPD, la sécurité, la sortie et les prix. Livré en format Word et PDF modifiable. Prix en boutique : 149 kr.

Voir le modèle de contrat SaaS

Questions fréquentes

Un contrat SaaS est-il la même chose qu'un contrat de licence ?

Pas nécessairement. Un contrat SaaS doit normalement aussi gérer le service continu, le fonctionnement, le support, les données, la sécurité et la sortie. La partie licence n'est qu'une partie de la relation.

Un contrat SaaS B2B doit-il être écrit ?

Il n'y a pas d'exigence de forme générale pour tous ces contrats, mais un contrat écrit est important pour pouvoir démontrer la portée du service et la répartition des risques. Certaines parties peuvent en même temps être soumises à leurs propres exigences, par exemple les exigences du RGPD concernant la régulation contraignante du traitement par le sous-traitant.

Le fournisseur peut-il modifier les fonctionnalités pendant la durée du contrat ?

Cela dépend du contrat. Régulez donc le droit de modification, la manière dont le client est informé et ce qui se passe si une fonctionnalité essentielle est supprimée ou modifiée.