L'escroquerie par l'IA cible le niveau perceptif: voix, visage, aspects visuels du document, style rédactionnel. Les coûts des contrefaçons convaincantes se sont effondrés précisément aux niveaux où les gens décident si quelque chose est digne de confiance. Une voix clonée à partir de trois secondes de support audio, un visage deepfake dans un appel vidéo en direct, une facture reproduite à la perfection jusqu'à la mise en page avec un IBAN remplacé: ces attaques ont été documentées au cours des 18 derniers mois, dans le Mittelland suisse (arnaque au président à Schwyz en janvier 2026, plusieurs millions de francs de préjudice), dans des entreprises artisanales allemandes (entreprise de couverture en septembre 2025, près de 27 000 euros après la manipulation de l'IBAN) et dans des services du personnel dans toute l'Europe, où des opérateurs nord-coréens avec des identités synthétiques ont signé des contrats de travail. Si vous souhaitez lire le détail de ces affaires, vous les trouverez sur notre page d'aperçu relative à l'escroquerie par l'IA.

En tant que Trust Service Provider suisse, nous vous montrons ici comment vous pouvez répondre techniquement à de telles attaques – comment passer de «semble authentique» à «peut être vérifié cryptographiquement». Nous vous montrons comment fonctionne cette transition sur le plan architectural, contre quelles catégories d'attaques elle agit, où se situent ses limites et comment un service de signature peut être intégré à un environnement systèmes existant.

Dans ce contexte, nous ne prétendons pas que les signatures électroniques qualifiées (SEQ) ou les sceaux réglementés soient totalement à l'abri de l'IA. Ils protègent contre trois attaques spécifiques: celles portant sur l'intégrité d'un document, celles visant l'authenticité de l'émettrice ou l'émetteur ou de la personne signataire et celles liées au rattachement d'une signature ou d'un sceau à l'identité d'une personne ou d'une organisation.

Cet article s'adresse aux Security Officers, Application Architects et Enterprise Architects qui doivent déterminer comment une solution de signature s'intègre réellement à leur environnement et quels points d'ancrage réglementaires doivent être pris en compte. Il complète notre guide pratique pour les responsables fonctionnels, qui met en lumière les six cas d'application du point de vue des processus.

1. Le déplacement de couche: de la perception à la vérification

Avec l'IA, le niveau perceptif devient incertain. Les signatures cryptographiques et les sceaux font de la confiance une décision techniquement claire.

L'IA générative a considérablement réduit les coûts des falsifications convaincantes au niveau perceptif. Les voix pour un appel peuvent être reconstituées à partir de trois secondes d'audio. Les visages sont remplacés en direct pendant un appel vidéo. Les mises en page des documents sont parfaitement reproduites, souvent avec les polices de caractères spécifiques et les artefacts d'impression d'un modèle. Les styles d'écriture peuvent être imités à partir de quelques données d'entraînement. L'angle d'attaque qui s'est développé au cours des deux dernières années est précisément celui qui permet d'évaluer la fiabilité.

Les signatures cryptographiques et les sceaux n'agissent pas à ce niveau. Ils n'essaient pas de frapper le faussaire au niveau perceptif. Ils remplacent l'évaluation probabiliste d'une personne par une vérification technique déterministe: dans le cas des signatures et des sceaux électroniques, le contenu du document est associé à une identité par cryptographie asymétrique. Dans la deuxième partie de cet article, nous montrons en détail comment cela fonctionne. Mais commençons par les points que les pirates utilisant l'IA exploitent désormais ou plus largement qu'auparavant.

2. Cinq vecteurs d'attaque par l'IA et les points où la faille est comblée

Cinq catégories d'attaques concrètes découlant de l'état réel des menaces – quelle faille est exploitée, comment la SEQ ou le sceau y remédie et quelles sont les limites de chaque situation.

Vecteur 1: entretiens vidéo deepfake lors d'engagements

Attaque: un candidat avec une identité synthétique ou volée réussit l'entretien vidéo avec un deepfake en direct, télécharge un scan de pièce d'identité généré et soumet de faux diplômes et de fausses références. En 2025, Pindrop, un prestataire américain de détection des fraudes vocales, a repéré plus de 800 candidatures pour une seule mise au concours, dont plus d'un tiers était entièrement falsifié.

