Quels sont les bonnes façons de garantir la continuité de l'activité avec un produit SaaS?

Question

Pour mon mémoire de licence, je fais des recherches sur la manière dont les fournisseurs de logiciels en tant que service (SaaS) peuvent mettre en place une sorte de garantie de continuité d'activité.

Vous connaissez probablement les arrangements de la consignation du code source pour les logiciels 'prêts à l'emploi'. Ils donnent aux clients l'accès au code source et à toute la documentation applicable chaque fois que le fournisseur de logiciels rencontre des problèmes (financiers). Cela ne fonctionne clairement pas pour les SaaS, car les clients n'ont pas besoin du seul code source, et ils ne peuvent probablement pas se permettre de ne pas pouvoir se connecter à leur système de CRM pendant quelques semaines parce que le fournisseur de SaaS fait faillite. Je suis actuellement en train d'étudier différentes méthodes pour résoudre ce problème.

Connaissez-vous de bonnes et pratiques solutions pour résoudre ce problème de continuité? Ou des entreprises qui offrent déjà une bonne solution?

Merci!

Answer 1

Je pense que vous devez distinguer deux cas :

1. Un fournisseur de SaaS fournit un service quasi-générique. Il est concevable que les données puissent être transférées à un fournisseur alternatif, et un fournisseur pourrait promettre de rendre les données disponibles sous une forme utilisable par ce fournisseur.
2. Un fournisseur de SaaS fournissant un service unique. Il n'y a pas de solution pratique autre que de créer votre propre centre de données. Au moment où vous aurez fait cela, vous pourriez ne plus être en activité.

La question que vous posez survient généralement dans le contexte d'une entreprise envisageant d'utiliser des services SaaS. Dans ces cas, une entreprise avisée (dans le cadre de son plan de continuité d'activité) doit (a) s'assurer de la viabilité financière du fournisseur (il est intéressant de noter que la plupart des personnes répondant à cette question voient cela comme le principal risque), et (b) s'assurer que le fournisseur dispose d'un plan de continuité d'activité adéquat qui garantira les services en cas de tous les risques majeurs. (Par exemple, si un centre de données est touché par un incendie et doit être temporairement fermé, existe-t-il une solution de secours? Est-il en veille active? Les données sont-elles dupliquées? Combien de données pourraient être perdues? Le trafic réseau peut-il être redirigé? etc.)

Bien sûr, le client doit également se préoccuper des problèmes de connectivité réseau : le fournisseur peut être en activité mais inaccessible. Et (dans les cas transfrontaliers), des risques politiques et réglementaires.

Les préoccupations pour un fournisseur de SaaS ne sont en fait pas si différentes de tout autre fournisseur de services ou produits critiques externalisés. (Si vous devez assembler des brides personnalisées et des passe-fils personnalisés pour produire des widgets, vous serez en difficulté si votre fournisseur ne peut pas vous fournir vos brides pour une raison quelconque.)

De manière intéressante, la préoccupation pour un fournisseur de SaaS avec quelques gros clients est la viabilité financière et la continuité d'activité de ses clients. L'échec d'un grand distributeur entraîne parfois l'échec de ses fournisseurs : non seulement les fournisseurs se retrouvent avec de grosses dettes non garanties, mais ils se retrouvent également sans une partie importante de leur chaîne de distribution.

Jan Husdal écrit un blog intéressant sur les questions de continuité d'activité de la chaîne d'approvisionnement, bien qu'il n'ait à ma connaissance pas abordé spécifiquement les problématiques liées au SaaS.

Un indicateur à surveiller pour l'avenir pourrait être l'exigence pour un fournisseur d'avoir un plan de continuité d'activité audité selon une norme reconnue (par exemple BS-25999). Il se peut que nous assistions à une propagation des normes de continuité d'activité de la même manière que les normes ISO-9000 se sont propagées à mesure que chaque entreprise repousse les exigences de certification à ses fournisseurs critiques.

Bonne chance pour votre mémoire. Vous avez choisi un sujet intéressant. Vous voudrez peut-être également poser votre question dans le groupe Disaster Recovery Journal sur LinkedIn. C'est la seule zone de discussion réellement active que j'ai trouvée sur les problématiques de continuité d'activité.

Answer 2

La disponibilité du service est toujours quelque chose à considérer lors de l'externalisation de quoi que ce soit, que ce soit le développement, la restauration ou l'hébergement (que feriez-vous si vous gérez une usine et que votre fournisseur de restauration fait faillite, laissant le restaurant de votre entreprise sans personnel?).

Dans le cas des logiciels, le dépôt de code est une étape pour garantir une perturbation minimale (même s'il y aura bien sûr toujours une certaine perturbation).

Avoir un contrat avec un fournisseur d'hébergement de secours où l'application est déployée en veille froide avec une synchronisation régulière de la base de données peut parfois être une option. Pour les applications qui nécessitent un temps de disponibilité élevé (ce qui semble être le cas ici puisque vous déclarez accepter même quelques jours d'arrêt), c'est de toute façon une nécessité. Après tout, le fournisseur SAAS pourrait ne pas faire faillite, mais si un avion s'écrase sur le bâtiment hébergeant leur ferme de serveurs, votre application sera également perturbée (j'ai travaillé pour un fournisseur SAAS, et nous avions nos propres fermes de serveurs de sauvegarde dans plusieurs endroits pour garantir la continuité du service, plus des sauvegardes régulières envoyées à un service de dépôt de code et envoyées au stockage dans un endroit sécurisé pour avoir des sauvegardes externes, aucune raison pour laquelle un client ne voudrait pas avoir sa propre sauvegarde à froid également, ou au moins une option de contrat pour reprendre le contrat d'hébergement en cas de perturbation du service due à la faillite du titulaire du contrat actuel).

Answer 3

En tant que petit fournisseur de logiciels en tant que service, nous sommes fréquemment interrogés sur cette question par des clients potentiels. Nous l'avons résolu en rendant notre produit open source. Ce n'est peut-être pas une option adaptée à tous, mais c'était la meilleure pour nous.

Answer 4

Eh bien, nous faisons du SaaS mais je ne suis pas sûr que la direction ait pensé à la continuité. Je crois que le plus souvent, un fournisseur de SaaS limite ses services et ses responsabilités par contrat afin de ne même pas avoir à y penser.

Comme solution possible : l'entreprise peut convenir par contrat de fournir un certain effort pour migrer les données vers un système logiciel alternatif choisi par le client en cas de fermeture de ses activités. À défaut de cela, il y a peu à espérer.

Comme option très brusque : donner la sauvegarde de la base de données au client qui pourra faire appel à des consultants ou en extraire des morceaux. Mais c'est plutôt un cas d'urgence.

Answer 5

Je suppose que vous pourriez toujours concevoir votre système de telle sorte que dans le cas où votre entreprise est sur le point de faire faillite, vous pourriez fournir aux clients suffisamment de logiciels côté serveur, de fichiers de configuration et de données pour qu'ils puissent héberger leur propre version de votre service. Essentiellement, leur donner/vendre une image de votre système à héberger (en interne ou en payant quelqu'un d'autre) suffisamment longtemps pour passer à un nouveau système. Si vous exécutez tous vos logiciels côté serveur à l'intérieur d'une machine virtuelle, cela peut rendre plus facile de (en essence) donner au client votre serveur. Vous pourriez même réussir à organiser le transfert de l'image de la machine virtuelle directement à un fournisseur d'hébergement tiers (et prépayer suffisamment de temps pour remplir le reste du contrat actuel du client) si votre entreprise est sur le point de fermer ses portes.