Next.js ou React : la différence se voit sur la facture et dans Google

La question arrive presque toujours sous cette forme : React ou Next.js ? — et elle est mal posée, parce que ce ne sont pas deux technologies concurrentes entre lesquelles il faudrait trancher.

Next.js, c’est React auquel on a ajouté une couche serveur. En le choisissant, vous ne renoncez pas à React : vous lui ajoutez un serveur qui assemble la page avant qu’elle ne parte vers le navigateur. Toute la décision se ramène donc à une seule question : l’une de vos pages doit-elle être visible dans Google et rapide à la première ouverture ?

Un mot sur le destinataire, parce que le mot « Next.js » attire deux publics très différents. Ce texte est écrit pour la personne qui décide, pas pour celle qui code. Vous n’y trouverez pas une ligne de code, pas une commande à copier, pas de tutoriel de démarrage. Vous y trouverez ce qu’une offre veut dire quand elle écrit l’un de ces deux noms : ce que cela change sur la facture, dans la visibilité, et sur le profil des personnes que vous devrez recruter dans deux ans. Et aussi ce que Next.js perd, parce que cette question-là ne figure dans aucune offre.

Une précision propre à ce marché, qui revient tout au long du texte. Un site d’entreprise suisse existe rarement dans une seule langue. Partout où l’original de cet article compte des pages, cette édition compte aussi des versions linguistiques — parce que la même décision technique ne coûte pas la même chose à une langue et à trois.

React et Next.js : la phrase à laquelle tout le reste renvoie

React est une bibliothèque qui construit l’interface dans le navigateur de l’utilisateur. Le serveur envoie un fichier HTML pratiquement vide et un paquet de JavaScript ; c’est ce JavaScript qui dessine ensuite ce que l’on voit à l’écran.

Next.js, c’est le même React, avec une couche qui effectue ce travail plus tôt — sur le serveur, ou dès la construction du site. Le navigateur reçoit un HTML déjà rempli, et le JavaScript arrive ensuite pour animer ce qui demande de l’interaction.

S’y ajoutent des éléments que l’on assemble soi-même en React pur, à partir de bibliothèques séparées : le routage des adresses, l’optimisation des images et des polices, le découpage du code, la récupération des données côté serveur. Dans Next.js, tout cela est en place dès le premier jour.

Cette distinction n’a rien d’académique : tout ce qui suit en découle. C’est aussi le choix par défaut du marché — selon l’enquête State of React 2025 (3 760 réponses recueillies entre novembre 2025 et janvier 2026), 78 % des nouvelles applications React sont construites sur Next.js. C’est le méta-framework React le plus choisi, ce qui a une conséquence directe sur la disponibilité des développeurs.

Un point mérite d’être précisé ici, car il est source de malentendus à la réception d’un projet. Dans Next.js, tout ne se passe pas sur le serveur. Le framework sépare la page en deux familles d’éléments : ceux que le serveur assemble et envoie tout faits, et ceux qui doivent vivre dans le navigateur parce qu’ils réagissent à un être humain.

Du côté du serveur atterrit naturellement ce qui se lit : descriptions de prestations, fiches produits, articles, listes, navigation. Du côté du navigateur reste ce qui réagit au clic : formulaires, calculateurs, cartes, filtres, panier, chat. La conclusion pratique pour vous : choisir Next.js ne signifie pas que le site « n’a plus de JavaScript » — cela signifie que le JavaScript cesse d’être la condition pour voir le contenu et ne reste que la condition pour utiliser les fonctions.

Quatre différences qui se voient sur la facture et dans Google

Visibilité : Google a deux files d’attente, et votre site en rejoint une

C’est la différence qui tranche le plus souvent — et celle que les offres décrivent avec le plus de flou (« Next.js est meilleur pour le SEO »).

Le mécanisme est le suivant. Googlebot télécharge d’abord le fichier HTML. S’il s’agit d’une application rendue dans le navigateur — du React pur, sans couche serveur — ce fichier est vide : on y trouve le squelette de la page et un appel vers le JavaScript, mais pas le contenu. Pour voir le contenu, Google doit exécuter ce JavaScript, et cela demande des ressources distinctes. La page rejoint donc une seconde file d’attente, celle du rendu, et attend sa part de puissance de calcul. L’indexation du contenu peut ainsi être retardée de plusieurs jours ou semaines, et sur un site volumineux, une partie des pages n’atteindra jamais le haut de la file dans un délai raisonnable.

