Coordonnées bancaires, pièce d'identité : pourquoi votre formulaire n'est pas le bon endroit

Un PDF signé, puis ressaisi à la main

Une équipe qui met en place un prélèvement automatique récupère les coordonnées bancaires de ses clients par un PDF envoyé en signature électronique, avant de les ressaisir manuellement dans l'outil de paiement. Ce circuit fonctionne, au sens où il produit le résultat attendu. Il fonctionne aussi mal, au sens où chaque IBAN passe par une étape de recopie humaine entre deux systèmes, avec le risque d'erreur de frappe que ça suppose sur une donnée qui déclenche ensuite un prélèvement réel sur un compte réel.

Le prestataire de paiement propose pourtant, depuis le début, un lien hébergé : le client saisit directement ses coordonnées sur une page sécurisée du prestataire, sans passer par l'équipe interne. La suggestion est accueillie avec une hésitation prévisible : « ça ajoute une étape », « on préfère rester sur notre document actuel ». Cette hésitation, presque réflexe, mérite d'être questionnée avant d'être suivie.

Cette situation se répète sur presque toutes les intégrations qui touchent à une donnée sensible : un outil d'authentification propose une page de connexion déjà sécurisée, une plateforme de facturation propose une capture de moyen de paiement déjà conforme, et l'équipe interne, par habitude ou par souci de continuité visuelle, préfère garder son propre écran et faire suivre l'information ensuite. Le nombre d'outils SaaS connectés à un système d'information augmente chaque année, et chacun de ces points de contact reproduit la même question sans qu'elle soit jamais posée explicitement.

Le réflexe « on reste sur notre formulaire »

Garder la capture d'une donnée sensible sur un support interne, PDF, formulaire maison ou document Word, procure un sentiment de contrôle qui ne correspond à aucun contrôle réel. L'équipe croit maîtriser le parcours parce qu'elle en possède le support. En pratique, elle porte surtout la responsabilité de la validité de la donnée, sans les outils de contrôle qu'un prestataire spécialisé a construits précisément pour ce cas : validation du format d'un IBAN, vérification qu'un mandat existe déjà, alerte en cas de doublon.

Ce que le formulaire maison ne fait jamais aussi bien

Un lien hébergé par un prestataire spécialisé dans le paiement ou l'identité embarque, par construction, des contrôles qu'un formulaire interne ne reproduira jamais au même niveau, simplement parce que ce n'est pas le métier de l'équipe qui l'a conçu. Le lien peut être pré-rempli avec les métadonnées déjà connues du client, valider le format en temps réel, et refuser une saisie incohérente avant qu'elle n'entre où que ce soit dans le système. Le formulaire maison, lui, se contente le plus souvent de collecter un texte libre, à valider ou corriger après coup.

La différence ne se voit pas tout de suite, elle se voit au premier incident : un IBAN mal recopié, un mandat signé sans être rattaché à la bonne référence contractuelle, une pièce d'identité floue qu'il faut redemander. Chacun de ces incidents coûte un aller-retour avec le client, et un aller-retour sur une donnée bancaire ou identitaire abîme la confiance bien plus qu'un simple email de relance sur une facture.

La question de la responsabilité, pas seulement de la sécurité

Le sujet dépasse la seule sécurité technique. Une entreprise qui conserve une donnée bancaire ou une pièce d'identité dans ses propres systèmes en porte la responsabilité juridique en cas de fuite ou d'erreur, même si cette donnée ne lui sert plus à rien une fois transmise au prestataire qui l'exploite réellement. Conserver une donnée qu'on n'exploite pas soi-même ajoute un risque sans ajouter de valeur : c'est un arbitrage que peu d'équipes formulent explicitement avant de choisir, par défaut, de tout garder en interne.

Capturer, pas ressaisir

Chez Leando, ce principe s'appelle capturer, pas ressaisir : quand un prestataire SaaS propose un mécanisme validé pour collecter une donnée sensible, l'utiliser directement plutôt que de la faire transiter par un support interne qui devra ensuite la retranscrire. Le principe ne dit pas que le lien hébergé est automatiquement la bonne réponse dans tous les cas, il dit que le réflexe de le refuser par habitude mérite d'être remplacé par un test concret. Le prestataire a construit ce mécanisme pour un volume de clients bien supérieur au vôtre, sur une donnée où l'erreur coûte cher : il a très probablement déjà résolu des problèmes que votre formulaire maison n'a pas encore rencontrés.

