Achat de logiciel, quelle politique de licensing en mode SaaS?

Logiciels et services informatiques en mode SaaS sont de plus en plus demandés par les directions métier des entreprises (la direction marketing en tête) créant parfois des points de friction avec la DSI. Mais que se cache-t-il réellement derrière le mode SaaS en termes de services, de clauses contractuelles, d'intérêt financier? Comment la direction achats doit-elle se positionner pour faire les bons arbitrages et développer la bonne stratégie? Quels sont les écueils à éviter? Autant de questions auxquelles maître Franklin Brousse a tenté de répondre lors de la dernière réunion du Club Acheteurs.

"Le mode SaaS regroupe en fait une grande diversité de typologies de services, de projets associés et de modèles économiques, explique l'avocat des directions achats et des directions digitales. Or, selon le service et le projet associé, l'approche contractuelle et financière doit bien évidemment être différenciée". En fonction des cas et des besoins à couvrir, les responsabilités ne sont pas les mêmes, il n'y a donc pas un mais plusieurs types de contrats SaaS.

Les différentes typologies de services SaaS :

Un applicatif "porté". C'est le cas d'un ERP par exemple. Cela implique donc un progiciel assez lourd, un contrat complexe et une mise en place assez longue.

Un applicatif "pure player" comme le propose Salesforce (CRM + caisse)

Un applicatif avec des services associés en mode BPO (autrement dit externalisés) qu'on retrouve souvent dans les services de gestion de paye avec gestion de souscription de contrats en ligne. Nous sommes donc là sur un mode d'application externalisée.

Un service d'analyse "Big Data" qui inclut un applicatif et des services d'analyse de données. On retrouve cette typologie de services dans les outils de Tag Management System par exemple.

Un service d'hébergement "cloud" qui comprend l'hébergement et l'applicatif comme le propose Amazon ou Google Cloud.

Les typologies de projets associés aux services SaaS :

Le Plug & Play, projet peu impliquant disponible tout de suite, on utilise la solution telle quelle en se "branchant" au logiciel de l'éditeur.

Le Setup & Play qui nécessite un minimum de mise en place et de paramétrage.

Le Build & Run qui concerne les gros projets informatiques impliquant une phase de construction et mise en place d'1 à 6 mois puis l'élaboration d'une "recette" avant d'entrer dans le service applicatif à proprement dit.

Les typologies de modèles économiques :

Abonnement simple avec possibilité de se désengager à tout moment. Associé aux projets Plug & Play

Setup fee + abonnement qui inclut des frais d'installation. Associé aux projets Setup & Play

Project fee + abonnement qui inclut des coûts de gestion. Associé aux projets Build & Run

Différentes formes de redevance sont également pratiquées. La redevance qu'elle soit mensuelle, trimestrielle ou annuelle peut être fixe, à l'usage (c'est-à-dire que plus on l'utilise plus on paye) ou bien liée au chiffre d'affaires généré grâce à la solution. "Ce dernier système de redevance concerne généralement un service transactionnel de bout en bout. On commence a le voir de plus en plus dans le secteur du e-commerce par exemple." Certains acteurs spécialisés comme Demandware n'utilisent que ce type de redevance. Leur plateforme e-commerce est construite de telle façon qu'il suffit d'y connecter son site pour générer du chiffre d'affaires additionnel. En contrepartie Demandware prend 20% de commission.

La redevance liée à l'usage oblige les achats à travailler sur une volumétrie hypothétique avec régulation (ajustement ou rattrapage) en fin d'année. "Bien souvent la discussion s'amorce sur la base d'un référentiel tarifaire puis acheteur et prestataire définissent une volumétrie hypothétique de départ. L'inconvénient est bien sûr qu'on ne peut définir en amont combien coûtera le service réellement. Cette pratique est donc peu répandue", indique Franklin Brousse. Enfin, on voit aussi apparaître une logique de revenu minimum imposé. Le prestataire ne vous ouvre son service que si vous lui garantissez un revenu minimum.

Dans ces conditions quel type de contrat privilégier?

"Il faut toujours garder à l'esprit qu'un contrat SaaS est avant tout un contrat de service! Ce n'est plus un contrat de licence. La licence devient l'accessoire", souligne maître Brousse. "Le SaaS c'est aussi le principe du tout compris (utilisation, hébergement, maintenance corrective, mise à jour...) avec une promesse qui doit être tenue!" Parmi les trois types de contrats Plug& Play, Setup & Play et Build & Run, le plus utilisé dans la pratique est celui du Setup & Play. Le problème est qu'il est trop long pour un projet Plug & Play et insuffisant pour un projet Build & Run.

