Les données d’un site créé avec une solution SaaS sont-elles vraiment sécurisées ? Commencez par vérifier leur propriété

Les données d’un site SaaS sont-elles réellement sécurisées ? Commencez par examiner leur propriété

Lors de l’évaluation technique d’une solution de création de site SaaS, de nombreuses équipes commencent par demander où se trouvent les serveurs, si des sauvegardes sont disponibles, si HTTPS est pris en charge et si les autorisations d’administration sont suffisantes. Ces éléments sont certes importants, mais ce qui détermine réellement si une entreprise peut conserver durablement le contrôle de ses actifs web est souvent une question plus fondamentale : à qui appartiennent les données ?

La « sécurité des données » est souvent comprise comme l’absence de perte ou de fuite. En réalité, elle doit également inclure un autre aspect : lorsqu’une entreprise change de prestataire, ajuste son orientation technique ou lorsque le prestataire d’origine cesse un service produit, peut-elle emporter l’intégralité de ses données métier de manière raisonnable et exploitable ? Pour les entreprises disposant de sites de commerce extérieur, de boutiques transfrontalières et menant des actions Google SEO à long terme, il ne s’agit pas d’un détail contractuel, mais d’une question liée à la continuité des noms de domaine, des contenus, des demandes de renseignements, des relations clients et des actifs de recherche.

À clarifier d’abord : la propriété des données ne signifie pas que la plateforme possède les serveurs

Dans le modèle SaaS, le prestataire est généralement responsable du fonctionnement du logiciel, de la maintenance de l’infrastructure, des mises à niveau de version et de l’exploitation de la sécurité ; l’entreprise saisit quant à elle dans le système les produits, articles, informations clients, commandes ou demandes de renseignements. La partie qui achète les serveurs et celle qui assure la maintenance du code ne déterminent pas la propriété des données métier. Un principe relativement clair est le suivant : les données métier soumises par l’entreprise elle-même, obtenues légalement ou générées dans le cadre de ses activités doivent rester sous le contrôle de l’entreprise ; la plateforme peut traiter ces données dans la mesure nécessaire à la fourniture du service, mais ne doit pas assimiler de manière ambiguë ce droit de traitement à un droit de propriété.

Dans les projets réels, il est facile d’ignorer que les « données » ne se limitent pas à une liste de contacts exportée depuis le back-office. Les actifs d’un site orienté marketing comprennent au minimum le texte des pages, les fichiers image et vidéo, les paramètres produits, les versions multilingues, les demandes issues des formulaires, les comptes utilisateurs, les informations de commande, les règles de redirection, les métadonnées SEO, les plans de site, les configurations de balisage, ainsi que les données de conversion générées par les canaux publicitaires et de réseaux sociaux associés. Lorsqu’une entreprise est exploitée depuis de nombreuses années, la structure des URL, les contenus historiques et les performances de recherche organique qu’ils ont accumulées sont souvent plus difficiles à migrer que le modèle de site lui-même.

Pour évaluer la sécurité, ne demandez pas seulement « peut-on exporter les données ? »

De nombreuses démonstrations commerciales répondent que « l’exportation de données est prise en charge », mais l’évaluation technique ne doit pas s’arrêter là. Exporter un fichier CSV et disposer d’une véritable capacité de migration sont deux choses très différentes. Par exemple, les produits peuvent permettre d’exporter le nom et le prix, mais pas les attributs, la hiérarchie des catégories, les relations entre variantes ou les adresses des images ; les articles peuvent permettre d’exporter le contenu, mais sans conserver les liens d’origine, les balises ni la date de publication ; les demandes de renseignements peuvent permettre d’exporter les contacts, mais sans la page source, les paramètres UTM ni le statut de suivi. Lors de la migration vers un nouveau système, toutes ces lacunes engendrent des coûts supplémentaires de nettoyage manuel et de reconstruction.

Une approche plus pratique consiste à demander au prestataire, avant l’achat, de présenter un véritable processus d’exportation : exporter depuis le back-office un lot de contenus, de produits et de demandes de renseignements, puis ouvrir aléatoirement les fichiers afin de vérifier les champs ; il convient également de confirmer comment récupérer les ressources statiques telles que les images. Si la plateforme fournit une API, il faut aussi clarifier si les autorisations d’interface, les limites d’appel et les frais sont inscrits dans les conditions de service. Une « prise en charge de la migration » non vérifiée ne constitue généralement qu’une description fonctionnelle et ne peut pas être considérée comme une mesure de maîtrise des risques.

Le mécanisme de sauvegarde résout la « perte », mais ne remplace pas la « maîtrise »

Le fait que la plateforme dispose de sauvegardes ne signifie pas que l’entreprise peut restaurer à tout moment ses propres données métier. L’évaluation technique doit aller plus loin : les sauvegardes couvrent-elles uniquement la base de données ou incluent-elles également les fichiers média ? Quelle est la durée de conservation ? Après une suppression accidentelle, est-il possible de restaurer par site et par point dans le temps ? Qui effectue la restauration, est-elle payante et existe-t-il un mécanisme de vérification avant la restauration dans l’environnement de production ? Pour les boutiques transfrontalières, il faut également confirmer que les commandes, les stocks et les statuts de paiement relèvent du même périmètre de sauvegarde cohérent.

