Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Les clés d'un progiciel SaaS durable
  3. Stratégie pour un logiciel SaaS durable
Extrait - Les clés d'un progiciel SaaS durable Aligner l'architecture, l'usine logicielle et l'organisation
Extraits du livre
Les clés d'un progiciel SaaS durable Aligner l'architecture, l'usine logicielle et l'organisation
1 avis
Revenir à la page d'achat du livre

Stratégie pour un logiciel SaaS durable

Construire et piloter sa roadmap

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

a. Les trois niveaux de la roadmap

La roadmap doit porter la vision stratégique de l’entreprise et sa déclinaison en exécution opérationnelle par raffinages successifs.

Il est important de considérer qu’une roadmap n’est pas un objet figé dans le marbre : au contraire, elle évolue en permanence et c’est plutôt un signe de bonne santé, à condition de ne pas tomber dans l’excès inverse révélant un manque de constance dans la stratégie globale produit.

Voici les trois niveaux que nous proposons de mettre en œuvre dans une roadmap :

  • Tout en haut se trouve le niveau Entreprise pour lequel nous proposons une arborescence à deux niveaux :

  • Thème : on décrit ici les éléments du Business Plan de l’entreprise qui sont les objectifs stratégiques à deux ou trois ans en général. Ce niveau est porté par la direction marketing et peut aussi être dénommé Objectif (ou Goal) dans certaines organisations.

  • Initiative : une initiative est à considérer comme un ensemble d’améliorations consistantes entre elles dans un thème donné permettant de délivrer une valeur métier. On décline les initiatives...

Choisir son architecture

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 :

  • L’architecture monolithique pourrait être comparée à un système avec des engrenages et des poulies reliés ensemble.

  • L’architecture SOA pourrait être un ensemble d’engrenages reliés via des courroies à un élément central.

  • L’architecture microservice serait dans cette image composée de différents systèmes d’engrenages et une motorisation propre avec un couplage très limité entre les systèmes.

  • L’architecture FaaS est une évolution de l’architecture microservice avec une granularité plus fine encore....

Quels langages pour quels usages ?

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...

Modélisation de l’usine SaaS et l’usine logicielle

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. 

Types d’usage / Critère opérationnel

DSI d’un client final

Usine SaaS de l’éditeur (Production)

Usine Logicielle de l’éditeur SaaS (Développement)

Nombre de logiciels à gérer

10..1000

1 (< 10)

1

Importance de la maîtrise du multi-tenant applicatif

Faible

Importante

Faible si monolithe et Importante si microservice

Nombre de versions à gérer

La gestion de l’interopérabilité...

Gestion des dépendances et de l’obsolescence

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 :

  • Le nommage (variables, classes, URL Rest…), ce qui a encore plus d’importance si on examine la pratique du Domain Driven Design. C’est à la précision du nommage que je reconnais souvent une bonne partie de la qualité du développeur, qui s’attache à avoir le code le plus clair et le plus maintenable possible (#ubiquitousLanguage).

  • L’invalidation de cache, pour tous les problèmes de synchronisation et de contention que cela peut poser.

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...

La performance des applications

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.

images/4_6_1.png

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

a. La diversité des acteurs impliqués

Le problème de performance est un problème...

User Experience

Les termes UI et UX sont tous les deux liés à l’expérience utilisateur mais ils portent à la fois des concepts différents et complémentaires :

UX

UI

Design d’interaction

Design visuel

Prototypage / Wireframe (maquette fonctionnelle)

Couleurs

Hiérarchisation des informations

Conception graphique

Recherche utilisateur (User Research)

Layout (agencement)

Scenarios utilisateurs

Typographie

Après avoir été laissé en priorité basse dans les équipes R&D, le métier d’UX revient sur le devant de la scène parce qu’il est enfin considéré comme un métier apportant de la valeur monétisable notamment dans les applications SaaS. Le mouvement a démarré par le e-commerce avec l’élaboration des parcours utilisateurs (paniers, favoris…) puis a progressivement gagné les progiciels et fait dorénavant les beaux jours d’industriels y compris hors du domaine informatique comme Décathlon. Le "design thinking" est désormais une façon de concevoir un produit, ce qui montre le chemin parcouru par rapport au temps où ce périmètre se limitait à des choix de police ou de couleur. Cette activité ne peut ainsi plus être passée au second rang par le management, au même titre que l’agilité ou l’approche DevOps.

Cela paraît être une évidence et pourtant l’UX est devenu un must-have et un critère de choix pour toute application même réservée aux professionnels ; en effet, ceux-ci demandent parfois pour leurs utilisateurs des UI/UX proches des applications personnelles de leurs employés, tels que Gmail, Facebook, LinkedIn… 

Se lancer dans l’UX nécessite au préalable de placer le curseur au bon niveau en d’autres termes de bien mesurer les bénéfices que l’on souhaite en tirer. En effet, le développement d’une application où l’UX est très présente peut coûter dix fois le prix d’une application web HTML avec une ergonomie peu intuitive et peu réactive, pour un seul navigateur, et dont le contenu est généré entièrement par le serveur....