Duquesne Group Duquesne Group

English version
Recherche et Analyse

Pour éclairer les décideurs dans le domaine de la Continuité d'Activité et de la Sécurité de l'Information, Duquesne Group propose ses analyses et réflexions issues de ses réalisations concrètes en clientèle. Observation critique du terrain par nos experts, contacts permanents avec les principaux acteurs du domaine et expérience vécue dans nos missions de conseil sont nos principales sources. Contactez-nous pour en savoir +
French version
Research

To support decision makers in the management and optimisation of information systems, Duquesne Group delivers in-depth analyses of information technologies, their implementations and their markets. Our research is based on critical observation of the market by our analysts and their on-going contacts with the vendor community, together with hands-on, practical experience from our consulting work. Contact us to find out more


Pour un sourcing logiciel performant

Un Rapport d'Analyse Duquesne Research



Le sourcing de logiciels ressemble souvent à une sorte d’affrontement asymétrique entre des éditeurs aguerris et des acheteurs pris au piège. Ce rapport d’analyse met en exergue la nature de cette relation, les enjeux qui la sous-tendent, et les écueils les plus courants, pour proposer des pistes en vue d’en optimiser l’issue.



Pour un sourcing logiciel performant

Une problématique complexe pour l’entreprise

Au moment où l’industrie logicielle vante les mérites du SaaS (Software as a Service), et où un nombre croissant d’acteurs du marché prônent une sorte de « dématérialisation » de l’infrastructure informatique via le « cloud computing », le spectre des options ouvertes à l’Entreprise en matière de sourcing de solutions logicielles s’élargit encore et se complexifie.

Quel que soit le format retenu pour la fourniture d’une telle solution logicielle – par nature support de processus plus ou moins vitaux– il importe de comprendre que l’on se situe dans une relation durable, stratégique mais aussi asymétrique avec l’éditeur.

Par souci de clarté de notre exposé nous excluons volontairement dans ce qui suit l’Open Source dans ses aspects spécifiques même si les règles énoncées ci-dessous trouvent un champ d’application, De même nous ne traiterons pas ici des problématiques particulières où la propriété intellectuelle est partagée entre éditeur et client.

Un acte de management structurant, éminemment stratégique

L’utilisation d’un logiciel engage l’avenir de l’ entreprise (ou de l’organisation) bien plus que tout autre équipement. Les choix ainsi effectués sont structurants et souvent difficilement réversibles. Car si l’on peut envisager de changer de fournisseur de serveur, de stockage ou même de prestataire de services, changer de plateforme applicative ou d’outils de gestion ne pourra se faire qu’au prix d’un effort financier, et surtout organisationnel, considérable.

Mais, au fil de cette relation, il est inévitable que les intérêts, les business models, les priorités et aussi les fortunes économiques des acteurs - entreprise d’un côté, éditeur de l’autre -, avec notamment leur aspect le plus visible, les opérations de fusion-acquisition, évoluent de manière indépendante, voire divergente.

Le sourcing logiciel est donc un exercice éminemment stratégique, en ce qu’il conduit à allouer des ressources de l’entreprise à une certaine manière de mettre en œuvre ses processus, et qu’il peut déterminer largement l’aptitude de l’organisation à réagir à son propre environnement.

Un processus permanent, avec une dimension tactique déterminante

C’est aussi, inévitablement, un exercice permanent, qui ne se termine pas avec la signature d’un contrat. La relation avec l’éditeur consiste à gérer des intérêts au moins indépendants et souvent divergents. Parallèlement, l’obtention de la qualité n’est jamais acquise quelle que soit la sophistication ou la part de marché de l’éditeur et de ses partenaires. Cet exercice permanent est donc bien un processus de management. Dans ce processus de management, le volet relation avec les entités utilisatrices et avec les décideurs et la direction sera également une composante majeure. La DSI ou l’acheteur informatique se trouvent en effet généralement entre marteau et enclume…

Enfin, le sourcing logiciel peut recourir à des tactiques spécifiques pour créer, à des moments bien précis, les conditions d’une bonne négociation. Ces tactiques ne seront productives qu’à ces moments précis et seulement si elles s’inscrivent dans une vision stratégique globale et un management rigoureux de la relation client – éditeur. Ces tactiques dépendent du moment relationnel (acquisition initialle, renégociation de maintenance, ...), de la nature de l’entreprise cliente et de l’éditeur, ou encore du contexte économique.

