davidm

Cf ce que j'ai dit ci-dessus sur la pérennité et la dépendance de l'open source vs propriétaire. A mon avis une application propriétaire abandonnée est bien plus problématique... Et au passage, qui peut garantir qu'une boîte sera encore là dans 5 ans ? La pérennité n'est pas plus du côté d'un éditeur que d'une communauté open source (en tout cas, pour celles qui réunissent des centaines voire milliers de designer/utilisateurs/développeurs depuis plusieurs années). Une tendance "fashion victim" des acteurs du libre ? je ne vois pas grand chose bouger de ce côté là au contraire la plupart des prestataires ont suivi les acteurs principaux comme L*nagora ou S*ile : Typo3, SPIP, Joomla/Mambo c'est 90% du marché des CMS libre en PHP/MySQL et ça ne bouge pas vraiment (pour rester tendre ). Après du as des indépendants comme Loupilo qui bosse avec SPIP et Textpattern, Vincent ou Claire qui travaille sur Drupal (le challenger n°1) ou sur d'autres systèmes "challengers", et enfin tu as des gens comme moi qui sont des passionnés qui suivent ce qui se fait outre-atlantique et qui traduisent+importent des systèmes "innovants" (enfin je pense, comme je l'ai fait pour Textpattern ou MODx). Je ne suis pas sûr qu'il y ai plus d'effet turn-over dans une communauté open source que dans une entreprise...

Et apparemment dans l'intervalle il avait atteri dans le mauvais sujet (celui sur CMS et web agency) Concernant cet article (un peu court au niveau de la démonstration, soit dit en passant) son point de vue c'est que "Dans un environnement pur et parfait, le logiciel libre ne serait pas plus sûr que les logiciels dont le code source est tenu secret." Il s'agit donc d'un raisonnement abstrait, dans l'absolu. "Ross Anderson montre en effet qu'un code source rendu public est aussi vulnérable qu'un code source privé." A mon avis, je dirai que tout dépend de la situation : il s'agit d'un arbitrage entre l'avantage de fermer le code au public afin de rendre plus difficile (mais possible, mainte fois démontré par la réalité) à pirater et l'avantage de soumettre le code aux yeux du plus grand nombre pour qu'il soit amélioré et rendu plus sûr. La phrase "les responsables de Microsoft soutiennent depuis bien longtemps que Windows est plus sûr avec un code privé qu'il ne le serait si son codé était public." est une illustration parfaite de mon propos ! Ca veut dire : si je suis mauvais, mieux vaut ne pas faire de pub du code (ça tombe sous le sens)... Bien sûr, mieux vaut laisser le code de Windows fermé parceque sinon ce serait un désastre complet vu la qualité de celui-ci... pardonnez moi de revenir à Windows, mais la suite du texte de l'article me ramène sur les OS puisque la méthodologie de test MTBF est calibré pour les systèmes d'exploitations (OS). "Mais comment Ross Anderson a-t-il procédé pour parvenir à de telles conclusions ? Il a utilisé une application couramment employée par l'industrie informatique qui permet de tester le temps que met un système avant d'être affecté par une panne. Un standard qui porte le nom de MTBF et qui a déjà fait ses preuves dans les services de contrôle qualité de nombre de fabricants. Inutile de préciser que le protocole de test a été calibré pour ne repérer que les bugs qui mettent en danger la sécurité d'un OS." Donc en matière d'OS je dirai quelque soit les conclusion de Ross Andersion d'un point de vue théorique que la réalité est là : Windows est un gruyère par rapport à Linux ou OS X (et de TRES loin, demandez à la NSA et au FBI pourquoi ils sont tous passé sous Mac OS X et Linux...). Encore une fois, je vais être en désaccord avec toi. Non pas sur le fait que la licence / le mode de développement n'est pas le critère discriminant concernant la sécurité d'une application (dans un sens, ou dans l'autre) mais c'est bien la qualité du code produit et le respect de certaines bonnes pratiques qui est le facteur n°1. Qu'il soit plus facile de trouver une faille dans un logiciel open source que dans un logiciel propriétaire, évidemment puisque le code est ouvert. Mais la médaille a son revers : le fait que le code soit fermé de permet pas de juger de la qualité de l'application sur l'aspect essentiel des techniques de conception et du respect de bonne pratiques... La confiance dans la sécurité d'un logiciel propriétaire est donc intrinsèquement fondée sur la réputation du (des) développeur(s) et/où de l'éditeur... On en arrive au sujet de la dépendance... Concernant la dépendance maintenant, là je pense que la dépendance est du côté de l'application propriétaire. C'est naturel, puisque le modèle économique du développement d'applications propriétaire est par définition basé dessus ! Combien de développeurs maîtrisent l'application ? Un nombre restreint puisqu'on a pas accès au code... la boîte fait faillite ? Je suis potentiellement coincé avec une application propriétaire que je ne maîtrise plus... pire encore, si le format des données est lui aussi propriétaire et que je ne peux pas l'exporter et le transférer à un autre outil.... En revanche, si un projet open source s'arrête, je dispose du code et à supposer qu'une autre communauté ne reprenne pas le code, je demande à n'importe quel développeur compétent en php/mysql ou java, ou Ruby... etc qui peut reprendre la maintenance, le développement...etc. Je peux aussi exporter les données et les utiliser dans un autre système... Je suis donc libre et totalement indépendant, au contraire...

L'explication c'est que j'avais splitté ce post déjà long car tu as lancé une nouvelle discussion sur la sécurité des applications open source vs propriétaire, qui est un sujet à part entière...

Hmmmm, je ne sais plus la/lesquelles mais il me semble bien que ça existe pourtant (Drupal ?)... au moins pour la mise à jour du système (par exemple Textpattern). Mais c'est vrai qu'un système de patch auto, c'est intéressant ! Tellement que je vais voir avec l'équipe de dév si on ne peut pas mettre ça au programme de la prochaine version de MODx

Note : Quelques redondances avec NiCoS, j'ai mis un peu plus de temps à poster Excellents points, d'ailleurs Les propos d'Alan Cox ne sont pas nouveaux. Dire que parmi le foisonnement des projets open source, une proportion significative est moins sûre que le noyau Linux (c'est la comparaison qu'il fait, sachant que le noyau linux est une des applications les mieux sécurisée de la planète...), c'est une évidence (il y a 133 000 projets open source sur sourceforge !). Bien sûr, comme il le souligne justement tout dépend de l'expérience et des compétences des développeurs. La sécurité d'une application commence par le respect de bonnes pratiques : des choses aussi basiques que configurer PHP avec register_globals Off (en)) jusqu'au respect des règles du secure coding (en) rédigé par Open Web Application Security Project (OWASP). Il va de soi que toutes les applications ne sont pas égales en la matière. Dan pourra témoigner quels sont les "mauvais de la classe" au vu des dizaines de dédiés qu'il administre... PHP Nuke est un bon exemple (d'après Secunia -> voir ici, 31 failles de sécurité, dont 16% seulement ont été patchées). phpBB en est un autre... Un petit tour sur Secunia, un site web dédié au rapport de vulnérabilité d'applications, propriétaire ou libres est donc assez intéressant. Cela démontre si besoin était que la sécurité n'est pas forcémment meilleure côté commercial/propriétaire que côté open source. Il y a de bons développeurs d'un côté comme de l'autre. Chacun sait qu'aucune application n'est inviolable, et la question est plus de savoir : Combien de failles sont découvertes / exploitées Quelle est la criticité des failles découvertes Parmi les failles trouvées, combien sont résolues Parmi celles résolues, à quelle vitesse le patch est publié (surtout pour les failles critiques). Bien entendu, plus un système est répandu, plus le risque de rapport d'une faille est important (et aussi, plus l'intérêt de hacker le système est tentant pour le hacker...). Si je prend l'exemple de MODx, nous avons un développeur spécialiste de la sécurité, Timon Reinhard (aka NetNoise), et jusque là nous avons eu une brèche sur la 0.9.1 de moyenne importance résolue très rapidement. Mais on peut dire que des projets comme Drupal, Joomla ou Typo3 sont globalement tout aussi sûrs et/ou dispose d'un support correct. C'est là que le prestataire joue aussi un rôle important. Rôle de conseil dans le choix de la solution (et là, pour choisir en connaissance de cause il vaut mieux qu'il ai accès au code de l'application ou à défaut aux alertes de sécurité), mais aussi rôle de maîtrise de l'environnement applicatif. Le prestataire maîtrise t-il la configuration de son serveur (s'il est sur un mutualisé, difficile à garantir. S'il est sur un dédié, qui administre son serveur) ? A t-il accès aux remontées de failles (par exemple, l'équipe de MODx a décidé de ne pas rendre public les remontées de faille dans le bugtracker -> afin d'éviter de donner la recette aux petits rigolos qui pourrait profiter de l'intervalle avant publication du patch) ?

Dommage... en ce qui me concerne je pense que le débat est toujours intéressant... En ce qui me concerne je n'ai pas d'idée préconçue. Je ne pense pas que l'open source soit la réponse à tout projet, que les solutions commerciales sont intrinsèquement mauvaises, ou que développer un CMS maison soit une mauvaise option. Dans un grand nombre de cas, je suis par contre de ceux qui pensent que les solutions libres sont très compétitives et que le modèle derrière le développement open source est un bel exemple d'une forme d'économie alternative à l'économie de marché... Enfin, pour finir aucun choix n'est définitif en ce qui me concerne. Si je teste une solution qui me semble meilleure qu'une autre pour un projet donné, je n'hésiterai pas à m'y plonger et à m'en faire l'avocat, l'utiliser et en faire bénéficier mes clients ou même mes concurrents. Evidemment, si je ne peux pas tester une solution, je ne risque pas de l'utiliser (souvent, tester les solutions commerciales passe par un processus qui n'est pas ouvert et donc qui n'incite pas les prestataires à l'adopter). Je ne partage pas ton opinion. 1) Il existe des CMS open source aboutis : autrement dit fonctionnels, surs, performants. 2) Il n'existe pas (heureusement !) de solution universelle : l'outil qui viserait à répondre à *tous* les besoins est voué à devenir une usine à gaz qui sera difficile à maintenir, pour lequel le développement d'extension sera long et coûteux, et qui finalement à vouloir être "tout pour tout le monde" ne sera "rien pour personne. C'est à mon avis le travers de 95% des CMS de type "Portail"... La tendance actuelle du développement web est aux applications "agiles" (pour prendre un mot à la mode . Le livre de 37signals cité plus haut est l'archétype du courant actuel du web qui consiste à recentrer les outils sur les fonctionnalités les plus uliles et utilisées... et comme chacun sait "faire simple, c'est compliqué". Le véritable enjeu est là et non pas dans la licence des applications : les applications de 37 signals ne sont pas open source et pourtant j'applaudi des deux mains BaseCamp, TaDa List, WriteBoard et CampFire (le seul hic, le manque d'internationalisation de ces applications hébergées). Il faut donc changer notre mode de réflexion sur les outils, "moins, c'est plus". Cela demande un effort constant au quotidien, car nous sommes formatés à penser en terme de puissance, de comparison de listes de fonctionnalités, de cahiers des charges.... etc. Mais les vrais juges sont les utilisateurs : qu'ils soient prestataire chargé de la mise en oeuvre comme moi ou qu'il soit utilisateurs finaux. Catpcha vocal, voilà une innovation intéressante pour l'accessibilité des sites web ! Bravo donc J'aimerai voir largement diffusé ce type d'innovation... d'où mon goût pour l'open source je dois dire Quant à BBComposer, j'utilise le même type d'outil depuis quelques temps... Citons l'extension BBCode Extra pour Firefox, mais il y en a d'autres.... Ceci dit il semble que tu ai amélioré le principe d'une façon intéressante ! Je vais le tester Edit : tiens j'ai pu voir la démo de XCMS, côté admin.

Si le message original avait expliqué la problématique plus précisémment, la réponse aurait été plus qualitative Maintenant que NiCoS a répondu, je n'ai plus grand chose à ajouter... de plus SPIP n'est pas mon domaine (Loupilo ou est tu ?)

Google Bon, ce n'est pas dans mon habitude de répondre ce genre de chose. Mais avant de poser une question (qui plus est aussi courte), il est bon de se poser la question de savoir si la réponse n'est pas facile à trouver par soi-même... La recherche Google ci-dessus t'aurai donné l'adresse d'une des ressources phrare, spip-contrib... qui t'aurait éclairé sur le fait qu'un thème sous SPIP, s'appelle un squelette. D'où la recherche google suivante : http://www.google.fr/search?q=SPIP+squelet...9l%C3%A9charger Qui t'aurai mené entre autre à : http://www.spip-art.net/net/ Mais il y en a bien d'autre... à toi de chercher !

Cet argument n'est pas totalement faux en ce qui concerne l'indépendance. Pas totalement faux, mais dans la pratique je ne suis pas sûr que ce choix soit forcémment optimal. Il est quand même difficile pour un développeur seul de produit le même niveau de qualité de code qu'une équipe de personnes motivées et souvent très compétentes (les statistiques nous disent que l'expérience moyenne d'un développeur dans le monde de l'open source est de 11 ans). D'autre part, l'open source est un monde habité de passionnés, qui ne sont pas là pour l'argent mais pour travailler librement, de manière collaborative. Les conditions d'émergence de l'innovation sont bien là... Concernant la perrenité, l'argument n'est pas moins vrai pour une entreprise que pour une communauté. Voire même, moins vraie en ce qui concerne l'open source puisque précisémment les sources sont ouvertes et à supposer qu'une communauté abandonne un projet ou décide de passer à une licence commerciale pour les versions ultérieures d'autres dev peuvent très bien reprendre le code et le faire évoluer. C'est, au passage, ce qui s'est en partie passé lorsque le concepteur d'Etomite a abandonné le projet pour se consacrer à l'écriture d'un CMS commercial dérivé du code d'Eto. Certains dév, dont Ryan Thrash et Raymon Irving (deux des fondateurs), qui avait développé une extension majeur nommée... MODx, sont parti de la communauté en "forkant" suite à des luttes de pouvoir intestines. Je ne pense pas que le fait qu'un CMS propriétaire soit plus pérenne qu'un CMS open source. Les sources sont fermées et si un produit n'est plus supporté pour X ou Y raisons, vous êtes le nez dans le sable avec un code propriétaire dont vous ne pouvez rien faire. Je ne partage pas cet avis. En quoi cela permet-il d'avoir un "temps d'avance" ? Dans quel domaines ? J'aimerai comprendre en quoi cela peut devenir des arguments commerciaux redoutables... je suis curieux ! Pour te contredire, tout dépend des communautés : certaines sont animés par un développeur unique (c'était le cas de Textpattern, maintenant ils sont trois mais il n'ont pas le talent de Dean...), d'autres par 2/3 développeurs, d'autres (comme Drupal, MODx ou Joomla) par une équipe de fondateur entourée de dizaines de développeurs. Pour avoir testé pas mal de CMS propriétaires, rares sont ceux qui sortent du lot... la proportion n'est ni moins bonne ni meilleure que dans l'open source (encore que ).... Encore une fois, je vais te contredire : tout dépend de la qualité de la documentation de l'API... et pour ce qui est des failles de sécurité, reprenons l'exemple de Windows et Linux : lequel est le plus sûr ? Je ne pense pas que la taille d'un CMS soit directement proportionnelle à sa qualité : tout dépend des fonctionalités présentes....

J'ajouterai juste à l'excellente réponse de Vincent que, pour moi, le sur mesure en partant de zéro n'est plus une option viable aujourd'hui. Maintenant, on peut soit partir d'un coeur de fonctionnalités avec une API permettant l'extension de ce coeur (cas de Drupal ou MODx et de tous les Content Management Framework), soit partir de zéro mais s'appuyer sur un framework applicatif (Web application framework) qui est plus généraliste qu'un CMF (typiquement aujourd'hui c'est Django, CakePHP, Code Igniter, Symfony, Ruby On Rails...etc). C'est simplement une question d'efficacité. Ces frameworks offrent effectivement des bibliothèque de fonctions de bas niveau comme dit Vincent et qui permette d'éviter de ré-inventer l'eau chaude.

Je pense que cette discussion dépasse largement le cadre des outils... Joomla! peut être customisé bien sûr, et sortir du modèle à 3 colonnes -> mais pas aussi rapidement et facilement qu'avec d'autres outils. Mais c'est un autre débat...

Difficile question. Faire simple, c'est compliqué La tendance actuelle du web c'est le recentrage sur l'essentiel, que ce soit côté applicatif ou côté design. 37signals est en effet un modèle du genre et "Getting Real" donne quelques recettes en la matière. Un premier moyen de savoir si une fonctionnalité va être utile et surtout utilisée c'est de ne pas prendre le projet à l'envers au démarrage. C'est à mon avis un des gros écueil du processus traditionnel de définition d'un cahier des charges : on raisonne dèjà en terme de fonctionnalités souhaitées et souvent c'est le responsable informatique ou dans les petites structure le dirigeant ou un manager qui formule et décide des fonctionnalités qu'il souhaite. A mon sens, on devrait d'abord se poser la question de savoir quels sont les objectifs que l'on vise lorsque l'on lance un site ou/et une application web. Ensuite, on devrait sonder les futurs utilisateurs sur ce qu'ils attendent de l'outil (de manière très simple, sans forcémment lancer une étude qualitative complexe). Cela présente deux avantages : on prend en compte les besoins des utilisateurs finaux pour valider les objectifs et les prioriser. Ensuite seulement, on traduit ces objectifs en spécifications fonctionnelles. Moins l'écart entre les besoins et les fonctions est grand, plus on a de chance que l'outil soit utilisé. Moins l'écart entre les objectifs et les fonctions est grand, plus on a de chance que l'outil soit efficace (rappelons que la définition de l'efficacité c'est le rapport Résultat/Objectif. L'efficience, c'est Résultat/Moyens...). Vincent a raison, plus un outil permet de combiner librement des briques fonctionnelles très granulaire, plus il est capable de s'adapter aux besoins de l'utilisateur final. Le type même d'outil qui permet ce genre de chose, c'est le framework. Les briques fonctionnelles d'une API visent avant tout à automatiser les opérations de base dont on a besoin pour traiter les données. On ne part pas de zéro (on a des composants ayant chacun leur fonction), mais on est pas coincé dans un moule pré-défini (qui nécessairement ne correspond pas forcémment au besoin). Ceci dit, il faut quand même nuancer parceque la logique derrière cette approche, c'est la personnalisation complète des applications. Et qui dit personnalisation dit quand même développement additionnel. La question a se poser c'est donc : mon besoin est-il spécifique ou générique ? S'il est spécifique, alors il peut être plus pertinent de prendre la voie "37 signals", s'il est générique alors c'est plutôt le packaging pré-configuré à la Joomla! Bien sûr, je schématise fortement, on est rarement dans un cas où dans un autre. Dans la liste des besoins, certains sont génériques (et donc des modules pré-configuré, à condition de laisser une certaine liberté quand même) sont adaptés - certains sont spécifiques (il est alors pratique d'avoir une API sous la main pour travailler vite et efficacement au développement d'un module). C'est l'essence même qui m'a conduit à choisir MODx comme fer de lance de mon activité : à la fois CMS et framework...

Et voilà ce qui sera probablement la dernière béta (on aurait pu l'appeler MODx 0.9.5 Release Candidate, franchement...). MODx 0.9.5 beta 5 est sortie : Annonce originale Téléchargement

"faire" ou "faire faire", un choix effectivement qui se présente quand on a les ressources en interne. Attention toutefois à ce que je disais, si le web semble "facile", il ne l'est pas forcémment... un projet web est un projet complexe, et une application web n'est pas moins complexe qu'une application traditionnelle (le fait de devoir gérer des environnements clients hétérogène -> i.e plusieurs plateforme + navigateurs, n'y est pas étranger). Le lien, c'est qu'un système de navigation (menu) par exemple, qui est une des pièces maîtresse de l'interactivité sur un site, ne peut pas se permettre d'être inaccessible. Si il est mal conçu, ou inacessible à certains visiteurs, ceux-ci ne reviendront pas... Exemple type : menu en Flash, menu en javascript (si une alternative n'est pas prévue...). Mais il ne s'agit pas seulement de la technique utilisée pour le menu (full CSS est préférable toutefois), mais aussi de la réflexion initiale sur la façon dont on va structurer le site et penser la logique de la navigation... Oui. Très souvent. En partie parcequ'en plus d'avoir beaucoup lu sur le knowledge management depuis 1998, j'ai une bonne expérience du conseil en organisation (et une formation initiale (DESS) en management). En fait, je met souvent en garde contre les espoirs vis à vis d'un site web. Que cela soit d'un point de vue des retombées commerciales ou des conditions de réussites pour la mise en oeuvre des outils collaboratifs (et comme tu le soulignes, cela signifie investir du temps et effectuer des choix en terme de management des ressources humaines). Pour un site "plaquette" par exemple, les bénéfices ne sont pas "directs", et dépendent largement de l'intégration de la stratégie web avec la stratégie de com (curieusement, c'est assez rare !), la stratégie commerciale, l'attitude de la société vis à vis de ses clients d'une manière générale... etc. C'est d'ailleurs la raison pour laquelle je passe du temps au début à bien comprendre l'activité de mes clients, et ensuite pour laquelle j'insiste sur la nécessité de ne pas envisager le site web comme une extension "désarticulée". Donc bon point oui : un site web, qu'il comprenne des outils permettant l'interactivité ou pas, est un projet qui ne doit pas être envisagé comme indépendant du reste de l'activité et de la stratégie.... Mais là, ne nous faisons pas d'illusion, nos managers sont peu nombreux a bien comprendre les enjeux et le changement de paradigme induit par ces outils. Ce qui explique aussi qu'ils soient réticents à voir leur autorité (fondé sur le statut) mis en question par des outils qui re-définissent l'autorité (les outils collaboratifs ont le don de faire émerger ceux qui ont des compétences... qui gagnent alors en autorité. Mais aussi ils modifient les interactions des acteurs dans l'entreprise, et les réseaux de pouvoir informels peuvent se développer au détriment de la hiéarchie classique...). Mettre en place ces outils n'est donc pas neutre... J'espère que je ne finirai pas comme lui

Je rigole aussi avec NiCoS et je partage évidemment son avis (mais bon nous sommes des professionnels... ce genre d'affirmation est un peu simpliste à nos yeux) Sinon pour répondre à panchoskywalker, surtout va tester les CMS sur opensourcecms.com, on ne le dira jamais assez... (oops tribords a été plus rapide) Vu ton besoin, regarde plus côté portail facile d'accès au débutant (Joomla! , e107...).

Evidemment, il semble y avoir plein de petits progrès, mais à part quelques contrôles supplémentaire côté interface admin qui donnent un plus à l'utilisabilité, je n'ai pas vu le relifting annoncé... Ceci dit, comme je dis txp reste un excellent CMS au dessus du panier. C'est juste qu'il stagne...

Merci Puisse le ciel t'entendre ! Même si ça marche plutôt bien, rien n'est jamais gagné. Je ne sais pas ce que vous en pensez mais le marché est tendu (notamment, pas mal de gens qui travaillent "vite fait bien fait" qui tirent les prix vers le bas, et il faut vraiment argumenter pour tirer les budgets vers le haut...). Mes deux prochaines références sont "ajaxifiées" (je me suis beaucoup formé ces derniers temps côté AJAX et framework d'effets js comme MooTools) ce qui devrait me rapporter des contacts (curieusement, ce sont les effets "visibles" qui attirent les clients, alors que ce n'est qu'une partie de la valeur ajoutée qu'on apporte). Un des trucs que j'ai mis au point c'est le lancement au chargement de la page d'une animation flash dans une fenêtre type Lightbox, assez cool Ceci dit, pour le "Quel dommage que tu aies choisis MODx et non pas Drupal." je ne pense pas car la diversité est aussi une bonne chose. Certains site seront mieux servi par Drupal, d'autres par MODx... Et de toute façon, rien n'est définitif. A l'époque où j'ai trouvé Textpattern début 2004, j'étais hyper enthousiaste car ça a été le premier CMS à offrir une flexiblité totale côté template (perso un des gros points bloquant côté Drupal pour moi c'est l'utilisation de phpTemplate. Je n'aime pas les moteurs de templates, Smarty non plus d'ailleurs... pour moi ça ajoute une couche supplémentaire et surtout je ne clique pas avec la logique). Ensuite, Dean a laissé tomber Textpattern pour s'occuper de son nouveau bébé, l'hébergeur TextDrive puis ensuite les web apps avec Joyent. Le projet a stagné et dès que j'ai trouvé MODx l'année dernière, j'ai su que j'aurai les avantages de Textpattern (une logique assez similaire côté template), combiné avec la souplesse de structuration des données (via les variables de modèles) et en plus une API et une DBAPI (le côté framework quoi). En plus quand je vois avec qui je bosse dans l'équipe MODx, je peux dire qu'en un an j'ai énormément appris ! (le fait d'être bilingue anglais aide énormément pour apprendre car les ressources sur les techniques de pointe sont majoritairement en anglais) Ceci dit, je suis toujours à l'affut... mais pour l'instant je ne vois pas quel autre outil pourrait avoir ma faveur, d'autant que j'ai une visibilité totale sur ce qui va venir : c'est ambitieux, innovant et ça va faire mal !

Malheureusement, cela arrive souvent, a un degré ou à un autre les clients ont l'impression de savoir ce qui est mieux pour leur site et parfois sont fixés sur des idées qui ne sont pas forcémment pertinentes. Il y a un gros travail de pédagogie à faire, ne serait-ce que pour expliquer ce qu'est le web tout simplement, et pourquoi faire tel ou tel choix peut être vraiment handicapant pour un projet. Le problème, c'est la comparaison avec l'existant : un dirigeant ou un responsable voit un site qui lui plaît, il voit la surface des choses et souvent, lorsqu'on regarde sous le capot, on a peur !!! Sémantique inexistante, code fouilli, technique obsolètes, outil mal choisi...et je ne parle même pas de conformité aux standards. [copyright] Les avantages du web sur les autres médias c'est avant tout ( là je dévoile un peu du contenu du contenu de mon site pro en refonte ): l'interactivité -> de plus en plus vraie avec les interfaces riches la recherche-abilité (désolé pour le néologisme -> la possibilité de trouver une information rapidement et facilement) la connectivité -> de plus en plus vrai avec les web services, les connecteurs entre applications, les protocoles ouverts l'ubiquité (i.e le fait d'être accessible depuis n'importe quel point du globe équipé d'une connection) l'universalité -> de plus en plus vrai grâce à la séparation du contenu et de la présentation (CSS), possiblité de servir du contenu à différent support de manière cohérente (PDA, télphone, TV, dispositif pour aveugles... etc). la facilité d'accès -> le web n'est pas un medium cher ni en publication ni en consultation Je suis obligé de répeter ça très souvent, sur un point ou un autre, pour objecter par rapport à des demandes clients, et voilà comment je traduis les avantages du web (enfin les points 1,2,3 et 5) en exigences à prendre en compte pour le développement : l'interactivité : si votre interface n'est pas accessible, vous rendez difficile la navigation sur votre site, vos pages ne seront pas consultées, vos visiteurs ne reviendront plus (ou peu). la recherche-abilité : si vos contenus ne sont pas balisés sémantiquement (voire pour Flash, pas balisés du tout ), l'indexation de votre site sera handicapée la connectivité : si vous choisissez une solution utilisant des protocoles propriétaires, le coût de développement des "connecteurs" sera beaucoup plus élevé. l'universalité : si vos pages web ne respectent pas certaines bonnes pratiques, elles ne seront pas accessibles à tous les publics et aussi vous devrez re-coder toutes vos pages si d'autres moyens de navigation se développent (qui peut dire combien de personne surferont sur leur téléphone ou PDA d'ici 2 ou 3 ans...). [/copyright] Par ailleurs, on en discutait l'autre jour avec des développeurs : un client n'aura pas la même approche avec une application web qu'avec une application traditionnelle. Pour commencer, une entreprise est prête à dépenser des fortunes en logiciel que ce soit en bureautique (même si Open Office grignote du terrain) ou du côté progiciel. Par contre, elle ne sera pas forcémment prête à investir beaucoup dans un site ou une application web (dans le cas des PME souvent moins que pour leur banale plaquette "papier" !). Le paradigme derrière ça c'est que le web, c'est simple . Même à l'époque des pages web statiques, les non-initiés sous-estimaient la complexité du développement d'un site compatible avec les navigateurs du marché. Maintenant que quasiment tous les sites sont animés par des applications de gestion de contenu, et que de plus en plus d'applications sont hébergées sur des serveurs web (y compris la bureautique avec des applis comme Google Docs), le contexte est encore plus complexe pour le développement web. Comme tu le dis, les moins compétents sont aussi ceux qui écoutent le moins... et qui se sentent menacés parcequ'en fait il ne comprennent pas le web... Exactamente !

N'exagérons pas. Je ne suis pas un martien non plus : je connais plusieurs personnes qui sont à peu près dans ma configuration en tant qu'indépendants. Je me suis plongé dans les CMS depuis 1998, et vraiment activement depuis 2002. J'ai eu le temps de m'imprégner donc. A partir d'un certain moment, on capitalise aussi car la logique d'un CMS n'est jamais totalement unique. Par exemple, le fait d'avoir bossé 2 ans avec Textpattern m'a aidé à me former à MODx en très peu de temps (par exemple, Textpattern utilise des forms comme micro template pour les plugin de la même manière que MODx utilise des chunks comme micro-templates pour les snippets). Idem pour CMS Made Simple qui a une logique très similaire. Le cas de Drupal est un peu à part, il a sa propre logique et c'est aussi la raison qui le rend plus difficile d'accès (ceci dit, eZpublish ou Typo3 sont assez différent dans leurs approches aussi...). Parfois, c'est une question de manière de penser, ça clique ou ça ne clique pas pour un développeur/designer. Je ne dis pas que la spécialisation est une erreur... simplement que pour la dimension "conseil" en avant projet, cela rend la crédibilité moins évidente. Je ne pense pas qu'un positionnement mono-produit soit inéluctable pour un freelance, même si il est évident qu'on ne peut pas être spécialisé dans un grand nombre de système. La question est plus de savoir quel type d'outil on souhaite proposer. Personnellement je préfère les outils : - flexibles (qui ne contraint pas le designer dans un modèle pré-défini) - modernes (conformité aux standards, bonne séparation du contenu et de la présentation, approche modulaire = core léger et API pour faciliter le développement d'extension) - innovants (qui s'appuient sur les techniques les plus récentes) Cedi dit, comme tu dis l'avantage du positionnement mono-produit c'est qu'on est identifié clairement comme un spécialiste d'un outil et que si cet outil est connu des entreprises, tu es sollicité pour un devis. Mais même sans être mono-produit, on peut bénéficier de contacts (par exemple, je suis pas mal sollicité sur MODx - ce qui est logique vu ma position privilégiée au sein de la core team et mon implication dans le projet - et j'ai décroché du business via des contacts spontannés ). Je n'exclu pas, côté CMS, de basculer sur un positionnement mono-produit à partir de MODx 1.0 puisque les limitations actuelles seront levées (système de permission, multi-linguisme natif, revisionning et workflow). Je n'aurai vraiment que peu de raison d'utiliser un autre système (du moins, en l'état actuel du marché).

Je pencherai quand même pour un compromis entre proposer 20 outils open source et 1 seul. Le problème d'être mono-produit c'est qu'on est pas forcémment objectif par rapport au choix de l'outil et que si on aborde une demande on peut être tenté de ne pas écouter le besoin (c'est naturel, sinon on ne vit pas ). Ceci dit, si le client passe d'abord par un prestataire uniquement pour définir son besoin et obtenir une matrice de correspondance entre besoin/fonctionnalités alors oui tu peux être bien placé. Mais par expérience, c'est rarement le cas pour des petits/moyens projets (et c'est bien dommage ). Personnellement, je passe systématiquement par une phase (qui paraît parfois longue au client parcequ'il ne voit pas les choses avancer "concrètement") de définition des besoins et du choix de l'outil. Parfois il faut bien insister qu'on gagne tu temps par la suite, et surtout on évite (ou on réduit les risques) de se fourvoyer... Sinon pour ce qui est de la spécialisation, en ce qui me concerne, j'ai choisi un positionnement intermédiaire. J'ai quelques outils à mon arc : MODx bien sûr mais aussi Textpattern ou CMS Made Simple. Je compte passer un peu de temps à approfondir SPIP et Drupal pour étendre ma capacité de réponse. Et aussi, développer mes compétences sur Code Igniter pour faire du très spécifique. Enfin côté applications web plus pointues j'en choisi une par "type" : ActiveCollab pour la gestion de projet, UNB pour les forums, Vtiger pour la CRM, DotClear pour le blog... Sinon, pour ce qui est du positionnement, j'ai décidé de ne faire que du sur mesure : je n'utilise jamais de template "tout fait" ni de contrat "tout fait". J'ai déjà refusé des clients qui souhaitaient ce genre de prestations. Le "vite fait bien fait" pour pas cher, ce n'est pas mon marché... Je pense qu'il est tout à fait possible que maîtriser plusieurs applications. Mais cela prend du temps. Je sais que je passe facilement un tiers de mon temps lorsque je suis en mission et deux tiers hors contrat à me former . Il faut dire aussi que pour moi, c'est une passion et que ma semaine ne fait pas 40 heures J'imagine que c'est la même chose pour pas mal d'indépendants...

Exact, et il est excellent ! Tellement que maintenant on a aussi forummatrix

MediaWiki a encore bien progressé depuis la 1.5.x, et rappelons que c'est le wiki qui fait tourner WikiPedia donc oui c'est vraiment le wiki de choix pour les projets d'une certaine envergure Merci du témoignage !

A mon avis, c'est une étape clé de ton projet. Pour la méthodo, je suis sûrement influencé par mes 5 années en tant que consultant en organisation / processus, ceci dit Je pense qu'il faut distinguer plusieurs choses. C'est vrai qu'on va souvent se focaliser sur les prix : - le coût des prestations elles-même (là, ça dépend plus de la nature de la prestation que de la licence du logiciel) - le coût des licences (zéro pour l'open source, payante selon des modalités plus ou moins restrictives -> nb d'utilisateurs, fréquence de renouvellement...etc) - le coût du support (c'est souvent là qu'on va te dire que l'open source n'est pas forcémment économique parcequ'il faut passer par un prestataire au lieu de s'adresser à l'éditeur du logiciel, supposémment moins cher. Mais franchement, ça reste à voir...) Ce qu'on oublie parfois de souligner, c'est que choisir une application "propriétaire" demande de faire attention : - au format des données : s'agit-il d'un format "ouvert" dont les spécifications sont publiques ? Si ce n'est pas le cas (comme pour Office) tu te retrouve captif de ton fournisseur parceque tu n'est pas vraiment totalement propriétaire de tes données (!). - à la pérennité du fournisseur : dans le monde du propriétaire, on a pas accès au code source de l'application, si l'éditeur fait faillite on se retrouve dans une situation assez désagréable car on ne maîtrise plus son application... Avec d'autres applications, comme MODx, l'imbrication n'a aucune limite de niveaux (quoique, d'un point de vue de l'utlisabilité, faire ce genre de choix est discutable...) Pour en revenir à waaps, il faudrait que je regarde...

Pardon oui ça n'était pas clair : ton interprétation est bonne... J'aurai du être plus précis en effet. Je pense qu'étant donné ta problématique et le fait que tu ne sais pas encore si tu vas confier la réalisation à un prestataire, tu pourrai envisager de faire appel à un professionnel pour définir ton besoin. En général, une petite réunion de 1h30 bien menée avec une méthodologie en entonnoir (on élimine pas à pas les éléments clés à vérifier pour arriver à cerner le besoin progressivement) permet d'aboutir à un choix d'outil (ou liste de 2/3 d'outils) cohérent. Une fois que tu as choisi l'outil, tu peux choisir ton prestataire plus facilement, en examinant justement quel est la maîtrise qu'il a de la solution qu'il propose. Petite, moyenne, grande taille, c'est un peu arbitraire c'est vrai. J'aurai du parler de complexité plutôt que de taille comme on le fait traditionnellement dans le milieu. Comme tu le dis ça ne reflète pas l'envergure du site. Personnellement, je m'appuie sur plusieurs critères pour évaluer la complexité d'un projet : 1) La couverture fonctionnelle : c'est là que ton cahier des charges rentre en ligne de compte. En plus des grandes fonctionnalités (forum, blog ou autre galeries), il doit détailler les actions type qu'un utilisateur doit pouvoir effectuer. Ensuite, tu attribue une priorité à telle ou telle fonction, puis tu effectues une comparaison avec l'existant. Pour résumer, plus la couverture fonctionnelle est large (plus tu as besoin de fonction), plus le projet est complexe. Comment on évalue la couverture fonctionnelle ? On se pose quelques questions. Prenons l'exemple d'un forum. Tel module de forum existe : répond t-il à toutes les exigences les plus importantes ? oui. Répond t-il aux exigences secondaire ? non. Est-ce que les avantages de la solution sont suffisant pour laisser de côté des fonctionnalités ? oui/non. Souvent, les fonctionnalités secondaires sont surestimées dans la valeur perçue par l'utilisateur final. N'oublions pas que plus une extension ou un système est fonctionnellement riche, moins la proportion de fonctionnalités utilisées sera importante. Autrement dit parfois moins, c'est plus. Attention, je ne dis pas que Vanilla (forum ultra léger) sera toujours meilleur que IPB par exemple. Simplement que lorsqu'on envisage IPB, il faut que cela corresponde à un besoin réel. Il ne suffit pas de dire "Vous avez besoin d'un forum, je vais vous installer le forum le plus puisssant du marché". Comme le dit NiCoS, il faut d'abord, encore et toujours partir des besoins. 2) Le degré de personnalisation : a) Côté design : un site sur mesure demande une réflexion préalable plus approfondie. On ne part pas d'une structure prédéfinie. L'idée est de partir d'une réflexion approfondie sur les besoins des visiteurs/utilisateurs du site pour élaborer une structure de page qui permette de mettre en valeur les informations, des plus importantes aux moins importante (hiéarchie visuelle). Avec les méthodes modernes (CSS), on peut faire énormément de variantes de mise en page. Si on fait les choses bien, on met aussi en place les briques nécessaire à une maintenance et un redesign facilité (par exemple, j'utilise une technique dénommée "server side CSS" qui permet de modulariser les feuilles de styles et rendre certains éléments dynamiques. En gros, faire avec les styles CSS ce qu'on a commencé à faire avec les pages web avec php dans les années 90 -> des pages dynamiques. Donc on utilise maintenant des feuilles de styles dynamiques). Côté fonctionnalités : On a parlé de couverture fonctionnelles (nombre de fonctionnalités) mais là on va parler de fonctionnalités sur mesure. Lorsqu'un besoin n'est satisfait par aucun outil (ou aucun qui corresponde au budget et à l'environnement technique comme le serveur), il faut examiner l'opportunité d'un développement spécifique. Là plus qu'ailleurs il faut clairement établir que cela correspond à un besoin réel, car un développement spécifique, ça coûte. Evidemment, plus un projet demande de développement spécifique, plus il est complexe (et aussi, plus le délai de livraison est soumis à des aléas). D'autres critères rentrent en ligne de compte, mais ce sont les deux principaux. Oui pardon, DTD c'est "Document Type Definition", autrement dit cela permet au navigateur qui parcoure une page web de savoir quel "grammaire" le document web utilise. Cet article d'OpenWeb te donnera plus de billes. Pour ce qui est des extensions, effectivement lors des montées en version il peut être nécessaire de modifier celles-ci. Dans la plupart des cas, ça n'est nécessaire que lorsque l'API du CMS est modifiée, ce qui ne se produit pas à chaque version. Aussi, tout dépend du degré d'activité de la communauté de développeur autour du CMS. Une extension "majeure" reste rarement longtemps sans être mise à jour, parceque la communauté en fait largement l'usage. J'ai aussi vu que tu parlai d'un système d'alerte. C'est un point important, tous les CMS n'en disposent pas... Enfin, concernant A****PHP (je m'auto-censure, et pas de lien), je dirai que leur site est très ambigu et ce genre de déclaration ne m'inspire guère confiance : Vrai, tous les projets open source ne sont pas en GNU GPL : il y a aussi les licences BSD, MIT, Apache... etc. Mais ils ont une licence ! Là, on ne sait pas, c'est le flou total. Ca me semble être purement et simplement une application commerciale. "Les développeurs qui l'ont inspectées vous le confirmeront." Habituellement, il existe un forum de développeur accessible à tous qui permet justement de le savoir... d'autre part, le code est ouvert donc on peut regarder soi-même... là : rien. "Mais elle appartient à ses concepteurs qui en assurent, avec leurs clients, les évolutions et la sécurisation" Autrement dit c'est une application commerciale (dont on a aucun prix, d'ailleurs, sur le site... détrompez moi si j'ai raté quelque chose...). D'autre part, tu n'as pas de démo, et tu ne peux pas le télécharger (une première pour un soft open source ). D'ailleurs, à propos de démos, je te suggère de faire un tour sur opensourcecms.com ou tu pourras tester les sytèmes qui t'intéressent.

La question n'est pas le nombre de module existant (d'ailleurs j'ai insisté sur leur nombre), ni même sur l'API. Relis ce que j'ai écrit : j'ai dit que Joomla était un très bon CMS lorsque l'on souhaite faire du "standard" mais moins efficace lorsque l'on souhaite customiser que ce soit le look ou la structure de données. Maintenant, c'est faisable et il y a des gens qui font des choses très bien avec Joomla, simplement c'est plus compliqué (donc plus long, donc plus cher). Pour résumer, Joomla n'est pas (à mon avis) le meilleur choix pour faire du sur mesure... Je pense que je me suis mal expliqué. Je ne dis pas qu'il n'y a pas des web agencies qui travaillent proprement (l'exemple de groupe-reflect est pour moi un bon contre-exemple de ce qui se fait de bien dans les agences. Mais pour un exemple de ce type, il y en a facilement 100 qui sont à l'opposé. Ce que je dis c'est que les indépendants sont obligés de se différencier et que souvent, ça les pousse à être plus pointu pour se différencier. On voit plus d'indépendant défendre les standards, l'accessiblité, que d'agences (en tout cas, française ). Maintenant, c'est vrai que pour des projet plus importants, de multiples compétences sont parfois nécessaires. La plupart du temps, les agences sont mieux placées pour ces demandes mais on voit de plus en plus de freelance s'allier sur des missions sous forme de réseaux informels (voire, plus formels comme des GIE). Aussi, en moyenne, l'approche d'une agence est plus celle d'une stratégie de volume que celle de la personnalisation des prestations par rapport au besoin du client. Il est plus rapide et plus rentable pour une agence de vendre un produit "standardisé" (ou dont les éléments sont standardisé) que du sur-mesure. D'où une offre plus souvent basée sur du Typo3 ou du Joomla que sur des frameworks type Django, Code Igniter, et autre RoR pour prendre l'autre extrême. Quant à la sous-traitance, en dehors des questions de prix, elle n'est pas toujours abordée de manière "transparente" (le client n'est pas toujours au courant que son site est réalisé par un sous-traitant). C'est un point à vérifier... Je n'ai pas dit que Joomla était aussi pointu que Drupal sur le multilinguisme, le module i18n de Drupal est un modèle du genre qui a peu d'équivalent en open source...