NiCoS

Si je comprends bien : - tu aurais une liste de flux RSS (en vrac ? catégorisé ?) - l'admin peut faire une recherche parmi ces flux (sur quels critères ?) - pour un flux qui l'intéresse, il peut le sélectionner et l'affecter à une ou plusieurs catégories du site / de son application pour pouvoir les visualiser ensuite ??

Je comprends ton point de vue mais pour le coup, je pense que c'est au prestataire de bien délimiter son périmètre et sensibiliser son client. Ce n'est pas forcément évident mais je pense qu'il faut aussi apprendre à dire non à son client si la demande ne rentre pas dans le périmètre d'intervention ou si cela va trop loin. On peut compatir avec lui, trouver ça dommage, comprendre son problème mais lui faire comprendre que son problème ne rentre pas dans le cadre de la prestation qu'il a acheté. A trop donner, on se fait bouffer et on ne récolte que les problèmes je trouve parfois...

Là, c'est un autre débat - tous les projets de la boite où je travaille ne sont pas OSS, on cherche à prendre le meilleur outil en fonction des besoins du client... Ce n'est pas à toi de supporter leur choix. S'ils ne prennent pas de contrat de maintenance, ben tant pis pour eux... J'ai personnellement des clients avec des solutions OSS que je suis (et qui me sont donc fidèles) depuis plus de 3 ans et sans aucun soucis (on les conseille, on fait des évolutions, on fait des mises à jour si nécessaires) et sans contrat de maintenance particulier d'ailleurs. Ils nous font des demandes ponctuellement qu'on assure. Cet argument n'est pas recevable...

Pour la migration d'un logiciel vers un autre "plus à la mode" ou plus adapté, cela coutera moins cher au client si le 1er soft est libre que s'il est proprio (sous réserve que la boite retenue connaisse le premier outil). Sinon va falloir ajouter une partie de reverse engineering dont le client aurait pu se passer... Pour le coté évolution qui casse la compatibilité avec la version précédente, en général un script de maj est fournie... charge au client et/ou au prestataire (qui peut ne pas être le prestataire initial) de faire la mise à jour...

Merci, je peux te retourner le compliment

Hmm à mon avis, c'est plus subtile que tes propos (si je m'en remémore bien) et plus subtile que "un logiciel libre est totalement sur". Ce qui compte surtout c'est qu'un soft (OSS ou proprio) soit patché rapidement, plus que son nombre de failles. La licence ne fait pas la sécurité, même si je pense que en ayant un code libre, on est certes plus sensibles aux failles mais aussi on peut les corriger plus rapidement qu'un soft proprio (vu que les failles ne sont pas repérées sauf lors de la réalisation d'un audit ou si l'équipe a les compétences pour les trouver). Sur le long terme, un soft OSS est à mon avis de meilleure qualité qu'un soft proprio sous réserve d'avoir les équipes adéquates. Un soft OSS peut en outre permettre de récolter l'avis de développeur n'ayant pas les mêmes connaissances ou pratiques de dev. Du coup, chaque développeur peut éclairer de son avis les éventuelles faiblesses / risques du soft OSS. Dans un soft proprio, si c'est toujours la même équipe qui bosse dessus, il se peut qu'ils ne voyent jamais la/les failles qu'ils ont créés/laissés. Voir à ce sujet : - http://blogs.zdnet.com/Ou/?p=352 - http://www.washingtonpost.com/wp-dyn/conte...6021100217.html Alan Cox dit bien de faire attention au cliché du "si c'est libre, alors c'est forcément sur" et rien de plus...

Pour Sivit, pourquoi tu ne prends pas un vds avec les modules sivit ? pour le coup tu n'auras rien à configurer pour apache/mysql/mail/dns, tu auras juste à utiliser l'interface dédiée à cet effet

Tu en trouveras aussi sur la zone : http://zone.spip.org/trac/spip-zone/browser/ ou sur spip-contrib http://www.spip-contrib.net/-Squelettes-

