Payload CMS : ce que c’est que de faire tourner le site d’une entreprise dessus

La plupart des textes consacrés à Payload CMS sont de la documentation réécrite. Celui-ci est différent pour une seule raison : le site que vous êtes en train de lire tourne sur Payload — avec le panneau d’administration dans lequel cet article a été rédigé, les calculateurs de la rubrique outils et ses quatre versions linguistiques.

Nous n’écrivons donc pas sur ce que le système promet, mais sur ce qui en découle quand on travaille dessus au quotidien : ce qui s’est révélé meilleur que prévu, ce qui nous a coûté des semaines, et à qui nous ne le recommanderions pas.

Ce qui distingue Payload du CMS que vous connaissez : le « code-first »

Sous WordPress et sous Strapi, la structure du contenu se clique dans un panneau. Vous ajoutez un champ « Prix », vous choisissez un type, vous enregistrez — et le champ apparaît dans le formulaire. Commode, jusqu’au jour où quelqu’un nomme un champ « Prix » avec une espace à la fin, ou le supprime un vendredi soir.

Payload fonctionne à l’envers. La structure est du code : un développeur décrit une collection et ses champs dans un fichier, et le panneau d’administration n’est que le reflet de ce code. On ne peut pas ajouter un champ depuis le panneau, parce que personne n’a dessiné ce panneau à la main — il est engendré à partir de ce code.

Pour une entreprise, trois conséquences, dans cet ordre d’importance :

• La structure du contenu passe par les mêmes portes que le reste du logiciel — revue de code, tests, historique des modifications. On sait qui a ajouté un champ, quand et pourquoi.
• Toute une classe de pannes disparaît, celle du « une faute de frappe dans un nom de champ a mis la page d’accueil par terre » : les noms de champs sont des types, et une incohérence est détectée avant la mise en ligne, pas par un lecteur.
• La rédaction perd son autonomie sur la structure. Un nouveau champ ou un nouveau type de section devient une tâche de développement. C’est un coût réel, et nous y revenons plus bas.

Sur notre propre site, cette « structure en code » a produit 28 010 lignes de définitions de types — un fichier que personne n’écrit à la main et dont dépend toute l’application. C’est une mesure physique de la quantité de structure que porte le site d’une entreprise, celle à laquelle personne ne pense dans un système qui se clique.

Ce qu’a changé la version 3 : une application au lieu de deux

C’est le changement qui pèse le plus lourd dans une conversation avec un directeur technique, et celui qui se perd le plus sûrement dans les descriptions commerciales.

Auparavant, un CMS headless était un serveur distinct : il se tenait à côté du site, avec sa propre mise en production, son propre hébergement et sa propre maintenance. Depuis la version 3, Payload s’installe dans une application Next.js — la documentation de l’éditeur le dit sans détour : « Add Payload to a new or existing Next.js app » (payloadcms.com).

Ce que cela change dans le calcul :

• Une mise en production au lieu de deux. Le panneau et le site sont la même application : il n’y a plus deux environnements à installer, à surveiller et à mettre à jour.
• Un seul hébergement. Le serveur dédié au backend disparaît, et avec lui une ligne distincte du budget d’infrastructure.
• Moins de travail d’administration. Plus deux chaînes de déploiement à synchroniser, ni deux endroits où les versions peuvent diverger.

Pour une entreprise sans équipe d’exploitation interne, c’est la différence entre « il nous faut quelqu’un pour l’infrastructure » et « un développeur qui connaît Next.js suffit ».

Ce que cela donne chez nous — le site en chiffres

Toutes les valeurs ci-dessous ont été comptées dans le dépôt de ce site le 11 septembre 2026 :

La colonne « article parent » de cette liste n’est pas une décoration : toute la hiérarchie de la rubrique, de l’aiguillage thématique jusqu’au texte isolé, est une relation dans les données. C’est ce qui permet à l’adresse, au fil d’Ariane et à la liste des articles liés de provenir d’un seul endroit, au lieu d’être saisis trois fois à la main.

Cet unique écran montre quatre choses à la fois. Les onglets répartissent les champs en groupes, de sorte qu’un rédacteur ne fait pas défiler cent champs pour atteindre le titre. La mention « — pl » à côté d’un champ signifie que la langue est une propriété du champ et non une page séparée : les mêmes données ont quatre valeurs, pas quatre copies. Le bloc « Banner » est l’une des quarante briques dont le contenu est assemblé. Et le bouton « Traduire » lance une traduction automatique des champs vers les trois autres langues — une fonction qui n’existe pas dans la boîte et que nous avons ajoutée nous-mêmes, parce que le panneau fait partie de notre propre application.

