Patterns d’Architecture logicielle pour le SaaS

1. Les différents niveaux de maturité

En sécurité informatique, AAA correspond à un protocole qui réalise trois fonctions : l’authentification, l’autorisation et la traçabilité (Authentication, Authorization, Accounting/Auditing en anglais). Le premier A est évidemment fondamental ; il est à noter qu’il faut faire une nuance entre l’identification qui permet de connaître l’utilisateur et l’authentification (connaître l’utilisateur et vérifier, en général via un mot de passe, que c’est bien lui). Les utilisateurs peuvent être des utilisateurs "humains" ou des machines, notamment dans des architectures distribuées par exemple en SOA (Service Oriented Architecture) ou en Microservices.

Nous pouvons constater différents niveaux de maturité dans les applications de gestion. L’âge de pierre serait celui où le login / mot de passe est géré dans chaque application, ce qui oblige l’utilisateur à devoir pour chacune, non seulement retaper son mot de passe, mais également le gérer (renouvellement, avoir un mot de passe différent par application). L’âge de bronze est celui de la gestion d’un login ou d’un mot de passe dans un espace centralisé par exemple sous forme d’annuaire LDAP ou d’un annuaire Microsoft (Active Directory). 

Dans ce niveau de maturité, l’utilisateur doit toujours saisir son mot de passe, mais celui-ci est commun entre plusieurs applications et la gestion est facilitée. En outre, en cas de départ d’un salarié, il suffit de supprimer le compte de l’annuaire et non pas le compte dans chacune des applications. À l’âge de fer, l’utilisation du Single Sign-On que nous allons détailler ici est un Must-Have pour toute application SaaS, permettant à l’utilisateur de ne pas saisir systématiquement, à chaque nouvelle connexion à une application, son mot de passe. Enfin, des améliorations sont largement possibles pour qu’il n’y ait pas que le mot de passe qui soit centralisé, mais également toutes les informations redondantes qu’on trouve classiquement dans toutes les applications...

1. Un peu d’histoire - Les SDKS

Dans les années 90, la plupart des ERP ou des gros logiciels professionnels (Microsoft Office, Autocad, SolidWorks…) proposaient un SDK et ceux-ci utilisaient souvent les technologies OLE/COM renommé ActiveX lorsqu’il s’agissait des composants pour les navigateurs. COM a ensuite évolué ensuite vers un modèle distribué appelé DCOM. Ces technologies propriétaires de Microsoft avaient un énorme avantage : elles étaient accessibles depuis les Macros Visual Basic en ce qui concerne Microsoft Office, ou l’IDE complet Microsoft Visual Basic pour les autres, ce qui permettait d’automatiser bon nombre d’intégrations. Certes, tous les utilisateurs n’avaient pas l’envie ou la capacité de faire du Visual Basic, mais ils pouvaient aussi utiliser n’importe quel langage qui permettait ces intégrations, tel que Visual C++ ou encore Borland Delphi.

Ces plateformes de développement rapide (RAD) étaient particulièrement efficaces notamment avec l’inspecteur d’objets où on pouvait manipuler directement les propriétés, s’enregistrer sur des événements pour bâtir des automatismes avec des IHM simples. On peut considérer que Visual Basic était le "Low Code" d’hier, c’est-à-dire que le code que l’on produisait était du code de très haut niveau et destiné à l’intégration sans l’aspect pur métier qui, lui, était encapsulé par les objets exposés via des composants OLE/COM. Puis le monde du Web est apparu sans patterns d’intégration aussi évolués. Pour pallier ce manque, certains fournisseurs passaient par des plugins plus ou moins évolués et peu sécurisés. D’ailleurs, les gros processus industriels nécessitant beaucoup d’intégration ont continué très longtemps avec des clients lourds communiquant par des protocoles bas niveau tels que TCP/IP.

2. Du besoin d’enrichir les logiciels SaaS

Parler de SDK pour des solutions SaaS peut sembler incongru, puisqu’on utilise un logiciel SaaS pour éviter de s’embarrasser avec du développement. Pourtant, si vous êtes...

1. Introduction

