création de logiciel spécifique et responsabilité

Bonjour,

Cela existe c'est certain.

Je pense qu'il faut tout simplement ajouter une clause à votre contrat stipulant que votre société peut être tenu responsable des bugs, uniquement si il concerne le code source livré par vos soins, et qu'en aucun cas vous ne pouvez être tenu responsable d'un souci provenant d'un développement que vous n'avez pas vous même effectué.

C'est un souci très classique des éditeurs de logiciel.

Bon courage.

Bonjour,

De toutes manières, à mon avis, le risque de mise en cause d’une quelconque responsabilité en cas de modification par le client est très limité. Encore faut-il qu’il en ait le droit donc que ce soit prévu par contrat et dans les formes.

Si la cession des sources n’est pas prévue au contrat on ne voit pas sur quel fondement le client pourrait les exiger. Pour ce qui concerne la modification éventuelle des programmes sources par un tiers ce n’est pas du tout évident s’ils ne sont pas documentés. De plus, cela m’étonnerait que les droits de cession aient été transférés dans les formes nécessaires et rappelées ci-dessous.

Pour céder des droits il y a des mentions obligatoires. Pour information l’article L131-3 du CPI dispose que « La transmission des droits de l'auteur est subordonnée à la condition que chacun des droits cédés fasse l'objet d'une mention distincte dans l'acte de cession et que le domaine d'exploitation des droits cédés soit délimité quant à son étendue et à sa destination, quant au lieu et quant à la durée. ».

Pour une cession des droits il y a donc 4 conditions à mentionner et le contrat doit notamment prévoir la durée de cession ce qui ne semble pas être le cas ici. Elle ne peut pas être indéfinie vu qu’elle est forcément limitée.

Tout ceci est évidemment primordial si l’on développe des logiciels dont on cède ou l’on concède les droits.

Pour des exemples de clauses il serait utile de faire des recherches sur Internet.

Il est également possible de verrouiller contractuellement un certain nombre de dispositions (voir article L 122-6 du CPI) dont notamment « la traduction, l’adaptation, l’arrangement ou toute autre modification d’un logiciel et la reproduction du logiciel en résultant ».

Pour aller plus loin il serait pertinent de consulter le site de l’APP (Agence de Protection des Programmes) sur la page relative à
- « la-vie-du-logiciel » § « Les cessions de droits »,
- et « guide-du-contrat-en-droit-d-auteur ».

Bonjour,

De toutes manières, à mon avis, le risque de mise en cause d’une quelconque responsabilité en cas de modification par le client est très limité. Encore faut-il qu’il en ait le droit donc que ce soit prévu par contrat et dans les formes.

Si la cession des sources n’est pas prévue au contrat on ne voit pas sur quel fondement le client pourrait les exiger. Pour ce qui concerne la modification éventuelle des programmes sources par un tiers ce n’est pas du tout évident s’ils ne sont pas documentés. De plus, cela m’étonnerait que les droits de cession aient été transférés dans les formes nécessaires et rappelées ci-dessous.

Pour céder des droits il y a des mentions obligatoires. Pour information l’article L131-3 du CPI dispose que « La transmission des droits de l'auteur est subordonnée à la condition que chacun des droits cédés fasse l'objet d'une mention distincte dans l'acte de cession et que le domaine d'exploitation des droits cédés soit délimité quant à son étendue et à sa destination, quant au lieu et quant à la durée. ».

Pour une cession des droits il y a donc 4 conditions à mentionner et le contrat doit notamment prévoir la durée de cession ce qui ne semble pas être le cas ici. Elle ne peut pas être indéfinie vu qu’elle est forcément limitée.

Tout ceci est évidemment primordial si l’on développe des logiciels dont on cède ou l’on concède les droits.

Pour des exemples de clauses il serait utile de faire des recherches sur Internet.

Il est également possible de verrouiller contractuellement un certain nombre de dispositions (voir article L 122-6 du CPI) dont notamment « la traduction, l’adaptation, l’arrangement ou toute autre modification d’un logiciel et la reproduction du logiciel en résultant ».

Pour aller plus loin il serait pertinent de consulter le site de l’APP (Agence de Protection des Programmes) sur la page relative à
- « la-vie-du-logiciel » § « Les cessions de droits »,
- et « guide-du-contrat-en-droit-d-auteur ».

Outre ce qui a été dit plus haut, je vois une possibilité de rapporter du CA en +, au cas où les droits sont cédés :

Pourquoi ne pas également proposer une sorte de "support" pour le futur ? Si le client modifie le programme, qu'il plante, vous n'êtes pas responsable, et admettons qu'ils vous rappellent pour réparer, vous pouvez faire ça, non ?

