Formulaire et recherche sur un site statique : comment faire

L’objection qu’on entend le plus souvent quand on propose un site statique : « Mais on a un formulaire, une recherche, une newsletter. » Ajouter un formulaire ou une recherche à un site statique ne demande pas de transformer tout le site en application : chaque besoin se traite à part, page par page.

Ce guide passe en revue les besoins dynamiques les plus courants et la façon de les brancher. Il suppose la décision prise ; si elle ne l’est pas encore, commencez par pourquoi migrer vers un site statique avec Astro.

Où s’exécute le code d’un site statique ?

Un site statique fabrique ses pages au moment de la publication. Ce qui doit réagir à une action du visiteur (envoyer un message, chercher un mot, s’inscrire) est confié à un service dédié, appelé depuis la page.

Avec Astro, la frontière est explicite : par défaut, tout le site est pré-rendu en HTML, et une page précise peut être rendue à la demande avec une seule ligne, export const prerender = false, à condition d’installer un adaptateur pour l’hébergeur. Le reste du site ne change pas.

C’est le cas d’un webhook, l’adresse qu’un service extérieur appelle pour signaler un paiement confirmé ou un message reçu : elle doit exécuter du code à chaque appel, ce qu’aucune page fabriquée à l’avance ne sait faire.

Comment ajouter un formulaire à un site statique ?

Le circuit

Un formulaire de contact sur un site statique fonctionne en trois temps :

1. la page envoie les champs à une petite fonction serveur (une fonction Netlify, un Worker Cloudflare, une fonction Edge Supabase) ;
2. la fonction vérifie les données et les enregistre dans une base ou dans le CRM ;
3. une fois l’enregistrement fait, elle envoie l’email de notification et la confirmation au visiteur.

La règle qui évite de perdre des demandes

L’ordre des étapes 2 et 3 n’est pas un détail. Sur Palmora, un site immobilier que nous opérons pour son agence, les demandes ne passaient d’abord que par l’email, sans garantie : un échec d’envoi était avalé, et le visiteur recevait quand même une réponse de succès. Or une demande qui n’existe que dans un email disparaît sans trace dès que l’envoi échoue, pour un quota atteint ou une adresse mal configurée. Le circuit enregistre désormais chaque demande en base avant d’envoyer le moindre email.

D’où la règle à appliquer partout : la base d’abord, l’email ensuite. Un email qui échoue se renvoie. Une demande jamais enregistrée est perdue.

Les services de formulaires prêts à l’emploi

Plusieurs hébergeurs proposent une gestion de formulaires intégrée : on ajoute un attribut au formulaire HTML, et les envois apparaissent dans une interface. C’est pratique pour un site vitrine qui reçoit peu de demandes. Trois questions à poser avant de s’y fier :

• où les données sont-elles stockées, et peut-on les exporter ?
• les demandes arrivent-elles dans le CRM, ou faut-il les recopier à la main ?
• que se passe-t-il au-delà du quota de l’offre ?

Pour une entreprise qui vit de ses demandes entrantes, nous préférons une fonction qui enregistre la demande, puis la crée dans le CRM. Elle y arrive avec sa source, sans ressaisie.

Contre les robots

Un formulaire public reçoit des envois automatiques. Trois filets simples, tous vérifiés côté serveur : un champ caché que seul un robot remplit, un temps minimum passé sur la page avant l’envoi, et une limite d’envois par heure. Ce sont ceux de l’inscription à la lettre du blog de Challenge Us, une application de défis de groupe que nous avons développée, avec en plus un double opt-in : l’adresse n’est inscrite qu’après un clic dans l’email de confirmation.

Comment ajouter une recherche interne ?

Un index fabriqué à la publication

Une recherche interne n’a pas besoin d’un serveur de recherche. Au moment de la publication, un script parcourt les pages et fabrique un index ; dans le navigateur, un petit programme interroge cet index.

Pagefind, une bibliothèque de recherche entièrement statique, indique pouvoir mener une recherche plein texte sur un site de 10 000 pages avec moins de 300 Ko transférés au total, bibliothèque comprise, et plutôt 100 Ko pour la plupart des sites. Son index est découpé en morceaux, et une recherche n’en charge qu’une petite partie.

Challenge Us a écrit son propre index, en deux fichiers : l’un pour son blog, l’autre pour sa base de connaissances, fabriqués à la publication depuis les mêmes listes que les pages et chargés au premier appui dans le champ, soit environ 130 Ko compressés pour celui du blog en septembre 2026. Les deux approches tiennent sur un hébergement statique, sans service à payer.

