Site statique, CMS ou framework : comment choisir ?

La question revient au début de chaque projet et se règle trop souvent par la préférence de celui qui va construire le site. Or les trois familles de solutions n'ont ni le même coût de départ, ni le même coût d'entretien, ni surtout les mêmes conséquences sur qui pourra faire évoluer le site dans trois ans. Un générateur de site statique, un système de gestion de contenu et un framework de développement répondent à des situations différentes, et le critère décisif n'est presque jamais technique : il s'agit de savoir qui met à jour le contenu, à quelle fréquence, et quelle part de logique métier le site doit porter au delà de l'affichage de pages.

Poser la question dans le bon ordre

Avant de comparer des technologies, il faut décrire le site en trois phrases : qui écrit le contenu et avec quel niveau de compétence technique, à quelle fréquence il change, et ce que le site doit faire au delà d'afficher des pages. Ces trois réponses éliminent en général deux des trois options. Un site institutionnel mis à jour deux fois par an par une agence, un blog alimenté chaque semaine par une équipe éditoriale et une application métier accessible par navigateur n'ont strictement rien en commun, et prétendre les traiter avec le même outil relève de la préférence personnelle plutôt que de l'analyse. Écrire ces trois phrases prend un quart d'heure et évite des mois de regrets, ce qui en fait probablement l'exercice au meilleur rendement de tout le projet.

La deuxième question porte sur la durée de vie attendue et sur les personnes qui interviendront. Un site conçu pour trois ans dans une organisation dotée d'une équipe technique ne pose pas les mêmes contraintes qu'un site conçu pour dix ans dans une structure qui changera plusieurs fois de prestataire. La disponibilité des compétences sur le marché, le coût de reprise par un tiers et la pérennité de la solution pèsent alors davantage que l'élégance technique. Ce raisonnement rejoint ce que nous exposons dans notre article sur le CMS, sa définition et son fonctionnement.

La troisième question, la plus négligée, porte sur le volume et la nature du contenu. Trente pages figées, trois mille articles, un catalogue de dix mille produits alimenté par un système externe : ces trois situations orientent le choix bien plus sûrement que n'importe quelle considération de performance. Il vaut la peine de les évaluer honnêtement, en tenant compte de la croissance prévisible, car un choix parfaitement adapté à trente pages devient franchement pénible à mille, et l'inverse est vrai aussi. La nature du contenu compte autant que son volume : des pages rédigées librement, des fiches structurées et des données issues d'un système externe n'appellent pas les mêmes outils.

Le site statique

Un générateur de site statique produit des fichiers HTML à partir de contenus écrits dans un format simple et de gabarits, puis ces fichiers sont déposés sur un serveur qui n'a plus qu'à les servir. Il n'y a ni base de données, ni code exécuté à la demande, ni surface d'attaque applicative. Les conséquences sont considérables : une rapidité que rien d'autre n'égale, un hébergement dérisoire, une sécurité presque totale et une capacité à absorber n'importe quelle pointe de trafic sans configuration particulière. Pour un site de contenu, ces avantages sont réels et durables. Ils se doublent d'une sobriété technique appréciable, un site statique consommant une fraction des ressources serveur d'un site équivalent généré à la demande.

Les contreparties sont tout aussi nettes. La publication demande une chaîne de génération et de déploiement, ce qui met le contenu hors de portée d'une personne non technique à moins d'ajouter une interface d'édition, laquelle rétablit une partie de la complexité qu'on avait fuie. Toute fonctionnalité dynamique, formulaire, recherche interne, espace membre, commentaires, doit être confiée à un service tiers ou à un composant séparé. Enfin, le temps de génération croît avec le nombre de pages, ce qui rend l'approche pénible au delà de quelques milliers de contenus si le générateur ne gère pas la construction incrémentale. Ce point mérite d'être vérifié avant de s'engager, car il détermine directement le confort de travail au quotidien une fois le site rempli.

Cette famille convient parfaitement à une documentation technique, à un site institutionnel, à un blog tenu par des personnes à l'aise avec les outils de développement, ou à un site à très fort trafic dont le contenu change peu. Elle convient mal dès que plusieurs personnes non techniques doivent publier sans coordination. Les interfaces d'édition adossées à un dépôt de code règlent partiellement ce point, à condition d'accepter que la publication ne soit pas instantanée. Le point de comparaison le plus parlant est celui que nous développons dans notre article sur les CMS Ghost ou Hugo face à WordPress.

Le système de gestion de contenu

