Vérifier des SIRET dans n8n ou Make : workflow no-code pas à pas

Ce que renvoie l’API recherche-entreprises, et pourquoi elle convient au no-code

L’API recherche-entreprises est éditée par la DINUM (Direction interministérielle du numérique) au sein de l’Annuaire des Entreprises. Elle expose la base Sirene de l’INSEE, complétée par le Registre national des entreprises tenu par l’INPI, et répond en JSON à une simple requête GET, sans clé d’authentification ni inscription. C’est précisément ce qui la rend confortable dans n8n ou Make : un seul nœud HTTP, aucun jeton à stocker ni à renouveler. D’après l’INSEE, Sirene est actualisée chaque jour ouvré, et l’API reprend ces mises à jour quotidiennement.

La requête tient en une ligne, le paramètre q recevant les 14 chiffres du SIRET :

GET https://recherche-entreprises.api.gouv.fr/search?q=81234567800019

La réponse contient un tableau results. Pour un SIRET, il ne devrait comporter qu’une entrée, avec quatre champs qui suffisent à qualifier la ligne : nom_complet (la dénomination), etat_administratif au niveau de l’unité légale (A pour active, C pour cessée), puis, dans matching_etablissements, le siret retrouvé et son propre etat_administratif (A pour ouvert, F pour fermé). Un champ total_results à 0 signale un numéro inconnu. La documentation officielle de l’API détaille les autres champs (adresse, code NAF, date de création, tranche d’effectif) et fixe la limite d’usage : 7 requêtes par seconde et par adresse IP, au-delà desquelles le serveur répond par un code HTTP 429.

Étape 1 : préparer la feuille et filtrer le format avant tout appel

Le point de départ est une feuille (Google Sheets, Airtable, Notion, peu importe) avec une colonne siret et des colonnes vides à remplir : statut, raison_sociale, naf et verifie_le. Deux précautions évitent la moitié des erreurs rencontrées ensuite dans le workflow.

• Forcer le format texte : un SIRET qui commence par 0 perd son zéro dès que la cellule passe en format nombre. La colonne doit rester en texte brut, sans espaces ni points.
• Tester la clé de Luhn avant tout appel réseau : un numéro dont la clé est fausse n’a aucune chance d’exister dans Sirene, et chaque requête épargnée compte dans la limite de débit. La formule Google Sheets qui teste la clé de Luhn sans automate se pose en une colonne, puis le workflow ne traite que les lignes où elle renvoie VRAI.

Dans les exemples ci-dessous, le SIRET 812 345 678 00019 sert d’illustration. Remplacez-le par vos propres données.

Étape 2 : le workflow dans n8n, nœud par nœud

Le canevas comporte sept nœuds. Nommez-les exactement comme ci-dessous, le script du nœud Code y fait référence.

1. Déclencheur : un nœud Manual Trigger pendant la mise au point, remplacé ensuite par un Schedule Trigger (tous les jours à 7 h, par exemple) ou par un Google Sheets Trigger sur l’événement Row Added pour contrôler chaque nouvelle ligne au fil de l’eau.
2. Google Sheets, opération Get Row(s) : lecture de l’onglet avec un filtre sur la colonne statut vide, afin de ne relancer que les lignes jamais vérifiées.
3. Loop Over Items (anciennement Split in Batches), taille de lot 5 : cinq appels par tour, c’est sous le plafond de 7 par seconde même si un autre workflow partage l’adresse IP.
4. HTTP Request : méthode GET, URL en mode expression, réponse au format JSON. Dans l’onglet Settings du nœud, activez Retry On Fail (Max Tries 3, Wait Between Tries 2000 ms) et réglez On Error sur Continue (using error output) : une ligne en échec sort par la branche d’erreur au lieu d’arrêter le lot.
5. Code, mode Run Once for Each Item : le script ci-dessous aplatit la réponse en six champs prêts à écrire.
6. Google Sheets, opération Update Row, colonne de correspondance siret : écriture des champs statut, raison_sociale, naf et verifie_le sur la ligne d’origine. Reliez aussi la branche d’erreur du nœud HTTP à ce nœud, via un nœud Edit Fields qui pose statut à « erreur_api ».
7. Wait d’une seconde, relié en retour au nœud Loop Over Items : le tour suivant démarre après la pause, ce qui lisse le débit.

URL du nœud HTTP Request, en mode expression :

https://recherche-entreprises.api.gouv.fr/search?q={{ $json.siret }}

Script complet du nœud Code, à coller tel quel :

const res = $input.item.json.results || []; const fiche = res[0] || null; const etab = fiche && fiche.matching_etablissements ? fiche.matching_etablissements[0] : null; return { json: { siret: $('Loop Over Items').item.json.siret, trouve: !!etab, statut: !etab ? 'introuvable' : (etab.etat_administratif === 'A' ? 'actif' : 'ferme'), raison_sociale: fiche ? fiche.nom_complet : '', naf: etab ? etab.activite_principale : '', verifie_le: new Date().toISOString().slice(0, 10) } };