Avec un rendu côté serveur ou une génération statique, la première réponse contient déjà le contenu. Le robot l’indexe dès son premier passage, sans attendre l’exécution des scripts.

Ce n’est pas une interprétation de la branche : Google décrit lui-même cette séparation entre le téléchargement et l’étape de rendu dans sa documentation sur le JavaScript dans la recherche, assortie de la réserve que le rendu est différé jusqu’à ce que des ressources soient disponibles.

Les files d’attente de Google sont réelles et parfois longues, y compris au stade du simple téléchargement. Dans notre propre corpus, lors d’une revue d’indexation, quarante des soixante-quinze adresses rejetées avaient un dernier téléchargement remontant à cinq ou six mois avant la mesure. Cela concerne la file de téléchargement, pas celle du rendu, mais le message est le même : le temps du robot n’est ni gratuit ni illimité.

Et c’est ici que le nombre de langues change l’échelle du problème. Ces files comptent des adresses, pas des contenus. Un site de trente pages publié en français, en allemand et en anglais n’est pas un site de trente pages du point de vue du robot : c’est quatre-vingt-dix adresses, chacune à télécharger, chacune à rendre si le contenu n’arrive pas dans la première réponse. Les balises hreflang déclarent que ces adresses sont des équivalents linguistiques les unes des autres, elles ne les fusionnent pas en une seule entrée dans la file. Le coût du rendu différé se multiplie donc par le nombre de versions linguistiques, exactement comme le volume de contenu.

Quand cette différence n’a-t-elle aucune importance ? Lorsque les pages ne doivent être visibles qu’après connexion. Espace client, application interne, tableau de bord : Google n’a rien à y indexer, et la couche serveur n’achète pas de visibilité, faute d’endroit où l’acheter.

Comment vérifier ce que votre site envoie aujourd’hui

C’est une vérification de deux minutes, qui ne demande aucun développeur — et qui tranche la conversation où votre prestataire affirme une chose et l’offre concurrente en suggère une autre.

Première étape : regardez le fichier brut, pas ce qui s’affiche à l’écran. Dans votre navigateur, choisissez « Afficher le code source de la page » (et non « Inspecter l’élément », qui montre l’état après exécution des scripts, c’est-à-dire précisément ce que le robot ne voit pas d’emblée). Dans le fichier ouvert, cherchez n’importe quelle phrase de votre site. Si vous la trouvez, le contenu est dans la première réponse. Si le fichier tient en une quinzaine de lignes et ne contient que des appels de scripts, le contenu n’apparaît que dans le navigateur.

Deuxième étape : regardez ce que voit Google. Dans la Search Console, l’outil d’inspection d’URL affiche le code rendu et une capture de ce que le robot a effectivement vu. On y voit non seulement si le contenu est là, mais aussi si quelque chose en a bloqué le chargement.

Troisième étape, propre à un site multilingue : refaites les deux premières sur chaque version linguistique. Ce n’est pas une formalité. Beaucoup de sites servent leur langue par défaut depuis le serveur et laissent les autres langues au navigateur, parce que les bibliothèques de traduction côté client récupèrent leur dictionnaire dans un fichier distinct, chargé après le démarrage de la page. Résultat : la version française est dans la première réponse, les versions allemande et anglaise sont des pages vides jusqu’à l’exécution du script. On ne le voit jamais à l’écran, où tout paraît identique — on ne le voit que dans le code source.

La même vérification vaut la peine d’être faite sur les sites de vos concurrents, avant d’accepter l’idée que, dans votre branche, « tout le monde fait comme ça ».

Le délai de mise en œuvre : ce qu’il y a dans la boîte

Dans Next.js, le routage, le rendu côté serveur, l’optimisation des images et des polices ainsi que le découpage du code sont configurés par défaut. En React pur, chacun de ces éléments s’ajoute séparément et s’entretient soi-même.

De combien cela raccourcit exactement un projet dépend de ce que vous construisez — et nous ne connaissons aucune étude qui l’ait mesuré, nous ne donnons donc aucun pourcentage ici. La conséquence pratique, elle, est simple : plus votre projet a réellement besoin d’éléments de cette liste, plus la configuration prête à l’emploi est rentable. S’il n’en a besoin que d’un sur quatre, vous achetez l’ensemble pour un seul.

