Beaucoup de partenaires Microsoft français (Gold et Silver Partners) ont eu la surprise de recevoir au cours des 18 mois écoulés un courrier recommandé avec A/R de la part de l’éditeur concernant les licences MSDN.
Il s’agissait d’un rappel sans sommation des règles d’usage des licences contractées au travers du programme de partenariat Microsoft : partenariat de type Partenaires Solutions, Partenaires Développement ou Bizspark.
Le courrier invitait le partenaire à évaluer son niveau de (non)conformité logicielle, à renseigner le bilan ainsi effectué sur le site Microsoft et à régulariser au plus vite sa situation par l’acquisition de licences « Commerciales », en opposition aux licences Partenaires déjà contractées… Vous vous dites sans doute que vous n’auriez pas dû signer ce recommandé !..
En effet il existe une dichotomie définie par Microsoft entre ces deux groupes de licences : les licences Partenaires (souscrites à travers le programme de partenariat, avec un paiement à l’année) sont destinées à un usage interne de l’entreprise, les licences Commerciales (souscrites ou acquises à travers un accord de licences en volume) sont destinées à un usage interne et externe à l’entreprise.
Si l’on comprend bien cette différentiation sur les solutions Microsoft de type infrastructure (type Windows Server, Exchange, SharePoint,…), celle-ci est beaucoup plus complexe à appréhender dans le cadre des licences de type développement comme Visual Studio et MSDN.
En effet les licences de type infrastructure Partenaires sont destinées aux architecture internes des partenaires (jusque-là c’est facile !), dans un but de formation et d’usage au quotidien des solutions, de façon à ce que le partenaire Microsoft soit plus facilement prescripteur de ces solutions chez le client final. La restriction d’usage interne évite notamment que le partenaire puisse utiliser ces licences pour fournir un service commercial direct au client final (par exemple l’hébergement de sa messagerie)
Dans le cas des licences de type développement, la définition des droits d’usage (et des restrictions d’usage) des licences partenaires s’accompagne d’une notion de génération d’un « chiffre d’affaires direct »
Que signifie cette notion ? Si l’on se réfère au site Partenaires Microsoft, un chiffre d’affaires direct est le résultat d’une activité de consulting, de personnalisation d’application packagée ou la création d’une application personnalisée pour un client, moyennant des frais.
Pour autant il est aussi précisé sur le site, ainsi que dans un livre blanc réalisé par IDC, hébergé sur le site Microsoft, que le partenaire dispose d’un droit d’usage des outils de développement pour des activités générant un « chiffre d’affaires indirect », comme création d’une application packagée, pouvant être ensuite revendue au client final (“Partners can use MSDN subscriptions for indirect revenue-generating activities, such as building a packaged application on the Microsoft platform, which they can then market and sell to their customers”). Avez-vous parfaitement compris la différence entre la personnalisation d’une application packagée et la création d’une application packagée et la façon de juger des deux typologies d’applications et de leur mode de commercialisation vis-à-vis du client final ? Personnellement nous cherchons encore.
Si l’usage en interne de solutions d’infrastructure reste techniquement compréhensible, l’usage purement interne d’une solution de développement pour un partenaire dont la raison d’être est justement de développer des applications pour ses clients reste un paradoxe.
Imaginez une nouvelle restriction sur les licences Partenaires d’infrastructure de type messagerie qui imposerait aux partenaires Microsoft l’échange de mails en interne uniquement… et l’obligation d’acquisition de nouvelles licences de messagerie en cas d’échange de mails avec l’extérieur de l’entreprise, et vous aurez une bonne vision de ce paradoxe !
Peu de partenaires Microsoft avec qui nous avons échangé envisagent d’équiper leurs équipes de développeurs de deux licences Visual Studio par personne (une pour l’interne et une pour l’externe, donc), ou de segmenter leurs équipes entre des développeurs internes (par définition peu nombreux ou souvent inexistants) et des développeurs externes. Cette campagne de conformité logicielle aura eu l’intérêt de les questionner sur l’utilité des licences MSDN souscrites à travers le programme de partenariat et de la nécessité de mettre en œuvre une politique d’optimisation des licences Microsoft, que, pour des raisons de stratégie commerciale, l’éditeur les avait dispensés de définir jusqu’à présent.
Parmi les pistes d’optimisation on pourra, par exemple, préconiser l’usage ciblé des différents niveaux de version de Visual Studio/MSDN : utilisation de la version Pro plutôt que d’équiper tous les développeurs de la version Premium, ou même l’usage de Visual Studio Express si les contraintes projet et les restrictions d’usage s’y prêtent. Il y a 6 versions de Visual Studio… de quoi optimiser ses achats ! Les idées d’optimisation dans l’organisation du delivery ne manquent pas non plus.
Dans ce paradoxe licencing, l’intérêt du programme de partenariat développeurs Microsoft devient même plus évident pour les clients finaux eux-mêmes que pour les partenaires Microsoft (!!), à la condition que le client final ne développe que pour ses besoins internes… ce qui est bien souvent le cas
On pourra en conséquence s’interroger sur la pertinence commerciale de cette campagne de conformité visant les prescripteurs des technologies Microsoft chez les clients finaux, alors même que la stratégie de l’éditeur repose en grande partie sur une démarche indirecte, via ses partenaires. Il est à parier par extension que l’on verra beaucoup moins de versions Visual Studio Ultimate utilisées par les partenaires Microsoft lors de démonstration clients ou de salons développeurs, peut-être même certains partenaires feront le choix d’une approche Java/Eclipse selon les cas… Vous avez dit “contre-productif” ?