Un générateur de données d’entreprise produit l’ensemble des champs qu’un formulaire d’onboarding d’entreprise demande — une dénomination sociale avec le bon suffixe pour sa juridiction, un numéro d’immatriculation, un identifiant fiscal, une adresse, et souvent une forme juridique et un contact — agencés de manière que les parties s’accordent entre elles. La difficulté n’est pas d’inventer un nom d’entreprise ; c’est de faire tenir une douzaine d’identifiants interdépendants en cohérence avec une seule juridiction.
Ce guide couvre la façon dont les conventions de dénomination des sociétés changent d’un pays à l’autre, pourquoi les numéros d’immatriculation et fiscaux suivent des règles différentes de ce que la plupart des équipes attendent, quels champs un parcours KYB requiert réellement, et à quoi une entité générée ne pourra jamais servir. À la fin, vous saurez quels contrôles de cohérence appartiennent à votre propre suite de tests et quelles hypothèses sur les données d’entreprise sont tout simplement fausses.
Pourquoi les noms d’entreprise portent-ils la juridiction dans leur suffixe ?
Le suffixe à la fin d’un nom d’entreprise n’est pas décoratif. Il identifie la forme juridique sous laquelle l’entité existe, et il est obligatoire dans la plupart des juridictions. Une société à responsabilité limitée allemande porte GmbH, une société française ou espagnole peut porter S.A. ou S.A.S., une société malaisienne porte Sdn. Bhd., une société australienne à responsabilité limitée porte Pty Ltd, une société américaine à responsabilité limitée porte LLC, et une société anonyme turque porte A.Ş.
Parce que le suffixe encode la forme juridique, il contraint aussi le reste de l’enregistrement. Une entité avec un suffixe GmbH est régie par le droit allemand des sociétés, donc son numéro d’immatriculation suit le schéma allemand, son identifiant fiscal suit le schéma allemand, et son adresse se situe en Allemagne. Un enregistrement qui mélange un suffixe allemand avec un numéro d’immatriculation britannique n’est pas subtilement faux ; il décrit une société qui ne peut pas exister.
La ponctuation et les diacritiques ajoutent une seconde couche. Plusieurs suffixes contiennent des points, certains contiennent des caractères accentués, et certains s’écrivent par convention sans espaces. Un champ de nom qui supprime la ponctuation à la saisie corrompra une dénomination sociale, et un validateur qui attend une seule liste de suffixes rejettera ceux qu’il n’a jamais vus. L’article sur les suffixes de noms d’entreprise par pays rassemble les formes courantes et leurs conventions.
En quoi les numéros d’immatriculation et les identifiants fiscaux diffèrent
Un numéro d’immatriculation est émis par le registre des sociétés d’une juridiction précise. Sa longueur, son format et le fait qu’il contienne des lettres varient tous. Certains registres utilisent une séquence purement numérique, certains intègrent une année ou un district, et certains émettent une chaîne alphanumérique. Il n’existe aucune norme internationale qui rende ces numéros interchangeables, et un système qui les stocke dans un seul champ avec une seule règle de validation rejettera des saisies valides de la majeure partie du monde.
Un identifiant fiscal est un numéro différent émis par une autorité différente, et confondre les deux est l’une des erreurs de modélisation les plus courantes dans les systèmes d’onboarding. Dans de nombreux pays, une entreprise possède à la fois un numéro d’immatriculation et un numéro fiscal, ils ont des formats différents, et ils figurent dans des champs différents d’un formulaire. Un enregistrement qui remplit les deux champs avec la même valeur est incohérent, même si chaque valeur est plausible isolément.
L’identifiant de TVA ajoute une troisième variante. Au sein de l’Union européenne, il commence généralement par un préfixe de pays à deux lettres suivi du numéro fiscal national, et le préfixe doit correspondre au pays de l’adresse et de l’immatriculation. L’article sur les formats de numéro de TVA par pays montre l’éventail des formes concernées, et l’article sur les règles de validation des identifiants fiscaux couvre les contrôles qui les distinguent.
Qu’en est-il des identifiants LEI et D-U-N-S ?
L’identifiant d’entité légale (LEI) est un code alphanumérique de vingt caractères attribué aux entités qui participent à des transactions financières, et il est globalement unique. Ce n’est pas un numéro d’immatriculation et il n’en remplace pas un ; c’est un identifiant supplémentaire qu’une contrepartie financière peut demander. Sa structure comprend un préfixe d’unité opérationnelle locale, une section réservée, et deux chiffres de contrôle calculés selon une norme publiée.
Le numéro D-U-N-S est un identifiant à neuf chiffres émis par un fournisseur de données commercial, largement utilisé dans les évaluations de crédit et de fournisseurs. Ce n’est pas un identifiant gouvernemental, et il n’existe que pour les entités que ce fournisseur a enregistrées. Le traiter comme obligatoire dans un formulaire exclura la plupart des entreprises de la plupart des pays.
Les deux identifiants valent la peine de figurer dans un jeu de données de test car leurs règles de longueur et de caractères sont distinctives, et parce que leur présence dans un formulaire change le chemin de validation. Mais un générateur devrait préciser si le LEI qu’il produit satisfait la somme de contrôle publiée, car un LEI bien formé en apparence mais doté d’une mauvaise clé de contrôle échouera exactement au point que vous cherchiez à tester. L’article sur les identifiants d’entreprise examine les deux plus en profondeur.
Quels champs rendent un dossier KYB cohérent
Un parcours de connaissance de l’entreprise demande la dénomination sociale d’une entité, sa juridiction et sa forme juridique, son adresse enregistrée, son numéro d’immatriculation, son identifiant fiscal, ses représentants, et souvent sa structure de propriété. L’exigence de cohérence est que ces champs décrivent une seule entité en un seul endroit.
Cela signifie que la juridiction régit la convention de dénomination, le format du numéro d’immatriculation et le format du numéro fiscal. L’adresse enregistrée se situe dans le même pays, et si elle se situe dans une subdivision, le code postal doit correspondre à cette subdivision. Les représentants portent des noms et des adresses appropriés à la juridiction, et la date de constitution précède tout document que l’entité signe. Les deux numéros sont des faits distincts et un formulaire qui les confond acceptera un identifiant fiscal dans le champ d’immatriculation, ce qui est un défaut qui n’apparaît que lorsqu’une juridiction utilise le même pour les deux. L’article sur le numéro d’immatriculation d’entreprise par pays énumère les formats qu’un contrôle de cohérence doit imposer.
La cohérence a aussi une direction. Changer la juridiction devrait entraîner tous les champs dépendants avec elle, de sorte qu’un test qui bascule le pays sur un enregistrement existant teste plus qu’une étiquette. En pratique, la plupart des formulaires ne le font pas, et un numéro d’immatriculation périmé est laissé sous le nouveau pays, ce qui est exactement le genre de défaut qu’un jeu de données cohérent fait remonter en une exécution plutôt qu’en production.
Le champ qui casse le plus souvent la cohérence est l’adresse, car c’est celui que les équipes réutilisent d’un enregistrement de personne sans ajuster le pays. Une société allemande avec un code postal britannique est un défaut évident qu’un validateur imbriqué intercepte immédiatement, et la même logique s’applique à l’indicatif téléphonique du pays sur l’enregistrement de contact. L’article sur la liste de contrôle des tests KYB expose les contrôles dans l’ordre où un vrai pipeline d’onboarding les applique.
Il existe aussi un ensemble de champs que beaucoup de systèmes ajoutent et qui n’ont aucun format universel : le nombre de salariés, le chiffre d’affaires annuel, la classification sectorielle et le site web. Ceux-là sont libres ou fondés sur une classification, et un jeu de données de test devrait les faire varier délibérément plutôt que de laisser chaque entité générée identique en taille et en secteur. Les faire varier importe parce qu’une logique de validation qui ne rencontre jamais une valeur inhabituelle est une logique de validation qui n’a jamais été exercée.
Les entreprises générées sont-elles des entités réelles
Non. Une entreprise générée possède une dénomination sociale avec un suffixe valide, un numéro d’immatriculation au bon format, un identifiant fiscal au bon format et une adresse dans le bon pays, et rien de tout cela n’est enregistré nulle part. Il n’y a aucun dépôt derrière le numéro d’immatriculation, aucun dossier fiscal derrière l’identifiant, et aucune entité derrière le nom.
C’est cette propriété qui rend les données sûres à utiliser. Parce que la société n’existe pas, aucun tiers ne peut être lésé par l’enregistrement, aucun crédit ne peut être accordé sur sa base, et aucune contrepartie ne peut être induite en erreur si l’enregistrement est clairement étiqueté. Cela signifie aussi que tout contrôle qui consulte un registre échouera, ce qui est le résultat correct et devrait être le comportement attendu dans un test. Un nom d’entreprise généré devrait donc aussi éviter d’entrer en collision avec un nom réel, et la sauvegarde la plus simple est de garder les noms générés manifestement génériques plutôt que suffisamment plausibles pour être recherchables.
La frontière mérite d’être énoncée clairement dans le jeu de données lui-même. Les enregistrements de ce type sont des données d’entreprise synthétiques, ils ne correspondent à aucune entité enregistrée, et ils ne doivent pas servir à ouvrir un vrai compte, à franchir un vrai contrôle KYB ou de crédit, à obtenir des biens ou services à crédit, à envoyer des paiements sous un faux nom, ni à représenter une entreprise réelle.
Lorsqu’une entreprise générée est combinée avec une personne générée comme représentant, l’enregistrement entier reste synthétique, et la même interdiction s’applique à la combinaison. Un enregistrement ne devient pas utilisable pour une vraie transaction parce qu’il est cohérent ; la cohérence interne est une propriété de test, et rien de plus.
Que devraient couvrir vos tests de formulaires B2B
Testez d’abord l’appariement entre juridiction et forme juridique, car il pilote tout le reste. Sélectionnez un pays, confirmez que les formes juridiques proposées sont celles que ce pays reconnaît, et confirmez que le suffixe du champ de nom est validé par rapport à la sélection plutôt que laissé libre.
Testez le champ du numéro d’immatriculation contre plusieurs pays dans la même exécution, avec une valeur de la bonne longueur et une valeur trop courte. C’est là qu’une règle unique codée en dur se révèle, car le champ rejettera le numéro étranger valide plutôt que le numéro local invalide.
Testez l’identifiant fiscal comme un champ séparé avec ses propres contrôles, y compris le préfixe de pays là où il est attendu, et confirmez que le formulaire refuse un numéro dont le préfixe contredit le pays sélectionné. L’article sur les cas de test du formulaire de facturation étend cela aux parties du parcours proches du paiement, là où l’enregistrement d’entreprise rencontre une facture.
Testez aussi l’ordre dans lequel les champs sont présentés, car un formulaire global unique impose une séquence à toutes les juridictions et cette séquence est fausse quelque part. Un champ obligatoire dans un pays et dénué de sens dans un autre sera marqué requis pour les deux, et la friction qui en résulte est un défaut que les utilisateurs signalent comme une confusion plutôt que comme un bug. L’article sur les formes juridiques par juridiction cartographie les appariements pays et forme juridique qu’une matrice de tests devrait couvrir.
Testez ensuite les champs libres. Une dénomination sociale avec une esperluette, un nom contenant un point issu d’un suffixe abrégé, un nom à la limite de longueur et un nom dépassant d’un caractère couvrent ensemble la plupart des façons dont un champ de nom casse. Le générateur d’entreprises de ce site produit des enregistrements dans ces juridictions en gardant les identifiants cohérents, afin qu’une seule ligne exportée puisse servir de fixture cohérente plutôt que d’être assemblée à la main.
Chaque enregistrement produit de cette manière est une donnée de test synthétique réservée au test logiciel. Il ne décrit aucune entité enregistrée ni en activité, il ne confère aucune existence juridique, et il ne doit pas servir à usurper l’identité d’une entreprise, à ouvrir ou enregistrer de vrais comptes, à obtenir du crédit ou des biens, ni à franchir une vraie vérification d’entreprise.