HARVIE

Hello, We would like to developp a module able to duplicate the whole order process of Prestashop (1.6 version). In Front, we need a second cart with a second order process. In Admin, we need a second orders pages. Thanks, Regards

Légalement, le développeur ne peut rien faire avec. Cette clause de propriété sert donc essentiellement à valoriser l'actif mais aussi à se protéger en cas de problème. Ensuite, bien sûr, cette clause n'empêche absolument pas le délit de se faire. Le dévellopeur peut très bien deguiser le module en le transformant assez, pour ensuite le revendre. Comme voler un objet et le repeindre avant de le re-vendre. Mais, dans les 2 cas, ça reste un délit, puni par la loi. Après si le dévellopeur modifie en profondeur la demande initiale, je ne vois pas bien l'intérêt de prendre le risque de partir sur une base dont il n'est pas propriétaire.

Entre ma première question, et cette dernière intervention, j'ai eu le temps de me renseigner. Certaines choses annoncés plus haut sont vraies, et d'autres fausses. Donc je résume pour ceux qui sont intéressés par cette question, qui reste importante pour les développeurs, et pour les clients : Il existe 2 types de dévellopement : 1. Un dévellopement industriel. Un module (ou un logiciel) est créé par un dévellopeur dans le but de le revendre en masse, en essayant de répondre à une demande générale. Le prix du module est donc généralement bas, et c'est par le volume de vente que le dévellopeur va espérer générer un profit. La règle est toujours la même, à savoir que si rien n'est spécifié au départ (dans un contrat, CGV, CGU etc...) c'est bien le créateur et donc le développeur qui a la propriété du module. Je ne vois de toute façon absolument pas l'intérêt qu'aurait un développeur dans ce cas à vouloir céder la propriété à un tiers (mais il pourrait le faire). Les modules vendus de cette façon sont un actif très important pour le dévellopeur, et il a donc tout intérêt à les sécuriser, par des clauses de réserve de propriété par exemple. Mais encore une fois, même si rien n'est spécifié, il reste quand même le propriétaire. Aucun litige ne pourrait de toute façon donner raison au client dans ce cas de figure. Il n'y a donc aucune polémique possible à mes yeux dans ce cas. Passons au 2ème cas de figure. 2. Un développement artisanal. Un module (ou autre) est créé sur-mesure par un développeur pour un client unique, suivant la demande et le cahier des charges du client. La règle est toujours la même, à savoir que si rien n'est spécifié au départ (dans un contrat, CGV, CGU etc...) c'est bien le créateur et donc le développeur qui a la propriété du module. Le dévellopeur peut donc ensuite décider de revendre ce module en masse, au prix qu'il le souhaite. Le client, lui, ne pourra même pas le revendre à une seule personne, car il n'est pas le propriétaire. Contrairement au premier cas de figure, ce type de dévellopement est beaucoup plus litigieux. Le client peut en effet vite se sentir léser. Il a étudié un projet, créé un cahier des charges, payé en général assez cher un dévellopement spécifique, et il n'est même pas propriétaire. Pire, il retrouve son projet sur une plate-forme pour une poignée d'euros. S'il venait à demander réparation, l'issue serait en fait très aléatoire. D'abord, est-ce que le dévellopeur l'a bien avertit (par contrat, CGV, CGU, ou simplement par écrit ou par oral) de cet aspect de propriété? En effet, soyons claire, dans ce cas de figure, le dévellopeur ne peut pas se permettre "d'oublier" cet aspect, car il est fondamentale. Car un prestataire de services est toujours dans l'obligation d'informer le client des aspects essentiels d'une prestation. Cette règle est très importante. Nul doute que dans le cas d'une demande spécifique et sur-mesure, la propriété sera jugée comme un aspect essentielle. Et puis, si le prix payé par le client (qui sera généralement assez élevé) n'est pas en adéquation avec le prix qu'il aurait payé pour un module dont il ne serait pas propriétaire (comme un module présent sur l'addons prestashop), cela pourrait aussi aider à justifier le bien fondée de donner la propriété au client. Si, sans justificatif dans les mains, un client demande réparation pour devenir propriétaire d'un dévellopement spécifique, l'issue sera donc incertaine pour les 2 parties. Pour le dévellopeur et le client, il n'y a donc qu'une seule chose à faire : préciser cet aspect de propriété dès le départ. Si le client considère que ce dévellopement doit rentrer comme un actif important de sa plate-forme pour la valoriser, il doit demander la cession complète de la propriété, et ceci devra être spécifié par écrit et signé par les 2 parties (des contrats tout fait existe partout sur le net). De cette façon, le dévellopeur ne pourra jamais utiliser le dévellopement ailleurs, et le client pourra utiliser ou revendre ce dévellopement comme il l'entend. Le dévellopeur peut refuser la cession, aussi il est indispensable de parler et de régler cet aspect dès le départ. Si le dévellopeur considère que ce dévellopement doit rester sa propriété, il doit, au moins d'un point de vue morale et éthique, en informer le client au départ. Si le client n'y voit pas d'objection et que ceci est acté, le dévellopeur pourra ainsi faire ce qu'il souhaite de son dévellopement. Et sera sûr que le client ne pourra rien en faire de son côté. Il existe enfin des solutions intermédiaires qui rentreront alors dans le cas de négociations : 2 prix différents (en cession de propriété ou pas), un partage de propriété suivant des règles spécifiques...etc La finalité de tout ça, comme pour beaucoup de chose dans le commerce, reste, pour les 2 parties, de penser à bien se protéger dès le départ d'une prestation. Donc clients et dévellopeurs, amusez-vous mais sortez couverts...

