Analyse de conformité réglementaire

Règlement Général sur la Protection des Données (RGPD)

Analyse d'applicabilité

Le RGPD (UE 2016/679) constitue le cadre juridique le plus strict au monde en matière de protection des données personnelles. Son application est conditionnée par l'existence d'un "responsable du traitement" (celui qui détermine les finalités et les moyens du traitement) et d'un "sous-traitant" (celui qui traite les données pour le compte du responsable).

Dans l'architecture d'iCanText, ces notions sont fondamentalement remises en question :

• Absence de Responsable de Traitement Central : L'éditeur du logiciel iCanText ne collecte, ne stocke et n'a accès à aucune donnée de communication des utilisateurs. Il ne peut donc être qualifié de responsable du traitement pour ces données. Le service se limite à fournir un outil.
• L'Utilisateur comme Propre Responsable : Chaque utilisateur, en contrôlant ses clés et en initiant des communications, agit comme son propre responsable de traitement pour les données qu'il émet. Les "données personnelles" (le contenu des messages) ne transitent jamais par une entité identifiable qui pourrait être tenue pour responsable.

Conformité aux principes fondamentaux du RGPD

Même en considérant que le RGPD puisse s'appliquer indirectement, l'architecture d'iCanText est conçue pour respecter ses principes fondamentaux par défaut :

• Article 5 - Principes relatifs au traitement :
  • Licéité, loyauté, transparence : Le fonctionnement est transparent, sans collecte cachée.
  • Limitation des finalités : La seule finalité est la communication initiée par l'utilisateur.
  • Minimisation des données : C'est un pilier de la conception. Aucune donnée non essentielle n'est collectée.
  • Exactitude : Non applicable, car aucune donnée n'est stockée centralement.
  • Limitation de la conservation : La conservation est gérée par les utilisateurs sur leur propre appareil, ou n'existe pas en mode éphémère.
  • Intégrité et confidentialité : Assurées par le chiffrement de bout-en-bout et les signatures numériques.
• Article 25 - Protection des données dès la conception (Privacy by Design) : iCanText est un exemple paradigmatique de ce principe. Les mesures de protection ne sont pas ajoutées à un système existant, elles SONT le système.
• Article 32 - Sécurité du traitement : Les mesures techniques (chiffrement fort, pseudonymisation via les clés, résilience du réseau) sont à l'état de l'art.
• Droits de la personne concernée (Articles 15-22) :
  • Droit d'accès et de rectification : L'utilisateur a un accès total et est le seul à pouvoir "rectifier" ses données (ce qui n'a pas de sens ici, mais le contrôle est total).
  • Droit à l'effacement ("droit à l'oubli") : L'utilisateur peut supprimer son identité de son appareil à tout moment, la rendant définitivement inutilisable. Il n'y a pas de copie sur un serveur à faire effacer.

Directive ePrivacy et recommandations de la CNIL

Directive ePrivacy (2002/58/CE)

Souvent appelée "loi cookie", cette directive régit la confidentialité des communications électroniques et le suivi des utilisateurs.

• Confidentialité des communications : L'article 5 de la directive impose aux États membres de garantir la confidentialité des communications. Toute interception, écoute ou stockage est interdit sans le consentement des utilisateurs concernés. L'architecture P2P chiffrée de bout-en-bout d'iCanText non seulement respecte, mais incarne ce principe.
• Cookies et traceurs : L'article 5(3) requiert le consentement de l'utilisateur avant de stocker ou d'accéder à des informations sur son terminal. iCanText n'utilise aucun cookie ou technologie de traçage. Cette obligation est donc respectée par absence d'action.

Recommandations de la CNIL

La Commission Nationale de l'Informatique et des Libertés (CNIL) promeut activement le principe de minimisation des données et la sécurité des communications. L'architecture d'iCanText s'aligne directement sur ses recommandations clés :

• Chiffrement Fort : La CNIL recommande l'usage du chiffrement pour protéger les données personnelles. iCanText l'implémente systématiquement pour tout le trafic.
• Minimisation et Pseudonymisation : La CNIL insiste sur la nécessité de ne collecter que les données strictement nécessaires. L'anonymat de l'identité (remplacée par une clé cryptographique) est une forme de pseudonymisation très forte.
• Sécurité des applications mobiles/web : Les recommandations de la CNIL pour le développement sécurisé (gestion des secrets, authentification forte) sont respectées au niveau de la gestion de l'identité locale chiffrée.

Législations internationales

CLOUD Act (États-Unis)

Le Clarifying Lawful Overseas Use of Data Act (CLOUD Act) est une loi fédérale américaine qui permet aux autorités d'obliger les fournisseurs de services technologiques américains à fournir les données demandées, quel que soit le lieu de stockage de ces données. Cette loi représente une menace significative pour la confidentialité des utilisateurs de services basés aux États-Unis.

L'architecture d'iCanText la rend structurellement immunisée contre les requêtes du CLOUD Act. La raison est simple et fondamentale :

• Il n'existe aucun serveur central appartenant à l'éditeur du logiciel qui stocke les données des utilisateurs (messages, listes de contacts, clés).
• Par conséquent, il n'y a aucune donnée que l'éditeur pourrait être contraint de remettre aux autorités. Une requête légale ne peut pas forcer la divulgation de données qui n'existent pas ou qui ne sont pas en sa possession.

Electronic Communications Privacy Act (ECPA) - États-Unis

L’ECPA est une loi fédérale américaine de 1986 encadrant la protection des communications électroniques contre l’interception en transit et l’accès non autorisé aux données stockées. Un de ses volets majeurs, le Stored Communications Act (SCA), définit les procédures (mandats, assignations) permettant aux autorités d'accéder aux données détenues par des fournisseurs de services.

L'architecture d'iCanText redéfinit l'application de l'ECPA par la neutralisation technique :

• Inexistence d'un "Fournisseur de Stockage" : Contrairement aux services de messagerie classiques, iCanText n'agit pas comme un "fournisseur de service de communication électronique" ou un "fournisseur de stockage à distance" au sens de l'ECPA. Les messages ne résident jamais sur les serveurs de l'éditeur ou d'un tiers ; ils circulent exclusivement en P2P et sont chiffrés de bout-en-bout.
• Absence de communications stockées (SCA) : Le volet SCA de l'ECPA ne trouve aucune prise sur iCanText. Puisqu'il n'y a pas de stockage centralisé, il n'existe aucune base de données sur laquelle un warrant (mandat) ou un subpoena (assignation) pourrait s'exercer auprès de l'éditeur.
• Protection des métadonnées : Les informations de routage ne sont pas centralisées et sont protégées par le routage scellé. Cela élimine la possibilité pour une autorité d'exiger du fournisseur la divulgation de journaux de connexions (logs) qui, par conception, n'existent pas.

En résumé : l’ECPA s’applique aux services qui gèrent ou acheminent des communications via leurs propres infrastructures. iCanText n’étant pas un intermédiaire technique de stockage, son architecture P2P + E2EE minimise structurellement la portée de l’ECPA vis-à-vis de l’éditeur du logiciel.

Wiretap Act (Title I de l’ECPA) - États-Unis

Le Wiretap Act interdit toute interception intentionnelle, utilisation ou divulgation de communications électroniques, filaires ou orales, à moins d'une exception légale stricte (consentement d'une partie ou mandat judiciaire). Cette loi protège les données "en transit".

iCanText garantit le respect du Wiretap Act par une impossibilité technique d'interception :

• Absence de point de capture : Contrairement aux architectures centralisées où le trafic passe par un commutateur ou un serveur géré par l'éditeur, iCanText établit des connexions directes en P2P (Peer-to-Peer). Il n'existe aucun point de passage obligé sous le contrôle de l'éditeur où une interception pourrait être pratiquée.
• Neutralisation de l'interception par le chiffrement : Le Wiretap Act vise l'accès au contenu des communications. Grâce au chiffrement de bout-en-bout (E2EE), même si un flux de données était capturé sur le réseau, son contenu resterait mathématiquement indéchiffrable. L'éditeur ne possédant pas les clés de session, il se trouve dans l'incapacité de "lire" ou d'écouter les échanges.
• Conformité par l'inaction forcée : iCanText ne surveille pas, ne redirige pas et n'analyse pas le trafic des utilisateurs. Le logiciel est conçu pour que l'éditeur reste un tiers totalement étranger à la communication, garantissant qu'aucune interception intentionnelle ne puisse être mise en œuvre au niveau applicatif.

Conclusion Wiretap Act : iCanText respecte les dispositions du Wiretap Act par son architecture même. En éliminant les relais en clair et en décentralisant les flux, le service supprime les vecteurs d'interception, plaçant la confidentialité des échanges au-delà de toute capacité technique de monitoring par le fournisseur de logiciel.

Children’s Online Privacy Protection Act (COPPA) - États-Unis

