Planète

Mais c’est quoi un CMS ?

Un CMS, ou SGC en français, est un logiciel ou une plateforme permettant de créer et modifier facilement le contenu qui alimente un site internet. Le contenu peut être généré par une personne seule ou une équipe de webmasters mais il est également possible de laisser les visiteurs publier leur propre contenu. On parle dans ce cas de contenu généré par les utilisateurs (UGC).

Le CMS est protéiforme, il peut gérer votre site institutionnel, votre boutique en ligne, votre blog, votre médiathèque, votre site d’offres d’emploi.... Bien configuré, il peut propulser des sites allant d’une dizaine de visiteurs jusqu’à plusieurs dizaines de milliers par jour.
Un système de gestion de contenu est dans sa zone de confort pour la saisie, la validation, la classification, la gestion de médias, la configuration du référencement (SEO), l’attribution de rôles/droits à des utilisateurs(rices), l’agrégation, la navigation au sein de ces contenus...

Les CMS ne sont bien sûr pas la seule solution pour créer un site, mais ils sont accessibles et possèdent une base de fonctionnalités déjà existantes et suffisamment complètes. En optant pour un CMS, vous avez déjà un panel de fonctionnalités à votre disposition.

Le CMS peut être open source (Drupal, Wordpress, Prestashop…) ou propriétaire (Sitecore, Kentico, Adobe site manager...). Selon votre choix, des coûts de licence peuvent s’appliquer et votre niveau d’autonomie pour modifier / voir sous le capot varie très fortement.
À l’heure où les supports et canaux se multiplient pour se spécialiser (applications mobiles, réseaux sociaux, site institutionnel, site RH, site du support utilisateurs…), une constante est toujours présente : le besoin de rédiger votre contenu ! Vous avez donc toujours un intérêt à avoir un système de gestion de contenu au sein de votre structure.

Le marché tend à se rapprocher du modèle suivant : vous créez un site dédié à l’administration de votre contenu pour centraliser votre contenu et vos sites / applications se connectent à ce système de gestion de contenu pour présenter les bons contenus au(x) bon(s) endroit(s). Grâce à cette mutualisation vous simplifiez la mise à jour de l’information en évitant la répétition.

Faites votre choix

Chaque structure a ses propres besoins et le modèle décrit ci-dessus ne s’applique pas forcément à votre organisation. Rassurez-vous, il existe des solutions pour chaque taille de structure / projet. Passons en revue vos options de la moins onéreuse à la plus onéreuse.

Nous ne vous détaillerons pas ici, ni ailleurs, les avantages et inconvénients de chacun des logiciels car il en existe plusieurs dizaines dans chaque langage (PHP, Python, Ruby…). De plus, nous estimons que seule l’expérience d’utilisation et la mise en œuvre de ces outils permettrait de donner un avis objectif et légitime. Ce n’est pas notre cas, nous sommes experts Drupal.

À noter que nous mentionnons le terme de réversibilité dans les 3 options, ce terme désigne la capacité à repartir avec le code de votre site et vos contenus pour pouvoir les mettre chez un autre prestataire / hébergeur et les modifier.
 

Option 1 : Un site générique, hébergé sur une plateforme SaaS

Ce peut être l’offre de votre hébergeur type Ionos (1&1) ou un service dédié type Wix, Hubside. Il existe aussi des services spécialisés si vous voulez monter une boutique par exemple : Squarespace ou Shopify sont les services les plus connus.

Pour quelques euros par mois vous pouvez choisir parmi une collection de gabarits et ambiances visuelles celui qui vous plaît pour ensuite modifier le contenu des pages.
Les possibilités de personnalisation sont très limitées mais pour un site simple (type plaquette), cette option fait le travail. Vous n’avez pas à vous préoccuper de la maintenance, de l’hébergement, des sauvegardes. Tout est compris dans l’offre.

La contrepartie est que vous ne pourrez pas transformer le site pour en faire ce que vous voulez si le site doit évoluer au bout de quelques mois ou années. Vous ne pourrez pas non plus repartir avec le code source du site (réversibilité) pour l’héberger ailleurs ou le faire modifier par un(e) développeur(se). C’est la plateforme sur laquelle vous créez votre site qui est propriétaire de vos données.

Le coût de ces services est très accessible :

• Coût de la conception et du développement : Gratuit si vous le faites vous même. Quelques centaines d’euros si vous passez par un prestataire.
• Adaptabilité aux besoins métiers : Inexistante
• Coût récurrent tout au long de la vie du site : 
  • Licence : Entre 1 et 50 € par mois pour le service
  • Hébergement : Compris
  • Maintenance : Compris