Faille: l'impression visuelle et conversationnelle ne suffit plus pour statuer sur l'identité. La reconnaissance humaine des deepfakes est plus ou moins due au hasard.

Résolution: l'émission d'une SEQ requiert un processus d'identification formel sur présentation d'une pièce d'identité officielle, avec des éléments de sécurité physiques ou basés sur la technologie NFC, mené par un Trust Service Provider certifié selon une procédure auditée. La signature sur le contrat de travail ne signifie donc plus «la personne avait l'air authentique dans la vidéo», mais «la personne a réussi l'identification qualifiée et détient une clé privée liée à cette identité vérifiée». Cet obstacle est nettement plus élevé que l'existence d'un entretien vidéo. En effet, quiconque veut falsifier le contrat ne peut plus se contenter de produire des résultats audiovisuels convaincants, mais doit s'attaquer à l'infrastructure de confiance elle-même: la procédure réglementée de vérification de l'identité et le contrôle exclusif de la clé privée de la personne signataire vérifiée.

Limites: la SEQ n'empêche pas les entretiens basés sur un deepfake, mais la conclusion effective d'un contrat par une personne non identifiée. La protection ne se situe donc pas au niveau de l'entretien, mais de la conclusion du contrat.

Vecteur 2: instructions «voice-cloned» ou comptes e-mail compromis

Attaque: un appel téléphonique avec voix clonée ou un compte e-mail piraté d'un partenaire commercial déclenche des modifications de contrats, de coordonnées bancaires ou d'adresses de livraison. L'arnaque au président de Schwyz en janvier 2026 est l'exemple suisse documenté: plusieurs millions de francs transférés en Asie, en réponse à des instructions formulées par une voix clonée au téléphone.

Faille: dans de nombreuses organisations, les instructions verbales ou par e-mail sont acceptées comme valant autorisation, bien qu'elles ne comportent pas de lien cryptographique avec une personne identifiée.

Résolution: la SEQ déporte l'autorisation du canal verbal ou de l'e-mail. Un appel téléphonique convaincant ne peut pas, à lui seul, générer de signature. La personne qui détient légitimement la clé doit suivre un processus d'authentification et d'activation de la signature auprès du Trust Service Provider. Dans les architectures avec SEQ à distance, cela comprend une authentification multi-facteurs associée à une confirmation de signature conforme à la norme SCAL2. La personne signataire autorise ainsi explicitement le processus de signature cryptographique spécifique, selon un processus réglementé qui garantit son contrôle exclusif. Seule la personne effectivement responsable d'une entreprise partenaire peut apposer cette signature.

Limites: si le processus en aval continue d'accepter des instructions verbales sans étape de signature, la SEQ est inutile. C'était précisément le point faible dans l'affaire de Schwyz: les virements sont intervenus en dehors d'un processus contractuel, directement sur la base d'instructions téléphoniques. L'architecture doit exiger la signature comme condition préalable ferme aux modifications de contrat, aux mandats de paiement et aux modifications de livraisons, faute de quoi la faille demeure.

Vecteur 3: factures manipulées par l'IA sur le canal de transmission

Attaque: une facture PDF est interceptée entre la personne émettrice et la personne destinataire. Un outil IA remplace l'IBAN, la mise en page est conservée à la perfection, la personne destinataire ne remarque rien. Dans l'affaire de l'entreprise de couverture de septembre 2025, les pirates avaient accédé à la messagerie électronique du propriétaire, manipulé l'IBAN dans le PDF et transmis la facture. Si le paiement a pu être évité, c'est uniquement grâce à une comptable attentive.

Faille: la personne destinataire ne peut pas déterminer visuellement si le PDF a été modifié après coup. Un IBAN modifié ressemble à l'IBAN d'origine.

Résolution: le sceau électronique réglementé de l'émettrice ou de l'émetteur relie le contenu du document à l'organisation émettrice via son hachage cryptographique. Chaque modification postérieure à l'apposition du sceau, y compris un chiffre modifié dans l'IBAN, modifie le hachage du document et invalide le sceau sur le plan cryptographique. L'outil de vérification de la personne destinataire, n'importe quel lecteur de PDF usuel ou le validateur gratuit de la Confédération, le signale automatiquement.

