Livraison code source avec application ?
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.
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
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.

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
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
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.
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 ?
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.
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
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.