Modèles de déploiement pour les organisations réglementées : comparaison des enjeux de souveraineté et de conformité

Les organisations réglementées se heurtent à un problème structurel lorsqu’elles évaluent les plateformes de partage de fichiers et de contenu en entreprise : la question n’est jamais simplement « quel modèle de déploiement est le plus sûr ? » mais bien « quel modèle de déploiement nous offre le niveau de souveraineté, la couverture de certification et le contrôle opérationnel exigés par notre environnement réglementaire — et qu’est-ce qui change concrètement lorsque l’on passe de l’un à l’autre ? »

La réponse est plus complexe que ce que les fournisseurs admettent généralement. Les déploiements sur site, en cloud privé, en cloud autorisé FedRAMP, hybrides et en environnement isolé (air-gapped) reposent tous sur des technologies de base similaires. Mais leur couverture d’attestation de conformité, leurs garanties de résidence des données, leur contrôle opérationnel client et leurs implications en matière de souveraineté diffèrent de façon significative pour les équipes achats, les DPO et les architectes sécurité. Une certification valable pour un modèle de déploiement peut ne pas s’appliquer du tout à un autre. Un engagement de résidence des données dans l’UE valable pour un SaaS peut nécessiter une négociation contractuelle dans un autre mode de livraison.

Cet article cartographie ces différences. Il détaille ce que chaque modèle de déploiement implique réellement en matière de souveraineté, quelles certifications s’appliquent à quel modèle, et quelles questions les équipes achats doivent poser pour combler les lacunes documentaires que laissent la plupart des fournisseurs. L’analyse s’adresse aux équipes évaluant des plateformes pour des charges de travail réglementées — défense, services financiers, santé, infrastructures critiques — où le choix du modèle de déploiement relève de la conformité, et non d’une simple préférence architecturale.

Résumé Exécutif

À retenir : Les différents modèles de déploiement entraînent des conséquences très concrètes en matière de souveraineté et de conformité — pas seulement en théorie, mais aussi dans le périmètre de certification, les garanties de résidence des données et le contrôle opérationnel client. Les équipes achats doivent disposer d’une vision spécifique à chaque modèle de déploiement concernant la couverture de conformité, et non d’une simple liste de certifications laissant penser qu’elles s’appliquent uniformément à toutes les options de livraison.

Pourquoi c’est important : NIS 2, DORA et des cadres comme BSI C5, IRAP et G-Cloud 14 imposent aux organisations de vérifier que les contrôles sur lesquels elles s’appuient sont effectivement attestés pour le modèle de déploiement utilisé. Une attestation BSI C5 pour un service cloud managé ne couvre pas automatiquement un déploiement sur appliance sur site, et inversement. Pour combler cette lacune, les fournisseurs doivent publier — et les organisations demander — une matrice de correspondance reliant les certifications aux modèles de déploiement. La plupart des fournisseurs ne le font pas à ce jour.

5 points clés à retenir

