Nous avons récemment été amenés à choisir des systèmes de gestion de contenu (CMS – Content Management System) pour certains de nos clients, et un système de wiki pour notre usage interne.
Bien sûr, le choix d’un système de blog, de wiki, ou d’un système de gestion de contenu se fait souvent sur son utilisabilité, sur ses fonctionnalités, sur la capacité des développeurs à le faire évoluer, et encore sur un tas de critères souvent difficiles à quantifier. Lorsque l’on réfléchit à court et moyen terme, ces critères suffisent.
Mais lorsque l’on se pose la question de l’utilité de ce type de système à long terme, il n’y a qu’une seule question qui compte vraiment : les formats.
On ne choisit pas un système de gestion de contenu pour 10 ans. C’est faux. C’est un idéal, certes. C’est une vision pour le meilleur et pour le pire, mais à long terme, c’est tout simplement une utopie. Tôt ou tard, tout système de gestion de contenu sera démodé, une refonte sera envisagée, des nouvelles fonctionnalités nous tenteront, et là, il ne restera qu’une seule question vraiment importante : vais-je pouvoir prendre mes contenus et les porter sous un autre système de gestion de contenus, voire sous d’autres médias ?. Car ne l’oublions pas, la convergence a déjà largement commencé.
Dès aujourd’hui, un excellent système de gestion de contenu doit permettre au minimum :
- Le stockage de tous ses contenus dans un format ouvert et standardisé (spécifications publiques),
- Mieux, l’export de tous ses contenus dans un format ouvert et standardisé;
- Idéalement, l’import de contenus extérieurs à la condition qu’ils soient dans un format ouvert et standardisé;
Quelques observations :
- L’utilisation des technologies standards comme HTML, XHTML ou CSS nous permettent de séparer le fond de la forme.
- L’utilisation des CMS nous a permis de séparer la fonction technique de la fonction de rédaction (pour tous les contributeurs)
- Le choix d’un CMS, même « libre » ne doit pas nous obliger à choisir un format propriétaire pour nos contenus.
Chacun a sa vision de la liberté. Par exemple, ma liberté sera de retirer un jour le contenu de tous les billets publiés ici pour les porter dans un autre système.
Alors, au moment de vous marier avec un CMS, un wiki, un blog, envisagez déjà le divorce, on ne sait jamais 😉
10 commentaires sur “Choisir des outils pour le web ?”
Les commentaires sont clos..
Si ce n’est pas indiscret, vous avez choisi quoi comme cms ?
Merci
Je dirais même plus, il doit proposer :
– une gestion de template HTML afin de pouvoir publier dans un format ouvert et standardisé, et donc ne pas changer de CMS :p
– doit organiser la publication des contenus (pour une gestion de vie descendante des documents)
Même question que Steven :
Quel est selon vous le CMS qui se rapproche le plus de cet idéal ? Quels sont les meilleurs prétendants pour un tel mariage. ?
Alors, concernant le CMS, nous avons récemment choisi EZpublish, mais j’ai encore quelques réserves sur ce point précis.
Il permet en effet de récupérer des contenus sous des formats ouverts, mais nous avons quelques problèmes pour récupérer l’intégralité d’un site. J’ai vu récemment un CMS basé sur JAVA (infoglue) qui permet de faire l’export global d’un site au format XML.
EN l’état actuel, je n’ai donc pas encore trouvé le CMS idéal. En ce qui concerne le système de wiki, nous sommes en train de tester Dokuwiki, que j’apprécie particulièrement. Les fichiers sont stockés à part dans un répertoire isolé, et chaque page correspond à un fichier texte, tout à fait lisible et compréhensible à la fois par un humain et par des machines.
Voilà où nous en sommes. Si d’autres lecteurs ont des suggestions à faire en termes de CMS sur ce point, je crois que je ne serai pas le seul à être preneur. A vos commentaires.
Tes questions sont légitimes mais pas nécessaires. A partir du moment où vous utilisez un CMS qui repose sur des logiciels ouverts (MySQL, PHP) et des formats standards (SQL, HTML, …), tout contenu est récupérable pour peu que l’on consente à concevoir (ou à chercher) l’interface de migration. L’idéal serait que les structures (et non les formats) soient standards. SPIP aussi utilise un format d’export en XML mais son format est "spécifique". Après tout, il revient au W3C de définir un format XML (pas de RDF siouplaît).
@Balluche
Si ce sont des questions légitimes, ne sont-elles pas nécessaires 😉
Si je te suis bien, lors de l’adoption d’un CMS, il faudrait donc se dire la chose suivante : "Lorsque je voudrai changer de CMS, je construirai mon interface de migration.". Tout le monde a t-il les moyens de construire sa propre interface? L’utilisateur qui adopte un CMS est-il le mieux placé pour le faire? Je réponds non à ces deux questions.
En fait, puisque les différents CMS sont en concurrence les uns avec les autres, le fait qu’une interface de migration soit proposée par défaut en fait un avantage concurrentiel.
De là à dire que cet avantage est décisif, il y a une marge. Pour ma part, je pense que la pondération de ce critère sera à coup sûr de plus en plus importante.
La norme JSR-168 me semble être ce type de format ouvert que vous attendez d’un CMS. Dès lors, il me semble important de mentionner Magnolia, qui à mes yeux est un excellent produit, bien supérieur à tous ceux que j’ai pu essayer.
http://www.magnolia.info/en/magn...
http://www.magnolia.info/en/abou...
Vous avez dit CMS…?
A voir…. indépendant de tout navigateur et de toute taille d’écrans!…
Un cms qui fonctionne aussi bien sur un mobile, un PDA ou un PC…. 🙂
Avec sortie imprimante correcte!
PS: n’utilise pas de base de donnée! Tout en XML!
je ne pense pas que le stockage des données dans un format ouvert soit nécessaire. Bien souvent chaque logiciel cherche à optimiser son stockage des données, et cette optimisation est liée à des fonctionnalités spécifiques de chaque logiciel. Par contre l’interopérabilité est importante, i.e. l’import / export. A ma connaissance il n’existe pas de format ouvert décrivant le contenu d’un cms. (si vous en connaissez, ca m’intéresse:)) Le fait qu’un fichier d’export soit en xml ne le rend pas ouvert et standardisé pour autant.
Il serait possible d’exporter les pages d’un cms en xhtml, mais après il manque un format ouvert pour la structure de ces pages. Reste aussi le problème des url dans ces pages.
Pour les blogs, il y a toujours le format movabletype, pas vraiment ouvert, et la possibilité d’utiliser atom comme format de stockage.
Pour les wikis, la syntaxe de chaque wiki est probablement ouverte mais non standardisée, ce qui ne facilite pas l’interopérabilité.
On est encore aux balbutiements de l’interopérabilité dans ce domaine…
Magnolia est un des seuls CMS opensource à supporter JSR170.
Pour davantage d’information sur le JSR170 veuillez suivre ce lien : http://www.cmswatch.com/Feature/...
Entre autres caractéristiques il dispose de :
– Interface AJAX
– Backup automatique de meta-data (comme nom l’auteur et la date)
– Multi langage – administration dans 15 langues ; et contenu dans toute langue..
– Recherche dans le repository par contenu ou par mots clef
– Gestion de version
– Workflow, lequel peut être modifié pour être ajusté à des processus complexes de publication.
– Publication différée, toute publication peut automatiquement être programmée à une date postérieure.
– Création de flux RSS
– PodCasting
– Url virtuellement statiques (à toute page on peut lui donner un url de type statique de manière facilement accessible aux moteurs de recherches et d’être indexés) Virtuel Static Web Addresses
– intégration avec des portails par l’intermédiaire de JSR-168
– Connecteur vers CRM
– Authentification avec Single Sign On, JAAS et LDAP (*)
– Connecteur CRX
– Module de déploiement
– clustering et load-balancing
– Cache, Magnolia peut mettre en cache toute page de manière à augmenter la rapidité de l’accès, le cache est mis automatiquement à jour selon que les pages aient été modifiées ou non.
– Logging en utilisant Apache Log4j Magnolia utilise le standard Log4j logging. Its extensive customization options allow you to focus logs on your particular needs.
– Backup possible à travers plusieurs moyens, ou directement par le repository ou à travers d’un mécanisme d’export/import qui peut être planifié. De même il y a un module de packaging qui permet de faire un backup des templates, classes java, etc…
– Gestion de rôles, de manière à assigner à un utilisateur un ou davantage de rôles à travez de groupes bien définis le contenu peut seulement être vu, lu et changé par ces personnes qui ont été assignées.
– Possibilité de créer les templates de manière dynamique avec le sitedesigner, sans devoir savoir rien de html ou de jsp.
Il y a aussi la version enterprise edition, qui n’est pas gratuite mais apporte beaucoup de fonctionalités et en outre le support, beaucoup d’entreprises n’utilisent pas opensource justement parce qu’il n’y a aucun support derrière les produits
Pour plus d’information vous pouvez visiter le site de magnolia ici : http://www.magnolia.info