Pour faire suite au billet sur les failles de sécurité des CMS (systèmes de gestion et publication de contenu sur internet) précédent, il est l’heure de faire le point sur les technologies dites "propriétaires".
Face à un Spip, un Joomla !, un EZPublish ou un Typo 3, il existe des solutions CMS qui ne sont pas Open Source.
Pour certains (les plus "techniques"), cela peut sembler absurde : pourquoi réinventer la roue, pourquoi tenter de commercialiser une solution alors que des milliers de sites en tout utilisent des briques logicielles libres ?
Je pense que le raisonnement et la reflexion tiennent une place importante dans cette question du "pourquoi", même si en cette fin d’année 2007 il semble presque "naturel" de proposer un Spip ou un Typo 3 à un client souhaitant un site administrable lorqu’on est développeur web, webagency ou webdesigner.
Tous ceux qui l’ont fait (proposer un logiciel libre, à base de templates PHP pour la plupart des cas) savent que si le logiciel est bien "libre", la démarche ne l’est pas pour autant. Dans un souci perpetuel d’industrialisation, de recherche de la rentabilité au milieu de ce secteur incroyablement concurrentiel qu’est la création de sites internet, on en vient vite à (ne) vendre (que) ce que l’on a passé du temps à maîtriser.
Et mine de rien, chacune des solutions citées plus haut représente un temps de prise en main qui est loin d’être négligeable. Il faut d’abord appréhender la logique, puis le système de fichiers, d’appels, d’includes ; puis la logique des plug-ins, des modules, etc...
Installer et déployer tout ça sur des machines qui ont de fortes chances d’être différentes (une fois sur le serveur privé d’un client, une autre sur un mutualisé pas cher, une autre peut-être sur sa propre machine ?) représente un temps de configuration, de paramétrage, de tests important, et qui donc n’est pas sûr d’être amorti car pas forcément reproductible.
Ajoutons à cela les issues propres au maintien et au support de ces solutions : quelle perennité pour ces projets et ces développement bénévoles ? Et quand bien même, au delà des éventuelles sissions (branches différentes d’un projet initial, cf. mambo et joomla !), des abandons ou rachats éventuels (zope/plone), il faut pouvoir être assuré des compatibilités ascendantes et descendantes des différentes versions et moutures des projets.
Combien de sites, parce que la mise à jour de leur noyau impliquait un grande risque d’incompatibilité, n’ont jamais été upgradés ?
Combien de fonctions se sont vus dépréciées, abandonnées, ou n’ont jamais dépassées la phase bétâ ?
Combien de temps passé à la recherche d’une information, d’un support mal traduit, de réponses approximatives sur des forums ?
A la reflexion, nous venons d’entraperçevoir le fait que les CMS Open Source ne sont pas forcément la meilleure solution. Dans certains cas, ils peuvent répondre à une demande, mais il convient de bien évaluer l’investissement en amont :
temps passé à comparer les solutions entre elles par rapport aux spécificités requises par un projet ;
fiabilité,
fonctionnalités,
perennité,
évolutivité,
compatibilité,
qualité du support,
temps et coût de formation,
temps et coût de suivi par une activité de veille.
Face à cela, la possibilité d’opter pour une solution payante est-il si absurde ? Le reflexe du choix systématique de solutions CMS Open Source tire bien souvent son origine de deux choses : le prestataire ne sait pas qu’une telle solution existe ; et le buzz entourant le monde du logiciel libre gagne tous les milieux (c’est le cas du client qui exige un Typo 3 pour son site de 10 pages). Ce qui est une très bonne chose en soi. Mais la définition des besoins, même lorsqu’on a affaire à des logiciels libres, ne doit pas pousser le raisonnement vers un simpliste "qui peut le plus, peut le moins".
Au cours du prochain billet nous entamerons la présentation de quelques solutions de CMS propriétaires...