- Accueil
- Solutions
- Pourquoi Klytic
- Guides
- Tarifs
- Partenaires
- Contact
-
-
Souveraineté
On protège une entreprise du CLOUD Act en choisissant qui détient les données, pas en déplaçant seulement les serveurs. La loi américaine de 2018 permet à une autorité des États-Unis, dans une procédure, d’exiger d’un prestataire soumis à ses juridictions les données que ce prestataire détient ou contrôle, y compris si elles sont stockées hors des États-Unis. Elle ne crée pas un accès automatique aux datacenters européens.
Le CLOUD Act (Clarifying Lawful Overseas Use of Data Act) modifie le droit américain des communications stockées. Trois limites évitent les contresens.
Le risque réel est donc plus étroit qu’on ne le dit, et plus durable : une demande ciblée, adressée au prestataire, dans le cadre d’une procédure.
La loi organise aussi des accords entre gouvernements pour encadrer certaines demandes transfrontières. Ce volet ne change pas la question d’achat : qui, dans votre chaîne, est un prestataire américain ayant le contrôle des données ?
L’injonction est adressée au prestataire et porte sur les données qu’il a sous sa détention ou son contrôle. Le client dépend alors de ce que le prestataire fera de la demande.
Selon 18 U.S.C. § 2703(h), le prestataire peut demander l’annulation ou la modification de l’injonction s’il estime que le client n’est pas une « United States person », ne réside pas aux États-Unis, et que la communication l’exposerait à un risque sérieux de violer le droit d’un « gouvernement étranger qualifié ». Il dispose de 14 jours après la signification.
Un « gouvernement étranger qualifié » est un État qui a conclu avec les États-Unis un accord exécutif entré en vigueur. Le ministère américain de la Justice publie des accords avec le Royaume-Uni, signé le 3 octobre 2019, et avec l’Australie, signé le 15 décembre 2021. Aucun accord n’est en vigueur avec l’Union européenne ; des négociations UE–États-Unis sur la preuve électronique ont repris en 2023. La page du ministère ne mentionne aucun accord avec la France.
Conséquence : le mécanisme de contestation propre au § 2703(h) suppose un tel accord. Une entreprise française ne doit pas compter sur ce recours comme sur une protection acquise.
Le critère de la loi est le contrôle, pas la géographie. Soit une PME industrielle avec deux sites qui a choisi une région de données européenne chez un éditeur américain. Ses messages sont stockés en Europe. Mais la société qui administre le service et peut restaurer une boîte reste américaine. Face à une injonction, la région de stockage ne change pas la question : ces données sont-elles sous son contrôle ?
Le 10 juin 2025, devant la commission d’enquête du Sénat sur la commande publique, le directeur des affaires publiques et juridiques de Microsoft France a été interrogé : pouvait-il garantir sous serment que les données des citoyens français confiées à Microsoft via l’Ugap ne seraient jamais transmises, à la suite d’une injonction du gouvernement américain, sans l’accord explicite des autorités françaises ? Sa réponse : « Non, je ne peux pas le garantir, mais, encore une fois, cela ne s’est encore jamais produit. » Les deux moitiés de la phrase comptent. La première décrit le cadre juridique ; la seconde, la pratique constatée par l’entreprise.
Le droit marocain aborde la question par l’autre bout. Selon l’article 43 de la loi n° 09-08, des données personnelles ne peuvent être transférées vers un État étranger que si cet État assure un niveau de protection suffisant. L’article 44 prévoit des exceptions, dont le consentement exprès de la personne, l’exécution d’un contrat ou une autorisation expresse et motivée de la CNDP.
Au Maroc, la loi n° 09-08 a été promulguée par le dahir n° 1-09-15 du 18 février 2009 et publiée au Bulletin officiel n° 5714 du 5 mars 2009. Elle est appliquée sous le contrôle de la CNDP, et soumet les traitements à une déclaration préalable ou, pour certains, à une autorisation préalable (article 12). Une réforme est discutée ; le texte en vigueur reste celui de 2009.
Un prestataire américain qui sert des clients marocains peut donc se trouver entre deux droits : une injonction américaine d’un côté, une loi marocaine qui encadre tout transfert vers un État étranger de l’autre. Les articles 43 et 44 ne tranchent pas ce conflit à la place du prestataire. Pour l’acheteur, l’enjeu est concret : demander comment ce prestataire traite une telle demande, s’il la conteste, et s’il en informe le client lorsque la loi le permet.
Un service d’éditeur américain comporte en général des transferts vers un État étranger : stockage dans une région située hors du pays, accès du support, escalades. Chacun doit reposer sur l’article 43 (niveau de protection suffisant de l’État de destination) ou sur l’une des exceptions de l’article 44, dont le consentement exprès, l’exécution d’un contrat ou une autorisation expresse et motivée de la CNDP. La loi impose aussi des mesures techniques et organisationnelles appropriées, et le choix d’un sous-traitant offrant des garanties suffisantes, encadré par contrat (article 23).
Ces règles encadrent les transferts au sens du droit marocain. Elles ne retirent pas un prestataire américain du champ du CLOUD Act. Une entreprise prudente documente ce fondement et prévoit quoi faire s’il tombe. Ce suivi relève de la documentation des traitements, pas d’un slogan.
Choisir l’exploitant. Si la société qui facture, sauvegarde et administre le service est européenne, et qu’elle ne dépend pas d’un groupe américain pour la détention des données, l’injonction du CLOUD Act ne s’adresse pas à elle. C’est le levier principal.
Lire les sous-traitants. Un opérateur européen qui envoie les mails, les sauvegardes ou le support à un sous-traitant américain réintroduit un prestataire soumis au droit américain. La liste des sous-traitants fait partie de la protection. L’erreur fréquente : vérifier l’hébergeur principal et oublier l’outil de tickets ou la sauvegarde.
Distinguer l’éditeur et l’exploitant. Utiliser un logiciel dont l’éditeur est américain n’équivaut pas à confier les données à cet éditeur. Zimbra est édité par Synacor, aux États-Unis. Installé et sauvegardé par un hébergeur européen, dans les salles de cet hébergeur, le détenteur opérationnel des boîtes est l’hébergeur. Le contrat doit interdire à l’éditeur un accès aux contenus, et dire qui applique les correctifs.
Traiter le support comme un accès. Un technicien qui ouvre une boîte ou une sauvegarde traite des données. Le lieu de ce technicien, la trace de l’accès et le motif comptent autant que le lieu du disque.
Chiffrer avec une clé que vous détenez, lorsque le service le permet. Le chiffrement au repos dont le prestataire détient la clé le protège contre le vol de disque. Il ne l’empêche pas de lire les données pour rendre le service, ni de les produire s’il y est contraint. Un chiffrement dont vous seul détenez la clé change la donne sur le contenu. Sur une suite complète, il ne couvre pas toujours toutes les étapes : certaines exigent que le service traite le contenu, et le chiffrement y est alors du ressort de l’éditeur ou de l’exploitant (filtrage et quarantaine, indexation pour la recherche, traitement de documents dans un CRM). Les bonnes questions sont donc : à quelles étapes le prestataire gère-t-il la clé, combien de temps les données y restent-elles, et qui peut y accéder ? Il faut lire le périmètre.
Garder une sortie. Export régulier, formats ouverts, et essai de restauration. Une protection juridique sans copie récupérable est incomplète.
Le CLOUD Act n’est pas non plus le seul critère. Une entreprise aux données peu sensibles, qui dépend de fonctions avancées de Microsoft 365 ou de Google Workspace et documente le fondement de ses transferts, peut raisonnablement rester. Le choix devient discutable quand il n’a pas été fait : personne n’a nommé le détenteur des données ni prévu de sortie. Les pages cloud européen ou cloud américain et Microsoft 365 ou solution souveraine développent cet arbitrage.
Exemple : un cabinet d’expertise comptable de 25 personnes qui fait cet exercice constate souvent que la messagerie est bien identifiée, mais que l’outil de signature, le partage de fichiers avec les clients ou la sauvegarde ont été ajoutés sans vérifier l’exploitant. Ce sont ces lignes à encadrer en priorité.
Microsoft 365, Google Workspace et Klytic sont comparés dans la page Microsoft 365, Google Workspace et Klytic ; les critères généraux, dans qu’est-ce qu’un cloud souverain.
Non. La loi vise le prestataire soumis au droit américain qui a la détention ou le contrôle des données, où qu’elles soient stockées. Le lieu du disque reste utile, mais il ne répond pas à la question de l’exploitant.
Le § 2703(h) prévoit un recours en annulation ou en modification, dans les 14 jours suivant la signification. Ce recours suppose un accord exécutif en vigueur avec le pays concerné. La page du ministère américain de la Justice ne mentionne aucun accord avec la France, et aucun n’est en vigueur avec l’Union européenne.
Elle pose une règle marocaine : un transfert vers un État étranger suppose un niveau de protection suffisant (article 43), sauf exceptions (article 44). Elle place le prestataire américain dans un conflit de lois, sans le résoudre à sa place.
Dedicace Software, société française, exploite Klytic. L’hébergement est assuré dans toute zone géographique correspondant à la juridiction applicable, sous réserve de la disponibilité des services requis, ou sur les serveurs du client. Le logiciel de messagerie est Zimbra, édité aux États-Unis : la protection vient de l’exploitant et du contrat d’exploitation, pas de la nationalité de l’éditeur. L’éditeur n’a pas accès aux données et ne peut pas contraindre Klytic à les lui transmettre.
La protection contre les risques liés au CLOUD Act ne repose pas uniquement sur le lieu où sont hébergées les données. Elle dépend également de la juridiction de l’opérateur, de son organisation, de ses accès techniques et de la manière dont les données sont chiffrées.
Chez Klytic, les communications entre les utilisateurs et les services de la plateforme sont protégées par TLS. Pour la messagerie, ce chiffrement est assuré depuis Klytic MTA jusqu’au poste ou au logiciel de messagerie de l’utilisateur, et dans le sens inverse. Lorsqu’un message est échangé avec un domaine externe, Klytic maintient le chiffrement lorsque le serveur distant prend en charge TLS ; la dernière partie du trajet ne peut toutefois pas être garantie par Klytic lorsque le serveur destinataire ne le prend pas en charge.
Le chiffrement du stockage doit être distingué du chiffrement dont la clé est détenue par le client.
Pour les documents, le chiffrement à la source est systématiquement activé. La clé est générée à partir du compte du client et Klytic ne peut pas la lire. Sans le secret nécessaire à son déverrouillage, Klytic ne peut donc pas accéder au contenu en clair. Les documents sont ainsi chiffrés avant leur conservation dans l’infrastructure et restent protégés par une clé que Klytic ne détient pas.
La messagerie repose sur un mécanisme différent. Les mails sont chiffrés sur les supports de stockage de Klytic avec des clés gérées par Klytic. Ce chiffrement protège notamment les données contre l’accès direct aux supports, mais Klytic doit pouvoir déchiffrer les messages pour assurer les fonctions de messagerie, de filtrage et de traitement du service.
Le client peut en outre utiliser un chiffrement de message à message, notamment avec S/MIME ou GPG. Dans ce cas, la clé privée reste exclusivement détenue par le client. Klytic peut transporter et stocker le message chiffré, mais ne dispose pas de la clé privée permettant d’en lire le contenu.
Le stockage lui-même est également chiffré sur disque par Klytic. Cette seconde protection sécurise les données présentes sur les supports, mais ne doit pas être confondue avec le chiffrement à la source : le chiffrement à la source protège le contenu avec une clé que Klytic ne détient pas, tandis que le chiffrement du stockage est géré par Klytic afin de permettre au service de fonctionner.
Cette distinction permet de limiter concrètement les données auxquelles Klytic pourrait techniquement accéder. Elle ne constitue toutefois pas, à elle seule, une protection juridique contre une demande d’accès : la souveraineté repose également sur la juridiction applicable à l’opérateur et à l’infrastructure, ainsi que sur la gouvernance des accès.
Chez Klytic, l’accès aux comptes de messagerie des clients est prohibé. Les accès sont contrôlés et audités, et des alertes permettent de détecter les comportements susceptibles de révéler une utilisation frauduleuse. Les mécanismes de protection technique viennent ainsi compléter les garanties apportées par la localisation de l’infrastructure et la juridiction applicable.
Pour garantir une confidentialité du contenu que Klytic ne puisse pas lever lui-même, le client bénéficie donc, pour les documents, du chiffrement à la source systématique, et peut utiliser pour ses messages un chiffrement de bout en bout tel que S/MIME ou GPG, dont il conserve la clé privée.
Voir aussi la page hébergement et souveraineté.
Klytic n’est pas qualifié SecNumCloud. Aucune de ces phrases ne constitue une immunité générale : un opérateur français reste soumis au droit français.
Cette page décrit un cadre général. Elle ne constitue pas un conseil juridique.
Point juridique au 5 octobre 2026. Ce texte ne remplace pas l’analyse d’un contrat. Au Maroc, la loi n° 09-08 encadre le traitement des données personnelles et leur transfert vers l’étranger ; la CNDP en contrôle l’application. Le catalogue ANSSI fait foi pour SecNumCloud.
Consultées en octobre 2026.
Messagerie, documents, visioconférence, CRM et téléphonie, hébergés dans la zone qui correspond à votre juridiction, ou chez vous.
Offre de bienvenue
Offre d'essai sans engagement. Un conseiller vous rappelle pour comprendre vos besoins et préparer votre espace Klytic.
