Comment choisir une agence Next.js : 8 contrôles tirés de notre propre site
Neaptide · 10 octobre 2026 · 10 min de lecture
8 contrôles pour choisir une agence Next.js. 6 pages sur 6 de neaptide.ai : HTTP 200, un H1, canonical conforme et 7 alternatives linguistiques.
Dans cet article

Comment choisir une agence de développement Next.js ?
Choisissez une agence Next.js en lui demandant de passer huit contrôles sur de vraies URL publiées et sur le flux éditorial que vous utiliserez. Le 7 octobre 2026, nous avons contrôlé six pages de neaptide.ai : les six ont renvoyé HTTP 200, un seul H1, une canonical conforme et sept alternatives linguistiques. Demandez les mêmes preuves avant de signer.
- Contrôles de sortie : 4 des 8 contrôles portent sur le HTML renvoyé par une URL publiée, à savoir statut, canonical, H1 et alternatives linguistiques.
- Nos données : 6 pages sur 6 de neaptide.ai ont passé ces quatre contrôles le 7 octobre 2026, avec des requêtes HTTP non authentifiées et sans rendu navigateur.
- Contrôles du travail : les 4 autres portent sur l’édition dans le CMS, la migration, les formulaires et la passation, et chacun exige une démonstration réelle.
- Budget : la page développement web de Neaptide affiche des prix de départ de 2 900 $ US pour une landing page, 8 200 $ US pour un site d’entreprise et 14 000 $ US pour une application web.
- Signal d’alerte : un prix ferme pour un site multilingue avec CMS qui ne cite ni modèles, ni langues, ni anciennes URL.
Quels 8 contrôles une agence Next.js doit-elle passer avant la signature ?
Une agence Next.js doit passer huit contrôles avant la signature : quatre sur le HTML renvoyé par ses URL publiées et quatre sur un travail qu’une requête HTTP ne voit pas. Ces huit contrôles sont la réponse du serveur, la canonical, un seul H1, les alternatives linguistiques, le flux éditorial, la migration, les formulaires et intégrations, et la passation. Les alternatives linguistiques sont les liens hreflang qu’une page déclare vers chaque version linguistique, plus x-default.
| Contrôle | Ce qu’il faut demander à l’agence | Réussi / Signal d’alerte si absent |
|---|---|---|
| 1. Réponse du serveur | Le statut HTTP et la balise robots d’URL publiées représentatives | Réussi : 200 et index, follow sur chaque page publique. Alerte : aucun relevé par URL fourni. |
| 2. Canonical | La canonical déclarée par chaque URL | Réussi : une canonical identique à l’URL demandée. Alerte : absente, en double ou pointant vers une autre URL. |
| 3. Un seul H1 | Le nombre de H1 dans le HTML de chaque URL | Réussi : exactement un H1. Alerte : aucun H1 ou plusieurs. |
| 4. Alternatives linguistiques | Les alternatives linguistiques de chaque URL et une requête vers chaque cible | Réussi : chaque langue publiée plus x-default, chaque cible accessible. Alerte : une langue manquante ou des cibles non testées. |
| 5. Flux éditorial | Une session CMS en direct menée par votre futur rédacteur | Réussi : brouillon, aperçu, publication d’une version linguistique, correction et restauration. Alerte : l’une de ces cinq actions non montrée. |
| 6. Migration | L’inventaire des anciennes URL et le plan de redirections | Réussi : chaque ancienne URL a une destination ou une décision consignée. Alerte : un devis de migration sans inventaire. |
| 7. Formulaires et intégrations | La preuve de livraison de chaque formulaire et intégration | Réussi : un envoi de test arrive à destination. Alerte : des formulaires listés sans test de livraison. |
| 8. Passation | Accès au dépôt et aux comptes, instructions de déploiement et d’édition | Réussi : une deuxième personne refait le déploiement et l’édition à partir des instructions. Alerte : accès détenus par la seule agence. |
Notre étude couvre uniquement les contrôles 1 à 4. Les contrôles 5 à 8 se testent sur le projet commandé.
Que demander en premier à une agence Next.js ?
Demandez à l’agence Next.js les preuves manquantes dans cet ordre et arrêtez-vous au premier point qui s’applique : tant que ce manque n’est pas comblé, les propositions ne se comparent pas équitablement.
- Si l’agence ne peut montrer aucun contrôle de sortie par URL pour un site qu’elle a livré, demandez-le avant tout.
- Si le projet inclut un CMS et que votre futur rédacteur n’a pas vu un brouillon passer par l’aperçu, la publication et la restauration, demandez cette session.
- Si le nouveau site remplace un ancien et que le devis ne contient aucun inventaire des anciennes URL, demandez cet inventaire et le plan de redirections.
- Si les formulaires et intégrations sont listés sans test de livraison, demandez comment la livraison sera testée avant la mise en ligne.
- Si ces quatre points sont réglés, comparez les propositions sur le périmètre, les honoraires, les exclusions et les conditions de passation.
Qu’a montré le contrôle de notre propre site ?
Le 7 octobre 2026, les six pages en ligne de neaptide.ai que nous avons contrôlées ont toutes renvoyé HTTP 200, un seul H1, une canonical identique à l’URL demandée, des métadonnées robots index, follow et sept alternatives linguistiques chacune. Neaptide, un studio de marketing numérique qui crée aussi des sites sur Next.js, a mené ce contrôle sur son propre site de production. Le contrôle lit uniquement le HTML du serveur : il ne prouve ni l’indexation Google, ni la qualité des traductions, ni les capacités d’un CMS.
Cet article présente une étude du propre site de Neaptide. Il ne compare pas d’agences nommées, ne rapporte aucun résultat client et ne démontre pas de CMS headless. Notre site actuel stocke les articles dans le dépôt de code : sa sortie multilingue ne prouve que le fonctionnement de ce système de publication.
Comment les données sur les six pages ont-elles été recueillies ?
Les données sur les six pages proviennent de requêtes HTTP GET non authentifiées envoyées le 7 octobre 2026 à six URL de production anglaises de neaptide.ai. Le HTML renvoyé a été analysé pour le statut, la canonical, le nombre de H1, les métadonnées robots et les alternatives linguistiques. Les six URL sont les pages de services SEO, GEO, développement web et conseil en IA, la page d’audit Next.js et le guide sur le chatbot de connaissances internes. L’heure de collecte et une empreinte de chaque réponse HTML figurent dans le fichier JSON téléchargeable.
Les requêtes n’ont pas exécuté de JavaScript dans un navigateur. L’étude ne mesure ni l’ergonomie, ni les scores de performance, ni les formulaires, ni les droits du CMS, ni la qualité des traductions, ni l’indexation : chacun de ces points demande son propre test. Les six URL ont été choisies pour couvrir cinq pages commerciales et un article ; elles ne forment pas un échantillon aléatoire du site.
| Chemin d’URL | HTTP | Canonical | Nombre de H1 | Alternatives linguistiques | Résultat |
|---|---|---|---|---|---|
| /en/services/seo | 200 | Identique à l’URL demandée | 1 | 7 | Réussi |
| /en/services/geo | 200 | Identique à l’URL demandée | 1 | 7 | Réussi |
| /en/services/web | 200 | Identique à l’URL demandée | 1 | 7 | Réussi |
| /en/services/ai | 200 | Identique à l’URL demandée | 1 | 7 | Réussi |
| /en/services/seo/nextjs-seo-audit | 200 | Identique à l’URL demandée | 1 | 7 | Réussi |
| /en/blog/company-knowledge-chatbot | 200 | Identique à l’URL demandée | 1 | 7 | Réussi |
Un contrôle HTTP réussi prouve-t-il qu’une page Next.js est indexée ?
Un contrôle HTTP réussi prouve ce que le serveur a renvoyé au moment de la collecte ; l’indexation Google et la canonical retenue par Google se vérifient séparément. Sur les six pages de neaptide.ai, les champs étaient cohérents : un H1, une canonical conforme, index, follow et sept alternatives linguistiques (six langues plus x-default).
Sept alternatives linguistiques déclarées par page ne prouvent pas que chaque cible fonctionne ni qu’elle contient une traduction correcte. Cette étude n’a pas interrogé les cibles des 42 entrées d’alternatives (6 pages × 7). Une recette complémentaire doit ouvrir chaque URL cible et vérifier que les liens sont réciproques.
Google présente la canonical déclarée comme un signal. Pour diagnostiquer un problème d’indexation, croisez la réponse de la page avec les données de Search Console, l’accès des robots d’exploration, les liens internes et les sitemaps.
Sur quelles pages réceptionner un site Next.js multilingue ?
Un site Next.js multilingue se réceptionne sur au moins cinq types de pages : une page de service représentative, un article, une étude de cas, une page sans traduction et chaque URL migrée. Le site publié doit exposer le contenu et les métadonnées prévus. Un aperçu privé suit ses propres règles d’accès et d’indexation.
Si un CMS fait partie de la commande, votre futur rédacteur doit dérouler le flux éditorial en direct : créer et prévisualiser un brouillon, publier une version linguistique, la corriger et restaurer une version précédente. Notre étude HTTP ne peut pas montrer si ces actions fonctionnent dans un CMS, et nous ne l’utilisons pas comme preuve.
Cinq volets du périmètre doivent figurer dans le brief :
- Modèles de contenu : champs des services, articles et études de cas, sections partagées et relations.
- Règles linguistiques : champs traduits, champs partagés, URL et traductions indisponibles.
- Publication : rôles éditoriaux, accès à l’aperçu, validations et restauration.
- Migration : inventaire réel des anciennes URL, redirections et décisions de contenu.
- Passation : accès au dépôt et aux comptes, instructions de déploiement et responsabilité de la maintenance.
Les contrôles changent-ils pour une agence, un freelance ou une équipe interne ?
Les mêmes huit contrôles s’appliquent à une agence Next.js, à un freelance ou à une équipe interne, car chaque contrôle porte sur des URL publiées et des flux qui fonctionnent, pas sur la taille du prestataire. Nos données ne comparent pas ces trois options : cet article ne dit donc pas laquelle est la meilleure.
Avec chacune des trois, réglez à l’avance qui détient les accès après la mise en ligne. Demandez des accès au dépôt et aux comptes au nom de votre entreprise, avec des instructions de déploiement et d’édition qu’une deuxième personne peut suivre.
Combien coûte un site Next.js ?
Chez Neaptide, un site Next.js commence à 2 900 $ US pour une landing page, 8 200 $ US pour un site d’entreprise et 14 000 $ US pour une application web, selon notre page développement web capturée le 7 octobre 2026. Ce sont des prix de départ par format. Un projet multilingue avec CMS, migration et intégrations demande un devis fondé sur ses modèles, ses langues et ses besoins de publication réels.
La même page indique qu’un projet dure en général 4 à 8 semaines : environ une semaine pour le design et l’architecture, 3 à 5 semaines pour le développement et les contenus, puis une dernière semaine pour les ajustements, les tests de charge et la mise en ligne.
Quels signaux d’alerte avant d’engager une agence Next.js ?
Sept signaux d’alerte doivent suspendre un contrat avec une agence Next.js tant qu’elle ne les a pas levés :
- Aucun contrôle de sortie par URL pour un site en ligne livré par l’agence.
- Une URL représentative qui renvoie un statut autre que 200, plus d’un H1 ou une canonical différente de sa propre adresse.
- Des alternatives linguistiques qui n’énumèrent pas chaque langue publiée plus x-default : un site en six langues en déclare sept, comme chaque page contrôlée de neaptide.ai.
- Une démonstration du CMS qui saute l’aperçu, la publication d’une version linguistique ou la restauration d’une version précédente.
- Un devis de migration sans inventaire des anciennes URL et de leurs redirections.
- Des instructions de passation qu’aucune deuxième personne n’a refaites avant la réception.
- Un prix ferme pour un site multilingue avec CMS qui ne cite ni modèles, ni langues, ni intégrations, ni exclusions.
Ces signaux sont des critères de réception ; Neaptide n’a pas mesuré leur fréquence chez les agences.
Comment réceptionner un site Next.js lors de la passation ?
Réceptionnez un site Next.js seulement après qu’une deuxième personne de votre équipe a suivi seule les instructions de déploiement et d’édition, sans l’aide de l’agence. Conservez les contrôles de sortie par URL avec l’inventaire de migration et les preuves de livraison des formulaires, pour séparer ce qui est vérifié de ce qui n’a pas été testé.
La méthode appliquée aux six pages de neaptide.ai peut être rejouée avant et après une mise en production dans ce dossier de réception, avec les contrôles de l’éditeur, de la migration et des intégrations.