"La solution est d'avoir au moins deux contrats : un modèle compatible Plug & Play et Setup & Play ET un modèle compatible Build & Run", estime Franklin Brousse. Avoir cette double approche permet de gagner du temps. Les petits projets sans enjeu, qui n'entraînent pas d'interaction avec votre SI ne présentent pas de risque et peuvent supporter un contrat plus léger. En revanche en cas d'interaction avec votre système interne ou bien si le projet implique l'utilisation de données sensibles, la vigilance est de mise. "Tout est question de gestion de risque, indique l'avocat. Et si dans la pratique sur la partie achat logiciel il est rare que les achats arrivent avec un contrat type mais partent du contrat fournisseur cela ne veut pas dire qu'il ne faut pas regarder précisément ce contrat. Il ne faut pas partir perdant, on peut toujours négocier un contrat même avec un gros acteur comme Google."

Sur quoi négocier?

Pour ne pas se tromper de combat, il est important d'identifier les points contractuels à forts enjeux et de ne pas perdre de temps sur les clauses en réalité peu impactantes. Et sur ce point l'important n'est pas toujours là où l'on croit. Par exemple pas la peine de perdre du temps et de l'argent à acheter la licence pour détenir la propriété intellectuel. "Cela coûte cher et présente peu d'intérêt dans le sens où le SaaS est d'abord un service. Le seul cas où avoir la propriété intellectuelle présente un intérêt est si vous êtes le premier à proposer au fournisseur de SaaS de développer un service très différenciant qu'il pourra ensuite développer en "vertical" pour d'autres clients. Et encore! Mieux vaut négocier des royalties plutôt que la propriété intellectuelle", précise Franklin Brousse.

Il n'est pas non plus intéressant de négocier l'accès aux codes sources : "si vous travaillez avec une start-up vraiment différenciante le sujet n'est pas de négocier les codes sources qui coûtent horriblement cher mais négociez plutôt le rachat de la start-up en cas dépôt de bilan ou au contraire de pouvoir se désengager en cas de fusion avec une autre entreprise." Les indicateurs de service, aujourd'hui standardisés et mutualisés, ne méritent pas non plus qu'on s'y attarde démesurément. Les recettes (sauf en cas de projet Build & Run), la responsabilité et la dépendance économique sont également des points contractuels à faibles enjeux selon le spécialiste.

A l'inverse, les forts enjeux de négociation portent sur :

- la sécurisation de la partie "build"

- la protection des données personnelles. Il est important de désamorcer ce sujet en amont. Définissez dès le départ si des données personnelles seront ou non utilisées par le fournisseur. Bien souvent ce n'est pas le cas, cela vous permettra de gagner un temps précieux. Dans le cas contraire il est important de savoir où se trouvent les data centers (en zone euro ou non) et si le fournisseur ET l'hébergeur sont bien conformes au RGPD.

- La sécurité informatique; S'il y a interaction avec le SI il y a risque.

- Les conditions financières afin de maîtriser les coûts par rapport au modèle économique déployé. De même il est important de bien définir le point de départ de la facturation. "Les services achats ont tendance à partir du principe que le point de départ de la facturation se situe au moment de la première utilisation alors que la logique des fournisseurs est de facturer à l'activation du service c'est-à-dire à partir du moment où le service est mis à disposition qu'il soit utilisé ou non".

- La réversibilité ou la restitution des données. Ce point est devenu très simple à négocier et souvent inclut dans les contrats fournisseurs.

Le mode Saas véritable intérêt économique ou miroir aux alouettes?

Avec le mode Saas c'est la fin des licences "one shot". La plupart des éditeurs développent désormais une logique de récurrence des revenus autrement dit d'abonnement ou licensing. Le licensing à l'usage est également une tendance qui émerge. "Il peut être intéressant seulement s'il s'agit de vrai licensing à l'usage c'est-à-dire si la solution est installée chez vous mais n'engage une redevance qu'en cas de consultation. Et si, bien sûr, les consultations peuvent se limiter à deux ou trois dans l'année pour du suivi," souligne Franklin Brousse.

Autre point de vigilance : le mode SaaS a bouleversé le business modèle des éditeurs qui avec une récurrence des revenus bénéficient d'un avantage économique en termes d'investissements et de cotations boursières. Tous les acteurs cherchent donc à faire basculer leur clients en mode licensing et là gare à la facturation des usages indirects! "Les usages indirects qui n'étaient pas facturés hier, le seront demain. Certains éditeurs multiplient audits et régulations. SAP ce n'est pas un secret en est l'exemple flagrant et si vous êtes client de longue date avec un ancien produit il y aura des points de frictions avec les achats", prévient Franklin Brousse qui préconise pour le moment d'adopter le status quo et de résister en attendant d'avoir des "armes" jurisprudentielles pour négocier.

Le mode SaaS présente donc un intérêt pour les projets court terme et principalement si vous souhaitez automatiser et externaliser des fonctions ou services qui ne présentent pas d'enjeux pour l'entreprise. "Nous utilisons le SaaS pour les projets de commodité. Sur les projets à enjeux liés à notre coeur métier nous privilégions le Premise", indique une responsable achats logiciel du secteur aéronautique.

A lire aussi :

[Tribune] Le coût invisible des logiciels d'entreprises

Comment bien gérer ses actifs logiciels grâce au SAM ?

[Tribune] Quel est le coût réel d'un audit logiciel?