La crise est un accélérateur du SaaS, coûts maîtrisés et peu ou pas d’investissement étant un moteur puissant. A ces éléments habituels de choix, la dématérialisation en rend plus immédiatement sensible un troisième : le risque.
Dernièrement, le Syntec a publié un guide de contrat SaaS traitant de la performance du service, de sa disponibilité et sécurité. Précisons quelques aspects sur la sécurité des données.
Dans un contrat SaaS, il est tout particulièrement important de contractualiser la gestion du risque, tant au niveau du service attendu que des données de l’entreprise, et il est bon de travailler avec l’idée que le prestataire n’est plus seulement un fournisseur, mais un partenaire.
Les données confiées au prestataire ne lui appartenant pas, il ne peut en disposer ni même y accéder en dehors des actions indispensables d’exploitation. Dans certains cas, ces données n’appartiennent même pas au client du service, mais aux clients de ce client qui peuvent faire jouer les clauses légales de suppression d’informations personnelles par exemple : il faut donc s’assurer que cela est possible. En cas de malveillance, les responsabilités mutuelles du client et du prestataire doivent pouvoir être établies, les dommages estimés pour aboutir à une réparation éventuelle. Comme il s’agit d’une situation par nature conflictuelle, le processus doit être clairement spécifié a priori. Si les fournisseurs de SaaS s’engagent facilement et avec efficacité sur le contrôle des accès internes aux informations des clients, une récente affaire de violation de cette règle chez Google laisse à penser que l’aspect de réparation des préjudices n’est pas automatique.
D’autre part, en l’état actuel de la technologie, garantir qu’aucune donnée ne sera perdue en cas d’incident matériel ou de dysfonctionnement logiciel est impossible. Il faut donc spécifier le niveau de perte acceptable de données. Usuellement, les contrats standards proposent au plus 24 heures de traitement. Demander un niveau de perte inférieur se traduit par un coût qui peut être particulièrement élevé ou peut être une cause de renoncement au SaaS s’il n’est pas satisfait. Sur la problématique de la restauration en cas d’incident, le prestataire doit être en mesure non pas de prouver qu’il sait sauvegarder des données, mais qu’il sait restaurer un environnement complet et intègre (application et données). L’affaire T-Mobile Sidekick montre que l’opérateur SaaS doit être sans faille.
Enfin, le contrat doit défricher les cas de rupture de l’engagement, par faute, défaillance ou toute autre raison. Dans ces cas, l’entreprise doit avoir le temps de récupérer ses données et de les réinjecter dans un autre système d’information. Opération extrêmement complexe qu’il est souhaitable de garantir par une assurance. A défaut, le client devra mettre en place a minima une sauvegarde personnelle de ses données et inclure la défaillance d’un prestataire SaaS comme un sinistre dans son propre plan de reprise d’activité.
Beaucoup des risques évoqués rapidement ici ne sont pas nouveaux et ils existent dans le modèle informatique classique (« on premise »), certains évoluent (le risque de défaillance de mes équipes devient un risque de défaillance de mon prestataire) alors que d’autres deviennent plus sensibles même lorsqu’objectivement ils diminuent en mode SaaS (par le biais de la mutualisation, les équipes de production en SaaS sont plus rentables et il est plus facile de leur allouer les moyens nécessaires). Lorsque nous conseillons nos clients dans leur évolution stratégique, nous portons une très grande attention à l’équilibre Coût / Performance / Risque.
Philippe RIS,
fondateur d’@uris Solutions