Limites: S/MIME protège le canal de messagerie, mais uniquement tant que l'e-mail reste dans le canal d'origine et qu'un échange de clés a eu lieu. Le sceau protège le document lui-même, quelle que soit la voie de transmission, y compris en cas de réexpédition ou d'impression multiple. Les deux mécanismes se complètent; aucun ne remplace complètement l'autre.

Vecteur 4: identités synthétiques lors de l'ouverture d'un compte et de la souscription d'une police

Attaque: les processus KYC sont contournés par des artefacts d'identité générés par l'IA ou volés qui semblent authentiques pour les contrôles automatisés. En 2024 et en 2025, une assurance maladie allemande pour animaux a documenté plusieurs cas dans lesquels des opérations sur des chiens avaient été simulées au moyen de radiographies générées par l'IA et de factures falsifiées, sur la base d'identités créées de manière purement mécanique.

Faille: le contrôle basé sur des images n'aide pas à lutter contre les contrefaçons de haute qualité. Une copie PDF d'une pièce d'identité peut être générée facilement.

Résolution: la SEQ empêche la fraude à l'identité synthétique, non pas au niveau des documents, mais au niveau de la constatation de l'identité. Avant qu'un certificat qualifié ne puisse être délivré, la personne à l'origine de la demande doit suivre un processus réglementé de vérification de l'identité auprès d'un Trust Service Provider, basé sur des documents d'identité officiels et des procédures de vérification auditées, si possible avec lecture biométrique de la puce. Elle peut être auditée selon une norme réglementaire définie, notamment la circulaire FINMA 2016/7, les exigences eIDAS et la norme ETSI TS 119 461. Les identités synthétiques ne franchissent pas cette étape, car elles ne peuvent pas fournir de document d'identité authentique.

