Lors du choix d’un prestataire de création de sites SaaS, vérifiez si les données peuvent être exportées

Si, avant la signature du contrat, il n’est pas possible de migrer intégralement et de manière exploitable les données du site et de marketing, la commodité apportée par la création de sites SaaS peut devenir une contrainte lors du renouvellement, d’un changement de fournisseur, d’une intégration après acquisition ou de la mise en place d’un système interne. Lors de l’évaluation d’un prestataire de création de sites SaaS, il ne suffit pas de confirmer qu’il « prend en charge l’exportation » : il faut également vérifier les objets exportés, la structure des données, les relations entre elles et le niveau de restauration possible après migration. Une fonction d’exportation permettant uniquement de télécharger des captures d’écran de pages, des tableaux ou des archives compressées est généralement insuffisante pour une migration réelle.

Il convient d’abord de définir clairement les limites de la propriété des données. Le titulaire de l’enregistrement du nom de domaine, le contrôle du DNS, les fichiers sources du site, le contenu des pages, les fichiers originaux des images et vidéos, les fiches produits, les demandes de renseignements clients, les commandes, les enregistrements de formulaires, les événements de tracking, les configurations des pages de destination publicitaires, les métadonnées SEO et les rapports analytiques peuvent être hébergés dans des comptes et systèmes différents. Le contrat doit préciser que l’entreprise détient le droit d’utiliser, de sauvegarder et de migrer ses propres données métier et actifs de contenu, et non un simple droit d’accès à l’interface d’administration. Si le nom de domaine est enregistré au nom du prestataire ou si le compte de résolution DNS ne peut pas être transféré, des interruptions d’accès et des risques liés à la résolution des e-mails peuvent survenir pendant la migration, même si le contenu peut être téléchargé.

Distinguer d’abord « fichier exporté » et « données migrables »

La migrabilité ne consiste pas simplement à exporter une base de données au format CSV. Pour un site axé sur le contenu, les articles, produits, documents téléchargeables et pages multilingues doivent au minimum conserver le titre, le corps du texte, le résumé, les catégories, les étiquettes, l’auteur, la date de publication, l’URL, le titre SEO, la description, les paramètres Canonical, les données structurées et les relations de référence aux médias. Si seul le texte principal est exporté, il faudra encore réintégrer les images, modifier les liens et compléter les métadonnées après l’importation dans le nouveau système ; les pages existantes issues de la recherche organique risquent alors de présenter des contenus manquants ou des changements d’adresse.

Pour une boutique transfrontalière, il convient également de vérifier si les SKU produits, les attributs de variantes, les stocks, les règles tarifaires, les comptes clients, les adresses de livraison, les statuts de commande, les enregistrements de remboursement, les configurations fiscales, les numéros de suivi logistique et les identifiants de transactions de paiement peuvent être exportés séparément. Les informations de cartes de paiement sont généralement soumises à des restrictions de conformité et de sécurité et ne peuvent pas nécessairement être migrées directement ; toutefois, les numéros de commande, montants, devises, détails des produits et statuts de paiement doivent pouvoir être conservés de manière vérifiable. Il faut distinguer ici les identifiants sensibles qui ne peuvent pas être migrés des enregistrements métier qui devraient être conservés mais ont été omis.

Les données de demandes de renseignements et de marketing sont plus facilement négligées. La définition des champs de formulaire, la source des prospects, les paramètres UTM, les versions des pages de destination, les pièces jointes, le statut de suivi, les enregistrements de consentement à l’abonnement par e-mail, les heures de déclenchement des événements et la configuration du retour de conversion publicitaire déterminent la possibilité de poursuivre l’attribution et le suivi. Si le prestataire ne fournit que le nom, l’e-mail et le téléphone des contacts, la source d’acquisition et le parcours de conversion d’origine seront interrompus, et les données historiques deviendront difficiles à utiliser pour le remarketing ou l’analyse rétrospective des canaux.

Le format d’exportation doit résister à une importation réelle

Lors de l’évaluation, il faut demander à consulter des fichiers d’exemple plutôt que de se fier uniquement à la description des fonctionnalités. Les données métier structurées devraient être fournies au format CSV, XLSX, JSON ou accessibles via API ; les fichiers médias tels que les images et documents doivent être conservés dans leur format d’origine, avec une liste indiquant le nom du fichier, le chemin, le type et l’objet associé. Si le contenu des pages est enregistré dans un modèle propriétaire ou un format binaire et ne peut plus être modifié hors du système d’origine, il faut confirmer s’il peut être exporté en HTML, Markdown, JSON ou dans un autre format ouvert et analysable.