Un système de gestion de contenu apporte une interface d'administration, une gestion des droits, une médiathèque, un système de gabarits et un écosystème d'extensions. Il permet à une personne sans compétence technique de publier, de modifier une page, de téléverser une image et de gérer un menu. Cette capacité est le seul argument qui compte dans la majorité des projets réels, et elle explique la domination durable de cette famille bien au delà des débats techniques qu'elle suscite. Sur un site alimenté quotidiennement, elle vaut à elle seule toutes les contraintes qu'elle impose. Il faut ajouter que la disponibilité des compétences est ici incomparable : trouver quelqu'un capable d'intervenir sur les solutions les plus répandues ne pose aucune difficulté, où que l'on soit.

Le prix à payer est un temps de réponse plus élevé, puisque chaque page est produite à la demande, une surface d'attaque bien plus large, et une dépendance à un écosystème dont on ne maîtrise pas les mises à jour. L'entretien est réel : mises à jour du cœur et des extensions, sauvegardes, surveillance, gestion des incompatibilités. Ce coût récurrent est presque toujours sous estimé au moment du choix, et il représente pourtant sur cinq ans une part significative du coût total de possession, souvent supérieure au coût de construction initial. L'omettre du budget initial ne le fait pas disparaître, il réapparaît simplement sous forme d'incidents non provisionnés.

Cette famille convient à l'immense majorité des sites de contenu, aux boutiques et aux sites institutionnels vivants. Elle convient mal quand la logique métier devient centrale : dès qu'un site passe plus de temps à calculer, à valider et à orchestrer qu'à afficher des pages, on se bat contre l'outil plutôt qu'avec lui, et chaque fonctionnalité demande de contourner des mécanismes prévus pour autre chose. Ce moment est identifiable et mérite d'être reconnu plutôt que nié pendant deux ans. Le signal le plus fiable est le nombre d'extensions installées uniquement pour contourner un comportement natif, qui croît silencieusement jusqu'à devenir ingérable.

Le framework de développement

Un framework fournit une structure, des composants éprouvés et des conventions, sans imposer de modèle de contenu. Tout ce qui est spécifique se construit, ce qui donne une liberté complète sur la modélisation des données, sur les parcours et sur l'intégration avec des systèmes externes. Pour une application métier, un outil de gestion, un site à logique complexe ou une interface adossée à un système d'information existant, c'est la seule approche qui ne conduise pas à une accumulation de contournements.

Le coût initial est nettement plus élevé, puisqu'il faut construire ce que les autres solutions fournissent : administration, gestion des droits, médiathèque, formulaires. Il faut également des compétences de développement durablement disponibles, ce qui constitue le risque principal pour une petite structure. Un site sur mesure abandonné par son développeur devient très difficile à reprendre, non pas parce que le code serait mauvais mais parce que chaque projet a ses propres conventions, qu'il faut apprendre avant de pouvoir intervenir. Une documentation d'architecture, même sommaire, et le respect de conventions largement partagées réduisent considérablement ce risque.

Cette famille se justifie quand la valeur du projet réside dans ce qu'il fait plutôt que dans ce qu'il affiche. Elle se justifie aussi lorsque des contraintes réglementaires ou d'intégration rendent les solutions génériques inadaptées. C'est fréquemment le cas dans la santé, la finance ou les métiers soumis à des obligations de traçabilité précises. Elle ne se justifie pas pour un site de contenu, quelles que soient les préférences de l'équipe technique, et les projets qui ont pris ce chemin pour un site vitrine se retrouvent invariablement avec un outil que personne ne veut plus maintenir. La structuration d'un tel projet est décrite dans notre article sur la manière de structurer un projet PHP sans framework.

Les critères qui tranchent réellement

Trois critères suffisent à décider dans la quasi totalité des cas, et ils ne figurent jamais en tête des comparatifs que l'on trouve en ligne. Le premier est l'autonomie éditoriale : si des personnes non techniques doivent publier sans passer par un intermédiaire, la question est réglée et les deux autres options demandent un travail supplémentaire pour atteindre ce que la troisième offre nativement. Ce critère à lui seul explique la plupart des choix raisonnables. Il mérite d'être vérifié auprès des personnes concernées plutôt que supposé : une équipe qu'on croit non technique peut parfaitement travailler avec un dépôt de code, et l'inverse arrive tout aussi souvent.

Le deuxième est la part de logique métier. Un site qui affiche des pages, même beaucoup de pages, reste un site de contenu. Un site qui calcule des tarifs selon des règles complexes, orchestre des validations, dialogue avec un système de gestion et applique des droits fins par utilisateur est une application, quelle que soit son apparence. Confondre les deux conduit soit à construire une application sur un outil de publication, soit à construire un site de publication avec un outil d'application, deux erreurs symétriques dont la seconde est simplement moins fréquente. Le test le plus simple consiste à compter les règles métier que le site doit appliquer : au delà d'une dizaine, on quitte le domaine de la publication.