Le COPPA est une loi fédérale américaine visant à protéger la vie privée des enfants de moins de 13 ans en ligne. Elle impose aux opérateurs de services la mise en place d'un consentement parental vérifiable, de politiques de confidentialité explicites et d'un droit d'accès ou de suppression des données concernant les mineurs.

L'approche d'iCanText vis-à-vis de COPPA repose sur l'absence structurelle de collecte :

• Absence de collecte d'Informations Personnelles Identifiables (PII) : Le déclencheur principal de COPPA est la "collecte de données personnelles". iCanText ne requiert aucune donnée de ce type (ni numéro de téléphone, ni adresse email, ni nom) pour fonctionner. L'identité numérique de l'utilisateur est une clé cryptographique générée localement sur son terminal.
• Inexistence de base de données "mineurs" : COPPA cible l'opérateur qui stocke ou traite des informations sur des enfants. Puisqu'iCanText n'utilise aucun serveur central pour stocker les profils ou les communications, il n'existe aucune base de données de mineurs que l'éditeur pourrait administrer ou pour laquelle un consentement parental pourrait être techniquement recueilli et stocké.
• Contrôle exclusivement local : La gestion des données (messages, contacts) restant sur l'appareil de l'utilisateur, ce sont les parents ou tuteurs qui exercent, au niveau matériel, le contrôle total sur l'usage et la suppression des informations, conformément à l'esprit de la loi.

Conclusion pratique : COPPA s’applique lorsqu’un service en ligne collecte ou traite sciemment des données de mineurs. En éliminant toute collecte identifiable et tout stockage centralisé, iCanText place son architecture hors du champ d'application opérationnel de COPPA : sans collecte de données identifiables par l'éditeur, les obligations de consentement parental centralisé ne trouvent pas d'objet.

Communications Assistance for Law Enforcement Act (CALEA) - États-Unis

Le CALEA est une loi américaine de 1994 qui impose aux opérateurs de télécommunications et aux fournisseurs d'accès à large bande de concevoir leurs réseaux de manière à faciliter les interceptions légales par les autorités de police.

L'architecture d'iCanText se situe structurellement hors du périmètre de CALEA :

• Absence de statut de "Carrier" (Opérateur) : CALEA s'adresse spécifiquement aux transporteurs de trafic et aux fournisseurs d'infrastructure réseau. iCanText n'est pas un opérateur de transport ; c'est un logiciel applicatif exécuté localement dans le navigateur de l'utilisateur. Il ne possède ni n'exploite l'infrastructure de transport des données.
• Inexistence de point d'interception centralisé : L'application de CALEA suppose l'existence d'un commutateur, d'une passerelle ou d'un nœud central contrôlé par le fournisseur où une interception peut être activée. iCanText fonctionnant sur un modèle P2P (Peer-to-Peer) strict, il n'existe aucun relais centralisé par lequel transite le trafic et où une interception pourrait être techniquement configurée.
• Protection légale du chiffrement : CALEA stipule explicitement (Section 103) que les entités soumises à la loi ne sont pas tenues de déchiffrer les communications cryptées par l'utilisateur, à moins que le fournisseur ne détienne les clés. Dans le modèle E2EE d'iCanText, l'éditeur ne possède aucune clé de déchiffrement, rendant toute injonction d'interception techniquement inexécutable.

Conclusion CALEA : L’architecture décentralisée d’iCanText, combinée au chiffrement de bout-en-bout sans tiers de confiance, place nativement le service hors du périmètre légal et technique de CALEA. La FCC et les tribunaux américains confirment que CALEA n’oblige pas les éditeurs de logiciels à modifier leur architecture pour permettre la surveillance ou à affaiblir leurs mécanismes de sécurité.

FISA / FISA Amendments Act (Section 702) - États-Unis

La loi FISA (*Foreign Intelligence Surveillance Act*), et plus spécifiquement la Section 702, autorise les agences de renseignement américaines à collecter des données de communications étrangères transitant par des fournisseurs de services ou des infrastructures basés aux États-Unis.

iCanText est structurellement non exploitable par les mécanismes de collecte prévus par FISA :

• Inexistence d'un accès "fournisseur" (Provider Access) : Les ordonnances émises sous FISA 702 imposent à un fournisseur de services de remettre les données qu'il possède ou qu'il contrôle. L'architecture d'iCanText garantit que l'éditeur ne possède aucun contenu de message, aucune clé de déchiffrement, ni aucune métadonnée exploitable. Une requête FISA ne peut contraindre la divulgation de données qui ne sont ni détenues, ni accessibles par l'éditeur.
• Absence de rôle d'intermédiaire de transmission : La loi cible prioritairement les entités qualifiées de *Electronic Communication Service Providers* (ECSP). iCanText n'étant pas un intermédiaire acheminant le trafic sur ses propres serveurs, mais un outil logiciel exécuté côté client (navigateur), il ne constitue pas un point de collecte technique pour les programmes de surveillance de masse.
• Immunité contre le déchiffrement forcé : Comme pour les autres législations de surveillance américaines, FISA ne permet pas d'obliger un éditeur de logiciel à modifier son code source pour y introduire une faille de sécurité (backdoor) ou pour affaiblir un chiffrement de bout-en-bout déjà en place.

Conclusion FISA : Par sa conception "Zero-Knowledge" et son modèle de réseau P2P, iCanText neutralise les vecteurs de collecte de FISA. En l'absence de point de stockage central et de contrôle sur les clés privées des utilisateurs, l'éditeur se trouve dans l'incapacité technique de répondre favorablement à une demande de surveillance, garantissant ainsi l'intégrité des échanges.

USA PATRIOT Act - États-Unis

Adopté en 2001, le Patriot Act a considérablement élargi les pouvoirs de recherche et de surveillance des agences fédérales américaines. Il a notamment facilité l'usage des *National Security Letters* (NSL), étendu les capacités de saisie via *subpoenas* (assignations) et renforcé les obligations de coopération forcée des fournisseurs de services technologiques.

L’impact du Patriot Act sur iCanText est neutralisé par l'absence de données existantes :

• Limites des pouvoirs de coercition (Subpoenas & NSLs) : Le Patriot Act facilite l'accès aux données déjà détenues par un fournisseur. Cependant, l'architecture d'iCanText garantit qu'aucune donnée de communication, aucune métadonnée et aucune clé privée n'est jamais en possession de l'éditeur. Les pouvoirs étendus du Patriot Act ne peuvent s'exercer sur des informations inexistantes.
• Absence d'obligation de "création" de données : Il est crucial de noter que le Patriot Act élargit les procédures d'accès, mais ne crée aucune obligation technique de modifier une architecture logicielle. Il n'impose pas à l'éditeur de créer des journaux (logs), de conserver des clés de chiffrement ou de transformer une solution décentralisée en un système centralisé pour permettre une surveillance future.
• Maintien de l'immunité structurelle : Le Patriot Act n'augmente pas l'exposition d'iCanText par rapport aux lois qu'il a modifiées (comme l'ECPA ou FISA). Sans point de contrôle central et sans stockage de données tierces, l'éditeur ne dispose d'aucun levier technique pour satisfaire une demande de coopération forcée visant le contenu des échanges.

Conclusion Patriot Act : Le Patriot Act renforce les moyens de saisie des données centralisées, mais il ne remet pas en cause la légalité du chiffrement de bout-en-bout ou des architectures décentralisées. En éliminant la "banque de données" centrale, iCanText retire l'objet même sur lequel les dispositions du Patriot Act pourraient s'appliquer.

Lois sur la Rétention des Données (Data Retention)

De nombreux pays imposent aux fournisseurs de services de communication de conserver les métadonnées (qui a contacté qui, quand, depuis où...) pour une durée déterminée, à des fins de sécurité nationale.

Ces lois sont également inapplicables à iCanText :

• iCanText n'est pas un "fournisseur de service de communication" au sens traditionnel. Il fournit un logiciel, pas un service d'acheminement.
• L'architecture P2P et le routage scellé sont spécifiquement conçus pour empêcher la collecte centralisée de métadonnées. Il n'y a donc aucune donnée de ce type à retenir.

Loi sur la protection des renseignements personnels et les documents électroniques (LPRPDE / PIPEDA) - Canada

La LPRPDE (PIPEDA en anglais) est la loi fédérale canadienne qui régit la manière dont les organisations du secteur privé collectent, utilisent et communiquent les renseignements personnels dans le cadre d'activités commerciales. Elle repose sur dix principes de protection de la vie privée, notamment le consentement, la limitation de la collecte et la responsabilité.

L'architecture d'iCanText redéfinit la conformité au droit canadien par la souveraineté de l'utilisateur :

