Vérifier les références et certificats des fournisseurs SaaS : sources publiques

Ce qui peut être vérifié publiquement concernant les références et les certificats

Les sources publiques et indépendantes des fournisseurs pour les preuves SaaS sont le registre des certificats de l'organisme émetteur, les vérifications de signature, les avis d'adjudication, le droit suisse (LPD, OCPD) et la connexion eIAM. Chacune de ces sources atteste d'éléments différents.

Un label ISO 27001, des logos de clients et la mention « certifié » sur la page marketing sont des autodéclarations. Elles ne deviennent vérifiables que par l'intermédiaire d'un tiers indépendant du fournisseur. Il peut s'agir du répertoire de l'organisme de certification émetteur, d'une clé publique pour la vérification de signature ou de l'avis d'adjudication de l'autorité adjudicatrice. La vérification ne se fait donc pas en interrogeant le fournisseur, mais en contrôlant ses déclarations auprès de tiers.

Quatre catégories de preuves sont accessibles au public, et chacune atteste d'éléments distincts. Une inscription au registre de l'organisme de certification atteste l'existence, le titulaire, le champ d'application et la durée de validité d'un certificat. Elle n'atteste pas que ce champ d'application couvre la prestation SaaS concrètement souscrite. Une signature atteste qu'un document provient inchangé du détenteur d'une clé spécifique – pas que le contenu est correct.

Une clé publique située à une adresse fixe sur le domaine du fournisseur atteste qui est autorisé à émettre des documents. Elle rend la vérification indépendante de la collaboration du fournisseur. Un avis d'adjudication atteste qui a obtenu un marché public et quand – pas comment le projet s'est déroulé.

Pour les achats, cela signifie : définir pour chaque preuve ce qui est exigé et où la vérification autonome est effectuée. Exiger du fournisseur le numéro de certificat et l'organisme émetteur plutôt qu'une copie PDF. Exiger l'emplacement de stockage de la clé publique ainsi que son empreinte digitale plutôt qu'un rapport en pièce jointe d'e-mail. Pour les projets de référence, exiger l'autorité adjudicatrice et la date d'adjudication afin que l'avis puisse être recherché soi-même.

Il convient de régler contractuellement la mise à jour : les certificats doivent être renouvelés sans interruption, et les nouvelles versions des rapports doivent être livrées avec signature.

En Suisse, les sources accessibles au public sont la notice eIAM (version 1.7 du 9 octobre 2024), l'Ordonnance sur les certifications en matière de protection des données (OCPD) ainsi que la norme W3C DID:web pour les identifiants des émetteurs. Ces sources sont consultables sans la collaboration du fournisseur.

La LPD du 25 septembre 2020 est consultable publiquement sur Fedlex. L'OCPD la complète. Ces deux actes peuvent être vérifiés sans la collaboration d'un fournisseur.

Des exemples concrets peuvent être vérifiés ainsi. QSearch livre ses rapports de sécurité signés PGP et est enregistré en Suisse. Priverion exploite une plateforme ISMS hébergée en Suisse pour ISO 27001:2022. Dans le modèle de contrôle pour le Passeport numérique de produit décrit par Transpareo, chaque fabricant publie son identifiant d'émetteur sur son propre domaine, selon la norme W3C DID:web.

Qui souhaite vérifier cherche l'inscription au registre, la signature et l'avis d'adjudication. Si l'une de ces traces manque, la déclaration reste une autodéclaration.

Sources de vérification publiques pour les fournisseurs SaaS en Suisse

Contrevérifier les certificats dans le registre de l'organisme de certification

Un certificat ISO 27001 n'est pas délivré par l'organisation auditée. Un organisme de certification accrédité réalise un audit externe et vérifie si le système de management de la sécurité de l'information (SMSI) répond aux exigences de la norme. L'émetteur et le titulaire du certificat sont deux parties distinctes ; l'organisme émetteur tient son propre répertoire de certificats. C'est là que s'effectue la contrevérification, pas sur le site du fournisseur.

L'organisme de certification émetteur doit être accrédité pour la norme. Une inscription au registre sans accréditation traçable ne constitue pas une preuve solide. Vérifiez l'accréditation avant d'accepter l'inscription comme preuve.

Six mentions doivent être reprises du certificat : la dénomination juridique de l'entreprise certifiée plutôt que la désignation du produit ou de la marque, le numéro de certificat, la norme avec l'année de publication (par exemple ISO/IEC 27001:2022), l'organisme de certification émetteur, la durée de validité et le champ d'application formulé mot pour mot. Le champ d'application détermine l'utilité : il nomme les sites, les unités commerciales et les activités qui ont été audités.