Le multilingue n’est pas une option ici : comment Payload modélise les langues

En Suisse, la question n’est presque jamais « aurons-nous une deuxième langue ? » mais « deux ou trois, et lesquelles ? ». C’est aussi le point sur lequel un CMS se choisit ou s’écarte, bien avant les considérations d’éditeur de blocs — et c’est celui que nous connaissons le mieux, puisque ce site en fait tourner quatre.

Dans Payload, la langue est une propriété du champ. Un champ déclaré localisé stocke autant de valeurs qu’il y a de langues dans la configuration ; un champ qui ne l’est pas en stocke une seule, commune à toutes. Un article n’est donc pas quatre articles : c’est un seul document dont certains champs portent quatre valeurs.

Sur ce site, la ligne de partage est la suivante — et c’est exactement la décision à prendre avant de construire quoi que ce soit :

Quatre conséquences pratiques en découlent, et toutes les quatre se remarquent dès la deuxième langue :

• Ce qui est commun se corrige une fois. Changer l’image d’en-tête, rattacher un texte à une autre catégorie ou le déplacer dans la hiérarchie : l’opération vaut pour toutes les versions, sans que personne ait à répéter le geste dans chaque langue ni à vérifier qu’il a bien été répété.
• Un lien posé une fois fonctionne partout. Les relations entre articles étant communes, un renvoi inséré depuis la version française pointe vers le bon document dans chacune des autres, sans table de correspondance à tenir à jour.
• L’adresse, elle, est propre à chaque langue. Le slug fait partie des champs localisés : chaque version linguistique vit à sa propre adresse, lisible dans sa langue, alors qu’il s’agit d’un seul et même document. Vous n’avez donc pas à choisir entre des adresses lisibles dans chaque langue et une structure unique — les deux tiennent ensemble.
• Et l’inverse est un piège. Un champ commun modifié dans une langue est modifié dans toutes. Si la version allemande a besoin d’une autre image que la française, ce champ doit être déclaré localisé dans le code : c’est une tâche de développement, exactement le coût décrit plus haut. Cette ligne de partage se décide au moment de la modélisation, pas six mois après.

Le statut de publication est lui aussi par langue, et c’est le point que nous conseillons de vérifier en premier dans n’importe quel système multilingue. Sur ce site, le champ qui distingue un brouillon d’un texte publié est déclaré localisé : un même document peut être publié dans une langue et encore à l’état de brouillon dans une autre. C’est ce qui rend une traduction en retard inoffensive — la version prête part en ligne, celle qui ne l’est pas attend, et personne n’a à jongler avec deux documents pour y arriver. L’option se déclare dans le code ; sans elle, un document n’a qu’un seul statut pour toutes ses langues, et publier signifie publier aussi la version que personne n’a relue. S’y ajoute la publication programmée, qui permet à une version linguistique d’attendre une date décidée à l’avance.

Ce que cela change au budget mérite d’être dit franchement, parce que c’est là que les devis divergent le plus. Une deuxième version linguistique n’est pas ici un deuxième site. Il n’y a pas une deuxième installation à mettre à jour, pas une deuxième base de données à sauvegarder, pas une deuxième licence à renouveler : c’est la même application, la même mise en production et le même panneau, avec un sélecteur de langue en haut de l’écran. Le coût variable du multilingue redevient ce qu’il devrait être — le travail de traduction lui-même, qui est un coût de contenu et non un coût de plateforme.

C’est aussi la raison pour laquelle notre bouton « Traduire » existe. Le panneau étant du code à nous, nous y avons branché une traduction automatique qui remplit les trois autres langues à partir de la version rédigée, laissant à la relecture humaine son vrai rôle : vérifier et réécrire, pas retaper. Sur un système fermé, une fonction de ce genre s’achète si elle existe ; ici, elle se construit.

Ce n’est plus seulement un système de gestion de contenu

Le plus intéressant dans le tableau ci-dessus, ce ne sont pas les articles : c’est ce qui a poussé à côté d’eux. Sur les trente-neuf collections, une bonne part n’a rien à voir avec du contenu :

