vincedo

Salut alrobine, merci pour l'info, je savais pas que allopass acceptait les paiements CB. Malheureusement, mes réserves sont plus ou moins les mêmes qu'avec Paypal : Allopass introduit une étape supplémentaire D'après le site allopass, "Une fois son achat effectué, votre client obtient à l'écran son Ticket d'accès et reçoit par email sa confirmation de paiement. Il pourra alors l'insérer sur votre site et accéder à votre contenu payant." Aspect moins professionnel Par rapport à un paiement bancaire intégré En tt cas merci, et désolé si je parais négatif, j'ai des contraintes à respecter

Hello Théo, J'imagine que tu fais référence aux tâches proposées par Amazon Turk. C'est vrai qu'on se demande s'ils trouvent des gens pour les réaliser avec un "salaire" pareil.

Après plusieurs coups de fil, il ressort que : les 2 seuls moyens d'embaucher qqn en France sont en tant qu'indépendant ou que salarié. si salarié, le contrat doit préciser le nombre d'heures ou de jours (on est donc dans une rémunération à l'horaire et non à la tâche) et respecter le salaire minimum légal (SMIC horaire : 8,03 EUR / heure) le TEE ou CETPE évoqués par Boussole sont uniquement des modes de paiement du salaire et sont destinés à simplifier les formalités administratives ; ils ne dispensent en rien de la réalisation d'un contrat de travail (cdd, cdi...) Bref, tout ça est plus compliqué que ce que je pensais. D'après l'inspection du travail, ma demande "s'inscrit dans une logique anglo-saxonne, pas française". Ils ont également souligné qu'à l'heure du débat sur le Contrat Première Embauche et la précarité qu'il instaure, je m'inscris dans une logique d' "hyper-précarité" (ce qu'ils ne voient pas d'un très bon oeil). Pour ceux qui veulent plus d'infos : Titre Emploi Entreprise (TEE) Centre national TEE de PARIS (gère les professions informatiques) Tel : 0810.15.75.75 http://www.letee.fr/ Chèque emploi Très Petite Entreprise (CETPE) Centre de Paris (gère les professions informatiques) Tél. : 0810 123 873 http://www.emploitpe.fr/ Moi, je m'en vais monter une boîte en Angleterre.

