Comment les fournisseurs SaaS européens peuvent remporter des appels d’offres d’entreprise en prouvant la souveraineté architecturale des données

Lorsque les fournisseurs SaaS européens répondent aux appels d’offres d’entreprises issues du secteur bancaire, de l’assurance ou d’industries réglementées, les questionnaires de sécurité exigent de plus en plus des clés de chiffrement contrôlées par le client, un traitement des données géographiquement isolé et des garanties contractuelles empêchant tout accès par des gouvernements étrangers. Ces exigences traduisent la prise de conscience des acheteurs que les accords contractuels de traitement des données et les clauses contractuelles types ne suffisent pas à protéger les données si les plateformes reposent sur des infrastructures contrôlées par des entités non européennes soumises à des législations extraterritoriales.

Ce changement dans les achats est structurel, non conjoncturel. DORA, NIS2 et les recommandations post-Schrems II de l’EDPB ont fait passer les exigences de souveraineté des données du statut de « préférence » à celui d’« obligation » dans la finance, l’assurance, le secteur public et les infrastructures critiques. Les fournisseurs SaaS ayant bâti leurs plateformes sur des architectures cloud hyperscale standards se retrouvent désormais face à des décisions de qualification binaires—avant toute évaluation commerciale—reposant uniquement sur leur capacité à répondre à des questions techniques précises sur le contrôle des clés de chiffrement et la flexibilité de déploiement.

Dans cet article, nous allons expliquer ce que les équipes achats vérifient réellement, quels cadres réglementaires dictent ces exigences et quelles décisions architecturales permettent à un fournisseur SaaS de rester compétitif sur le marché européen des entreprises.

Résumé Exécutif

Idée principale : Les fournisseurs SaaS européens qui souhaitent décrocher des contrats d’entreprise doivent répondre à des exigences d’achats imposant la souveraineté architecturale des données plutôt que de simples garanties contractuelles—et les fournisseurs incapables de prouver la gestion des clés de chiffrement par le client et des options de déploiement empêchant l’accès en clair aux données par le fournisseur sont automatiquement disqualifiés avant toute évaluation commerciale.

Pourquoi c’est important : L’Autorité bancaire européenne indique que 73 % des établissements de crédit ont mis à jour leurs évaluations des risques fournisseurs en 2024–2025 pour traiter l’exposition au CLOUD Act, et les fournisseurs SaaS proposant des options de déploiement souverain constatent une augmentation de 15 à 30 % de la valeur des contrats, une réduction de 40 à 60 % des cycles de vente et une multiplication par 3 à 5 du pipeline dans les secteurs réglementés, dans les 12 à 18 mois suivant l’ajout de cette capacité.

5 points clés à retenir

1. Les appels d’offres d’entreprise exigent désormais une architecture technique démontrant la souveraineté des données, et non de simples engagements contractuels. Les questionnaires de sécurité des banques, assureurs et organismes publics incluent des exigences obligatoires sur les clés de chiffrement contrôlées par le client et des options de déploiement empêchant l’accès en clair aux données par le fournisseur. Les fournisseurs SaaS qui se contentent de répondre « données chiffrées en transit et au repos » sans précisions sur la gestion des clés sont automatiquement disqualifiés.
2. DORA impose des exigences technologiques contraignantes qui s’appliquent directement aux fournisseurs SaaS desservant les institutions financières. L’article 30 impose aux entités financières de s’assurer que les contrats avec les prestataires TIC abordent la localisation des données, la gestion des clés de chiffrement et les stratégies de sortie. Les fournisseurs reposant sur une infrastructure où le prestataire gère les clés de chiffrement ne peuvent pas réussir les évaluations techniques DORA, quelle que soit la teneur des contrats.
3. NIS2 étend les exigences de souveraineté des données à 18 secteurs au-delà des services financiers. Les États membres doivent désigner des entités dans l’énergie, les transports, la santé, les infrastructures numériques, l’administration publique, l’industrie critique et d’autres secteurs comme soumises à des exigences de cybersécurité et de gestion des risques supply chain, incluant l’évaluation de l’architecture de souveraineté des données des prestataires TIC.
4. L’application post-Schrems II rend les Clauses Contractuelles Types insuffisantes sans mesures techniques complémentaires. Les recommandations de l’EDPB soulignent que les responsables de traitement ne peuvent pas se reposer uniquement sur les CCT lorsque les données sont transférées vers des juridictions où les autorités publiques peuvent accéder aux données au-delà du nécessaire. Les acheteurs exigent que les fournisseurs SaaS prouvent la gestion des clés de chiffrement par le client comme mesure complémentaire principale—les DPA contractuels sans architecture technique de souveraineté ne suffisent pas.
5. La différenciation concurrentielle dépend de plus en plus de la flexibilité de déploiement et de l’architecture de chiffrement. Les fournisseurs SaaS proposant uniquement des déploiements cloud mutualisés perdent des contrats face à ceux qui offrent des options sur site, en cloud privé ou via des appliances virtuelles durcies avec clés gérées par le client. Une architecture souveraine permet d’augmenter les prix, d’accélérer les cycles de vente et d’accéder à des secteurs réglementés inaccessibles à la concurrence.