Plusieurs éléments de réponse : - il faut penser "simple" : plus ta fonctionnalité est complexe, moins elle sera utilisé (car inutilisable) - il faut penser "simple" (bis) : mieux vaut une fonctionnalité simple et l'enrichir dans les version ultérieures que spécifier/implémenter une uzine à gaz qui ne verra jamais le jour - il faut faire confiance au prestataire (ou au moins en discuter) sur ce qu'il a l'habitude de voir (combien de fois on m'a demandé des workflow en au moins 3 étapes ou debrayables ou avec et au final, on voit que 2 est suffisant...) Sinon, je rejoinds l'avis de mes camarades

Oui, là où les virtual hosts sont définis...

Hello, J'ai pris l'habitude d'héberger mes sites sous Apach2 que je trouve très souple à utiliser (surtout sous Debian avec les a2enmod/site & a2dismod/site). Je vois à droite et à gauche (surtout depuis que Rails est sorti), que lighttpd peut être une bonne alternative à Apache. Lighttpd semble plus léger / rapide que ce dernier. Comme je vois le load average de mon serveur monté au fur et à mesure, et comme je n'ai pas vraiment envie de me payer un hébergement plus cher, je me demandais si cela pourrait valoir le coup de migrer vers lighttpd. Les sites hébergés sont principalement en PHP/MySQL, ainsi que 2 instances de subversion/trac et prochainement des sites sous Python/Django. Est-ce que vous avez des retours sur la migration de Apache/PHP5/Python/mod_php/mod_python à Lighttpd/FastCGI/PHP5/Python ? Je suis déjà tombé sur ceci : http://buytaert.net/drupal-webserver-configurations-compared Merci d'avance, Nicolas

As tu vérifier que AllowOverride est à All pour ton domaine ?

Sans vouloir te flatter ou te rassurer, dans la mesure où tu as une démarche visant à te renseigner ou mieux comprendre les choses, je ne pense pas que tu sois ce type de personnes . Ce type de personnes connaissent la vérité ultime donc ne seraient pas venus poster un message ici... Et puis maintenant que tu es prévenu, tu n'as pas de raisons de tomber dans ce travers Bonne journée, Nicolas

Il me semble que le javascript est en effet echappé pour des raisons de sécurité. Quand tu dis que tu as essayé <HTML></HTML>, as tu aussi essayé avec <html></html> ?

Ah ah ah :-D Tout dépend de ses besoins et les moteurs de blog ne sont que des CMS spécialisés/particuliers.

Et moi, rien... snif, je suis jaloux... Sur ce je repars dans Django...

Ben la maintenance corrective/évolutive, ainsi que les montées de version je présume Tout dépend du contrat avec le prestataire. Même si le PHP est lisible (pour le coup, il peut être encodé pour éviter qu'on lise les sources), le contrat qui te lie à ton prestataire peut t'empêcher d'y toucher... Sans vouloir te vexer (ce n'est pas le but, juste du vécu que je raconte), je me méfie du client qui connait le web / a des compétences en matière de programmation. Cela peut être un grand atout comme une cause d'échec. J'ai déjà eu des responsables informatiques de structure ou des personnes qui soit disant s'y connaissaient et qui en faisant part de leurs avis ont failli faire capoter certains projets. En voulant briller devant leurs camarades peu au fait du monde du web, ils donnent parfois de mauvais conseils et peuvent ainsi pousser le projet dans une direction qui n'est pas la bonne sous prétexte "qu'ils connaissent" ou "qu'ils savent". A contrario, j'ai aussi eu des clients ayant ses compétences et avec qui se fut un plaisir de travailler et le projet a ainsi pu bénéficier de synérgies très intéressantes. Je pense que tant du coté prestataire que "client qui connait" il faut savoir rester humble/honnête et apprécier les apports de chacun et chercher à jouer sur les complémentarités. Un client peut être doué en programmation / architecture web / ... mais nul en ergonomie par ex. On a l'impression que pour certains responsables informatiques, c'est reconnaitre leur défaillance que de faire appel à des prestataires... et du coup ils se braquent... Pour conclure, je pense qu'il faut laisser le prestataire présenter sa méthodologie et l'ajuster le cas échéant si certains sujéts sont maitrisés ou si la réflexion est mature / a déjà été menée proprement. Sur ce, bon week end