Tout à fait d'accord avec la distinction de Marie entre télétravail pour une société et travailleur indépendant à distance (j'avais mal compris, je croyais que tu étais ds le 2e cas). C'est effectivement pas évident de demander à un employeur qui pensait t'avoir ds l'entreprise si tu px travailler depuis ton domicile (je comprends mieux maintenant ce que tu disais sur être soupçonné de fainéantise, etc.). Comme en plus, c'est un entretien d'embauche, la question est un peu délicate. Faut peut-être attendre de voir si l'entretien se passe bien pour évoquer la possibilité du télétravail. Tu pourrais aussi commencer full-time en entreprise histoire de démontrer ton sérieux, puis passer en télétravail... En Belgique (j'ai vécu qq années là-bas), ce mode de travail semble bcp plus répandu qu'en France, alors tt devrait bien se passer. Bon courage pour cet apm !!

Quelques précisions : On parle bien d'une société qui existe et qui veut rémunérer des gens ; cette société est de bonne volonté et prête à déclarer tout ce qui devra l'être . Cela dit, cette société ne veut pas être liée par un contrat de travail à ses employés : elle veut pouvoir utiliser les services de quelqu'un pour une série de tâches, le payer disons 50 EUR et ne plus en entendre parler (c'est une façon de parler ; je vx juste souligner qu'il n'y a pas de notion de durée ou d'engagement, mais uniquement de tâche/mission à effectuer). Cette société veut pouvoir payer n' "importe qui", pas uniquement des indépendants. Exemple (totalement fictif) : elle passe une annonce ds les forums "cherche modérateur payé 2 cents par post modéré", les candidats répondent, elle en sélectionne un qui modère 1000 posts, et hop, elle le paie 20 EUR. Tout ça doit rester le plus informel possible. On parle donc bien de rémunérer des micro-tâches et donc pas d'un emploi. Ds cette perspective, les pistes évoquées par Boussole semblent très intéressantes (car très peu de formalités). Cela dit, pouvez-vous m'éclairer sur un point : qq soit la solution retenue, la société doit toujours payer des charges sociales. Est-ce que ça veut dire que ça lui coûte 100 EUR pour qu'un employé ait finalement 50 EUR en poche (en supposant que charges sociales = la moitié du salaire) ? Si oui, la rentabilité d'un tel mode de rémunération est sérieusement entamée... (mais bon, appelez-moi naïf, jvois pas comment payer un salaire légalement sans charges sociales).

Bonjour, Vous est-il jamais arrivé de vouloir embaucher quelqu'un pour effectuer un petit travail sur votre site ? Retouches graphiques, écriture d'articles, soumission de posts dans vos forums, validation de contenu... Il y a de nombreuses tâches qu'un webmaster pourrait vouloir déléguer contre rémunération. Un bon exemple est le site d'Amazon Turk (anglais) : le site rémunère ses "employés" entre 1 cent et 3 dollars par tâche effectuée (voir la liste des tâches). Au final, on arrive à des "salaires" de quelques dizaines d'euros, mais comment faire pour les payer - légalement - aux personnes qui ont effectué les tâches ? Ma question suppose que je ("je" générique) suis une société. Je peux donc payer des factures et embaucher des gens. Mais vu les sommes en jeu, je ne souhaite pas formaliser un contrat de travail avec chaque employé. Idéalement, ces employés devraient pouvoir être n'importe qui (c. à d. pas obligatoirement des indépendants ou d'autres sociétés - car il me serait alors facile de les facturer). Vincent PS. Cette discussion fait suite à celle sur le business model des sites d'annuaire, dans laquelle Cendrillon évoquait le recours à une une "équipe éditoriale" (éventuellement rémunérée) pour garantir la qualité d'un annuaire.

Dan et Monique, merci de vos conseils. J'avais effectivement envisagé Paypal, mais il me pose un gros problème : l'acheteur doit être inscrit sur Paypal ; et même si cette inscription est extrêmement simple (quelques champs à remplir), je suis certain que ça en dissuaderait plus d'un (certains hésitent encore à utiliser leur numéro de carte bancaire, alors s'ils doivent en plus donner leur nom, leur email, cliquer le lien de vérification Paypal...). En plus (et c'est peut-être juste ma perception), je trouve qu'un site qui utilise Paypal pour facturer ses clients projette une image moins professionnelle, ça fait "petit" site (or on parle effectivement d'un petit site, mais qui ne veut pas en avoir l'air ). C'est un peu comme d'utiliser le nom de domaine bob.dupilou.free.fr à la place de dupilou.com. Enfin, je ne pense pas que le recours à une banque soit fondamentalement une mauvaise idée (au contraire). C'est plus la question des tarifs qui me gêne (ils me paraissent élevés, mais je n'y connais rien) ; le but du post est aussi de savoir s'il existe des solutions similaires (via une banque) et moins chères.

Bonjour, Je me suis récemment renseigné sur les solutions de paiement électronique pour un des sites sur lesquels je travaille. Pour avoir une interface de paiement par carte bancaire sur ce site, une banque me propose : frais d'installation : 176 EUR abonnement : 30 EUR / mois plus env. 2% du montant de chaque transaction Comme le panier moyen est d'environ 20 EUR par commande, tout ça me paraît un peu cher. Que pensez-vous de ces tarifs ? Faut-il les négocier ? Connaissez-vous des tarifs / solutions plus intéressantes ? Vincent PS. Le paiement doit se faire par carte bancaire style carte bleue ou visa, pas d'audiotel ou de SMS.

Hello antf, Bienvenue sur le hub, et aussi : félicitations pour ton excellent français, c'est impressionnant ! Vincent

Bien sûr que c'est possible. Encore plus dans cette profession qu'une autre, puisque l'essentiel de ton travail va "transiter" par un ordinateur et une connexion Internet. En plus, tu es chanceux, car le graphisme/webdesign est un domaine qui se prête tout particulièrement au télétravail : Il est assez fréquent d'employer des indépendants pour faire le graphisme. J'ai bossé dans une petite agence web, et tous nos designs étaient réalisés par des indépendants en télétravail ; ça coûtait moins cher à l'agence qui n'avait pas besoin d'eux à temps plein, et ça permettait surtout d'avoir des "styles graphiques" variés en changeant régulièrement d'indépendants. Bien sûr, les plus grosses boîtes préféreront avoir des graphistes en interne. Ces indépendants n'avaient pas besoin d'être sur place, au contraire. En effet, petite boîte = pas bcp de place, donc c'était mieux qu'ils soient en télétravail. Et comme le travail qu'ils produisent est "numérique", tout transite par e-mail. Voici qq pistes pour démarrer : créer son site avec des exemples de réalisations (n'oublie pas, ton site = ta carte de visite, il doit être nickel, surtout si tu bosses en télétravail, car c'est par ton site que les gens feront ta connaissance et détermineront s'ils veulent bosser avec toi). s'inscrire dans les annuaires spécialisés (comme http://www.praktica.net/). se faire créditer sur les sites qu'on a réalisés (sous forme d'un lien pointant vers ton site) vendre ses designs via une bibliothèque de designs comme http://www.kitgrafik.com/ se spécialiser dans le design de "themes" ou "skins" pour logiciels open-source (WordPress, PHPnuke, Drupal...) ; il me semble que ces logiciels sont pas mal utilisés et qu'il y a une demande pour ça. Ca doit être pas être facile au début, mais si ton style plaît, tu remarqueras que ça peut aller très vite : les graphistes que je connais et qui ont un vrai style ont plutôt trop de boulot que pas assez. Enfin, comme l'ont souligné d'autres personnes, le télétravail n'est pas tjours facile, et notamment il s'opére vite un "brouillage" entre temps de travail et temps de loisirs, qui peut déboucher - selon ton caractère - sur trop bosser ou pas assez bosser. Bon courage, Vincent

Salut, Ton message est formulé un peu bizarrement : travailler à domicile n'est pas un "système" ou une méthode. Tu dois d'abord considérer le style de travail que tu fais ou que tu veux faire, puis te demander si tu peux l'exercer à domicile ou pas. Maintenant, peut-être que je t'ai mal compris, et que tu t'interroges sur les pour et les contre du travail à domicile pour un style de boulot donné. Vincent

Benoît : merci pour ta réaction, c'est très instructif. On va dire que c'est l'enthousiasme du débutant (enfin, débutant sur ce forum, pas dans la conception web hein ). Tu pourrais nous en dire plus dièse ? Sans vouloir entrer (trop) dans les détails de ta situation, es-tu dans une boîte qui t'impose la programmation en binôme, ou est-ce ton choix perso ? Comment ça se passe concrétement : vous êtes 100% du temps à 2 ? est-ce qu'il y en a un au clavier et un autre qui regarde ?... Oui, ça fait d'ailleurs partie des pratiques définies par l'XP, par exemple, "Convention de nommage : dans l'optique d'appropriation collective du code et de facilitation de la communication, il est indispensable d'établir et de respecter des normes de nommage pour les variables, méthodes, objets, classes, fichiers, etc. ;". Sinon, tt à fait d'accord avec ta remarque sur l'adaptation de la méthode à la taille du projet.

Juste. Mais les 4 lettres sont bcp moins puissantes qu'une classe comme PHPMailer. Suffit de jeter un oeil à ça puis ça. Mais comme tu le soulignes, ne débattons pas de l'utilité d'un framework (je pense que tout le monde en est convaincu). La vraie question, c'est : utiliser un framework existant ou développer le sien ? Et nous vlà reparti pour un tour ! LE MOT DE LA FIN* Pour éviter de tourner en rond, je vais poster mes conclusions perso. Non qu'elles aient valeur universelle (pas du tout, on n'a cessé de souligner la spécificité des besoins de chaque développeur, et des fonctionnalités de chaque framework). Simplement, vos messages m'ont permis d'y voir plus clair, et je voulais vous en faire part : D'abord, merci à tous. Je suis nouveau sur le hub et je trouve ça bien agréable de pouvoir échanger avec des "travailleurs du web" expérimentés, en français en plus (je traînais bcp sur les forums anglophones jusqu'à maintenant). Faire un framework de + en projet collaboratif open-source n'est pas une bonne idée. Car le noyau de fonctionnalités communes sur lequel ses développeurs s'entendraient n'apporterait rien par rapport aux frameworks existants ; ça serait réinventer la roue. De plus, la gestion d'un tel projet est une activité à temps plein. Or, mon but, c'est de faire des sites Web, pas de passer à mon temps à fabriquer une solution pour les faire. Dans mon cas, il serait plus intéressant d'avoir mon framework spécialisé. D'après vos messages, il semble que je ne sois pas le seul. Le style de sites que je veux construire repose sur un modèle assez précis. Mieux vaut utiliser un framework implémentant exactement ce modèle plutôt qu'un framework généraliste qui alourdirait l'ensemble et que je devrais "tordre" pour qu'il fasse ce que je veux. Je vais donc fabriquer mon propre framework, mais pas en partant de 0. Je suis assez partisan d'écrire son propre code, ne serait-ce que parce que c'est très formateur. Cela dit, il existe déjà de très bons frameworks/classes et ça serait dommage de s'en priver complétement. Sans forcément les ré-utiliser tels quels, on peut s'inspirer de leur logique, structure et bonnes pratiques pour gagner du temps et de la qualité. Vouloir construire un framework était peut-être un peu naïf. Mon idée était sûrement motivée aussi par le fait de vouloir passer moins de temps sur le dévt. Ceux d'entre vous qui gèrent des sites le savent, le dévt n'est qu'une partie du boulot (y a aussi le contenu, le marketing, le SEO...). J'adore coder mais je pense honnêtement que si j'avais eu les moyens, j'aurais embauché un développeur PHP calé avec qui j'aurais développé en binôme (histoire de garder les mains ds le code mais d'avoir plus de temps, et puis de partager l'expérience à la manière de l'Extreme Programming). Faut que j'vous laisse, jvais appeler mon comptable. (*) Quand je dis mot de la fin, mon intention n'est ni de mettre un terme à cette discussion ni de prétendre détenir la vérité, c'est juste une conclusion à ce stade de la conversation.

