Ce site web est notre spécification technique — y compris les mesures qui ne nous avantagent pas.
Nous construisons des sites rendus côté serveur, avec des images en AVIF et WebP, des en-têtes de sécurité vérifiés de l’extérieur, un plan de site généré à partir des données et une vérification d’acceptation exécutée après chaque publication. Tout peut être inspecté sur la page que vous lisez.
Déjà construitNous ne pouvons pas citer un site client sans son accord, mais nous n’en avons pas besoin : la preuve est cette page même. Elle tourne sur Next.js 16.2.4 avec React 19.1.0, elle est servie en pré-rendu depuis le cache (`x-nextjs-prerender: 1`, `x-nextjs-cache: HIT`), porte HSTS avec `preload`, `nosniff`, `SAMEORIGIN`, `Referrer-Policy` et une politique de contenu complète — vérifiés avec `curl -I` le 06.09.2026. Le plan du site contient 147 adresses, toutes générées à partir de données, pas écrites à la main. La deuxième implémentation, dans le même dépôt : l’infrastructure du formulaire — journal append-only, sonde publique de santé, limitation de débit — et le script d’acceptation exécuté après publication.
Un site vitrine n’a qu’un seul test honnête : pouvez-vous vérifier de l’extérieur ce que l’entreprise en dit ? C’est pourquoi cette page n’énumère pas des technologies, mais des choses que vous pouvez contrôler vous-même avec une commande. Le site fonctionne sous Next.js 16.2.4 et React 19.1.0, et les pages sont pré-rendues à la construction et servies depuis le cache — cela se voit dans les en-têtes de réponse : `x-nextjs-prerender: 1`, `x-nextjs-cache: HIT`, `s-maxage=31536000`, avec une fenêtre de 300 secondes pendant laquelle une page ancienne peut encore être servie pendant qu’elle se rafraîchit.
Le rendu côté serveur n’est pas une préférence d’architecte. Un visiteur avec une connexion faible et un moteur de recherche reçoivent le même HTML complet, sans attendre JavaScript. À cela s’ajoute une discipline des ressources : les images sortent en AVIF et WebP, avec un cache d’un an ; les polices sont hébergées chez nous, et non demandées à un service externe ; huit bibliothèques d’interface ont leurs imports optimisés afin de ne pas charger des modules entiers pour une seule icône.
Les en-têtes de sécurité sont envoyés depuis deux endroits et vérifiés dans la réponse réelle, pas seulement dans la configuration : transport sécurisé imposé pendant deux ans avec sous-domaines et inscription sur la liste de préchargement, interdiction de deviner le type de fichier, restriction de l’encadrement dans des cadres étrangers, politique de référent, et une politique d’autorisations qui ferme la caméra et laisse le microphone uniquement pour sa propre origine — parce que les démonstrations vocales en ont besoin et, sans cette exception, le navigateur refuse en silence.
La dernière partie est celle qui nous différencie, et elle est désagréable : nous publions aussi ce que nous avons mal mesuré chez nous. Le serveur ne fournit pas encore Brotli ni HTTP/2. Le catalogue de traductions est transmis à chaque navigation et coûte environ 70 KB compressés à chaque fois. Un paquet de 443 KB contient quatre catalogues de langue, dont un seul est routable. Les polices apportent aussi le sous-ensemble cyrillique, bien que les pages vérifiées ne contiennent aucun caractère cyrillique. Ces chiffres sont mesurés, écrits dans le dépôt et dans la liste des corrections. Un fournisseur qui n’a pas de tels chiffres sur son propre site n’a soit pas mesuré, soit ne veut pas le dire.
Ce que cela comprend
Le travail, par composantes
Rendu côté serveur, servi depuis le cache
Les pages sont pré-rendues au moment de la construction et livrées comme HTML complet, et non construites dans le navigateur. Dans la réponse réelle apparaissent `x-nextjs-prerender: 1` et `x-nextjs-cache: HIT`, avec `cache-control: s-maxage=31536000` et une fenêtre de 300 secondes pendant laquelle l’ancienne version peut encore être servie pendant qu’elle se rafraîchit. L’effet pratique : un visiteur avec une connexion faible et un crawler reçoivent le même contenu, dans la même requête.
Images et polices avec budget, pas avec la chance
Les formats configurés sont AVIF et WebP, avec une durée minimale de cache de 31.536.000 secondes — un an — et un en-tête `immutable` sur les fichiers statiques, les images et les polices. Les polices sont hébergées par nous lors de la construction, et non demandées à un service externe à chaque visite, et elles sont affichées avec `swap`, afin que le texte apparaisse avant le téléchargement de la police. Il existe aussi un script de compression en lot, avec une qualité de 80 pour WebP et de 75 pour AVIF, afin que la source ne dépende pas de ce que quelqu’un a exporté depuis l’éditeur graphique.
En-têtes de sécurité envoyés depuis deux endroits et vérifiés dans la réponse
Depuis l’application : transport sécurisé imposé pendant 63.072.000 secondes avec sous-domaines et inscription sur la liste de préchargement, `X-Content-Type-Options: nosniff`, `X-Frame-Options: SAMEORIGIN`, `Referrer-Policy: strict-origin-when-cross-origin` et une politique d’autorisations qui ferme la caméra, laisse le microphone uniquement pour sa propre origine et désactive le regroupement par centres d’intérêt. Depuis le serveur web, séparément : une politique de sécurité du contenu complète, avec la liste explicite des origines autorisées. À la remise, il est écrit explicitement que ce sont deux endroits — sinon le prochain qui change quelque chose cherchera au mauvais endroit.
Plan du site généré à partir de données, pas écrit à la main
Le plan du site est construit à partir de cinq sources — 13 adresses fixes, les articles, 19 produits, 12 services et 100 combinaisons service × domaine — puis passe par une déduplication finale. Résultat : 147 adresses, comptées à la fois dans le code et dans le fichier servi en production. Une nouvelle page entre automatiquement ; une page supprimée disparaît. Personne ne maintient une liste parallèle qui se désynchronise en trois semaines.
Les anciennes adresses ne meurent pas : 43 redirections permanentes
Un nettoyage de structure laisse derrière lui des adresses que quelqu’un a enregistrées ou publiées. Dans la configuration, il y a 43 redirections permanentes — 9 guides vers le blog, 20 articles orphelins, 6 études de cas remappées et 8 pages individuelles. Il existe aussi 11 pages qui redirigent depuis l’intérieur de l’application ; elles sont correctes fonctionnellement, mais plus coûteuses qu’une règle de configuration, et elles sont consignées comme telles dans la liste des corrections.
Le formulaire est une infrastructure, pas un décor
La demande est écrite dans un journal append-only avant toute tentative de livraison, avec une deuxième ligne pour le résultat ; il existe une sonde publique de santé qui dit si un lead peut atteindre un humain en ce moment ; et les requêtes vers les interfaces sont limitées à 10 par minute, avec la clé prise depuis le dernier saut de l’en-tête d’adresses redirigées, et non du premier — le premier est envoyé par le client. Les raisons sont écrites dans le code, pas dans une documentation séparée.
Vérification d’acceptation après chaque publication
Un script ouvre chaque page de produit, par groupes de trois, et échoue s’il manque le code 200, l’ancre de questions, l’ancre d’exemple ou l’adresse canonique. Il vérifie ensuite le plan du site — qu’il contienne chaque produit et qu’il ne contienne pas de variantes de langue qui ne peuvent pas s’ouvrir — et `robots.txt`, afin qu’il ne bloque pas les ressources nécessaires au rendu. Chaque vérification correspond à quelque chose qui s’est déjà cassé une fois.
Adresse canonique résolue une fois, pour tout le site
L’adresse canonique est déclarée de manière relative, à un seul endroit dans la structure de base, et elle est résolue pour chaque route séparément. Même solution pour l’adresse de partage social, qui déclarait auparavant la page d’accueil sur la plupart des pages. C’est une ligne de code qui remplace une convention que chaque nouvelle page aurait dû retenir d’elle-même — et qu’elle ne retient inévitablement pas.
Ce qui ne fonctionne pas est écrit dans le dépôt, à côté du code
Le dépôt contient un fichier de défauts connus qui explique, par exemple, pourquoi les variantes de langue dans l’adresse ne changent pas la langue, pourquoi la solution évidente aggrave les choses — au rendu côté serveur, il n’y a ni stockage local, ni navigateur, donc le détecteur tombe sur l’anglais et toutes les pages sortent en anglais — et quelles sont les deux vraies solutions. Nous préférons qu’un acheteur technique trouve la limite que nous avons écrite, plutôt qu’il la découvre lui-même.
À quoi cela ressemble
Le parcours, étape par étape.
01
L’inventaire des adresses et ce qui se passe avec les anciennes
La première livraison est la liste des adresses existantes et la décision pour chacune : elle reste, elle est redirigée ou elle disparaît. Pour ce site, 43 redirections permanentes en ont résulté. C’est le travail que tout le monde saute et qui produit, quelques mois plus tard, des pages d’erreur dans les résultats de recherche.
02
La structure de contenu et les sources à partir desquelles elle est générée
Les pages de produit et de service sont construites à partir de données, et non de fichiers séparés. De là viennent le plan du site généré automatiquement, les adresses canoniques cohérentes et la possibilité de vérifier par programme que chaque page a ce qu’il faut. Nous livrons la structure de données, pas seulement les pages rendues à partir d’elle.
03
La construction, avec des budgets fixés avant le contenu
Nous définissons dès le départ quel format ont les images, ce qui est mis en cache et pour combien de temps, ce qui est rendu côté serveur et ce qui reste interactif dans le navigateur. Le contenu se place ensuite dans ce budget. L’ordre inverse produit des sites qui ont belle allure au lancement et s’alourdissent à chaque page ajoutée.
04
La publication avec gate et vérification d’acceptation
La publication vérifie la mémoire libre du serveur, exécute l’audit de sécurité des dépendances, construit à partir d’un état propre et confirme que le processus est lancé avant de signaler le succès. Juste après, le script d’acceptation ouvre les pages et vérifie les ancres, les adresses canoniques, le plan du site et `robots.txt`. Les deux sont remis, ils ne restent pas chez nous.
05
La remise, avec la liste des manques et des mesures
Nous remettons le code, la procédure de publication, la procédure de retour, les adresses de santé — et la liste écrite de ce qui n’est pas couvert, avec des chiffres. Pour ce site, la liste comprend l’absence de Brotli et de HTTP/2 sur le serveur, le coût du catalogue de traductions à chaque navigation et le sous-ensemble de polices non utilisé. Nous préférons que la liste vienne de nous.
Quatre couches vérifiables de l'extérieur
Les données
Ce que nous touchons, où elles sont et combien de temps elles restent
Les questions que pose toute personne ayant un délégué à la protection des données — posées ici avant qu'il ne les pose.
Les données du formulaire de contact
Nom, adresse e-mail, téléphone, entreprise, service choisi, message, page de provenance et préfixe réseau du visiteur. Elles sont écrites dans un journal sur son propre serveur, avec des droits `0700` sur le répertoire et `0600` sur les fichiers, en dehors du répertoire de version. Délai : 24 mois, appliqué par le code à chaque écriture, et non par un planificateur qui peut être oublié.
Adresse IP, tronquée avant d’être écrite
Seul le préfixe réseau est conservé — `/24` pour IPv4, `/48` pour IPv6 — et le dernier saut est lu dans l’en-tête, car le premier est envoyé par le client et ne prouve rien. La même fonction est aussi utilisée pour la limitation de débit, donc il n’existe pas de deuxième endroit où l’adresse complète pourrait arriver par erreur.
Statistiques de trafic
La mesure passe par l’outil d’analyse configuré et ne s’active qu’après consentement. Les cookies réels ont été vérifiés empiriquement sur le site en production, avant et après acceptation, et la politique de cookies a été réécrite après cette vérification — et non l’inverse. La politique précédente énumérait des cookies qui n’existaient pas.
Registre des traitements, versionné à côté du code
Chaque type de données touché par le site a une entrée avec la finalité, le fondement, les catégories et le délai, dans un document conservé dans le même dépôt. Quand le code modifie un délai, le document change dans le même commit. Ce qui n’est pas établi — par exemple la rétention réelle dans le compte d’analyse — est marqué explicitement comme élément à clarifier, et non déclaré comme un fait.
Ce qui ne sort pas du serveur
Les jetons de notification, les clés de fournisseur et les identifiants de canal. La sonde de santé ne renvoie que des valeurs logiques, justement pour pouvoir être interrogée par un service externe sans rien divulguer sur la configuration.
Un cas
Ce que révèle l’audit de son propre site quand vous le publiez en entier
La situation
Après une restructuration, le propre site semblait en ordre : toutes les pages répondaient 200, le tableau de bord était vert. Nous nous sommes posé la question que nous posons à nos clients : qu’indique une mesure effectuée de l’extérieur, sur toutes les adresses à la fois, et non sur la page d’accueil ?
Ce que nous avons construit
Nous avons parcouru avec des requêtes directes chaque adresse connue — 249 adresses, 23 colonnes par adresse, sans suivre les redirections, avec au plus six requêtes en parallèle — et nous avons mis le résultat dans un fichier tabulaire versionné. Par-dessus, nous avons exécuté des vérifications séparées : la compression réelle du HTML, ce qui se transmet à chaque navigation, ce que contiennent les paquets JavaScript, quelles polices sont téléchargées, quels en-têtes de cache et de transport offre le serveur. Chaque chiffre a été vérifié dans la réponse réelle, pas déduit de la configuration.
Ce qui en est sorti
244 adresses répondent 200 et 5 redirigent. 131 pages n’avaient pas d’adresse canonique, et 219 sur 244 déclaraient la page d’accueil comme adresse de partage — les deux sont maintenant corrigées avec une ligne chacune dans l’agencement de base, qui s’applique à chaque route. Le serveur n’offre ni Brotli ni HTTP/2. Le catalogue de traductions, 2.268 clés, est transmis à chaque navigation et coûte environ 70 KB compressés à chaque fois. Un paquet de 443 KB contient quatre catalogues de langue, dont un seul est routable. Les polices apportent aussi le sous-ensemble cyrillique, bien que les pages vérifiées ne contiennent aucun caractère cyrillique. Tous les chiffres, avec les commandes qui les reproduisent, sont écrits dans le dépôt.
Ce que le cas ne dit pas
Ce sont des mesures de laboratoire, effectuées de l’extérieur, avec des requêtes directes. Ce ne sont pas des données de terrain provenant de visiteurs réels et nous ne les présentons pas comme telles : les métriques de chargement perçu n’ont pas pu être lues dans l’outil utilisé et sont explicitement marquées comme non mesurées. Nous n’avons pas exécuté la construction de l’application pendant l’audit, parce que plusieurs personnes travaillaient sur le même checkout.
Questions
Ce que les gens nous demandent avant d'appeler
Avec quoi construisez-vous, concrètement ?
Next.js 16.2.4 avec React 19.1.0 et TypeScript, avec Tailwind pour les styles et des composants d’interface accessibles basés sur les primitives Radix. Les pages sont pré-rendues à la construction et servies depuis le cache — cela se vérifie de l’extérieur : les en-têtes de réponse contiennent `x-nextjs-prerender: 1` et `x-nextjs-cache: HIT`. Ce n’est pas une liste de technologies que nous avons lue ; c’est la pile sur laquelle tourne la page que vous lisez maintenant.
Comment vérifier moi-même ce que vous dites sur la sécurité ?
Avec une seule commande : `curl -I https://www.megapromoting.com/servicii`. Vous verrez `strict-transport-security: max-age=63072000; includeSubDomains; preload`, `x-content-type-options: nosniff`, `x-frame-options: SAMEORIGIN`, `referrer-policy: strict-origin-when-cross-origin`, une politique d’autorisations qui désactive la caméra et laisse le micro uniquement pour sa propre origine, plus une politique de sécurité du contenu avec la liste explicite des origines. Les cinq premières viennent de la configuration de l’application ; la dernière est envoyée par le serveur web — deux endroits différents, et nous l’écrivons à la remise.
Comment savez-vous que vous n’avez rien cassé lors de la dernière publication ?
À partir d’un script d’acceptation exécuté après la publication. Il ouvre chaque page de produit et échoue s’il manque le code 200, l’ancre de questions, l’ancre d’exemple ou l’adresse canonique ; il vérifie ensuite que le plan du site contient chaque produit et ne contient pas de variantes de langue qui ne s’ouvrent pas, et que `robots.txt` ne bloque pas les ressources de rendu. Chaque vérification de la liste correspond à quelque chose qui s’est déjà cassé. Le script est remis avec le projet — vous pouvez aussi l’exécuter.
Votre site est rapide ?
Cela dépend de ce que vous mesurez, et nous avons des chiffres dans les deux sens. Bons : les pages sont prerendues et servies depuis le cache, les images sortent en AVIF et WebP avec un cache d’un an, les polices sont hébergées localement. Mauvais, mesurés sur notre propre site : le serveur ne fournit ni Brotli ni HTTP/2 — une requête avec `Accept-Encoding: br` reçoit une réponse non compressée ; le catalogue de traductions est transmis à chaque navigation et coûte environ 70 KB compressés à chaque fois ; un paquet de 443 KB contient quatre catalogues de langue dont un seul est routable. Je ne vous donne pas un score de laboratoire ; je vous donne les octets mesurés et la liste des réparations qui en découle.
Qui entretient le plan du site ?
Personne, et c’est la bonne réponse. Il est généré à partir de cinq sources de données — adresses fixes, articles, produits, services et combinaisons service × domaine — puis passe par une déduplication finale. On obtient 147 adresses, le même chiffre dans le code et dans le fichier servi en production. Une nouvelle page entre automatiquement. Ce qui manque aujourd’hui, pour être dit : les entrées ne portent pas de date de dernière modification, et 93 adresses indexables ne sont pas encore dans le plan. Elles sont dans la liste des réparations, pas cachées.
Faites-vous des sites multilingues ?
Ici, je dois être précis, car c’est la limite la plus claire de ce site. Le changement de langue dans l’adresse ne fonctionne pas : la configuration fixe le roumain, donc le détecteur ne lit jamais le paramètre. J’ai écrit dans le dépôt pourquoi la solution évidente est pire — au rendu côté serveur, il n’y a ni stockage local ni navigateur, donc le détecteur tombe sur l’anglais et toutes les pages sortent en anglais — et quelles sont les deux vraies solutions : des routes par chemin, avec segment de langue, ou la résolution de la langue côté serveur sur chaque page. La première est recommandée. Pour un nouveau projet, nous partons directement sur des routes par chemin ; pour un projet existant, c’est un travail, pas un réglage.
Que se passe-t-il avec les anciennes adresses quand vous refaites un site ?
Elles sont inventoriées et reçoivent chacune une décision : elle reste, elle est redirigée de façon permanente ou elle disparaît. Au nettoyage de ce site, cela a donné 43 redirections dans la configuration. Il existe aussi 11 pages qui redirigent à l’intérieur de l’application — elles fonctionnent, mais construisent la page avant d’envoyer la réponse de redirection, ce qui est du gaspillage ; elles sont dans la liste à déplacer vers la configuration. Je vous le dis pour que vous sachiez quel type de liste vous recevez à la remise.
Comment savoir que le formulaire transmet réellement ?
Vous le lui demandez : `GET /api/health/contact` répond 200 si un lead peut parvenir à un humain maintenant et 503 sinon, en vérifiant séparément que le jeton du canal de notification est valide et que le journal des requêtes peut être écrit. La réponse ne contient que des valeurs logiques, jamais le jeton. Il existe parce que c’est précisément ici que cela s’est cassé une fois : jeton révoqué, route renvoyant 500, requêtes perdues sans trace. Désormais, la requête est écrite dans le journal avant que la livraison soit tentée.
Que ne faites-vous pas ?
Nous ne promettons pas de positions dans la recherche, de taux de conversion ou de scores de performance que nous n’avons pas mesurés sur votre projet. Nous ne livrons pas un site sans liste d’anciennes adresses ni procédure de retour. Nous n’assumons pas les plateformes tierces auxquelles nous n’avons pas accès. Et nous ne présentons pas comme prêt quelque chose qui a une limite connue — si j’ai une limite, vous la trouverez écrite dans le dépôt avant de la trouver en production.
Sur quoi reposent les affirmations ci-dessus (15 sources)
La production sert des pages prérendues depuis le cache : `x-nextjs-prerender: 1`, `x-nextjs-cache: HIT`, `cache-control: s-maxage=31536000`, `x-nextjs-stale-time: 300`https://www.megapromoting.com/servicii · 2026-09-06
En-têtes de sécurité dans la réponse réelle : HSTS `max-age=63072000; includeSubDomains; preload`, `nosniff`, `SAMEORIGIN`, `strict-origin-when-cross-origin`, politique de permissions avec `microphone=(self)` ; plus une politique de sécurité de contenu complète servie par nginx et ABSENTE de `next.config.ts`https://www.megapromoting.com/servicii · 2026-09-06
13 d'entre elles sont du code et des fichiers de nos dépôts. Nous n'en publions ni le nom ni la ligne : réunies sur une seule page, elles décriraient trop précisément comment sont construits des systèmes qui ne sont pas seulement les nôtres. Nous les parcourons avec vous, dans le dépôt, sur demande — la vérification reste possible, elle se fait simplement lors d'un échange.
Qu'est-ce que vous voudriez voir mieux fonctionner ?
Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.