Industrie Mag - Le journal de l'industrie.

Saaswedo, spécialiste de l’édition de solutions de pilotage des télécoms, partage ses 12 années d’expériences en la matière, qui lui ont permis de devenir l’acteur majeur de son secteur.

Une tribune de Brice Miramont, Directeur des systèmes d’information de Saaswedo

Cela fait des années qu’il en est maintenant question – sous des sobriquets divers. Le Software as a Service, modèle « next-gen » pour les éditeurs de logiciels, est présenté depuis longtemps comme le sésame ouvrant sur tous les trésors. Simplicité, récurrence, mutualisation… Le tableau parait splendide. Les pure-players, qui n’ont souvent que quelques années d’expériences, voient tout simplement le SaaS comme une évidence.

Oui mais voilà. Pour un éditeur, après une décennie (ou plus) en mode licence, le passage au SaaS peut faire mal. S’il ne faut pas chercher loin dans les médias pour avoir de nombreuses recommandations (savoir changer de culture d’entreprise, rémunérer différemment ses commerciaux, déléguer l’hébergement à un partenaire de confiance…), il est pour autant nécessaire de ne pas occulter les points suivants :

Trois préceptes de base, pour commencer

Primo : messieurs les éditeurs, avec le SaaS, vous allez changer de métier. Le Software as a Service est un modèle d’exploitation et de maintenance. Pour une entreprise de moins de 100 personnes, l’on estime que l’exploitation représente entre 60% et 80% du budget IT. Vous ne pourrez pas ignorer la question de la place prise par vos équipes de développeurs dans ce schéma. Ni l’importance de la redondance, de la sauvegarde et des monitorings couvrant votre Service-level agreement.

Deuxio : vous allez devoir situer votre modèle entre deux dogmes. Le premier, distribué, low-cost, ouvert, à l’image d’un Google, va aligner des centaines de machines pour des centaines de clients. Le second, que nous avons retenu, s’apparente à de l’orfèvrerie, avec un nombre plus restreint de machines ultraperformantes et une approche multitenant. De l’un à l’autre, obligations et stratégies seront fortement différentes. Et dans notre expérience, il ne vaut mieux pas les confondre… même si on peut mixer les deux approches selon les besoins et les contraintes.

Tertio : le « Service » de l’acronyme SaaS n’est pas là pour faire joli. C’est ce que vous allez vendre. Vos indicateurs clefs doivent changer en conséquence. Le taux de disponibilité devient l’alpha et l’oméga de ce que vous offrez et vous allez être confronté à la « loi du online » : dans ce business, le moindre écart de performance et de latence va faire la différence. Vous entrez en effet dans un monde « Real-Time » avec toutes les contraintes et les points de vigilance que cela implique pour votre activité.

Entrons dans le détail. Voici nos principaux points d’attention

Que faire de son legacy ?

Le premier écueil dans la transition vers le SaaS d’un acteur qui distribue ses logiciels est bien souvent le poids du legacy. Comment le migrer ? D’un coup ? Par modules ? Notre vécu en matière de SaaS, nous dicte le bon sens : le juge de paix doit être les besoins de vos clients. Avec des budgets clients réduits et une base installée importante, mieux vaut procéder graduellement, en ajoutant petit à petit des fonctionnalités « connectées », comme les rapports de crash ou le live update.

Quel mode de développement et de distribution fait le plus sens, en SaaS ?

Pour la conception de la couche technologique, la scalabilité est la clef du SaaS et va impacter jusqu’au service rendu au final au client. Se concentrer sur la facilité de déploiement initiale est à double tranchant. L’éditeur doit anticiper, définir son « plan de charge sur l’exploitation » pour ne pas risquer de grever, au quotidien, son service client. Pour traiter la multitude, la distribution indirecte et les partenariats sont extrêmement efficaces.

En termes d’anticipation, vos choix vont devoir également prendre en compte dès le départ les enjeux de croissance à l’international. Ne sous-estimez l’impact que celle-ci aura sur l’architecture, les processus de chargements, les services clients… Enfin, cela ne fait pas de mal de le rappeler, le SaaS - en changeant la nature de votre modèle de facturation - risque bien d’augmenter temporairement le Besoin de Fonds de Roulement de votre entreprise.

Quelles sont les règles du jeu, côté Architecture ?

Simplicité et SOA. Mais nous voyons trois idées plus précises à retenir :

 Le point de départ n’est pas la technologie (Unix, Windows…) ou la méthode (REST…), mais le service qui doit être délivré. Etre agnostique de la technologie, c’est être libre dans ses choix futurs.

 Cela impose également de faire preuve de souplesse, pour savoir abandonner une technologie au profit d’une autre, si le service l’exige.

 Dans cette dynamique, vous pouvez tout à fait être crédible vis-à-vis d’un grand compte en découpant vos technologies par couche, pour pouvoir choisir le best-of-breed sur chacune d’entre elles.

Quelques exemples ? Nous avons jugé le code JavaScript qui s’exécutait à l’ouverture de la page trop dépendant du navigateur et de la machine utilisée par notre client… nous l’avons abandonné au profit d’une technologie JVM, multiplateforme, aux calculs exécutés en back-office. De même, nous générions tous nos rapports à la volée sous ColdFusion. Face aux problèmes que cela induisait, nous avons choisi un fonctionnement en mode planification (scheduling) avec BI Publisher sur WebLogic… scalable et robuste.

Quid de l’architecture et du staffing ?

Dans notre expérience, il faut être vigilant sur deux points supplémentaires

 Même en cas de sous-traitance, maitrisez chaque technologie. Cela vous évitera de vous retrouver piégés par la disparition du sous-traitant… ou de régler ces problèmes lors d’un procès.

 N’hésitez pas à développer une API d’interfaçage de couches plus performantes que celles pré-fournies par un tiers.

Enfin, last but not least (loin de là) :

Qu’en est-il du service client ? On ne triche pas avec ses clients, encore moins en mode SaaS. Ils ne voient aucune différence face à un logiciel traditionnel, certes, mais ils vont être particulièrement sensibles aux temps d’accès et à la disponibilité. C’est la loi des usages web. Voici donc pour finir quelques remarques sur ce qui arrive immanquablement à un éditeur SaaS, en matière de relation client :

 Les heures ouvrées vont être allègrement dépassées. Le service client doit y être préparé ou au moins faire preuve de pédagogie, par exemple en expliquant les risques qu’il y a malgré tout à lancer une énorme opération (dans notre cas un rapport) juste avant l’heure de chargement d’un entrepôt. Les plages de maintenance de l’infrastructure doivent être connues.

 Le service va être utilisé au-delà du raisonnable. Il faut vite apprendre à prévenir des pics de charge, grâce à des contrats ad-hoc et un bon plan de charge.

 Le web, c’est aussi de la sécurité. Un sujet particulièrement verrouillé en entreprise, surtout chez les grands comptes. Le service client va devoir retrousser ses manches pour ouvrir des ports, gérer des caches, se familiariser avec certains protocoles (SFTP, AMF…).

 Le client n’a jamais de mauvaise bande-passante. Son fournisseur SaaS par contre… C’est en tout cas ainsi que le problème va être perçu. Le service client va devoir apprendre à faire des diagnostics de bande passante à distance.

http://www.saaswedo.com