D'après Wikipedia, "l'Extreme Programming (XP) est une méthode agile de gestion de projet informatique, dont l'objectif est de permettre de gérer des projets de manière simple et efficace." (voir le très clair article de Wikipedia pour une définition plus précise). J'aimerais connaître votre avis sur l'XP et notamment sur : la programmation en binôme ; peu de specs initiales mais des itérations et des releases fréquentes. Avez-vous déjà essayé ? Convaincus ? Echaudés ? Juste tentés ? Vincent

Je suis épaté de voir que même après avoir passé un peu de temps à étudier la question, je continue à découvrir régulièrement de nouveaux frameworks que je ne connais pas. Ca aide pas franchement à se décider tout ça. Pour info, une liste de frameworks PHP est disponible ici: http://dmoz.org/Computers/Programming/Lang...pts/Frameworks/

J'ai échangé plusieurs e-mails avec eux, et ils m'ont fait une très bonne impression. J'ai également consulté Lafraise.com et netvibes.com qui ne m'en ont dit que du bien.

Hello, je suis à la recherche d'un hébergeur PHP/MySQL et je suis tombé sur typhon.net qui me paraît pas mal du tout. Les prix ne sont pas les moins élevés mais ma priorité est la qualité du service. Ils hébergent notamment lafraise.com et netvibes.com, qui sont quand même 2 grosses pointures dans leurs catégories. Certains d'entre vous ont-ils déjà essayé ?