Pour répondre à coeos.pro, je crois que tu n'a pas saisis mon intervention. Il s'agit d'une simple curiosité "juridique" (comme expliqué dans ma toute première phrase), et j'ai donné mon avis sur la question. Mon avis sur ce qui se passerait si un client porte plainte, va devant un tribunal, qu'aucune loi n'existe, et qu'un juge doit trancher en faveur de l'un ou de l'autre. Moi, je pense que c'est la logique commerciale qui l'emporterait, et donc que le développeur devrait proposer l'article similaire, au prix du marché. Car la différence de prix pour un même produit est trop importante, et surtout que le client est avant tout le fondateur de l'idée. Il se pourrait même qu'il soit tout simplement le propriétaire. Je n'attaque personne. Et je n'ai aucun contentieux avec des développeurs. A qui je souhaite de gagner l'argent qu'il mérite. Pour la petite histoire, nous demandons en ce moment des dévellopements spécifiques pour une nouvelle plate-forme. Et jamais 2 sans 3, le sujet est revenu 3 fois de suite, avec 3 dévellopeurs, sous diverses formes, à propos de cette histoire de "propriété" justement. Dernier en date, Ether Création, qui vient de répondre à ce topic, et avec qui j'étais justement au téléphone ce matin. Qui m'indiquait que de multiple possibilité de rémunération existait sur l'utilisation d'un module spécifique, à travers le dévellopeur, l'acheteur, et le client final. Cela implique des transferts de propriété, qui je trouve, sont compliqués à cerner dans un monde "virtuel". Je suis donc simplement curieux de la législation dans ce domaine car nous allons ouvrir notre site à des partenaires extérieurs et il important de savoir ce que l'on a le droit de faire, ou pas. Donc coeos.pro, si mon hypothèse te choque, j'espère en tout cas pour toi et pour tous les développeurs qu'elle est fausse. Et pour répondre à Ether Création, un module à 30 € est un "risque", en tout cas un pari sur un volume minimum à écouler qu'a pris le dévellopeur. D'où l'aspect industriel. Mais c'est son choix. C'est une stratégie commerciale qui fonctionne, même à 30 € le module, pour peu que l'offre soit cohérente et la demande suffisante en volume. Le client lambda sur addons comprend pourquoi il paye 30 € un module, mais 1200 € s'il avait dû le faire dévelloper pour lui seulement. Dans ce sens, il n'y a aucun litige possible. Mais ce qu'un client peut ne pas ne comprendre et ne pas accepter, c'est le cas inverse. Car on part de "sa" création pour diffuser en masse un produit, 40 fois moins chers.