• Absence de collecte commerciale : La LPRPDE s'applique dès lors qu'une organisation "collecte" des renseignements personnels. iCanText ne requiert aucun compte, aucun identifiant (email, téléphone) et ne crée aucun profil utilisateur. En l'absence de collecte centralisée de données identifiables, les obligations de consentement préalable et de gestion de base de données ne trouvent pas d'objet vis-à-vis de l'éditeur.
• Distinction entre outil logiciel et traitement de données : En droit canadien, une distinction cruciale est faite sur le "contrôle" des renseignements. Puisqu'iCanText ne peut ni accéder, ni indexer, ni utiliser les messages (stockés en RAM chez l'utilisateur), l'organisation n'est pas considérée comme ayant la garde ou le contrôle des données. Elle fournit un outil de communication et non un service de traitement de données pour son propre compte.
• Sécurité et Chiffrement de bout-en-bout : Le principe de "Mesures de sécurité" de la LPRPDE impose de protéger les renseignements personnels contre la perte ou le vol. En utilisant un modèle P2P chiffré de bout-en-bout, iCanText implémente les mesures de protection les plus élevées du marché, garantissant que même en transit, l'information reste inaccessible à tout tiers, y compris à l'éditeur du logiciel.

Conclusion LPRPDE / PIPEDA : L'approche "Zero-Knowledge" d'iCanText place le service en parfaite adéquation avec l'esprit de la législation canadienne. En rendant l'organisation techniquement incapable d'accéder aux données des utilisateurs, iCanText élimine les risques de communication non autorisée et garantit que la responsabilité et le contrôle des renseignements restent exclusivement entre les mains de l'utilisateur final.

Projets de loi C-13 et C-51 (Cybercriminalité et Surveillance) - Canada

Le projet de loi C-13 (*Loi sur la protection des Canadiens contre la cybercriminalité*) et le projet de loi C-51 (*Loi antiterroriste de 2015*) ont modernisé les pouvoirs d'enquête au Canada. Ces textes facilitent l'accès des autorités aux données détenues par les fournisseurs de services et encadrent les ordonnances de production de données de transmission et de pistage.

L’impact de ces lois sur iCanText est neutralisé par le principe de "possession des données" :

• Inapplicabilité des ordonnances de production : Les pouvoirs d'enquête prévus par C-13 et C-51 s'exercent sur les données qu'un fournisseur "possède ou contrôle". L'architecture d'iCanText garantit que l'éditeur ne détient aucun contenu de communication, aucune clé de déchiffrement et aucune métadonnée exploitable. Une ordonnance de production ne peut contraindre la divulgation de ce qui, par conception, n'existe pas dans les systèmes de l'éditeur.
• Absence de métadonnées centralisées : Les dispositions de ces lois visent souvent les données de transmission (qui a communiqué avec qui). Grâce au routage scellé et à l'architecture P2P, ces informations ne sont jamais collectées ni centralisées par iCanText. Il n'existe donc aucun registre de métadonnées que l'éditeur pourrait être contraint de remettre aux autorités.
• Respect de l'intégrité architecturale : Bien que ces lois renforcent les capacités de partage d'informations entre agences gouvernementales, elles n'imposent pas aux éditeurs de logiciels de modifier leur architecture pour créer des capacités d'interception ou pour stocker des données qu'ils ne collecteraient pas normalement dans le cadre de leur activité.

Conclusion C-13 / C-51 : Ces lois augmentent les pouvoirs de saisie sur les infrastructures centralisées, mais n'augmentent pas l'exposition juridique d'iCanText. En éliminant tout stockage de données et tout contrôle centralisé sur les échanges, iCanText demeure structurellement protégé contre les demandes de production de données, garantissant la confidentialité des utilisateurs face aux mécanismes de surveillance.

Loi fédérale sur la protection des données (nLPD - révisée en 2023) - Suisse

Entrée en vigueur le 1er septembre 2023, la nLPD a modernisé le cadre juridique suisse pour s'aligner sur les standards européens (RGPD) tout en conservant ses spécificités. Elle s'applique à tout traitement de données personnelles ayant un effet en Suisse, indépendamment du siège de l'entreprise qui effectue le traitement.

L'architecture d'iCanText neutralise les obligations de "responsable de traitement" au sens du droit suisse :

• Absence de pouvoir de disposition sur les données : En droit suisse, le traitement suppose un pouvoir de disposition sur les renseignements personnels. iCanText ne collecte aucune donnée identifiable, ne stocke aucun message et ne peut techniquement pas accéder au contenu des échanges. En l'absence d'accès et de stockage, l'éditeur n'exerce aucun "traitement" au sens de la nLPD pour les communications transitant via l'outil.
• Neutralité de l'outil technique : Le responsable du traitement est l'entité qui détermine les finalités et les moyens essentiels du traitement. iCanText agit exclusivement comme un fournisseur de technologie neutre. Puisque l'éditeur ne définit ni pourquoi, ni comment le contenu est échangé (ces choix appartenant aux utilisateurs), il ne peut être qualifié de responsable de traitement pour les données des communications.
• Sécurité et Proportionnalité par conception : La nLPD insiste sur les principes de sécurité et de proportionnalité. En garantissant l'absence de logs, d'identifiants (ID) centraux et d'analytics intrusifs, iCanText implémente une architecture qui respecte nativement les exigences de protection des données dès la conception (*Privacy by Design*).
• Souveraineté et contrôle local : Les données restant exclusivement sous le contrôle des utilisateurs (sur leurs terminaux respectifs), iCanText garantit que les droits des personnes concernées (accès, portabilité, effacement) sont exercés directement par l'utilisateur sur son propre environnement, sans dépendance vis-à-vis d'un tiers.

Conclusion nLPD : Tant que l’architecture d'iCanText demeure fidèle à son modèle décentralisé (pas de stockage, pas d'identité centrale), l'éditeur ne peut être tenu pour responsable de traitement au sens de la nLPD pour les échanges privés. Cette architecture offre aux entreprises suisses et internationales un niveau de protection supérieur, plaçant les données hors de portée de toute exploitation non autorisée par le fournisseur de service.

Loi sur la surveillance de la correspondance par poste et télécommunication (LSCPT / BÜPF) - Suisse

La LSCPT (BÜPF en allemand) définit le cadre légal de la surveillance des télécommunications en Suisse à des fins de poursuite pénale. Elle impose des obligations de coopération aux Fournisseurs de Services de Télécommunication (FST) ainsi qu'aux fournisseurs de services de communication dits "dérivés".

L'architecture d'iCanText place le service hors du champ opérationnel de la surveillance légale suisse :

• Absence de statut de Fournisseur de Services de Télécommunication (FST) : La LSCPT vise prioritairement les entités qui fournissent un accès au réseau ou transportent des données pour le compte de tiers. iCanText n'assurant ni l'accès réseau, ni le transport physique du trafic, il ne relève pas de la catégorie des FST soumis aux obligations de stockage préventif des métadonnées (rétention).
• Incapacité technique d'interception (Services dérivés) : Même si iCanText devait être qualifié de "fournisseur de services dérivés", la loi ne peut exiger que des mesures techniquement réalisables. L'architecture d'iCanText supprimant tout relais central et toute clé de déchiffrement côté éditeur, il n'existe aucun "point d'interception" où une mesure de surveillance pourrait être activée. Une ordonnance de surveillance resterait donc sans objet faute de faisabilité technique.
• Légalité du chiffrement de bout-en-bout : Le droit suisse reconnaît la licéité du chiffrement fort. Contrairement à d'autres juridictions, la LSCPT n'impose aucune obligation d'introduire des failles de sécurité (*backdoors*) ou d'affaiblir une architecture décentralisée pour faciliter le travail des autorités. L'intégrité du chiffrement E2EE est préservée.
• Absence de métadonnées de surveillance : La LSCPT s'intéresse particulièrement aux données permettant d'identifier qui communique avec qui. Par son routage scellé et son absence de journalisation centrale, iCanText ne génère aucune métadonnée exploitable par l'éditeur, rendant toute demande de renseignements rétroactive techniquement impossible.

Conclusion LSCPT : En Suisse comme à l'international, l'architecture d'iCanText protège les utilisateurs par l'absence structurelle de point de capture. En ne centralisant ni le contenu, ni les métadonnées, ni les clés, iCanText se situe hors de portée des mécanismes de surveillance de masse ou ciblée, tout en restant en parfaite conformité avec les obligations de moyens du droit suisse.

Code pénal suisse - Protection du secret des communications

Le Code pénal suisse protège rigoureusement la sphère privée. Les articles 179bis et suivants sanctionnent sévèrement l'écoute, l'enregistrement, la divulgation ou l'exploitation de communications privées sans le consentement des participants ou sans base légale. Le secret des télécommunications est une liberté fondamentale protégée par la Constitution fédérale et le droit pénal.

La conformité d'iCanText au Code pénal suisse est assurée par une impossibilité technique de violation :

