Ludovic Foreau
CEO
Satelliz
Le SLA (Service Level Agreement) définit contractuellement le niveau de qualité minimum d’un service fourni par un prestataire à son client.
Pour un service applicatif, le SLA détermine la disponibilité de l’application (son taux d’accessibilité), ou autrement dit, le temps maximal de perturbation du service applicatif toléré par le client, sous peine de pénalités financières.
Par exemple, un SLA applicatif de 99,5% garantira au client un maximum de 4 heures d’indisponibilité mensuelle de son application en ligne.
Jusque là, rien de nouveau…
Sauf que dans le cas d’une application en ligne, en mode SaaS, qui est souscrite par le client sous forme d’abonnement « tout compris » directement auprès de l’éditeur, c’est à ce dernier que revient la responsabilité du SLA applicatif. Une responsabilité d’un genre nouveau pour l’éditeur.
De surcroit, les usages ont évolué faisant accroitre le niveau d’exigence des clients. Organisation sur plusieurs fuseaux horaires, télétravail, utilisation via mobile en continu, … Toute application d’entreprise, qu’elle soit critique ou non pour le business, doit désormais être disponible en continu, 24h/24 et 7j/7. Le « 24/7 » est devenu la norme pour l’usage, et donc aussi pour le SLA applicatif.
Organisé jusqu’alors pour travailler sur une plage heures de bureau en assurant un support fonctionnel sur son logiciel, tout éditeur doit désormais fournir un service ininterrompu en 24/7 et s’engager contractuellement sur la qualité délivrée.
Chose totalement nouvelle, c’est donc à l’éditeur d’orchestrer toutes les briques techniques, depuis le réseau jusqu’à l’hébergement, en passant par la sécurité, la gestion physique des serveurs, l’administration des systèmes, le pilotage des contrats de service et de maintenance s’y rapportant…
L’éditeur doit opérer en 24/7 sa propre application, ce qui s’apparente à faire le métier d’un infogéreur. Il doit ainsi consolider chaque maillon technique et chaque SLA intermédiaire de la chaine de production, pour être en mesure de s’engager contractuellement sur l’ultime indicateur clef gage de la qualité exigée par le client : le SLA applicatif 24/7.
Mais plus qu’un engagement contractuel, garantir le SLA applicatif en 24/7 relève du défi pour l’éditeur ! Un défi organisationnel et humain d’une part, et un défi économique d’autre part.
Défi organisationnel et humain pour répondre aux problématiques de production et de maintien en condition opérationnelle d’un service continu 24/7 :
- Comment superviser en temps réel le bon fonctionnement des services ?
- Comment détecter et être prévenu de tout dysfonctionnement ?
- Comment organiser une équipe humaine prête à intervenir en cas d’incident, 24h/24 et 7j/7 ?
- Comment minimiser les temps d’intervention et rétablir rapidement le service applicatif ?
- Comment calculer le SLA applicatif 24/7 pour le justifier auprès de son Client ?
La bonne gestion du SLA applicatif 24/7 passe par une solution de supervision, devant intégrer non seulement la détection, l’alerte en temps réel des anomalies techniques, le calcul du SLA applicatif, mais aussi et surtout l’intervention humaine immédiate en cas d’incident, sur une couverture 24/7.
Au début, les équipes de R&D en place sont sollicitées pour assurer la production 24/7, mais cela tient tant que l’activité est faible… sans parler des risques RH : se réveiller en pleine nuit, parfois les week-ends et jours fériés, pour rétablir un service n’apparait pas dans la fiche de poste d’un développeur, profil que l’éditeur doit préserver. Prévoir une structure humaine additionnelle pour assurer le SLA applicatif 24/7 devient vite inéluctable.
Défi économique car la mise en place de nouveaux outils et plus encore d’une nouvelle organisation 24/7 – minimum 6 personnes pour assurer un roulement – représente un coût non négligeable pour l’éditeur, qu’il ne peut absorber qu’à la condition d’avoir un volume important de clients et de jouer la carte de la mutualisation à outrance au niveau de sa plate-forme SaaS. Pas simple.
Sachant que pour ne rien faciliter, de plus en plus de clients souhaitent utiliser leurs applications ailleurs que depuis la plate-forme multi-tenante de l’éditeur, plate-forme où les efforts de supervision sont investis et mutualisés… En effet, il n’est pas rare qu’un client souhaite une instance applicative dédiée, basée sur ses propres serveurs (en interne, sur un Cloud privé ou public). Impossible alors pour l’éditeur de répondre positivement à de telles demandes, sauf à envisager le déploiement d’une solution de supervision déportée chez le client, donc dédiée. Complexe techniquement et souvent trop couteux.
La solution de supervision doit ainsi coller au modèle économique de l’éditeur, dès son premier client, en étant proposé sous forme d’abonnement, que ce soit pour la partie outil comme pour la partie humaine 24/7.
Elle doit pouvoir également être suffisamment flexible et polymorphe pour être proposée quelque soit les exigences particulières des clients finaux,… ce qui, en plus de permettre le respect du SLA applicatif 24/7, permet à l’éditeur de générer plus de business.
Ludovic Foreau interviendra à la table ronde n°6 « Risques et vigilance » des Etats Généraux du Cloud, le 9 juillet.