Bonjour, Nous souhaitons faire dévelloper un module spécifique de commande fournisseur : - possibilité depuis le détail d'une commande client dans le BO, de générer une commande par fournisseur reprenant les différents aspects (livraison, ref.fournisseur, prix d'achat...). Possibilité d'envoi des commandes par e-mail, génération de pdf (bon de commande, bl...) - intégration d'un listing complet des commandes fournisseur et semblable au listing commande client (statuts, boîte de message...) Réponse et détail par MP SVP. Cordialement,

Bonjour, Nous souhaitons faire dévelloper un module spécifique de transporteur avec ces 2 spécifités : - un transporteur sera rattaché à un fournisseur (et donc à tous ces produits). Cela impliquera que 2 produits de 2 fournisseurs différents dans un panier feront se cumuler le montant total des frais de port. Le transporteur du fournisseur 1 + le transporteur du fournisseur 2. - des règles de calcul des frais de port plus complexes seront à dévelloper (prise en compte du prix de vente, prix d'achat, poids, quantité etc...). Nous avons ces règles déjà définis, mais il faut les coder. Réponse et détail par MP SVP. Cordialement,

Merci pour vos retours. Pour ma part, je pense que si un développement spécifique est demandé par un client, et si rien n'est spécifié ou négocié au départ, ce dévellopement doit se retrouver sur le site du client. Point final. Car nous sommes d'accord que ce dévellopement est, par principe, unique et dédié. La demande du client va bien dans ce sens. Le floue arrive quand le dévellopeur utilise ce dévellopement pour créer un produit qu'il va ensuite revendre à grande échelle. Car, on passe en fait d'un stade artisanal à un stade industriel, et le client de départ est forcément lésé, là où le développeur ne court strictement aucun risque. En stade artisanal, lors du dévellopement spécifique, les 2 parties sont gagnantes. Le client paie un prix fixé au départ, pour un dévellopement qui va être fait sur-mesure. Et puis le développeur décide de passer en mode industriel. Normalement, cela implique des frais fixes depensés au départ important (en temps de dévellopement) qui devront ensuite être comblé par des ventes répétées. Comme pour la mise sur le marché d'un module classique. Sauf que là, il n'y a aucun frais de départ. Tout a été payé par un tiers. Sans règle spécifique, je pense que la logique commerciale voudrait que le développeur soit dans l'obligation de proposer le module au client initial au nouveau tarif. Cela re-équilibrerait le risque au niveau de "l'industriel". Qui doit maintenant compenser ses frais par des volumes de vente suffisants. Sans vouloir m'avancer, je pense qu'il y a un vide à ce niveau...

Bonjour, Question assez juridique : Si nous faisons dévelloper sur-mesure un module pour notre boutique par une agence ou par un devellopeur free-lance, qui, in-fine, sera le propriétaire de ce module? En gros, un développeur peut-il facturer à prix d'or un dévellopement, pour ensuite le revendre sur la plate-forme prestashop? Ou doit-il demander l'autorisation du client qui a fait développé le module? Merci d'avance, Cordialement, Hervé Kieffer

Bonjour, Nous recherchons un prestataire pour modifier à plusieurs endroits le theme de base de Prestashop 1.6. Le theme doit rester parfaitement valide et responsive. Merci, Cordialement

Les nouveaux produits, créés depuis le site en 1.6 sont bien présents et les images aussi. Ici, pas de problème. Les anciens produits, créés depuis le site en 1.4 sont bien présents, mais nous n'arrivons pas à intégrer les images. Les produits sont pour le moment en BDD en version "light" (id produit, nom, réf). Si quelqu'un veut nous débuguer ceci, vous pouvez nous faire une proposition par MP. Merci.

Bonjour, Nous avons un site 1.4 en production et un site 1.6 en dévellopement. Il nous reste à transférer les images des produits d'un site à l'autre...Dans le site 1.6, il y a déjà des nouveaux produits qui n'existaient pas dans le 1.4. Les images de ces nouveaux produits sont déjà stockées dans img/p et dans les différents sous-dossiers (des sous-dossiers qui n'existaient pas dans la version 1.4). Pour les anciens produits, nous avons transféré l'ensemble des images dans img/p/, puis, depuis le BO, nous avons demandé le déplacement des images. Et elles ont disparu...on a re-essayé et plus rien ne se passe... Donc nous recherchons quelqu'un capable de nous faire cette manipulation... Merci, Cordialement,

