Blog

Comment ajouter un formulaire de contact à GitHub Pages

27 mai 2026 · 3 min de lecture

GitHub Pages ne sert que des fichiers statiques - pas de PHP, pas de code serveur, aucun moyen de recevoir un POST de formulaire. Un formulaire de contact a donc besoin d'un endpoint externe vers lequel envoyer les données. Voici les trois vraies options, et la version qui prend une minute.

Option 1 : un backend de formulaires (recommandé)

Pointez l'action de votre formulaire vers un endpoint de formulaire hébergé :

<form action="https://formhook.app/f/fh_your-key" method="POST">
  <label>Email <input type="email" name="email" required></label>
  <label>Message <textarea name="message" required></textarea></label>
  <button type="submit">Send</button>
</form>

Commit, push, terminé. Les soumissions arrivent dans un tableau de bord et sonnent sur votre téléphone via une notification push. Le spam est filtré par un honeypot et des limites de débit avant même de vous atteindre. Cela fonctionne à l'identique pour les dépôts HTML classiques et les sites Jekyll (le générateur natif de GitHub Pages - voir le guide Jekyll pour un include avec thème, ou le guide HTML classique).

Avantages : un seul attribut, aucun JavaScript requis, spam géré, soumissions stockées.
Inconvénients : c'est un service tiers - vérifiez donc les limites du niveau gratuit et la politique de conservation de celui que vous choisissez. Le niveau gratuit de Formhook conserve les soumissions indéfiniment.

Option 2 : un lien mailto:

<a href="mailto:you@example.com">Email me</a>

Honnête mais faible : cela suppose que le visiteur ait un client mail configuré (de moins en moins vrai sur ordinateur), expose votre adresse aux robots collecteurs, ne vous offre aucune protection anti-spam, et ne vous dit rien sur le taux d'abandon. Très bien pour un README de projet perso ; coûteux pour tout ce où les demandes de contact valent de l'argent. (Plus de détails sur ce compromis dans mailto vs formulaire de contact.)

Option 3 : une fonction serverless ailleurs

Vous pouvez garder le site sur GitHub Pages et recevoir le POST avec un Cloudflare Worker ou équivalent. Ça fonctionne - mais vous devez maintenant écrire et maintenir le récepteur : validation, filtrage anti-spam, stockage, envoi d'e-mails, et CORS. Vous avez réintroduit exactement le backend que GitHub Pages vous permettait d'éviter. Raisonnable si ça vous plaît ; superflu sinon.

L'amélioration AJAX (facultative)

Le formulaire HTML classique quitte la page à la soumission. Pour rester sur la page :

<script>
document.querySelector("form").addEventListener("submit", async (e) => {
  e.preventDefault();
  const res = await fetch(e.target.action, {
    method: "POST",
    body: new FormData(e.target),
    headers: { Accept: "application/json" },
  });
  e.target.outerHTML = res.ok
    ? "<p>Thanks - message sent.</p>"
    : "<p>Something went wrong. Please email us directly.</p>";
});
</script>

Aucune étape de build, aucune dépendance - cela fonctionne dans un dépôt GitHub Pages brut.

Remarque sur les domaines personnalisés

Si votre site Pages tourne sur un domaine personnalisé, assurez-vous que les paramètres par formulaire de votre service (comme une liste blanche CORS) incluent ce domaine, et pas seulement username.github.io. Dans Formhook, c'est un seul champ dans les paramètres du formulaire.

Voilà toute l'histoire : GitHub Pages gère votre site, un endpoint de formulaire gère la seule chose qu'il ne peut pas faire. Commencez gratuitement et le formulaire sera en ligne avant même que votre prochain git push ne se termine.

Mettez en ligne un formulaire fonctionnel en une ligne

Hébergé dans l'UE, soumissions conservées indéfiniment, notifications push sur tous les niveaux.

Commencer gratuitement

Sans carte bancaire · consultez la documentation