Les certificats de groupe couvrent rarement chaque filiale et chaque service. Un certificat pour le développement et l'exploitation ne signifie pas automatiquement que le centre de données pertinent pour vous ou les sous-traitants utilisés y sont inclus.

Outre le champ d'application, le cycle d'audit doit être vérifié. Les certificats ont une durée de validité et sont accompagnés durant cette période par des audits de surveillance récurrents ; un audit de renouvellement a lieu avant l'échéance. Demandez la date et le type du dernier audit et comparez-les avec la durée de validité. Si un certificat expire dans quelques mois et que la preuve du renouvellement fait défaut, l'affirmation « certifié » n'est aussi solide que le papier lui-même.

Le temps nécessaire jusqu'à la certification est un indicateur de plausibilité. Le fournisseur suisse de SMSI Priverion indique généralement 6 à 12 mois pour une certification selon ISO 27001:2022, selon le degré de maturité du SMSI. Cela permet de situer la période entre l'audit et la délivrance du certificat.

Qui souhaite contrevérifier un certificat cherche l'inscription dans le répertoire de l'organisme émetteur. Si l'inscription ou l'accréditation fait défaut, la preuve fait défaut.

Situer les certifications de protection des données selon le droit suisse

Depuis le 1er septembre 2023, la Loi fédérale sur la protection des données (LPD) révisée ainsi que les nouvelles dispositions d'exécution dans l'Ordonnance sur la protection des données (OPD) et l'Ordonnance sur les certifications en matière de protection des données (OCPD) sont en vigueur. Aucun délai transitoire n'est prévu.

La LPD révisée protège la personnalité et les droits fondamentaux des personnes physiques qui se trouvent en Suisse, dont les données sont traitées par des privés ou l'État ; les données des personnes morales ne sont plus protégées. Pour l'achat de SaaS, cela signifie : une certification en matière de protection des données concerne les données personnelles des personnes physiques – les données d'entreprise que le même service traite également n'en font pas partie.

Les données personnelles sont toutes les indications qui se rapportent à une personne physique déterminée ou déterminable (art. 5 let. a LPD). Le traitement est toute opération ayant trait à des données personnelles, quels que soient les moyens et procédés appliqués (art. 5 let. b LPD). La LPD présente une grande proximité matérielle avec le Règlement général sur la protection des données (RGPD).

L'OCPD constitue le cadre pour les certifications en matière de protection des données selon la LPD. Comme pour tout certificat, on peut vérifier l'organisme émetteur, son autorisation pour le domaine concerné, l'objet décrit dans le certificat – quels traitements et quelles parties de l'organisation ont été examinés – ainsi que la durée de validité. Exigez le certificat et la désignation de l'organisme certificateur et insistez pour pouvoir consulter vous-même l'inscription.

Une certification du fournisseur ne remplace pas l'examen de sa propre responsabilité. Qui, en tant que responsable du traitement, externalise des données personnelles auprès d'un fournisseur SaaS, reste responsable du traitement envers les personnes concernées ; ce sont les processus du fournisseur qui sont certifiés, pas l'utilisation du service par vous.

Par conséquent, l'achat comprend également des clarifications propres : quelles données personnelles entrent dans le service et dans quelle mesure, quel traitement sur mandat est convenu, où les données sont traitées et stockées. Il faut aussi clarifier comment les données sont récupérées et supprimées à la fin du contrat.

La LPD en vigueur date du 25 septembre 2020 et est consultable publiquement sur Fedlex, le site du droit fédéral. L'Ordonnance sur les certifications en matière de protection des données (OCPD) la complète. Ces deux actes peuvent être vérifiés sans la collaboration d'un fournisseur.

Qui souhaite vérifier une certification en matière de protection des données selon l'OCPD cherche l'organisme émetteur, l'autorisation, l'objet et la durée de validité. Si l'autorisation fait défaut, le certificat reste non étayé.

Cadres juridiques pertinents en Suisse

Vérifier soi-même les rapports signés et les clés publiques

Les rapports de sécurité, les rapports de tests d'intrusion et les documents d'audit devraient être exigés sous forme de fichiers signés, et non comme une simple pièce jointe PDF. Le fournisseur suisse QSearch livre ses rapports de sécurité signés PGP. Si la signature est valide, le fichier est inchangé depuis son émission et provient du détenteur de la clé privée correspondante. La signature permet une contre-vérification sans devoir recontacter l'expéditeur.