Dans cette note de recherche, nous nous situons essentiellement dans un contexte de sourcing de type acquisition initialle mais une grande partie de l’analyse s’applique aussi à la renégociation.

Une relation asymétrique

Il faut bien constater que dans cet exercice complexe, l’organisation utilisatrice se trouve confrontée à une situation largement asymétrique :

Côté Client : En tant qu’entreprise, elle opère par nécessité des systèmes d’information, qui remplissent une fonction clef de support de ses processus, mais ne constituent pas en eux-mêmes la raison d’être de l’entreprise. L’acquisition de solutions logicielles est donc souvent vécue comme un « moment », un point de passage, et l’entreprise ne mobilise que ponctuellement ses forces vives (notamment au niveau Direction) pour traiter le sujet. La tentation peut même être grande, de chercher à « évacuer » le sujet au plus vite, ou, pire, de vouloir (consciemment ou non) évacuer des problèmes organisationnels à travers un choix de solutions.

Côté Fournisseur : L’éditeur, quant à lui, a pour vocation, raison d’être et objectif premier, la vente de ses solutions et la génération de revenu, autant que possible récurrent, à partir de ces solutions. Il est donc entièrement mobilisé sur la gestion de sa relation avec ses clients. Dans cette relation, la qualité ou la satisfaction du client sont avant tout des facteurs de légitimation du revenu courant et de préservation du revenu futur.

Le Sourcing Logiciel performant sera donc celui qui réduira cette asymétrie, sans parvenir toutefois (en général) à l’éliminer.

Le processus global de sourcing logiciel

Dans cette note de recherche, nous nous situons essentiellement dans un contexte de sourcing de type acquisition initialle mais une grande partie de l’analyse s’applique aussi à la renégociation.

Le processus global de sourcing passe en général par les phases suivantes :

- Analyse du marché et sélection des réponses « fonctionnellement » pertinentes
L’outil clef de cette phase est la « Request For Information » (RFI)

- Examen de la faisabilité et qualification des candidats clefs (ceux de la « short list »)
Outil clef de cette phase : Request for Quotation / Price (RFQ ou RFP)

- Sélection du candidat à retenir et phase de négociations exclusives
A cette étape on peut passer par une « Request for Offer » incluant une base de négociation contractuelle. On inclura dans cette phase toutes les problématiques d’alignement des conditions sur l’évolution du marché et des conditions générales (publiques) tarifaires et contractuelles de l’éditeur et de ses concurrents.

- Contractualisation
Dans cette phase seule la « mécanique » de gestion de la relation reste à établir. Ainsi, les « contrats de progrès » ou les clauses de « benchmarking » ou de Qualité auront été traitées en amont, car partie intégrante du « contenu » des accords.

- Gestion de la vie du contrat et de la rélation fournisseur

Une démarche volontariste doit permettre au Client d’inscrire ces étapes dans un planning strict qui interdira les dérives, tant de planning que de périmètre, qui ne profitent jamais au projet vu dans son ensemble. Maintenir le « tempo » du processus global, et notamment de la négociation à proprement parler, est essentiel pour au moins deux raisons clefs :

- ne pas « redonner la main » aux éditeurs pour « restaurer l’asymétrie relationnelle » et maintenir le « pression »

- ne pas laisser la négociation s’étaler sur une période trop longue dans laquelle les postulats de départ peuvent évoluer suffisamment pour rendre caduques nos hypothèses de départ (par exemple :contexte marché, ou priorités stratégiques du client)

Tactiquement, le maintien du « tempo » nous permet de ne pas « rater » des échéances comme par exemple la conclusion d’un accord dans une période favorable (exemple : cloture d’exercice de l’éditeur). Il demeure naturellement toujours possible de ralentir ce tempo quand on le juge stratégiquement ou tactiquement approprié.

La conclusion du contrat ne marquera pas la fin du processus de gestion de la relation avec l’éditeur, mais bien simplement le « passage » à un autre état, celui de « vie du contrat ».

Avant de passer en revue quelques étapes clés du processus de sourcing, il est indispensable de prendre en compte deux pré-requis fondamentaux. En effet, évaluer la pertinence d’un éditeur et de ses offres, puis gérer efficacement les phases de négociation, de conclusion et de vie des contratssuppose que : ent satisfaits deux pré-requis essentiels :

