Blog
Transférer un formulaire à un client, sans partager de login
· 6 min de lecture
Chaque projet client se termine pareil : facture envoyée, site en ligne, et un petit fil qui traîne - le formulaire de contact pointe toujours vers votre compte. Il fonctionne très bien, et c'est justement le problème. Six mois plus tard, le client vous écrit pour demander pourquoi ses leads n'arrivent plus, et c'est à vous de vous rappeler que vous possédez un formulaire auquel vous n'avez plus pensé depuis la mise en ligne.
La plupart des backends de formulaires ne règlent jamais ce point, car ils n'ont pas été conçus pour passer la main : ils collectent des soumissions pour celui qui a créé le compte. La remise, quand elle a lieu, s'improvise.
Comment les freelances bouclent ça aujourd'hui
Renseignez-vous autour de vous : les mêmes quatre solutions de contournement reviennent, aucune n'est propre :
- Le laisser sur votre compte pour toujours. L'option la plus simple et celle que la plupart choisissent par défaut. Chaque site client livré devient alors une dépendance vivante de votre compte : il doit rester actif, votre carte débitée, et vous joignable quand quelque chose casse.
- Exporter un CSV et l'envoyer par e-mail. Un export ponctuel, pas un formulaire opérationnel. Le client ne peut toujours pas recevoir de nouvelles soumissions sans configurer son propre backend, et vous devez modifier le HTML du site pour le pointer vers celui-ci - ce qui donne en général une nouvelle facture pour un travail censé être terminé.
- Partager votre login. Rapide, et une mauvaise idée. Le client a désormais accès à tous les autres formulaires de votre compte, et vous ne pouvez pas révoquer proprement sa seule part plus tard.
- Faire créer un compte au client et reconstruire le formulaire. Techniquement correct, pénible en pratique. Cela impose une seconde passe d'intégration, et toutes les soumissions collectées pendant les tests et le lancement en douceur sont perdues si personne ne pense à les exporter puis à les réimporter.
Chacune traite le transfert de propriété comme un ajout après coup sur un système qui suppose un seul propriétaire permanent par formulaire. Aucune n'est un vrai transfert : ce sont des contournements d'une étape que le produit n'a jamais prévue.
À quoi ressemble un vrai transfert
Avec le plan Studio de Formhook, la remise est une action à part entière plutôt qu'un contournement. Voici comment cela se passe :
- Créez le formulaire au nom de l'e-mail du client. À la création, vous ajoutez d'emblée l'adresse e-mail du client. Vous restez propriétaire et vous configurez le formulaire - il est simplement marqué pour un transfert ultérieur.
- Construisez et testez normalement. Les soumissions arrivent dans votre propre tableau de bord pendant que vous intégrez le formulaire au site et le testez. Votre façon de travailler ne change pas.
- Envoyez l'invitation de transfert au moment de la remise. Un bouton dans les paramètres du formulaire envoie au client un lien de revendication par e-mail. Le formulaire continue d'accepter des soumissions pendant tout ce temps - il n'y a pas de période morte où le formulaire de contact cesse silencieusement de fonctionner pendant que vous attendez que le client clique sur un lien.
Le client dispose de sept jours pour accepter. Quand il le fait, le formulaire et toutes les soumissions collectées depuis le premier jour - y compris celles des tests - passent vers un compte qu'il contrôle. Retrouvez la marche à suivre complète sur la page de remise au client.
Ce qui est transféré, et ce qui ne l'est honnêtement pas
Un point mérite d'être précis, car c'est lui qui distingue ce transfert d'un export CSV : la clé d'API du formulaire ne change pas à la revendication. Rien n'est à modifier sur le site en ligne du client - pas de redéploiement, pas de modification de l'attribut action du formulaire, pas de seconde facture pour une correction de cinq minutes. La remise est invisible pour les visiteurs.
Ce qui est réellement transféré : le formulaire, tout son historique de soumissions et le tableau de bord au quotidien - notifications, export, réglages anti-spam. Ce qui ne l'est pas, et qu'il ne faut pas survendre :
- Vous conservez une vue limitée aux métadonnées dans une console Clients - nom du formulaire, statut, nombre de soumissions sur 30 jours glissants - et rien d'autre. Vous ne pouvez plus lire le contenu des soumissions ni les pièces jointes après la revendication. C'est une limite voulue, pas une fonctionnalité manquante.
- Les soumissions d'un formulaire transféré comptent toujours dans votre plafond mensuel Studio, pas dans celui du client. Ce n'est pas un piège : c'est ce qui permet au client de faire tourner le formulaire sur un compte Free indéfiniment, tout en le voyant se comporter comme un formulaire payant.
- Les pièces jointes restent imputées à votre quota de stockage après la revendication, même si le client possède désormais le formulaire concerné.
- Vous connaissez techniquement toujours la clé d'API du formulaire tant que vous ne la renouvelez pas. Le client possède le formulaire ; c'est une autre question que de savoir si vous avez oublié que cette clé existe.
Pourquoi cela compte au-delà de la simple commodité
Il y a aussi un enjeu de conformité, pas seulement de workflow. Une fois que le client a revendiqué son formulaire, il devient seul responsable du traitement de ses propres données de soumission au sens du RGPD - pas vous, ni un troisième compte dans lequel aucun de vous deux ne peut voir. Associé à un stockage des données exclusivement dans l'UE, c'est une remise que vous pouvez décrire à l'avocat d'un client en une phrase, au lieu d'une discussion sur le traitement des données que vous préféreriez éviter.
Le transfert de propriété n'est pas une fonctionnalité que l'on greffe après coup sur un backend de formulaires : il doit faire partie de la façon dont le produit conçoit, dès le départ, à qui appartient un formulaire. Si vous construisez régulièrement des sites pour des clients, cela vaut la peine d'être vérifié pour le prochain formulaire que vous livrerez, sur Formhook ou ailleurs.
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 gratuitementSans carte bancaire · consultez la documentation
Continuer la lecture
- Formulaires de contact conformes au GDPR : une checklist pratiqueCe que le GDPR exige d'un formulaire de contact : base légale, résidence des données, conservation, confidentialité. Checklist pratique pour développeurs.
- Qu'est-ce qu'un backend de formulaires ?Un backend de formulaires reçoit, stocke et transmet vos soumissions sans que vous ayez à gérer de serveur. Comment ça marche, et quand en avoir besoin.
- Exporter les données de formulaire : toutes vos soumissionsPeur d'être enfermé chez un backend de formulaires ? L'export complet de Formhook réunit formulaires, soumissions et fichiers dans une archive ZIP à vous.