Bonjour

Merci pour toutes ces réponses.

Houla, je pars du principe que je suis freelance de base, c'est a dire que j'ai des contrats avec des clients de base. Un client de base n'a pas vraiment d'argent, pas envie de faire un cahier des charges, il a un projet, ou plutot un objectif, pour le reste, il a deja programmé mais n'a pas envie de developper from scratch.

C'est la que j'interviens, sur une mission ponctuelle, 2 à 5 jours, tarifés entre 400 et 1500 euros. Oui je sais, c'est pas assez, je tourne a 300TTC/jour et mes client estiment que c'est le cout horaire normal d'un salarié ingénieur donc d'un freelance.

Ils partent du principe que c'est une procédure allégée, cela l'est et que donc c'est un prix acceptable.

Moi de mon coté, comme deja dit, c'est un second boulot, je ne choisis que des missions qui me plaisent et je prends le client qui va avec.

Le client moyen... avec l'expérience je commence a m'en méfier, c'est celui qui rajoute au fil de lot des demandes, qui ne fait pas trop gonfler l'enveloppe en fonction, mais je fais avec. Sur ma dizaine d'expériences, j'ai toujours été payé.

Mon problème quand meme, vient sur la responsabilité. Je ne connais pas vraiment le professionnalisme du client de base, mais je fais des factures, et plus ou moins cela me lit contractuellement a leurs problemes a venir.

Le client de base considère que lorsqu'il y a laché plus de 1000e sur un projet, l'assistance et la hotline sont inclus a vie 🙂 C'est assez drole l'applomb qu'ils peuvent avoir quand ils appellent un an apres. "On a un soucis avec ton code". 100% du temps, cela n'avait rien avoir avec le code, où meme le programme. Bon, ca me prend 30 min au tel... je laisse passer.

Ce qui me gene c'est que je fais une facture de logiciel alors qu'au final, je fais un bout de leur programme (la partie qui ne savent pas faire) et ils vont integrer ce morceau dans leur programme a eux.

Ne sachant pas comment l'intégration se passe. Sachant que j'ai fait le programme en fonction d'un scénario d'utilisation et que si cela se trouve le code va etre copiée tel quel dans une autre configuration qui n'a rien a voir et qui met son fonctionnement en danger.

Bref, la facture du logiciel sous entend que l'on donne qqc de "standalone", quand on livre "un bout de code", ce n'est pas pareil... on ne sait pas au final ce que le client va en faire et les risques qu'il prend.

Bref, je me retrouve a écrire un contrat de création de logiciel spécifique avec 40 disclaimers. C'est un peu ridicule.

Si je regarde en arriere, pas mal sont des entreprises sur des chaines de production (création de catalogue professionnel, détection d'un motif sur une image, module 3D dans un site web de vente de produit configuré en ligne)...

J'ai regardé les assurances "informatiques" et généralement la création de logiciel associé a une chaine de production ou a un caractere scientifique est une exclusion...

buzzz a écrit : Le client de base considère que lorsqu'il y a laché plus de 1000e sur un projet, l'assistance et la hotline sont inclus a vie 🙂 C'est assez drole l'applomb qu'ils peuvent avoir quand ils appellent un an apres. "On a un soucis avec ton code". 100% du temps, cela n'avait rien avoir avec le code, où meme le programme. Bon, ca me prend 30 min au tel... je laisse passer.

Sur les projets au "forfait" j'indique systématiquement en option "1 an de support technique". C'est une option, le client est libre de le prendre ou pas, mais si il le prend pas j'ai un argument pour ne pas me prendre la tête en cas de besoin.

Et si il prend l'option, ça permet de relancer les clients une fois par an pour le renouvellement et à l'occasion de voir si ils n'ont pas de nouveaux besoins (et accessoirement, c'est du CA en plus, récurrent si ca se passe bien).

Après évidemment si la réponse prend quelques minutes, il faut aussi savoir être commercial.

Le type de fonctionnement que tu décris, je le connais, mais à la longue, tu vas y laisser ta santé (et ta chemise).
Plus tu en fais, et plus le client en veut, et moins il est prêt à payer (en gros il considère que les nouvelles fonctions sont des corrections de bug sur la version précédentes = gratos. Et le support est gratuit et illimité dans le temps).
Mon conseil (je sais, c'est plus facile à dire qu'à faire) :
- remonter ton taux journalier - ça doit être un combat de tous les instants, pour éviter de travailler gratuitement.
- définir clairement les limites de ton intervention. Ca peut sembler ridicule, mais c'est salvateur.
- définir clairement les conditions d'utilisation de ton logiciel (recette, exploitation, et conditions de support).