Collecte & intégration
Enregistrer la demande avant de passer le relais.
Au départ…
Un visiteur remplit un formulaire. Une indisponibilité du service suivant ne doit pas faire disparaître sa demande ni lui imposer de recommencer.
Ce que nous avons construit
Une collecte enregistrée dans Supabase, suivie d’une notification HTTP au format stable pour un CRM ou un orchestrateur. La soumission et sa livraison sont deux sujets distincts.
- Vercel
Formulaire
Validation côté serveur
- Supabase
Soumission conservée
La donnée survit à une erreur aval
- Zapier
Relais possible
Qualification et routage vers le CRM
La collecte et le webhook sont documentés ; le relais Zapier est une possibilité d’intégration, à valider sur le Zap réel.
Ce que nous voulons changer
Conserver une trace fiable de la demande et permettre au métier de suivre son traitement.
Comment c’est construitModèle de données, code, contrôles et autonomie des équipes
Parcours utilisateur
- 01
Valider les champs et enregistrer la soumission.
- 02
Notifier le destinataire configuré avec le contexte du formulaire.
- 03
Suivre séparément la livraison et le traitement métier.
Structure des données et des échanges
| Entité / table | Champs clés | Relations |
|---|---|---|
| Configuration des formulaires | Type · validation · destination | Définit le contenu envoyé |
| Soumissions | Formulaire · champs · date de réception | Conserve la demande initiale |
| Références CRM / livraison | Clé de soumission · destination · résultat | Suivi opérationnel proposé |
Implémentation technique
- Le code examiné écrit la demande avant la notification HTTP.
- Le webhook conserve une forme commune entre formulaires et utilise un délai d’expiration.
- Une boîte d’envoi persistante et un mécanisme de reprise sont une évolution recommandée pour les flux critiques, pas une garantie du mécanisme actuel.
Décision d’ingénierie
Borner la notification sans perdre la demande enregistrée
Adapté du helper webhook appelé après l’enregistrement du formulaire. La requête est interrompue après cinq secondes, les échecs HTTP et réseau sont distingués et le minuteur est toujours nettoyé. Cela ne fournit ni file de reprise durable ni preuve de traitement aval. Après un timeout, le destinataire peut avoir reçu la requête sans que sa réponse soit revenue.
type Delivery = | { ok: true } | { ok: false; reason: "disabled" | "timeout" | "http-error" | "network" };export async function notifySavedEnquiry( configuredUrl: string | null, payload: { form_type: string; data: Record<string, unknown> },): Promise<Delivery> { if (!configuredUrl) return { ok: false, reason: "disabled" }; const controller = new AbortController(); const timer = setTimeout(() => controller.abort(), 5_000); try { const response = await fetch(configuredUrl, { method: "POST", headers: { "content-type": "application/json" }, body: JSON.stringify(payload), signal: controller.signal, }); return response.ok ? { ok: true } : { ok: false, reason: "http-error" }; } catch (error) { return { ok: false, reason: error instanceof Error && error.name === "AbortError" ? "timeout" : "network", }; } finally { clearTimeout(timer); }}// URL comes from trusted server configuration, not the visitor's form.// The persisted submission remains the source of truth for follow-up.Extrait adapté de l’implémentation
Contrôles et limites
- Ne transmettre que les champs nécessaires au destinataire.
- Un webhook livré ne prouve pas que le dossier a été traité.
- Le connecteur destinataire et sa reprise doivent être validés avant mise en production.
Qui peut contribuer
- Métier : règles de qualification et affectation.
- Builders : formulaires et mappings approuvés.
- Développeurs : validation, accès, livraison et reprises.
Ce qui documente ce cas
Code de collecte et de notification examiné. Le format prévoit un destinataire de type Zapier, n8n ou CRM ; aucun Zap aval n’a encore été vérifié.