Bonjour, Je suis en train de basculer d'un site 1.4 en 1.6. J'ai un module qui permet de générer des fichiers CSV pour faire l'export/l'import des données (catégories, fabricants, fournisseurs, produits...). J'ai commencé par les catégories et j'ai bien tout récupéré, en maintenant les mêmes ID, et il me reste à récupérer les photos. J'ai copié les images du dossier img/c/ de la version 1.4 et je les ai mis dans le dossier du site 1.6. Ca fonctionne sauf que les types d'images dans les 2 cas ne sont pas du tout les mêmes, car les 2 thèmes sont très différents. Je précise que ce sont les formats et les noms des types qui sont différents (grosses modifs sur le site 1.4 à l'époque). J'ai donc, pour la version 1.6, re-généré les minitaures et demandé la suppression des aniciennes. Mais le problème, c'est que les anciens types d'images de la version 1.4 sont toujours dans le dossier. Il y a donc une quantité importante d'images en FTP qui ne sert à rien... Je voulais donc connaître la manip pour les supprimer et avoir quelque chose de clean... Merci d'avance pour votre aide, Cordialement,

Bonjour, Suite à la migration de notre site Prestashop sur la dernière version 1.5.6, nous recherchons un dévellopeur pour une série de modifications à effectuer en FO, en BO, et sur certains modules. Notre demande est urgente, et nous cherchons donc quelqu'un disponible de suite. L'idéal serait ensuite d'avoir un partenariat, sous forme de ticket ou forfait par exemple, pour les modifications futurs. Merci de nous répondre par MP pour plus de détails. Cordialement,

Bonjour, Je n'ai vu les produits cités nul part sur la page en question. J'ai vu un terme «Snap On Cover» dans la description de la catégorie. Si c'est dans cette description que tu veux mettre des balises de type html (par exemple <h2>), il va falloir installer une librairie style Tiny MCE pour les descriptifs catégories, ce qui n'est pas natif sous Prestashop. Mais tu trouveras la manip facilement sur le forum...Pour infos, si tu veux mettre des <h2> dans le descriptif de tes catégories dans un optique de référencement, c'est à éviter. Privilégie des balises comme <strong>. Si le <h2> est à mettre sur le titre des produits présents sur des pages catégories, il va falloir modifier cela dans product-list.tpl.

Bonjour, Merci pour votre réponse. Je suis allé sur le blog en question mais je n'ai pas trouvé d'articles parlant des tags...mais en tout cas, j'ai ma réponse. Donc pour résumé, Prestashop avait 2 choix : 1. Bloquer les tags en indexation et donc ne pas faire le travail d'optimisation puisque, dans ce cas, aucun intérêt...le défaut de cette solution étant, et bien, que dans l'état, les tags ne peuvent pas être utilisés en vue d'optimiser une boutique d'un point de vue SEO. OU 2. Autoriser les tags en indexation, et dans une optique SEO, permettre une optimisation...mais sachant que si les tags sont mal utilisés, trop identiques aux catégories et aux produits, cela n'apporte aucun intérêt en SEO, et même pire, peut desservir la boutique. Ils ont donc opté pour la première solution. Quant à moi, je vais explorer la deuxième, sur une boutique de test et voir ce que cela apporte...