- D’une part, une véritable définition des besoins (y compris dans ses incertitudes) agréée par toute l’entreprise

- D’autre part, une claire compréhension des business models des éditeurs considérés pour déterminer ce qui peut être demandé de manière réaliste aux éditeurs.

Une fois ces deux pré-requis traités, on sera en mesure de comprendre les offres des éditeurs dans toutes leurs dimensions et donc de savoir ce que l’on peut en attendre. Il sera alors possible d’appliquer des tactiques de négociation efficaces, visant à obtenir des conditions à la fois favorables et atteignables.

Premier pré-requis : documentation des besoins

Ce pré-requis évident est connu de tous. Toutefois, savoir définir et maîtriser les besoins relève le plus souvent de la résolution de la quadrature du cercle tant les métiers sont prompts à justifier l’urgence de disposer des outils nécessaires au maintien de la compétitivité de l’entreprise. Il est bien sûr inenvisageable de s’y opposer. Mais c’est en se positionnant comme facilitateur de la communication entre services et de l’élaboration d’un consensus « opérationnel », c'est-à-dire pertinent et traduisible en spécifications concrètes, que la DSI pourra garder la maîtrise du processus et gérer par anticipation les évolutions possibles.

Le point de départ est, bien entendu, une connaissance approfondie de l’existant et des besoins de l’entreprise appuyée sur une relation étroite avec les entités utilisatrices et le management. . Cet inventaire formalisé des besoins immédiats et futurs portera aussi bien sur les fonctionnalités que sur la volumétrie, sans se soustraire aux exigences de flexibilité, de contrôle et de sécurité.

Rien n’est pire que de signer un contrat inadapté au besoin réel évalué dans sa durée. Pour prendre un exemple : de nombreuses entreprises ont connu des situations où l’éditeur, un an après l’implémentation de son logiciel, bien que sélectionné après une étude approfondie, vient réclamer un complément de facture substantiel, non budgété, parce que le nombre d’utilisateurs ou le nombre de processeurs utilisés ont fortement augmenté par rapport au chiffrages initiaux.

Si le capacity planning est souvent d’usage dans les DSI, l’implication des directions utilisatrices dans leur propre planification doit permettre de budgéter sans dérive majeure sur 3 voire 5 ans. Et si l’évolution de la volumétrie est un paramètre critique, il faut veiller aussi à ne pas se laisser entrainer vers l’adjonction contractuelle de fonctionnalités dont la nécessité n’est pas prouvée et dont le coût sera tôt ou tard répercuté, au plus tard sur la redevance de maintenance. Mieux vaut donc se réserver une latitude budgétaire pour envisager l’adjonction de modules additionnels en fonction de l’évolution des besoins.

A ce stade, les questions à se poser sont :
- En terme de besoins, a-t-on bien envisagé la dynamique de l’utilisation des logiciels concernés ?
- L’influence de cette utilisation sur les ressources physiques a-t-elle bien été prise en compte dans les chiffrages et les budgets ?
- Enfin, aura-t-on à élargir le périmètre logiciel à d’autres fonctions ou modules ?

Deuxième pré-requis : décryptage des business models des éditeurs

Le deuxième préalable est vital mais moins pratiqué que l’inventaire des besoins. Il s’agit de parvenir à une vraie connaissance des business models des différents éditeurs, afin de décripter les véritables mécanismes structurants de leurs offres. La compréhension de l’économie, de la culture des éditeurs, et une connaissance précise de leurs particularismes pour chacun d’entre eux, permettra une maîtrise fine des tactiques de négociation appropriées.

Tous les éditeurs ont aussi certaines grandes caractéristiques en commun.

La première caractéristique du logiciel commercial est que son coût marginal est quasi nul : produire une copie supplémentaire de MS Office ne coûte quasiment rien à Microsoft. On pourra cependant objecter que ceci n’est pas vrai en termes de support, pour lequel le poids des coûts variables est plus important.

C’est pourquoi il faut bien comprendre qu’un éditeur a en réalité trois métiers de base, tous essentiels à son activité, mais avec des contraintes très différentes :

- un métier d’industriel du développement logiciel
- un métier de vendeur de ses solutions
- un métier de prestataire de services et de maintenance

Ces trois métiers ont des adhérences : l’industriel a besoin des vendeurs et des prestataires de support pour affiner sa connaissance des besoins clients et élaborer les évolutions de ses logiciels, le commercial dépend de la qualité perçue des logiciels et de la tenue des délais par le développement, le support doit remonter les problèmes de bogues au développement, etc…