La notion de tenant est une notion qui est souvent mal comprise chez les éditeurs comme les utilisateurs et confondue avec la notion de client. Or, un client peut posséder plusieurs tenants par exemple de démo, de recette, de préproduction ou de production. La notion de multi-tenant gomme encore plus les frontières car, en cherchant à les optimiser, on peut en perdre le contour exact. La meilleure façon de comprendre la notion de tenant est de se projeter dans une opération de churn, c’est-à-dire d’arrêt de la souscription d’un client souhaitant qu’on lui rende ses données de production. Dans ce cas, il faudra bien lui restituer un jeu de données distinct par type d’environnement (recette, prod…) et évidemment sans lui adjoindre les données des autres clients ! Le tenant correspond ni plus ni moins qu’à cet ensemble de données que vous devriez lui restituer.

Avant de parler du multi-tenant, il nous semble important de revenir au principe économique de base du modèle SaaS. D’après les benchmarks, le coût d’infrastructure d’une solution SaaS ne doit pas représenter plus de 20 % des revenus issus du service SaaS. Les coûts d’Infrastructure se décomposent en deux catégories : 

Il est donc nécessaire d’être extrêmement attentifs à ces deux coûts, puisqu’on imagine très bien que s’ils atteignent 25 ou 30 %, ils vont amoindrir les autres capacités de financement telles que le budget R&D et, potentiellement, avoir un impact sur la marge. Pour optimiser ces coûts et rester compétitif, il faut suivre a minima les deux principes d’optimisation suivants :

Avant d’expliquer le multi-tenant, nous vous proposons de bien revoir sur un exemple concret les limitations...

1. Introduction

Dans une application de gestion SaaS, il est souvent nécessaire de s’adapter aux différents flux de travail entre les acteurs sur un même dossier. Dans un MVP (Minimum Viable Product), le workflow est bien souvent "codé en dur" sous forme d’un énuméré d’états et/ou d’étapes (donc linéaire et ne permettant pas des états ou des étapes en parallèle). Pour autant, la demande de flexibilité des clients conduit souvent à complexifier les règles métiers, jusqu’à ne plus savoir réellement ce qui est implémenté, car les règles de gestion du processus sont noyées dans le cœur du logiciel. L’introduction d’un workflow seul ou couplé avec un moteur de règles est une bonne solution pour offrir cette flexibilité aux clients tout en retrouvant la maîtrise, éviter les bugs et problèmes de sécurité. Il donne également davantage la main aux clients en leur permettant à minima de visualiser le workflow et parfois de le modifier.

Comme dans la plupart des problématiques transverses, il existe des solutions et des normes : en matière de workflow, la plus connue d’entre elles s’appelle le BPMN (Business Processing Model and Notation) et permet l’interopérabilité des outils couvrant ce domaine. En théorie, en incorporant un workflow de type BPMN, vos clients pourraient éditer le workflow de votre solution avec l’outil de leur choix, puis le réimporter et tout fonctionnerait. Comme dans l’approche UML, il existe un certain nombre de types de diagrammes.

Voici un exemple de workflow compatible BPMN :

Dans cet exemple, il existe plusieurs pistes (lanes en anglais) correspondant à différents participants et entités. Ensuite, dans chaque piste, il y a différentes transitions (actions qui conduisent à un nouvel état).

Pour un acteur SaaS B2B, les nombreuses possibilités offertes par cette approche peuvent être différenciantes au sein de l’offre, mais elles doivent surmonter bon nombre d’obstacles.

2. Le prix d’un moteur de workflow

Un moteur de workflow étant une fonctionnalité...

1. Introduction

Au fur et à mesure du développement de votre logiciel SaaS va se poser la question des jeux de données et du paramétrage. Le modèle économique d’un service SaaS ne peut pas reposer sur des myriades d’intégrateurs, qui vont alourdir la facture d’entrée, alors même que le modèle économique à privilégier repose sur un démarrage rapide et une consommation à l’usage. L’outillage autour des données, des tenants et du paramétrage est une clé à ne pas négliger et cette approche est différenciante dès le début de l’expérience client pour faire du "vrai SaaS" en mode B2B. La cible est de faire rentrer le client dans un pipeline de bonnes pratiques, avec un vrai service valorisable, testé et automatisé. On évitera de laisser la porte ouverte à des développements spécifiques pour réaliser l’intégration, le mieux étant que la phase d’intégration soit entièrement réalisable via l’interface graphique du logiciel. Dans ce cadre, l’initialisation des données d’un nouveau tenant et la gestion du cycle de vie des paramétrages font partie des sujets les plus délicats que nous avons rencontrés sur les gros progiciels de gestion.