1. Le choix du modèle de déploiement relève de la conformité, pas seulement de l’architecture. Le modèle choisi détermine les certifications applicables, la résidence des données possible, les obligations de contrôle opérationnel et la capacité à fournir des preuves d’audit de façon autonome. Ce sont des questions réglementaires à trancher avant de finaliser l’architecture technique — pas après.
2. Les certifications ne sont pas automatiquement transférables entre modèles de déploiement. Un fournisseur disposant de BSI C5 Type 2, ISO 27001 et SOC 2 Type II a obtenu ces attestations pour un environnement cloud managé précis. L’appliance sur site du même fournisseur peut bénéficier de tout ou partie de ces attestations, ou d’aucune, selon le périmètre évalué par chaque organisme certificateur. Les équipes achats doivent demander explicitement : quelles certifications s’appliquent à quel modèle de déploiement ?
3. La résidence des données strictement UE est réellement atteignable en déploiement sur site — mais nécessite une vigilance accrue en SaaS. Un déploiement sur site, sur une infrastructure détenue par le client dans un État membre de l’UE, garantit la résidence physique et juridique des données dans cette juridiction, sans dépendance à l’infrastructure ou au routage du fournisseur. Les modèles SaaS et cloud privé exigent des engagements contractuels sur les régions UE et une vérification que les opérations du fournisseur, ses sous-traitants et l’accès support ne génèrent pas de transferts vers des pays tiers au sens du RGPD (Chapitre V).
4. Le déploiement air-gapped offre les garanties de souveraineté les plus fortes mais implique la charge opérationnelle la plus élevée. Aucune connectivité externe signifie aucun accès fournisseur via le cloud, aucune télémétrie sortante et aucune mise à jour automatique — ce qui élimine un pan entier de risques de souveraineté, mais transfère l’intégralité de la gestion des correctifs, de la supervision et de la gestion des incidents au client. Pour les charges de défense et de renseignement, ce compromis est souvent incontournable. Pour la plupart des entreprises réglementées, une appliance durcie avec connectivité contrôlée est un équilibre plus réaliste.
5. Il n’existe pas encore de matrice consolidée de correspondance des certifications sur le marché — et cette absence constitue un risque pour les achats. La plupart des plateformes publient des pages de conformité listant les certifications à l’échelle mondiale sans préciser celles qui s’appliquent à chaque modèle de déploiement. Les équipes achats qui se contentent d’une liste globale sans la relier à leur modèle de déploiement risquent de s’appuyer sur des attestations qui ne couvrent pas leur environnement réel. La bonne posture consiste à exiger de chaque fournisseur une déclaration de périmètre de certification spécifique au modèle de déploiement évalué.

Comprendre ce que détermine réellement le choix du modèle de déploiement

Avant de comparer les modèles, il est utile de préciser ce qui change — et ce qui ne change pas — lorsqu’on passe d’une option de déploiement à une autre pour une plateforme de partage de fichiers en entreprise. Cette distinction détermine les questions à poser côté achats et les affirmations que les fournisseurs peuvent ou non légitimement avancer.

Ce qui change selon les modèles de déploiement

Quatre éléments évoluent significativement selon le modèle de déploiement : le contrôle de l’infrastructure, la localisation physique et le routage des données, le périmètre des certifications applicables et la responsabilité opérationnelle en matière de disponibilité et de sécurité.

Le contrôle de l’infrastructure détermine si le client ou le fournisseur décide du rythme des correctifs, des changements de configuration, de l’achat du matériel et des contrôles d’accès physiques. La résidence des données détermine où les données sont stockées et si elles transitent par des réseaux soumis à une juridiction étrangère. Le périmètre de certification détermine si les attestations tierces détenues par le fournisseur couvrent effectivement l’environnement d’exploitation du client. La responsabilité opérationnelle détermine qui est responsable — contractuellement et réglementairement — de la disponibilité, de la gestion des incidents et des contrôles sous-jacents à ces responsabilités.

Ces quatre dimensions n’évoluent pas toujours de concert. Un déploiement offrant un contrôle fort de l’infrastructure peut présenter une couverture de certification limitée. Un service managé très certifié peut offrir des garanties de résidence des données plus faibles qu’une alternative sur site. Les équipes achats doivent évaluer chaque dimension séparément, sans considérer le « modèle de déploiement » comme une simple variable binaire.

Ce qui ne change pas : le cœur de la plateforme

Kiteworks repose sur une appliance virtuelle durcie unique qui constitue le socle de tous les modèles de déploiement — sur site, cloud privé, cloud autorisé FedRAMP et hybride. Cette cohérence architecturale a un impact réel sur la conformité : la configuration de l’appliance durcie, la pile de chiffrement, le cadre de contrôle d’accès et l’architecture des journaux d’audit ne sont pas des produits différents avec des postures de sécurité différentes. Il s’agit de la même plateforme exécutée dans des environnements opérationnels distincts.