Je connaissais pas ce petit dernier... à quand le frameworkmatrix ?

Je n'ai pas dit non plus qu'il fallait avoir 20 outils à son arc Sur le principe, on a la même logique que davidm (se concentrer sur qqs outils pour avoir une bonne compétence sur chacun d'entre eux tout en ayant la possibilité d'offrir un panel à nos clients) sauf qu'avec notre nombre (~40), on a un effet multiplicateur intéressant Faut en tous cas bien choisir son produit pour une telle stratégie. Il y a 2 ans en arrière, alors que beaucoup de CMS permettaient encore peu de typer ses contenus ou de créer des nouveaux types de contenus, je me suis souvent retrouvé bloqué ou du moins un peu en peine à répondre à certains cahier des charges. Si les besoins vont vers des aspects que ton outil ne couvre pas du tout ou peu, tu vas te retrouver dans la mouise et à devoir trouver un remplaçant. Néanmoins, avec drupal, tu as a priori un panel de fonctionnalités importantes qui devrait te permettre de voir venir les choses

http://www.wikimatrix.org/ est aussi ton ami

Pour moi il y a une énorme différence : - si tu fais appel à un prestataire qui ne vend qu'un cms (au delà des problématiques de format ouverts, pérennité de l'entreprise, etc mentionnés par davidm), le prestataire ne pourra pas te proposer autre chose et tu risques de payer très cher le fait d'adapter l'outil à ton besoin... voir même tu devras adapté ton besoin à l'outil... - si tu fais appel à un prestataire utilisant des outils opensource/libre et que ce dernier en maitrise plusieurs, alors il va pouvoir répondre à ton besoin en prenant l'outil qui répond le plus à tes besoins (le 100% est rarement atteignable, quoique...) et donc tu évites d'être dépendant d'un prestataire en tant que tel (un autre prestataire peut maitriser l'outil retenu) et en plus, le cout des dev devrait être moindre (et à long terme, la maintenance et montée de versions devrait être facilitée). C'est cette approche (compétences sur plusieurs cms & technologique) que ma boite a retenu. Cela nous permet pour un cahier des charges données de pouvoir répondre avec l'outil qui nous semble le plus adapté (que celui-ci soit open source ou propriétaire d'ailleurs). Il nous arrive même d'évaluer les outils de nos clients au regard de produits du marché. Il m'est ainsi arrivé dernièrement d'évaluer des CMS comme drupal, ezpublish avec le framework d'un de nos clients pour voir quel était l'outil le plus adapté pour réaliser leur projet... Pour en finir, je te dirais effectivement de bien définir ce que tu veux d'un point de vue fonctionnel (voir les propos de davidm que je rejoinds totalement) et ensuite de proposer ton cahier des charges à des prestataires qui ont des compétences multiples pour avoir la meilleure réponse possible... Il est à mon avis pas/peu souhaitable que tu te focalises déjà sur un outil (mais avoir un aperçu des fonctionnalités des cms existants peut t'aider bien sur dans ta réflexion...). Hope it helps...

+1 / premier post de davidm sur le choix des outils et sur l'appel à un prestataire (qu'il s'appelle webagency, intégrateur, ssii,...). Comme dans tout métier, il faut choisir le bon partenaire et pour chaque type de partenaire, il y a des bons et des moins bons... De même, plutot que de choisir directement un outil, il me semble plus judicieux que tu te concentres sur la définition de tes besoins, qu'éventuellement tu communiques à l'éventuel prestataire une liste des outils que tu as vues mais qu'il puisse éventuellement t'en conseiller d'autre ou du moins celui qui lui parait le plus approprié pour ta demande. Ensuite, sur l'évaluation des différents outils, vous pouvez très bien lancer une discussion pour qu'il argument son choix J'avoue avoir du mal parfois avec "je veux faire mon site avec tel outil" (sauf s'il y a une contrainte forte bien sur...), car souvent on voit que ce n'est pas l'outil le plus adapté ou que ce n'est pas la solution la plus optimale (en cout, délais, etc).