• Personnalisation à votre image de marque : Inexistante à Faible
• Connaissances techniques requises : Aucune
• Réversibilité : Impossible

Option 2 : Un site sur mesure à partir d’un CMS

Si vous souhaitez un site qui reflète fidèlement votre identité visuelle et pour lequel l’expérience de navigation est taillée sur mesure pour vos contenus, alors le site hébergé sur une plateforme tierce ne conviendra pas. Vous aurez besoin de gérer votre site en autonomie.

Selon que vous possédiez les compétences au sein de votre structure ou via un prestataire type agence web (tel qu’Happyculture ;-)), les étapes de conception de l’interface (Design / Responsive), l’organisation de la circulation au sein des pages (ergonomie et organisation de l’information) et le développement seront des passages obligés pour rendre du mieux possible un service à vos visiteurs.

Pour construire ce site sur mesure, plutôt que de partir d’une feuille blanche, le CMS est l’outil nécessaire à votre projet pour les raisons mentionnées précédemment.
Avec un CMS vous partez d’un socle de fonctionnalités extensible. L’équipe technique se charge de configurer et enrichir ce socle en piochant dans la bibliothèque de modules complémentaires gratuits ou payants. Si vos besoins sont pointus et non couverts par un module complémentaire, les développeurs peuvent créer des fonctionnalités sur mesure. Dans certains cas, il pourra être nécessaire de déconstruire certaines fonctionnalités pour les redévelopper si le comportement par défaut ne vous convenait pas (ex : recherche de contenu sur mesure).

Drupal dispose de milliers de modules complémentaires centralisés sur le site officiel drupal.org. Cela permet de garantir la couverture par son équipe de sécurité et vous protéger d’éventuelles attaques ou fuites de données (si votre site applique les mises à jour (!)). Les modules sont développés par la communauté, 85% par des personnes payées pour le faire, 15% par des bénévoles.

Pour maîtriser votre image de marque et l’organisation de votre contenu votre site devra donc être hébergé sur vos serveurs ou chez un hébergeur. Selon la taille du site, le coût varie de quelques dizaines à quelques centaines d’euros par mois.

Il faudra ajouter à cela une ligne budgétaire dédiée à la maintenance du site. Qu’elle soit corrective ou évolutive, votre site vit au-delà de sa mise en ligne initiale. Des failles de sécurité peuvent être découvertes et votre site doit être mis à jour pour que vous restiez protégés. Des bugs peuvent également être corrigés par la communauté qui développe ces modules et vous en faire bénéficier gratuitement en appliquant ces mises à jour.

Pour résumer, vous êtes pleinement propriétaires de votre site, vous maîtrisez la mise en forme, l’organisation du contenu. 

Le coût de la conception et du développement représentent l’essentiel de la création du site mais permettent de se distinguer de ses concurrents et de garantir une réponse aux besoins de vos visiteurs.

• Coût de la conception et du développement : Plusieurs milliers à dizaines de milliers d’euros selon la taille du site
• Adaptabilité aux besoins métiers : Moyenne
• Coût récurrent tout au long de la vie du site : 
  • Licence : 0 € pour les CMS open source
  • Hébergement : À partir de 50 € par mois
  • Maintenance : À partir de 100 € par mois pour une version minimale (correctifs de sécurité), plus si on ajoute des correctifs autres + des évolutions
• Personnalisation à votre image de marque : Totale
• Connaissances techniques requises : Une équipe technique interne ou un prestataire est indispensable
• Réversibilité : Possible (peut dépendre du contrat, pensez à vérifier !)

Option 3 : Un site sur mesure à partir d’une page blanche

La troisième et dernière option qui s’offre à vous et votre équipe technique est l’utilisation d’un Framework (Symfony, Express, Django, Ruby on Rails…). Un framework est une boîte à outils qui permet à l’équipe technique de construire un outil personnalisé de A à Z. Vous tirerez les mêmes bénéfices que l’option 2 et irez plus loin dans la personnalisation en imaginant également la partie administration du site sur mesure.

Ce cas peut être intéressant pour des sites qui comportent une partie “métier” forte qui ne peut pas être réalisée via des modules complémentaires et le cœur d’un CMS ou qui nécessiteraient beaucoup de développements sur mesure.

Cette solution d’une certaine façon implique de réinventer la roue pour la saisie et l’administration des contenus car toutes les fonctionnalités de saisie du contenu et d’administration doivent être développées, là où le CMS propose une solution clé en main. C’est autant de budget en plus à y dédier.