Tout à fait d'accord avec toi ! J'ai posé la question pour lancer la discussion mais je pense en effet que c'est en vendant des services autour du code qu'on peut gagner sa vie. Le modèle semble bien fonctionner dans l'open-source : PHP, MySQL, Linux, de nombreux CMS... tous sont gratuits, mais de nombreuses sociétés se sont développées en vendant du conseil, de la formation, du paramétrage, de la customisation... Pour prendre un exemple concret : Drupal est un CMS open-source que certains d'entre vous ont peut-être déjà utilisé. A ce titre, il est entièrement gratuit. Pourtant une boîte comme Bryght (pas de pub, juste un exemple - ils sont au Canada et tout en anglais) a bâti son commerce sur la vente de services autour de Drupal (installation, hébergement, paramétrage...). Petite précision : je parle beaucoup de Drupal ; je n'ai à ce jour aucun intérêt particulier dans ce CMS, si ce n'est qu'après des recherches un peu approfondies en quête du "CMS idéal", c'est celui qui m'est apparu comme le meilleur candidat. Que tu es chanceux ! Merci Microsoft. La communauté PHP n'a pas la chance d'avoir un framework "officiel", même si c'est en projet.

Hello Robinson. Précisément ! Mais t'es-tu jamais demandé pourquoi tous ces projets avaient si peu de succès ? D'après moi, voici qq raisons : Bon nombre d'entre eux sont tout simplement de mauvaise qualité Bugs, fonctionnalités inutiles ou mal implémentées, code de piètre qualité, HTML produit ultra pollué... Il y en a trop Eclatement de la communauté des développeurs en différentes "paroisses" concurrentes au lieu d'unir leurs efforts. Pas assez "user-friendly" De nombreuses personnes veulent du Joomla, du prêt-à-utiliser. Or les projets open-source nécessitent souvent des installations et des configurations manuelles un peu ardues. Les interfaces ne sont pas toujours très belles et explicites. Pas de support Bien sûr, il y a la "communauté open-source". Mais ça, c'est quand le projet est une "star" comme tu dis. Dans les autres cas... MAIS SURTOUT, absence de leaders, c. à d. de personne(s) avec une vision claire qui donne une couleur unique, une direction et un dynamisme au projet, quelqu'un qui soit capable de fédérer une communauté autour d'une vision. La plupart de ces projets ne sont le fait que de quelques passionnés (ou égarés ? ) et sont, par nature, "amateurs". C'est tout ça que je me propose d'éviter quand je m'interroge sur l'utilité de construire un framework PHP. Pas uniquement. Du "code" (terme volontairement assez large) peut désigner un CMS, un framework, des APIs (ie. des fonctions, des classes)... Les cibles et des utilisations du code sont alors différentes (CMS cible les webmasters, framework cible les développeurs).