2. Différents types de données pour un tenant

Tout d’abord, avant de détailler les différents cycles de vie des données, nous allons faire un zoom sur les types de données constitutifs d’un service métier.

Nous proposons de distinguer trois grandes familles de données qui sont elles-mêmes subdivisées :

Chaque famille est elle-même subdivisée en plusieurs couches de données que nous allons détailler.

1. Introduction

Le concept de transaction est apparu au même moment que les bases de données. Rappelons qu’avant les Systèmes de Gestion de Bases de Données Relationnelles, le code métier était souvent chargé également d’écrire sur le disque et de gérer les cas d’erreurs sous forme d’appels aux primitives systèmes (fopen, fwrite…). Dès lors que les accès aux bases de données ont été normalisées via SQL dans les années 70 et que les mécanismes d’écriture des données ont été délégués au SGBDR, les systèmes de gestion de transactions se sont popularisés.

Le principe des transactions est de faire un commit en cas de succès ou de faire un rollback (annulation de toutes les commandes en cours) en cas d’erreur. 

Si vous avez développé des applications complexes, vous êtes sans doute tombé dans des problèmes de type deadlocks, qui se produisent lorsque plusieurs transactions manipulent les mêmes données. Il est important de maîtriser les mécanismes de transaction qui évoluent eux aussi avec les architectures modernes, notamment les architectures distribuées qui sont de plus en plus sollicitées pour les architectures SaaS, avec l’influence du Domain Driven Design. 

2. L’approche transactionnelle classique : ACID

Les caractéristiques d’un système transactionnel ont été mises sous l’acronyme ACID (Atomicité, Cohérence, Isolation, Durabilité) :

1. Introduction

En tant que fournisseur SaaS, il faut bien comprendre que l’on fournit et que l’on opère une extension délocalisée d’un morceau du SI de plusieurs clients. Non seulement le risque est critique pour l’éditeur SaaS qui, en cas d’attaque, met en péril l’entreprise elle-même vis-à-vis de son image, mais en plus elle est un propagateur potentiel de vulnérabilité pour ses clients si sa politique sécurité n’est pas étanche ou cloisonnée.

Pour bien comprendre l’évolution actuelle des pratiques, faisons tout d’abord un petit retour arrière sur les patterns de sécurisation réseau. L’approche consistant à mettre en place partout des VPN a été le moyen le plus répandu de sécuriser les accès extérieurs vers l’intérieur du SI du client. Or, avec les évolutions récentes, les usages changent et les anciens patterns ne sont plus adaptés à l’ère du SaaS, et du Cloud. Par exemple, on peut imaginer un utilisateur qui est en conférence sécurisée chez lui en Wi-Fi, puis passe dans sa voiture en 4G, et enfin arrive au travail où il se reconnecte à son réseau local. Dans ce cadre, on voit bien que la sécurisation via le VPN ne répond pas à ces nouveaux cas d’usage en termes de continuité de service.

La sécurisation des années 2000 reposait en effet généralement sur le concept de DMZ (zone démilitarisée). Dans cette approche, l’idée était de n’exposer sur Internet que les ressources non critiques, telles que les serveurs web, e-mail, FTP…, et de protéger le cœur du SI par plusieurs Firewalls (pare-feu). Cela permettait par exemple de ne pas exposer les serveurs applicatifs sur tous les ports et surtout de protéger les bases de données des accès distants non sécurisés.

Cette sécurité qu’on appelle "périmétrique" a été utilisée notamment parce qu’elle permettait de pallier les déficiences de sécurité de certains logiciels, pour lesquels l’ajout de fonctions...