Comment savoir si une entreprise est en difficulté

Passer un portefeuille de SIREN en revue, par paquets de 200

Le chapitre traite un dossier à la fois. Ici l'entrée est un fichier de clients ou de fournisseurs, et la sortie tient en une colonne : quelles sociétés du lot ne sont plus actives au registre depuis le dernier passage. Basile ne dira pas quelle procédure est ouverte, seulement si la société tient encore debout.

Dans la plateforme, pas à pas

1. Ouvrez la recherche entreprises et dépliez le filtre « SIREN / TVA ». Tapez un SIREN (neuf chiffres collés, sans espaces), validez avec Entrée ou avec le bouton +, et recommencez : le champ ajoute une pastille par valeur et ne sait pas lire un fichier collé.
2. Décochez « Entreprises actives uniquement ». Ce réglage est actif par défaut sur toute recherche, et il masque exactement ce que vous cherchez.
3. Lancez la recherche. Les sociétés dont le registre dit « inactif » portent une pastille rouge « Fermée » à côté de leur nom.
4. Exportez le résultat en CSV, format « 1 ligne par entreprise ». Le fichier porte legal_siren, legal_ceased et legal_statut_rcs : c'est votre relevé daté, celui que vous comparerez au passage suivant.
5. Ne comptez pas sur le filtre « En procédure collective » visible dans le panneau : il porte la mention « Bientôt disponible » et ne filtre rien aujourd'hui.

La saisie pastille par pastille borne cette voie à un contrôle ponctuel, quelques dizaines de lignes tout au plus. Il n'existe aucun import de fichier dans l'écran : un portefeuille de plusieurs milliers de SIREN passe par l'API.

Par l'API : POST /companies/find

{
  "limit": 200,
  "filters": {
    "siren": {
      "include": ["552100554", "380129866", "775665019"]
    },
    "company_ceased": true
  }
}

La réponse a la forme { total, leads[], pagination, meta }. Chaque lead porte source: "Legal" et un objet data où figurent siren, legal_name, consolidated_status ("actif" ou "inactif") et company_ceased. Avec "company_ceased": true, seules les sociétés inactives reviennent : sur un paquet de 200 SIREN, vous ne payez que les mauvaises nouvelles, une clé d'API débitant une unité par fiche renvoyée, à chaque appel. Pour chiffrer avant de payer, rejouez le même corps avec "countOnly": true : le comptage est gratuit et la liste revient vide. Sur un paquet de cette taille le total est le décompte exact ; ce n'est vrai que sous 2 000 lignes brutes, au-delà de quoi le total redevient la somme des trois sources avant déduplication, donc une estimation haute. Lisez enfin meta.noticeCode s'il est présent : c'est là que la recherche dit qu'elle a restreint ou élargi ses sources.

Le filtre siren accepte 200 valeurs par appel côté entreprises : découpez le fichier en paquets de 200, un appel par paquet, et tout tient dans une seule page (aucune pagination à gérer). Ce filtre n'existe que sur le registre légal, ni LinkedIn ni Google ne portant de SIREN : la recherche s'y restreint d'elle-même. Deux réserves au dépouillement. Lisez consolidated_status plutôt que le booléen brut company_ceased : les deux se contredisent sur environ 6,5 % des fiches, dont près de 1,72 million de sociétés marquées non cessées alors que leur statut consolidé est « inactif », et c'est bien le statut consolidé que le filtre applique. Ensuite, la recherche ne rend qu'une fiche par domaine : deux SIREN qui partagent le même site certifié (une holding et son exploitation, par exemple) se fondent en une ligne. Comparez donc toujours les SIREN reçus aux SIREN envoyés, et repassez les manquants sans le filtre company_ceased pour obtenir leur fiche une à une, plutôt que de les tenir pour actifs par défaut.

Le détail des champs, des filtres et des codes de réponse est dans la documentation de l'API.

Avec Claude, en langage courant

J'ai 240 SIREN dans ce fichier. Compte d'abord, puis dis-moi lesquels correspondent à des sociétés qui ne sont plus actives au registre, avec leur raison sociale.

Claude enchaîne basile_count puis basile_search_companies.

Le MCP se facture comme une clé d'API : basile_count est gratuit et rend le total, basile_search_companies débite une unité par fiche renvoyée. Claude découpe lui-même en paquets de 200 et pose company_ceased à true pour ne rapporter que les sociétés cessées. Au-delà de quelques centaines de lignes, c'est la conversation qui sature, pas la base : c'est le moment de passer à l'API.