Je ne visais pas ton produit en particulier, que je ne connais pas, et tant mieux s'il résoud des problématiques qu'un CMS libre n'existe pas. Ce qui m'a énervé, c'est la façon dont tu vois les CMS libres dans tes propos initiaux alors que sur la fin, tu reconnais qu'il y a des logiciels libres pro Le fait que le code soit ouvert et à la disposition de tous peut certes permettre la recherche de faille pour les exploiter mais aussi pour les corriger... chaque avantage a ses inconvénients et inversement. Un produit proprio peut être tout autant un gruyère en matiere de sécu qu'un produit libre. Sauf que comme pour le produit proprio, l'éditeur publie rarement ses failles... ben on a juste aucune visibilité sur sa sécurité. La sécurité apparente d'un soft proprio n'est qu'apparente pour le consommateur vu qu'il n'a aucun moyen de la vérifier. Au moins avec un soft libre, tout à chacun peut mener des audits et s'il a les compétences nécessaires, l'utilisateur peut vérifier que le produit est sure (et le corriger le cas échéant ) Aucun, nous sommes d'accord et de toute façon, si tu veux vendre ton produit, vaut mieux qu'il ait un intérêt Je ne suis pas contre le proprio (relis mes propos) mais seulement s'il se justifie. Sur le milieu ultra concurrentiel des CMS, je suis pas sur que ce soit une bonne idée d'avoir un produit proprio (vu le nombre pléthorique de CMS libre) si ce CMS ne fait que des fonctions de base. S'il apporte un plus, pourquoi pas... même si je doute de sa capacité à maintenir son avantage sur le long terme si l'éditeur est de petite taille ou n'a pas des clients qui financent massivement le projet. Après, tu fais ce que tu veux hein et bon courage à toi et je te souhaite de réussir :-) Sur ce, bon dimanche

Si les logiciels libres ont des failles ou sont réservés pour des utilisations perso, peux tu me dire ce que tu penses de : - bind - apache - postifx - mysql - php - ... Si les logiciels libres sont plein de failles & co, j'en déduis aussi que ton cms devrait être basé sur un langage proprio (asp & co) ? J'espère que tu es cohérent avec toi même jusau'au bout... ce coté libre = amateur/perso ou proprio = professionnel me fait doucement rire... Je ne suis pas contre les logiciels proprio si et seulement si ils apportent un avantage réel et bénéfique pour les utilisateurs sans qu'on le prenne pour une vache à lait. Il y a encore je pense plein de secteurs dans lesquels le logiciel proprio a des raisons d'être et de belles années devant lui. Pour un CMS basique, j'en doute car amha un bon logiciel libre (avec une communauté & co) peut largement dépasser un soft proprio... et dans ce cas, si le client a pris un cms proprio il est largement perdant. Bref, je comprends qu'il y ait des softs proprio pour des besoins spécifiques / spécialisés mais pour des besoins classiques de CMS, je privilégie le libre... Le seul cas ou je favoriserais une solution proprio / une solution libre est si le soft proprio fournit d'emblée tout ce que mon client souhaite et si cela couterait plus cher de le faire avec un libre pour le mettre à niveau... Je préfère le pragmastime ou prosélytisme/intégrise libre vs proprio... surtout quand il est aussi mal argumenté...

Trop gros, passera pas L'ouverture du code permet aussi de le corriger plus vite. rien n'indique qu'un produit proprio est de meilleure qualité / a moins de bugs / a moins de faille, puisqu'on ne peut accéder à son code !! Quel joli FUD en tous cas en ce samedi matin !