Headless CMS vs PHP classique : faut-il vraiment complexifier pour exister ?

Le nouveau réflexe technique
Aujourd’hui, difficile de lancer un projet web sans entendre parler de “headless CMS”.
Le terme revient partout. En réunion, dans les recommandations, dans les appels d’offres. Il rassure, il donne une impression de modernité, presque comme si c’était devenu un passage obligé. À côté, dire qu’on fait un site “classique” en PHP donne presque l’impression de faire quelque chose de dépassé.
Mais derrière cette opposition, une question simple mérite d’être posée : est-ce qu’on choisit vraiment une solution parce qu’elle est adaptée… ou simplement parce qu’elle est à la mode?

Deux façons de faire (sans blablabla)
Un site classique, c’est le modèle le plus simple à comprendre. Tu écris ton contenu dans un outil, et il s’affiche directement sur ton site. Tout est connecté, tout fonctionne ensemble, sans détour.
Le headless fonctionne autrement. Ton contenu est stocké à un endroit, et ton site vient le récupérer pour l’afficher. Il y a une étape en plus entre les deux. Ce n’est pas visible pour l’utilisateur, mais ça change complètement la manière dont le site est construit.
Ce n’est pas forcément mieux. C’est simplement une autre façon de faire, un peu plus technique, un peu moins directe.

Une promesse séduisante… mais pas gratuite
Si le headless séduit autant, c’est parce qu’il donne plus de liberté. Il permet de créer des expériences plus poussées, d’utiliser des technologies modernes et de réutiliser le même contenu à plusieurs endroits, par exemple sur un site et dans une application.
Sur le papier, tout paraît plus flexible, plus évolutif, plus ambitieux.
Dans la réalité, cela demande aussi plus de travail. Les projets deviennent plus techniques, les équipes doivent être plus organisées et chaque modification peut demander plus d’interventions. Ce que l’on gagne en liberté, on le paie en complexité.

Le risque de compliquer pour rien
C’est là que beaucoup de projets se trompent.
On choisit une solution avancée alors que le besoin est simple. Un site vitrine, quelques pages, du contenu à mettre à jour de temps en temps. Rien qui justifie une architecture compliquée.
Et pourtant, on met en place une machine assez lourde pour gérer ça. Le site fonctionne, bien sûr. Mais il devient plus difficile à maintenir, à faire évoluer, et parfois même à comprendre.
C’est un peu comme utiliser un outil trop puissant pour un besoin basique. On finit par perdre du temps là où on voulait en gagner.

La tentation du “on verra plus tard”
On entend souvent qu’il faut penser à l’avenir, anticiper, construire quelque chose de scalable. L’intention est bonne, mais elle est souvent floue.
Évoluer, oui. Mais vers quoi exactement ?
Si ce futur n’est pas clairement défini, on prend le risque de complexifier le présent pour quelque chose qui n’arrivera peut-être jamais. On construit une solution pour un problème hypothétique, au lieu de répondre simplement à un besoin réel.

Alors, quand utiliser quoi ?
En pratique, tout dépend du projet.
Un site classique reste parfaitement adapté dès que le besoin est simple et clair. Présenter une activité, publier du contenu, être visible en ligne. Dans ces cas-là, on cherche surtout à aller vite, à rester efficace et à garder un outil facile à utiliser.
Le headless devient intéressant lorsque le projet change de dimension. Par exemple, quand le contenu doit être utilisé sur plusieurs plateformes, quand l’expérience utilisateur devient plus poussée, ou quand le site s’inscrit dans un ensemble plus large. Là, la complexité a du sens, parce qu’elle répond à un besoin réel.

Une question de bon sens
Au fond, la décision est assez simple. Il suffit de se demander d’où vient la complexité.
Si elle vient du projet lui-même, de ses usages ou de ses ambitions, alors une solution plus avancée peut être pertinente. Mais si elle vient uniquement du choix technique, alors il y a de fortes chances que ce ne soit pas le bon choix.

En bref
Le headless CMS n’est pas une révolution. Le PHP classique n’est pas dépassé.
Ce sont simplement deux façons de construire un site.
Le vrai enjeu n’est pas d’utiliser la solution la plus moderne, mais celle qui est adaptée au projet. Parce qu’au final, un bon site n’est pas celui qui impressionne techniquement, mais celui qui fonctionne, simplement et efficacement.