Cette cohérence est essentielle car elle garantit que les contrôles vérifiés lors de l’évaluation pour un modèle de déploiement sont substantiellement les mêmes que ceux sur lesquels on s’appuiera dans un autre. Les variables sont l’environnement d’exploitation, le périmètre de certification et la répartition des responsabilités opérationnelles — pas l’architecture de sécurité sous-jacente.

Déploiement sur site : souveraineté maximale, responsabilité opérationnelle maximale

Le déploiement sur site — via une appliance virtuelle durcie exécutée sur du matériel contrôlé par le client — représente la posture de souveraineté la plus élevée pour le partage de fichiers en entreprise. Pour comprendre pourquoi, il faut saisir ce que recouvre la notion de souveraineté dans ce contexte, et à quel prix.

Ce que vous apporte le déploiement sur site

Lorsqu’une organisation réglementée opte pour un déploiement sur site, les données ne quittent jamais l’infrastructure propre à l’organisation. Aucun environnement cloud du fournisseur, aucun data center tiers, aucun réseau opéré par le fournisseur pour le transit des contenus. Les contrôles d’accès physiques et logiques relèvent entièrement du client. Le fournisseur ne peut accéder à l’environnement sans autorisation explicite et traçable du client.

Pour les organisations européennes soumises à des exigences strictes de résidence des données au titre du RGPD, c’est la solution la plus simple à la question des transferts vers des pays tiers (Chapitre V). Les données traitées et stockées sur l’infrastructure du client dans un État membre de l’UE restent soumises au droit européen — sans dépendre d’engagements contractuels du fournisseur sur les régions UE ou de clauses contractuelles types pour obtenir ce que l’architecture garantit structurellement.

Le déploiement sur site de Kiteworks s’appuie sur une appliance durcie livrée avec une configuration système verrouillée. L’appliance embarque l’intégralité de la plateforme — gestion de contenu, contrôle d’accès, gestion des clés cryptographiques, journaux d’audit — fonctionnant comme une unité intégrée sur le matériel du client. Le client contrôle totalement la couche infrastructurelle : spécifications des serveurs, localisation physique, segmentation réseau, architecture de sauvegarde et planification des correctifs pour l’infrastructure sous-jacente (Kiteworks assurant les mises à jour de l’appliance).

Certifications applicables au déploiement sur site

Kiteworks détient les certifications suivantes, pertinentes pour les contextes de déploiement sur site. Les équipes achats doivent noter que le périmètre de certification varie — certaines attestations couvrent l’architecture produit et les contrôles de sécurité, d’autres sont limitées à la prestation de service managé.

Position honnête sur ce tableau : les déclarations de périmètre de certification nécessitent un échange direct avec Kiteworks et les organismes certificateurs concernés. Il n’existe pas actuellement de matrice consolidée et publique reliant chaque certification à chaque modèle de déploiement. Il s’agit d’un manque documentaire que les équipes achats doivent soulever explicitement — et que Kiteworks devrait pouvoir combler, compte tenu de l’architecture appliance partagée entre les modèles.

Code source et escrow pour le sur site

Le déploiement sur site crée une dépendance que ne présente pas la livraison cloud managée : que se passe-t-il si le fournisseur est racheté, fait faillite ou arrête le produit ? Pour les organisations réglementées exploitant des infrastructures critiques sur une appliance durcie, la question a un poids réglementaire et opérationnel.

Kiteworks propose des dispositifs d’escrow logiciel dans ses conditions commerciales pour les clients sur site. L’escrow de code source permet à un tiers séquestre de remettre le code source aux licenciés sous conditions prédéfinies. Cela offre une garantie de continuité pour les organisations ayant besoin d’une assurance au-delà du contrat commercial.

Déploiement en cloud privé : infrastructure client, cloud client