Faire tourner ce rapprochement tout seul, tous les mois

Un contrôle qui dépend de quelqu'un qui y pense n'est pas un contrôle. Sur un gros portefeuille, la voie fiable n'est pas la recherche page par page mais l'export asynchrone : vous demandez un fichier, le serveur le construit en dehors de votre requête, vous le récupérez quand il est prêt. Une connexion coupée ou un déploiement en cours de route ne perdent rien.

Dans la plateforme, pas à pas

L'application n'a pas de planificateur. Rien, dans l'écran, ne relance une recherche à date fixe ni ne compare deux passages. Le menu « Exports » conserve les fichiers déjà produits et permet de les retélécharger pendant sept jours, ce qui aide à retrouver le relevé précédent, mais le déclenchement reste un geste manuel.

Par l'API : POST /exports

{
  "source": "companies",
  "filename": "portefeuille-2026-09.csv",
  "filters": {
    "siren": {
      "include": ["552100554", "380129866", "775665019"]
    }
  }
}

202 avec { "success": true, "job": { "id", "status", "source", "recordType", "filename", "selectedCount" } }. Le CSV se construit ensuite côté serveur, que vous restiez connecté ou non. Interrogez GET /exports/{jobId} : le job passe par queued, puis running, puis done (ou partial si un plafond a été atteint en route, failed en cas d'échec), avec rowCount, byteSize et ready. Quand ready vaut true, GET /exports/{jobId}/download répond une redirection 302 vers une URL signée, que curl -L suit pour écrire le fichier ; tant que le fichier n'est pas prêt, la même route répond 409 avec le statut courant. Le fichier reste téléchargeable sept jours. GET /exports, sans identifiant, liste vos jobs récents.

Trois points avant de programmer quoi que ce soit. Une clé d'API doit poser au moins un filtre qui filtre vraiment : un corps avec "filters": {} est refusé par un 400 « At least one filter is required. », et c'est voulu, une liste de SIREN satisfait la règle. L'export débite le compteur mensuel de lignes, le même qu'entame la recherche par clé : une ligne récupérée vaut une unité, et le comptage (countOnly sur /companies/find) reste gratuit si vous voulez chiffrer d'abord. Gardez enfin le découpage par paquets de 200 SIREN, un job par paquet. Ce n'est pas une limite de cette route (elle ne borne pas la liste, contrairement à /companies/find qui la plafonne à 200) mais une prudence d'exploitation : un job court se rejoue sans douleur et vous voyez immédiatement lequel a échoué. Le fichier porte les mêmes colonnes que l'export de l'écran ; trois suffisent à la comparaison mensuelle : legal_siren, legal_ceased et legal_statut_rcs. Bonne nouvelle sur la première : dans le CSV, legal_ceased est déjà calculée depuis le statut consolidé de la fiche légale de la ligne, la réserve du mode précédent ne concerne que la réponse JSON de la recherche. legal_statut_rcs, lui, vaut « Inscrit », « Radié » ou « Non inscrit », tel que le registre le fournit. Seul « Radié » est un signal : « Non inscrit » ne dit rien de la santé de la société, la plupart des entrepreneurs individuels et des artisans ne relevant tout simplement pas du RCS, et cette valeur couvre donc une large part du parc. La comparaison, elle, vous appartient : Basile ne conserve pas l'état du mois précédent et ne publie aucun flux de changements.

Le détail des champs, des filtres et des codes de réponse est dans la documentation de l'API.

Avec Claude, en langage courant

Le serveur MCP n'expose pas les exports asynchrones et n'a pas de planificateur. Son outil basile_export rend le CSV directement dans la conversation et refuse au-delà de 500 lignes, ce qui convient à un échantillon, pas à un portefeuille. Une conversation peut faire le passage du mois quand vous la lancez, mais elle ne se déclenche pas seule et ne garde pas le fichier du mois précédent pour le comparer. Le récurrent se pose sur une clé d'API, avec votre propre déclencheur horaire.

Voir qui dirige aujourd'hui les sociétés que vous suivez

Le chapitre range le changement de dirigeant parmi les signaux qui précèdent la procédure. Il se lit sur les mêmes SIREN, du côté des personnes : le registre dit qui détient un mandat en cours. La comparaison avec votre relevé précédent fait le reste, car il n'existe ici ni historique daté ni alerte.

Dans la plateforme, pas à pas

1. Commencez par la recherche entreprises et ajoutez vos SIREN dans le filtre « SIREN / TVA », comme pour la revue de portefeuille.
2. Sélectionnez les sociétés trouvées, puis cliquez « Trouver les contacts ». La recherche bascule côté personnes, préremplie avec vos SIREN (pour le registre) et les noms d'employeur entre guillemets (pour LinkedIn), jusqu'à 1 000 sociétés en une fois.
3. Dans le panneau personnes, activez « Actuellement dans le poste ». C'est le registre légal qui porte cet indicateur, les profils LinkedIn n'ont pas d'équivalent tenable.
4. Laissez « Masquer les personnes morales » inactif si vous voulez la photo complète : certains mandataires sont eux-mêmes des sociétés, une holding présidente par exemple. Activez-le pour ne garder que des êtres humains.
5. Lisez la colonne « Rôle / Intitulé » : c'est le libellé du mandat tel qu'il est enregistré (Gérant, Président, Directeur général, Liquidateur). Exportez pour figer la photo : person_full_name, person_title_raw, person_in_office et legal_siren suffisent à la comparaison.

Un dirigeant qui s'en va ne s'affiche pas avec une mention « parti » : sa fiche cesse simplement d'apparaître. Les fiches que le registre ne soutient plus sont d'ailleurs retirées de la recherche en bloc, 724 002 fiches de dirigeants présentes dans la version précédente du registre ayant disparu de la version courante ; elles restent résolues par identifiant dans vos listes et leurs exports, mais ne remontent plus dans une recherche. Le mouvement se lit donc dans l'écart entre deux relevés, jamais dans un signal isolé. Notez aussi que l'écran n'offre pas de liste fermée de mandats : le champ « Rôle / Intitulé » mélange intitulés LinkedIn et mandats légaux, groupés sous deux en-têtes dans le menu déroulant, et vous y tapez « Liquidateur » comme n'importe quel autre libellé.

Par l'API : POST /people/find

{
  "limit": 100,
  "filters": {
    "siren": {
      "include": ["552100554", "380129866"]
    },
    "result_is_current": true,
    "mandate_role": {
      "include": ["gerant", "president", "dg", "liquidateur"]
    }
  }
}

{ total, leads[], pagination, meta }. Chaque lead porte source: "Legal" et un data où figurent result_full_name, result_role (le libellé exact du mandat), siren et legal_name. Regroupez par siren et comparez au relevé précédent : un nom qui disparaît, un nom qui apparaît, un libellé qui change, c'est là que se lit le mouvement. Comme côté entreprises, "countOnly": true donne le nombre de mandats concernés sans rien débiter, et la recherche coûte sinon une unité par fiche renvoyée.

Côté personnes, le filtre siren accepte jusqu'à 1 000 valeurs par appel : c'est une correspondance exacte sur neuf chiffres collés, pas un balayage, et elle reste rapide. Les codes de mandat acceptés sont gerant, president, dg, dgd, administrateur, commissaire_comptes, associe, directeur_non_dg, chef_entreprise, liquidateur, et autre pour le reste. Deux d'entre eux ne figurent dans aucune liste de l'écran et méritent le détour. chef_entreprise est devenu le mandat le plus courant du registre depuis sa reprise d'août 2026, avec environ 65 % des lignes de mandats à lui seul : c'est celui de l'entrepreneur individuel. liquidateur en représente environ 2,5 %, soit de l'ordre de 490 000 fiches ; un liquidateur nommé sur l'un de vos SIREN dit que la société est en cours de liquidation, sans dire si elle est amiable ou judiciaire, distinction qui se lit au BODACC et non ici. Enfin, result_is_current et mandate_role n'existent que sur le registre : leur présence restreint la recherche à cette source, ce que le SIREN seul ne fait pas (posé seul, il interroge aussi LinkedIn et vous rend les salariés en plus des mandataires). "hide_legal_entities": true écarte les mandataires qui sont des sociétés.

Le détail des champs, des filtres et des codes de réponse est dans la documentation de l'API.

Avec Claude, en langage courant

Voici les 60 SIREN que je suis. Dis-moi, pour chacun, qui est enregistré aujourd'hui comme dirigeant avec le libellé exact de son mandat, et signale-moi ceux où apparaît un liquidateur.

Claude enchaîne basile_count puis basile_search_people.

basile_search_people accepte les mêmes filtres que l'API, mandate_role et result_is_current compris. Comptez d'abord, basile_count est gratuit : une société porte souvent plusieurs mandataires, et la recherche débite une unité par fiche renvoyée. Gardez la réponse quelque part, dans un fichier ou un tableur : sans relevé précédent, il n'y a rien à comparer et l'information ne vaut que par la comparaison.