SIRET : fiche client B2B remplie
code_sirenapiv3 · v2.1.0 · AGPL-3.0-or-later
Le client professionnel tape son SIRET : la raison sociale apparaît pendant la saisie, puis le code d'activité et l'adresse du siège sont renseignés à l'inscription. Aucun réglage, aucune clé d'API, aucun compte à créer.
Ce que ce module fait, et ce qu'il refuse
- ✓La raison sociale apparaît pendant la saisie du SIRET, avant toute validation
- ✓Code APE et adresse du siège renseignés à la création du compte
- ✓Aucune clé d'API ni compte à créer — l'annuaire public répond sans authentification
- ✓La clé de contrôle du SIRET vérifiée avant tout appel (Luhn, cas de La Poste inclus)
- ✓N'écrase jamais une saisie du client et n'ajoute jamais une seconde adresse
- ✓N'empêche jamais une inscription d'aboutir : 3 s de délai, panne silencieuse et journalisée
- ✓Point d'entrée public borné : POST seul, jeton de page, 10 appels par minute
- ✓Un essai à blanc dans l'écran de configuration, sans rien écrire
Le problème
Un client professionnel s'inscrit sur votre boutique. Il tape son SIRET, et c'est tout ce que vous obtenez : pas de raison sociale fiable, pas de code d'activité, pas d'adresse de siège. Vous les ressaisissez à la main, ou vous faites sans.
Ce module remplit ces champs tout seul — sans réglage, sans clé d'API, sans compte à créer.
Ce qu'il faut pour qu'il serve à quelque chose
Le mode B2B doit être actif, dans *Paramètres de la boutique → Clients*. Sans lui, PrestaShop ne demande pas de SIRET à l'inscription, et le module n'a rien à lire. L'écran de configuration vous le dit en clair plutôt que de rester muet.
Pendant la saisie du formulaire
Dès que quatorze chiffres valides sont tapés dans le champ SIRET, le champ Société se remplit si le visiteur ne l'a pas déjà renseigné, et un court texte sous le champ dit ce qui a été reconnu. Le visiteur sait tout de suite qu'il ne s'est pas trompé de numéro, au lieu de le découvrir après validation.
C'est un confort, pas le mécanisme : sans JavaScript, sur un thème qui ne porte pas ces champs, ou si l'annuaire ne répond pas, il ne se passe rien de visible et l'inscription suit son cours. L'enrichissement ci-dessous a lieu de toute façon.
À la création du compte
- La clé de contrôle du SIRET est vérifiée localement, avec le cas
particulier de La Poste — un numéro fautif n'est jamais envoyé à l'annuaire.
- L'annuaire est interrogé sur ce SIRET. S'il ne connaît pas cet établissement,
une seconde requête porte sur le SIREN, les neuf premiers chiffres, qui désigne l'entreprise : c'est alors l'adresse de son siège qui est posée, et l'étiquette de l'adresse le dit.
- La raison sociale et le code d'activité sont écrits sur la fiche
client.
- Une adresse « Siège social » est créée.
Les établissements fermés sont bien indexés par leur SIRET, contrairement à ce qu'on pourrait croire : le repli sur le SIREN n'est pas là pour eux, mais pour un numéro juste de clé et absent de l'index — un établissement trop récent, par exemple.
Ce qu'il ne fait pas, volontairement
- Il n'écrase jamais une saisie. Raison sociale et code d'activité ne sont
remplis que s'ils sont vides : le client qui a tapé son nom d'usage a plus de raisons d'avoir raison que l'annuaire.
- Il n'ajoute pas une seconde adresse. Si le client en a déjà une, aucune
n'est créée — un carnet d'adresses en double au premier jour est une gêne.
- Il n'empêche jamais une inscription d'aboutir. Le délai d'appel est de
trois secondes, et toute panne — annuaire muet, SIRET inconnu, réponse illisible — laisse le compte se créer sans enrichissement. L'incident part dans les journaux de la boutique, pas à la figure du visiteur.
- Il ne valide pas le SIRET à la saisie. Refuser une inscription parce qu'un
service externe n'a pas répondu coûte plus cher qu'une fiche incomplète.
- Il n'enrichit pas la modification d'une fiche existante.
- Il ne crée aucune table et n'a aucun réglage.
Ce qu'il écrit sur votre serveur, et ce qu'il n'écrit pas
Deux fichiers dans le cache de la boutique : les réponses de l'annuaire, pour ne pas le solliciter deux fois pour le même numéro, et les compteurs du plafond de débit. Les supprimer est sans conséquence, ils se recréent.
Il ne conserve l'adresse IP de personne. Le plafond de débit a besoin de savoir si deux appels viennent du même endroit, pas d'où ils viennent : il n'en garde qu'un condensé tronqué, salé par la clé de votre boutique — ni réversible, ni rapprochable d'une autre boutique. Ces compteurs s'effacent au bout d'une heure d'inactivité.
Sur le nom du module
Le nom technique code_sirenapiv3 est historique. La version 1.0.0 visait l'API Sirene v3 de l'INSEE, qui exige un compte et une clé ; depuis la 2.0.0 le module ne s'en sert plus et interroge l'annuaire des entreprises de la DINUM, qui répond sans authentification. Le nom est conservé pour ne pas casser les installations existantes.
Installation
Back-office → Modules → Installer un module → déposer le .zip. Vérifiez que le mode B2B est actif, et c'est tout : il n'y a rien à configurer.
Ce que la licence exige de vous
Ce module est sous AGPL-3.0-or-later. Installé sans modification, vous n'avez rien à publier. Modifié et servi à vos visiteurs, vous devez leur offrir la source de ce module modifié — jamais celle de votre boutique, de votre thème, ni du cœur de PrestaShop. Le fichier NOTICE de l'archive porte les attributions exactes.
Le module est gratuit. Une adresse e-mail suffit.
Sans compte à créer, et la lettre d'information reste facultative.