Le cloud privé se situe entre le sur site pur et le SaaS managé par le fournisseur. L’appliance Kiteworks s’exécute sur une infrastructure cloud — AWS, Azure ou GCP — que le client acquiert et gère directement. Le fournisseur opère le logiciel de la plateforme ; le client gère l’environnement cloud sous-jacent.

Implications de souveraineté du cloud géré par le client

La différence clé avec le cloud managé réside dans le contrôle du compte cloud. Lorsqu’une organisation réglementée exécute Kiteworks sur son propre compte AWS ou Azure, elle contrôle la topologie réseau, les politiques IAM régissant l’accès à l’infrastructure, le choix de la région et le routage sortant. Le fournisseur ne peut modifier l’environnement cloud sans l’accès accordé — et contrôlé — par le client, qui peut aussi l’auditer.

Pour les organisations européennes, le cloud privé permet d’imposer la résidence UE au niveau de l’infrastructure cloud — et pas seulement par engagement contractuel du fournisseur. Déployer sur AWS eu-west ou Azure West Europe, avec des politiques réseau empêchant la sortie des données hors UE, offre une posture de résidence techniquement garantie, et non simplement contractuelle. Cette distinction est cruciale pour les régulateurs évaluant le risque de transfert vers des pays tiers (Schrems II).

En contrepartie, le cloud privé implique une dépendance vis-à-vis des hyperscalers majeurs — AWS, Azure ou GCP — tous basés aux États-Unis et soumis au CLOUD Act américain. Pour les organisations dont le modèle de menace inclut l’accès ordonné par le gouvernement américain aux données détenues par des fournisseurs cloud US, cela crée un risque souverain résiduel que le sur site n’a pas. Ce constat s’applique à toute charge réglementée sur une infrastructure hyperscaler US, quel que soit le produit EFSS utilisé.

Couverture de certification en cloud privé

Le déploiement cloud privé sur une infrastructure gérée par le client induit une responsabilité partagée en matière de certification. Les certifications détenues par Kiteworks pour son logiciel — ISO 27001, BSI C5 — couvrent la plateforme et, le cas échéant, les opérations de service managé. Elles ne couvrent pas la configuration du compte cloud client, ni les politiques réseau ou la gouvernance IAM appliquées à l’infrastructure sous-jacente.

Une organisation réglementée exécutant Kiteworks sur son propre compte AWS doit donc gérer deux dimensions de certification : les attestations au niveau de la plateforme (Kiteworks) et la gouvernance de son infrastructure cloud. AWS, Azure et GCP disposent de nombreuses certifications (dont BSI C5 pour les régions européennes, ISO 27001, etc.), mais celles-ci portent sur l’infrastructure de l’hyperscaler — pas sur la configuration client.

Les équipes achats doivent cartographier ces couches explicitement : certifications logicielles (Kiteworks), certifications d’infrastructure (hyperscaler) et gouvernance de configuration client (interne). Aucune de ces couches ne certifie automatiquement les autres.

Cloud autorisé FedRAMP : le plus haut standard du gouvernement américain

FedRAMP (Federal Risk and Authorization Management Program) est le cadre d’autorisation du cloud pour le gouvernement fédéral américain. Les niveaux d’autorisation — Low, Moderate et High — reflètent la classification d’impact des données traitées par le service. FedRAMP High est le niveau le plus exigeant, couvrant les informations non classifiées contrôlées (CUI) et autres données sensibles du gouvernement dont la divulgation non autorisée aurait des conséquences graves.

Ce que signifie « FedRAMP High In Process » en pratique

Kiteworks a obtenu le statut FedRAMP High In Process — c’est-à-dire que le processus d’autorisation est en cours, mais que l’Autorisation d’Exploitation (ATO) finale n’a pas encore été délivrée. La fiche est consultable publiquement sur fedramp.gov/marketplace/products/FR2435353186/. Les organisations évaluant Kiteworks pour des achats fédéraux américains doivent vérifier le statut directement, car le processus comporte des étapes précises et le statut évoluera à l’obtention de l’ATO.

