Injonctions & mandats : ce qu'il advient de vos données de formulaires

Toute entreprise qui exploite des formulaires en ligne avec du contenu sensible finira un jour par rencontrer une variante de cette question : que se passe-t-il si un tribunal, un procureur, une autorité fiscale ou un gouvernement étranger demande à notre fournisseur de formulaires de livrer les soumissions d'un utilisateur ? La plupart des entreprises n'y pensent pas jusqu'au jour où cela arrive. À ce moment-là, le choix architectural qui détermine la réponse — ce que le fournisseur a effectivement et sous quelle forme — a déjà été fait des années plus tôt, souvent sans que personne du côté métier ne se soit aperçu que c'était un choix.

Cet article passe en revue à quoi ressemble réellement une procédure légale contre un fournisseur de formulaires, ce qui peut ou non être extrait par contrainte, comment les ordres transfrontaliers compliquent le tableau et comment une architecture à connaissance nulle change fondamentalement la réponse. Ce n'est pas un conseil juridique — voir l'avertissement en bas — mais c'est assez de carte pour qu'un DPO, une direction juridique ou un opérateur soucieux de confidentialité comprenne le terrain.

Ce que signifie « procédure légale »

« Subpoena » est un terme propre aux États-Unis ; ailleurs le vocabulaire diffère. En Suisse, un procureur peut émettre une ordonnance de production (Editionsverfügung) ; un tribunal, un mandat de perquisition et de saisie ; une autorité fiscale, une ordonnance d'information ; un tribunal civil peut contraindre à la production via des ordres procéduraux. Dans les États membres de l'UE, des instruments analogues existent dans les codes de procédure pénale, civile et les lois sectorielles (LBA, fiscal, télécoms). Au niveau UE, les décisions d'enquête européennes (DEE) et le nouveau règlement e-Evidence créent des mécanismes transfrontaliers. Et les États-Unis étendent leur propre procédure à l'étranger via le Stored Communications Act et le CLOUD Act.

La forme commune de ces instruments est suffisamment cohérente pour qu'un seul modèle mental en couvre la plupart :

• Une autorité publique — tribunal, procureur, régulateur, parfois un plaideur civil — émet une demande formelle au fournisseur de formulaires portant sur des données précises concernant un utilisateur, un compte, un formulaire ou un ensemble de soumissions
• La demande est adossée à un certain degré de procédure judiciaire ou quasi-judiciaire ; le fournisseur n'a pas une liberté illimitée de refuser, mais a généralement des motifs pour contester
• La demande comprend typiquement une clause de non-divulgation empêchant le fournisseur d'en informer l'utilisateur pour une période définie
• Le fournisseur produit ce qu'il a, tel qu'il l'a. Un fournisseur sérieux pousse contre les demandes trop larges, demande des limitations et épuise ses mécanismes de contestation. Un moins sérieux se plie avec moins d'examen
• Ce qui sort par la porte est exactement ce que contenaient les systèmes du fournisseur — ni plus, ni moins

Ce dernier point est la phrase la plus importante de cet article. Tout le reste en découle.

Ce que le fournisseur peut réellement produire

Le fournisseur ne peut produire que ce qui se trouve dans ses systèmes. Pour un outil SaaS typique, c'est souvent beaucoup : contenu de chaque soumission, métadonnées sur qui a soumis quoi et quand, adresses IP ayant accédé au formulaire, tickets de support liés au compte, journaux d'audit administratif et, parfois, les clés et la configuration d'un éventuel chiffrement au repos appliqué par le fournisseur. Rien de cela n'exige de casser un système cryptographique — tout est dans une base que le personnel peut interroger.

Un fournisseur à connaissance nulle se trouve structurellement ailleurs. Si le fournisseur ne reçoit jamais de texte en clair — parce que chaque réponse et chaque pièce jointe ont été chiffrées dans le navigateur contre une clé publique dont la privée n'est jamais chez lui — la base ne contient que du chiffré. Une ordonnance peut être signifiée et respectée ; ce qui sort est du chiffré sans moyen de déchiffrement. La contrainte est satisfaite formellement ; l'effet opérationnel sur la confidentialité est drastiquement réduit.

Procédures suisse, UE et transfrontalières

Procédure suisse contre un fournisseur suisse

