La validation d’un identifiant fiscal est la pratique consistant à contrôler un identifiant fiscal avant qu’il ne soit stocké, facturé ou déclaré — et c’est aussi le champ où les attentes sont le plus souvent placées trop haut. Un contrôle bien conçu empêchera des chiffres transposés d’entrer dans votre base de données. Il ne vous dira pas si l’entreprise existe, si le numéro a jamais été délivré, ni si la société qui se trouve derrière a droit à quoi que ce soit.
Cet article explique ce qu’est un identifiant fiscal, pourquoi certains formats peuvent être contrôlés arithmétiquement et d’autres non, comment construire la validation par couches afin que chaque couche réponde à une question à laquelle elle peut réellement répondre, et pourquoi un contrôle échoué ne doit jamais être signalé comme une société manquante.
Qu’est-ce qu’un identifiant fiscal ?
C’est l’identifiant qu’une administration fiscale attribue à un contribuable. Telle est la définition entière, et elle est délibérément large, parce que les pays organisent l’immatriculation fiscale de façons très différentes.
Un pays peut avoir un numéro fiscal national unique utilisé pour tout. Un autre peut avoir des numéros distincts pour différents impôts, de sorte qu’une entreprise détient un identifiant pour les impôts directs et un autre pour la taxe sur la valeur ajoutée. Un autre encore peut utiliser un numéro antérieur au système fiscal lui-même, introduit pour une autre finalité administrative puis adopté pour l’impôt. Certaines juridictions utilisent un identifiant qui sert aussi de numéro d’immatriculation de société ; d’autres les gardent strictement séparés.
Deux conséquences en découlent immédiatement. Premièrement, « numéro fiscal » n’est pas un champ unique dans la réalité ; c’est une famille de champs dont la composition dépend du pays. Deuxièmement, toute affirmation de la forme « un numéro fiscal contient toujours x » est fausse quelque part, ce qui explique pourquoi votre validation doit être écrite de manière défensive.
Pourquoi certains numéros fiscaux portent-ils une clé de contrôle ?
Parce que l’autorité émettrice les a conçus ainsi. Une clé de contrôle est une redondance arithmétique : le dernier caractère, ou un caractère intégré au milieu, est calculé à partir des autres selon une règle publiée, de sorte qu’un seul caractère mal saisi ou transposé produit généralement une valeur qui échoue à la règle.
Lorsqu’un pays publie une telle règle, l’implémenter est réellement utile. Elle attrape les erreurs de saisie les plus courantes au moment de la saisie, sans appel réseau, sans dépendance externe et sans question de confidentialité. Elle est peu coûteuse, rapide et déterministe — et c’est le contrôle le plus fort que vous puissiez effectuer localement.
Lorsqu’un pays ne publie aucune règle de ce type, l’identifiant n’est qu’une attribution : l’autorité l’a attribué et enregistré, et aucune arithmétique ne peut distinguer un vrai d’un inventé. C’est plus fréquent que les développeurs ne l’attendent. Certaines très grandes juridictions délivrent de simples numéros séquentiels sans aucune redondance.
L’instruction qui en découle est sans détour. N’implémentez un algorithme de clé de contrôle que pour les pays précis où vous avez vérifié que l’algorithme est publié et toujours en vigueur. Ne devinez pas un algorithme à partir de la forme du numéro, et ne présumez pas que, parce que le format d’un pays ressemble à celui d’un autre, la même règle s’applique.
| À quoi ressemble le numéro | Ce que vous pouvez honnêtement contrôler |
|---|---|
| Algorithme publié avec une clé de contrôle | Le jeu de caractères, la longueur et la règle arithmétique |
| Simple attribution, aucune règle publiée | Le jeu de caractères et une borne de longueur généreuse uniquement |
| Format avec un préfixe de pays ou d’autorité | Que le préfixe correspond au pays déclaré |
| Format qui sert aussi de numéro d’immatriculation | Ce que le registre lui-même peut confirmer |
Réussir la validation signifie-t-il que le numéro est réel ?
Non. La validité de format et l’existence sont des propriétés différentes, et les confondre est l’erreur de conception la plus courante dans ce domaine.
Un numéro syntaxiquement parfait peut n’appartenir à personne. Quiconque comprend le motif peut en produire un qui satisfait toutes les règles locales, y compris la clé de contrôle, parce que la clé de contrôle est conçue pour attraper les accidents plutôt que les adversaires. Un numéro peut aussi être parfaitement réel et échouer à votre règle locale, si cette règle a été écrite pour une mise en page plus ancienne, un autre pays, ou un document qui formatait le numéro de manière inhabituelle.
L’existence n’est établie que par l’autorité qui a délivré l’identifiant. Lorsqu’une administration fiscale publie un service officiel de consultation, ce service est la réponse à la question de l’existence ; lorsqu’elle ne le fait pas, l’existence peut n’être confirmable qu’à partir des documents fournis par l’entreprise. C’est une garantie réellement plus faible, et elle doit être décrite comme telle plutôt que présentée comme une vérification.
Il existe aussi une subtilité qui surprend les équipes : même une immatriculation confirmée est un fait ponctuel. Un numéro peut être valide aujourd’hui et annulé le mois prochain, de sorte qu’un cache agressif de « ce numéro est valide » finit par entrer en conflit avec la réalité. Mettez en cache délibérément, et préférez mettre en cache la réponse avec un horodatage plutôt que de la conserver pour toujours.
Comment la validation devrait-elle être organisée par couches ?
En trois passes, ordonnées par coût, la moins chère et la plus certaine en premier.
La première passe est locale et structurelle : le champ est-il non vide, reste-t-il dans une longueur maximale généreuse, ne contient-il que des caractères qui apparaissent dans un format quelconque, et le pays déclaré correspond-il à un préfixe présent. Cette passe ne devrait presque jamais rejeter une saisie plausible ; son rôle est d’attraper les valeurs vides et manifestement endommagées.
La deuxième passe est propre au pays : appliquez la règle de clé de contrôle publiée lorsque vous en avez une, et seulement là. Rapportez le résultat comme un avertissement de faute de frappe attaché au champ, formulé comme « cela ne semble pas correct, veuillez vérifier », parce que c’est ce que signifie réellement un échec de clé de contrôle.
La troisième passe est la consultation qui fait autorité, asynchrone et ne bloquant jamais le formulaire. Elle a trois résultats qu’il vaut la peine de distinguer — confirmé, introuvable et indisponible — et elle devrait pouvoir dire lequel s’est produit. Une consultation incapable de distinguer « ce numéro n’existe pas » de « le service est en panne » finira par rejeter un client légitime un jour de mauvaise connexion.
Pour les développeurs : erreurs, cache et pistes d’audit
Le travail de conception porte surtout sur l’honnêteté dans la gestion des erreurs. Chaque couche devrait produire un résultat distinguable, et le message que voit l’utilisateur devrait nommer la couche qui a échoué. « Nous n’avons pas pu joindre l’administration fiscale, vos informations sont enregistrées et nous vérifierons à nouveau » est un message utilisable. « Numéro fiscal invalide » accroché à une valeur que l’utilisateur a copiée d’un certificat officiel ne l’est pas.
Envisagez un type de résultat explicite plutôt qu’un booléen. Quatre états — non vérifié, forme valide, consultation confirmée, consultation introuvable — couvrent le terrain sans forcer une distinction que le système ne peut pas faire. Un booléen les écrase et garantit qu’une valeur légitime finira par être traitée comme fausse.
La mise en cache devrait être asymétrique. Un résultat confirmé vaut la peine d’être conservé pendant une période raisonnable ; un résultat introuvable devrait expirer rapidement, parce que les immatriculations changent et que l’absence d’hier est une mauvaise raison de rejeter le client d’aujourd’hui. Un résultat indisponible ne devrait pas du tout être mis en cache comme négatif.
Auditez ce que vous avez contrôlé sans transformer le journal en copie de la base de données clients. Consignez le fait et l’heure d’un contrôle, la couche appliquée et le résultat ; évitez de dupliquer l’identifiant brut dans des systèmes qui n’en ont pas besoin. Lorsque l’identifiant doit être conservé, traitez-le comme des données commerciales avec le même soin que n’importe quelles autres — et gardez les valeurs générées clairement distinctes des valeurs réelles, ce à quoi servent les champs d’identifiant fiscal synthétiques de ce site. L’article sur les formats de numéro de TVA couvre le membre le plus courant de cette famille, et les données d’entreprise de test montrent à quoi ressemble le reste d’un enregistrement d’entreprise synthétique.
Prochaines étapes
Inventoriez chaque contrôle de numéro fiscal dans votre produit et étiquetez chacun avec la couche qu’il implémente. Tout contrôle qui rejette une valeur sur la base d’un motif deviné devrait être rétrogradé en avertissement, et tout message qui dit « n’existe pas » sur la foi d’un test arithmétique devrait être réécrit pour dire ce qui a réellement été testé. Utilisez ensuite le générateur de données d’entreprise pour produire des enregistrements pour plusieurs pays et confirmez que votre formulaire gère un pays qu’il ne connaît pas du tout sans refuser la saisie d’emblée.