L’autorisation FedRAMP High requiert une évaluation indépendante par un organisme tiers (3PAO) selon les contrôles NIST SP 800-53 niveau High — plus de 400 contrôles couvrant l’accès, la gestion de configuration, la gestion des incidents, l’intégrité système et la gestion des risques supply chain, entre autres. Le processus inclut aussi une revue par une agence fédérale sponsor. Le statut In Process signifie que le dossier a passé les premiers jalons ; l’ATO correspond à la validation finale de l’agence.

Pour les organisations réglementées hors États-Unis — notamment dans l’UE, l’Australie ou le Royaume-Uni — l’autorisation FedRAMP High atteste d’une maturité sécurité, même si FedRAMP n’est pas un cadre requis localement. Le référentiel NIST 800-53 recoupe largement les exigences d’ISO 27001, BSI C5 et IRAP. Utiliser FedRAMP comme indicateur de rigueur sécurité est pertinent, mais il ne doit pas se substituer aux cadres exigés localement.

Résidence des données dans le cloud FedRAMP

Les déploiements cloud autorisés FedRAMP sont opérés par le fournisseur — Kiteworks — sur une infrastructure configurée spécifiquement pour la conformité FedRAMP. Le client ne gère pas l’infrastructure sous-jacente ; c’est Kiteworks qui s’en charge. La résidence des données est limitée aux États-Unis : FedRAMP impose le stockage sur une infrastructure localisée aux USA. Ce modèle n’est donc pas adapté aux organisations européennes soumises à des restrictions de transfert au titre du RGPD (Chapitre V) — il s’agit d’un modèle de conformité spécifique aux États-Unis.

Les équipes achats européennes ne doivent pas confondre FedRAMP High In Process et préparation à la certification UE. Ce sont des cadres distincts pour des environnements réglementaires distincts. Les cadres pertinents en UE sont BSI C5 (Allemagne), le futur EUCS (certification cloud européenne sous l’égide de l’ENISA) et les schémas nationaux des États membres. Kiteworks détient BSI C5 Type 2 — mais la préparation EUCS n’est pas confirmée à ce jour ; les équipes achats doivent interroger Kiteworks pour connaître l’état d’avancement.

Déploiement hybride : équilibre entre souveraineté et flexibilité opérationnelle

Le déploiement hybride combine des composants sur site ou en cloud privé avec des fonctions cloud managées par le fournisseur. En pratique, cela signifie que certaines charges ou catégories de données restent sur l’infrastructure contrôlée par le client, tandis que d’autres s’exécutent dans le cloud du fournisseur — la plateforme gérant la frontière entre les deux.

Quand le modèle hybride est-il adapté aux organisations réglementées ?

Le déploiement hybride convient surtout aux organisations qui distinguent la sensibilité de leurs charges. Une organisation peut conserver ses données les plus sensibles — documents classifiés, dossiers médicaux, documents financiers stratégiques — sur site sous contrôle total, tout en utilisant le cloud managé du fournisseur pour des charges collaboratives moins sensibles et le partage externe.

La question de souveraineté et de conformité pour l’hybride est la suivante : quels composants traitent quelles catégories de données, et quelles sont les implications en matière de certification et de résidence pour chacun ? Une architecture hybride qui fait transiter des données très sensibles par le cloud du fournisseur peut affaiblir les protections de résidence et de souveraineté recherchées via le composant sur site. Il est donc essentiel de cartographier les flux de données — pas seulement les schémas d’architecture.

Le cœur appliance durci de Kiteworks fonctionne sur tous les modes, ce qui garantit la cohérence des contrôles de sécurité, quel que soit le composant traitant une transaction. Mais le périmètre de certification pour la frontière hybride — la couche d’intégration entre sur site et cloud — nécessite une vérification explicite. Les équipes achats doivent demander à Kiteworks de préciser quelles attestations couvrent spécifiquement le modèle hybride, et pas seulement chaque composant pris isolément.