« GoCardless, ils disent que c'est possible que vous stockiez les coordonnées bancaires chez nous. Le truc, c'est que pour l'injection, on va devoir les stocker nous-mêmes. Donc du coup on ne délègue plus le stockage, on délègue le paiement. En fait on délègue que la partie prélèvement. »

Cette distinction entre déléguer le stockage et déléguer seulement l'exécution est au cœur du principe. Un prélèvement peut être exécuté par un prestataire sans que la donnée bancaire ne transite jamais par vos propres systèmes, ce qui vous retire une responsabilité de sécurité sans vous retirer le contrôle du processus métier qui l'entoure : à qui envoyer le lien, à quel moment, avec quel rappel en cas d'échec.

Isoler ces questions dans un bloc à part, plutôt que de les traiter au fil de l'eau au milieu des autres sujets de conception, change la nature de la discussion. Ce n'est plus une question de préférence d'interface, c'est un arbitrage explicite sur qui porte quelle donnée, à quel moment du parcours, et pourquoi. Une fois posée sous cette forme, la réponse penche presque toujours du côté de la délégation, parce que l'alternative, garder la donnée en interne sans le mécanisme de contrôle du prestataire, n'a jamais vraiment été un choix assumé, juste une habitude jamais interrogée.

Ce que ce principe exclut

Capturer, pas ressaisir ne signifie pas déléguer aveuglément toute donnée à tout prestataire sous prétexte qu'un lien existe. Certaines données restent légitimement internes, notamment quand la réglementation ou un contrat impose que vous conserviez la trace vous-même, ou quand la donnée sert à un usage métier que le prestataire ne couvre pas. Le principe se réserve aux cas où la donnée capturée ne sert, in fine, qu'au prestataire lui-même pour exécuter sa propre prestation : un IBAN pour un prélèvement, un document d'identité pour une vérification réglementaire, des informations de carte pour un paiement.

Il exclut aussi de trancher sans mesurer. Le passage d'un support interne à un lien hébergé introduit un changement d'expérience pour le client, une étape supplémentaire ou une interface différente, dont l'effet réel sur la conversion ne se devine pas, il se teste. Un test A/B sur un flux limité suffit en général à objectiver la discussion, bien mieux qu'un débat d'intuitions entre équipes. Pour approfondir la manière de cadrer une intégration technique avant de s'engager dessus, notre article sur les pièges d'une intégration API détaille les questions à poser avant de coder quoi que ce soit.

Le coût invisible de la ressaisie manuelle

La ressaisie d'une donnée sensible entre deux systèmes n'apparaît jamais comme une ligne de coût identifiée, elle se dilue dans le temps d'une personne qui « fait aussi ça » entre deux tâches. C'est exactement le mécanisme que notre article sur le coût réel de la ressaisie chiffre sur une PME de cinquante salariés : une charge invisible dans les comptes, mais bien réelle dans le temps disponible de l'équipe. Sur une donnée bancaire ou identitaire, cette charge s'accompagne en plus d'un risque d'erreur dont la correction implique directement le client, ce qui n'est pas le cas d'une ressaisie interne classique.

Le paradoxe tient en une phrase : l'équipe qui refuse le lien hébergé par souci de qualité de service obtient, en pratique, une qualité de service inférieure. Le client remplit un document, attend une confirmation, puis découvre parfois plusieurs jours plus tard qu'une erreur de saisie a bloqué son prélèvement, alors qu'un lien direct aurait validé l'information au moment même où il la tapait. Le détour censé protéger l'expérience client est souvent celui qui la dégrade le plus.

Cette semaine, listez les données sensibles que votre équipe recopie encore d'un support interne vers un outil externe, et vérifiez, pour chacune, si ce prestataire propose déjà un mécanisme de capture directe que vous n'utilisez pas encore. La documentation technique du prestataire suffit en général à répondre en moins d'une heure, bien avant qu'il ne soit nécessaire de solliciter qui que ce soit en interne pour trancher.