Lorsqu'un procureur ou tribunal suisse signifie une ordonnance à un fournisseur basé en Suisse, la procédure reste en droit suisse. Les bases proviennent du CPP suisse, du droit fiscal et administratif et de la procédure civile. Les droits de protection des données sous la nLPD continuent de s'appliquer ; la personne concernée peut, dans certains cas, être informée après un délai statutaire, sous réserve des règles propres à l'autorité. Le droit suisse reconnaît des catégories de privilège (juridique, médical, religieux) qui limitent ce qui peut être saisi. Un fournisseur suisse de bonne foi examine les demandes pour sur-étendue et invoque les privilèges applicables.

Procédure UE contre un fournisseur UE

Dans l'UE, les procédures pénales, fiscales et civiles des États membres encadrent la production contrainte. Pour les enquêtes pénales transfrontalières, les décisions d'enquête européennes (DEE) permettent aux autorités d'un État membre de demander des preuves dans un autre. Le futur règlement e-Evidence de l'UE ((UE) 2023/1543) rationalise davantage les demandes transfrontalières de preuves électroniques, y compris des ordonnances de production et de conservation directement adressées aux prestataires d'autres États membres.

Extension US à l'étranger : CLOUD Act

Le CLOUD Act américain (2018) étend explicitement la procédure américaine aux données détenues par des prestataires basés aux États-Unis, où qu'elles soient stockées — y compris UE et Suisse. Un procureur US peut signifier un mandat à un fournisseur de formulaires incorporé aux États-Unis et contraindre la production des données d'un utilisateur suisse, même si les données résident dans un datacenter suisse. Le CLOUD Act a aussi créé un cadre d'accords exécutifs permettant à certaines autorités étrangères de signifier directement des demandes à des prestataires US ; le Royaume-Uni et l'Australie ont de tels accords en vigueur.

Implication pratique pour une entreprise suisse : si votre fournisseur est incorporé aux États-Unis ou est une filiale majoritairement US, les données sont dans le rayon du CLOUD Act, peu importe leur localisation physique et la nationalité de l'utilisateur. Le droit de protection des données UE/CH ne renverse pas la compétence US sur un prestataire US ; il affecte seulement ce que le prestataire est en droit de faire sous le droit UE/CH, et s'il doit enfreindre une loi pour respecter l'autre.

Suisse ↔ juridictions étrangères : entraide judiciaire