• la gestion commerciale — sociétés, contacts, clients et les relations entre eux ;
• la messagerie et l’agenda — comptes de courrier, messages et événements rapatriés de l’extérieur, pour que l’historique d’une relation client tienne en un seul endroit ;
• les rendez-vous — types de rendez-vous, créneaux disponibles, réservations ;
• les prospects — enregistrements issus des calculateurs, résultats des outils, sessions du questionnaire de projet ;
• les données de campagne — clics publicitaires et termes de recherche qui ont amené quelqu’un ;
• les mesures de performance — les Core Web Vitals relevés chez de vrais visiteurs, dont nous nous servons plus bas dans ce texte.

Chacune de ces choses est la même structure qu’un article : des champs décrits en code, avec leurs propres droits d’accès et leur propre API. Il n’a pas fallu acheter un système séparé pour chacune, ni raccorder quatre abonnements les uns aux autres — et c’est, après deux ans, l’argument qui nous convainc le plus.

Ce que la même chose donnerait sous WordPress

Nous ne prétendons pas que ce soit impossible : cela se fait. La question est de quoi la facture serait composée :

Une partie de cet assemblage est chiffrable : un constructeur de pages répandu se renouvelle annuellement entre 228 et 540 euros selon la formule (notre propre relevé des tarifs SaaS, 26 août 2026). Ce montant est publié en euros par l’éditeur pour le monde entier, et nous le citons donc dans sa monnaie d’origine sans le convertir. La maintenance technique d’un WordPress, elle, se facture soit au forfait mensuel soit à l’heure, et les tarifs varient trop d’un prestataire et d’un marché à l’autre pour qu’un chiffre unique ait ici un sens — nous ne relevons pas nous-mêmes le marché suisse de cette prestation. S’ajoutent les licences des autres extensions du tableau dont vous auriez réellement besoin.

Payload n’a pas de redevance de licence, mais il a son coût : le développeur, dont nous parlons plus bas. La différence n’est pas que c’est moins cher, c’est que le coût n’est pas au même endroit : là-bas dans les abonnements et les renouvellements, ici dans le travail sur votre propre code.

Performance : nos propres données, pas un banc d’essai

Voici la partie qu’il n’est pas nécessaire de nous croire sur parole — parce que nous la mesurons sur nous-mêmes, chez de vrais visiteurs.

Notre base de données contient une collection de mesures Core Web Vitals envoyées depuis les navigateurs des personnes qui consultent ce site. Entre le 26 juillet et le 11 septembre 2026, 10 003 mesures s’y sont accumulées. Les résultats au 75ᵉ centile, c’est-à-dire exactement de la façon dont Google les calcule :

• LCP 1 444 ms pour un seuil de 2 500 ms — 88 % des mesures dans la plage « bon » (n = 2 016)
• INP 88 ms pour un seuil de 200 ms — 96 % dans la plage « bon » (n = 972)
• CLS 0,00 pour un seuil de 0,1 — 87 % dans la plage « bon » (n = 1 882)

Dans le détail par appareil, le LCP s’établit à 1 636 ms sur ordinateur et à 1 120 ms sur téléphone — plus rapide sur téléphone, ce qui est l’inverse de ce à quoi la plupart des gens s’attendent, et qui tient aux images plus petites servies aux écrans plus petits.

Ce que ces chiffres ne disent pas. Nous ne les comparons pas à WordPress : nous n’exploitons aucun site équivalent sous WordPress que nous mesurerions de la même manière, et les comparatifs publics qui circulent existent en plusieurs versions contradictoires et affichent leurs données côté navigateur, ce qui interdit de les citer honnêtement. Ce qu’ils disent suffit : la pile technique sur laquelle repose ce site maintient les trois métriques dans la plage « bon », sur des données venues de vraies personnes, et non sur un test de laboratoire lancé une fois.

D’où vient mécaniquement cet avantage : la page est assemblée sur le serveur et envoyée en HTML terminé, et il ne part vers le navigateur ni couche de thème ni une dizaine d’extensions ajoutant chacune ses propres scripts. Comment mesurer cela chez vous pour que le résultat signifie quelque chose, nous le décrivons dans notre texte sur le test d’un site.

Ce qui fonctionne mieux que nous ne l’attendions

Un versionnement que personne n’a besoin de se rappeler. Chaque enregistrement crée une version, et une version de travail se distingue d’une version publiée. Une correction qui a cassé quelque chose se défait d’un clic, sans demander de sauvegarde à qui que ce soit.

