Management
Bien négocier la qualité des logiciels
Devant les défauts qui, selon les entreprises, entâchent les logiciels, examen des règles à suivre pour se prémunir et réduire les problèmes dès la négociation. (Mardi 27 août 2002)
     
Les entreprises, ce n'est pas nouveau, se plaignent (voir cet article pour un exemple parmi d'autres), du niveau de qualité des logiciels qu'elles utilisent, particulièrement lorsqu'elles font l'acquisition de solutions intégrées, pour lesquelles les attentes en la matière sont encore plus fortes.

Comment se traduisent ces reproches ? Principalement en matière de failles de sécurité, d'ampleur des bogues, mais aussi et surtout du trop grand cloisonnement des solutions de différents éditeurs, leur faible interopérabilité du fait de l'absence de standard.

A la décharge des vendeurs, beaucoup de problèmes surgissent lorsqu'une entreprise tente de personnaliser à l'excès, d'adapter finement à ses besoins, un outil du marché (surtout quand il s'agit d'une solution intégrée), mais il reste néanmoins vrai que les erreurs des logiciels, quand elles sont effectivement patentes, n'épargnent pas les plus grands éditeurs (Microsoft, Oracle, SAP ou Computer Associates, par exemple, selon étude du magazine CIO sur l'année 2001) et de surcroît donne le plus souvent lieu, aux dires des entreprises, à des correctifs insatisfaisants.

Les étapes de la négociation
Dans un tel paysage, l'étape de négociation avec l'éditeur, lors de l'achat d'une solution, s'avère primordiale, et doit impliquer les DSI, qui parfois se voient court-circuités par les éditeurs au profit des directions générales.
En matière de négociation, qu'il s'agisse d'une réduction importante sur le coût de licence, de formation ou consulting gratuits, plusieurs points doivent être pris en compte, et notamment autour des quatres thématiques suivantes qui sont autant d'étapes de la négociation.

1) Bien impliquer les acteurs de la négociation
Cela signifie tout d'abord réunir l'ensemble des personnes qui pourront apporter des arguments utiles dans la négociation, afin de former, assez en amont, une équipe préparée. Ensuite, cela implique d'inclure, outre l'entreprise concernée et l'éditeur, les rôles des partenaires (intégrateurs, consultants) dans le contrat d'achat.

2) Prendre en compte les spécificités du projet
Evoqué plus haut, le problème d'une trop grande exigence d'adaptation de l'outil aux besoins fins de l'entreprise peut être anticipé en précisant avec la plus grande clarté les besoins. Par ailleurs, les coûts de maintenance et de gestion doivent être également prévus, qu'ils impliquent l'éditeur lui-même voire, comme nous l'évoquons plus haut à propos des phases conseil et intégration, un partenaire-tiers. Le coût global inclut également des coûts cachés issus de problèmes spécifiques, que nous détaillons plus bas.

3) Tirer profit de sa position face à l'éditeur
Nous prendrons deux exemples: le premier consiste à tirer profit, le cas échéant, de la position sur le marché (et notamment sur le secteur d'activité de l'entreprise) de l'éditeur. Faire jouer la concurrence, même en exagérant son importance, peut fonctionner si le vendeur tente de pénétrer un nouveau marché et n'en connaît pas encore parfaitement toutes les caractéristiques.
Le seconde exemple provient du constat, tenu notamment par le Meta Group, du fait que les entreprises achètent souvent, dans l'objectif de faire des économies, des licences supplémentaires. Or, cela peut s'avérer économiquement défavorable suivant l'habilité de l'éditeur, qui trouve là une occasion de prendre le jeu en main. Préférablement, la négociation lors de l'achat d'un logiciel du prix (fixé alors contractuellement) des achats futurs (plan pluriannuel par exemple) de licences supplémentaires, est potentiellement source de réduction de coût.

4) Prévoir les conséquences de problèmes imprévus
Cette dernière thématique/étape nous ramène au sujet de la qualité: le contrat doit bien sûr mentionner quelles contreparties (financières ou sous d'autres formes) l'entreprise recevra en cas de non respect du Service Level Agreement, qui doit couvrir une variété de points de qualité, quelle est la durée du support de l'éditeur, etc.
Plus spécifiques sont les points autour de l'utilisation du logiciel liée à des changements dans le système d'information (transfert sur d'autres postes ou serveurs, par exemple) ou des besoins de sauvegarde (copie de secours du logiciel): de tels usages occasionneront peut-être des pénalités pour l'entreprise. Encore une fois, mieux vaut prévoir avant.
Autre cas de figure pouvant figurer dans le contrat: la faillite pure et simple de l'éditeur. Dans ce cas, une clause peut par exemple assurer à l'entreprise la main sur le code source du logiciel, afin qu'elle assure elle-même, ou via un tiers, l'évolution du produit.

D'une manière générale, la qualité du logiciel (et la qualité du service associé) ne peut se négocier efficacement que lorsque des indicateurs précis de mesure de la qualité ont été mis en place par l'entreprise, ceci afin d'identifier les points à prendre particulièrement en compte, mais aussi de fournir arguments et exemples, lors de futures négociations.
[Jérôme Morlon, JDNet]
 
Accueil | Haut de page
 
 

  Nouvelles offres d'emploi   sur Emploi Center
Auralog - Tellmemore | Publicis Modem | L'Internaute / Journal du Net / Copainsdavant | Isobar | MEDIASTAY

Voir un exemple

Voir un exemple

Voir un exemple

Voir un exemple

Voir un exemple

Toutes nos newsletters