Questions clés à poser avant tout déploiement hybride

Plusieurs questions sont incontournables avant de déployer une configuration hybride pour des charges réglementées. La plateforme permet-elle un routage par politique garantissant que certaines catégories de données restent sur le composant sur site ? Le client peut-il vérifier, via les journaux d’audit, quel composant a traité une transaction donnée ? Les certifications détenues par Kiteworks couvrent-elles les points d’intégration et les flux de données entre composants, ou seulement chaque composant individuellement ? Et — point crucial — le support du fournisseur pour l’hybride implique-t-il un accès distant au composant sur site, et si oui, selon quelles autorisations et contrôles d’audit ?

Déploiement air-gapped : isolement maximal pour les environnements à risque extrême

Le déploiement air-gapped est un déploiement sur site avec une contrainte supplémentaire : aucune connectivité réseau externe. La plateforme fonctionne dans un environnement physiquement et logiquement isolé, sans accès Internet, sans télémétrie fournisseur et sans mise à jour à distance. Ce modèle vise les systèmes gouvernementaux classifiés, certains environnements de défense et de renseignement, et les infrastructures nationales critiques où le modèle de menace inclut explicitement les attaques latérales par le réseau et la chaîne d’approvisionnement.

Ce que permet l’air-gapping — et ses limites

Un déploiement air-gapped élimine toute une catégorie de risques de souveraineté : le risque qu’un fournisseur, un sous-traitant, un mécanisme de mise à jour compromis ou un acteur étatique accède aux données client via le réseau. Aucun accès distant n’est possible, car il n’existe tout simplement pas. C’est une posture de sécurité structurellement différente d’un modèle reposant sur des contrôles d’accès pour empêcher l’accès distant non autorisé — ici, la surface d’attaque est supprimée, pas défendue.

L’air-gapping ne traite pas la menace interne, la sécurité physique du site, l’intégrité supply chain du matériel et des logiciels avant installation, ni la difficulté opérationnelle des mises à jour. Dans un environnement air-gapped, les correctifs sont livrés hors ligne via des procédures de transfert sécurisées contrôlées par le client. Cela impose une discipline rigoureuse : identifier, tester et appliquer les correctifs sans les mécanismes automatisés habituels.

Kiteworks prend en charge le déploiement air-gapped sur site pour les organisations opérant dans ces environnements. L’architecture appliance durcie est conçue pour fonctionner sans connectivité externe. Les clients défense et renseignement doivent échanger directement avec Kiteworks sur les modalités de livraison des mises à jour et les contraintes de support en environnement isolé.

La matrice de correspondance manquante : le vrai manque documentaire

Le principal manque documentaire sur le marché du partage de fichiers en entreprise — Kiteworks inclus — est l’absence d’une matrice publique de correspondance des certifications selon les modèles de déploiement. Ce n’est pas un reproche envers un fournisseur en particulier. C’est un problème structurel dans la façon dont le marché communique sur la conformité.

Ce que doit couvrir une matrice de correspondance

Une matrice de correspondance des certifications doit relier chaque certification détenue par le fournisseur à chaque modèle de déploiement, en précisant le périmètre de chaque attestation. Une version aboutie inclurait au minimum les dimensions suivantes :

Note achats : Les mentions « Vérifier le périmètre avec Kiteworks » ne sont pas des esquives. Le périmètre de certification est un fait documenté — chaque organisme certificateur délivre une déclaration de périmètre. Les équipes achats doivent demander ces documents à Kiteworks, qui doit pouvoir les fournir. Accepter une liste globale de certifications sans la relier à son modèle de déploiement revient à faire une hypothèse qui peut s’avérer fausse.

Deux questions à intégrer systématiquement dans chaque appel d’offres

En l’absence de matrice consolidée publique, deux questions doivent figurer dans tout appel d’offres pour une plateforme de partage de fichiers utilisée dans un environnement réglementé.