Le modèle de contrôle décrit par Transpareo pour le Passeport numérique de produit peut être directement transposé : le fabricant publie son identifiant ou sa clé publique sur son propre domaine à une adresse fixe (selon la norme W3C DID:web). La vérification s'effectue dans le navigateur de l'utilisateur et ne contacte aucun serveur du fournisseur. L'application d'affichage est open source, permettant la lecture du code de vérification. La clé privée reste chez le fabricant ; Transpareo ajoute seulement sa propre contre-signature.

Pour les achats, cela signifie : exigez l'adresse du dépôt de clés et vérifiez vous-même un fichier livré.

Volontairement pas de chaîne de certificats classique : les chaînes de certificats expirent sur des décennies, tandis qu'une adresse sur son propre domaine reste robuste. Qui conserve des preuves qui doivent rester vérifiables même après longtemps mise donc sur des adresses de clés durablement accessibles et non sur une chaîne dont la racine peut avoir expiré entre-temps. Si la signature ne repose pas comme un bloc sur le document, mais sur chaque indication individuelle, les champs ajoutés ultérieurement restent également prouvables sans qu'une nouvelle signature soit nécessaire.

Il convient de régler contractuellement le lieu de publication de la clé publique et de l'empreinte digitale ainsi que l'obligation de livraison signée de chaque rapport. Il faut également réglementer la conservation de la clé et du rapport dans vos propres archives, car une signature ne reste vérifiable que tant que la clé est retrouvable.

L'application d'affichage open source pour ce modèle de contrôle s'appelle Transpareo Time Machine. Elle charge le passeport, recalcule son empreinte digitale et vérifie les deux signatures sans contacter un serveur du fournisseur. Les sceptiques peuvent lire le code.

Qui souhaite vérifier une signature cherche l'adresse fixe de la clé sur le domaine du fournisseur et l'empreinte digitale. Si l'adresse fait défaut, le rapport reste non vérifié.

Reconstituer les références à partir des données publiques d'adjudication

Les références peuvent être retracées via les informations publiques d'adjudication, car les attributions et les contrats-cadres sont publiés. L'approche méthodique utilise simultanément trois horizons temporels : le passé (qui est le leader du marché ?), le présent (quels appels d'offres correspondent aujourd'hui ?) et l'avenir (quels contrats-cadres arrivent bientôt à échéance ?). Pour la vérification des fournisseurs, cela signifie : rechercher les avis d'adjudication avec le nom du fournisseur et enregistrer l'autorité adjudicatrice, l'objet, la date et la durée. Ne vous fiez pas à la liste de références dans la présentation.

En Allemagne, l'Office central des achats IT (ZIB) au sein de l'Office fédéral des achats gère un volume annuel de contrats-cadres IT d'environ 4 milliards d'euros. En Autriche et dans l'UE, il y a plus de 16'000 autorités publiques adjudicatrices dans le domaine IT.

Pour le timing, il vaut la peine de regarder les cadres contractuels : en Allemagne s'appliquent les contrats-cadres EVB-IT, en Autriche les AVB-IT et en Suisse les CG Informatique avec leurs cycles de quatre ans. Ces durées sont un instrument de timing. Qui sait quand un contrat-cadre expire sait aussi quand un fournisseur est à nouveau en concurrence. On peut alors comparer à nouveau les références et les conditions.

Un contrat cloud EVB-IT exige une preuve de la protection de base BSI. Qui connaît de telles exigences peut vérifier les références plus cibléement. Le verrouillage fournisseur (Vendor Lock-in) peut ainsi être détecté plus tôt.

Un titulaire récurrent est la référence la plus significative et le signal d'avertissement le plus clair à la fois. Un fournisseur présent chez l'autorité adjudicatrice depuis quatre ans connaît l'infrastructure et a déjà intégré son système ; qui propose une offre neuve part de zéro. L'ordre des attributions et les durées des contrats-cadres permettent donc de lire où existent des dépendances. On voit également depuis combien de temps une autorité adjudicatrice est liée et quand le marché s'ouvre pour une nouvelle attribution.

Le paysage des portails dans l'espace DACH est fragmenté. Rien qu'en Autriche, des centaines de procédures IT pertinentes paraissent chaque année, avec la plus forte densité à Vienne. Une recherche par mot-clé comme « IT » ou « logiciel » fournit des milliers de résultats et masque justement les grands projets.