• Absence de capacité d'interception : Pour qu'il y ait interception ou écoute illicite au sens du Code pénal, un acteur doit être en mesure de capter le flux et d'en comprendre le contenu. L'architecture P2P d'iCanText élimine tout relais central, tandis que le chiffrement de bout-en-bout (E2EE) garantit que l'éditeur reste incapable de capter ou d'exploiter les échanges.
• Inexistence d'un "auteur" pénalement qualifiable : La responsabilité pénale suppose une action intentionnelle d'accès aux données. Dans le modèle d'iCanText, l'éditeur ne possède aucun moyen technique (clés, accès serveur, accès RAM) pour accéder aux communications. Par conséquent, l'éditeur ne peut se trouver dans une situation où il pourrait être accusé de violation du secret des communications, n'ayant aucun levier pour commettre l'infraction.
• Protection contre l'exploitation de métadonnées : Le Code pénal protège également contre l'exploitation abusive d'informations liées aux communications. En ne collectant aucune métadonnée centralisée et en utilisant le routage scellé, iCanText prévient structurellement toute divulgation ou exploitation de données de trafic.

Conclusion pénale : L'architecture "Zero-Knowledge" d'iCanText offre une garantie de sécurité bilatérale. Elle protège les utilisateurs contre toute interception illicite par des tiers ou par le fournisseur lui-même, et elle protège l'éditeur en le plaçant hors de portée de toute mise en cause pénale liée au secret des télécommunications. La confidentialité n'est pas seulement un engagement contractuel, c'est une barrière mathématique et architecturale.

Obligations de conservation et collaboration pénale - Suisse

En vertu du Code de procédure pénale (CPP) et de la LSCPT, les autorités suisses peuvent exiger des fournisseurs de services qu'ils collaborent à une enquête en remettant des données de communication ou en effectuant des interceptions. Toutefois, cette obligation est strictement limitée par le principe de proportionnalité et de faisabilité technique.

La coopération d'iCanText avec les autorités est juridiquement satisfaite par l’incapacité technique de produire des données :

