En date du 21/09/2010, nous avons actualisé et complété notre comparaison des CMS et solutions e-commerce sous l’angle de l’analyse de leur code source sur une page dédiée de notre site qui sera régulièrement mise à jour.
Il est évident que tous ces projets n'ont pas la même couverture fonctionnelle, il est donc important d'avoir en tête les capacités et objectifs de ces projets avant de les comparer entre eux. Nous avons pris les versions françaises considérées comme stables et n'avons installé aucune extension complémentaire. Il s’agit véritablement ici d’installations "out of the box" et on comprendra que ces classements peuvent très vite se dégrader à l'installation de modules supplémentaires.
Encore une fois, ce comparatif ne s'attarde que sur le code lui-même. Il s'agit d'un parti pris qui nous permet une comparaison avec une approche particulière traduisant la philosophie technique des plateformes auditées.
Versions des CMS testés et typologie principale :
- Kiubi version actuellement en production : CMS, e-commerce, Blog, ...
- Drupal 6.15 : CMS
- Joomla 1.5.15 : CMS
- Prestashop 1.2.5.0 : e-commerce
- OSCommerce 2.2rc2a : e-commerce
- Magento 1.3.2.4 : e-commerce
- Thelia 1.4.2.1 : e-commerce
- Wordpress 2.9.1 : blog
- Dotclear 2.1.6 : blog
Parce que les chiffres qui vont suivre peuvent sembler très abstraits, nous les accompagnerons d’un commentaire afin de comprendre leurs significations.
Nombre de lignes de code :
Le premier indice de volumétrie est le nombre de lignes de code exécutables du projet, c'est à dire sans les indentations, ni les commentaires, ni les retours à la ligne superflus.
- Magento 288 962
- Joomla 123 099
- Kiubi 83 295
- Wordpress 75 967
- Prestashop 63 841
- Drupal 37 478
- OSC 32 188
- Dotclear 32 015
- Thélia 31 464
Magento atteint un nombre impressionnant de lignes de codes. C’est ce qui se passe quand on inclus le framework ZEND quasi intégralement et qu'on y ajoute le Framework PEAR. Est-il encore possible de maitriser pleinement un code aussi important ? Joomla parait également très volumineux alors qu'aucun module supplémentaire n'a été installé. Pour les autres, le nombre de lignes est, selon nous, en phase avec le type de logiciel (CMS, Blog ou solution e-commerce).
La classe :
En programmation, les classes permettent de packager des fonctionnalités et des interactions. Un faible nombre de classes volumineuses signifie en général que les classes sont complexes et trop rigides, un nombre trop important indique qu’il faudra faire un montage savant de petites classes avant d'être réellement productif. Bien entendu, ces chiffres sont toujours à relativiser par rapport à la couverture fonctionnelle attendue.
- Magento 4 346
- Kiubi 855
- Joomla 759
- Prestashop 411
- Thélia 195
- Wordpress 174
- Dotclear 140
- OSCommerce 73
- Drupal 1
Toujours un beau record pour Magento qui ne se concentre pourtant que sur l'e-commerce (merci Zend et PEAR). Pour les autres, la volumétrie semble normale. On voit bien pour OSCommerce et Drupal que les projets sont si anciens qu'ils datent d'avant le boom de la programmation orientée objet (ce qui n'est pas une tare non plus). Un développement procédural, ou pour simplifier "sans objets", amène à un code souvent plus accessible pour le néophyte, mais ce modèle a montré ses limites en terme d'évolution et de maintenance. De plus, la programmation objet a le vent en poupe, c'est donc sur ce genre de projet que les communautés se forment le plus.
Les fonctions :
Les fonctions sont un moyen pratique de centraliser des fragments de codes pour les réutiliser un peu partout. Les inconvénients sont : la difficulté de maintenir une cohérence dans un grand ensemble de fonctions indépendantes et leur trouver un nom. Voilà le nombre total de fonctions que propose chaque projet :
- Magento 31
- Dotclear 23
- Prestashop 188
- Kiubi 214
- Thélia 258
- OSCommerce 368
- Joomla 454
- Wordpress 1 841
- Drupal 1 951
Un grand nombre de fonctions est synonyme de programmation procédurale, anti-thèse de la programmation orienté objet. Mentions spéciales pour Wordpress et Drupal donc, qui en arrivent inévitablement à des fonctions avec des noms beaucoup trop longs (ex trouvé dans wordpress: "_wp_kses_decode_entities_chr_hexdec(" ).
Nombre de lignes de commentaires par ligne de code exécutable :
- Magento 1,11
- Joomla 0,67
- Drupal 0,64
- Wordpress 0,58
- Kiubi 0,57
- Thelia 0,57
- Dotclear 0,42
- Prestashop 0,39
- OSCommerce 0,32
La quantité de commentaires exprime une volonté de clarté du code source et sert à l'auto-documentation de l'application. Magento dépasse le chiffre impressionnant d'une ligne de commentaire pour chaque ligne de code.
Le seul véritable intru ici est OSCommerce avec un taux étonnamment bas, ce qui reflète une facilité de compréhension du code en retrait de celle des autres plateformes. Les projets open source massivement communautaires, qui sont diffusés par définition à un grand nombre de développeurs, sont habituellement bien commentés. En effet, le code doit être compréhensible pour que des développeurs tiers y ajoutent leurs fonctionnalités et dans le même temps, chaque contribution doit être commentée pour que le noyau dur en charge du projet décide de l'intégrer au code source.
Nos conclusions :
Les projets historiques accusent le coup, tous les indicateurs précédents semblent condamner OSCommerce et Drupal. Leur conception date des années 2000 et cela ressort clairement dans les chiffres précédent. Le successeur d'OSCommerce est clairement Magento. C'est en revanche beaucoup plus flou pour Drupal. Joomla s'accroche toujours mais Wordpress est de plus en plus utilisé en tant que CMS.En gardant à l'esprit la couverture fonctionnelle de chaque logiciel, on constate sans surprise que Magento et Joomla sont de véritables "usines à gaz". 280 000 lignes de codes et plus de 4 000 classes à connaitre pour l'un et 120 000 lignes et 750 classes pour l'autre. Leur maitrise est clairement réservée à une élite de spécialistes. Prestashop, selon les critères examinés, a des résultats moyens sur quasiment tous les critères, il ne présente ni qualités ni défauts particuliers sous cet angle.
Pour finir, Dotclear et Thélia s'en sortent bien. Ce sont des projets plus modestes, mais dont le code source se concentre sur leur coeur de métier sans se disperser. La vivacité de Drupal et Wordpress s'explique en partie par la facilité de modification du code. Le développeur néophyte peut personnaliser son site avec quelques notions de bases. Kiubi et Magento sont des projets plus ambitieux pour lesquels l'accent est mis sur l'évolutivité et la maintenance du code.
Kiubi montre selon les critères techniques évalués une base technique conforme aux pratiques modernes de génie logiciel, pensée de façon modulaire et évolutive. Très concrètement cela nous a permis de basculer tous les sites de nos utilisateurs vers du PHP5 il y a plusieurs mois de cela, sans intervention de leur part. Les gains de performance ont été immédiats pour tous les Kiubistes.
Quelques perspectives...
Une évolution majeure telle que le passage de PHP4 à PHP5 n'est pas anedoctique et plusieurs des logiciels opensource étudiés ici vont confronter prochainement leurs utilisateurs à ce changement pouvant nécessiter des interventions très lourdes sur les sites, voire une refonte complète ou un changement d'hébergeur.Côté prestataire web, la bonne gestion des évolutions majeures des logiciels que l'on utilise pour développer les sites de ses clients est une question encore plus délicate. D'un côté, si en 2000 les clients acceptaient d'attendre 5 ans avant de faire évoluer la base technique de leur site, aujourd'hui la plupart des porteurs de projet a compris qu'attendre plus de 6 mois pour mettre son site à niveau est un handicap dans un environnement très concurrentiel. De l'autre côté faire évoluer individuellement plusieurs centaines de sites et leurs développements annexes vers la dernière version d'un logiciel s'avère quasiment impossible à réaliser rapidement pour un prestataire.
C'est dans ce contexte que l'on constate un engouement croissant pour le modèle SaaS, y compris pour des projets opensource qui vont devoir prendre leurs marques dans ce domaine.
Commentaires
Super comparatif, vraiment instructif. Il traduit véritablement la sensation globale qu'on peut avoir en testant les différents outils, sauf peut-être pour Drupal. Il doit évoluer si il veut rester compétitif.
Dommage de ne pas trouver TYPO3 dans ce comparatif...
Bien, mais Kiubi aurait toute sa place dans ce comparatif si son code source était public... la plupart des applications citées doivent respecter nombre de contraintes non imposées à un SaaS:
-Prise en charge d'une vaste variété de configurations serveur.
-Niveau de sécurisation élevé (le code étant public, les failles potentielles sont très exposées).
-Code internationnal : un développeur ousbek doit pouvoir s'y coller facilement.
-Compatibilité ascendante: une mise à jour de Joomla ne doit pas altérer les contenus en place.
Bonjour,
J'ai un article similaire (F Zisermann si je me souviens bien) qui comparait la qualité d'un projet à partir du nombre de tables dans la base de données.
J'ai l'impression de retrouver la même chose ici, et même si ces informations sont pertinentes, c'est vraiment à prendre avec des pincettes :
1) Il n'y a pas de mauvais outils, seulement des outils inadaptés à un besoin
2) La théorie de "la mienne est plus longue que la tienne, donc plus efficace" transposée au code est un peu limite ...
Bref osCommerce (le plus mauvais de classement) peut-être la meilleure réponse à un projet et Magento la plus mauvaise, ou inversement.
Attention aux raccourcis rapides ;)
Sympa ce comparatif... Mais il n'y a pas SPIP alors que Thélia s'en inspire beaucoup. Il aurait été bien de voir selon vos critères comment s'en sort SPIP...
Amicalement.
Très intéressant, juste sur le nombre de lignes de codes / nombre de ligne de commentaire, je pense que si c'est bien ce ratio là qui est utilisé, cela signifie que Magento au contraire de votre commentaire est peu documenté. J'ai l'impression qu'il y a une légère confusion sur ce point.
Je rejoins M-commerce Pro sur Thelia/SPIP : le 2e a quand une communauté énorme, alors que l'audience de Thelia est relativement confidentielle ...
@Luc et @Teddy : nous nous sommes volontairement limités à l’étude des logiciels avec lesquels nos clients et partenaires prestataires sont amené à comparer Kiubi le plus souvent. Typo3 et EzPublish (pour répondre à http://twitter.com/Sleipne/status/20723972302 ) sont rarement dans la liste car en général destinés à des projets volumineux et complexes et moins connus du grand public.
Pour répondre à http://twitter.com/HerveThouzard/status/20720205719 d’une part il nous a semblé justement intéressant de comparer selon un même prisme des projets aux périmètres fonctionnels différents pour observer leurs niveaux de complexité respectifs et voir s’il y avait des décalages entre la couverture fonctionnelle et la complexité du code de certains projets (c’est effectivement le cas). D’autre part nous nous mettons à la place du porteur de projet qui a tendance à chercher une solution complète à sa problématique de communication online, et cela passe la plupart du temps par un mix cms-blog, blog-ecommerce ou cms-blog-ecommerce. Vous pouvez à partir de nos chiffres facilement évaluer la complexité pour maîtriser le code d’un projet complet du type Magento+Joomla+Wordpress contre un Thélia+Dotclear.
@nicolas : les contraintes de logiciels en mode SaaS sont également très nombreuses bien qu’effectivement différentes sur plusieurs points. Sur l’aspect sécurisation bien qu’en effet le code ne soit pas analysable par le public, la barre est nécessairement placée plus haut en mode SaaS, car sa nature mutualisée fait que chaque problème concerne forcément 100% des clients. Il en va de même concernant la compatibilité ascendante car c’est le cœur même de la « promesse » faite par toute plateforme : faire évoluer tous les sites de ses clients sans qu’ils interviennent. Un SaaS qui évoluerait aussi peu qu’OsCommerce serait mort très rapidement, à moins de lever plusieurs millions et de les investir en relations presse…
Sur l’aspect « configuration serveur » il s’agit plutôt pour une application SaaS d’être capable de s’adapter à des architectures matérielles complexes différentes afin d’optimiser les ratio volumétrie/performances/coûts il faut donc également une polyvalence importante. Concernant le programmeur Ouzbèque, il lui faudra certes un logiciel multilingue, mais en dehors de cela point de différences notables.
@M-commerce : comme nous le disions en introduction cet article nous proposons un angle de lecture particulier et partiel. Pour autant nous estimons qu’il reflète une certaine philosophie technique sous-jacente à chaque projet et le décalage ou non avec des pratiques de génie logiciel bien établies. Nous vous rejoignons complètement sur le fait qu’il n’y a pas de « meilleur » logiciel et que c’est le besoin qui est le critère principal de décision. En revanche dire qu’il n’y a pas de mauvais logiciel est erroné, il existe des tonnes de mauvais logiciels, y compris dans le domaine dans lequel ils étaient censés apporter une solution, le fait que ces mauvais logiciels correspondent à l’idéal de quelques-uns n’y change rien.
Cependant, ce que mettent en avant les chiffres que nous donnons n’est en aucun cas le fait que certains logiciels étudiés ici soient « bons » ou « mauvais », mais plutôt qu’ils soient en décalage ou non avec des pratiques actuelles, avec des besoins fonctionnels classiques et avec des niveaux de compétences standards.
Cela souligne en revanche le fait qu’aucun logiciel n’est éternel et que l’Open-Source n’échappe pas à cette règle, la pérennité absolue est un leurre, sinon OsCommerce aurait évolué de façon continue en un équivalent de Magento. Dans le domaine de l’alimentaire il existe des « DLUO » : dates limites d’utilisation optimales, il en va de même dans l’industrie du logiciel, à la différence près que ce n’est jamais indiqué... Peut-être que les indicateurs que nous avons utilisés, parmi d’autres, peuvent permettre d’en mesurer la proximité, cela aurait le mérite de permettre de faire des choix de logiciels en meilleure connaissance de cause.
@Disparitus Il s'agit d'une erreur dans le titre du graph. Elle est corrigée merci :-) .
Un comparatif entre Magento et joomla, c'est déjà particulier, mais comparer sur le nombre de ligne, l'est encore plus.
Joomal, sans plug, est prévu pour faire du contenu, pas du e-commerce, et n'a donc rien à faire dans ce comapratif, ce qui aurait été intéréssant, c'est une analyse du code restitué, perfs, ref, etc.
Dans ce cas, ça n'a pas de valeur à mon avis.
Merci pour cette analyse et cette approche originale !
je n'imaginais pas qu'on puisse se se servir de Dotclear de cette façon.
@Samy, Et si (en SaaS) chaque problème concerne forcément 100% des clients, il n'en va pas de même pour "chaque solution"...
Rien sur Spip... dommage, car ça aurait rendu le comparatif plus fort.
Je suis de l'avis de plusieurs intervenants, vous comparez des choses pas comparables et faites des raccourcis pour mettre votre produit dans la liste, c'est un peu limite, même si dans l'absolu vous êtes sur votre blog, vous faites ce que vous voulez. Mais plutôt que de présenter ca comme une "étude", rajoutez la mention "ceci est une publicité".
Une autre question me taraude: Kiubi c'est combien de développeurs ? 1 ou 2 ? En tout cas difficilement comparable avec des équipes de développeurs sur des projets d'envergure.
Bref, même le titre de votre billet sens le SEO a des kilomètres ;-)
Je trouve l'approche effectivement, vu par le petit bout de la lunnette.
De plus vous comparez ici, des projet 100% Open Source, et d'autre purement commercial. Hors, l'orientation initial du projet, en change les contraintes, et les objectif.
effectivement oscom à ces faiblesse, toutefois le comparez à magento qui a une approche GNU litigieuse, de la même manirère que presta. Favorise les raccourcis, et le nivellement vers le bas.
De plus, oscom ayant encore la majorité des palteforme de ecommerce en ligne, et étant le papa sinon, la muse des autre projet ne le place pas tout a fait sur la même marche que ces concurent...
Enfin, si tous les professionnel vendant de l'open source, contribuez ou financer , oscom n'en serai certainement pas la.
Tous ca pour dire que effectivement , je rejoins aline, commencer par , ceci est une publicité
Très intéressant comme article, d'ailleurs j'aimerais avoir la même analyse mais cette fois-ci avec Drupal 7, qui d'après ce que j'ai vu, semble avoir pris une direction vers l'objet, de ce fait, je pense qu'il deviendra peut-être le bon CMS à avoir sous la main.
@Francois @oscim @requiemforageek : ce comparatif compare un aspect particulier commun à tout projet logiciel, il est donc tout à fait légitime. Le fait que cette analyse soit partielle est clairement exposé en début d’article et complété dans notre commentaire précédent. Cela ne la rend pas pour autant partiale.
L’outil utilisé, PHPLoc n’a pas vocation à distribuer des « bons points » sur le respect d’une licence, d’un modèle économique ou du nombre de développeurs de l’équipe, ce n’est donc pas le sujet de l’article.
@oscim @requiemforageek : il serait bon de ne pas confondre communication et publicité. Ce n’est pas parce que l’approche de notre article ne vous convient pas que cela doit justifier la projection de vos fantasmes à notre égard. Je vous invite à utiliser votre énergie à élaborer vos propres comparatifs et à nous en faire profiter de façon constructive.
Ce comparatif ne contient pas SPIP; c'est un grave manquement qui enlève beaucoup dans sa qualité.
Bonjour,
C'est l'un des articles les plus interéssant que j'ai pu lire depuis maintenant 5 ans que je snife le Web :) Enfin du concret comparable ! Merci à Kuibi pour cet éffort d'analyse qu'il fallait bien faire un jour. Pour ma part, je trouve très compliqué, voir impossible de blamer tel ou tel application, dans la mesure ou le choix ce fait essentiellement, dans l'approche pédagogique et dictatique du CMS/F/E lors de son apprentissage. De plus c'est un choix personnel, qui se définie pour une forme de sensibilité du CMS proche ou pas de la personnalité de la personne qui choisi son outil. Disons que d'un point de vue purement technique cet article va correspondre et satisfaire un Webmaster sur le choix de son outil futur. Mais d'un point de vue grand public (Utilisateur), le choix se fera sur l'image et l'utilisabilité du CMS.
Pour conclure un CMS sera apprécié par le plus grand nombre si l'équation de son développement rime avec Communautée, Objectif en commun, Utilisabilité, Documentation, Modularité.
Cependant, mes dires ne sont certainement pas objectifs, car tout dépend à qui s'adresse un CMS ... Au Grand Public ou aux Techniciens ?
Squirrel :)
Intéressant, sauf que vous ignorez superbement SPIP volontairement ou non, dommage
Comparatif intéressant, mais qui me laisse sur ma faim : il manque un CMS cher à mon cœur : SPIP.
Autre élément de comparaison : la puissance serveur nécessaire. http://www.spip-blog.net/CMS-et-sites-a-fort-trafic-parlons-chiffres.html indique : 1 pour SPIP, 4 pour Drupal, 10 pour Wordpress.
Enfin, pour SPIP, une partie des commentaire du code sont une URL qui renvoie à http://doc.spip.org/
Le comparatif est de qualité, mais il manque SPIP pour en faire un vraiment super...
Donc grosso modo si je résume, tant qu'on vous dit super génial votre article les mecs vous êtes les meilleurs ya pas de problèmes, par contre dès qu'on vous donne notre sentiment sur la tournure alambiquée de votre démarche, là c'est : "t'es gentil, vas jouer ailleurs..." Je vais certainement me faire traiter de Troll (d'idées ;) mais je ne semble pas être le seul, ici ou sur Twitter a partager ce sentiment. La moindre des choses, messieurs, c'est que quand on se lance dans ce genre d'exercice on en accepte les risques, à savoir, ne pas mettre tout le monde d'accord, et pas se jeter à la gorge du premier critique: surtout des trucs du genre..."cela doit justifier la projection de vos fantasmes à notre égard".
Je ne pense pas avoir été méprisant dans mes propos, donc restez polis, vous avez un beau produit, qui a sa place sur le marché, mais revoyez un peu votre com, parce que les gens sur la défensive, la plupart du temps, le sont parce qu'ils n'ont pas la conscience tranquille...
Donc, bonne continuation a vous, apprenez un peu l'humilité et bloquez les commentaires quand vous êtes pas sûr de faire l'unanimité dans vos propos, surtout si vous n'êtes pas prêt pour la critique.
Se baser sur le nombre de lignes de code pour tirer de telles conclusions.. je n'ai jamais vu d'analyse aussi insignifiante.
@requiemforageek : Nous n’avions pas pour ambition de faire l’unanimité en publiant le résultat de notre analyse, mais simplement de partager des observations qui, nous le pensons, peuvent intéresser. Encore une fois, il ne s’agit pas d’une publicité déguisée, mais d’un véritable comparatif, réalisé sous un angle inhabituel.
Notre conclusion concerne un point de vue qui peut être partagé ou pas et c’est la raison pour laquelle nous ne fermons pas les commentaires, cela nous a permis de constater par exemple qu’une bonne partie des lecteurs de ce blog souhaite y voir figurer SPIP.
Nous n’avons pas de soucis avec les critiques ou l’expression de sentiments particuliers. Lorsqu’elles sont fondées, justifiées, argumentées, ces discussions peuvent être constructives et, au final, positives pour les protagonistes.
Suite à la demande de nombreux lecteurs, nous publierons prochainement une mise à jour de ce comparatif, avec les nouvelles versions et les CMS dont l’absence a été commentée.
@Squirrel : Nous sommes tout à fait d’accord avec vous. Au final c’est l’adéquation entre les besoins et les fonctionnalités d’un CMS qui fait la différence. C’est pourquoi, il n’existe pas de CMS universel ou un « meilleur CMS ».
Votre question sur le public final d’un CMS est très intéressante et il y aurait beaucoup à dire.
Selon nous, un CMS a quasiment toujours deux publics : d’un côté ceux qui l’utilisent, qui devraient normalement constituer le public « cible » et de l’autre, ceux qui développent dessus. Les deux sont clairement interdépendants et trouver un équilibre n’est pas chose aisée car un logiciel apprécié des développeurs ne l’est pas forcément des utilisateurs et inversement. Par ailleurs la communauté des développeurs fait souvent partie des « early-adopters » et contribue ainsi à diffuser un premier ressenti à destination d’un public plus large, le cas du lancement de Magento en fut un très bel exemple.
Ben dis donc, j'ai lu l'article lors de sa sortie il y'a quelques semaines et il n'y avait évidement pas autant de commentaire. Leurs lecture m'inspire plusieurs choses :
1 - Effectivement, comparer Kiubi et des produits open source est un peu biaisé, mais pourquoi pas. Je pense que l'analyse reste interessante meme si on enlève Kiubi. Je dirais meme que c'est ce qui la rend interessante. Apres, evidement que Kiubi à le droit d'y figurer, c'est eux qui ont fait le boulot d'analyse.
2 - La série de "il manque" mon produit préféré ( spip, etc... ) n'est pas de la pub ? Bien entendu qu'aucun comparatif ne peut être objectif. Pour ma part, il manquerait Diem mais bon, si ca m'interesse j'ai qu'a faire l'analyse moi même.
3 - L'approche "Code" me plait bien et est clairement atypique et à contrairement à ce que disent de nombreux commentaire de l'intérêt. Il est évident que personne ne va choisir un CMS en se basant uniquement sur ce critère mais il est souvent occulté à tord à mon avis. Si on analysais un peu plus ce critère, y'aurait beaucoup moins de site sous cette bouse de Joomla
4 - S'attaquer même si c'est pour comparer à la communauté opensource est dangereux. C'est plein de dangereux intégriste totalement fermé à la discutions et contre tout ce qui n'est pas leurs joujous préféré.
Bonjour,
Merci pour le travail effectué. Au moins, cela conforte, *sous un certain angle*, les avis qui circulent ("Magento c'est du lourd", "Avec Joomla! la taille de la DB est vite importante même pour un site de 3 rubriques", "OS Commerce est mort"...)
Le grand dam de ce genre d'étude, très chronophage et qui demande une grande rigueur, c'est qu'il devient rapidement obsolète, les développeurs des communautés sortant des nouvelles versions régulièrement et rapidement. Ce qui est valide à la publication de votre billet de blog début Août, et qui va être archivé et linké un peu partout, ne le sera plus d'ici quelques semaines. ..
Bonjour,cette article est excellent.Merci pour le partage.
@CMS Metrics Merci. Nous avons désormais le "protocole" et une mise à jour ne nous prendra plus autant de temps que cette première analyse. Une mise à jour régulière est prévue et nous pensons par exemple mettre à jour ce comparatif pour la mi-Septembre.
Tout de même seuls Drupal et Joomla sont des CMS.
Même si il y plus de 5 ans ils servaient à construire des blogs, leurs couvertures fonctionnelles, comme vous dites, et leurs codes n'ont rien à voir avec les autres produits listés.
Analyse très intéressante, ceux qui ont compris de quoi il retourne vont pouvoir en tirer les conclusions nécessaires.
Merci pour le travail accompli.
Pierre
P.S.: si je peux me permettre Dotclear est passé récemment en version 2.2 ;)
Bonjour,
Je connaissais pas ce logiciel pour sortir ce genre de stats, sous linux grâce au commande de base tree, ls et wc j'ai sorti des stats pour spip et joomla, mais c'est moins précis que l'outil utilisé pour les votres mais au moins il y a spip...
http://codes-libres.org/blog/?Comparaisons-des-CMS-SPIP-Joomla
Bonne journée.
Je n'est pas utilisé que les commandes Linux, je me suis servi de l'onglet statistics du logiciel phpxref:
http://phpxref.sourceforge.net/
Ce comparatif, quoique non exhaustif, est très intéressant et a le mérite d'exister. Pour ma part, je ne suis pas du tout choqué de ne pas voir Spip qui a mes yeux est un outil en fin de vie.