Lancez une exécution de test avec trois lignes : une active, une fermée, une inventée. Les trois statuts (actif, ferme, introuvable) doivent apparaître dans la feuille avant de brancher le déclencheur automatique.

Étape 3 : le même workflow dans Make, module par module

Make raisonne en modules reliés dans un scénario et compte chaque exécution de module comme une opération. Le scénario équivalent en compte cinq.

1. Google Sheets, module Search Rows : filtre statut « is empty », nombre maximal de lignes renvoyées fixé à 200 par exécution. Make itère de lui-même sur chaque ligne trouvée, un Iterator est donc superflu. Pour un traitement au fil de l’eau, remplacez-le par le déclencheur Watch Rows.
2. HTTP, module Make a request : méthode GET, option Parse response activée pour obtenir directement des collections exploitables, et URL construite avec la variable siret du module 1.
3. Tools, module Sleep d’une seconde : il ralentit la cadence sous le plafond de l’API. Comptez-le dans le budget, chaque pause consomme une opération.
4. Router avec deux routes : la première filtrée sur total_results supérieur à 0, la seconde définie comme fallback pour les numéros inconnus.
5. Google Sheets, module Update a Row sur chaque route : le numéro de ligne vient du module 1 (variable Row number), les valeurs sont mappées depuis la réponse. Attention, les tableaux Make sont indexés à partir de 1 : la dénomination se lit dans results[1].nom_complet et l’état de l’établissement dans results[1].matching_etablissements[1].etat_administratif.

URL du module HTTP :

https://recherche-entreprises.api.gouv.fr/search?q={{1.siret}}

Sur le module HTTP, ajoutez un gestionnaire d’erreur (clic droit, Add error handler). La directive Resume renvoie une valeur par défaut (statut « erreur_api ») et laisse le scénario continuer, tandis que Break conserve l’exécution incomplète pour la rejouer plus tard depuis l’historique.

Récapitulatif : chaque étape dans n8n et dans Make

Gérer les erreurs et les limites de débit

Quatre situations couvrent l’essentiel des incidents rencontrés en production.

• Code 429 : trop de requêtes. Réduisez la taille de lot ou allongez la pause. Avec Retry On Fail et un délai de 2 secondes, l’appel repasse presque toujours au second essai.
• Codes 5xx ou délai dépassé : indisponibilité passagère. Trois tentatives espacées suffisent. Au-delà, marquez la ligne « erreur_api » et laissez le prochain passage la reprendre, plutôt que d’interrompre le lot.
• total_results à 0 : le numéro n’existe pas dans Sirene, ou bien il appartient à un entrepreneur individuel ayant demandé la non-diffusion de ses données, que l’API masque en partie. Un contrôle manuel s’impose avant de conclure à une fraude.
• Résultat trouvé mais SIRET différent : la recherche par q reste textuelle. Comparez toujours matching_etablissements[0].siret au numéro d’entrée avant d’écrire le statut.

Le plafond de 7 requêtes par seconde autorise, en théorie, plus de 25 000 vérifications par heure. En pratique, un workflow n8n plafonne bien plus bas à cause des lectures et écritures dans la feuille, et Make consomme quatre à cinq opérations par ligne. Sur n8n Cloud comme sur Make, d’autres clients partagent la même adresse IP sortante et puisent dans le même quota. Ces contraintes ressemblent à celles de l’API Sirene de l’INSEE, et les solutions de repli quand les quotas d’API freinent une vérification en volume valent tout autant pour recherche-entreprises.

Quand préférer l’upload d’un fichier au workflow

Un workflow no-code excelle pour le flux : chaque nouveau client, chaque fournisseur créé dans le CRM, chaque ligne ajoutée à la feuille est contrôlée dans la minute. Il devient coûteux pour le stock : reprise d’une base de 5 000 fournisseurs, audit annuel, préparation d’une migration. Sur Make, 5 000 lignes représentent plus de 20 000 opérations. Sur n8n, cela signifie plusieurs heures d’exécution à surveiller, avec des reprises manuelles sur les lignes en erreur.

Le contexte réglementaire rend ces reprises fréquentes : selon le calendrier publié par la DGFiP, toutes les entreprises doivent pouvoir recevoir des factures électroniques depuis le 1er septembre 2026, et les PME et micro-entreprises devront en émettre à partir du 1er septembre 2027. Un SIRET faux ou fermé dans la base fournisseurs devient un motif de rejet, d’où les grandes passes de nettoyage.

Pour ce cas précis, l’import direct est plus simple : Trouve-ton-siret.com accepte un fichier Excel ou CSV, vérifie chaque SIRET, SIREN ou numéro de TVA contre Sirene et rend le fichier enrichi (dénomination, état, adresse, code NAF) en quelques minutes, exportable en CSV ou JSON, sans workflow à maintenir. La règle pratique tient en une phrase : le workflow pour le flux, le dépôt d’un fichier entier pour le stock, et rien n’empêche de combiner les deux.

Questions fréquentes