Stratégie pour un logiciel SaaS durable

1. Les enjeux critiques

Comme nous l’avons vu plus haut, la réussite dans le SaaS repose tout d’abord sur une croissance rapide, donc sur la vitesse d’exécution initiale puis sur la capacité à rendre cette croissance durable.

Pour cela, un certain nombre de critères doivent être bien identifiés, portés au plus haut dans les choix d’architectures et pilotés dans la roadmap qui doit devenir la boussole de l’ensemble de l’entreprise.

Les enjeux critiques qui doivent être pilotés dans la roadmap tournent autour de l’intégrabilité, l’ouverture du système, la sécurité, la performance, la User Experience, la maîtrise de la dette technique et selon le secteur métier, on peut retrouver des enjeux réglementaires aussi. 

Il est donc essentiel que la construction et le pilotage de cette roadmap soient un processus connu de tous et collaboratif.

2. Construire sa roadmap

1. Du monolithe aux microservices

Avec la bascule vers le Web, l’accélération des rythmes de livraison, la volonté d’innover sans cesse et le désir d’ouverture des systèmes d’information, ces vingt dernières années ont vu une évolution bien marquée et clairement identifiée des architectures logicielles.

Le choix entre l’une ou l’autre des architectures est extrêmement structurant et nous allons rappeler les principes conducteurs de chacune d’elles.

L’architecture monolithique a dominé sans partage jusque dans les années 2000, à l’exception de la période des EJB (Enterprise Java Bean) qui était une architecture déjà distribuée mais qui s’avérait trop consommatrice de ressources mémoire, CPU et réseau à un moment ou l’infrastructure coûtait encore très cher et était On Premise.

Au début des années 2000 sont apparues les architectures type bus (ou SOA), en 2010 environ sont apparus les microservices et depuis 2017 arrivent les architectures FaaS/Serverless.

Cette évolution est caractérisée par la constante miniaturisation de la granularité de service rendu par chaque instance applicative. Par rapport à une application type monolithe, une application microservice pourrait être comparée à un ensemble de pierres de construction, alors qu’une architecture type Serverless/FAAS serait composée de grains de sable.

Les différences de couplage entre les différentes architectures sont également caractéristiques :

1. Les motivations pour le choix d’un langage

S’il y a bien un sujet qui génère des discussions interminables et parfois des complications managériales, c’est bien le choix du langage et, parfois plus que le langage, le Framework à utiliser.

Beaucoup de contre-vérités sont lancées régulièrement via des blogs ou des posts Twitter, ou même en interne dans les entreprises, sur l’avantage concurrentiel de tel ou tel langage. Il est important de ne pas être emporté par ce qu’on appelle l’effet Cargo venant des grands acteurs tels que les GAFAM. Cet effet a été décrit pendant la Deuxième guerre mondiale : sur les îles du Pacifique, les indigènes recevaient la visite de l’armée américaine et cette dernière y installait des bases aéronautiques pour y reprendre progressivement le contrôle du Pacifique. Or, sur les pistes d’avion faites pour l’occasion, se trouvaient des militaires chargés de coordonner via des mouvements de bras, comme sur les porte-avions pour les décollages et atterrissage, la gestion de la logistique pour y apporter matériel et nourriture. Quand les Américains se sont retirés de ces îles, les indigènes ont repris les gestuelles, pensant à tort qu’il y aurait un lien de cause à effet entre ces gestes et l’arrivée de nourriture ou de matériel. Cet exemple, s’il fait peut-être sourire, n’est pas très éloigné de ce qui se produit parfois pour choisir le langage et le Framework de développement d’un logiciel. Combien de fois a-t-on entendu dans les entreprises : « Si Google a choisi cela et que nous faisons le même choix, cela va résoudre tous nos problèmes ». Le choix d’un nouveau langage ou d’un nouveau Framework est souvent présenté comme le remède à tous les maux et à toutes les mauvaises expériences passées. Cette manie sur le choix du langage se décline à toutes les échelles de l’entreprise, depuis le développeur junior qui exige dès l’entretien de recrutement de coder dans un langage, jusqu’au PDG...

1. De la nécessité de modéliser

La plupart des sociétés ont des progiciels de gestion intégrée (ERP, Enterprise Resource Planning en anglais) pour assurer la cohérence de la gestion de leur entreprise sur toutes les fonctions supports comme la comptabilité, la finance, la facturation fournisseurs, etc.