Le nombre de langues déplace ce calcul, et de façon nette. Le routage par langue fait partie de la boîte : les adresses par version linguistique, le sélecteur de langue, les balises hreflang, le plan de site par langue. À une langue, c’est une note de bas de page. À trois, c’est une pièce structurelle, que quelqu’un construira et maintiendra — soit une fois, dans le framework, soit à chaque fois, à la main. Le décompte « combien d’éléments sur quatre nous servent vraiment » donne donc rarement le même résultat pour un site monolingue et pour un site trilingue.

Le coût : une proportion, sauf sur un poste

Une réalisation en Next.js démarre généralement plus cher qu’une application simple en React pur : la couche serveur, c’est de l’infrastructure en plus, des décisions d’architecture en plus, et un endroit de plus où quelque chose peut casser. La différence se récupère à l’exploitation : moins de configuration maison à mettre à jour, moins de bibliothèques à recoller entre elles, moins de travail à chaque nouvelle page.

Elle ne se récupère cependant que si le projet utilise réellement la couche serveur. Sur un espace client accessible après connexion, vous la payez sans jamais vous en servir.

Nous ne publions volontairement aucune fourchette de tarifs ici. Ce que vous entendez dans les conversations — chez nous comme ailleurs — est une observation du marché, pas une étude avec une méthode. S’il vous faut des chiffres sur lesquels budgéter, allez chercher les rapports de rémunération publiés, ventilés par technologie et par niveau d’expérience ; ils sont mis à jour chaque année, et un tarif périmé dans un devis est pire que pas de tarif du tout. Ce qui compose l’ensemble de la facture d’exploitation d’un site, nous le détaillons à part dans le texte sur les frais récurrents.

Un seul poste fait exception, parce qu’il est chez nous et que nous le publions : la deuxième langue. Dans notre calculateur, un site vitrine démarre à 3 500 CHF et l’option multilingue ajoute 1 750 CHF — la moitié de la base, pour une seule langue supplémentaire. Le commentaire attaché à cette option dans notre propre configuration dit l’essentiel : la mise en place technique n’est qu’une fraction du coût, et la traduction professionnelle de toutes les pages coûte à peu près autant à nouveau.

Retenez surtout la répartition entre les deux moitiés, parce que c’est elle que la décision technique déplace. La traduction, vous la payez quel que soit le framework. La mise en place technique, en revanche, est exactement ce qui est dans la boîte d’un côté et à construire de l’autre — et c’est elle qui se paie une deuxième fois à chaque langue ajoutée si personne n’a prévu la structure dès le départ.

Disponibilité de l’équipe : le React pur est devenu une niche

L’intuition souffle qu’une technologie plus simple facilite le recrutement. C’est l’inverse. Puisque 78 % des nouvelles applications React sont construites sur Next.js, un développeur React est aujourd’hui par défaut un développeur Next.js, et une équipe travaillant exclusivement en React pur fait une chose de plus en plus rare.

Pour vous, cela signifie une chose : choisir Next.js ne réduit pas le vivier de candidats. Ce qui le réduit, c’est l’insistance à conserver une configuration React maison, qu’il faut réexpliquer de zéro à chaque nouvel arrivant.

Ce raisonnement pèse plus lourd sur un marché de taille modeste que sur un grand. Nous n’avons aucune mesure du vivier romand à vous donner, et nous n’allons pas en inventer une — mais la logique tient sans chiffre : plus le nombre de personnes susceptibles de reprendre votre code est faible, plus chaque choix non standard coûte cher le jour où il faut en trouver une. C’est un argument de succession, pas un argument de mode.

Quand React suffit, et quand Next.js se rentabilise

Le seuil est unique et se vérifie en une minute : si vous ne pouvez désigner aucune page qui doit être visible dans un moteur de recherche, la couche serveur est un coût sans recette.

Si votre arbitrage ne porte pas sur des frameworks mais sur des plateformes entières — WordPress, Webflow, headless, développement sur mesure — c’est une autre décision, et nous la traitons dans la comparaison des plateformes.

Passer de React à Next.js : ce que cela veut dire concrètement

La crainte la plus fréquente s’exprime ainsi : « il faut donc tout réécrire ». Non — et c’est l’avantage pratique de ce couple sur un changement de technologie plus radical.

Les composants restent. Puisque Next.js est React, le code de l’interface — boutons, formulaires, mises en page, toute la bibliothèque d’éléments que vous possédez — continue de fonctionner. Ce qui change, c’est où et quand ce code s’exécute, ainsi que ce qui l’entoure : la façon de décrire les adresses des pages et la façon de récupérer les données. C’est une réécriture de couche, pas de produit.