Le panneau fait partie de l’application, donc il s’étend. Un bouton à soi, un champ à soi, une validation à soi au moment de l’enregistrement : c’est du code dans le même dépôt, pas une extension d’un éditeur tiers qui cessera un jour d’être maintenue. Notre traduction automatique, la génération de liens courts à la publication et les images automatiques pour les réseaux sociaux sont nées exactement comme cela.

Des types plutôt que de la documentation. Puisque les champs sont du code, le reste de l’application sait tout d’eux : une faute de frappe dans un nom de champ ne compile pas, au lieu de se manifester par un trou blanc dans la page.

Des droits d’accès descriptibles avec précision. Puisque l’accès est du code, on peut écrire « ce rôle ne voit que ses propres entrées, celui-là peut publier, cet autre ne touche pas aux données clients » et être certain que cela vaut partout — dans l’API aussi, pas seulement dans l’apparence du panneau. Sous WordPress, ce niveau de contrôle signifie en général une extension de plus.

Ce qui nous a coûté du temps

Honnêtement, parce que c’est la partie absente des tests produits.

Un conflit avec le mécanisme de cache de Next.js 16. Le nouveau modèle de pré-rendu — une coquille statique servie immédiatement, des fragments dynamiques chargés derrière — exige un drapeau global dans la configuration. Le panneau de Payload ne fonctionne pas avec ce drapeau activé, parce qu’il utilise en interne l’heure courante et des accès dynamiques aux données, et que ce drapeau ne s’active pas pour quelques routes seulement : c’est tout ou rien. Conclusion pratique, qui nous a coûté le temps de simplement identifier le problème : le panneau et le site doivent alors être deux mises en production distinctes — ce qui retire une partie du bénéfice décrit dans la section sur l’application unique, et qui se planifie au départ plutôt que se découvre en cours de route. Nous revenons plus longuement sur le mécanisme lui-même dans notre texte sur Next.js et React.

La courbe d’apprentissage de la rédaction est réelle, et elle ne passe pas là où nous l’attendions. Il ne s’agit pas de l’usage du panneau : celui-ci est plus simple que WordPress. Il s’agit d’un choc d’habitudes : sous WordPress, la personne du marketing qui avait besoin d’un champ pour une description SEO ou d’une nouvelle section installait une extension et l’avait un quart d’heure plus tard. Ici, elle l’annonce au développeur et attend une mise en production. Les premières semaines après une bascule ne sont pas l’apprentissage d’un outil, mais l’apprentissage d’un nouveau partage du travail — et cela vaut la peine d’être dit à l’équipe avant, pas après.

La structure du contenu demande des décisions en amont. Puisque les champs sont du code, ajouter un vingt et unième type de section est une tâche de développement. Sur un projet où personne n’a réfléchi à ce dont on aurait besoin, cette file d’attente grossit plus vite que le budget.

À quoi ressemble une migration depuis un système existant

La question qui suit immédiatement la décision est toujours la même : que devient le contenu déjà en place. Voici l’ordre qui a fonctionné chez nous et que nous proposons à nos clients :

La structure d’abord, pas les données. Avant que quiconque exporte la première entrée, il faut décrire en code quels types de contenu existent et de quoi ils sont faits. C’est le moment où l’on découvre que l’« article » de l’ancien système porte un champ que personne n’utilise depuis deux ans, et trois autres qui veulent dire la même chose. Dans un projet multilingue, c’est aussi le moment où l’on tranche la ligne de partage décrite plus haut : ce qui est commun et ce qui est propre à chaque langue.

Ensuite la migration par lots, pas en une nuit. Un type de contenu d’abord, vérifié sur une douzaine d’entrées, et seulement ensuite le reste. Les adresses se déplacent avec le contenu — et si l’une d’elles change, elle a besoin d’une redirection publiée avant la disparition de l’ancienne, pas après.

La rédaction en dernier. Le panneau est plus simple que WordPress, donc la formation prend moins de temps que tout le monde ne le suppose. Le plus difficile est ce que nous avons décrit plus haut : le changement de partage du travail. Cela mérite une conversation à part entière, pas une diapositive dans une présentation d’après-lancement.

Ce qui ne se transfère jamais : les extensions. Tout ce qu’une extension faisait dans l’ancien système — formulaires, galeries, mécanique SEO — est de ce côté-ci à construire ou à remplacer par un service. C’est le plus gros poste du devis de migration, et le seul capable de le faire basculer.

Base de données : MongoDB ou Postgres — et pourquoi la question vient du service sécurité