Le troisième est la durée et le contexte de maintenance. Une solution que personne ne saura reprendre est une mauvaise solution, quelles que soient ses qualités. La question à poser est simple : si l'équipe actuelle disparaît demain, combien de temps faut il à quelqu'un d'autre pour être opérationnel. Ce critère favorise nettement les solutions répandues et documentées, et il explique pourquoi des choix techniquement discutables restent souvent les plus raisonnables pour une petite organisation. La question de la reprise doit être posée à voix haute au moment du choix, et pas seulement le jour où elle se pose concrètement.

Les solutions mixtes

La frontière entre ces trois familles est devenue nettement plus poreuse, et les approches mixtes règlent élégamment un certain nombre de situations. La plus répandue consiste à utiliser un système de gestion de contenu pour l'édition et à générer des pages statiques à partir de son contenu, ce qui combine le confort éditorial et la rapidité de service. Le dispositif ajoute une étape de génération et un délai entre la publication et la mise en ligne, contrainte acceptable sur la plupart des sites de contenu. Ce montage suppose toutefois une chaîne de publication fiable, dont la panne bloque toute mise en ligne, et cette chaîne doit être surveillée comme n'importe quel composant critique.

Une autre approche consiste à conserver un système de gestion de contenu pour ce qu'il fait bien, la publication éditoriale, et à développer séparément les parties applicatives, les deux cohabitant sur le même domaine. Cette séparation évite de contorsionner l'outil de publication pour lui faire porter une logique qui ne lui convient pas, et elle permet de faire évoluer chaque partie indépendamment. Elle demande en contrepartie une réflexion sur l'authentification partagée et sur la cohérence visuelle entre les deux ensembles. Ces deux points se règlent proprement quand ils sont traités au début, et deviennent pénibles quand ils sont découverts en cours de route.

Enfin, un site statique peut parfaitement intégrer des éléments dynamiques chargés après le rendu, formulaire, recherche, éléments personnalisés, ce qui étend son domaine d'application bien au delà de la documentation. La règle qui guide ces montages est toujours la même : chaque partie du site doit être servie par l'outil qui lui convient, et la complexité d'assemblage doit rester inférieure à celle qu'on cherchait à éviter, faute de quoi le remède est pire que le mal. Un montage que l'on ne sait pas expliquer en trois phrases à quelqu'un d'extérieur est presque toujours trop compliqué pour le besoin qu'il sert.

Ce que coûte un mauvais choix

Un mauvais choix ne se manifeste jamais immédiatement. Le site sort, il fonctionne, tout le monde est satisfait. Les difficultés apparaissent au bout d'un an ou deux, quand une évolution simple sur le papier demande trois jours au lieu de trois heures, quand chaque mise à jour casse quelque chose, ou quand la personne qui publie renonce à modifier une page par crainte de tout abîmer. Ces symptômes sont progressifs et rarement rattachés au choix initial, ce qui explique qu'ils soient si rarement corrigés. Les repérer suppose de poser régulièrement la question aux personnes qui utilisent le site au quotidien, seule source d'information fiable sur ce point.

Le coût réel se mesure en frein à l'évolution. Un site qu'on n'ose plus toucher cesse d'être mis à jour, son contenu vieillit, son référencement se dégrade et il finit par être refait entièrement trois ans plus tard. La refonte est alors présentée comme un choix stratégique alors qu'elle n'est que la conséquence d'un choix technique inadapté, et le même raisonnement produira souvent le même résultat si personne n'a analysé ce qui n'a pas fonctionné. Une refonte réussie commence donc toujours par un examen honnête de ce qui a coincé dans la précédente, exercice que peu d'organisations prennent le temps de mener.

La bonne nouvelle est que ces situations se diagnostiquent assez bien. Si les évolutions courantes demandent systématiquement une intervention technique, si l'équipe éditoriale contourne l'outil en passant par des documents envoyés par courriel, ou si chaque nouvelle fonctionnalité suppose une extension supplémentaire, le choix initial ne correspond plus au besoin réel. Reconnaître ce décalage tôt permet de le corriger progressivement, par exemple en déportant une partie applicative, plutôt que d'attendre la refonte complète. Une correction progressive coûte une fraction du prix d'une refonte et évite de tout remettre en jeu, y compris ce qui fonctionnait très bien. Elle suppose seulement d'accepter une architecture composite pendant un temps, situation moins élégante sur le papier mais nettement plus prudente en pratique.