Limites: des identités authentiques volées, associées à d'autres éléments d'attaque (pièce d'identité volée plus deepfake plus personne participant à la détection de vivacité), restent un risque résiduel. Mais l'obstacle est nettement plus difficile à franchir que celui des contrôles purement basés sur des images; l'e-ID suisse et l'EUDI Wallet renforceront encore cette protection à l'avenir.

Vecteur 5: certificats et diplômes falsifiés générés par l'IA

Attaque: un candidat présente un faux diplôme d'une université renommée. Visuellement, il est impossible à distinguer de l'original, car l'IA générative reproduit de manière convaincante la mise en page, le sceau, la signature et la texture du papier. Google Threat Intelligence a documenté des diplômes inventés d'universités européennes dans les programmes informatiques nord-coréens, qui ont été créés exactement de cette manière.

Faille: l'inspection visuelle d'un PDF ne permet pas de distinguer un faux de qualité généré par l'IA d'un document authentique. Prendre contact avec l'établissement émetteur ne permet pas d'évolution.

Résolution: le sceau électronique réglementé de l'établissement émetteur associe les éléments d'identification à l'identité juridique vérifiée de l'établissement. La vérification selon les points d'ancrage officiels, tels que la Trusted List de l'UE ou la Trusted List suisse, transforme le contrôle d'authenticité, qui passe d'une évaluation humaine subjective à un processus de vérification cryptographique déterministe.

Limites: quiconque ne contrôle pas les éléments d'identification n'est pas protégé. La protection ne fonctionne que si la vérification côté destinataire est intégrée au processus commercial. Un service RH qui ne passe les diplômes au crible que visuellement ne tire aucun bénéfice de diplômes munis d'un sceau. L'architecture de l'étape de vérification est donc tout aussi importante que le sceau lui-même.

3. Création d'une signature: le processus en cinq étapes

Une signature passe par cinq étapes, de la création du document à la vérification par la personne destinataire. Quiconque connaît la procédure peut argumenter clairement sur le point auquel un ancrage de confiance intervient et sur la manière de l'intégrer au mieux à l'architecture.

Le même principe s'applique par analogie aux sceaux, à la différence près qu'ils sont rattachés à l'identité d'une organisation, et non d'une personne physique.

Étape 0 (unique): identification de la personne signataire

Avant de pouvoir utiliser une SEQ, la personne doit s'identifier auprès du Trust Service Provider (TSP). Cette étape ne fait pas partie de chaque processus de signature, mais constitue un obstacle unique avant la première utilisation, comparable à une ouverture de compte. Le TSP contrôle la personne sur présentation d'une pièce d'identité officielle, généralement par identification vidéo, par identification automatique sur le smartphone (sur la base de la norme ETSI TS 119 461) ou prochainement à l'aide de l'e-ID suisse. La procédure fait l'objet d'un audit selon une norme réglementaire.

Seule une identité vérifiée au niveau requis permet l'émission d'un certificat qualifié qui rattache cette identité vérifiée à une clé privée dans le HSM du TSP. C'est précisément cette étape qui constitue le véritable levier contre l'escroquerie par l'IA: les identités synthétiques et les numérisations de cartes d'identité échouent ici. Quiconque déclenche la clé lors de l'opération de signature ultérieure est manifestement la personne dont l'identité a été vérifiée formellement et ponctuellement par le TSP.

Étape 1: création du document

Le document est créé dans le système source, par exemple une facture depuis l'ERP, un contrat depuis la gestion du cycle de vie des contrats ou un diplôme depuis le système de gestion de campus. À ce moment-là, le document est disponible sous forme de fichier non signé, généralement au format PDF, XML ou dans un autre format structuré. Le contenu est définitif, car toute modification ultérieure invaliderait une signature.

Remarque concernant l'architecture: le point de création du document est également le point naturel pour l'intégration de la signature ou du sceau. Plus la signature intervient concomitamment à la création, plus il est difficile de manipuler le document ultérieurement.

Étape 2: calcul du hachage

Un hachage cryptographique du document est calculé, typiquement SHA-256. Ce hachage est un résumé univoque du contenu. Si le document était modifié ne serait-ce que d'un seul chiffre, le hachage donnerait une valeur complètement différente.

Pour les services basés sur le cloud, le document est téléversé sur le portail de signature pour ce traitement, par exemple le service web de signature de SwissSign. Dans le cadre de la signature par hachage, en revanche, seul ce hachage est transmis au Trust Service Provider, et non le document lui-même. Le document reste ainsi sous le contrôle de l'organisation émettrice.

Étape 3: le Trust Service Provider signe le hachage avec la clé privée de la personne signataire

Chez le TSP, la clé privée de la personne signataire est conservée dans un module de sécurité matériel (HSM) certifié. Avant d'être validée pour l'opération de signature, la personne signataire doit s'authentifier avec une authentification multi-facteurs qui garantit le contrôle exclusif (sole control) sur la clé privée. Cette authentification s'appuie sur le résultat d'identification de l'étape 0: seule la personne vérifiée de façon unique peut déclencher la clé qui lui a été attribuée. C'est précisément ainsi que l'exigence légale du «contrôle exclusif» sur la clé est satisfaite.

Le hachage du document n'est signé qu'une fois l'authentification réussie. Le résultat est une valeur cryptographique (le «hachage signé») qui ne pouvait être générée qu'avec cette clé précise. En cas de signature qualifiée, un horodatage qualifié est également joint, qui établit de manière traçable l'heure de la signature. C'est cet horodatage qui est requis par le droit suisse pour que la SEQ soit assimilée à la signature manuscrite.

Étape 4: la signature est intégrée au document et émise

Le hachage signé est maintenant intégré au document avec le certificat de la personne signataire et les données d'horodatage, selon un profil ETSI standardisé (pour le PDF, il s'agit du PAdES gemäss ETSI EN 319 142, voir section 4).

Le document est maintenant signé et peut être émis, c'est-à-dire envoyé par e-mail, mis à disposition sur un portail, archivé ou distribué d'une autre manière. Important: la signature fait partie du document et voyage avec lui. Elle reste vérifiable même après plusieurs transferts, enregistrements ou affichages dans un lecteur de PDF.

Étape 5: la personne destinataire vérifie la signature

La personne destinataire ouvre le document dans un lecteur PDF ou un validateur spécial (par exemple le validateur gratuit de la Confédération). Le logiciel effectue automatiquement trois contrôles.

Premièrement, le contrôle d'intégrité. Le hachage du document actuel est recalculé et comparé au hachage dans la signature. Si les deux concordent, cela signifie que le document n'a pas été modifié depuis la signature. S'ils ne concordent pas, la signature est «brisée» et le lecteur affiche un avertissement clair.

Deuxièmement, le contrôle du certificat. Le certificat intégré est vérifié au moyen de la Trusted List officielle, c'est-à-dire la Trusted List européenne pour l'eIDAS ou la Trusted List suisse pour la SCSE. On s'assure ainsi que le certificat a bien été émis par un Trust Service Provider reconnu et qu'il était valable au moment de la signature.