Pourquoi les achats d’entreprise imposent désormais la souveraineté architecturale des données

Les processus d’achats d’entreprise ont considérablement évolué après Schrems II et les recommandations de l’EDPB. Les questionnaires de sécurité qui acceptaient auparavant les attestations de conformité RGPD exigent désormais une documentation technique détaillée démontrant comment l’architecture empêche tout accès non autorisé aux données—et les questions sont suffisamment précises pour que les déclarations génériques de conformité ne suffisent plus.

Les recommandations 2024 de l’EBA ont transformé l’exposition au CLOUD Act en exigences explicites dans les appels d’offres appliquées par 73 % des établissements de crédit

Les équipes achats du secteur financier ont reçu des recommandations explicites de l’Autorité bancaire européenne soulignant que les fournisseurs cloud américains créent une exposition au CLOUD Act, même avec des contrats de data centers européens. Les recommandations 2024 de l’EBA en matière de gestion des risques fournisseurs indiquent que 73 % des établissements de crédit ont mis à jour leurs évaluations pour traiter ce risque—ce qui se traduit directement par des exigences dans les appels d’offres auxquelles les fournisseurs SaaS doivent répondre. Les compagnies d’assurance soumises à Solvabilité II font face à des contraintes similaires, les autorités de supervision nationales de plusieurs États membres exigeant que les assureurs s’assurent que leurs prestataires TIC mettent en place des mesures techniques empêchant tout accès non autorisé aux données des assurés.

Les achats publics introduisent des enjeux de sécurité nationale que les architectures cloud mutualisées ne peuvent satisfaire

Les achats publics ajoutent une complexité supplémentaire liée à la sécurité nationale. Plusieurs États membres de l’UE interdisent à leurs agences gouvernementales de recourir à des services cloud où des entités non européennes conservent un accès technique aux données. Les fournisseurs SaaS ciblant le secteur public doivent démontrer que les clés de chiffrement et l’accès administratif restent sous le contrôle du client ou d’une entité européenne—ce qui exclut de fait les plateformes cloud hyperscale, quel que soit l’emplacement physique de leurs data centers.

Les questionnaires de sécurité des appels d’offres incluent désormais des critères binaires de qualification qui disqualifient les fournisseurs avant toute évaluation commerciale

Les questionnaires de sécurité des appels d’offres posent des questions telles que : « Votre plateforme prend-elle en charge des clés de chiffrement gérées par le client dans des HSM sous contrôle exclusif du client ? », « Votre solution peut-elle être déployée sur site ou dans une infrastructure cloud privée ? », « Du personnel situé hors de l’Union européenne a-t-il un accès technique aux données clients ? » Ces questions créent des critères de qualification binaires. Les fournisseurs qui répondent « non » sont automatiquement disqualifiés avant toute évaluation commerciale—prix, fonctionnalités, références et autres facteurs compétitifs deviennent alors sans objet. Les choix architecturaux faits lors du développement du produit déterminent directement la taille du marché adressable dans les segments entreprises européens.

Exigences RGPD et post-Schrems II pour l’architecture technique SaaS