Payload fonctionne sur MongoDB et sur Postgres — dans la documentation de l’éditeur : « Direct DB access and ownership with migrations, transactions, and proper indexing across MongoDB and Postgres ».

Ce n’est pas un choix technique, c’est un choix organisationnel. Dans les entreprises d’une certaine taille, la base de données n’est pas décidée par l’équipe projet mais par le service informatique ou par la sécurité — et les procédures y sont parfois écrites uniquement pour des bases relationnelles. Un projet qui arrive avec MongoDB peut s’enliser à l’étape de validation, non pour des raisons de fond, mais parce qu’il ne figure pas au catalogue des solutions admises.

La possibilité de faire tourner le même système sur Postgres est donc un laissez-passer, pas une préférence. Si vous discutez d’un déploiement dans une organisation dotée d’un processus formel de validation des technologies, c’est la première question à poser — avant toutes les autres.

Souveraineté des données : où vos contenus se trouvent physiquement

Les systèmes vendus par abonnement — Contentful, Sanity — conservent le contenu chez eux. Pour la plupart des entreprises, c’est un avantage : il n’y a rien à exploiter. Pour une partie d’entre elles, c’est une condition éliminatoire.

Services financiers, santé, marchés publics, industrie de défense : les exigences relatives au lieu de traitement des données et aux contrats de sous-traitance y sont parfois formulées de telle façon qu’envoyer le contenu dans le nuage d’un tiers est simplement exclu. Payload est un logiciel libre que vous exécutez sur votre propre infrastructure, si bien que la question « où se trouvent les données ? » reçoit une réponse que vous donnez vous-même, et non votre fournisseur.

C’est la même différence que celle que nous détaillons à propos de l’architecture headless : le modèle par abonnement vous retire l’exploitation et vous retire le contrôle avec elle ; l’hébergement chez soi fait exactement l’inverse.

Payload, Strapi, Contentful, Sanity — un partage par philosophie, pas par tarif

Les classements des « meilleurs CMS headless » ne servent à rien, parce que ces systèmes ne se concurrencent pas sur le même terrain. Ce qui les sépare, c’est le postulat sur qui a le droit de modifier la structure du contenu :

Nous ne donnons délibérément pas les prix de ces systèmes. Nous ne les détenons dans aucun relevé qui nous appartienne, et recopier le tarif d’un tiers sans date de relevé produit une information qui vieillira plus vite que cet article. Si vous comparez les coûts, allez les chercher sur les sites des éditeurs le jour de la décision et traitez-les comme un ordre de grandeur : le logiciel par abonnement modifie ses prix et ses limites plusieurs fois par an.

À qui nous ne recommanderons pas Payload

À une entreprise qui n’a et ne veut avoir personne du côté technique — ni chez elle, ni chez son prestataire. Payload exige quelqu’un qui l’entretient ; il n’exige pas que cette personne soit assise dans vos bureaux. Dans la pratique, nous rencontrons trois montages qui fonctionnent : un développeur interne, une agence sous contrat permanent, ou nous. Un quatrième ne fonctionne pas : le système construit une fois par quelqu’un qui a ensuite disparu — il tient alors effectivement jusqu’au premier changement impossible à faire depuis le panneau, puis devient une chose à laquelle tout le monde a peur de toucher.

Si donc vous lisez ceci depuis la position « nous n’avons personne de technique », ce n’est pas une raison de renoncer au headless. C’est un poste de budget à nommer avant de choisir un système, pas après.

À une équipe qui veut composer ses pages en faisant glisser des éléments. Payload fournit des briques préparées à l’avance ; il ne donne pas la liberté de poser n’importe quoi n’importe où. Si le marketing attend cela, il sera frustré — et à juste titre.

À un projet dont la valeur réside dans les extensions. Une boutique, une infolettre, des réservations, un cours en ligne : dans le monde WordPress ce sont des extensions toutes faites, ici c’est du travail à réaliser. Parfois rentable, parfois absurdement cher.

À qui nous le recommanderons : à une entreprise qui a ou construit une application en Next.js, qui publie en deux ou trois langues ou sur plusieurs canaux à partir du même contenu, qui veut garder ses données chez elle — et qui dispose d’un chemin de maintenance établi et stable, peu importe qu’il soit interne ou chez un prestataire.

Ce que cela coûte

Licence : zéro. Payload est un logiciel libre ; il n’y a ni redevance d’utilisation, ni facturation au nombre de rédacteurs, ni supplément par version linguistique.

