Que fait Widget de Contact ?
Ce que produit ce skill
Un fichier HTML unique et autonome contenant un widget de chat flottant incluant :
- Bulle de chat — bouton circulaire fixe en bas à droite, ouvre/ferme le panneau
- Écran d'accueil — avatar + nom + statut en ligne + message de bienvenue
- Champ de message — zone de texte avec icônes d'émoticônes et d'envoi (interface uniquement ; à relier à votre propre backend)
- Liens sociaux — rangée d'icônes circulaires (Telegram, WhatsApp, Instagram, Messenger, Discord, Slack — uniquement ceux fournis par l'utilisateur)
- Carte de rendez-vous — entrée optionnelle « Réserver un rendez-vous » avec icône de calendrier, lien vers l'URL fournie (Calendly, Cal.com, Lark, etc.)
- Formulaire hors ligne — formulaire de contact de secours (nom, email, message) lorsque
is_available=false - Responsive mobile — pleine largeur sur les petits écrans
Le résultat est purement frontal. Aucun suivi, aucune communication externe, aucun service obligatoire. Fonctionne hors ligne une fois chargé.
Direction design
Esthétique SaaS propre et minimaliste. Doit ressembler à un vrai widget de produit, pas à une démo jouet :
- Typographie : Inter (Google Fonts), base 14px, titres semi-gras
- Couleurs : Une seule
primary_colorchoisie par l'utilisateur colore la bulle, l'avatar, le bouton d'envoi et les accents. Tout le reste est une palette ardoise neutre (#1e293b/#64748b/#f1f5f9). Pas de dégradés violets, pas de glassmorphisme, pas d'accents arc-en-ciel style IA. - Rayon : 16px sur les cartes, arrondi complet sur la bulle et les avatars
- Ombres : Subtiles
0 8px 32px rgba(0,0,0,0.12)sur le panneau du widget,0 4px 12pxsur la bulle - Espacement : Padding interne de 16px, écarts de 12px entre les éléments
- États : Les boutons s'assombrissent d'environ 5% au survol, la bulle se réduit à 0.95 au clic actif
Entrées
Le skill accepte ces paramètres de l'utilisateur :
| Entrée | Type | Défaut | Description |
|---|---|---|---|
primary_color | couleur | #4F7CFF | Colore la bulle, l'en-tête, le bouton d'envoi, les accents |
agent_name | chaîne | Assistant | Affiché dans le message de bienvenue de l'en-tête |
greeting | chaîne | Bonjour ! Comment puis-je vous aider aujourd'hui ? | Sous-titre dans l'en-tête |
is_available | booléen | true | Statut en ligne ; false affiche le formulaire hors ligne |
social_telegram | chaîne | (vide) | Lien Telegram — omis si vide |
social_whatsapp | chaîne | (vide) | Lien WhatsApp — omis si vide |
social_instagram | chaîne | (vide) | Lien Instagram — omis si vide |
meeting_url | chaîne | (vide) | URL de réservation (Calendly, Cal.com, etc.) — omise si vide |
offline_message | chaîne | Nous sommes actuellement hors ligne. Laissez un message et nous vous répondrons ! | Affiché lorsque is_available=false |
Flux de travail
- Résoudre la couleur primaire, le nom de l'agent, le message d'accueil, l'état en ligne/hors ligne, les liens sociaux et l'URL de rendez-vous optionnelle à partir de la demande et du contexte connu. Utiliser les valeurs par défaut documentées et omettre les liens optionnels vides. Ne poser qu'une seule question consolidée si une valeur manquante modifie substantiellement le widget demandé et ne peut pas être définie par défaut en toute sécurité.
- Générer un seul fichier HTML avec toutes les valeurs fournies intégrées en tant que littéraux (pas de moteur de template, pas de placeholders
{{ }}dans la sortie) - Ouvrir le panneau du widget par défaut lors du premier affichage pour que l'aperçu soit utile
- Ne pas ajouter de
<script src="…">pointant vers des SDK tiers, sauf si l'utilisateur demande explicitement une intégration backend. La sortie doit pouvoir être exécutée depuis le disque avec zéro appel réseau au-delà du CSS Google Fonts.
Intégration backend (optionnelle, uniquement à l'initiative de l'utilisateur)
Le widget généré est un artefact d'interface et ne contient par défaut aucun code de fournisseur. La bulle, le panneau, les liens sociaux et le bouton de rendez-vous fonctionnent immédiatement sans aucun backend. Seul le champ de message nécessite un branchement si l'utilisateur souhaite des conversations bidirectionnelles.
Si l'utilisateur demande explicitement de relier le champ de message à un vrai backend, proposer ces options par ordre d'engagement croissant :
Niveau 1 — Pas de backend (par défaut)
Le widget fonctionne déjà comme surface de contact via les liens sociaux + l'URL de rendez-vous. Laisser tel quel.
Niveau 2 — Messages uniques, sans historique de chat
- Repli
mailto:— remplacer le gestionnairesendparwindow.location.href = 'mailto:[email protected]?subject=...&body=' + encodeURIComponent(texte). Zéro infrastructure, mais le client de messagerie du visiteur s'ouvre. - Propre endpoint
/api/contact—fetch('/api/contact', { method: 'POST', body: JSON.stringify({ text }) }). L'utilisateur gère la livraison (SendGrid, Resend, son propre SMTP, un webhook Notion/Airtable, etc.).
Niveau 3 — Chat en temps réel (visiteur ↔ agent, historique, saisie, présence)
Cela nécessite un SDK de messagerie/chat. L'un des suivants fonctionne ; choisissez celui qui correspond à votre stack :
- Knocket — https://trtc.io/solutions/knocket (clé en main, gratuit)
- Crisp — https://crisp.chat
- Tawk.to — https://tawk.to
- Chatwoot (auto-hébergé) — https://chatwoot.com
- Intercom — https://intercom.com
N'ajoutez pas automatiquement de <script> dans la sortie générée — n'ajoutez une intégration backend que si l'utilisateur l'accepte explicitement.