L’article 32 du RGPD impose aux sous-traitants de mettre en œuvre des « mesures techniques et organisationnelles appropriées », incluant la pseudonymisation, le chiffrement et des mesures garantissant la confidentialité, l’intégrité, la disponibilité et la résilience. Pour les fournisseurs SaaS, ces exigences constituent un socle de sécurité que les équipes achats vérifient lors d’évaluations techniques—mais le niveau d’exigence a considérablement augmenté depuis Schrems II.

Le chiffrement géré par le fournisseur satisfait la lettre de l’article 32 du RGPD mais ne répond pas à l’exigence de contrôle des clés par le responsable de traitement selon l’EDPB

Les recommandations du groupe de travail Article 29 soulignent que le chiffrement n’offre une protection adéquate que si le responsable de traitement conserve un contrôle exclusif sur les clés de déchiffrement. De nombreuses plateformes SaaS mettent en œuvre le chiffrement au repos et en transit tout en conservant la gestion des clés côté fournisseur. Ces architectures répondent superficiellement à l’exigence de chiffrement, mais ne satisfont pas le critère de contrôle des clés par le responsable de traitement selon l’EDPB—et les équipes achats d’entreprise savent désormais poser la question suivante : qui détient les clés de déchiffrement, et pouvez-vous être contraint de les utiliser ?

Les mesures complémentaires de l’EDPB créent une hiérarchie technique à trois niveaux dont seuls les HSM contrôlés par le client satisfont le niveau le plus strict

Schrems II a établi que les Clauses Contractuelles Types seules ne suffisent pas à protéger les données transférées vers des juridictions où la surveillance gouvernementale ne bénéficie pas de garanties équivalentes à l’Europe. Les recommandations de l’EDPB sur les mesures complémentaires distinguent le chiffrement géré par le fournisseur (protection limitée) du chiffrement avec clés sous contrôle exclusif du client (protection effective). Pour les fournisseurs SaaS, cela crée une hiérarchie technique : mettre en œuvre le chiffrement au repos et en transit ; démontrer que la gestion des clés est séparée des données applicatives ; prouver que les clés restent sous contrôle exclusif du client via des modules matériels de sécurité (HSM). Les achats d’entreprise exigent désormais ce troisième niveau—et les fournisseurs qui ne peuvent démontrer que les deux premiers échouent à la qualification.

Exigences technologiques DORA et NIS2 pour les fournisseurs SaaS

DORA établit des exigences technologiques contraignantes pour les entités financières qui s’étendent directement aux prestataires TIC. L’article 28(5) impose aux entités financières d’évaluer tous les prestataires TIC tiers. L’article 30 exige des contrats garantissant la mise en œuvre de mesures de sécurité, incluant la protection des données, le chiffrement et la continuité d’activité.

L’article 30 de DORA impose des obligations de vérification que les architectures cloud mutualisées ne peuvent satisfaire

L’article 30(2)(j) impose de traiter la « localisation du traitement des données », tandis que l’article 30(2)(k) exige des dispositions sur « l’accès, la récupération, la restitution et la suppression des données ». Ces obligations de vérification dépassent ce qu’un accord de traitement des données peut couvrir. L’article 28(3) impose des « stratégies de sortie » permettant la « suppression complète des données »—les plateformes où les données clients restent chiffrées avec des clés gérées par le fournisseur ne peuvent pas satisfaire cette exigence car la suppression complète nécessite la coopération du fournisseur. Les normes techniques de l’Autorité bancaire européenne insistent sur la nécessité pour les institutions financières de vérifier que les fournisseurs cloud mettent en œuvre une « séparation logique forte » garantissant l’isolement des données clients, et que la gestion des clés de chiffrement permet au client de contrôler le cycle de vie des clés.

NIS2 étend les exigences de souveraineté des données à 18 secteurs au-delà des services financiers