Les coûts sont à deux autres endroits. L’infrastructure — c’est-à-dire le serveur et la base de données, au prix d’un hébergement d’application ordinaire ; nous en détaillons les étagères dans le choix d’un hébergement. Et le travail du développeur, puisque chaque changement de structure et chaque nouveau type de section est une tâche à exécuter. Plutôt que d’inventer ici un tarif de marché, chiffrez votre propre cas dans notre calculateur de coût d’un site.

Le troisième poste, récurrent celui-là, est l’exploitation : quelqu’un doit suivre les mises à jour, les sauvegardes et la disponibilité, que le site tourne sur Payload ou sur autre chose. Dans notre propre grille, ce forfait démarre à 25 CHF par mois pour une page d’atterrissage et à 50 CHF par mois pour un site d’entreprise de 5 à 15 pages, hors taxes ; les autres types de site se chiffrent ligne par ligne dans le calculateur de coût de maintenance.

La chose à calculer avant la décision et non après : combien de types de section vous recevez au départ, et ce qui se passe lorsque vous en voulez un de plus. C’est le seul poste de ce calcul capable de surprendre.

Cinq questions avant de décider

1. Qui, chez nous, pourra ajouter un nouveau type de section, et en combien de temps ? Si la réponse est « personne sur place », c’est une réponse sur le système, pas sur l’équipe.
2. Combien de types de section recevons-nous au départ ? Ce nombre décide de la fréquence à laquelle vous reviendrez vers votre prestataire l’année suivante.
3. En combien de langues publions-nous, et lesquels de nos champs doivent différer d’une langue à l’autre ? C’est la question qui se pose le moins souvent et qui se répare le plus difficilement après coup.
4. Sur quelle base de données cela tournera-t-il, et passera-t-elle notre procédure de validation ? Une question pour le service informatique, pas pour l’agence.
5. Où les contenus se trouvent-ils physiquement et qui y a accès ? Si vous avez des exigences réglementaires, c’est la première question, pas la dernière.

Et une sixième, qui ne concerne pas le système mais le contrat : que se passe-t-il si nous nous séparons de notre prestataire ? Dépôt de code, documentation, accès à l’infrastructure — écrits dans le contrat, pas promis en réunion.

D’où viennent ces chiffres

• Les chiffres sur notre propre site — comptés dans le dépôt de ce site le 11 septembre 2026 : 39 collections, 9 réglages globaux, 40 blocs de contenu, 22 variantes de hero, 4 versions linguistiques, 10 configurations de calculateurs, 28 010 lignes de définitions de types engendrées.
• Le modèle multilingue décrit ici — la configuration de ce site : champs localisés, statut de publication localisé et publication programmée, tels qu’ils sont déclarés dans nos collections. C’est une description de mécanisme, sans chiffre.
• Les captures d’écran — le panneau de ce site, lancé sur un environnement local, septembre 2026.
• L’installation dans une application Next.js et la prise en charge de MongoDB et de Postgres — la documentation de Payload CMS, vérifiée à la source le 11 septembre 2026.
• Les Core Web Vitals de ce site — la collection web-vitals de notre base de données, 10 003 mesures issues de vrais utilisateurs et recueillies entre le 26 juillet et le 11 septembre 2026 ; valeurs au 75ᵉ centile, seuils d’après la documentation Core Web Vitals.
• Le prix de renouvellement du constructeur de pages — notre propre relevé des tarifs SaaS, prix tel que publié par l’éditeur et relevé le 26 août 2026, cité dans sa monnaie d’origine et non converti.
• Nos forfaits de maintenance — les lignes de notre calculateur de coût de maintenance, en francs suisses et hors taxes, identiques à celles de la rubrique consacrée au prix d’un site web.
• Le conflit entre le panneau et le drapeau global de cache de Next.js 16 — notre propre déploiement, et non la documentation de l’un ou l’autre projet.
• Les tarifs de maintenance d’un WordPress — délibérément absents : nous ne relevons pas nous-mêmes cette prestation sur le marché suisse, et transposer un tarif relevé ailleurs fabriquerait un chiffre invérifiable. Reste le mécanisme de facturation, qui se transpose.
• Les prix de Payload Cloud, de Contentful et de Sanity — délibérément absents eux aussi : nous ne les détenons dans aucun relevé qui nous appartienne, et un tarif recopié sans date se périme plus vite que ce texte.