Cependant, chacun de ces métiers fonctionne de manière spécifique, avec sa propre économie et ses propres méthodes. Les éditeurs « mixent » - en fonction de leur histoire et de leur stratégie - ces trois métiers avec une pondération qui leur est spécifique, et en général pas rapidement modifiable.

Naturellement, tous les éditeurs ont des aspects spécifiques qu’il convient d’analyser avant toute négociation (idéalement avant toute approche). Parmi eux l’on peut notamment citer :

- Les aspects de dominance stratégique : structure financière du bilan, date de clôture d’exercice, vulnérabilité M&A, part de marché, chiffre d’affaires, profitabilité, puissance de la « franchise marché » (très forte par exemple chez Microsoft, SAP ou Oracle)

- La nature de l’offre et son « packaging » : logiciel pur classique (SAP, Microsoft, SAS), logiciel sur plateforme (soft système IBM, Cisco) SaaS (Google, Salesforce.com), ouverture ou non sur d’autres technologies (cloud, etc…), nature des contrats (location, vente, SaaS, etc…), durée des licences (perpétuelle, limitée…)

A partir d’un ensemble de caractéristiques communes, c’est par conséquent en appliquant une « grille de lecture » au cas spécifique de chaque éditeur que l’on pourra comprendre son business model et définir les meilleures approches, y compris tactiques, pour parvenir à des accords mutuellement satisfaisants.

Le métier « industriel du développement »

Il doit pouvoir gérer des plannings tendus et optimiser ses coûts. Il définitdes roadmaps dont les priorités sont arbitrées entre besoins exprimés, exigences marketing, faisabilité technique et ressources disponibles. Ces roadmaps seront rarement en pleine adéquation avec les attentes de tel ou tel client particulier, et il sera en général illusoire de chercher à les infléchir significativement. Quant au client qui aura vu dans le développement d’extensions spécifiques (même achetées à l’éditeur lui-même) le moyen de contourner les insuffisances de son logiciel, il sera vite confronté à des coûts exorbitants pour « suivre » les versions ou maintenir ses extensions.

Il faut donc comparer culture de développement interne (SAS Institute) versus culture d’acquisitions (CA), degré d’ouverture aux demandes client (nulle chez Microsoft, forte chez de petits éditeurs), track record d’annonces versus livraisons.

Le métier « commercial»

Il a en général le double objectif d’étendre la base client et d’optimiser (lire : maximiser) la valeur extraite de chaque client existant. Un nouveau client est donc non seuelement une source de revenu immédiat, mais aussi une promesse de revenu récurrent et peut, à ce titre, contribuer à la valorisation boursière de l’éditeur. Selon la stratégie de l’éditeur, cet aspect pourra l’amener par exemple à consentir de forts rabais sur le prix initial des logiciels pour faire croître sa base de revenu récurrent. Ces rabais seront plus ou moins « habillés » selon les pratiques commerciales de l’éditeur : licences supplémentaires gratuites, produit additionnel gratuit (mais inclus ensuite dans la base de calcul de la maintenance …).

Dans la pratique, pour bien apprécier les tactiques utiles pour la négotiation avec un éditeur donné, il faut comprendre son modèle de commercialisation :