La migration peut être progressive et devrait généralement l’être. L’ordre raisonnable est le suivant : les nouveautés naissent déjà dans le nouvel ensemble, l’ancien site continue de tourner à côté, et vous déplacez les sections une par une. On commence par celles qui doivent être visibles dans les moteurs de recherche — c’est là que la couche serveur produit un effet immédiat — donc par les pages d’offre, le blog et les fiches produits. L’espace après connexion se déplace en dernier, ou jamais.

Ce qu’il faut surveiller pendant ce passage. Les adresses des pages doivent rester identiques, et si l’une d’elles change, elle a besoin d’une redirection 308 posée avant que l’ancienne ne disparaisse. C’est l’endroit où une migration coûte le plus souvent de la visibilité : ce n’est pas la technologie qui échoue, c’est la liste d’adresses qui se révèle incomplète.

Et cette liste se multiplie par le nombre de versions linguistiques. Une page dont l’adresse change dans un site trilingue, ce sont trois adresses à rediriger, pas une. Trente pages en trois langues, ce sont quatre-vingt-dix règles à écrire, à vérifier et à déployer — et une seule oubliée suffit à faire disparaître une langue entière des résultats, souvent celle que personne dans l’équipe ne relit. Les vérifications avant et après la mise en ligne sont décrites dans le texte sur le test d’un site, et le calcul plus large d’une modernisation dans l’audit.

Et l’équipe. Un développeur React n’apprend pas un nouveau langage, seulement de nouvelles conventions du même framework. Notre expérience de ces passages est que les deux premières semaines partent dans les conventions, et que la douleur n’arrive pas à l’apprentissage mais à la décision : qu’est-ce qui doit s’exécuter sur le serveur et qu’est-ce qui doit s’exécuter dans le navigateur ? C’est une décision de conception, pas une décision technique.

Vue, Angular et Astro : le même calcul ailleurs

React n’est pas la seule façon de construire une interface, et Next.js n’est pas la seule couche serveur du marché. Le mécanisme des deux files d’attente de Google fonctionne à l’identique dans chacun de ces mondes — seul change le nom de l’outil avec lequel vous le traitez.

Vue et Nuxt

Nuxt est à Vue ce que Next.js est à React : il ajoute le rendu côté serveur, la génération statique, le routage et les optimisations. Si quelqu’un vous propose Vue, la question sur la couche serveur se pose donc dans les mêmes termes, et la réponse s’appelle Nuxt.

Deux différences se voient réellement du côté du donneur d’ordre. L’entrée dans un projet est parfois plus douce — la syntaxe de Vue est plus proche du HTML ordinaire, si bien qu’un développeur connaissant HTML, CSS et les bases de JavaScript devient productif plus vite qu’en React, où s’ajoutent des conventions propres. Le vivier de candidats est en revanche plus étroit. Nous n’avons pas de mesure de ce vivier sur ce marché et nous n’en avancerons donc pas ; l’argument qui pèse est celui de la durée : la question n’est pas de savoir si vous trouvez un prestataire aujourd’hui, mais si vous en trouverez un autre dans trois ans, quand le premier ne répondra plus au téléphone. Publier une offre d’emploi fictive avant de signer reste le test le moins cher de cette hypothèse.

Angular

Angular est un framework complet, avec ses conventions imposées, et non une bibliothèque autour de laquelle on assemble le reste. Pour une entreprise, cela signifie moins de décisions d’architecture au démarrage et un code plus prévisible lorsque le projet passe d’une équipe à une autre — au prix d’une entrée plus raide et d’une souplesse moindre.

La question « React ou Angular » se pose réellement, et la réponse en pratique est ennuyeuse : si vous avez une équipe qui travaille en Angular, faites le calcul en Angular. Réécrire une application qui fonctionne pour la porter en React, dans le seul but d’ajouter le rendu côté serveur, est le chemin le plus cher vers un résultat que votre propre framework sait également atteindre.

Astro, quand toute cette couche est un excès

Si vous construisez un site de contenu — sans connexion, sans panier, sans logique côté serveur, mais avec beaucoup de texte à montrer — Astro fait exactement cette tâche-là, et il la fait plus simplement. Ce n’est pas un choix contre Next.js, c’est un ajustement de l’outil au périmètre : dans l’enquête State of React 2025, Astro devance Next.js de 39 points de pourcentage en satisfaction des développeurs, et le reproche le plus fréquent adressé à Next.js est précisément sa complexité croissante.

Ce que cette comparaison ne contient pas, volontairement