Qui souhaite vérifier une référence cherche l'avis d'adjudication avec le nom du fournisseur, l'autorité adjudicatrice, l'objet, la date et la durée. Si l'avis fait défaut, la référence reste une affirmation.

Vérifier les preuves de connexion et d'interopérabilité dans l'environnement fédéral

Les fournisseurs SaaS actifs dans l'environnement fédéral doivent prouver leur connexion eIAM. Cette preuve est vérifiable publiquement. La base est la notice eIAM « Connexion d'applications à eIAM ».

eIAM est le système central d'accès et d'autorisation de la Confédération. AGOV est une composante inhérente d'eIAM et occupe une position particulière ; CH-LOGIN est en phase de suppression. La notice pour les achats « Connexion d'applications à eIAM » (version 1.7 du 9 octobre 2024) est consultable publiquement. Elle sert de base pour les questions de connexion et doit être lue dans la version actuelle au moment de l'achat.

eIAM, y compris AGOV, authentifie les personnes physiques, pas les personnes morales. Cette distinction est à prendre en compte lors de la vérification des références et des certificats, car les preuves de protection des données se rapportent aux personnes physiques.

Selon cette notice, les applications web et les applications mobiles natives sont soumises à l'obligation de recours à eIAM. La connexion peut être directe ou indirecte ; plusieurs variantes de connexion indirecte existent. La notice distingue également les cas où les services du DFJP doivent être utilisés de ceux où le service eIAM est utilisé. Avant d'accepter une promesse d'interopérabilité, faites désigner par écrit la variante de connexion choisie et la voie prévue. Vérifiez l'obligation de recours par rapport à la notice.

Cela est vérifiable sans la collaboration du fournisseur : la notice est disponible publiquement, tout comme les informations sur eIAM, AGOV et les fournisseurs d'identité, auprès desquels eIAM obtient les identités électroniques. Les questions au fournisseur portent donc sur des éléments prouvables – quelle variante de connexion, sur la base de quelle version de la notice, coordonnée avec quelle instance. Les assurances générales d'interopérabilité ne suffisent pas.

Dans le système central eIAM incl. AGOV, aucune IA n'est actuellement utilisée. Cette indication de transparence est consultable publiquement.

La notice est publiée publiquement sur le site web eIAM de la Confédération. Les fournisseurs d'identité sont la source des identités électroniques pour eIAM. Le passage de CH-LOGIN conduit à AGOV et FED-LOGIN. La fédération d'Entra avec eIAM est également documentée publiquement.

Qui souhaite vérifier une preuve de connexion cherche la variante de connexion choisie et la version de la notice. Si l'indication fait défaut, la promesse d'interopérabilité reste générale.

Signaux d'alarme et limites de la vérification publique

Les signaux d'alarme résultent directement des sources publiques : un label sans inscription au registre trouvable ; un certificat dont le champ d'application ne couvre pas la prestation exploitée, le site ou les sous-traitants. D'autres signaux d'alarme sont un certificat expiré sans preuve de renouvellement ; des clients de référence nommés sans avis d'adjudication et sans date ; un rapport de sécurité en PDF sans signature.

Les questions qui en découlent s'adressent directement au fournisseur : numéro de certificat, organisme émetteur, champ d'application formulé mot pour mot, durée de validité, date et type du dernier audit. Il faut également demander l'adresse et l'empreinte digitale de la clé publique ainsi que l'engagement de livrer chaque rapport signé. Pour chaque référence nommée, l'autorité adjudicatrice, l'objet du mandat et la date doivent être indiqués ; pour la connexion, la variante de connexion eIAM choisie avec la version de la notice. Qui n'obtient aucune de ces indications a déjà une réponse.

Les limites de la vérification publique sont tout aussi claires : seul ce qu'une tierce partie publie est traçable. Les constatations internes d'audit, la liste des sous-traitants, l'historique des incidents et l'état actuel d'une instance productive ne peuvent pas être vérifiés ainsi ; cela nécessite des informations et des droits de contrôle sécurisés contractuellement. Un certificat atteste un système de management fonctionnel, pas la sécurité d'une configuration spécifique en exploitation.

Ce qui n'est pas trouvable publiquement manque comme preuve. Inscription au registre, signature et avis d'adjudication sont les traces solides.

Avantages et limites de la vérification publique des preuves SaaS