L’encodage, le fuseau horaire, la langue et les identifiants uniques doivent également être vérifiés. Les caractères chinois, arabes, russes et autres ne doivent pas être altérés après l’exportation ; les pages multilingues doivent conserver leurs codes de langue et leurs relations de traduction ; les dates doivent indiquer le fuseau horaire utilisé ; les enregistrements de produits, commandes, contenus et clients doivent disposer d’ID stables afin d’éviter les créations en double ou les pertes de relations lors de l’importation. Pour les URL d’images, il faut aussi vérifier si elles restent accessibles après téléchargement ou si elles dépendent d’adresses à signature temporaire du site d’origine.

L’existence d’une API ne signifie pas que la migration est réalisable. Il faut vérifier si l’interface couvre tous les objets, si elle prend en charge la pagination, la lecture incrémentielle, le filtrage des enregistrements historiques et les téléchargements par lots ; les règles de limitation de débit, les frais d’utilisation, le périmètre des autorisations et la durée de disponibilité de l’interface après la résiliation du contrat influent également sur la fenêtre de migration. Une interface de lecture sans téléchargement des médias, dictionnaire de champs ni explication des relations augmente encore les coûts de nettoyage des données.

Risques de publication du site pendant la migration

La migration de contenu comprend généralement plusieurs étapes : exportation de l’ancien site, mappage vers le nouveau site, validation avant publication, basculement DNS et conservation de l’ancien site. Si les URL des pages d’origine changent, il doit être possible de générer un mappage complet entre les anciennes et nouvelles adresses et de configurer des redirections 301 sur le nouveau site. Ne migrez pas uniquement les pages les mieux classées : les pages produits de longue date, les pages régionales, les adresses de téléchargement PDF et les pages de destination dédiées à la publicité peuvent toutes recevoir des liens externes ou du trafic publicitaire.

Les formulaires, codes analytiques, pixels publicitaires, mécanismes de consentement aux cookies, notifications par e-mail et Webhooks CRM doivent être testés un par un avant le basculement. L’environnement de test ne doit pas envoyer de notifications réelles directement aux clients ou aux systèmes commerciaux ; il est possible d’utiliser des e-mails de test, des prospects de test et des adresses de rappel isolées. Après le basculement, il faut vérifier les codes d’état des pages clés, les titres de page, les paramètres robots, le plan du site, les balises Canonical et les résultats d’envoi des formulaires, afin d’éviter des fluctuations d’indexation causées par un paramètre noindex erroné ou des redirections incorrectes.

Les sites fréquemment mis à jour ne devraient pas être « gelés puis déplacés » en une seule fois. Il est possible de réaliser d’abord une exportation complète et le mappage des champs, puis d’exporter avant la mise en ligne les contenus incrémentiels, les dernières commandes ou les nouvelles demandes de renseignements. Le périmètre incrémentiel doit être confirmé à la fois selon la date de création et la date de mise à jour, afin d’éviter d’omettre les anciens contenus modifiés. La durée de conservation de l’ancien site, la poursuite éventuelle de sa facturation et la date d’expiration des ressources médias doivent également être clairement définies dans le plan de migration.

Formuler la capacité de migration sous forme de clauses contractuelles vérifiables

Lors de la phase d’achat, les exigences de migration doivent être transformées en conditions de livraison exécutables, au lieu de se limiter à des formulations telles que « prise en charge de la sauvegarde des données ». Il est possible de convenir du canal de demande d’exportation, du délai de traitement, du support de livraison, du format de fichier, de la description des champs et du périmètre d’assistance en cas de résiliation du service, de désactivation du compte ou de litige. Si la migration entraîne des frais supplémentaires, la base de facturation doit être définie à l’avance afin d’éviter de perdre toute marge de négociation lors d’un basculement urgent des activités.

• Exiger la réalisation d’une exportation à petite échelle pendant la période d’essai ou de réception : sélectionner des pages contenant des images, du contenu multilingue, des pièces jointes de formulaires et des champs SEO, afin de vérifier que les fichiers peuvent être ouverts et importés de manière indépendante.
• Conserver le dictionnaire de champs, la documentation API, les instructions de configuration des modèles et les règles de redirection. Sans ces documents, les données exportées ne peuvent souvent être réorganisées que manuellement.
• Définir clairement la période de conservation des données après la fin du service, le mécanisme de suppression et la capacité de restauration des sauvegardes, notamment le périmètre de conservation des demandes de renseignements, commandes et journaux d’accès.
• Pour les données hébergées par des outils tiers, tels que les e-mails, les paiements, la publicité et les enregistrements de service client, confirmer séparément la propriété du compte et le chemin d’exportation ; il ne faut pas supposer que le prestataire de création de sites peut assurer une livraison unifiée.

L’évaluation finale doit reposer sur un exercice de migration reproductible : les données obtenues depuis l’interface d’administration peuvent-elles être lues, vérifiées et importées sans dépendre de l’environnement d’exécution propriétaire du prestataire d’origine, et permettent-elles de restaurer les pages clés, les enregistrements métier et les parcours marketing ? Ce n’est qu’à cette condition que la migration des données n’est pas un argument promotionnel, mais une capacité système vérifiable.