Des chiffres affirmant que, dans tel écosystème, un projet se construit x pour cent plus vite. Nous ne connaissons aucune étude qui l’ait mesuré sur des projets comparables, et chaque chiffre de ce genre qui circule est une impression déguisée en mesure. La seule comparaison qui ait du sens se fait sur votre projet et votre équipe — et elle donne un résultat différent pour chaque entreprise.

Comment cela se passe chez nous : Next.js 16, Payload et le PPR

Ce site tourne sur Next.js avec Payload CMS, nous pouvons donc dire quelques choses de première main, et non d’après la documentation d’autrui.

Next.js 16, sorti le 21 octobre 2025, a introduit les Cache Components — un modèle fondé sur le Partial Pre-Rendering et la directive use cache. La version stable est aujourd’hui la 16.3, du 3 août 2026 ; les détails figurent dans les notes de version.

Ce que le PPR signifie en langage de facture, plutôt qu’en langage d’architecture :

• Vitesse. La coquille statique d’une page — en-tête, mise en page, contenu qui ne bouge pas — part du réseau CDN en quelques millisecondes, parce qu’elle est prête avant que quiconque n’arrive. Les fragments dynamiques, comme les stocks, les prix par client ou le contenu du panier, se chargent en flux et apparaissent sur une page déjà visible.
• Coût. Le serveur ne reconstruit pas la page entière à chaque visite, il ne complète que ce qui doit l’être. Avec un rendu serveur classique, chaque visite coûte un travail de processeur complet ; ici elle en coûte une fraction. Dès qu’il y a du trafic, cela se voit sur la facture d’infrastructure — ce que nous détaillons au moment du choix de l’hébergement.

Le nombre de langues entre ici dans un calcul très concret. La coquille statique est générée par adresse, pas par contenu. Trente pages en trois langues, ce sont quatre-vingt-dix pages à pré-générer à chaque construction du site, et un temps de construction qui suit la même multiplication. Ce n’est pas un obstacle, c’est une ligne de budget d’exploitation dont il vaut mieux connaître l’existence avant d’ajouter la troisième langue : la question à poser à votre prestataire n’est pas « combien de temps dure une construction », mais « combien de temps durera-t-elle quand nous serons en trois langues et à deux cents pages ».

Et maintenant le mur sur lequel nous sommes tombés, et qui ne figure dans aucune documentation. Activer les Cache Components exige un drapeau global cacheComponents dans la configuration de Next.js. Payload 3.x ne fonctionne pas avec ce drapeau : le panneau d’administration utilise en interne Date.now() et un accès dynamique aux données, ce qui contredit les hypothèses du pré-rendu — et Next.js ne permet pas d’activer ce drapeau pour un sous-ensemble de routes seulement. C’est global ou rien.

La conclusion de mise en œuvre, à connaître avant de choisir sa pile plutôt qu’après : si vous construisez sur Payload et voulez profiter du PPR, le panneau et le site public doivent être deux déploiements distincts. C’est faisable, mais cela se planifie au départ — reconstruire un site en service pour le scinder en deux déploiements coûte nettement plus cher que de le poser ainsi d’emblée. Nous parlons plus longuement du système lui-même dans le texte sur Payload CMS.

Parmi les changements plus discrets mais sensibles au quotidien : depuis la version 16, Turbopack est le constructeur par défaut, en développement comme en production, et les notes de la version 16.2 annoncent un démarrage de next dev quatre fois plus rapide et un rendu plus rapide de moitié par rapport à la version précédente.

Là où Next.js perd. Disons-le franchement : sa domination porte sur l’adoption, pas sur la satisfaction — ces mêmes 78 % décrivent ce que les gens choisissent, pas ce dont ils sont contents. Le reproche récurrent est la complexité croissante, et pour un site purement éditorial, Astro se révèle souvent le meilleur choix ; nous le développons dans la section sur les autres frameworks ci-dessus. Ce n’est pas un argument qu’il vaut la peine de taire dans une offre.

Ce que ce choix ne réparera pas

Le framework décide à quelle vitesse et sous quelle forme le contenu arrive au navigateur et au robot. Il ne décide de rien de ce qui détermine si quelqu’un vous contactera.

Il ne réparera pas une offre que l’on ne voit pas sur le site. Il ne réparera pas des textes qui ne répondent pas à la question du client. Il ne construira pas la visibilité d’un site que personne ne cite et qui n’a rien à montrer au moteur de recherche : le rendu côté serveur accélère l’indexation du contenu, mais il ne crée pas de raison de le montrer.

