Ne vous laissez jamais abuser par le mot Saas

Avec la révolution du Cloud, certains éditeurs de logiciels ont vite fait de renommer leur offre « SaaS » (Software as a service). Mais comme pour le cholestérol, il existe le bon SaaS et le mauvais, et l’adoption de services hébergés à l’ancienne est un poison pour le système d’information.

Les logiciels en mode SaaS, chouchou des métiers

Si vous choisissez un logiciel SaaS, il faut que vous puissiez créer le nombre d’environnements de travail dont vous avez besoin, que les données et les fonctions du logiciel soient accessibles via des API (interfaces d’accès) ouvertes, qu’aucun intégrateur ne soit obligatoire pour réaliser la mise en œuvre du produit et que vous puissiez utiliser vos propres clefs de chiffrement.  Des facilités qui sont indispensables.

L’objectif principal pour les métiers en adoptant une solution en mode SaaS est de bénéficier d’une solution complète déjà validée par d’autres, de ne pas requérir un investissement en Capex important et de réduire au minimum les risques de mise en œuvre de la solution.

Malheureusement, les métiers évaluent peu les critères technologiques d’intégration du logiciel en mode SaaS au système d’information. Ils se laissent souvent séduire par le marketing très bien rôdé des éditeurs. Pourquoi d’ailleurs regarder la partie technique, l’éditeur affirmant qu’il s’occupe de tout et que le client n’a rien à faire ? C’est du SaaS on vous dit.

Le SaaS doit être multi-tenant

Le critère principal de choix d’un logiciel SaaS concerne le caractère multi-tenant de la solution. En bon français : est-ce que le logiciel utilise une plateforme technique, logiciel et base de données, unique partagée entre tous les clients et est-elle capable de monter en puissance (« scalable »). Un exemple est la messagerie Gmail de Google ?

Ou bien s’agit-il d’une instance spécifique créée juste pour vous et hébergée à part ? Plus on utilise une solution proche de la version standard de l’éditeur, plus on bénéficie de l’effet de levier de la plateforme et on réduit les risques.

Néanmoins, les habitudes ont la vie dure et les informaticiens des DSI sont souvent les premiers à ne pas vouloir du mode multi-tenant. Ils estiment disposer d’un meilleur contrôle sur le logiciel et ses adaptations et mieux sécuriser leurs données.

Ils héritent donc d’un système hébergé et géré par un tiers, mais sur des ressources à part, isolées. En bref, ils ont les inconvénients d’un système interne, sans les avantages du Cloud. Car souvent, ces solutions ne sont pas « Cloud native » et sont hébergées sur des serveurs dans des centres de données standards. En cas de montée en charge rapide et imprévue, on a souvent des surprises.

De la spécialisation nait le risque

Dès qu’une solution non multi-tenante est choisie, on se retrouve extrêmement dépendant de l’éditeur qui peut imposer ce qu’il souhaite à chaque client. Très souvent, il imposera un « intégrateur », intermédiaire obligatoire (ce qui a un coût), qui devra créer et gérer les différents environnements. Parfois même, l’éditeur imposera des limitations inconcevables.

Un exemple est l’éditeur ADP, pourtant leader de la gestion de paie, qui n’offre qu’un environnement de production à certains de ses clients. Comment alors mener un projet normal lorsqu’on ne peut pas tester hors production ? Le fait de créer des plateformes spécifiques peut aussi engendrer des erreurs, lors de la promotion d’un environnement à un autre, ou lors des phases de développement.

Le logiciel SaaS doit offrir des APIs

Toute DSI (Direction des systèmes d’information) qui souhaite mettre en place un système d’information agile, dans un monde en pleine transformation digitale, doit imposer que le logiciel SaaS propose des APIs ouvertes et standards. Ces APIs doivent faciliter une intégration simple et rapide avec le logiciel en se basant sur les standards du moment, API REST et format JSON.

Il est extrêmement surprenant de voir qu’en 2017 il existe encore des logiciels qui n’offrent que de l’import/export fichier comme mode d’intégration avec des protocoles d’échange de type sFTP. Adopter ce type d’outil entraine une dette technique immédiate. Comment par exemple mettre en place un processus de gestion des employés et des partenaires de l’entreprise, si on ne peut avoir qu’un export fichier par mois, ou par jour, de son logiciel RH ? C’est aussi le cas de bon nombre de logiciels de gestion de trésorerie. Kyriba par exemple impose de créer des fichiers avec un nommage spécifique pour permettre leur intégration.

Ce que l’on gagne sur le prix des licences, on le perd en coût d’intégration et de conseil auprès des intégrateurs seuls habilités à paramétrer les imports/exports de données. Et si l’intégrateur n’a pas de ressources disponibles pour votre projet, alors vous serez bloqués. On mesure alors la différence avec un logiciel en mode SaaS qui propose des APIs ouvertes qui sont accessibles immédiatement sans aucun passage par un intégrateur obligatoire.

Le casse-tête des données

Tout éditeur de logiciel en mode SaaS devrait offrir une solution de chiffrement des données acceptant une clef de cryptage externe provenant du client, comme le préconise l’ANSSI (Agence Nationale de la Sécurité des systèmes d’information, voir Flash Ingérance Economique numéro 35 de Septembre 2017). Dans la réalité, c’est pourtant extrêmement rare. Lorsque l’on est sur des plateformes spécifiques créées en fonction de chaque client, on comprend pourtant bien que le risque d’erreur est plus important.