Une autre erreur fréquente consiste à assimiler « hébergement dans le cloud » et « sécurité absolue ». Le prestataire SaaS est responsable de l’exploitation et de la maintenance au niveau de la plateforme, mais l’entreprise doit toujours gérer la sécurité de ses propres comptes, notamment les autorisations d’administrateur, la récupération des comptes des employés partis, la politique d’authentification à deux facteurs ainsi que les limites d’accès internes aux formulaires et aux données clients. En particulier, après l’intégration du site à des outils tiers de publicité, d’analyse, de service client ou d’e-mail marketing, les données circulent entre plusieurs systèmes. Les sauvegardes du prestataire ne peuvent pas couvrir les configurations, les audiences ou les créations publicitaires des comptes externes de l’entreprise.

Avec l’intégration site web et marketing, les limites des actifs doivent être définies plus précisément

L’avantage d’un service intégré site web + marketing est que la création du site, le SEO, les pages de destination publicitaires, l’acquisition via les réseaux sociaux et l’analyse des données peuvent être coordonnés plus rapidement ; mais c’est précisément pourquoi les limites entre comptes et données doivent être examinées séparément. Il est recommandé que le nom de domaine soit enregistré au nom de l’entreprise et que celle-ci conserve les droits de gestion ; pour les comptes de gestion des ressources de recherche, d’analyse du site, de diffusion publicitaire et de pages de réseaux sociaux, il est préférable que l’entreprise crée le compte principal puis accorde les autorisations nécessaires à l’équipe de service. Ainsi, même en cas de changement ultérieur de partenaire opérationnel, les données historiques et le contrôle des canaux restent entre les mains de l’entreprise.

Pour une plateforme telle que Yiyingbao, qui couvre la création de sites intelligents, les boutiques transfrontalières, le SEO, la publicité et l’exploitation des réseaux sociaux, l’entreprise ne doit pas seulement évaluer si ses fonctionnalités peuvent prendre en charge un site officiel multilingue, les demandes B2B ou une boutique B2C. Elle doit également cartographier les flux de données : vers quelle page les visiteurs arrivent-ils depuis la publicité ou la recherche organique, où vont les données des formulaires, comment les commerciaux les reçoivent-ils, sont-elles synchronisées avec le CRM, et comment préserver la continuité de la recherche lorsque les contenus et les URL sont modifiés ? Plus les capacités de la plateforme sont centralisées, plus il est utile de définir clairement les limites de responsabilité dès le départ.

Le contrat doit au minimum préciser ces points

Les équipes techniques concentrent souvent leur attention sur la documentation d’architecture, tandis que le service juridique s’intéresse aux clauses générales ; il en résulte que les modalités de sortie les plus importantes ne sont parfois examinées par personne en détail. Un contrat ou accord de service relativement sûr doit clairement définir le périmètre et la propriété des données de l’entreprise, les finalités pour lesquelles le prestataire peut traiter les données, la période d’exportation des données après la fin du service, les modalités d’exportation et les obligations d’assistance raisonnable, les règles de suppression ou de conservation, ainsi que les mécanismes de notification et de traitement en cas d’incident de sécurité.

Si l’activité cible différents marchés étrangers, les données personnelles, les enregistrements de consentement marketing et le traitement transfrontalier des données peuvent également être soumis à des exigences locales. Ces questions ne devraient pas être traitées de façon générale par une simple affirmation de « conformité aux réglementations étrangères » ; elles doivent être confirmées plus avant par le service juridique de l’entreprise ou par un conseiller professionnel, en fonction des types de données réellement collectées, du déploiement des serveurs, des outils tiers et des marchés cibles. L’équipe technique doit au minimum s’assurer que le système peut identifier les sources de données, contrôler les autorisations d’accès et fournir, lorsque nécessaire, des enregistrements traçables.

Ce qui mérite réellement d’être fait : un « petit exercice de sortie »

La sécurité des données d’un site SaaS ne se juge finalement pas sur les promesses figurant sur une page promotionnelle, mais sur la capacité réelle de l’entreprise à utiliser, exporter, sauvegarder et migrer durablement ses propres actifs. Pour un petit site venant d’être mis en ligne, le problème peut ne pas être évident ; mais lorsque le contenu atteint plusieurs centaines de pages, que plusieurs langues sont exploitées simultanément et que le trafic publicitaire et organique entrent ensemble dans le tunnel de conversion, découvrir trop tard que le nom de domaine, les comptes ou les URL ne sont pas sous contrôle peut entraîner des coûts d’ajustement élevés.

Avant la mise en ligne, il peut être utile de réaliser un petit exercice de sortie : exporter un lot de contenus et de demandes de renseignements réels, puis vérifier dans un environnement de test s’ils sont lisibles ; confirmer les administrateurs du nom de domaine, des comptes d’analyse et de publicité ; consigner les URL existantes et les règles de redirection ; préciser les contacts et le processus de passation après la fin du service. Une solution SaaS capable de passer cet ensemble de vérifications n’est pas nécessairement sans risque, mais ses risques sont au moins visibles, évaluables et plus facilement maîtrisables par l’entreprise.