Ce qu’il faut prévoir

• Des accents et des majuscules indifférents : « reunion » doit trouver « Réunion ».
• Un extrait qui montre pourquoi le résultat sort. Un titre seul ne suffit pas quand le mot cherché est dans le corps de la page.
• Pas d’adresse par recherche. Si chaque recherche tapée devient une page que les moteurs peuvent explorer, le site se remplit de pages sans contenu propre. La recherche se fait dans la page, sans nouvelle adresse.

Où ranger la liste d’une newsletter ?

L’inscription à une lettre suit le circuit du formulaire. Deux choix comptent :

• Où vit la liste. Elle peut vivre chez un service d’emailing, ou dans votre base, poussée ensuite vers le service. Garder la liste chez soi permet de conserver la preuve du consentement (la phrase cochée, la date, la page) et de changer de service sans perdre personne.
• Le double opt-in. Il protège des inscriptions faites par des robots ou avec l’adresse de quelqu’un d’autre, et c’est la preuve la plus simple que le consentement vient du titulaire de l’adresse.

Et les pages qui changent à chaque visite ?

Certaines pages ne peuvent pas être fabriquées à l’avance : un espace client, un panier, un tableau de bord. Avec Astro, elles sont rendues à la demande, une par une, pendant que le reste du site reste statique. Le coût est celui des fonctions exécutées, un point à surveiller chez l’hébergeur : nous détaillons ce qui est compté selon l’hébergeur.

Quand ces pages deviennent nombreuses et que tout le site dépend de données qui changent dans la journée (un catalogue de biens, des disponibilités), un rendu serveur assumé, avec un cache bien réglé, est plus simple qu’un site statique bricolé. Le statique reste le bon choix tant que l’essentiel des pages change au rythme des publications, pas des visites.

Par où commencer

Faites la liste de tout ce qui doit réagir sur votre site actuel : formulaires, recherche, inscriptions, espace client. Chaque ligne trouve sa place dans un des circuits ci-dessus, et c’est cette liste qui dira ce que l’hébergement devra exécuter et compter.

Si votre site tourne aujourd’hui sous WordPress, Drupal ou Joomla, notre migration vers un site statique part d’un inventaire de vos pages, et compare chaque page à l’ancien site avant la mise en ligne.

Questions fréquentes

Un formulaire sur un site statique est-il moins sûr ?

Non, souvent plus. Il n’y a ni panneau d’administration ni extension à exposer : seule une petite fonction reçoit les données. Elle doit valider chaque champ côté serveur, limiter le nombre d’envois et ne jamais renvoyer d’erreur détaillée au visiteur. Les clés d’accès au CRM ou au service d’emails restent dans la fonction, jamais dans le code de la page.

Peut-on brancher le formulaire directement sur le CRM ?

Oui. La fonction serveur appelle l’API du CRM (Twenty, Odoo, HubSpot ou un autre) et crée le contact ou la demande. Ajoutez à chaque envoi la page d’origine, la langue et les paramètres de campagne (UTM) : sans eux, impossible de savoir quel canal amène les demandes. Et gardez l’enregistrement en base avant l’appel au CRM, pour qu’une panne de celui-ci ne fasse rien perdre.

Faut-il un service payant pour la recherche interne ?

Pas pour un site de quelques centaines ou milliers de pages. Un index fabriqué à la publication suffit, et il est servi comme les autres fichiers du site. Un service dédié se justifie pour un catalogue très volumineux, avec filtres, synonymes et tri par pertinence commerciale, ou quand les résultats doivent suivre un stock qui change dans la journée.

Que se passe-t-il si la fonction du formulaire tombe en panne ?

Les pages restent en ligne, puisque ce sont des fichiers : seul l’envoi échoue. Prévoyez dans la page un message d’erreur clair, avec une adresse email de repli, plutôt qu’un bouton qui tourne sans fin, et une alerte qui vous prévient de la panne. Si c’est le service d’emails qui tombe, la demande déjà enregistrée en base ne se perd pas.

Comment les équipes marketing publient-elles sur un site statique ?

Depuis un éditeur, pas dans le code. Le contenu vit dans des fichiers Markdown ou dans un CMS headless comme Sanity, et chaque publication reconstruit le site, avec un aperçu avant la mise en ligne et un retour possible à la version précédente. Le bon outil dépend de qui publie et à quel rythme : nous le détaillons dans notre article sur Astro et Sanity.