Si la décision technologique est chez vous la première décision du projet, elle est probablement prise trop tôt. Les cinq arbitrages qui la précèdent sont décrits dans le guide de la stratégie de site. Et si le site fonctionne déjà et que vous voulez savoir ce qui le ralentit réellement avant que quiconque ne propose de le réécrire, commencez par la mesure, pas par le framework.

Les chiffres de notre propre site

La meilleure preuve de ce que le framework ne règle pas, nous l’avons chez nous. Notre site polonais, digitalvantage.pl, tourne sur Next.js avec un rendu côté serveur : le contenu est dans la première réponse, exactement comme décrit plus haut. Et pourtant, en septembre 2026, nous avons examiné 124 adresses que Google n’affiche pas dans ses résultats, réparties en quatre états.

Soixante-quinze ont été téléchargées puis écartées — c’est un jugement de qualité, pas un problème technique. Vingt-cinq sont inconnues de Google, parce que rien ne pointe vers elles. Vingt-deux sont connues mais n’ont jamais été téléchargées. Deux, nous les avions exclues nous-mêmes avec une balise noindex avant de l’oublier pendant des mois.

Aucun de ces quatre états ne dépend du choix entre React et Next.js. La couche serveur achète une seule chose : quand le robot finit par venir, il a quelque chose à indexer immédiatement. Qu’il vienne, et qu’il juge le contenu digne d’être montré, se décide ailleurs — et la durée pendant laquelle il peut ne pas revenir se lit dans ces quarante adresses téléchargées pour la dernière fois cinq à six mois plus tôt.

Cinq questions qui révèlent si votre prestataire fait le même calcul que vous

Elles ne sont pas techniques et n’exigent aucune connaissance du framework. Chacune vérifie si, en face, il y a une décision ou une habitude.

1. Quelles pages doivent être visibles dans Google, dans quelles langues, et lesquelles sont derrière une connexion ? Une réponse du type « toutes » signifie que personne n’a fait le compte — et c’est la seule question qui tranche sur la couche serveur.
2. Qu’est-ce qui s’exécutera exactement sur le serveur, et qu’est-ce qui s’exécutera dans le navigateur ? Si la réponse est « le framework s’en charge », ce n’est pas une réponse.
3. À quoi ressemble la liste des adresses avant et après le changement, dans chaque langue, et qui pose les redirections ? Posée avant la mise en ligne, la question coûte une phrase ; posée après, elle coûte des positions.
4. Avec quoi mesurerons-nous l’effet, et quelle est la valeur d’avant ? Sans chiffre de départ, impossible de démontrer une amélioration — ni d’en constater l’absence. Un seuil utile parce qu’externe et vérifiable : le Largest Contentful Paint devrait tenir dans 2,5 secondes, et au-delà de 4 secondes il est jugé mauvais.
5. Que se passe-t-il quand le framework publie sa prochaine version majeure ? La réponse montre si la maintenance est dans le contrat ou si ce sera une autre conversation dans un an.

D’où viennent ces chiffres

• 78 % des nouvelles applications React sur Next.js et l’avance d’Astro de 39 points de pourcentage en satisfaction — enquête State of React 2025, 3 760 réponses recueillies entre novembre 2025 et janvier 2026.
• Dates et changements de Next.js 16 — notes de version du projet : la version 16 du 21 octobre 2025, la version stable 16.3 du 3 août 2026, Turbopack par défaut depuis la 16, les résultats de démarrage et de rendu issus des notes de la 16.2.
• Incompatibilité de Payload 3.x avec le drapeau global `cacheComponents` — notre propre déploiement de ce site, et non la documentation de l’un ou l’autre projet.
• Cent vingt-quatre adresses invisibles en quatre états, et quarante des soixante-quinze écartées dont le dernier téléchargement remonte à cinq ou six mois — notre propre revue d’indexation dans la Search Console, le 8 septembre 2026, sur notre site polonais digitalvantage.pl. Le site suisse est trop jeune pour produire un relevé comparable ; nous publions donc celui que nous avons réellement mesuré, en nommant le domaine.
• 3 500 CHF pour un site vitrine et 1 750 CHF pour la deuxième langue — notre propre tarif, celui du calculateur, en francs suisses. Ce sont nos prix, pas une moyenne de marché.
• Fourchettes de tarifs — volontairement absentes. Ce que nous avançons en conversation est une observation du marché, pas une étude ; les chiffres avec une méthode se trouvent dans les rapports de rémunération publiés.