Les avantages du Framework comparés au CMS sont faibles, le seul cas qui justifiera le surcoût sera l’intégration de nombreuses fonctionnalités métier.

• Coût de la conception et du développement : Plusieurs milliers à dizaines de milliers d’euros selon la taille du site
• Adaptabilité aux besoins métiers : Totale
• Coût récurrent tout au long de la vie du site :
  • Licence : 0 €
  • Hébergement : À partir de 50 € par mois
  • Maintenance : À partir de 100 € par mois pour une version minimale (correctifs de sécurité), plus si on ajoute des correctifs autres + des évolutions
• Personnalisation à votre image de marque : Totale
• Connaissances techniques requises : Une équipe technique interne ou un prestataire est indispensable
• Réversibilité : Possible (peut dépendre du contrat, pensez à vérifier !)

Conclusion

Voici un tableau récapitulatif des différents critères que nous vous avons présentés ci-dessus.

Avec toutes ces informations, nous espérons que vous y voyez plus clair sur l’intérêt d’un CMS et les situations où il est adapté.

Si vous comptez lancer un projet ou souhaitez des conseils sur l’organisation de votre contenu, n’hésitez pas à nous transmettre vos questions.

Depuis la sortie de Drupal 8, composer est devenu la façon la plus répandue de gérer les dépendances des projets. Ainsi, nous pouvons charger modules contribués et thèmes de façon unifiée ainsi que, si nécessaire, les librairies PHP dont ils dépendent. Cependant, certains modules ont besoin de librairies venant du monde du front et n'étant pas nativement supportées par composer. Ainsi, pour chacun de ces modules, il est nécessaire d'aller télécharger la librairie manuellement et de l'ajouter dans son dépôt de code. Il faut ensuite suivre régulièrement les mises à jour de toutes les librairies de tous les projets et les télécharger de nouveau en cas d'évolution ou de faille de sécurité.

Ça, c'était avant.

Cela fait bien longtemps maintenant que cette problématique a été résolue par les personnes travaillant sur le front des projets via divers package managers comme npm et bower, dont composer est d'ailleurs inspiré. Mais alors, pourquoi est-ce si compliqué de gérer ces librairies dans Drupal ?

npm, bower et composer ne référencent pas les mêmes types de paquets. En effet, les paquets PHP n'ont pas la même organisation et le même usage que les paquets Javascript. Cependant, même s'il est techniquement possible de déclarer un paquet Javascript dans packagist (la base de données alimentant composer), les auteurs de ces paquets ne le font généralement pas pour ne pas avoir à gérer tous les gestionnaires de paquets du monde et parce que cela n'est généralement pas pertinent pour l'usage que l'on peut faire de leur outil. Les personnes maintenant des outils Javascript se concentrent donc sur npm et bower, les deux plus utilisés.

Bienvenue Asset Packagist

La communauté étant pleine de ressources, le projet Asset Packagist a émergé pour répondre à ce besoin. Son but, mettre à disposition les paquets présents sur npm et bower via composer à moindre effort. Ainsi, il est possible de récupérer ces dépendances et de les maintenir à jour de la même façon que le reste de nos modules.

composer étant configuré pour uniquement chercher ses paquets sur son propre packagist, nous allons devoir tout de même procéder à quelques configurations dans notre projet pour pouvoir utiliser Asset Packagist comme source, suivez le guide !

Configurer le repository

Comme lorsque l'on souhaite pouvoir récupérer les modules et thèmes de Drupal, nous devons déclarer un repository spécifique au sein de notre fichier composer.json. Voilà à quoi ressemble la section repositories de mon fichier :

Désormais, vous avez la possibilité de récupérer les dépendances front de vos modules via les commandes composer require npm-asset/PAQUET ou composer require bower-asset/PAQUET en cherchant sur le site d'Asset Packagist le nom correspondant.

Cependant, en l'état nos dépendances seront installées dans le dossier /vendor, comme les dépendances PHP, ce qui ne nous arrange pas puisque les modules les chercheront dans le dossier /libraries pour les rendre accessibles aux visiteurs.

Configurer l'emplacement des librairies

Pour faire en sorte que composer place les fichiers à l'endroit voulu, il nous faut exploiter les possibilités offertes par le paquet composer/installers. Si ce dernier n'est pas déjà installé dans votre projet (ce qui est peu probable si vous gérez vos modules via composer), il vous suffit de taper la commande composer require composer/installers pour ajouter la dépendance.

Ensuite, il faut ajouter quelques informations dans la section extra de votre composer.json.

