Bonsoir,
Je prépare (encore) un dossier d'achat de logiciel. Le service informatique me pose une colle sur l'évolution du logiciel. Comment intégrer dans le marché les nouvelles versions du logiciel et notamment comment le faire chiffer par le prestataire ? Est-ce que l'on peut l'imposer et dire que ces évolutions doivent être comprises dans le prix initial d'acquisition ou doit-on mettre une ligne dans le BPU : cout des nouvelles versions du logiciel ? Cela me semble étrange vu que l'on se sait pas à l'avance quelles seront les nouvelles versions et à quel prix.
Le service informatique voulait faire un MBC avec mini et maxi et se réserver de commander des nouvelles versions jusqu'au maximum du marché sans prévoir de prix dans le marché : en gros ils font une demande de devis pour le rattacher au marché. Je sais que c'est pas très bon, si quelqu'un a une auter idée, je suis preneuse !!
Merci
Dans le marché initial, sauf "contrat de maintenance" incluant les nouvelles versions, je vois pas.
Peut-être un avenant (licence, installation, formation, à la nouvelle version) à chaque nouvelle version
dans la limite du maximum plafond du marché.
(J'ai plein de soucis aussi avec les logiciels).
Oui c'est super compliqué, c'est le deuxième en trois mois que je lance et à chaque fois je me pose de nouvelles questions et cela me fait douter sur le montage retenu pour le précédent.
Mon marché comporte l'acquisition et la maintenance. C'est un marché à bons de commande qui comprend une part fixe (l'acquisition) et une partie variable (les formations et lmes interventions techniciens à la demande).
Je sais que c'est pas top de mélanger les deux parties mais j'ai trop de mal à trouver un montage cohérent.
Je voudrais trouver une formation "montage des marchés informatiques", je pense que ce ne serait pas du luxe.
En règle générale, l'éditeur fait profiter son client des évolutions logicielles au titre du contrat de maintenance, qui comprend un volet "maintenance évolutive" ou par le biais d'une "assurance" forfaitaire dont le prix est fixé au départ et qui fait bénéficier au client de toute nouvelle version du logiciel qui sortirait dans un délai de X années à l'issue de l'achat de la version initiale de l'applicatif.
Et pourquoi ne pas intégrer dans l'expression du besoin (le cahier des charges) la durée de vie attendue pour cette acquisition? Comme ça, de fait, l'attributaire sera tenu de fournir les évolutions pour cette durée de vie attendue.
Juste une remarque, quand on acquiert un logiciel à un moment M il répond à un certain nombre de spécifications. Dans la plupart des cas les évolutions du-dit logiciel ne concernent en rien les fonctionnalités, ce sont des corrections de bug. En tant qu'informaticien je n'ai jamais admis que l'on fasse payer au consommateur les corrections d'erreurs, et en tant qu'acheteur ça devient carrément rédhibitoire. Donc en incluant dans le cahier des charges cette notion de durée de vie attendue je pense qu'on réduit grandement les prétentions des concepteurs de logiciels tout en s'assurant de ne pas payer pour des corrections d'erreurs (cachées ou non).
Lorsqu'il y a effectivement des modifications de fonctionnalités la question reste ouverte, mais ces évolutions sont-elles vraiment nécessaires, voir simplement utiles? Dans ce cas il y a donc évolution en parallèle de l'expression de besoin, donc changement du cahier des charges.