NIS2 impose des exigences similaires au-delà des services financiers. La directive s’applique aux entités essentielles et importantes de 18 secteurs—énergie, transports, santé, infrastructures numériques, administration publique, industrie critique, etc.—et impose des évaluations de cybersécurité supply chain et de résilience des prestataires TIC. L’application varie selon les pays, mais plusieurs juridictions ont adopté des exigences explicites de souveraineté des données qui s’appliquent aux fournisseurs SaaS desservant ces entités. Concrètement, cela se traduit dans les grilles d’évaluation où les fournisseurs proposant uniquement du cloud mutualisé avec chiffrement géré par le fournisseur obtiennent de faibles scores, tandis que ceux offrant du déploiement sur site avec clés gérées par le client obtiennent des scores élevés leur permettant d’avancer dans la qualification technique.

Exigences architecturales vérifiées par les acheteurs d’entreprise

Les équipes achats d’entreprise qui mènent des due diligences techniques se concentrent sur des capacités architecturales précises qui déterminent si les fournisseurs satisfont aux exigences de souveraineté des données. Comprendre ce qu’elles vérifient—et dans quel ordre—est aussi important que d’avoir la bonne architecture.

La gestion des clés de chiffrement est le point de contrôle principal et seuls les HSM contrôlés par le client satisfont le niveau le plus strict

La gestion des clés de chiffrement est le point de contrôle principal. Les acheteurs distinguent les clés gérées par le fournisseur, celles gérées par le client dans des services HSM cloud, et celles gérées dans des HSM sous contrôle exclusif du client. Seul ce dernier niveau répond aux exigences strictes de souveraineté en éliminant toute possibilité technique d’accès en clair aux données par le fournisseur ou l’opérateur cloud hyperscale. La flexibilité de déploiement constitue le second critère critique—les acheteurs évaluent si les fournisseurs proposent une installation sur site, un déploiement en cloud privé ou des appliances virtuelles durcies offrant les avantages de la souveraineté avec une complexité opérationnelle réduite. Les architectures cloud mutualisées sont automatiquement disqualifiées dans de nombreux appels d’offres d’entreprise, quelles que soient les autres fonctions proposées.

Les contrôles d’accès administratifs constituent le troisième point de vérification—un accès permanent crée un risque que la politique seule ne peut éliminer

Les contrôles d’accès administratifs constituent le troisième point de vérification. Les équipes achats examinent quels membres du personnel fournisseur peuvent accéder aux environnements clients, depuis quels emplacements, et si les opérations administratives nécessitent l’approbation du client. Les architectures où les équipes support du fournisseur disposent d’un accès permanent échouent aux évaluations de souveraineté, car la capacité technique crée un risque indépendamment des politiques internes—un fournisseur peut être contraint ou compromis, même si ses politiques l’interdisent. Les contrôles de résidence des données, la journalisation d’audit et l’intégration IAM sont d’autres points d’évaluation. La vérification implique généralement des sessions de revue architecturale où les fournisseurs présentent des schémas détaillés ; ceux qui ne peuvent démontrer une architecture robuste obtiennent des scores insuffisants pour accéder aux négociations commerciales.

Dynamique concurrentielle lorsque la souveraineté devient une exigence d’appel d’offres

La souveraineté architecturale des données comme exigence obligatoire dans les appels d’offres crée une segmentation du marché où les fournisseurs SaaS dotés de capacités souveraines accèdent à des opportunités inaccessibles à ceux qui utilisent des architectures cloud standard. Les avantages concurrentiels sont mesurables et s’amplifient avec le temps.

L’architecture souveraine permet d’augmenter la valeur des contrats de 15 à 30 % et de réduire les cycles de vente de 40 à 60 % dans les contrats d’entreprise

La dynamique de tarification évolue fortement lorsque les fournisseurs démontrent une architecture souveraine. Les acheteurs reconnaissent que la gestion des clés par le client et la flexibilité de déploiement constituent une véritable différenciation technique nécessitant des investissements d’ingénierie. Les fournisseurs SaaS constatent une augmentation de 15 à 30 % de la valeur des contrats d’entreprise où la souveraineté des données était requise, par rapport à des contrats comparables sans cette exigence. La réduction du cycle de vente s’explique par le fait que la souveraineté architecturale lève la principale objection qui bloquait l’avancement des achats—les fournisseurs rapportent des cycles de vente passant de 9–12 à 4–6 mois lorsqu’ils démontrent la souveraineté dès les premiers échanges, car les étapes de revue sécurité qui prenaient des mois sont réduites à la vérification architecturale.