• L'entrée installer-types permet de déclarer les types de paquets en provenance de Asset Packagist.
• L'entrée installer-paths permet de déterminer l'endroit où chaque type de paquet sera déposé. Dans le code ci-dessous, les déclarations ont été ajoutées à celles de Drupal.

Et voilà, votre projet est prêt à recevoir ces dépendances et à les maintenir à jour suivant le même processus que vos modules et vos thèmes !

Que se passe-t-il ?

Dès 2019, la date de fin de vie de Drupal 7 et Drupal 8 a été annoncée. Ce sera pour le mois de novembre 2021.

La règle dans la communauté Drupal c’est 2 versions majeures maintenues en simultané (Drupal 7 et Drupal 8 à l’époque). L’arrivée de Drupal 9 devait pousser Drupal 7 vers la retraite mais papy fait de la résistance !

En effet, son utilisation importante chez de nombreux utilisateurs finaux, la migration complexe vers Drupal 8 et le COVID ont repoussé son arrêt de carrière de 12 mois, il jouera donc les prolongations jusqu’en novembre 2022. 

De son côté, Drupal 8 est toujours rangé au placard à la date prévue car c’est sa dépendance à Symfony 3 qui arrive en fin de vie et qui lui fera quitter les projecteurs en novembre 2021.

Quels sont les risques ?

Avec le retrait de ces deux versions, votre système de gestion de contenu ne va pas arrêter de fonctionner du jour au lendemain.

Ce que signifie leur fin de vie c’est que les équipes officielles qui s’occupent de maintenir le logiciel ne le feront plus. Il n’y aura donc plus de mises à jour de correctif ou de sécurité. Votre site ne bénéficiera plus de la protection offerte par l’équipe de sécurité de drupal.org. Elle s’assure que tous les modules, thèmes, distributions et le cœur de Drupal sont sécurisés. Qu’aucune faille ne peut être exploitée par des pirates et le cas échéant, produit des patchs de sécurité pour que vous puissiez mettre à jour vos sites en toute sérénité. C’est cette partie là qui s’arrête au mois de novembre 2021 pour Drupal 8.

Que dois-je faire ?

Selon vos sites, vous êtes dans l’une des deux situations suivantes :

Mon site est sous Drupal 7

D’ici au mois de novembre 2022, vous devez lancer le chantier de montée de version de votre site. Vers Drupal 9 ou vers un autre CMS, vous devez vous posez la question de l’impact de cette échéance.
À l’instar de Drupal 6, quelques grosses sociétés expertes Drupal ont annoncé qu’elles contribueraient à la maintenance de correctifs de sécurité de Drupal 7. Si une faille de sécurité importante venait à être découverte, ils s’engagent à reverser à la communauté le patch de sécurité aussitôt qu’il sera disponible.
Bien que cela soit une bonne nouvelle, ils ne maintiendront pas tout l’écosystème des modules utilisés par Drupal 7. Vous devez tenir compte de cette échéance pour gérer la montée de version de votre site.

Si votre site n’est plus dynamique, vous pouvez envisager une statification pour ne pas vous engager dans une refonte.

Il vous reste 16 mois pour agir, la durée moyenne d’un projet de refonte est de plusieurs mois. Ne traînez pas, nous pouvons vous aider !

Mon site est sous Drupal 8

Si votre site est sous Drupal 8, l’échéance est dans 4 mois mais, la bonne nouvelle c’est que la route est bien plus droite. En effet, le principal reproche fait à Drupal 6 et 7 était la complexité des montées de versions majeures. Comme nous l’avons indiqué précédemment, passer de Drupal 7 à Drupal 9 est un coût non négligeable. Ce frein a été entendu par la communauté et la gestion des montées de version a été revue pour en tenir compte. Depuis Drupal 8, la montée de version est sans friction car pour peu que vous mainteniez votre site Drupal 8 à jour, le passage à Drupal 9 consiste à simplement retirer le code déprécié entre les deux versions. Ce qui est une quantité bien moindre que précédemment.

Le coût de la montée de version est donc quasiment le même que celui d’une montée intermédiaire. On parle de quelques jours tout au plus contre des semaines voire des mois précédemment (car on en profitait en général pour changer bien d’autres choses par la même occasion).

Votre équipe technique devra donc s’occuper de cela et ne devrait pas avoir de problèmes pour gérer cette montée de version. Les quelques freins qui peuvent exister étant des modules contribués non compatibles avec Drupal 9 mais ils sont minoritaires. 100% du top 200 des modules et 95% du top 1000 est compatible avec Drupal 9.

Vous souhaitez en savoir plus ? Vous souhaitez migrer votre site vers Drupal 9 ?
Contactez-nous !