Troisièmement, le contrôle de l'identité. Le lecteur indique qui a signé: dans le cas d'une SEQ, une personne physique avec un nom vérifié; dans le cas d'un sceau, une organisation avec une inscription vérifiée au registre du commerce ou dans un registre comparable. À ce stade, la boucle est bouclée avec l'étape 0: la personne destinataire peut être sûre que l'identité affichée a été formellement vérifiée par le TSP.

La vérification est binaire: soit les trois vérifications sont réussies, soit la signature n'est pas valable. Cela correspond à la transition que nous avons décrite à la section 1: de «semble authentique» à «vérifié selon une chaîne de confiance».

Ce que cela signifie pour la longévité

Une signature a une date d'expiration, car le certificat sous-jacent a une échéance, généralement de trois ans. Le profil PAdES-LTV doit être utilisé pour qu'un document puisse encore être vérifié dix ou vingt ans plus tard. Ce profil intègre directement au document toutes les données de validation nécessaires: le certificat, les listes de révocation valables au moment de la signature et les horodatages qualifiés. Ainsi, la vérification fonctionne même lorsque les services en ligne d'origine ne sont plus accessibles depuis longtemps. Pour l'archivage de longue durée, les audits et les litiges ultérieurs, c'est la condition préalable pour conserver des documents signés à valeur probante.

4. Cadre réglementaire pour les signatures et les sceaux

Cette liste est fournie à titre indicatif et n'est pas exhaustive. Elle couvre les normes qui apparaissent effectivement dans la plupart des discussions sur l'architecture et la conformité.

• eIDAS 2.0 (règlement UE 2024/1183): SEQ juridiquement équivalente à la signature manuscrite dans l'ensemble de l'UE. Nouvelles catégories de services de confiance, y compris Qualified Electronic Attestation of Attributes. Mandats EUDI Wallet pour les secteurs publics et réglementés jusqu'à fin 2026.

• SCSE (Suisse): SEQ équivalente à la signature manuscrite. Spécificité suisse importante: la SEQ suisse requiert un horodatage qualifié pour être considérée comme équivalente à la forme écrite, ce que l'eIDAS n'exige pas explicitement.

• Lacune entre les deux espaces juridiques: pas de reconnaissance mutuelle automatique entre la SEQ suisse et la SEQ européenne. Des négociations sont en cours. Les organisations qui opèrent à l'international entre la Suisse et l'UE doivent prévoir pour les deux espaces juridiques. SwissSign est certifiée Qualified Trust Service Provider pour les deux.

• Circulaire FINMA 2016/7: exigences en matière d'identification par vidéo et en ligne pour les intermédiaires financiers réglementés. La SEQ peut remplacer certaines étapes de vérification manuelles. Actuellement en révision partielle; l'audition s'est déroulée jusqu'au 27 février 2026 et intègre l'e-ID suisse comme nouveau moyen d'identification.

• Profils de signature ETSI: PAdES (ETSI EN 319 142) pour PDF, XAdES (ETSI EN 319 132) pour XML, CAdES (ETSI EN 319 122) pour les signatures binaires et indépendantes du format. Les profils de base B-B, B-T, B-LT, B-LTA couvrent différentes exigences de longévité.

5. Intégration: point d'attache effectif des services de signature

Trois modèles de déploiement

En principe, les Trust Service Providers ou les services de signature proposent trois modèles qui se distinguent par leur confidentialité et leur intégration: les services de signature basés sur le cloud, l'intégration à vos systèmes ou l'exploitation dans votre propre infrastructure.

SwissSign est le seul TSP suisse à proposer les trois modèles et à garantir pour tous le même niveau de souveraineté suisse. Le choix du modèle chez SwissSign s'effectue donc en fonction de la topologie de votre réseau, des exigences en matière de contrôle des données, des contraintes réglementaires et du modèle opérationnel.

• Service web: accès simple pour des utilisations ponctuelles ou de petite envergure, sans intégration. L'entreprise téléverse des PDF, le processus de signature est hébergé chez SwissSign. Plus de détails sur la page produit du service web.