Tout à fait d'accord avec ça. Mais "étude de marché" suppose que le marché est "étudiable". Tu as raison, mettre en place un questionnaire sur les attentes d'une population ciblée est sûrement très utile, mais c'est à prendre avec précaution : sur le papier, les gens peuvent dire une chose et se comporter autrement dans la réalité. Et surtout, si tu proposes un truc un peu novateur, l'étude risque de ne pas "parler" aux gens. Je crois vachement au ressenti des gens quand ils essaient un truc, à l'expérience que ça leur fait vivre, à l'histoire que ça leur raconte... Une étude de marché, c'est parler du projet, mais ça n'est pas le projet lui-même. Bien sûr, j'exagère mes propos et je te rejoins dans le fait qu'une bonne dose de préparation (étude ou autre) doit précéder son engagement dans tout projet. C'est exactement comme le business plan : les chiffres mentionnés sont peut être inexacts, mais au moins il aura permis de réfléchir aux bonnes questions. Ce que j'ai voulu dire, c'est que pour cerains projets (notamment un petit site avec peu de travail), "le faire pour voir" peut être plus pertinent que d' "essayer de savoir s'il faut le faire".

La couche d'abstraction pour la BDD, tout à fait d'accord. J'ai écrit MySQL un peu par réflexe. Notez que les spécifications ne sont pas du tout arrêtées, ce sont des pistes. Le fait que vous réagissiez par rapport à ça me fait penser que je me suis peut-être mal exprimé. L'idée centrale de mon message, c'est "des gens avec des besoins communs associent leurs ressources (financières ou en développeurs) pour construire un framework qui répondra à LEURS attentes". Ce qui veut dire que : le framework ne sera et ne fera que ce que les associés (ou sponsors) voudront qu'il fasse. Si tu es associé (ça fait très business, mais bon), tu décides des fonctionnalités avec les autres (impossible avec les nombreux frameworks existants). le but du framework n'est pas de "présenter une spécificité", simplement de faire EXACTEMENT ce qu'on attend de lui (c'est déjà énorme) ça présente les autres avantages cités ds mon précédent post (meilleur code, coût moins élevé...) Les inconvénients ? Le risque que chaque associé veuille tirer la couverture à soi pour que le framework réalise ce dont LUI a besoin. D'où l'idée de limiter le framework à une couche basse, générique, ré-utilisable pour tous sites, et dont tout le monde aurait besoin. Après, rien n'empêche de sponsoriser une fonctionnalité particulière si on en a besoin. Ca se fait déjà : certains postent des messages dans les forums du style "xxxx EUR pour un plug-in qui fait ci ou ça sous WordPress".

Salut Arnaud, c'est marrant, ça fait plusieurs fois que je lis "étude de marché" dans les forums. Et vraiment, j'aimerais qu'on m'explique comment on fait une étude de marché sur Internet. Où sont les chiffres ? D'où viennent-ils ? Quelles sont les personnes interrogées ? Personnellement, je suis plus partisan de tester une idée en montant un site et "voir si ça prend", plutôt que d' "étudier le marché" (quel marché d'abord ? on est sur Internet) pour savoir ce qu'il en pense.

C'est vrai. C'est parce que je viens de démarrer une nouvelle activité (en tant que société) et donc j'essaie d'explorer les différentes pistes. Oui, il existe des tas de frameworks, mais un paquet ne répondent pas à mes exigences (notamment : respect des standards, PHP5, séparation du code et de la présentation). Dans ceux qui restent, je pourrais peut-être trouver mon bonheur, mais je suis dépendant de la communauté derrière le framework : est-elle active ? corrige-t-elle les bugs rapidement ? si je dois personnaliser le framework, est-ce que ça va me prendre du temps pour comprendre comment il fonctionne ?... Dans tous les cas, les frameworks sont rarement suffisamment génériques ou flexibles, et donc je vais être amené à me plonger dans les profondeurs du code et y passer du temps. Dans ces conditions, autant l'avoir conçu depuis le départ. Sponsoriser un projet open-source = le code produit reste open-source mais le travail des développeurs qui bossent sur le projet est rémunéré. Cette rémunération prend souvent la forme de primes (le développeur touche autant pour tel module développé), mais ça peut aussi passer par l'embauche d'un ou plusieurs développeur(s) à temps plein sur le projet (Drupal fonctionne selon ce modèle). Concrétement, ça permet à des gens qui ont des attentes précises et un peu d'argent de s'associer pour : définir ensemble le framework dont ils ont besoin (alors que framework open-source = tu prends tel quel) répartir le coût du framework entre eux obtenir un modèle beaucoup plus réactif (les développeurs sont payés pour accomplir une tâche précise dans un délai précis) de bénéficier de certains avantages de l'open-source, notamment plus de testeurs et de feedback qu'avec un projet développé en interne C'est ce que j'ai fait moi aussi jusqu'à présent. Mais je suis persuadé que la qualité du code et la puissance de travail d'un seul développeur ne pourra jamais battre la qualité et la puissance d'une communauté de développeurs (à fortiori s'ils sont rémunérés, et donc plus motivés).

Salut Régis, J'ai été plusieurs fois amené à recruter des développeurs PHP dans le cadre de mon travail. Voici quelques pistes : Un test me paraît indispensable. Il te permet d'apprendre plein de choses sur un développeur : s'il code proprement, s'il code rapidement, s'il code logiquement. Selon moi, le test ne doit pas être trop difficile : il s'agit plus d'évaluer la façon de coder que les connaissances. Le contenu de ton test peut être adapté à tes besoins précis : si tu fais un projet qui manipule du XML, mets du XML dans ton test. Niveau logiciel, le bloc-note paraît un peu austère mais un éditeur simple est recommandé (faut pas que le candidat perde 10 min à comprendre le fonctionnement d'un éditeur hyper compliqué). A titre d'exemple, le test standard qu'on faisait dans ma boîte était : lister le contenu d'une table ds une base de données (déjà créée), pouvoir effacer, insérer, et mettre à jour ce contenu. Rien de bien sorcier. Le candidat doit partager vos valeurs. C'est encore plus vrai dans une petite boîte, en open-space. Je sais que tu t'interroges sur les critères de recrutement d'un développeur, mais c'est aussi une personne avec qui tu vas passer tes journées et peut-être déjeuner le midi. Tu seras plus heureux avec un candidat moyen en PHP mais jovial, qu'avec un tueur en PHP qui prend tout de haut. Le candidat doit être passionné. Il y a de fortes chances que le candidat ne sache pas déjà faire tout ce que tu vas lui demander, mais il peut apprendre. Pour moi, la curiosité et l'intelligence sont de bien plus grandes qualités que les connaissances déjà acquises. C'est pour ça que les diplômes ne sont pas très importants (ds ce domaine). En revanche, il faut évaluer son intérêt pour la programmation et PHP en dehors du boulot. S'il lit des bouquins, lit la presse, connaît les nouveautés, qu'il a "bidouillé" des appli PHP pour son plaisir... c'est très bon signe ! N'hésite pas si tu as d'autres questions. Vincent

En tant que webmaster, nous sommes nombreux à nous demander comment générer des revenus sur le net. Je voudrais aujourd'hui m'intéresser à l'un de ces moyens : vendre du code qu'on a conçu. Par "code", j'entends : une application complète, un système de gestion de contenu, un simple script, une classe ou un module... Peu importe tant qu'il s'agit de code qui s'exécute sur un site web et qui est vendu comme un tout fonctionnel. Selon moi, vendre du code présente plusieurs avantages par rapport à "vendre" (= gagner de l'argent avec) un site : Le code peut être vendu plusieurs fois (un nombre illimité de fois, bien plus de fois qu'on ne pourra créer de sites). Le code est la partie la plus facile. Pour quelqu'un qui sait programmer, il "suffit de" vendre son code aux webmasters qui en ont besoin. Ca sera ensuite à eux de faire tout le travail de remplissage du site, la promotion... bref, le plus dur. C'est un peu comme de dire qu'il est plus facile de créer un traitement de texte que d'écrire un best-seller (c'est un peu tiré par les cheveux, mais vous voyez l'idée). Vendre son code à quelqu'un = convaincre 1 personne ; vendre son site à quelqu'un = convaincre des centaines de personnes de l'utiliser. Je serais curieux de connaître votre opinion sur le sujet : Pensez-vous qu'il est plus facile et intéressant de vendre un outil générique (le code) à des webmasters plutôt que de vendre des sites aux utilisateurs finaux (vendre des sites = faire des sites qui fonctionnent) ? Si oui, quel type d'outil/de code vendre? Qu'est-ce qui serait utile aux webmasters ? (merci de ne pas faire de pub ds vos réponses, en indiquant uniquement le style de code ; par exemple : un script d'annuaire, un outil de gestion automatique de formulaires...) Vincent