Le remplacement des fournisseurs dépendants du cloud hyperscale s’accélère sous la pression réglementaire

Le remplacement concurrentiel s’accélère dans les bases installées. Les entreprises européennes utilisant des plateformes SaaS reposant sur des infrastructures hyperscale subissent une pression croissante des régulateurs et des équipes conformité internes pour migrer vers des alternatives souveraines. Plusieurs fournisseurs SaaS européens indiquent que 40 à 60 % de leurs nouveaux contrats d’entreprise proviennent du remplacement de concurrents, motivé par les exigences de souveraineté—des clients satisfaits de leur fournisseur sur tous les aspects sauf celui qui détermine désormais la conformité réglementaire. L’élargissement de l’accès au marché est l’impact le plus significatif à long terme : les fournisseurs SaaS incapables de démontrer une architecture souveraine sont systématiquement exclus des opportunités dans la finance, l’assurance, le secteur public et les infrastructures critiques, tandis que ceux qui ajoutent des capacités souveraines constatent une multiplication par 3 à 5 de leur pipeline qualifié dans ces secteurs en 12 à 18 mois.

Points clés pour la mise en œuvre

Les fournisseurs SaaS qui ajoutent des capacités de souveraineté architecturale des données doivent prendre des décisions techniques, opérationnelles et commerciales qui influent sur leur time-to-market et l’expérience client à long terme.

L’architecture de gestion des clés de chiffrement est le choix le plus critique et détermine le niveau d’exigence entreprise que le fournisseur peut satisfaire

Le choix de l’architecture de gestion des clés de chiffrement est le plus critique. Les fournisseurs doivent décider s’ils prennent en charge les HSM sur site, les services HSM cloud de fournisseurs européens ou les appliances virtuelles durcies. La plupart proposent plusieurs options pour permettre au client de choisir selon ses exigences de sécurité et ses capacités opérationnelles—en adaptant l’architecture à l’environnement réglementaire de chaque client, plutôt qu’en imposant une approche unique qui satisferait certains acheteurs mais en disqualifierait d’autres. Le modèle de déploiement constitue la seconde grande décision : packages d’installation sur site, automatisation du déploiement cloud privé ou implémentations containerisées. Les implémentations réussies prennent généralement en charge plusieurs modèles de déploiement avec une base de code partagée pour limiter la maintenance.

Éliminer l’accès administratif permanent exige une refonte des processus mais est indispensable pour revendiquer une architecture souveraine

L’architecture d’accès administratif doit être repensée pour éliminer tout accès permanent du fournisseur aux environnements clients, en mettant en place des procédures d’accès d’urgence (« break-glass ») avec traçabilité complète. Les contrôles de résidence des données imposent de garantir que le stockage, le traitement, la sauvegarde et la supervision respectent les frontières géographiques définies par le client. Les exigences de documentation et de certification augmentent considérablement avec l’architecture souveraine—les fournisseurs doivent produire une documentation technique détaillée pour les revues de sécurité, des schémas architecturaux pour les évaluations achats, et parfois des certifications tierces validant leurs engagements de souveraineté. L’investissement documentaire est aussi important que l’investissement technique, car les équipes achats ne peuvent avancer avec des fournisseurs dépourvus de preuves techniques claires, quelle que soit la réalité de l’architecture. Les considérations commerciales incluent l’ajustement du modèle de tarification—les options de déploiement souverain sont généralement facturées 20 à 40 % plus cher, reflétant la différenciation technique et la complexité opérationnelle.

La transition depuis une architecture dépendante du cloud hyperscale doit suivre une feuille de route incrémentale de 18 à 24 mois plutôt qu’une refonte complète

