Livraison code source avec application ?

adsads Membre
18:46 modifié dans Vos applications #1
Bonjour,

je vois de plus en plus de gens qui veulent qu'on leur fasse appli, mais dans le cahier des charges il est precisé qu'il faut livrer aussi les sources.  :o
C'est chose courrante ?
Le probleme qui peut se poser c'est que quand tu developpes des framework qui permettent a tes applis d'etre performant (et pourquoi pas en avance par rapports a d'eventuels concurents) , et que tu les utilises dans toutes des applis, c'est assez problematique.Ca peut etre genant de refourger certains savoir-faire. Pour du dev traditionnel pas de soucis.
J'ai un peu l'impression que certains DSI confondent dev d'un site web et dev d'appli iPhone qui est un veritable developpement de logiciel.

Vos remarques seront les bienvenue.

ads

Réponses

  • CéroceCéroce Membre, Modérateur
    18:46 modifié #2
    C'est une sécurité pour le client: ça lui permet surtout de refiler le projet à  un autre prestataire si ton programme ne leur convient pas ou s'ils ont de mauvaises relations avec toi. Sans le code source, un nouveau prestataire doit refaire le boulot. C'est donc un risque.

    Comme tu le dis, c'est également un risque pour le prestataire. Ce risque justifie de facturer plus cher.

    Note bien qu'il y a une différence entre:
    - donner accès au code source: le client peut voir comment il est fichu, par exemple pour en mesurer la qualité
    - le céder: tu n'en es plus propriétaire, le client en fait ce qu'il veut, et tu ne peux plus l'utiliser pour d'autres projets.
    - le licencier: le client peut réutiliser le code source dans les limites contractuelles.
  • jpimbertjpimbert Membre
    18:46 modifié #3
    Penser aussi au dépôt des sources, par exemple auprès de l'APP (app.legalis.net), et en particulier le contrat d'entiercement qui garantit au client qu'il pourra récupérer les sources en cas de défaillance du fournisseur.
  • adsads Membre
    18:46 modifié #4
    ça lui permet surtout de refiler le projet à  un autre prestataire si ton programme ne leur convient pas

    Si tu reponds a un cahier des charges bien precis, en general in y repond.
    Merci pour les differentes precisions.
    Pour le depot des sources on m'en a parlé aussi.

    En general, on vous demande les sources aussi ou c'est assez rare ?
  • AliGatorAliGator Membre, Modérateur
    18:46 modifié #5
    C'est effectivement chose courante, le client souhaitant souvent garder le code source pour pouvoir faire évoluer l'application plus tard si besoin sans pour autant dépendre du prestataire qui l'a créé à  l'origine, pouvant ainsi demander à  un autre prestataire de faire une évolution majeure quelques années plus tard, s'il n'a pas été satisfait de la prestation du premier... ou si ce dernier a déposé le bilan par exemple.

    Ceci dit, c'est un contrat entre le client et le prestataire, le tout est de se mettre d'accord sur les conditions.
    - Il y a en effet par exemple une distinction à  faire entre les 3 possibilités évoquées par Céroce. La plus courante étant de céder le code, cédant ainsi la PI de l'appli également.
    - Il y a également la possibilité pour toi de développer des librairies pour encapsuler ton code réutilisable que tu ne veux pas céder : justement, tu parlais de frameworks que tu pouvais avoir développer en interne et réutiliser pour plusieurs de tes clients. Si tu as bien encapsulé ces fonctionnalités réutilisables dans un framework ou dans une librairie (statique ou dynamique, seules les librairies statiques étant possibles pour iPhone), du coup tu ne livres au client que la lib ("maSuperLib.a") et ses headers ("maSuperLib.h") mais pas le code source ("maSuperLib.m" ou "maSuperLib.c" etc) de cette librairie.


    Tu peux ainsi lui livrer le code source de l'application dans son ensemble, appli qui fait appel à  ta lib pour des trucs spécifiques pour laquelle cette lib est faite et dont vous ne livrez pas le code source, par contre. Le tout étant de se mettre d'accord avec le client, pour lui mentionner exactement quels seront les livrables. Il peut tout à  fait être justifié que certaines fonctionnalités spécifiques " pour lesquelles vous avez déjà  développé des outils en interne " doivent être publiées sous forme de librairies et le code source non cédé.
    Cet avantage d'avoir en interne une lib qui fait déjà  une grosse partie du boulot pour une fonctionnalité donnée de l'appli peut également se monnayer (genre "par rapport à  nos concurrents qui devraient développer un truc ex-nihilo pour vous proposer cette fonctionnalité, nous on a déjà  un module qui fait ça et qui est éprouvé puisqu'on l'a déjà  testé et utilisé pour plusieurs autres applis"), selon l'impact et le poids que cela apporte effectivement à  l'appli.
  • adsads Membre
    18:46 modifié #6
    Merci AliGator pour cette reponse detaillee.
  • jpimbertjpimbert Membre
    18:46 modifié #7
    dans 1281612948:


    On me demande souvent les sources, ... et généralement je ne les donne pas (sauf si le boulot concerne des modifs d'Open Source).
    Sur demande, je propose une option "dépôt des sources en cas de défaillance" pour un petit pourcentage du coût de développement (pour couvrir les 190 € de dépôt, plus une partie des frais d'adhésion à  l'APP), et une option fourniture des sources pour un montant largement supérieur. D'autre part, je préviens que la fourniture des sources ne vaut pas transfert de propriété et que je les dépose de toutes façons pour lutter contre la contrefaçon.

    Personnellement, je ne pratique habituellement pas le transfert de propriété, sauf dans des cas très particuliers. Par exemple : le client insiste pour que je travaille, mais sur un domaine que je ne connais pas et pour lequel je ne peux pas utiliser mes bibliothèques ou mon savoir-faire habituel.

    Dans tous les cas, la fourniture est garantie (3 à  6 mois suivant les cas) et j'explique à  mon client qu'il peut récupérer les sources auprès de l'APP si je suis défaillant pendant la période de garantie (le contrat d'entiercement prévoit une correction dans les 8 jours d'un bug bloquant).

    Avec tout ça, le client préfère généralement l'option "dépôt des sources"

    Pour finir, je n'accepte pas de travailler sur des sources que m'apporte le client s'il ne m'apporte pas la preuve qu'il en est le propriétaire ou qu'il peut les modifier (Open Source).
  • adsads Membre
    18:46 modifié #8
    c'est clair que le transfert de propriete est delicat cart si le client veut etre penible il peut t'attaquer sur les prochains dev meme si ca ne lui concurence pas...
  • adsads Membre
    18:46 modifié #9
    jpimbert,
    pourquoi l'APP plutot que cleo-sgdl ou Scam Velasquez
    http://www.cleo-sgdl.org/ins-cond.asp
    http://www.scam.fr/fr/Accueil/AssociationScamVélasquez/tabid/363384/Default.aspx#depot

    qui sont bien moins cher ?

    une raison juridique ?

    Merci
  • jpimbertjpimbert Membre
    18:46 modifié #10
    C'est à  peu près le même prix que l'APP si on reste dans du dépôt simple, en vue de protéger l'oeuvre de la contrefaçon, ou au moins pour prouver l'antériorité, et donc protéger l'auteur.
    Ces organismes ne proposent pas de contrat d'entiercement destiné à  protéger également le client d'une défaillance du fournisseur.
    C'est pourquoi je préfère l'APP ; un seul interlocuteur pour tous mes besoins en la matière.
Connectez-vous ou Inscrivez-vous pour répondre.