Le site en question, une plateforme de ressources pédagogiques pour enseignants du secondaire, tourne sur une architecture headless API REST WordPress et front Vue depuis cinq ans. Chaque année, à peu près, quelqu’un dans l’équipe ou chez le client relance la même question : « ne devrait-on pas passer à GraphQL, comme tout le monde semble le faire maintenant ? ». Cette année, la question a enfin reçu une réponse écrite et argumentée, plutôt qu’un simple report informel à l’année suivante.
Ce texte documente ce choix, non pas comme un rejet de principe de GraphQL, dont les bénéfices sont réels sur d’autres types de projets, mais comme une décision propre à ce projet précis, à son historique et à ses contraintes.
Pourquoi la question revenait chaque année
L’argument le plus souvent avancé en interne n’était pas un problème concret rencontré sur le projet, mais une forme d’inconfort face à la tendance : la majorité des nouveaux projets démarrés par l’agence utilisaient désormais WPGraphQL, la documentation et les retours d’expérience de la communauté se concentraient de plus en plus sur GraphQL, et l’équipe craignait de se retrouver avec des compétences REST de moins en moins entretenues face à un écosystème qui semblait converger ailleurs.
Cet inconfort est légitime, mais il ne constitue pas, en soi, un problème technique documenté sur le projet lui-même. Une revue rétrospective des tickets de maintenance des trois dernières années a été menée pour objectiver la question : combien d’incidents, de lenteurs ou de limitations réelles ont été attribués à l’usage de l’API REST sur ce projet précis ?
Ce que la revue a montré
Sur trente-huit tickets de maintenance liés à la donnée sur trois ans, aucun ne mentionnait un problème structurellement lié au choix de l’API REST plutôt que GraphQL. Les problèmes rencontrés (un champ ACF mal exposé, une pagination mal gérée sur un listing, un souci de cache CDN) auraient été tout aussi possibles, sous une forme différente, avec une API GraphQL.
Le seul point identifié comme un inconvénient réel de l’API REST actuelle était un léger sur-fetching sur deux endpoints de listing utilisant _embed, un problème réglé en quelques heures par l’ajout du paramètre _fields pour restreindre les champs renvoyés, sans nécessiter de changement d’architecture.
Ce que la migration aurait coûté
- Réécriture de l’ensemble des appels de données du front Vue, soit environ soixante composants consommant directement ou indirectement l’API REST, un chantier estimé à plusieurs semaines de développement pleines.
- Installation, configuration et audit de sécurité de WPGraphQL et de ses extensions nécessaires (support ACF, support du contenu personnalisé), avec la charge de maintenance supplémentaire que cela implique sur les mises à jour futures de WordPress.
- Une période de transition à risque, avec deux systèmes à maintenir en parallèle le temps de migrer progressivement, sur un site consulté quotidiennement par plusieurs milliers d’enseignants pendant l’année scolaire.
Face à ce coût réel et chiffrable, aucun bénéfice concret et spécifique au projet n’a pu être identifié pour le justifier. Les avantages classiques de GraphQL (réduction du sur-fetching sur des requêtes complexes, agrégation de plusieurs ressources en un seul appel, typage fort du schéma) répondent à des problèmes que ce projet ne rencontre pas dans sa forme actuelle, son modèle de contenu étant resté volontairement simple depuis son lancement.
Ce qui aurait changé la décision
La revue a identifié explicitement les signaux qui justifieraient de reconsidérer ce choix à l’avenir : l’ajout d’un modèle de contenu significativement plus imbriqué (des relations multiples entre plusieurs types de contenu personnalisés, consommées en une seule vue), un besoin de mobile natif consommant la même API avec des contraintes de bande passante plus strictes, ou une équipe de développement ne maîtrisant plus REST du tout à force de ne travailler que sur des projets GraphQL. Aucun de ces trois signaux n’est présent aujourd’hui sur ce projet.
Ce que cette décision a permis
Documenter ce choix par écrit, avec les chiffres de la revue rétrospective, a eu un effet inattendu mais précieux : la question n’est plus revenue de façon informelle et anxiogène en réunion. Elle a désormais une réponse claire, datée et argumentée, consultable par toute nouvelle personne rejoignant l’équipe, ce qui évite de rouvrir un débat déjà tranché sur des bases solides à chaque changement d’interlocuteur côté client ou côté agence.
Suivre une tendance technique sans problème concret à résoudre revient à payer le coût d’une migration pour le seul confort de ne plus se sentir à contre-courant ; ce n’est jamais gratuit, et ce n’est pas toujours justifié.
Notre verdict
GraphQL reste un excellent choix pour de nombreux projets WordPress headless, en particulier ceux dont le modèle de contenu est complexe ou qui doivent servir plusieurs clients aux besoins de données très différents. Mais un projet mature, stable, dont l’API REST répond correctement à ses besoins réels documentés, n’a aucune obligation de suivre une tendance par simple confort collectif. La bonne question à se poser n’est jamais « que fait le reste de l’écosystème », mais « quel problème concret, sur ce projet précis, cette migration résoudrait-elle ».
