Sur les dernières années qui viennent de s’écouler, un constat est clair : de plus en plus de déploiements de solutions du SI sont réalisés en mode SaaS (de manière plus ou moins maîtrisée…). Sur ce périmètre, une très grande diversité de solutions émergent et la quasi-totalité des fournisseurs de logiciels se positionnent sur ce type d’offre. Cette évolution entraîne également une modification de la gouvernance et de l’organisation des entreprises. Les donneurs d’ordre sont à présent de plus en plus affiliés au métier et de moins en moins côté DSI. Ces modifications impliquent bien souvent une certaine désorganisation et il est d’ailleurs intéressant de voir comment une société comme Beamy propose d’aider à inventorier et reprendre la maîtrise les souscriptions SaaS au sein d’une entreprise.
Indépendamment de savoir s’il est pertinent ou non de faire du SaaS, et des problématiques légales ou contractuelles inhérentes à toutes solutions d’externalisation, notre propos ici concernera les bonnes pratiques d’intégration technique de ces solutions au sein du SI de l’entreprise. En effet, on ne peut plus raisonnablement intégrer une solution SaaS comme on intégrait un Application Service Provider il y a 15 ans. Nous nous intéresserons donc aux bonnes pratiques d’intégration sur les plans techniques et opérationnels sans aborder l’intégration applicative qui est un sujet bien trop vaste et qui aurait besoin de nombreux articles pour traiter chaque volet de manière unitaire (Provisionning, Authentification, échange de données, etc. …).
L’intégration technique
Le choix d’une solution SaaS étant très souvent motivé par un gain de flexibilité, de temps d’intégration et par une volonté de déléguer une partie de la gestion de la complexité de l’exploitation d’un SI, l’intégration technique sous-jacente doit impérativement être cohérente avec ces objectifs.
Dans le cas contraire, on prendra le risque de se retrouver dans un écosystème qui cumule le pire des 2 mondes.
Encore beaucoup d’acteurs dit “Saas” du marché ne sont en fait que des éditeurs historiques qui se sont simplement mis à héberger leur service en propre. Ils se sont mis à revendre leurs logiciels via un modèle d’exploitation commerciale “Saas” sans réfléchir aux pré requis techniques nécessaires l’utilisation de ce modèle.
L’objectif principal concernant l’intégration technique est de limiter au maximum son couplage avec son fournisseur de service.
Pour cela, la première règle à respecter est celle de s’appuyer sur des principes d’intégration technique “publique”. Pour préciser ce propos, cela implique donc de s’appuyer sur des IPs Publiques (exclus des segments RFC 1918) et des entrées DNS publiques pour joindre son service SaaS.
La mise en place de liaison s’appuyant sur un réseau privé (RFC1918, par exemple 10.0.0.0/8) partagé avec son partenaire, comme cela pouvait être la norme par le passé est à proscrire, en effet, ce type d’implémentation va générer plusieurs phénomènes qui créent un couplage très fort avec son fournisseur:
- Une définition d’un plan d’adressage spécifique avec son fournisseur pour ne pas avoir de chevauchement d’adresse IP, ou, pour palier à cela, la mise en place de règles de NAT spécifiques.
- La création de routes spécifiques sur son SI pour contacter ces adresses privées.
- L’utilisation d’entrées DNS privées avec des conditions spécifiques de forwarding, voir un enregistrement dans un domaine local pointant vers une entité externe.
C’est tout cela que l’on souhaite s’éviter lors de l’utilisation d’un service en Saas.
Principe d’intégration publique est généralement synonyme d’internet, mais pas uniquement, vous pouvez utiliser des liaisons dites privées (liaisons opérateurs). A titre d’exemple si pour des questions de performance ou de qualité de service, vous souhaitez mettre en place une liaison ExpressRoute pour utiliser les services O365 de Microsoft, vous aurez une liaison directe vers Microsoft (sans transit sur l’internet public) en revanche les routes échangées grâce au peering BGP sont des routes avec des IP publiques exclusivement. Les noms de services utilisés restent ceux enregistrés dans les DNS publics portant les domaines Microsoft.
L’intégration opérationnelle
Si certaines personnes pensent que l’exploitation d’un produit en Saas est très limitée, attention à ne pas faire l’erreur de penser qu’il ne faut pas un modèle opérationnel adapté. Une application en Saas doit s’exploiter ! C’est une brique du système d’information et elle doit y être pleinement intégrée d’un point de vue opérationnel :
Compréhension de la solution
D’un point de vue technique, il est important que cette nouvelle application Saas ne soit pas une “boite noire” pour les équipes. Lors de la phase projet, des niveaux de services vont être définis de manière contractuelle avec le prestataire mais il est important que les équipes au sein de la DSI comprennent comment cette application est conçue. Un dossier d’architecture complet qui décrit la solution et ses différents composants logiciels est un élément extrêmement important à demander à son fournisseur. Cela permet entre autre, aux équipes de s’approprier la solution, mais aussi de vérifier si les mécanismes techniques mis en place par le fournisseur sont alignés avec les niveaux de services attendus, d’identifier des possibles points de faiblesses (sur l’obsolescence, la sécurité , l’architecture…).
Monitoring / Supervision
Chaque acteur Saas met en général à disposition des informations de supervision détaillées dans le « back-office » de son application. Elles peuvent être utilisées ponctuellement mais n’apportent qu’une visibilité réduite à elles-mêmes. Ces applications doivent donc être interfacées avec votre outil standard de supervision. Dans la mise en œuvre, les opérateurs Saas mettent généralement à disposition des APIs de monitoring qui peuvent être appelées facilement par toutes les solutions standard de supervision du marché. Les incidents arrivent également sur les applications en Saas ! Il est d’ailleurs important d’avoir un canal de communication clairement établi avec son fournisseur et que celui-ci soit précisé dans une documentation accessible aux équipes en charge de l’exploitation du reste du SI.
Gestion des Logs
Pour permettre une exploitation optimum de son SI, la centralisation des logs est très souhaitable. Si c’est le cas pour les applications hébergées “en interne”, cela doit aussi être la règle pour les applications en Saas. La centralisation des logs permet d’avoir un point unique de consultation et apporte des capacités de corrélation sur toutes ses applications lors d’un incident, d’une faille de sécurité ou autre. L’intégration d’un service Saas ne doit pas déroger à cette règle. Si vous possédez déjà un SIEM (Security information and event management), un puit de logs, ou tout autre outil en charge de l’agrégation de logs, votre application Saas doit être intégrée à cet écosystème.
Environnements
Il vous faudra certainement plusieurs environnements à disposition pour tester de nouvelles évolutions. Là aussi, il faudra penser à se faire détailler ce point par le fournisseur de la solution pour qu’il puisse vous expliquer les différents environnements qu’il pourra vous mettre à disposition et leurs enjeux.
Conclusion
Les solutions en SaaS sont des briques à part entière du SI, il est donc important que la DSI soit impliquée dès le début des réflexions et de la sélection des fournisseurs pour conseiller au mieux le métier dans ce choix. Sans une intégration technique et opérationnelle réfléchies, l’utilisation de solutions Saas entraîne un éparpillement du SI avec de possibles forts couplages techniques rendant à terme les futures évolutions difficiles et une “agilité” qui se retrouve compromise… Tout le contraire du but initial recherché.