Une autorité étrangère souhaitant obtenir des données détenues par un fournisseur suisse sans passer par le CLOUD Act (parce que le fournisseur n'est pas US) a essentiellement une voie : une demande d'entraide judiciaire (EIMP / IRSG) ou une convention d'échange de renseignements fiscaux. Les autorités suisses évaluent la demande, notifient dans beaucoup de cas la personne concernée et n'imposent qu'ensuite la production. Ce processus est plus lent, plus scruté et plus protecteur de la personne concernée qu'un mandat domestique direct.

Ce qui arrive à la personne concernée

Quand une ordonnance vise les soumissions d'un utilisateur, celui-ci ignore typiquement tout au moment de la signification. La plupart des instruments incluent une obligation de non-divulgation empêchant le fournisseur d'informer l'utilisateur pour une période définie, souvent prorogeable par ordonnance supplémentaire. Cela préserve l'intégrité des enquêtes — et c'est aussi la raison pour laquelle « je fais confiance à mon fournisseur pour me prévenir » n'est généralement pas une posture défendable — des fournisseurs bien intentionnés peuvent avoir interdiction légale de prévenir.

Après la fin de la fenêtre de non-divulgation, les fournisseurs dotés de fortes pratiques de confidentialité notifient les personnes concernées. Certains publient des rapports de transparence annuels. Le droit suisse et beaucoup de droits UE exigent dans la plupart des cas une forme éventuelle de notification à la personne concernée, une fois les impératifs de secret levés. Rien de tout cela ne protège rétroactivement les données produites en clair pendant la fenêtre.

Ce que la connaissance nulle change pour l'utilisateur

Dans une architecture à connaissance nulle, le contenu des soumissions est protégé de la production indépendamment des pratiques de notification du fournisseur. Même fenêtre de non-divulgation ouverte, même si la personne n'est jamais avertie, même si le fournisseur coopère pleinement et rapidement : ce que l'autorité reçoit est du chiffré. Pour un utilisateur qui tient à la confidentialité — lanceur d'alerte, patient, client d'un cabinet, réfugié politique — c'est la garantie qui compte, car elle ne dépend ni du personnel, ni des procédures, ni des ressources juridiques du fournisseur.

Ce qu'une architecture à connaissance nulle ne peut pas faire

L'honnêteté sur les limites est essentielle, sinon l'argument glisse dans le marketing. La connaissance nulle a des propriétés précises, et des trous précis.

• Elle ne cache pas les métadonnées. ID de formulaire, horodatages, tailles de payload, adresses IP enregistrées par l'hébergeur peuvent tous faire l'objet d'une procédure
• Elle ne couvre pas les données de compte — e-mails du propriétaire, facturation, abonnements — sauf si le fournisseur applique des contrôles équivalents à ces systèmes
• Elle n'empêche pas les demandes prospectives. Un tribunal peut contraindre un fournisseur à modifier un formulaire pour l'avenir, à journaliser des champs supplémentaires, ou à livrer silencieusement un nouveau payload au navigateur d'un utilisateur ciblé. Les juridictions varient quant à la licéité, mais le chiffrement des données passées ne bloque pas cela
• Elle ne protège pas contre la compromission du détenteur de la clé — si le code d'accès du propriétaire du formulaire est lui-même compromis, cité à comparaître ou obtenu sous contrainte, le chiffré peut être déchiffré
• Elle ne remplace pas l'opsec pour des utilisateurs à haut risque. Un lanceur d'alerte soumettant depuis un appareil professionnel sur un réseau d'entreprise reste identifiable via cet appareil et ce réseau, quelle que soit la force du chiffrement du formulaire

La formulation honnête : l'architecture à connaissance nulle garantit que le fournisseur ne peut pas être contraint de produire un contenu de soumission lisible, parce qu'il ne l'a pas. C'est une protection significative et spécifique. Ce n'est pas un bouclier universel contre la puissance publique.

Liste : évaluer la posture « procédure légale » de votre fournisseur

Où Schweizerform se place dans ce tableau

Schweizerform est incorporé en Suisse, héberge les charges utiles de soumission sur une infrastructure suisse et applique un chiffrement de bout en bout à connaissance nulle à chaque soumission. Concrètement :

• Le contenu des soumissions et les fichiers téléversés sont chiffrés dans le navigateur de l'émetteur avant de quitter l'appareil, avec des clés que seul le propriétaire du formulaire contrôle — nous ne pouvons pas les lire
• Une demande légale qui nous est signifiée sur du contenu de soumission ne peut être satisfaite qu'avec du chiffré ; nous ne détenons pas le code d'accès et ne pouvons pas le produire
• La juridiction corporative suisse nous tient hors de portée du CLOUD Act ; les autorités étrangères doivent passer par l'entraide et un examen suisse
• Nous publions des déclarations claires sur ce que nous pouvons et ne pouvons pas produire sous procédure, et nous contestons les ordonnances trop larges là où le droit suisse le permet
• La conservation des métadonnées est minimisée par défaut ; ce que nous conservons est documenté dans notre politique de traitement

Cela ne fait pas de nous — ni d'aucun fournisseur — une garantie contre toutes les formes de puissance publique. Cela signifie, sur l'axe précis « qu'est-ce qui sort par la porte quand une ordonnance arrive », que notre capacité à livrer le contenu de vos utilisateurs est limitée par la cryptographie, pas par notre bonne volonté.

En résumé

La procédure légale contre les fournisseurs de formulaires est banale, silencieuse et presque jamais visible pour les utilisateurs dont les données sont en cause. Que cette procédure se termine par des soumissions en clair franchissant le seuil d'un bureau ou par du chiffré inutile est déterminé non par le langage de la politique de confidentialité du fournisseur, mais par son architecture — et par la juridiction qui a le chemin le plus court pour contraindre cette architecture.

Si le contenu que soumettent vos utilisateurs est assez sensible pour que vous ne soyez pas à l'aise qu'il figure dans un dossier, la question d'évaluation n'est pas de savoir si votre fournisseur « tient à la vie privée ». Elle est de savoir s'il peut physiquement lire la soumission et s'il se trouve dans une juridiction où cette lisibilité est à une ordonnance nationale d'être remise à un tiers. Tout le reste en découle.