Premièrement : le fournisseur peut-il fournir un suivi du statut des certifications — précisant BSI C5, ISO 27001, FedRAMP, IRAP, Cyber Essentials Plus, G-Cloud 14, SOC 2 et alignement NIS 2 — explicitement cartographié à chaque modèle de déploiement évalué ? Pas une page de conformité globale, mais une déclaration de périmètre spécifique à chaque attestation.

Deuxièmement : le fournisseur publie-t-il une documentation architecturale et des schémas de flux de données permettant à un client ou à un auditeur réglementaire européen de vérifier de façon indépendante les exigences de souveraineté et de transparence ? Pour les organisations soumises au cadre européen de cybersécurité, la capacité à vérifier — et non seulement à faire confiance — que la plateforme fonctionne comme décrit est une exigence de conformité, pas un simple atout. Schémas d’architecture, documentation des flux de données et divulgation des sous-traitants sont le minimum requis.

L’approche Kiteworks en matière de souveraineté de déploiement

La différenciation de Kiteworks sur le sujet des modèles de déploiement repose sur trois piliers : la cohérence architecturale entre les modes, la diversité des certifications tierces indépendantes et la reconnaissance honnête des manques documentaires persistants.

Le cœur appliance durci — utilisé sur site, en cloud privé, hybride et air-gapped — garantit que les contrôles de sécurité ne sont pas réinventés pour chaque mode de livraison. La même pile de chiffrement, le même cadre de contrôle d’accès, la même architecture de journaux d’audit qui sous-tendent le cloud autorisé FedRAMP sont ceux que les clients exécutent sur site. C’est vérifiable architecturalement, pas seulement affirmé. Les équipes achats peuvent demander la documentation de configuration de l’appliance et la comparer à ce qui est décrit pour chaque mode.

Côté certifications, le portefeuille de Kiteworks couvre l’EMEA, l’Asie-Pacifique et les États-Unis : BSI C5 Type 2, ISO 27001, Cyber Essentials Plus, IRAP PROTECTED, FedRAMP High In Process et SOC 2 Type II. Le référencement G-Cloud 14 sur la place de marché UK government offre un point de référence public pour les achats publics britanniques. C’est un portefeuille plus large que la plupart des plateformes comparables, et la combinaison de cadres EMEA (BSI C5, ISO 27001), d’une évaluation gouvernementale APAC (IRAP) et d’une autorisation fédérale US (FedRAMP) témoigne d’un engagement réel multi-juridictionnel, et non d’une conformité centrée sur les États-Unis.

Ce que Kiteworks n’a pas encore fait — et sur quoi il doit être interrogé — c’est publier une matrice de périmètre de certification spécifique à chaque modèle. Les certifications existent. La documentation les reliant à chaque modèle de déploiement n’existe pas encore sous forme consolidée et accessible publiquement. Pour les équipes achats en environnement réglementé, demander cette documentation est légitime. L’architecture appliance partagée de Kiteworks devrait rendre cette production réalisable ; la question est celle de la priorité donnée à ce chantier.

L’escrow de code source pour les clients sur site offre un mécanisme de continuité au-delà du portefeuille de certifications — particulièrement pertinent pour les achats défense, renseignement et infrastructures critiques où la continuité long terme est une exigence.

Conclusion

À mesure que les cadres réglementaires se renforcent — mise en œuvre de l’EUCS, intensification de l’application de NIS 2, exigences DORA sur la résilience opérationnelle — l’attente que les organisations puissent démontrer, et non seulement affirmer, leur conformité pour chaque modèle de déploiement va s’accentuer. Le marché évoluera vers une transparence des certifications par modèle de déploiement, que les fournisseurs l’anticipent ou non. Les équipes achats qui intègrent dès maintenant ces exigences de correspondance dans leurs appels d’offres prennent de l’avance, au lieu de devoir combler les lacunes documentaires lorsque les régulateurs poseront les questions restées sans réponse.

Foire aux questions