SaaSuffit !

Quelques réflexions sur le SaaS...

Bien qu'initialement le terme SaaS signifie Software As A Service, c'est à dire le fait de payer un logiciel à l'usage plutôt que comme un produit, la signification implicite de ce terme a rapidement dérivé pour décrire les logiciels avec une interface web. On devrait plutôt parler de web based software.

Le pendule de l'architecture client serveur

Qui se rappelle des débuts de l'informatique organisée autour des "mainframe", une sorte de méga unité centrale sur laquelle des terminaux venaient se connecter. C'était ça l'informatique des années 70, une architecture client-serveur, avec toute l'intelligence dans le main frame, et rien dans les terminaux. Le terminal n'était qu'un afficheur d'information en mode caractère (VT100). Déporter des capacités de traitement au niveau du terminal paraissait incongru. De fait cela n'était pas très gênant car la majorité des applications avait pour objet la consultation et la mise à jour d'enregistrements dans des bases de données.

Puis dans les années 80 arrivèrent les stations de travail pour le calcul scientifique et le "PC" d'IBM. Des unités autonomes, avec un processeur, un système d'exploitation, un disque dur, des applications. Et là ce fut l'effet inverse, des ordinateurs individuels de plus en plus puissants et des serveurs de plus en plus simples. Même les applications qui avaient pour objet la gestion de données centralisées tentaient, tant que faire se peut, de les décentraliser, de "distribuer" l'information.

Mais du coup les applications dépendaient de l'ordinateur, de l'architecture de son processeur, de son système d'exploitation. Les éditeurs se retrouvaient souvent liés à l'architecture de l'ordinateur, et leur application ne fonctionnait que sur une seule plateforme. Pour éviter cela certains ont fait explicitement l'effort de rendre l'application portable ce qui ne venait pas sans difficultés et limites techniques.

Pour se libérer de ces contraintes, aujourd'hui, beaucoup d'applications sont web based, c'est à dire exécutées dans un navigateur internet. Le pendule revient vers des architectures où le serveur exécute toute ou partie de l'application.

Le browser remplace l'OS

Les applications sur le client d'aujourd'hui ne ressemblent pas à celles d'hier sur un terminal en mode caractère. Elles sont maintenant très graphiques, et pour éviter trop d'aller-retour entre le client et le serveur, le maximum de traitement est exécuté dans le navigateur. Et tout cela fonctionne quel que soit le terminal utilisé: sur un ordinateur de bureau sous Windows, sous macOS, sous Linux, sur un smartphone, sur une tablette... Au final la question n'est plus de savoir si l'application fonctionnera sous macOS ou Windows mais plutôt sous Chrome ou Firefox. Ce qui assure la portabilité de l'application, ce n'est plus l'OS, c'est le browser.

Mais cela n'est pas sans poser les mêmes types de problèmes. Aujourd'hui les navigateurs proposent une nouvelle version tous les mois. Les éditeurs doivent être attentifs à ce que leur produit fonctionne sous toutes les versions encore utilisées et sous toutes les plateformes. Cela génère autant de difficultés, si ce n'est plus, que de s'assurer que l'application était portable d'un OS à l'autre.

Pas étonnant que de temps en temps on se retrouve à être obligé d'utiliser un navigateur spécifique sur un OS particulier pour accéder à une application.

Tour de babel

Les premières pages web étaient basées sur de l'HTML (Hyper Text Markup Language), une forme de XML. C'était simple, on pouvait l'écrire manuellement, et ça marchait. Aujourd'hui les applications web sont basées sur de multiples languages qui sont, soient interprétés du côté serveur (php, python, exécutables), soient interprétées du côté client (html, css, javascript). Ceci rend la programmation d'autant plus ardue chez les éditeurs. Du coup des frameworks se sont développés (Django, AngularJS , Symfony) pour faciliter le développement d'applications web. Mais là encore il faut suivre, les versions s'enchainent à un rythme effréné, s'appuient sur des versions de technos sous-jacentes qui évoluent aussi, avec le risque de proposer au final une application qui ne fonctionne que sur les dernières versions de hardware et de navigateur. Cela ne semble pas compatible avec les recommendations actuelles de conserver ses appareils le plus longtemps possible.

Sécurité

Avec une architecture web based, non seulement les applications résident sur le serveur mais les données aussi. Quelque part dans le cloud. L'utilisateur n'a absolument aucune idée d'où elles se trouvent physiquement, à quelle législation elles sont soumises, ni quel est le degré de sécurité lors des échanges. Il est même rarement possible d'exporter ses données pour les porter dans un autre logiciel. Tout cela est masqué. Ce qui rend l'utilisateur très dépendant de l'éditeur qui est lui même dépendant de l'hébergeur. Dans ces heures troubles où le besoin de souveraineté est de plus en plus prégnant cela devient difficile à accepter. Une solution serait d'héberger le serveur physiquement mais cela réduirait considérablement l'intérêt de ce type architecture et reviendrait à gérer non seulement les problèmes de compatibilité des clients mais aussi ceux des serveurs.

Pérennité

Quand on achète un logiciel classique, on a un exécutable qu'on installe sur une plateforme. On peut acheter des mises à jour, ou on peut rester avec la même version aussi longtemps qu'on le souhaite. Dans une architecture web based, l'éditeur va éviter de gérer de multiples versions en parallèle sur ses serveurs. L'utilisateur sera donc amené à s'adapter aux différentes évolutions qui seront imposées par l'éditeur. Ceci pose des questions sur la pérennité des données manipulées par l'application. Combien de temps mes informations seront elles exploitables ?

Dans tous les domaines industriels où la sûreté est primordiale, l'avionique, le militaire, le nucléaire, ou le rail, la stabilité des environnements est la base des certifications nécessaires à la mise sur le marché des produits. Dans ces contextes il est préférable de travailler avec des environnements maitrisés et d'éviter les architectures web based.

Retour du pendule

Il me semble que le pendule est allé très loin du côté du serveur. Les questions de sécurité, de souveraineté, de pérennité et de portabilité ne sont pas traitées correctement. Les évolutions incessantes des frameworks et des navigateurs vont empêcher les éditeurs de stabiliser les versions. S'assurer de la compatibilité avec les dernières nouveautés de tout l'écosystème va représenter un coût tel qu'il réduira la disponibilité des ressources pour développer de nouvelles fonctionnalités. Une sorte de fuite en avant pour finalement faire du sur place.

Je ne crois pas qu'il y ait une architecture universelle et unique pour toutes les applications. Je crois qu'il faut faire du SaaS dans certains contextes et du software classique dans d'autres. Ce qui coute aux éditeurs, c'est l'absence de standard d'interface commun à toutes les plateformes, que ce soit pour une application native ou une application SaaS. Imaginez que les API Windows, macOS et Linux soient les mêmes. Tout le monde en bénéficierait. Peut être faudrait il qu'un organisme international de standardisation s'en saisisse...