• Absence de stockage de contenu : Les autorités ne peuvent exiger que la production de "données existantes". iCanText ne stockant aucun message sur ses serveurs (modèle éphémère ou stockage local exclusif à l'utilisateur), l'éditeur se trouve dans l'impossibilité de produire des contenus de communication, même sous injonction judiciaire.
• Inexistence de journaux de métadonnées : Contrairement aux fournisseurs de services classiques, iCanText ne conserve aucun journal (logs) des connexions ou des interactions entre utilisateurs. Puisqu'aucune métadonnée n'est générée ou centralisée, il n'existe aucune trace de transmission que l'éditeur pourrait remettre pour identifier les correspondants d'un utilisateur.
• Chiffrement sans tiers de confiance : Les obligations de collaboration ne s'étendent pas à l'obligation de déchiffrer des données dont l'éditeur ne possède pas les clés. Dans le modèle de chiffrement de bout-en-bout d'iCanText, les clés de session sont générées sur les appareils des utilisateurs. L'éditeur n'a donc aucun moyen technique de fournir un contenu intelligible.

Conclusion : En Suisse, l'obligation de collaboration est une obligation de moyens et non de résultat si la technique l'empêche. Pour iCanText, la coopération avec les autorités est "satisfaite par l’absence" : ne détenant ni données, ni journaux, ni clés, l'éditeur répond aux réquisitions par la preuve de l'inexistence des renseignements demandés, garantissant ainsi l'immunité structurelle des communications de ses utilisateurs.

Décret sur la protection des données personnelles (Decree 13/2023/ND-CP) - Vietnam

Le Vietnam a considérablement renforcé son cadre juridique avec l'introduction de la PDPL (Personal Data Protection Law), un texte s'inspirant du RGPD européen. Il impose des obligations strictes aux organisations nationales et étrangères traitant des données de citoyens vietnamiens, notamment en matière de consentement, de sécurité et de localisation des données.

L'architecture d'iCanText neutralise les contraintes de la PDPL par l'absence de traitement centralisé :

• Absence de traitement de données personnelles : La PDPL définit le traitement comme toute opération liée à la collecte, au stockage ou à l'utilisation de données. iCanText ne requiert ni e-mail, ni numéro de téléphone, ni identifiant personnel pour fonctionner. En l'absence de collecte d'informations identifiables, l'éditeur n'effectue aucun "traitement" de données personnelles pour son propre compte au sens de la loi vietnamienne.
• Exemption naturelle de la localisation des données : Le droit vietnamien (notamment le décret 53) impose parfois le stockage local des données des utilisateurs au Vietnam. iCanText répond nativement à cette exigence sans infrastructure complexe : les données restant exclusivement sur les appareils des utilisateurs, elles sont de fait stockées là où se trouve l'utilisateur, sans jamais transiter ni être archivées sur des serveurs étrangers contrôlés par l'éditeur.
• Respect du consentement et de la transparence : Les obligations de recueil de consentement de la PDPL visent les entreprises qui exploitent des données tierces. Puisqu'iCanText est "Zero-Knowledge" et ne voit jamais le contenu des échanges, il n'existe aucun processus de traitement nécessitant un consentement au niveau de l'éditeur, plaçant la vie privée de l'utilisateur hors de portée de toute exploitation commerciale ou administrative centralisée.

Conclusion PDPL : Par son architecture P2P et son chiffrement de bout-en-bout, iCanText est structurellement "hors périmètre" de l'essentiel des obligations de la PDPL. En ne collectant ni ne contrôlant aucune donnée identifiable, l'éditeur supprime les risques de non-conformité et garantit aux entreprises opérant au Vietnam une souveraineté totale sur leurs communications stratégiques.

Privacy Act 1988 et Principes Australiens de Confidentialité (APPs) - Australie

Le Privacy Act 1988 est la loi fédérale australienne régissant la protection des renseignements personnels. Elle s'articule autour des 13 *Australian Privacy Principles* (APPs) qui s'appliquent aux organisations du secteur privé ayant un "lien avec l'Australie". Ces principes imposent des normes strictes sur la collecte, l'utilisation, la divulgation et la sécurité des données.

L'architecture d'iCanText place le service hors du champ des obligations de "collecte" prévues par le droit australien :

• Absence de statut d'"APP Entity" pour les communications : En droit australien, les obligations découlent de la "collecte" de renseignements personnels (*personal information*). iCanText ne demande ni nom, ni email, ni numéro de téléphone pour fonctionner. L'identité est gérée via des clés cryptographiques locales. En l'absence de collecte d'informations permettant d'identifier un individu, l'éditeur n'est pas considéré comme une entité traitant des renseignements personnels au sens des APPs 3 à 5.
• Souveraineté et contrôle exclusif de l'utilisateur : Les messages échangés peuvent contenir des données personnelles, mais celles-ci sont créées, chiffrées et conservées exclusivement sur les terminaux des utilisateurs. Puisque l'éditeur n'a aucun accès technique au contenu et ne détient aucune clé, il n'est pas le "détenteur" (*holder*) des informations. La responsabilité de la gestion des données (accès, correction selon l'APP 12 et 13) reste donc entre les mains de l'utilisateur final.
• Résolution native de la divulgation transfrontalière (APP 8) : L'APP 8 impose des restrictions sur le transfert de données personnelles hors d'Australie. L'architecture P2P d'iCanText résout nativement cette contrainte : les données ne sont jamais centralisées sur des serveurs étrangers gérés par l'éditeur. Elles transitent directement entre utilisateurs, garantissant que la donnée reste là où l'utilisateur se trouve physiquement.

Conclusion Privacy Act : iCanText (Say See Show) n’est pas une entité assujettie aux APPs pour ce qui concerne les communications privées, car il ne collecte ni ne détient de renseignements personnels identifiables. En éliminant le point de collecte central, iCanText permet aux organisations australiennes de communiquer en toute confidentialité sans créer de nouveaux registres de données personnels complexes à gérer selon le Privacy Act.

Telecommunications (Interception and Access) Act 1979 - TIA Act (Australie)

Le TIA Act est le pilier législatif australien encadrant l'interception des communications et l'accès aux données par les forces de l'ordre. Il définit les conditions dans lesquelles les autorités peuvent obtenir des mandats pour intercepter des communications en temps réel ou accéder à des données stockées.

L'architecture d'iCanText place le service hors du champ opérationnel du TIA Act :

• Absence de capacité technique d'interception : Pour qu'une interception soit possible au sens du TIA Act, il faut l'existence d'un acteur capable techniquement de capter le flux. iCanText n'étant pas un transporteur de données (pas d'infrastructure réseau) et fonctionnant sur un modèle P2P strict, il n'existe aucun point de passage centralisé où une interception pourrait être pratiquée par l'éditeur.
• Inexistence d'obligation de modification d'architecture : Bien que la législation australienne ait été renforcée ces dernières années, le TIA Act n'impose pas aux développeurs d'applications de modifier leur architecture logicielle pour créer des capacités d'interception inexistantes. iCanText n'a aucune obligation légale de transformer son modèle décentralisé en un modèle centralisé "interceptable".
• Protection du chiffrement de bout-en-bout : Le TIA Act ne contraint pas un fournisseur à déchiffrer des communications s'il ne possède pas les clés. Dans le modèle E2EE d'iCanText, les clés sont générées et détenues exclusivement par les utilisateurs finaux. L'éditeur est donc dans l'incapacité totale de fournir le contenu en clair d'une communication, même sous injonction légale.
• Absence de métadonnées exploitables : La loi australienne permet l'accès aux métadonnées (données de transmission). En utilisant le routage scellé et en ne tenant aucun registre central des interactions, iCanText garantit qu'aucune métadonnée n'est disponible pour une saisie rétroactive par les autorités auprès de l'éditeur.

Conclusion TIA Act : L’architecture décentralisée d’iCanText protège les utilisateurs par l’absence structurelle de point de capture. En ne centralisant ni le contenu, ni les métadonnées, ni les clés, iCanText se situe hors de portée des mécanismes d’interception prévus par le TIA Act, garantissant une confidentialité totale par l'impossibilité technique de surveillance.

Assistance and Access Act 2018 (AA Act) - Australie

Le *Telecommunications Legislation Amendment (Assistance and Access) Act 2018*, communément appelé AA Act, est l'une des législations les plus débattues au niveau mondial. Elle permet aux agences de renseignement et de police australiennes d'émettre trois types de demandes : les demandes d'assistance technique (TAR), les avis d'assistance technique (TAN) et les avis de capacité technique (TCN).

Bien que souvent perçue comme une loi "anti-chiffrement", l'AA Act comporte des protections strictes qui préservent l'architecture d'iCanText :

• Interdiction des faiblesses systémiques (Section 317ZG) : C'est le pilier protecteur fondamental. La loi stipule explicitement qu'un avis (TAN ou TCN) ne peut pas obliger un fournisseur à introduire une "faiblesse systémique" ou une "vulnérabilité systémique" dans ses logiciels. En pratique, cela signifie qu'il est illégal d'exiger d'iCanText qu'il casse son chiffrement de bout-en-bout ou qu'il introduise une "backdoor" (porte dérobée).
• Incapacité technique au sein des systèmes existants : Un avis de capacité technique (TCN) ne peut exiger d'un fournisseur que des actions qui sont techniquement réalisables dans le cadre de ses systèmes actuels. iCanText fonctionnant sans serveur central, sans stockage de clés et sans contrôle du trafic, l'éditeur ne dispose d'aucune "capacité" existante à activer. Créer une telle capacité (par exemple, ajouter un serveur de relais ou de stockage) constituerait une modification structurelle majeure interdite par la loi.
• Principe de proportionnalité et de faisabilité : Toute demande d'assistance doit être jugée "raisonnable et proportionnée" et le coût de mise en œuvre ne doit pas être excessif. Pour un éditeur P2P, l'exigence de transformer une architecture décentralisée en un système de surveillance centralisé serait jugée disproportionnée et contraire aux limites fixées par l'AA Act lui-même.
• Protection du secret industriel : L'AA Act n'oblige pas les fournisseurs à divulguer des secrets commerciaux ou des détails de propriété intellectuelle qui affaibliraient la sécurité globale du produit.

Conclusion AA Act : Malgré la portée étendue de l'AA Act, l'architecture d'iCanText demeure protégée par les clauses d'intégrité systémique de la loi. En l'absence de serveurs de contenu et de contrôle sur les clés privées, l'éditeur se trouve dans l'incapacité technique de fournir un accès aux communications. L'AA Act ne peut contraindre iCanText à créer un accès qu'il n'a pas, ni à affaiblir la sécurité mathématique qui protège ses utilisateurs.

Protection des mineurs et sécurité en ligne - Australie

L'Australie dispose d'un cadre rigoureux pour la protection des enfants en ligne, notamment via le *Privacy Act* et l'*Online Safety Act 2021*. Ces régulations sont supervisées par l'*eSafety Commissioner* et visent principalement les plateformes de médias sociaux, les services de partage de contenu et les fournisseurs de stockage.

iCanText se situe hors du champ d'application des obligations spécifiques aux plateformes de contenu :

• Absence de collecte de données d'âge ou d'identité : Contrairement aux réseaux sociaux, iCanText ne requiert aucune création de profil, aucune adresse email et aucune déclaration d'âge. Puisqu'aucune donnée personnelle n'est collectée par l'éditeur, les obligations de vérification de l'âge ou de consentement parental prévues par le *Privacy Act* ne s'appliquent pas au niveau du fournisseur du logiciel.
• Non-classification comme "Service de Médias Sociaux" : L'architecture d'iCanText est celle d'un outil de communication point-à-point (P2P). Il ne comporte ni fils d'actualité, ni algorithmes de recommandation, ni profils publics. À ce titre, il ne tombe pas sous la définition des services de médias sociaux ou des services de contenu régulés par l'*eSafety Commissioner*.
• Inexistence de contenu hébergé ou modéré : Les obligations de signalement ou de retrait de contenu illicite ciblent les fournisseurs qui "hébergent" ou "stockent" des données. iCanText n'ayant aucun accès au contenu chiffré et ne stockant aucun message sur ses systèmes, l'éditeur ne dispose d'aucun levier technique pour modérer, analyser ou supprimer des échanges privés entre utilisateurs.
• Protection de la vie privée des mineurs par le chiffrement : En garantissant une communication privée et chiffrée de bout-en-bout, iCanText protège l'intégrité des échanges des utilisateurs, y compris des mineurs, sans créer de bases de données vulnérables qui pourraient être exploitées par des tiers.

Conclusion : Aucune obligation spécifique de régulation des contenus ou de gestion de profils de mineurs ne s'applique à iCanText. En tant que fournisseur d'un outil de communication décentralisé et "Zero-Knowledge", l'éditeur n'exerce aucun contrôle sur les interactions et ne collecte aucune donnée permettant d'identifier ou de cibler des mineurs, garantissant ainsi une conformité par l'absence d'intervention.

Investigatory Powers Act 2016 (IPA) - Royaume-Uni

L'Investigatory Powers Act 2016, souvent surnommé la « Snooper’s Charter », constitue le cadre juridique principal régissant les pouvoirs des agences de renseignement et de police britanniques en matière de surveillance. Il encadre l'interception des communications, l'acquisition de données de connexion et l'émission d'avis de capacité technique (Technical Capability Notices - TCN).

L'architecture d'iCanText neutralise la portée opérationnelle de l'IPA par l'absence d'infrastructure centralisée :

• Statut contestable d'Opérateur de Télécommunications : L'IPA s'applique aux "telecommunications operators". Cette définition vise les entités qui fournissent un service de communication ou contrôlent l'infrastructure de transmission. iCanText ne fournit pas d'accès réseau, n'opère aucun transport physique de trafic et ne gère aucun serveur de contenu. En tant qu'outil logiciel exécuté localement côté client, sa qualification d'opérateur sous l'IPA est hautement contestable.
• Limite du "raisonnablement praticable" (Section 253) : Lorsqu'un avis de capacité technique (TCN) est émis, la loi stipule que les obligations imposées doivent être "raisonnablement praticables" et proportionnées. Pour iCanText, fournir un accès au contenu chiffré ou créer un point d'interception exigerait une refonte totale de son architecture décentralisée. De telles exigences sortent du cadre de ce qui est techniquement et raisonnablement exigible d'un fournisseur.
• Incapacité technique d'interception : Un TCN ne peut forcer un fournisseur à remettre des données qu'il ne possède pas ou à activer une capacité qu'il n'a pas. iCanText ne détenant aucune clé de déchiffrement, aucun message en clair et aucun relais centralisé, l'éditeur se trouve dans l'incapacité matérielle de satisfaire une demande d'interception légale.
• Préservation du chiffrement de bout-en-bout : Bien que l'IPA soit une loi puissante, elle n'impose pas explicitement de "backdoor" obligatoire ni le cassage systématique du chiffrement si le fournisseur ne dispose pas des moyens de déchiffrement dans le cadre de ses systèmes normaux. iCanText préserve l'intégrité de son chiffrement E2EE par son absence de tiers de confiance.

Conclusion IPA : Même sous l'Investigatory Powers Act, iCanText ne peut être contraint à fournir un accès qu'il n'a pas. L'architecture décentralisée garantit que le "pouvoir d'investigation" ne rencontre aucune donnée centralisée à saisir, plaçant la confidentialité des échanges sous la protection d'une barrière technique infranchissable pour l'éditeur lui-même.

Online Safety Act 2023 (OSA) - Royaume-Uni

L'Online Safety Act (OSA) est une législation majeure visant à réguler les contenus en ligne afin de protéger les utilisateurs, et particulièrement les mineurs, contre les contenus illicites ou préjudiciables. Elle impose des obligations de modération, de gestion des risques et de coopération avec l'Ofcom (l'autorité de régulation des communications au Royaume-Uni).

iCanText se situe en dehors du périmètre opérationnel de l'OSA par sa nature technique décentralisée :

• Absence de statut d'hébergeur de contenu : L'OSA cible prioritairement les services "user-to-user" qui permettent aux utilisateurs de partager du contenu qui est "hébergé" sur le service. iCanText fonctionne sur un modèle Peer-to-Peer (P2P) strict : aucun message n'est jamais stocké, archivé ou hébergé sur les serveurs de l'éditeur. En l'absence d'hébergement, les obligations de modération de contenu ne trouvent pas d'objet technique.
• Communications privées vs Diffusion publique : Contrairement aux réseaux sociaux ou aux plateformes de partage de contenu, iCanText est un outil de communication point-à-point. Il ne comporte aucun algorithme de recommandation, aucun fil d'actualité et aucune visibilité publique. Cette distinction est cruciale car l'OSA vise avant tout les services où le contenu peut devenir viral ou accessible à un large public.
• Impossibilité technique de modération : L'une des dispositions les plus débattues de l'OSA concerne la capacité de l'Ofcom à exiger l'analyse des messages pour détecter des contenus illicites. Toutefois, iCanText utilise un chiffrement de bout-en-bout (E2EE) sans accès aux clés par l'éditeur. En l'absence de serveur de transit et de capacité de lecture, l'éditeur est techniquement incapable d'analyser, de filtrer ou de modérer les échanges privés entre utilisateurs.
• Protection de la vie privée par le "Zero-Knowledge" : En ne collectant aucune donnée de profil et en ne stockant aucune métadonnée centralisée, iCanText garantit une confidentialité totale qui place les échanges des utilisateurs hors du champ des mécanismes de surveillance et de signalement automatique prévus pour les plateformes de contenu.

Conclusion Online Safety Act : iCanText est largement hors du périmètre opérationnel de l'OSA. En tant que fournisseur d'un outil de communication décentralisé et chiffré, l'éditeur n'exerce aucun contrôle sur le contenu échangé et ne dispose d'aucune infrastructure de stockage permettant la mise en œuvre des mesures de modération prévues par la loi. La responsabilité et le contrôle du contenu restent du ressort exclusif des utilisateurs.

Digital Services Act (DSA) - Europe

Le DSA vise à réguler les plateformes en ligne pour lutter contre les contenus illicites. Il impose des obligations de modération et de transparence aux "fournisseurs de services intermédiaires".

De par sa nature décentralisée et chiffrée de bout-en-bout, iCanText ne peut être considéré comme un "hébergeur" de contenu au sens du DSA. L'éditeur n'a aucun moyen technique de voir, d'analyser ou de modérer le contenu chiffré qui transite sur le réseau P2P. La responsabilité du contenu reste du ressort exclusif des utilisateurs qui le produisent et le partagent.

Loi fédérale sur les données personnelles (152-FZ) - Russie

La loi fédérale n° 152-FZ est le principal texte régissant le traitement des données personnelles en Russie. Elle s'applique à toute entité, russe ou étrangère, qui collecte, stocke ou traite des données de citoyens russes. Elle impose des obligations de base légale, de sécurité et, surtout, de localisation des données sur le territoire russe.

L'architecture d'iCanText neutralise les contraintes de la loi 152-FZ par l'absence de détention de données :

• Inexistence de traitement par l'éditeur : La loi 152-FZ définit l'opérateur comme l'entité qui organise ou effectue le traitement de données personnelles. iCanText ne requiert aucun compte, aucun email et aucun identifiant personnel. En ne collectant aucune donnée identifiable et en ne stockant aucun message, l'éditeur n'effectue techniquement aucun "traitement" de données personnelles pour son propre compte.
• Conformité native à la localisation des données : L'une des exigences les plus strictes de la loi 152-FZ est l'obligation de stocker les bases de données primaires des citoyens russes en Russie. iCanText résout ce problème par son architecture P2P : les données résident exclusivement sur les appareils des utilisateurs. Si l'utilisateur est en Russie, ses données y restent physiquement, sans jamais être centralisées sur des serveurs étrangers gérés par l'éditeur.
• Distinction entre usage personnel et opérateur : Le droit russe distingue l'activité d'un opérateur professionnel de l'usage des données par un individu à des fins purement personnelles ou familiales. Dans le modèle d'iCanText, les utilisateurs communiquent directement entre eux sans intermédiaire contrôlant les données, ce qui place l'échange sous la responsabilité et le contrôle exclusif des individus.
• Protection par le chiffrement de bout-en-bout : En l'absence de serveurs de transit et de clés de déchiffrement détenues par l'éditeur, le contenu des communications reste inaccessible, garantissant qu'aucune exploitation non autorisée des données personnelles ne puisse avoir lieu au niveau du fournisseur du logiciel.

Conclusion 152-FZ : iCanText n’est pas un opérateur de données personnelles au sens de la loi 152-FZ pour les communications elles-mêmes. En éliminant la collecte centralisée d'identifiants et en garantissant que les données ne quittent jamais l'appareil de l'utilisateur pour être stockées sur un cloud tiers, iCanText offre une solution structurellement conforme aux exigences de souveraineté numérique sans nécessiter d'infrastructure locale complexe.

Loi sur la localisation des données (242-FZ) - Russie

La loi fédérale n° 242-FZ est une extension majeure de la législation sur les données personnelles. Elle impose que l'enregistrement, la systématisation, l'accumulation, le stockage, l'adaptation et l'extraction des données personnelles des citoyens russes soient effectués à l'aide de bases de données situées physiquement sur le territoire de la Fédération de Russie.

L'architecture d'iCanText rend l'application matérielle de la loi 242-FZ sans objet :

• Inexistence de base de données centralisée : L'obligation de localisation s'applique aux "bases de données" contrôlées par l'opérateur. iCanText fonctionnant sans serveur central, sans stockage cloud et sans base de données utilisateur gérée par l'éditeur, il n'existe aucun actif numérique centralisé auquel une obligation de localisation pourrait être physiquement appliquée.
• Localisation par l'usage : Dans le modèle P2P d'iCanText, les données (messages, contacts, identités locales) sont stockées exclusivement sur le terminal de l'utilisateur. Si un citoyen russe utilise iCanText sur le territoire russe, ses données personnelles restent physiquement en Russie, sur son propre appareil. Cette architecture garantit une localisation de fait, sans nécessiter d'infrastructure intermédiaire.
• Absence de transfert transfrontalier par l'éditeur : Puisque l'éditeur ne collecte pas les données pour les stocker sur ses propres systèmes, il n'effectue aucun transfert de données personnelles des citoyens russes vers des serveurs situés à l'étranger. Le flux de données restant sous le contrôle exclusif des utilisateurs, l'éditeur ne peut être accusé de violation des règles de transfert international.

Conclusion juridique : La loi 242-FZ ne trouve aucune prise sur iCanText. En éliminant le stockage centralisé, iCanText supprime la cause même de l'obligation de localisation forcée, permettant ainsi une communication souveraine qui respecte l'esprit de protection des données locales sans en subir les contraintes techniques.

Loi sur la sécurité des infrastructures d’information critiques (187-FZ) - Russie

La loi fédérale n° 187-FZ vise à protéger les infrastructures d'information critiques (KII/CII) contre les cyberattaques. Elle s'applique aux organisations opérant dans des secteurs stratégiques (santé, transports, télécommunications, énergie, finance, etc.) et impose des obligations strictes de sécurité, de classification des systèmes et de connexion au système d'État GosSOPKA pour le signalement des incidents.

L'architecture d'iCanText redéfinit la gestion du risque lié à la loi 187-FZ pour les entreprises :

• Absence de statut de "Sujet de la KII" pour l'éditeur : La loi 187-FZ s'applique aux propriétaires ou exploitants de systèmes d'information critiques. iCanText étant un logiciel décentralisé s'exécutant sur le terminal de l'utilisateur, l'éditeur ne possède ni n'exploite l'infrastructure de communication des entreprises clientes. La responsabilité de la conformité KII reste au niveau de l'infrastructure de l'entreprise utilisatrice, et non chez le fournisseur du logiciel.
• Réduction de la surface d'attaque critique : En éliminant le serveur central (point de défaillance unique), iCanText supprime une cible majeure pour les cyberattaques visant les infrastructures critiques. Contrairement aux solutions centralisées qui pourraient être classées comme systèmes KII sensibles chez le fournisseur, iCanText distribue la donnée, minimisant ainsi l'impact d'une compromission systémique globale.
• Inexistence de base de données centrale à protéger selon GosSOPKA : Puisqu'iCanText ne centralise aucune donnée de communication, il n'existe pas de "système d'information" central chez l'éditeur qui doive être connecté aux systèmes de surveillance d'État russes. Les entreprises utilisant iCanText pour leurs communications internes protègent leurs flux sans créer de nouveaux actifs KII vulnérables chez un tiers.
• Souveraineté technique locale : Pour les entités russes soumises à la 187-FZ, iCanText permet de maintenir les flux de données exclusivement sur leurs propres terminaux et réseaux internes, garantissant que le contrôle de la sécurité reste intégralement entre les mains du sujet de la KII, sans dépendance vis-à-vis d'un cloud étranger ou centralisé.

Lois « Yarovaya » (2016) - Surveillance et Antiterrorisme (Russie)

L'ensemble législatif connu sous le nom de « lois Yarovaya » impose des obligations extrêmement lourdes aux entités qualifiées d'« Organisateurs de Diffusion d'Information » (ODI). Ces obligations incluent la conservation du contenu des communications, le stockage des métadonnées et la remise des clés permettant le déchiffrement des messages aux autorités (FSB).

L'architecture d'iCanText place le service hors du champ d'application technique de ces mesures :

• Qualification d'ODI hautement contestable : Au sens de la loi russe, un ODI est une entité qui assure la réception, la transmission ou la livraison de messages électroniques via une infrastructure qu'elle contrôle. iCanText ne possédant aucun serveur de transit, aucun relais central et ne contrôlant pas le trafic (P2P pur), il ne remplit pas les critères techniques définissant un organisateur de diffusion d'information.
• Incapacité matérielle de conservation des données : Les lois Yarovaya exigent le stockage massif du contenu des messages. Puisqu'iCanText n'héberge aucun contenu et ne dispose d'aucune infrastructure de stockage cloud, l'éditeur se trouve dans l'incapacité absolue de satisfaire à une quelconque obligation de rétention de données.
• Impossibilité de remise des clés de chiffrement : La loi impose aux ODI de remettre les clés de déchiffrement si l'entité les possède. Dans le modèle de chiffrement de bout-en-bout (E2EE) d'iCanText, les clés sont générées localement sur les appareils des utilisateurs. L'éditeur ne génère aucune clé serveur et ne détient aucune copie des clés privées des utilisateurs. Cette obligation est donc techniquement inexécutable pour l'éditeur.
• Absence de coopération forcée : Sans accès au contenu, sans métadonnées centralisées et sans clés de déchiffrement, iCanText ne dispose d'aucun levier technique pour collaborer activement aux programmes de surveillance prévus par la législation Yarovaya.

Conclusion Lois Yarovaya : L'architecture d'iCanText garantit une immunité par l'incapacité. Même si l'éditeur devait être sollicité, il serait techniquement incapable de se conformer aux exigences de déchiffrement ou de stockage. Pour iCanText, la protection de la vie privée ne relève pas d'une violation volontaire de la loi, mais d'une architecture qui rend la surveillance structurellement impossible.

SORM (Système d’interception légale) - Russie

Le SORM (Système de mesures d'enquête opérationnelle) est le cadre technique de surveillance d'État en Russie. Il impose aux opérateurs de télécommunications et aux fournisseurs d'accès Internet (FAI) l'installation d'équipements matériels spécifiques permettant au FSB (services de sécurité) un accès direct et en temps réel aux flux de données et aux métadonnées circulant sur les réseaux.

L'architecture d'iCanText se situe structurellement hors du champ d'application de SORM :

• Absence de statut d'opérateur d'infrastructure : SORM cible les entités qui possèdent ou exploitent l'infrastructure physique du réseau (câbles, commutateurs, serveurs de transit). iCanText est un logiciel applicatif décentralisé s'exécutant localement sur le terminal de l'utilisateur. Il n'est ni un FAI, ni un opérateur télécom, et ne contrôle aucune infrastructure réseau sur laquelle des équipements SORM pourraient être installés.
• Inexistence de point d'interception centralisé : Le système SORM repose sur la capacité de "brancher" des équipements de surveillance sur des nœuds de transit centraux. iCanText utilisant un modèle Peer-to-Peer (P2P) strict, les données circulent de manière chiffrée entre les terminaux sans passer par un serveur central contrôlé par l'éditeur. Il n'existe donc aucun point d'accès technique où l'éditeur pourrait faciliter l'installation d'un dispositif SORM.
• Neutralisation par le chiffrement de bout-en-bout (E2EE) : Même si les données cryptées d'iCanText étaient interceptées au niveau du fournisseur d'accès Internet (via SORM-2 ou SORM-3), elles resteraient mathématiquement indéchiffrables. L'éditeur ne possédant pas les clés de déchiffrement, il ne peut être contraint de fournir un accès intelligible au contenu, conformément à la séparation stricte entre le transport des données et le contrôle des clés.

Conclusion SORM : Juridiquement et techniquement, SORM est inapplicable à un logiciel de communication P2P dont l'intelligence réside exclusivement sur le terminal client. En éliminant tout nœud centralisé et tout contrôle sur les infrastructures de transport, iCanText garantit que les communications restent protégées contre les mécanismes d'interception matérielle, assurant ainsi la souveraineté numérique de ses utilisateurs.

Loi sur l’information, les technologies de l’information et la protection de l’information (149-FZ) - Russie

La loi fédérale n° 149-FZ constitue le cadre général régissant l'espace numérique en Russie. Elle accorde aux autorités, et en particulier au régulateur Roskomnadzor, des pouvoirs étendus pour restreindre l'accès à des services en ligne, ordonner le blocage de sites web ou blacklister des ressources jugées non conformes ou contraires aux intérêts nationaux.

Pour iCanText, l'enjeu de la loi 149-FZ est de nature opérationnelle plutôt que juridique :

• Risque de blocage administratif : Contrairement aux lois de surveillance (SORM, Yarovaya) qui visent l'accès aux données, la loi 149-FZ permet le blocage d'un service sur simple décision administrative. Même si iCanText est structurellement conforme au respect de la vie privée, il reste exposé au risque d'être rendu techniquement inaccessible sur le territoire russe si les autorités décident d'en filtrer l'accès.
• Indépendance vis-à-vis des infractions pénales : Le blocage sous la loi 149-FZ ne nécessite pas la preuve d'une infraction pénale. Il peut être motivé par le refus (parfois technique) de se plier à des exigences de stockage ou de surveillance. Pour iCanText, l'impossibilité technique de fournir un accès aux données (due à l'architecture P2P) peut paradoxalement devenir un motif de restriction administrative de la part du régulateur.
• Résilience limitée face au filtrage d'État : Bien que le trafic d'iCanText soit chiffré et difficile à identifier, les infrastructures permettant le téléchargement de l'outil ou la mise en relation initiale (signaling) peuvent faire l'objet d'un filtrage par "Deep Packet Inspection" (DPI) mis en œuvre par les FAI russes sous l'égide de la loi 149-FZ.

Conclusion pratique : Le risque principal lié à la législation russe n’est pas la compromission de la confidentialité des données, celle-ci restant garantie par le chiffrement de bout-en-bout et l'absence de serveurs, mais le risque de disponibilité. iCanText offre la meilleure protection contre l'espionnage, mais l'utilisateur doit être conscient que le service peut faire l'objet de mesures de blocage administratif visant à restreindre son usage au sein de la Fédération de Russie.

Réglementation du chiffrement et sécurité cryptographique - Russie

En Russie, l'usage du chiffrement n'est pas illégal en soi pour les particuliers ou les entreprises. Cependant, la législation (notamment via les décrets présidentiels et les lois Yarovaya) conditionne cet usage à une obligation de coopération : tout service fournissant des moyens de cryptographie doit être en mesure de permettre aux autorités d'accéder aux communications si une menace à la sécurité nationale est invoquée.

L'architecture d'iCanText crée un conflit structurel avec les exigences de coopération russes :

• Refus du "Key Escrow" (Séquestre de clés) : Les autorités russes privilégient les solutions où les clés de chiffrement sont soit partagées, soit accessibles via un tiers de confiance. iCanText utilise un chiffrement de bout-en-bout (E2EE) strict sans aucun mécanisme de séquestre. L'éditeur ne génère pas de clés serveurs et ne détient aucune copie des clés privées des utilisateurs, rendant toute demande de "décodage" techniquement impossible à satisfaire.
• Usage de standards cryptographiques mondiaux : iCanText s'appuie sur des protocoles de chiffrement à l'état de l'art (AES-256, Curve25519) qui ne comportent aucune porte dérobée (*backdoor*). Contrairement aux logiciels certifiés par les autorités locales qui peuvent intégrer des algorithmes spécifiques (type GOST) ou des accès facilités, iCanText privilégie une sécurité mathématique universelle et inviolable.
• Conflit politique vs Conflit juridique : Le différend entre iCanText et les exigences russes est avant tout politique. Juridiquement, l'éditeur ne viole pas la loi de manière intentionnelle, mais se trouve dans une incapacité technologique de répondre aux critères de "coopération" qui exigeraient d'affaiblir la sécurité de ses utilisateurs.

Conclusion sur le chiffrement : L'architecture d'iCanText est conçue pour garantir la confidentialité absolue des échanges, ce qui entre en contradiction directe avec la doctrine de surveillance de l'État russe. Pour les entreprises opérant dans cette région, iCanText représente le niveau de sécurité le plus élevé possible, précisément parce que son architecture ne permet aucune compromission, au risque de s'exposer à des mesures administratives de filtrage.

Cybersecurity Law (CSL – 2017) - Chine

La Loi sur la cybersécurité (CSL), entrée en vigueur en 2017, constitue le socle de la régulation numérique en Chine. Elle impose aux « opérateurs de réseaux » des obligations strictes en matière de protection de la sécurité nationale, de coopération avec les autorités de sécurité publique et de contrôle des contenus. La définition d'opérateur de réseau est extrêmement large et englobe pratiquement tout fournisseur de services en ligne.

L'architecture d'iCanText présente une incompatibilité structurelle avec les exigences de la CSL :

• Qualification d'opérateur de réseau : En pratique, tout service de messagerie ou de communication est qualifié d'opérateur de réseau par les autorités chinoises. Ce statut impose une obligation de "coopération technique" et de fourniture d'assistance aux agences de sécurité. iCanText, par sa conception décentralisée, ne dispose d'aucune infrastructure intermédiaire pour matérialiser cette coopération.
• Impossibilité technique d'assistance et d'accès : La CSL exige que les opérateurs fournissent un accès aux données lorsque la sécurité nationale est invoquée. iCanText n'ayant aucune donnée centralisée, aucun message en clair et aucune clé de déchiffrement en sa possession, l'éditeur se trouve dans l'incapacité matérielle de satisfaire à une telle requête.
• Absence de capacité de filtrage et de censure : La loi chinoise impose aux services de prévenir la diffusion de contenus illégaux. Le modèle P2P et le chiffrement de bout-en-bout (E2EE) d'iCanText empêchent l'éditeur de voir, d'analyser ou de filtrer le contenu des échanges. Cette "incapacité de contrôle" est en contradiction directe avec les obligations de modération active prévues par la CSL.
• Anonymat vs Identification réelle : La CSL impose l'identification de l'identité réelle des utilisateurs. iCanText, qui ne collecte ni numéro de téléphone, ni email, et gère l'identité via des clés cryptographiques locales, ne permet pas d'assurer cette traçabilité centralisée exigée par l'administration chinoise.

Data Security Law (DSL – 2021) - Chine

La Loi sur la sécurité des données (DSL), entrée en vigueur en septembre 2021, complète la CSL en se concentrant sur la gouvernance et le cycle de vie des données. Elle introduit un système de classification des données basé sur leur importance pour la sécurité nationale et le développement économique (données "normales", "importantes", ou "nationales").

L'architecture d'iCanText place l'outil en dehors du modèle opérationnel de gestion des données prévu par la DSL :

• Absence de responsabilité de gestionnaire de données : La DSL régule les entités qui collectent, stockent et traitent des données. iCanText ne collectant aucune donnée, ne les classant pas et ne les stockant pas sur des serveurs tiers, l'éditeur n'endosse pas, au sens strict du droit, la responsabilité d'un "gestionnaire de données". La gestion du flux reste exclusivement entre les mains des utilisateurs finaux.
• Neutralité architecturale vs Exigence de contrôle : Il existe une divergence fondamentale de doctrine : alors que le modèle "Zero-Knowledge" est reconnu comme une sécurité maximale dans de nombreuses juridictions, il est perçu sous la DSL chinoise comme une défaillance de contrôle. L'incapacité de l'éditeur à superviser ou à classifier le contenu chiffré qui transite sur le réseau P2P est en rupture avec l'exigence étatique de visibilité sur les flux de données.
• Autonomie des transferts de données : La DSL impose des contrôles rigoureux sur le transfert transfrontalier de données sensibles. iCanText résout ce point techniquement : en l'absence de serveur central, aucun transfert de données n'est initié par l'éditeur vers l'étranger. L'intégrité et la localisation de la donnée dépendent uniquement de l'emplacement physique des terminaux des utilisateurs.

Personal Information Protection Law (PIPL – 2021) - Chine

La PIPL est souvent qualifiée de « RGPD chinois ». Elle établit un cadre complet pour la protection des informations personnelles, imposant des exigences strictes en matière de consentement, de minimisation des données et de droits des personnes concernées. Cependant, contrairement au RGPD européen, la PIPL intègre une dimension de sécurité nationale et un rôle prépondérant de l'État dans la supervision des flux.

L'architecture d'iCanText crée une situation de neutralité juridique théorique qui se heurte aux attentes de la PIPL :

• Absence de traitement de données identifiables : La PIPL s'applique au traitement des informations personnelles. iCanText ne collecte aucun email, numéro de téléphone ou identifiant réel. L'identité est une clé cryptographique générée localement. En l'absence de collecte et de base de données centralisée, la majorité des obligations de la PIPL (consentement, notices d'information, droits d'accès) ne trouvent pas d'objet vis-à-vis de l'éditeur.
• Le paradoxe de la minimisation : Il existe un conflit d'interprétation majeur entre les juridictions occidentales et la PIPL. Là où le RGPD verrait dans l'architecture "Zero-Knowledge" d'iCanText une minimisation exemplaire et une protection par défaut (Privacy by Design), la PIPL y voit une absence de contrôle étatique. La loi chinoise suppose l'existence d'un responsable de traitement identifiable et capable de répondre aux autorités, une fonction qu'iCanText ne peut remplir par conception.
• Cross-border Data Transfer : La PIPL impose des évaluations de sécurité rigoureuses pour le transfert de données personnelles hors de Chine. iCanText neutralise ce risque : en ne stockant aucune donnée sur ses propres serveurs, l'éditeur n'initie aucun transfert transfrontalier. La donnée reste sur le terminal de l'utilisateur, respectant de fait la localisation sans intervention de l'opérateur.

Réglementation spécifique aux services de messagerie instantanée (Chine)

En plus des lois générales sur la cybersécurité, la Chine impose des règles sectorielles strictes aux outils de messagerie instantanée (notamment via les directives du MIIT et de la CAC). Ces règles visent à assurer une traçabilité totale et un contrôle permanent sur les flux d'informations circulant entre les citoyens.

iCanText présente une incompatibilité totale et directe avec les exigences opérationnelles chinoises :

• Absence d'enregistrement sous identité réelle (*Real-name registration*) : La réglementation chinoise impose que tout utilisateur de messagerie soit identifié par son identité réelle (généralement via un numéro de téléphone lié à une carte d'identité nationale). iCanText utilise une identité cryptographique générée localement, sans lien avec une identité civile, ce qui est formellement proscrit pour un service de messagerie autorisé en Chine.
• Incapacité de modération et de suppression des contenus : Les fournisseurs doivent être en mesure de filtrer, modérer et supprimer en temps réel les contenus jugés illicites par les autorités. Le modèle décentralisé P2P et le chiffrement de bout-en-bout d'iCanText empêchent structurellement l'éditeur de voir ou d'intervenir sur le contenu des messages, rendant la modération impossible.
• Absence de conservation des journaux de connexion (*Logging*) : La loi impose aux services de messagerie de conserver les journaux d'activité et les métadonnées pendant une période minimale (généralement 6 mois) à des fins d'enquête. iCanText, par sa conception "Zero-Log", ne génère ni ne stocke aucun registre d'activité, ce qui constitue une violation directe des obligations de conservation des données de trafic.
• Coopération forcée avec la sécurité publique : Les services doivent intégrer des mécanismes permettant l'accès immédiat des autorités aux échanges. L'absence de serveurs de transit et de clés de déchiffrement détenues par l'éditeur rend cette coopération techniquement inexécutable.

Loi sur le chiffrement (Encryption Law – 2020) - Chine

Depuis le 1er janvier 2020, la Chine dispose d'une loi globale sur le chiffrement qui classe les technologies de cryptographie en trois catégories : « centrale », « ordinaire » et « commerciale ». Bien que l'usage de la cryptographie commerciale par les entreprises soit encouragé pour la cybersécurité, son déploiement reste soumis à une supervision stricte et à des exigences de certification dès lors qu'il touche aux infrastructures d'information critiques (CII).

L'architecture d'iCanText présente un conflit structurel insoluble avec la doctrine cryptographique chinoise :

• Absence de certification locale et de contrôle d'État : Les produits de chiffrement utilisés en Chine doivent souvent faire l'objet d'une déclaration ou d'une certification auprès de l'Administration nationale de la cryptographie (SCA). iCanText utilise des standards internationaux de chiffrement fort (AES-256, Curve25519) qui n'intègrent aucune "porte dérobée" et qui n'ont pas été soumis aux processus de certification locaux exigeant une transparence vis-à-vis des autorités de sécurité.
• Refus du "Key Escrow" (Séquestre de clés) : La législation chinoise suppose que l'État doit pouvoir accéder aux communications chiffrées pour des motifs de sécurité nationale. iCanText repose sur un chiffrement de bout-en-bout (E2EE) où les clés sont générées et stockées uniquement sur les terminaux des utilisateurs. L'éditeur ne disposant d'aucune "clé maître" ou serveur de séquestre, il est techniquement incapable de fournir les moyens de déchiffrement exigés par la loi.
• Incompatibilité avec les standards nationaux (Série SM) : La Chine promeut ses propres algorithmes nationaux (comme la série SM2, SM3, SM4). iCanText privilégie une sécurité mathématique universelle basée sur des protocoles ouverts et éprouvés mondialement, ce qui l'éloigne des exigences de souveraineté technologique imposées aux services opérant officiellement sur le territoire.