Les tests KYB consistent à s’assurer qu’un flux de vérification d’entreprise se comporte correctement avant de rencontrer un vrai demandeur. KYB signifie Know Your Business, et le nom désigne la différence qui compte : le sujet vérifié est une organisation, non une personne, et une organisation comporte des strates — propriétaires, contrôleurs, immatriculations, documents — qu’un contrôle d’identité personnel n’a jamais à gérer.
Cet article expose ce que vérifie réellement un flux KYB, pourquoi la vérification d’une entreprise est plus difficile que la vérification d’une personne, comment le rejet et la révision devraient se comporter, et comment tester l’ensemble sans affaiblir les contrôles que vous testez.
Que vérifie réellement un flux KYB ?
Il vérifie que l’organisation est réelle, qu’elle est ce qu’elle prétend être, et que les personnes qui la dirigent sont bien celles qu’elles disent être. Un contrôle d’identité personnel répond à la question « cette personne est-elle bien celle qu’elle prétend » ; un contrôle d’entreprise pose la même question à propos d’une entité, puis y ajoute une seconde question sur les humains qui la contrôlent.
Un flux typique rassemble donc plusieurs types de preuves, et les exigences précises dépendent de la juridiction et du régulateur auquel l’entreprise qui s’inscrit répond. En termes généraux :
- Existence — la preuve que l’entité est immatriculée, tirée du registre de son pays de constitution.
- Identification — le numéro d’immatriculation et tout identifiant fiscal ou de TVA que l’entité détient.
- Localisation — la preuve de l’adresse enregistrée, et parfois aussi d’une adresse d’exploitation.
- Propriété et contrôle — les personnes qui possèdent ou contrôlent en dernier ressort l’entité.
- Activité — ce que l’entreprise fait réellement, et toute licence ou autorisation que cette activité exige.
- Représentation — la confirmation que la personne qui soumet est habilitée à agir pour l’entité.
Aucun de ces points n’est une formalité, et aucun ne peut être déduit d’un autre. Une société immatriculée peut avoir une propriété opaque, une licence peut être détenue mais expirée, et la personne qui remplit le formulaire n’est fréquemment pas un dirigeant.
Pourquoi vérifier une entreprise est-il plus difficile que vérifier une personne ?
Trois raisons structurelles, qui se manifestent toutes comme des défauts lors des tests.
La première est l’empilement. Une personne est un sujet unique avec une identité unique. Une entreprise peut être détenue par une autre société, elle-même détenue par une fiducie, administrée dans un troisième pays. Le flux doit suivre cette chaîne assez loin pour identifier les humains qui se trouvent à son extrémité, et « assez loin » est un jugement plutôt qu’un nombre fixe de sauts.
La deuxième est que la preuve est distribuée. Les documents d’identité personnels proviennent d’une seule autorité dans un seul pays. Les preuves d’entreprise proviennent d’un registre ici, d’une administration fiscale là, et d’une banque ailleurs, en plusieurs langues, avec différentes périodes de validité et différents degrés d’accessibilité publique.
La troisième est que la vérification n’est pas un événement unique. La propriété change, les adresses changent, les licences expirent, les entités sont renommées ou restructurées. Une entreprise qui a passé la vérification une année peut présenter un tableau sensiblement différent l’année suivante.
Que doit soumettre le demandeur ?
Cela dépend de la juridiction et du profil de risque appliqué par l’institution vérificatrice, mais un ensemble représentatif d’exigences ressemble à ceci.
| Exigence | Ce qu’elle établit | Notes pour les testeurs |
|---|---|---|
| Certificat de constitution ou équivalent | Que l’entité existe et que son nom et son numéro sont conformes à ce qui est déclaré | Souvent accompagné d’un extrait récent du registre |
| Preuve d’immatriculation fiscale ou de TVA | L’identité fiscale de l’entité | Peut ne pas exister pour toute entreprise légitime |
| Preuve d’adresse enregistrée | Où l’entité est officiellement située | Une facture de services publics ou un extrait de registre, selon le pays |
| Informations sur la propriété ou le contrôle | Qui possède ou contrôle en dernier ressort l’entité | La partie la plus difficile à modéliser et à tester |
| Documents d’identité des contrôleurs | Que les personnes sont réelles | Déclenche un contrôle personnel distinct |
| Licence ou autorisation | Qu’une activité réglementée est autorisée | Absente pour la plupart des entreprises non réglementées |
L’observation d’ingénierie cruciale se trouve dans la dernière colonne des lignes du milieu : plusieurs de ces éléments sont facultatifs d’une manière légitime plutôt qu’incomplète. Une entreprise sans immatriculation à la TVA n’est pas un demandeur défectueux, et un flux qui traite l’absence comme un échec rejettera une large part du marché réel.
Comment le rejet et la révision devraient-ils se comporter ?
Comme des états ordinaires et attendus plutôt que comme des erreurs terminales. Un flux de vérification qui ne peut se terminer que par une approbation ou une impasse est un flux qui sera contourné par les personnes qui l’exploitent, et contourner un contrôle est la façon dont on perd le contrôle.
Concevez les résultats séparément. Un rejet fondé sur des éléments documentés — un document qui ne correspond pas au registre, par exemple — est révisable et susceptible de recours. Une demande d’informations complémentaires est un état reprenable qui conserve tout ce qui a déjà été soumis. Une file de révision manuelle est un résultat légitime, non un échec de l’automatisation. Et tout rejet devrait porter un motif assez précis pour être exploitable, parce que « vérification échouée » ne donne au demandeur rien à corriger et à l’équipe de support rien à expliquer.
Deux propriétés transforment ces états de la théorie en un flux praticable. Les motifs de rejet devraient être un vocabulaire contrôlé, afin qu’ils puissent être comptés, routés et traités de façon cohérente. Et une demande rejetée devrait être reprenable : le demandeur corrige un document, pas toute la soumission.
Ce qui ne doit pas arriver, c’est un raccourci de test qui désactive les contrôles. Désactiver les contrôles de sanctions, de propriété ou de documents pour faire passer un test produit un système dont les défaillances sont invisibles jusqu’à ce qu’elles deviennent coûteuses.
Pour les développeurs : états, preuves et conservation
Modélisez le flux comme une machine à états explicite — non démarré, soumis, en révision, en attente d’informations, approuvé, rejeté — avec des transitions enregistrées, des horodatages et l’acteur responsable pour chacune. Un champ de statut qui est une chaîne de texte libre dérivera en un mois, et la dérive est invisible jusqu’à ce que quelqu’un tente d’en faire un rapport.
La preuve nécessite son propre modèle. Chaque document soumis devrait porter un type, un émetteur ou un pays, la date à laquelle il a été délivré et une date d’expiration le cas échéant, parce qu’une licence expirée n’est pas une preuve même si le fichier est toujours là. Séparez les métadonnées du document du fichier lui-même afin que les règles de conservation puissent agir sur les métadonnées sans toucher au contenu.
La propriété effective ultime est la partie que les équipes sous-estiment. Modélisez-la comme un graphe — entités et personnes comme nœuds, propriété et contrôle comme arêtes — même si l’interface ne montre jamais que deux niveaux. L’aplatir en quelques champs de nom rend les données inutilisables la première fois qu’une structure de propriété doit être revérifiée.
La conservation et l’isolement sont les autres impératifs non négociables. Les preuves de vérification comptent parmi les éléments les plus sensibles qu’une entreprise détient, alors gardez les environnements de test exempts de vrais documents et de vrais demandeurs, et gardez les données de production entièrement hors des bases de données de test. Les entités synthétiques produites par le générateur de données d’entreprise sont la bonne entrée pour répéter ce flux : elles ne décrivent aucune entreprise réelle, et l’article sur les limites des données d’entreprise synthétiques explique pourquoi cela compte lorsqu’une capture d’écran ou un export s’échappe de son environnement. La mécanique plus large des enregistrements d’entreprise synthétiques est couverte dans données d’entreprise de test.
Prochaines étapes
Notez par écrit chaque état dans lequel votre flux de vérification peut se trouver, puis vérifiez si chacun est atteignable dans un environnement de test et s’il porte un message exploitable pour le demandeur. Tout état qui ne peut pas être atteint en test est un état qui sera atteint pour la première fois en production. Répétez ensuite le flux de bout en bout avec une entreprise générée par le générateur de données d’entreprise et confirmez qu’aucune étape ne vous oblige à désactiver un contrôle pour aller au bout.