Formulaires Statamic : le classique qui fonctionne

Après collections, navigations, multisite et permissions, on aborde les formulaires — un besoin permanent sur les sites vitrines, landing pages et projets clients.

Statamic permet de :

• créer autant de formulaires que nécessaire dans le Control Panel ;
• définir les champs via un blueprint (comme pour les pages ou collections) ;
• afficher le formulaire en front avec des balises Antlers ;
• envoyer un email et enregistrer chaque soumission ;
• consulter, filtrer et exporter les réponses depuis le CP.

Référence : Forms — documentation Statamic.

Créer un formulaire dans le Control Panel

Dans le menu du CP, section Forms (Formulaires), vous créez un nouveau formulaire — par exemple contact.

Configuration générale

Pour chaque formulaire, vous configurez notamment :

• Envoi d’email : adresse du destinataire (client), copie éventuelle pour les tests ;
• Sujet de l’email ;
• Vue email : template HTML (ou texte) qui récapitule les champs soumis ({{ nom }}, {{ email }}, etc.) ;
• Stockage : enregistrer ou non les soumissions — en fichiers YAML (flat file) ou en base de données (Eloquent), selon votre stack.

Email + stockage : la combinaison recommandée

Mon approche habituelle : les deux.

• le client reçoit un email immédiatement (« vous avez un nouveau contact ») ;
• la soumission est aussi persistée côté Statamic.

Si l’email ne part pas (problème SMTP, spam…), il reste un historique consultable dans le CP. C’est une bonne pratique même hors Statamic sur un projet Laravel classique.

Blueprint du formulaire

Chaque formulaire a son blueprint : la liste des champs à remplir.

Pour un contact classique :

• nom — texte ;
• email — texte (type email) ;
• sujet — texte ;
• message — textarea.

Les types disponibles couvent la plupart des besoins : texte, textarea, select, radio, toggle, fichiers, images, etc. La palette est un peu plus réduite que pour les pages ou collections — logique, on construit un formulaire, pas une page éditoriale.

Vous pouvez aussi réutiliser des fieldsets pour factoriser des groupes de champs récurrents.

Honeypot : piège à robots

Statamic propose un champ honeypot intégré : un faux champ invisible pour les humains, visible pour les bots.

Exemple : un input nommé accept_cgu que l’utilisateur réel ne voit pas. Un robot qui scanne le formulaire le coche — Statamic détecte le spam et rejette la soumission.

Simple, sans service tiers, efficace contre les bots « basiques ». Pour une protection renforcée, on peut ajouter un reCAPTCHA Google en complément (comme dans l’exemple client de la vidéo).

Affichage en Antlers

Le formulaire s’affiche via un template Antlers dédié — par exemple contact.antlers.html.

Les balises Statamic fournissent :

• le handle du formulaire ;
• les messages de succès ou d’erreur ;
• la boucle sur les fields pour générer les inputs dynamiquement.

Boucle sur les champs

L’idée classique : parcourir chaque champ du blueprint et afficher le bon HTML selon le type :

• text → <input type="text"> ;
• textarea → <textarea> ;
• etc.

Les erreurs de validation sont exposées par champ — à afficher sous chaque input.

Honeypot dans le template

Pensez à inclure la balise honeypot dans le formulaire : Statamic injecte automatiquement la clé attendue. Sans elle, la protection ne fonctionne pas.

Ajax (optionnel)

Si votre front est en Vue.js ou autre SPA sans rechargement de page, Statamic gère aussi la soumission en Ajax — pas obligatoire si vous restez en Antlers/Blade classique avec POST traditionnel.

Soumissions dans le Control Panel

Une fois le formulaire actif, chaque envoi apparaît dans le CP sous Forms → [votre formulaire] → Submissions.

Le client peut :

• choisir les colonnes visibles dans la liste (masquer le message complet si trop long, par exemple) ;
• réordonner les colonnes ;
• exporter les soumissions en CSV ou JSON.

Cas réel : festival au Sénégal

Sur un site pour un grand festival de musique (première édition, forte affluence), le formulaire recevait des demandes de volontaires et de prestataires locaux. Au début, le client traitait tout à la main ; très vite, le volume a explosé. L’export CSV vers Excel lui a permis de trier et répondre efficacement — sans développement supplémentaire.

Exemple complet : formulaire contact

Vidéo : formulaires en pratique

• Ouvrir sur YouTube (youtu.be)
• Lien watch sur youtube.com
• Playlist Statamic

FAQ rapide (SEO & technique)

Où sont stockées les soumissions en flat file ?
Dans storage/forms/ (fichiers YAML par soumission), selon la configuration Statamic.

Peut-on n’envoyer que l’email sans stocker ?
Oui, mais conserver les soumissions est recommandé comme filet de sécurité.

Comment personnaliser l’email reçu par le client ?
Via une vue dédiée (HTML ou texte) référencée dans la configuration du formulaire, avec les variables des champs.

Antlers ou Blade pour les formulaires ?
Les deux sont possibles ; la doc et les balises {{ form: }} sont pensées pour Antlers, mais l’équivalent existe côté Blade.

Comment lutter contre le spam ?
Honeypot natif + reCAPTCHA ou service tiers si le volume de bots augmente.

Conclusion

Les formulaires Statamic, c’est du solide : blueprint familier, template flexible, email + historique, export pour le client. Peu glamour, mais indispensable — et bien intégré au reste du CMS.

Clair pour le client, rapide pour le développeur : exactement ce qu’on attend d’un CMS Laravel en fin de parcours de découverte.

Suite de la série : Statamic : version Pro obligatoire ? (gratuit vs payant).