Dans les principales industries, ces ERP sont extrêmement complets pour assurer le suivi voire le pilotage du flux de production, depuis la chaîne d’approvisionnement jusqu’aux ventes en passant par la production. Or, la plupart des éditeurs de logiciels qui produisent et opèrent des systèmes SaaS n’ont paradoxalement pas de Système d’information pour opérer leur cœur d’activité, tout simplement parce qu’il n’y a pas d’ERP spécialisé dans cette gestion. Il y a certes quelques logiciels dédiés à la gestion des déploiements comme XL Deploy mais ils sont finalement limités à cette seule activité et ne font pas le lien avec le reste de l’ERP (ex. déclenchement d’un avoir en cas d’indisponibilité du Service, notification des utilisateurs en cas de mise à jour, suivi de la maintenance).

2. Les trois types d’entités opérant du logiciel

Nous pensons que la gestion et la modélisation d’une activité dépend des usages et nous proposons dans le tableau suivant de comparer les besoins de la DSI d’un client final, les besoins spécifiques de la partie production d’un éditeur SaaS que l’on regroupe sous le terme "Usine SaaS" et les besoins pour la partie développement appelée "Usine Logicielle" ou Software Factory en anglais. 

1. Introduction

Au cours des années 80, l’usage du mot clé GOTO a été abandonné, jugé comme une mauvaise pratique. Ce mot-clé n’est plus présent dans la plupart des langages car il conduisait à ce qu’on appelle du "code spaghetti". Phil Karlton, un ancien ingénieur de Netscape, repris par Martin Fowler, le "Pape de l’Architecture Logicielle", indiquait de manière un peu tranchée et assez vraie qu’il n’y avait que deux problèmes difficiles à résoudre en informatique :

Nous pensons qu’il aurait fallu y ajouter le problème suivant qui n’est souvent pas bien traité par les équipes de développement : la gestion correcte des dépendances logicielles et de leur mise à jour.

2. Comment ce problème est-il devenu aussi prédominant ?

Depuis les années 2010, il y a une explosion du nombre de librairies utilisées (sécurité, Rest API, messaging…) dans des applications web même simples. Cette augmentation des librairies est due à plusieurs phénomènes, dont l’utilisation de plus en plus fréquente de Frameworks qui embarquent eux-mêmes des dépendances transitives et de nombreuses librairies parfois inutiles ou optionnelles. En dehors du fait qu’elles alourdissent énormément la taille de vos packages de livraisons, elles peuvent vous ralentir dans l’écriture du code fonctionnel, alors même qu’elles étaient censées faire gagner du temps et éviter de réinventer la roue.

Ces dépendances, si elles ne sont pas mises à jour peuvent démotiver vos meilleurs développeurs qui seront tentés...

1. Introduction

En SaaS, la performance des applications est soumise à rude épreuve car elle concerne en général des milliers voire des millions d’utilisateurs. Les coûts sont très directement liés à la performance de l’application car c’est sur votre matériel ou sur un matériel que vous louez que les services fonctionnent. Dans le cas où votre application est lente, vous devrez parfois compenser en dépensant plus d’argent dans l’infrastructure, ce qui ne suffira parfois pas à avoir une application performante pour certains de vos clients à forte volumétrie. Mais de quoi parle-t-on au juste, pourquoi est-ce que ce type de problème est compliqué à résoudre, quelles sont les pistes possibles pour un CTO qui souhaite améliorer les performances de son service SaaS ?

2. Exigence des utilisateurs

L’exigence des utilisateurs est de plus en plus importante et l’augmentation constante de la puissance moyenne du matériel client et serveur ne suffit pas à y répondre. Le diagramme suivant permet de comprendre qu’il n’est plus acceptable pour la plupart des utilisateurs que les pages s’affichent en plus d’une seconde, alors que c’était encore acceptable il y a quelques années.

D’autre part, les applications métiers ou les sites internet sont sujets à de plus en plus de pics de charge (soldes, pub TV, réseaux sociaux) et de plus en plus de synchronisations en temps réel sur de l’édition Collaborative (Google Docs, Office 365), jeux multijoueurs…

Or, le temps de réponse est devenu aussi et surtout un enjeu business, si l’on considère par exemple qu’Amazon a déclaré d’après ses études que 100 millisecondes de latence lui font perdre 1 % du CA. Dans les applications métiers, beaucoup d’entre elles sont utilisées par des gestionnaires pour des processus sur lesquels ils sont souvent objectivés au nombre de dossiers traités (notamment dans l’assurance, le domaine bancaire, etc.).

3. Des problèmes difficiles à résoudre