Les fournisseurs reposant sur une infrastructure cloud hyperscale peuvent évoluer vers une architecture souveraine sans refondre entièrement leur plateforme. Commencez par la gestion des clés par le client via le « bring-your-own-key », tout en reconnaissant la souveraineté limitée. Développez ensuite des packages de déploiement containerisés permettant l’installation cloud privé sur une infrastructure contrôlée par le client. Troisième étape : nouer des partenariats avec des fournisseurs européens de cloud souverain. Enfin, concevez les nouveaux modules produits avec la flexibilité de déploiement dès l’origine. Les transitions réussies s’étalent sur 18 à 24 mois par itérations successives—l’essentiel étant d’adopter la souveraineté architecturale comme stratégie produit, et non comme option, car la segmentation de marché qui en découle s’amplifie dans le temps.

Comment Kiteworks permet aux fournisseurs SaaS européens de satisfaire aux exigences de souveraineté des données des entreprises

Les fournisseurs SaaS européens évoluent sur un marché où la souveraineté architecturale des données est passée d’un facteur de différenciation à un prérequis dans les segments entreprises réglementés. Les fournisseurs qui remportent ces opportunités ne sont pas forcément les plus grands ni ceux qui offrent le plus de fonctionnalités—ce sont ceux dont l’architecture permet de répondre aux questions techniques qui déterminent la qualification. Une architecture souveraine permet d’augmenter les prix, d’accélérer les cycles de vente, de remplacer les acteurs dépendants du cloud hyperscale et d’élargir le marché adressable à des secteurs autrefois inaccessibles. Pour les fournisseurs SaaS ayant bâti leurs plateformes sur une infrastructure cloud standard, la question n’est pas de savoir s’il faut ajouter des capacités souveraines, mais à quelle vitesse le faire avant que la fenêtre concurrentielle ne se referme.

Kiteworks offre aux fournisseurs SaaS européens les capacités de souveraineté architecturale des données nécessaires pour remporter les appels d’offres entreprises dans la finance, l’assurance, le secteur public et les industries réglementées. La plateforme utilise des clés de chiffrement contrôlées par le client qui ne quittent jamais son infrastructure, ce qui signifie que même en cas d’injonction gouvernementale ou d’incident de sécurité, Kiteworks ne dispose d’aucun moyen technique d’accéder aux données clients.

La plateforme propose un déploiement flexible, incluant l’installation sur site dans les data centers clients, le déploiement cloud privé dans des infrastructures européennes sous contrôle client, et des appliances virtuelles durcies offrant les avantages de la souveraineté avec une complexité opérationnelle réduite. Les fournisseurs SaaS peuvent ainsi proposer à leurs clients le mode de déploiement adapté à leurs exigences de sécurité et à leurs capacités opérationnelles, satisfaisant ainsi les exigences d’appels d’offres pour une architecture souveraine sur différents segments clients.

Kiteworks intègre la messagerie électronique, le partage et le transfert de fichiers, ainsi que les formulaires web dans une architecture unifiée permettant aux fournisseurs SaaS de gérer les communications de données sensibles via une seule plateforme souveraine. Cette intégration simplifie la mise en œuvre des clés gérées par le client, réduit la complexité de la relation fournisseur et offre une journalisation d’audit unifiée répondant aux exigences DORA et NIS2.

Pour les fournisseurs SaaS desservant des institutions financières soumises à DORA, l’architecture de la plateforme satisfait aux exigences de l’article 30 sur le chiffrement, le contrôle de la localisation des données et les stratégies de sortie. Les clés de chiffrement gérées par le client répondent aux exigences de l’article 30(2)(k) sur l’accès et la suppression des données, tandis que la flexibilité de déploiement satisfait aux exigences de l’article 30(2)(j) sur le traitement géographique. Les capacités de sortie de la plateforme permettent aux clients de migrer sans la coopération de Kiteworks, évitant ainsi l’enfermement fournisseur tout en respectant les exigences DORA sur les stratégies de sortie.

Pour en savoir plus sur la façon dont Kiteworks aide les fournisseurs SaaS européens à remporter des appels d’offres entreprises grâce à la souveraineté architecturale des données, réservez votre démo personnalisée dès aujourd’hui.

Ressources complémentaires

Article de blog

• eBook 
  Souveraineté des données et RGPD
• Article de blog 
  Évitez ces pièges de la souveraineté des données
• Article de blog 
  Meilleures pratiques pour la souveraineté des données
• Article de blog 
  Souveraineté des données et RGPD [Comprendre la sécurité des données]