• REST-API: le temps de déploiement le plus rapide, hébergé en Suisse. Par défaut, le traitement des documents s'effectue via l'API SwissSign. La signature par hachage est une fonctionnalité optionnelle pour les cas d'application avec des exigences de confidentialité strictes, pour lesquels les documents ne doivent pas franchir les limites de l'organisation. Plus de détails sur la page produit REST-API.

• On-Premises: le logiciel SwissSign fonctionne au sein de l'organisation et prend en charge le traitement des documents, le workflow, le branding et la connexion aux systèmes clients. La signature par hachage fait partie intégrante du processus: seul le hachage est transmis à l'infrastructure de confiance de SwissSign pour l'opération de signature, le document lui-même ne quitte jamais l'environnement client. Le gain de souveraineté réside dans le contrôle total des documents, des métadonnées, des workflows et des données d'audit. Pertinent en cas de localisation stricte des données, de segmentation du réseau ou de séparation des mandants. Plus de détails sur la page produit On-Premises.

Points d'intégration dans l'infrastructure existante

• ERP et processus clés: signature au moment de la création des documents, batch sealing pour des volumes d'output élevés, notamment factures, déclarations ou polices d'assurance. Intégration généralement via l'API du service de signature de la couche de génération de documents.

• Gestion documentaire et archives: les documents signés sont classés dans des archives conformes WORM. Le profil PAdES-LTV garantit la vérifiabilité pendant des décennies, sans dépendre de services en ligne.

• Identity and Access Management: authentification step-up via des Corporate IdP existants (SAML, OIDC), avec un deuxième facteur mobile en option. La signature est une étape dans le flux IAM et non un système parallèle.

• SIEM et journal d'audit: chaque opération de signature produit un événement auditable avec requête, authentification, utilisation des clés, horodatage et vérification. Ces événements sont intégrés aux pipelines SIEM existants via Syslog ou API.

• Applications mobiles et customer-facing: les flux de signatures sont intégrés dans des applications existantes via SDK ou via des flux redirect. Pertinent pour le banking, les assurances et les portails citoyens e-government.

Remarques spécifiques à la branche

• Core Banking (Avaloq, Temenos, Finnova, FNZ): intégration typiquement sur la couche de l'output documentaire. Analyse approfondie dans notre article consacré aux défis de la mise en œuvre dans les établissements financiers.

• Systèmes centraux d'assurance: intégration au moment de la génération de polices et du workflow de gestion des sinistres.

• Systèmes documentaires du secteur public: intégration avec des plateformes e-government existantes, souvent sous forme de services partagés au-delà des autorités cantonales ou communales.

6. Réflexions sur l'architecture de sécurité

Six thèmes qui seront examinés par un Security Officer.

• Orientation Zero Trust: mTLS entre les composants, authentification step-up de chaque opération de signature, Least Privilege Enforcement et microsegmentation de l'infrastructure de signature.

• Audit et sécurité des preuves: journaux incontestables pour la surveillance réglementaire et les expertises forensiques. Chaque opération de signature est traçable jusqu'à l'authentification de la personne signataire. Dans le cas du service On-Premises, les données d'audit de l'application arrivent dans l'infrastructure client, les opérations cryptographiques sont en outre consignées dans le protocole TSP.

• Disponibilité post-quantique: monitoring des normes post-quantiques NIST (FIPS 203 à 205). Il existe une voie de migration: le modèle architectural reste valable, seuls les algorithmes sous-jacents changent. En tant que TSP, SwissSign est responsable de la migration.

7. Utilisation de référence sur le marché suisse

PostFinance: API de signature par hachage pour les demandes de cartes de crédit

PostFinance, l'un des plus grands établissements financiers de Suisse avec près de 2,5 millions de clientes et clients privés et commerciaux, a intégré la signature électronique qualifiée de SwissSign dans son processus de demandes de cartes de crédit. L'architecture est basée sur l'API de signature par hachage: les documents ne quittent pas le système de PostFinance, seul le hachage cryptographique est transmis au service SwissSign. La solution de signature est reliée à Bankident PostFinance, de sorte que les clientes et clients existants peuvent signer numériquement une demande de carte de crédit de bout en bout, sans devoir s'identifier à nouveau.

