Vente de mon code souce comment évaluer ça valeur?
robpic
Messages postés7Date d'inscriptionlundi 6 février 2006StatutMembreDernière intervention 1 juillet 2009
-
23 juin 2009 à 17:47
robpic
Messages postés7Date d'inscriptionlundi 6 février 2006StatutMembreDernière intervention 1 juillet 2009
-
1 juil. 2009 à 14:03
J'ai une application pour la gestion de charpente (Toiture, murs, poutrelles)
-Soumission
-Commande
-Cédule de production
-Gestion à l'usine
-Gestion de livraison
-Inventaire
-Etc..
Ma question est pas le prix quel vaux mais comment calculer le prix de mon code source.
J'ai eu comme entente que le code source m'appartenais avec mon client et le prix qu'il a payer jusqu'a aujourd'hui excluais le code source.
Maintenant mon client veux avoir mes sources, donc j'ai aucune idée ce que je doit faire et comment calculer ou évaluer le prix de mes source.
PCPT
Messages postés13272Date d'inscriptionlundi 13 décembre 2004StatutMembreDernière intervention 3 février 201847 23 juin 2009 à 17:58
salut,
c'est une question assez arbitraire...
en général on estime d'un pourcentage de ce que l'appli va apporter sur une période donnée. le problème se pose pour les appli à paiement mensuel à large redistribution
Prenez un instant pour répondre à [sujet-SONDAGE-POP3-POUR-CS_769706.aspx ce sondage] svp
robpic
Messages postés7Date d'inscriptionlundi 6 février 2006StatutMembreDernière intervention 1 juillet 2009 23 juin 2009 à 18:05
Et bien l'application est développer depuis 8 ans et toute l'entreprise fonctionne avec mon système, j'ai pour 40k d'heure de facturer jusqu'a maintenant! Et il vont l'utiliser encore très très longtemps.
xpert12
Messages postés114Date d'inscriptionlundi 5 février 2007StatutMembreDernière intervention10 septembre 2010 24 juin 2009 à 15:48
Salut,
Comme te le dis PCPT c'est dur à te donner des infos avec si peu d'infos. Par contre on peut te donner quelques pistes de réflexion :
Première question : Pourquoi veulent-ils le code source ? (changement de prestataire, ressources informatiques en interne, revente du logiciel...)
Deuxième question : Est ce c'est un achat stratégique pour l'entreprise ?
As-tu une clause d'exclusivité ? existe-t-il des opportunités/menaces sur le marché en question ? pourquoi maintenant et pas avant ?
Troisième question : Ils veulent acheter le CODE SOURCE : Est-ce un investissement productif ? (qui va leur ramener des sous)
- Existe-t-il des progiciels similaires en vente ? A quel prix (installation, license, màj, rythme màj...)
- combien d'utilisateurs ? multiplié par (8 ans + durée vie)
- durée de vie du progiciel en l'état ?
- Estimation d'une réécriture par un tiers (étude, prototype, test, livraison, formation, màj) * coût horaire * delta (% d'embettement pour la société en cas de redémarrage d'un projet)
En fait ce n'est pas tant la valeur du code source qui importe selon moi, c'est bien la valeur ajoutée qu'il crée. En effet, puisque ça fait 8 ans qu'ils payent sans avoir jamais rien vu, c'est bien la preuve que pour eux la valeur était ailleurs !!!! Si maintenant, ils veulent payer pour voir, c'est qu'il y a une autre valeur ajoutée (potentielle ou réelle) qui existe.
Voilà, en espérant que ces quelques pistes puissent t'aider.
xpert12
Messages postés114Date d'inscriptionlundi 5 février 2007StatutMembreDernière intervention10 septembre 2010 29 juin 2009 à 10:06
Il me semblait que le principe de base d'un forum avec une communauté aussi active que celle de vbfrance était de partager expérience, astuces, réflexion...
J'ai du mal comprendre. Dommage de ne pas avoir de nouvelles de ta réflexion qui nous concerne un peu tous.
xpert12
Messages postés114Date d'inscriptionlundi 5 février 2007StatutMembreDernière intervention10 septembre 2010 1 juil. 2009 à 13:36
Salut,
il est possible contractuellement d'indexer des clauses au contrat notamment en cas de disparition de l'auteur du Code Source. Il m'est arrivé de voir des clauses du type :
"un exemplaire du code source sera déposé chez maître X....... . La société Y pourra en prendre complètement connaissance (et/ou en avoir une copie) dans les cas suivants :..... sous telles conditions...."
Si ça peut t'aider.
Ce week-end, je devrai remettre la main sur un de mes nombreux bouquins qui circulent concernant le droit informatique.
Si tu as besoin d'exemples, fais moi signe.
xpert12
Messages postés114Date d'inscriptionlundi 5 février 2007StatutMembreDernière intervention10 septembre 2010 1 juil. 2009 à 13:41
Sinon, tu peux aussi imaginer un mode opératoire pour communiquer avec ton appli "boite noire" et la faire évoluer avec des add-ins. Il te faudra peut-être remanier un peu la structure de ton programme de base. Il te faudra une approche type "brique logicielle".
Avantage :
- tu ouvres ton application sans donner ton code source,
Inconvénient :
- tu laisses la possibilité à des tiers de prendre pied chez ton client.
xpert12
Messages postés114Date d'inscriptionlundi 5 février 2007StatutMembreDernière intervention10 septembre 2010 1 juil. 2009 à 13:57
Tu peux résumer ton application comme un jeu de LEGO. Chaque application fonctionnelle est "condensée" en une brique indépendante qui pourra servir à la construction d'un ensemble cohérent (un logiciel par exemple) et qui pourra communiquer avec d'autres briques.
Chez toi, voici quelques unes des briques :
calculs techniques (poutres...),
impression,
gestion d'une commande : devis, suivi simple, édition facture, envois messages (vers fabrication, compta, force commerciale...)
sauvegarde
gestion des utilisateurs
enfin tu vois et tu connais mieux ton logiciel que nous.
Sinon voici une autre définition :
Une brique logicielle est une partie de logiciel exploitable par
plusieurs applications. C'est notamment le cas des modules de langues
ou de polices de caractère pour les plus simples. On parle aussi de
composants logiciels :
Développé par un éditeur ou accessible
librement, un composant est une brique logicielle réutilisable par
plusieurs applications. Conceptuellement, un composant correspond à
l'expression logicielle des caractéristiques et des comportements d'un
objet, d'un service, d'un aspect ou éventuellement d'une application
informatique complète. Les composants logiciels tendent à devenir des
agents autonomes, capables d'apprendre, de s'organiser, de découvrir
les services offerts par les autres composants.
L'intérêt de
pouvoir se baser sur des briques logicielles existantes pour construire
de nouvelles applications informatiques est évident, mais le problème
de l'intégration n'est pas évident : il faut notamment s'assurer que le
comportement du composant sera conforme à ce que l'application attend.
Pour cela, il est nécessaire de développer des méthodes et des outils
pour assister le développement et l'intégration de composants : capture
des caractéristiques sémantiques, accès à des bases de données de
composants documentés, test de conformité et d'intégrité du composant.