- direct (appuyé en priorité sur une force de vente performante maintenue sous « pression » (SAS, CA…),
- indirect (appuyé en proirité sur un réseau de revendeurs en volume (Microsoft),
- centré « éco-système » avec un réseau de partenaires à valeur ajoutée (SAP).

Bien évidememnt la plupart des éditeurs pondèrent ces trois approches de manière spécifique pour élaborer leur propre modèle, mais toujours avec une dominante - qui se détermine en grande partie à partir de leur « culture » - et qui oriente leur stratégie et leurs pratiques commerciales.

Cette compréhension du modèle de commercialisation est nécessaire pour comprendre la structuration et la rémunération des équipes de vente, leur plus ou moins grande agressivité commerciale, la structure du catalogue et grilles de tarification, et également la gestion des contrats (y compris le volet support et maintenance). Une compréhension claire de ces aspects permettra d’optimiser les choix tactiques à opérer au cours de la négociation.



Le métier « prestataire»

Il est le côté « générateur de revenu récurrent » de l’éditeur. Ceci peut prendre des formes très diverses, par exemple le renforcement des capacités de service en propre ou l’animation d‘un écosystème de partenaires plus ou moins vaste (SAP) et plus ou moins en concurrence avec l’éditeur….

Ici encore, il sera important de comprendre le modèle de services (part du direct versus indirect ou écosystème), l’organisation du support, et le modèle économqiue des activités de support.

Une compréhension de tous ces aspects, présents chez tous les éditeurs permet déjà d’identifier des approches « perdantes » comme la recherche d’une maintenance gratuite. En effet, les coûts variables associés rendent nécessairement, à terme, l’opération désastreuse pour l’éditeur. Elle permet aussi de comprendre les « invariants » de la stratégie des éditeurs. La nécessité de générer une rentabilité du support est ainsi un invariant pertinent chez tous les éditeurs à vocation professionnelle (ce serait moins vrai chez certains éditeurs grand public comme Micro Applications, qui peut voir le support comme un centre de coût ou une obligation légale non rentable liée à la garantie).

L’histoire et la culture de tel ou tel éditeur peut aussi déterminer ses invariants spécifiques. Par exemple, la culture de pression sur les équipes de vente prévalente chez Oracle détermine des comportements commerciaux plutôt agressifs voire conflictuels, y compris avec les « bons clients » (dans la culture Oracle, « bon client » veut dire « cash cow »). Si l’on prend l’exemple deSAP, sa culture industrielle d’origine germanique induit une vision du client s’adaptant au produit plutôt que l’inverse. De même, on n’hésite pas chez SAP à forcer auprès des clients, dans la plus pure démarche « top-down », des changements contractuels importants, comme récemment en matière de maintenance. Ce type d’invariant spécifique ne peut être que très difficilement modifié dans le court terme et tenter de le faire peut affaiblir considérablement l’éditeur.

Comprendre les pratiques commerciales et les concessions possibles

Concrètement, ce travail de décryptage du business modèle permet en particulier d’éclairer et de comprendre les pratiques contractuelles de l’éditeur et ainsi, lors de la négociation, de bien viser des concessions qu’on peut éventuellement obtenir.

En effet, la complexité des contrats logiciels et des modèles tarifaires laisse perplexes de nombreux utilisateurs et acheteurs. Certains éditeurs choisissent de vendre, pour une durée plus ou moins longue, les droits d’utilisation (achat de licences perpétuelles ou non) de leurs logiciels (Computer Associates ou Microsoft par exemple), alors que d’autres préférent les louer (paiement de redevances mensuelles d’utilisation) tels SAS Institute par exemple.

De même, la tarification peut dépendre de facteurs assez différents :
- du nombre d’utilisateurs (le plus fréquent, mais pas toujours le plus simple entre utilisateurs actifs ou nommés, voire entre classes différenciées d’utilisateurs)
- de la puissance informatique utilisée (Oracle par exemple), exprimée en nombre de cœurs ou de processeurs, ou encore en « bon vieux MIPS » voire
- du nombre d’enregistrements effectués comme sur certains modules de logiciels d’achats (type SAP) ou de gestion de ressources humaines
- voire du chiffre d’affaire de l’entreprise cliente, une sorte de « modèle fiscal » qui se rapproche furieusement d’un impôt de l’éditeur sur la réussite de son client

Du point de vue de l’éditeur, toute cette alchimie commerciale doit permettre avant tout d’assurer des revenus les plus stables possibles et proportionnels aux coûts de développement et de support. Dans un second temps la tentation « fiscale » (cf supra) est grande pour l’éditeur, Il va donc essayer d’ajouter à ses revenus une participation aux bénéfices supposés que ses clients retirent de l’usage de ses produits.

Un éditeur peut aussi vouloir utiliser son modèle contractuel et tarifaire pour fidéliser (lire : garder captifs) ses clients, voire pour leur imposer de le suivre rapidement dans ses évolutions de versions et de releases. Ceci a pour effet induit de maintenir les utilisateurs sur la « face avant » de leur vague d’investissement sur le produit, une position où l’on ne peut que difficilement « sortir » puisqu’on n’a pas encore amorti ou rnetabilisé l’investissement sur la dernière version… C’est ainsi qu’il faut par exemple comprendre le modèle « Software Assurance » de Microsoft.

Coté client, l’on peut obtenir des concessions sur les aspects contractuels qui ne remettent pas en cause le business model de l’éditeur, par exemple les montants de licence initiale ; il ne faut par contre pas chercher à « tordre » les modes de calcul au point de casser ce business model. Ainsi, payer des licences et rechercher la gratuité de leur maintenance est un non sens : l’éditeur n’a pas pour vocation d’engranger des revenus qu’il va économiser pour payer ses charges au fil du temps, puisqu’il n’y aurait plus de revenus de licences

Par contre, le Client peut chercher à se donner quelques « degrés de liberté » pour l’avenir, tout en réduisant ceux de l’éditeur. On mettra donc en balance l’acceptation d’un modèle tarifaire et de services avec l’exigence que l’éditeur s’y tienne et que des modalités raisonnablement applicables de révision contractuelle (benchmark, contrats de progrès, etc…) soient mises en place.

L’une des responsabilités-clefs du décideur est donc d’apprécier si le business model et les pratiques contractuelles et tarifaires d’un éditeur sont suffisamment en adéquation avec les attentes, les contraintes et les exigences de l’entreprise.

Questions à se poser à ce stade :
- Assurez-vous d’avoir bien compris la logique économique propre de votre éditeur
- Son schéma de couverture de ses coûts par les revenus (auxquels vous allez participer) est-il viable pour vous ?
- Si rien ne vous choque aujourd’hui au regard de vos perspectives d’évolution, où cela vous’entraine-t-il ? Si vous n’êtes pas confortable, il vaut mieux renoncer.


Dans la suite de ce document, nous nous focalisons sur trois aspects delicats du processus de sourcing logiciel : la négociation, la contractualisation et la gestion de la vie du contrat.

Pour que la négociation soit mutuellement profitable

La sélection d’un logiciel par ses futurs utilisateurs repose essentiellement sur le jugement porté sur son aptitude fonctionnelle à remplir les tâches confiées. En revanche, la valeur ajoutée tangible de la négociation d’achat va trop souvent reposer sur l’ampleur du rabais obtenu par rapport au prix tarif annoncé au départ. On sait, en effet, que le principal indicateur pour quantifier le mérite des négociateurs reste (trop souvent) la mesure des économies réalisées.

Il importe d’aller bien au-delà d’un tel objectif (« remise tarifaire »), d’autant qu’en général cette « concession » ne porte que sur l’une des composantes – certes la plus visible ( en tous cas initialement) mais pas forcément la plus déterminante du « coût total de mise en œuvre ».

La clef « primaire » d’une négociation réussie repose sur la bonne compréhension du « mode d’emploi » des différentes composantes de l’accord à atteindre :

- L’« accord sur la chose et le prix » (cœur du contrat selon le Droit Civil) : il définit d’abord ce que l’on va recevoir, et ensuite la compensation financière que l’on accepte de payer en contrepartie. Il s‘agit bien du « produit » logiciel (au sens large) et de la grille tarifaire. Nous appellerons ce composant « contenu de l’accord » ; seuls les experts métier (incluant les directions générales) et techniques (la DSI notamment) peuvent décider de la pertinence de ce contenu.

- La formalisation de la relation par un « contrat » écrit dont la grande majorité des clauses ne servira qu’à gérer des désaccords et conflits éventuels. Ce document doit donc permettre aux parties d’assurer le bon niveau de fluidité dans leurs relations (à quel moment passe-t-on au mode conflictuel, avec quels pré-requis, et comment conduit-on le dénouement du conflit ?)

Il est essentiel de comprendre que l’importance relative de ces deux composantes dépendra avant tout du pouvoir de négociation du client. Pour beaucoup de PME, ce pouvoir sera faible, voire très faible, en face de grands éditeurs. Avec les grands comptes, il peut en aller autrement, mais cela n’est pas automatique. On devra donc « doser » l’effort pour privilégier le volet « contenu » en focntion de sa propre position de négociation, de l’importance stratégique de la solution recherchée, et aussi de l’éditeur et de sa capacité à s’inscrire dans une relation opérationnelle efficace avec le client (c'est-à-dire son aptitude à ne pas se retrancher trop vite derrière les clauses du contrat)

Les deux volets n’étant pas indépendants, la conduite du processus de négociation aura un impact décisif sur le résultat obtenu.

Lorsque l’éditeur est en place, le levier principal consiste à lui faire appliquer le bénéfice éventuel de nouvelles offres tarifaires standards qui seraient apparues postérieurement à la signature du contrat initial et qui, pour des raisons de compétitivité, se sont affinées et souvent améliorées.

Dans un souci de préservation des revenus, les commerciaux de l’éditeur ne sont naturellement pas spontanément disposés à faire bénéficier leur client, déjà utilisateur, d’offres plus avantageuses d’un point de vue stictement financier.

Il est donc indispensable de bien suivre les évolutions de l’offre marketing de l’éditeur en place afin de détecter les éventuelles offres intéressantes dont personne ne viendra vous parler. Ceci sous réserve d’avoir fait inclure dans le contrat un mécanisme de révision des conditions.

Il est généralement plus facile d’accéder à une nouvelle tarification lorsque mes perspectives de besoins évoluent quand bien même le contrat de base l’aurait prévu, car face à un potentiel d’affaires nouvelles l’éditeur peut être remis en concurrence et vouloir, par un effort supplémentaire, capter cette perspective d’accroissement de revenu.

Le contrat : socle contraignant d’une relation durable

Laisser un flou s’installer entre client et fournisseur ne peut finir qu’en malentendu préjudiciable à leur relation, quel qu’en soit le gagnant apparent à première vue.

Gardons toujours en tête qu’en affaires, entre client et éditeur, c’est l’intérêt réciproque qui permet d’avancer. Tout événement nouveau pour l’une des parties va se traduire en opportunité pour l’autre, avec son lot de risques. Une relation pérenne se doit donc d’être équilibrée.

Il convient donc d’observer que le contrat fournit bien la trame formelle de la relation avec le fournisseur. Ce contrat doit être vu par les utilisateurs comme une composante clef de leur architecture logicielle : il détermine directement ce que l’entreprise pourra ou non réaliser. Ainsi, un applicatif tarifé par utilisateur « nommé » pourra se révéler fort couteux si l’on veut ouvrir l’application à de larges publics hors de l’entreprise.

Pour compléter la négociation, l’adaptation des contrats standards des fournisseurs est parfois envisagée pour tenir compte de spécificités parce que les directions juridiques de certains groupes cherchent à harmoniser leurs conditions fournisseurs autour de leurs propres règles. Mais trop souvent les négociations juridiques n’ont pour objet, lorsqu’elles sont possibles, que d’infléchir l’application de dispositions générales.

Le risque majeur en la matière est de laisser travailler les juristes entre eux, ils passeront consciencieusement des mois voire plus d’une année (oui ! ça s’est vu…). Le temps qui leur sera accordé sera d’ailleurs d’autant plus long que le montant du contrat est élevé.
En définitive tous ces efforts n’auront, le plus souvent, pas plus d’effet que de s’acharner sur les virgules du contrat.

Outre le fait que, quelle que soit l’importance du marché, l’éditeur ne remettra jamais en cause l’équilibre de ses revenus et de ses coûts que ses contrats sont sensés protéger, il faut bien observer que l’objectif du processus de négociation discuté plus haut est avant tout de « border » l’aspect contenu contractuel. Il convient donc, lorsque le client use de toute sa puissance d’achat pour contraindre l’éditeur à infléchir ses conditions contractuelles, de veiller à focaliser ce remaniement non sur la satisfaction des exigences des juristes du client mais bien exclusivement sur la préservation des conditions clefs de la bonne réalisation du « contenu » de l’accord, en principe élaboré pour apporter un équilibre raisonnable de type « win-win ».

Un contrat trop aprement négocié peut de plus s’avérer être une catastrophe économique après quelques années seulement, à cause d’un particularisme recherché qui peut se payer soit par un isolement juridique soit par une dérive non contrôlée qui fragilise toute tentative de recours amiable.

On portera plutôt ses efforts pour se prémunir, dans la mesure du possible, contre des évolutions contractuelles et tarifaires majeures, a minima en prévoyant des clauses de sauvegarde permettant de s’en tenir à un schéma tarifaire existant, et mieux en imposant un processus de renégociation en cas de changement majeur de périmètre.

D’une façon générale nous déconseillons donc le sur-mesure contractuel. La nécessaire personnalisation de la relation (plus forte au niveau d’un grand compte et pour une application très stratégique, plus faible en PME ou pour une application de « support ») devra se confiner aux points définis plus haut (contenu et ajustement aux évolutions marché).

Enfin, il s’avérera judicieux de consacrer quelques efforts à batir une sorte de « jeu d’essais » afin de confronter les termes contractuels à des situations imaginées, aussi variées soient-elles, mais plausibles pour en déterminer un degré de solidité du contrat. Le nec plus ultra en la matière est bien sûr de confier à un tiers expérimenté, garant de neutralité, cette tache de test de résistance et d’adaptabilité au réel des clauses contractuelles.

Ainsi nous ne saurions trop attirer l’attention sur le soin particulier qui devra être porté aux clauses liées aux situations de Fusions et Acquisitions qui peuvent affecter l’entreprise. L’impact sur les besoins, sur la tarification et sur les contrats en cours mérite la simulation de différents cas pratiques afin de mesurer l’impact de tels bouleversements par rapport aux bases de l’accord initial.

Questions à se poser :
- Dois-je vraiment faire modifier les conditions contractuelles proposées ?
- La proposition globale ne répond-elle pas vraiment à mes attentes ? Ai-je une alternative ?
- La participation à un groupe d’utilisateur qi travaille sur le sujet n’est-elle pas un meilleur vecteur de progrès ?



Gestion de la vie du contrat et de la relation fournisseur

On peut aisémernt identifier un certain nombre de « moments forts » dans cette relation : l’acquisition ou la conclusion du contrat initial, les étapes de renégociation des contrats de service et de support notamment, les dénonciations de contrats. Néanmoins, on ne doit pas négliger la « vie du contrat » globale, qu’il convient de formaliser en amont de la signature. Ainsi on définira la tenue de comités de pilotage, de qualité, etc., dont les « livrables » auront un impact défini contractuellement.

En effet, les autres moments clefs de la relation pourront être définis soit par l’éditeur (c’est le cas le plus fréquent) soit par l’utilisateur. Les initiatives éditeur peuvent inclure des révisions de conditions (cf le support SAP récemment), ou des redéfinitions de périmètre (des options jusque là incluses dans le produit deviennent payantes, etc…)

En dépit d’un balisage contractuel attentif, il est donc capital de veiller à l’évolution stratégique de la tarification de l’éditeur en fonction du temps, car l’évolution non contrôlée et non renégociée de ses modes de calcul peut radicalement remettre en cause les choix initiaux (exemple Microsoft).

En face de cette gestion proactive de la relation par l’éditeur, les grands comptes devraient systématiquement instaurer leurs propres « moments », notamment en imposant à leur éditeur des points « déploiement » fréquents et formels dans la phase de mise en place (avec l’ensemble des acteurs y compris les intégrateurs), puis des points qualité réguliers, voire des revues stratégiques. Tout ceci sera bien plus facile à réaliser si on l’a prévu lors de la phase de négociatione et de contractualisation.

Encore une fois, la difficulté du management de la relation fournisseurs réside surtout dans l’asymétrie plus ou moins marquée de cette relation. Comme nous ne pouvons, en tant qu’entité utilisatrice, nous mobiliser exclusivement sur cette seule relation, il importe que nos processus nous permettent d’anticiper les phases les plus actives de cette relation et d’y arriver préparés. Souvent, en effet, les entreprises utilisatrices se trouvent dans une situation d’urgence faute d’anticipation suffisante. Or, dans une négociation, celui qui est pressé … perd !

Conclusion

Nous venons donc de cerner pourquoi le sourcing de logiciels ressemble souvent à une sorte d’affrontement asymétrique entre des éditeurs aguerris et des acheteurs pris au piège. Il requiert donc une démarche méthodologique particulière.

D’abord, la réussite de la négociation et de la contractualisation s’appuient sur les deux piliers examinés précédemment, la maîtrise des besoins et la compréhension de l’économie de nos fournisseurs.

De plus, des processus rigoureux de gestion de la relation fournisseur au fil du temps devront impérativement être mis en place, incluant la planification de l’évolution de l’infrastructure logicielle et de la renégociation régulière des termes de support ainsi qu’une veille permanente et une bonne exploitation des opportunités tactiques.

Enfin, un sourcing logiciel performant vise non pas une « victoire » souvent éphémère sur l’éditeur mais plutôt une relation de type « win-win » dans la durée. De ce fait, il est le gage d’une utilisation fructueuse pour l’entreprise de cette relation de partenariat stratégique.
Thierry Lup
Mardi 29 Octobre 2013

Home Home    Mail Mail    Print Print    Zoom + Zoom +    Zoom - Zoom -    Share Share


Dans la même rubrique :
< >

Duquesne Research Newsletter