«Nous voulions utiliser nos identités déjà vérifiées pour le processus de signature électronique. Pour nous, il était essentiel que la solution n'entraîne pas de charge de travail supplémentaire pour la clientèle du fait d'une nouvelle identification. La solution de signature de SwissSign nous a permis d'y parvenir sans effort et de mettre en place un processus plus rapide et plus confortable pour notre clientèle.» — Teodoro Pizzino, Customer Journey Owner Credit Cards chez PostFinance

• Modèle de déploiement: REST-API avec signature par hachage

• Composants du Trust Service: SEQ, rattachement d'identité via Bankident PostFinance

• Résultat commercial: processus de carte de crédit entièrement numérique, sans rupture de média, taux d'abandon réduit

Canton d'Argovie: plateforme Trust Service à l'échelle du canton

Début 2026, le canton d'Argovie a chargé SwissSign de mettre en place une solution centralisée pour les signatures électroniques, les sceaux réglementés et les horodatages qualifiés. L'appel d'offres s'est déroulé selon les conditions-cadres communes d'eOperations Suisse. La plateforme sera utilisable par l'administration du canton ainsi que par les communes rattachées. À l'avenir, les décisions ou les communications administratives pourront être revêtues d'un sceau électronique confirmant l'authenticité et l'intégrité. Les contrats ou les conventions seront directement signés dans le navigateur avec une SEQ, et des horodatages qualifiés garantiront de manière traçable l'heure de création ou de réception de documents dans les boîtes aux lettres électroniques et les archives.

• Modèle de déploiement: plateforme Trust Service centralisée pour le canton et les communes rattachées

• Composants du Trust Service: SEQ, sceaux réglementés, horodatages qualifiés

• Application: décisions, conventions, boîtes aux lettres électroniques, archivage de longue durée

egovpartner / canton de Zurich: solution standard pour les communes

Dans le cadre d'un appel d'offres centralisé lancé par egovpartner, SwissSign a été choisie en 2025 pour fournir une solution standard accessible à toutes les communes et villes du canton de Zurich. La signature électronique à valeur juridique peut ainsi être intégrée aux applications spécialisées existantes ou directement au navigateur, sans que chaque commune ne doive suivre son propre processus d'approvisionnement. Les domaines d'application vont des autorisations aux validations internes en passant par les contrats et les procès-verbaux.

• Modèle de déploiement: dépend du choix des différentes communes

• Composants du Trust Service: SEQ, sceaux réglementés en option

• Application: approvisionnement-cadre unique, activation individuelle par commune

8. Pourquoi est-ce le bon moment?

• Calendrier eIDAS 2.0: d'ici le 24 décembre 2026, tous les États membres de l'UE devront mettre à la disposition de leurs citoyennes et citoyens au moins un EUDI Wallet certifié. Un an plus tard, à partir de fin 2027, les secteurs réglementés tels que les banques, les télécommunications, la santé et les très grandes plateformes en ligne seront tenus d'accepter le portefeuille électronique comme méthode d'authentification si des utilisatrices ou des utilisateurs le présentent. L'utilisation du portefeuille électronique reste facultative pour les citoyennes et les citoyens. Les architectures prévues aujourd'hui devraient anticiper l'acceptation de l'EUDI Wallet afin de ne pas devoir rattraper leur retard en 2027.

• Mandats de facturation électronique: le projet ViDA de l'UE et le mandat de facturation électronique B2B allemand entrent progressivement en vigueur. Obligation de réception en Allemagne depuis le 1er janvier 2025, obligation d'envoi à partir du 1er janvier 2027 pour les entreprises ayant réalisé plus de 800 000 euros de chiffre d'affaires, à partir du 1er janvier 2028 pour tous les chiffres d'affaires B2B du pays. Important: l'obligation porte sur le format structuré (XRechnung, ZUGFeRD), pas sur le sceau. Cependant, rendre l'authenticité et l'intégrité effectivement démontrables nécessite un sceau en plus du respect du format. Les factures structurées et vérifiables deviennent ainsi un avantage concurrentiel.

• Déploiement de l'e-ID suisse: avec le déploiement attendu pour 2026, l'e-ID suisse réduit la friction lors de l'émission de la SEQ et dans les workflows pour la population. Les architectures d'ores et déjà planifiées devraient anticiper cette intégration afin de ne pas avoir à s'équiper après coup lors de l'activation de l'e-ID.

Foire aux questions

Cette publication reflète le point de vue de SwissSign et ne constitue pas un conseil juridique.