Comme toujours tout le monde parle de l’outil, et non du besoin.
Des CMS il y en a des chiées (pas joli cela) et on trouvera toujours des pélots qui vont sortir « WordPress c’est le meilleur », « Non c’est Drupal », « Non c’est SPIP »…

Avoir une grille comparative avec des caractéristiques techniques ce n’est pas intéressant, sauf pour dégrossir…

Malheureusement il faut voir quel est le besoin de base, n’oublions pas que les CMS sont déployés pour faciliter la tâche du client : des webmestres éditoriaux ou directement des responsables de com, des assistant(e)s…
Les CMS doivent donc être déployés en fonction des besoins des clients, notamment en termes de services proposés, d’évolutivité fonctionnelle, de typologie de site, de niveau d’apprentissage requis, etc.

Vouloir forcer, pour des raisons économiques, l’utilisation d’un CMS (je pense aux « agences joomla!esques ») pour la gestion d’un site dont la typologie va en contradiction avec le fonctionnement de base de Joomla! est un non sens. D’ailleurs à la refonte suivante les clients vont voir ailleurs et ne veulent plus entendre parler de cette solution, même si au final Joomla! serait l’outil idéal pour la future version du site…
EX : Joomla! ne gère pas de manière native un rubriquage traditionnel (rubrique/sous-rubrique/sous-sous rubrique/…) qui est très souvent utilisé dans les sites de collectivités ou corporate. Faut contourner soit par du dev (donc déjà cela veux dire que le cms n’est pas adapté) soit par du bidouillage inbuvable en back-office, et les clients font rapidement des conneries.

Je ne tape pas sur Joomla! je pourrai donner d’autres exemples de ce type avec d’autres CMS. J’ai travaillé dans une agence qui fait que du eZ Publish : faire des blogs avec eZ Publish je ne vois pas l’intérêt pour le blogueur qui achète la presta… Cela rajoute un zéro en plus sur la facture, c’est tout !

L’idéal serait donc de réussir à fédérer du monde autour d’un site qui permettrait de décrire fonctionnellement les CMS, parler des procédures d’édition, des procédures réelles de Workflow, l’intégration et l’installation devenant ainsi le dernier des soucis (la documentation est suffisamment étoffée).