API INPI Entreprises devient critique quand un SI exploite les données du Registre national des entreprises pour vérifier une société, suivre une formalité, télécharger un acte, récupérer un compte annuel, enrichir un dossier conformité ou alimenter un référentiel fournisseur.
Les sources officielles confirment le périmètre: l'INPI opère le RNE, alimenté par le Guichet unique, et Data INPI donne accès par API aux informations entreprises, aux créations, modifications, cessations, aux actes et statuts, ainsi qu'aux comptes annuels non confidentiels selon les jeux de données.
Le risque n'est pas de récupérer un JSON ou un PDF. Le vrai risque consiste à rediffuser une donnée qui ne doit pas l'être, ignorer une suppression `deleted`, perdre un curseur `searchAfter`, confondre flux quotidien et état courant, ou traiter un 429 comme une absence d'information.
Le bon arbitrage consiste à comprendre quoi décider, quoi bloquer et quoi corriger avant production: SSO, token Bearer, SIREN, formalités, actes PDF, comptes annuels, recherche différentielle, `pageSize`, `from`, `to`, `searchAfter`, données confidentielles, diffusion commerciale, codes 400, 401, 403, 429 et 500.
Pour poser ce cadre sans bricolage, notre accompagnement en intégration API aide à écrire les contrats, mappings, seuils, retries, dashboards, preuves et runbooks nécessaires. Le sujet rejoint la landing API services publics et Open Data et la page intégrateur INPI Entreprises, parce que la valeur vient d'un workflow légal gouverné, pas seulement d'une archive téléchargée.
Pour qui API INPI Entreprises devient critique
API INPI Entreprises devient prioritaire pour les équipes conformité, achats, finance, juridique, credit management, onboarding fournisseur, veille registre, marketplace B2B, analyse documentaire et data office qui doivent suivre la vie administrative d'une entreprise.
Le signal faible apparaît quand un contrôleur demande un acte sur Data INPI, un autre lit un compte annuel, un troisième se fie au CRM, et personne ne sait quel événement RNE a justifié la dernière décision de validation.
Le coût complet vient des contrôles refaits, des documents conservés malgré suppression, des comptes confidentiels demandés à tort, des recherches différentielles interrompues, des statuts juridiques contradictoires et des tickets support qui traduisent une donnée légale sans preuve.
Le déclencheur de priorité est simple: si une information RNE peut changer un onboarding, un paiement, une alerte fraude, une approbation fournisseur, une clause contractuelle ou une exclusion marketing, alors API INPI Entreprises doit porter owner, droits, trace, purge, seuils et rollback.
1. RNE, Guichet unique et périmètre INPI
Situer le RNE dans le SI
Depuis le 1er janvier 2023, le RNE remplace les anciens registres nationaux comme le RNCS, le Répertoire des métiers et le Registre des actifs agricoles pour les entreprises commerciales, artisanales, agricoles ou indépendantes du périmètre géographique défini.
L'INPI est l'opérateur du registre et le Guichet unique alimente directement les événements de création, modification et cessation déclarés par les entreprises. Le connecteur doit donc distinguer déclaration, validation, diffusion et consommation métier.
Le modèle interne doit relier SIREN, personne physique ou morale, forme d'exercice, établissement principal, autres établissements, composition, observations, pièces jointes et événements historiques. Sinon, le RNE devient un bloc opaque difficile à relire.
Séparer formalités, actes et comptes
Data INPI distingue plusieurs familles: informations entreprises et formalités en JSON, actes et statuts en PDF, comptes annuels ou bilans non confidentiels en JSON et PDF. Chaque famille a son endpoint, sa preuve et son mode de purge.
Les actes et statuts couvrent notamment des personnes morales et physiques depuis 1993 pour le stock et les nouveaux actes transmis par les entreprises. Les comptes annuels déposés depuis le 1er janvier 2017 sont disponibles quand ils ne sont pas confidentiels.
Si une fiche interne mélange formalité, acte et compte dans une même "preuve INPI", alors le support ne saura pas expliquer ce qui fonde la décision. Le contrat doit conserver la nature de la source et son usage autorisé.
Ne pas confondre Data INPI et API Entreprise
Certains flux INPI existent aussi via API Entreprise, par exemple l'attestation d'immatriculation RNE ou les bénéficiaires effectifs dans des conditions restreintes. Ces accès ne remplacent pas automatiquement les APIs Data INPI.
L'attestation RNE distribuée via API Entreprise renvoie notamment des données structurées et une URL PDF, avec un appel par SIREN et une limite affichée à 15 requêtes par minute. Les bénéficiaires effectifs relèvent d'un accès beaucoup plus encadré.
Le connecteur doit choisir le canal selon le cas d'usage: open data Data INPI, bouquet API Entreprise, habilitation fraude, ou téléchargement contrôlé. Mélanger ces canaux crée des droits flous et des messages support incohérents.
La matrice d'accès doit donc indiquer source officielle, base juridique, périmètre géographique, format, fréquence de mise à jour, limite d'appel, donnée sensible, rediffusion possible et interlocuteur responsable. Cette grille évite qu'une équipe prenne une réponse obtenue via un canal habilité pour une donnée librement réutilisable.
2. SSO, token Bearer et habilitations
Authentifier le compte technique
La documentation des formalités, actes et comptes décrit une connexion par appel SSO sur `/api/sso/login`, avec un couple identifiant et mot de passe. La réponse fournit un token à transmettre ensuite dans le header Authorization en Bearer.
Ce token ne doit pas être manipulé par chaque traitement. Le connecteur doit centraliser login, durée de vie, stockage temporaire, renouvellement, échec d'authentification et séparation entre environnement de test et production.
Le seuil de sécurité est atteint si un mot de passe API circule dans 3 jobs ou plus pendant 7 jours. Alors la rotation, le coffre, l'owner et le journal d'accès sont à corriger avant tout élargissement.
Distinguer public et confidentiel
Les informations publiques sont accessibles après création de compte, tandis que les informations confidentielles sont réservées aux entités habilitées selon les textes rappelés dans la documentation. Cette frontière doit être codée dans le mapping.
Un token authentifié ne signifie pas que toute donnée est exploitable ou rediffusable. Le flux doit identifier le droit d'accès, le droit d'affichage, le droit de conservation et le droit de transmission vers un outil aval.
Si un 403 est contourné par une extraction manuelle sans revue habilitation, alors le flux est à bloquer. Le problème n'est pas un manque de donnée, mais une absence de droit explicite pour la requête.
Journaliser l'usage de la donnée
L'API peut contenir des données à caractère personnel, des adresses, des personnes physiques, des pouvoirs, des observations et des documents attachés. Le connecteur doit donc tracer finalité, utilisateur applicatif, dossier, source et action.
La trace doit rester lisible: qui a demandé le RNE, pour quel SIREN, à quelle date, par quel endpoint, avec quel résultat et quelle donnée a été affichée, conservée, supprimée ou refusée.
Si un audit ne peut pas retrouver la finalité d'un téléchargement PDF en moins de 15 minutes, alors l'observabilité est insuffisante. La preuve doit suivre le document, pas seulement le ticket technique.
Cette journalisation doit aussi couvrir les usages internes: prévisualisation, téléchargement, envoi à un prestataire, ajout dans un dossier, suppression et export. Sans ces étapes, l'entreprise sait qu'un fichier existe, mais elle ne sait plus quelle décision il a réellement soutenue.
3. Formalités JSON et recherche entreprise
Appeler la recherche par entreprise
L'API formalités expose une recherche par entreprise sur `/api/companies`, avec des filtres comme `pageSize`, `page`, `siren[]`, `companyName`, `submitDateFrom`, `submitDateTo`, `numnat`, `activitySectors`, `codeCategory` et `zipCodes[]`.
Le détail d'une entreprise est ensuite accessible par `/api/companies/{siren}`. Ce endpoint doit être rattaché à une décision précise: lecture actuelle, contrôle de conformité, alimentation référentiel, pré-remplissage ou preuve de dossier.
Si plus de 5 % des recherches par dénomination créent des rapprochements corrigés sur 30 jours, alors le seuil de qualité est dépassé. La règle doit favoriser le SIREN confirmé plutôt qu'un nom contenant la bonne chaîne.
Utiliser les états historiques
L'API historique permet de récupérer l'état antérieur d'une entreprise en ajoutant une date au format AAAA-MM-JJ sur `/api/companies/{siren}`. Cette capacité est importante quand un litige porte sur une décision passée.
Le SI doit distinguer état courant, état au jour de l'événement, état au jour du contrat et état conservé comme preuve. Sans cette nuance, une formalité récente peut rendre incompréhensible une décision ancienne pourtant correcte.
Le seuil de recette est concret: 10 appels courants, 10 appels historiques, zéro écrasement silencieux et une phrase support expliquant pourquoi l'état affiché correspond à la date du dossier.
Modéliser les blocs JSON utiles
La documentation technique décrit des blocs comme personne physique, personne morale, exploitation, établissement principal, établissement modifié, autres établissements, pièces jointes, observations, adresse et identité.
Le connecteur ne doit pas exposer tout le JSON brut dans le back-office. Il doit traduire les blocs en statuts métier: personne morale validée, représentant identifié, cessation détectée, établissement modifié, document disponible ou donnée non rediffusable.
Si plus de 20 champs RNE sont stockés sans usage opérationnel, alors le mapping est à reprendre. L'intégration doit enrichir la décision, pas créer une copie exhaustive que personne ne sait purger.
La nomenclature métier doit rester plus courte que le JSON source: identité, établissement, composition, adresse, observation, pièce, événement, cessation et contrôle. Cette couche de traduction aide juridique, achats, finance, support, conformité et data à parler le même langage sans manipuler chaque attribut technique.
4. Actes PDF et comptes annuels
Récupérer les actes associés
L'API actes permet d'obtenir les identifiants des actes associés à une entreprise via `/api/companies/{siren}/attachments`, puis de récupérer les métadonnées d'un acte via `/api/actes/{id}` et de télécharger le PDF via `/api/actes/{id}/download`.
Les métadonnées peuvent indiquer `updatedAt`, SIREN, dénomination, date de dépôt, numéro chrono, nom du document, confidentialité, suppression et type d'acte. Ces champs doivent descendre dans une fiche documentaire gouvernée.
Si un acte supprimé reste téléchargeable en interne pendant 7 jours après réception de `deleted`, alors le seuil de risque documentaire est dépassé. Le fichier doit être retiré, la preuve conservée et le support informé.
Exploiter les comptes annuels
L'API comptes annuels permet d'accéder aux bilans et bilans saisis, avec des endpoints comme `/api/bilans/{id}`, `/api/bilans/{id}/download`, `/api/bilans?` et `/api/bilans-saisis?` selon le besoin documenté.
Les comptes annuels peuvent être complets, simplifiés, consolidés ou propres à certains secteurs, avec des métadonnées comme date de clôture, type de bilan, version, confidentialité, suppression et identifiant documentaire.
Le connecteur doit distinguer disponibilité de métadonnées, droit de téléchargement, confidentialité, usage métier et conservation. Un compte annuel ne doit pas être aspiré automatiquement si une preuve légère suffit au contrôle.
Éviter la confusion entre métadonnée et fichier
Les APIs PDF renvoient souvent d'abord des métadonnées, puis une étape de téléchargement. Cette séparation doit exister côté SI: rechercher un document, valider son usage, télécharger si nécessaire, puis tracer la conservation.
Un PDF n'est pas seulement une pièce jointe. Il peut contenir des données personnelles, des informations économiques ou des mentions dont la rediffusion doit être maîtrisée. Le stockage doit donc porter expiration, source et motif.
Si plus de 3 documents sur 30 jours sont téléchargés sans dossier associé, alors le seuil de contrôle est dépassé. Le workflow doit exiger une finalité avant toute récupération de fichier.
5. Différentiel, pageSize et searchAfter
Piloter les flux différentiels
Les APIs formalités, actes et comptes annuels proposent des recherches différentielles pour récupérer les éléments créés, modifiés, ajoutés ou supprimés depuis une date. Les utilisateurs peuvent choisir une fréquence quotidienne, hebdomadaire, mensuelle ou adaptée au besoin.
La formalité différentielle utilise `/api/companies/diff`, les actes utilisent `/api/actes?`, et les comptes annuels utilisent notamment `/api/bilans?` ou `/api/bilans-saisis?`. Les filtres `from`, `to`, `dateFrom` et `dateTo` doivent être normalisés dans le connecteur.
Si le backlog différentiel dépasse 2 jours ouvrés, alors le seuil de fraîcheur juridique est dépassé et la cadence est à corriger. L'équipe doit prioriser les dossiers bloquants avant les enrichissements non urgents.
Respecter pageSize et searchAfter
Les documentations indiquent un `pageSize` compris entre 1 et 100, avec 20 par défaut sur les flux différentiels. Le curseur `searchAfter` permet de reprendre la recherche à partir du SIREN indiqué dans les headers.
Ce curseur doit être stocké avec date de fenêtre, endpoint, taille de page, compteur, statut et dernier SIREN traité. Sans cette trace, une interruption peut créer un trou silencieux ou retraiter plusieurs milliers de lignes.
Le seuil de recette est concret: 20 pages simulées, 1 interruption volontaire, zéro doublon persistant, zéro trou de fenêtre et un redémarrage documenté depuis le bon `searchAfter`.
Découper les requêtes volumineuses
La documentation formalités indique une limite technique à 10 000 résultats et explique l'usage d'un endpoint count pour savoir si le nombre de résultats dépasse ce seuil. Les formalités quotidiennes peuvent atteindre 15 000 à 20 000 éléments.
Le connecteur doit donc découper par dates, départements, secteurs ou autres filtres autorisés, au lieu de laisser une seule requête chercher tout un mois. Le découpage devient un objet de run.
Si une fenêtre dépasse 10 000 résultats, alors le traitement est à bloquer et à recouper avant appel de masse. Cette règle évite les boucles coûteuses, les 429 et les reprises impossibles à expliquer.
6. Rediffusion, deleted et données sensibles
Respecter diffusion commerciale et diffusion INSEE
La documentation formalités rappelle que la réutilisation doit respecter les données personnelles, et qu'un déclarant peut s'opposer à l'usage de ses données à des fins de prospection commerciale via la variable `diffusionCommerciale`.
Elle rappelle aussi que certaines entreprises qualifiées non diffusibles par l'INSEE ne peuvent pas être rediffusées par un rediffuseur, avec une information portée par `diffusionINSEE`. Le mapping doit traduire ces contraintes.
Si un export marketing ignore `diffusionCommerciale` pendant 7 jours, alors le seuil de conformité est dépassé et l'export est à bloquer. La purge aval doit être prévue avant la première synchronisation.
Traiter deleted comme une instruction
Les documentations actes et comptes annuels signalent les suppressions par la variable `deleted` à true dans les métadonnées. Si un rediffuseur avait téléchargé le document, il doit le supprimer selon la règle rappelée.
Le connecteur doit donc distinguer document vu, document téléchargé, document supprimé, document purgé et preuve de purge. Sans ce cycle de vie, la recherche différentielle ne sert pas vraiment à maintenir le référentiel documentaire.
Si plus de 3 documents marqués `deleted` sur 30 jours restent visibles dans un outil aval, alors le seuil de risque est dépassé. Le rollback doit retirer le fichier et laisser une trace compréhensible.
Limiter l'empreinte documentaire
Une intégration mature ne télécharge pas tous les actes et tous les bilans. Elle commence par la question métier: preuve de dépôt, contrôle de forme juridique, document obligatoire, alerte sur modification ou enrichissement analytique.
La conservation doit porter une durée, un motif, un propriétaire et une règle de purge. Les fichiers PDF sont lourds, sensibles et difficiles à relire quand leur origine disparaît du contexte.
Le signal faible apparaît quand le stockage documentaire grandit plus vite que les décisions utiles. L'équipe archive, sauvegarde et protège des fichiers que personne n'utilise, ce qui augmente coût et risque.
Un bon cadrage fixe donc des règles d'économie documentaire: métadonnée seule par défaut, PDF seulement si la décision l'exige, durée de conservation proportionnée, chiffrement, contrôle d'accès, purge testée et preuve de retrait. Cette sobriété réduit la charge d'exploitation sans affaiblir la conformité.
7. Codes retour, quotas et erreurs
Distinguer auth et habilitation
Les codes retour communément utilisés dans les documentations INPI incluent 200, 400, 401, 403, 429 et 500. Un 401 signale que l'utilisateur n'est pas authentifié, tandis qu'un 403 signale un manque d'habilitation.
Le back-office doit traduire ces réponses. Une clé expirée, un token absent, une habilitation insuffisante ou un endpoint réservé ne demandent pas la même action, ni le même propriétaire de correction.
Si un 403 est traité comme une donnée absente, alors le flux est à bloquer. L'API n'a pas dit que l'information n'existait pas; elle a dit que l'appelant ne pouvait pas effectuer la requête.
Organiser 400 et 500
Un 400 indique au moins une erreur dans la requête: filtre invalide, paramètre mal construit, date incohérente ou variable non acceptée. Un 500 signale une erreur inattendue du serveur et doit déclencher un mode dégradé.
Le connecteur doit enregistrer la requête normalisée, les filtres, la fenêtre de dates, le curseur et le SIREN concerné, afin que l'équipe puisse rejouer ou isoler le problème sans perdre la fenêtre différentielle.
Le seuil de recette est simple: 4 erreurs 400 simulées, 2 erreurs 500 simulées, zéro mutation métier, un retry borné et une escalade claire. Sinon, le go-live reste prématuré.
Traiter 429 comme une limite de run
Les documentations actes et comptes annuels mentionnent un 429 lorsque les quotas journaliers de l'utilisateur sont dépassés, avec des limites indiquées à 10 000 appels API/IHM ou 10 000 Mo pour ces familles documentaires.
Le worker doit arrêter les relances immédiates, mettre les dossiers en attente, préserver le dernier curseur fiable et reprendre quand la fenêtre de quota le permet. Continuer à appeler aggrave la dette de reprise.
Si plus de 3 réponses 429 en 24 heures relancent la même fenêtre différentielle, alors le seuil de risque run est dépassé et la cadence est à corriger avant de télécharger de nouveaux documents.
La planification doit aussi protéger les usages humains. Les traitements nocturnes peuvent attendre, tandis qu'un dossier fournisseur bloquant, une revue conformité urgente ou une purge documentaire demandée par le support doivent garder une priorité claire. Cette file différenciée évite qu'un rattrapage massif empêche une décision métier immédiate, et elle donne au responsable d'exploitation un levier simple pour suspendre les lots lourds sans arrêter les contrôles essentiels. La consigne doit être visible dans le runbook, le dashboard et les messages support. Elle réduit aussi les escalades internes inutiles et répétées.
8. Plan d'action API INPI Entreprises
Cartographier sources et décisions
Commencez par lister les décisions qui consomment INPI: validation fournisseur, contrôle juridique, veille acte, vérification de compte annuel, fraude, conformité, enrichissement CRM, scoring risque, dossier achat et reporting direction.
La cartographie doit relier chaque décision à une source: formalité JSON, état historique, acte PDF, compte annuel, attestation RNE, bénéficiaire effectif sous habilitation ou API Entreprise. Cette séparation évite les droits flous.
Le livrable attendu tient dans une matrice: endpoint, SIREN, filtres, date, pageSize, searchAfter, donnée reçue, donnée affichée, donnée conservée, donnée purgée, owner, quota, retry, rollback, message support et impact métier.
- À valider d'abord: SSO, token Bearer, SIREN, endpoint, famille documentaire, droit d'accès et finalité du dossier.
- À bloquer avant ouverture: tout téléchargement PDF sans motif, durée de conservation, trace et règle de suppression.
- À corriger avant extension: tout `deleted`, 403 ou 429 traité comme une simple absence de donnée métier.
- À différer volontairement: les flux différentiels trop larges qui dépassent 10 000 résultats sans découpage fiable.
Écrire les contrats de réponse
Le deuxième jalon consiste à écrire les contrats: entreprise trouvée, état historique trouvé, document disponible, document supprimé, compte confidentiel, token absent, habilitation manquante, requête invalide, quota atteint et erreur serveur.
Chaque contrat doit préciser input, output, responsabilités, seuils, journalisation, idempotence, retry, queue, endpoint, payload conservé, fichier téléchargé, message agent, message client, décision autorisée et rollback.
Le contrat doit contenir un cas nominal et un cas dégradé par famille: SSO refusé, Bearer expiré, `pageSize` invalide, `searchAfter` perdu, `deleted` reçu, PDF indisponible, compte confidentiel, résultat supérieur à 10 000 et 500 serveur.
Il doit aussi préciser qui tranche quand la réponse est ambiguë: conformité, juridique, achats, finance, support technique, data steward ou responsable sécurité. Cette responsabilité évite que l'arbitrage reste caché dans un job nocturne.
Construire monitoring et preuves
Le troisième jalon porte sur l'exploitation: volume par endpoint, taux 200, erreurs 400, 401, 403, 429, 500, nombre de PDF, poids téléchargé, documents supprimés, curseur courant, âge de fraîcheur et backlog de fenêtres.
Les alertes doivent dire quoi faire. Si 429, alors attente et réduction de cadence. Si `deleted`, alors purge. Si 403, alors revue d'habilitation. Si fenêtre trop large, alors découpage par dates ou filtres.
La preuve doit être lisible hors logs bruts: SIREN, endpoint, token applicatif, date, fenêtre, curseur, statut, document, confidentialité, donnée conservée, purge éventuelle, décision métier et propriétaire.
Limiter la première ouverture
La première mise en production doit prouver un périmètre court: recherche entreprise, état historique, un acte PDF, un compte annuel, un flux différentiel, un `deleted`, un 403, un 429 et un rollback documentaire.
Le go-live doit être conditionné par des critères vérifiables: token isolé, habilitation relue, filtres validés, `pageSize` borné, `searchAfter` sauvegardé, suppression testée, dashboard prêt et support capable de relire un cas.
Le risque est de croire que l'open data légal suffit. Une intégration API INPI mature sait aussi ne pas télécharger, ne pas rediffuser, ne pas fusionner et ne pas décider quand le droit ou la preuve documentaire est insuffisant.
9. Exemple API INPI en production
Contrôler un fournisseur avant validation
Prenons un portail achat qui valide un fournisseur par SIREN. Le back-office interroge `/api/companies/{siren}`, vérifie l'état RNE, récupère les pièces utiles, puis rattache l'entreprise à un dossier de conformité.
Le scénario nominal paraît fluide, mais les variantes coûtent cher: token expiré, 403 sur une donnée non habilitée, acte supprimé, compte confidentiel, 429 pendant une reprise, état historique nécessaire ou recherche différentielle incomplète.
Le bon résultat n'est pas seulement une validation verte. Le dossier doit montrer SIREN, source, endpoint, date, document utilisé, droit d'affichage, donnée purgée, statut, décision fournisseur et action support autorisée.
Décider ce qui bloque le go-live
Cas concret: le flux différentiel indique qu'un acte précédemment téléchargé est désormais `deleted`. Le portail ne doit pas le laisser accessible; il doit retirer le fichier, conserver la trace et signaler la purge.
Le seuil de lancement doit être lisible: zéro PDF sans finalité, aucun `deleted` ignoré, aucun 403 contourné, aucun 429 sans attente, aucun token partagé sans owner et aucun compte confidentiel téléchargé par défaut.
Cette discipline protège l'équipe autant que le fournisseur. Elle donne une preuve exploitable sans transformer le SI en répertoire documentaire incontrôlé, coûteux à sécuriser et pénible à auditer.
Afficher la preuve dans le dossier
La fiche fournisseur doit présenter une chronologie simple: SIREN saisi, appel INPI, source RNE, document consulté, statut, éventuelle suppression, décision métier, propriétaire et prochaine action.
Les statuts visibles doivent rester peu nombreux: vérifié, en attente, document indisponible, document supprimé, compte confidentiel, habilitation requise, quota atteint, erreur serveur, revue juridique et action interdite.
Si un agent ne peut pas expliquer la décision en moins de 15 minutes, alors le connecteur n'est pas prêt. La preuve doit suivre le dossier, pas rester enfermée dans un téléchargement ou une console d'exploitation.
10. Recette, seuils et rollback
Tester les familles coûteuses
La recette doit couvrir les familles qui coûtent en production: SSO refusé, Bearer expiré, SIREN absent, état historique, document supprimé, compte confidentiel, 400, 401, 403, 429, 500, curseur perdu et fenêtre supérieure à 10 000.
Chaque test doit produire une preuve complète: endpoint, méthode, filtre, fenêtre, statut HTTP, quota, token applicatif, fichier, métadonnée, champ purgé, owner, décision, message agent, message client et rollback possible.
Le seuil d'acceptation peut être simple: si une même famille revient sur 7 jours sans cause documentée, alors le flux est à corriger avant toute extension. Cette règle protège conformité, achats, finance et support.
Séparer recette juridique et recette plateforme
La recette juridique vérifie finalité, habilitation, diffusion commerciale, suppression, confidentialité, statut fournisseur et message support. La recette plateforme vérifie SSO, token, pagination, différentiel, PDF, stockage, monitoring et purge.
Une réponse technique peut être correcte mais injustifiable si la finalité manque. Inversement, un écran métier rassurant peut masquer un document supprimé encore accessible dans un stockage aval.
Cette revue doit produire une décision écrite. Le ticket de recette doit dire quelle action est autorisée, quelle action reste interdite et quel indicateur prouvera que RNE, document et support racontent la même histoire.
Préparer rollback et mode dégradé
Le rollback peut prendre plusieurs formes: retirer un PDF, restaurer un état précédent, remettre une fenêtre différentielle en attente, invalider une décision fournisseur, purger une donnée, régénérer un token ou suspendre un endpoint.
Le mode dégradé doit rester juste. Une erreur INPI temporaire peut demander attente ou revue manuelle, mais elle ne doit pas valider un fournisseur si la décision dépend réellement d'une pièce ou d'une formalité récente.
Si, après 30 jours, l'équipe retrouve encore des `deleted` ignorés, des fenêtres perdues, des 429 répétés, des PDF sans finalité ou des 403 contournés, alors le seuil de priorité est dépassé et le run est à corriger.
Auditer les décisions réelles
L'audit des premières semaines doit partir de décisions réelles: fournisseur accepté, document purgé, compte refusé, état historique consulté, habilitation bloquée, flux différentiel repris ou téléchargement annulé.
Chaque cas doit être résolu avec les écrans disponibles, sans intervention de la personne qui a développé le connecteur. Si l'équipe doit ouvrir le JSON brut pour comprendre le document retenu, l'observabilité est trop faible.
Le seuil de sortie peut être concret: 8 dossiers relus en moins de 15 minutes, 8 décisions support cohérentes et zéro correction hors procédure. Si une réponse dépend d'un souvenir projet, la documentation est à corriger avant volume.
11. Erreurs fréquentes API INPI
Traiter le RNE comme une simple fiche
La première erreur consiste à traiter le RNE comme une fiche entreprise enrichie. Les formalités, documents, états historiques, suppressions et droits de rediffusion créent un cycle de vie plus exigeant qu'un simple pré-remplissage.
Le bon réflexe consiste à écrire la décision attendue avant l'appel: vérifier, télécharger, purger, bloquer, attendre, historiser, escalader ou refuser. Sans décision claire, l'API ajoute une preuve que personne ne sait gouverner.
Si un agent peut télécharger un acte sans dossier associé, alors l'architecture est trop ouverte. Le document doit rester rattaché à une finalité, un owner et une durée de conservation.
Oublier deleted et diffusionCommerciale
La deuxième erreur consiste à synchroniser les nouveautés sans traiter les suppressions et restrictions. Une donnée supprimée ou non réutilisable peut rester exposée longtemps dans un CRM, un stockage ou un export commercial.
Le support doit savoir dire "à purger", "à masquer", "à conserver comme preuve", "à demander sous habilitation" ou "à ne pas utiliser en prospection". Ces statuts ne peuvent pas rester dans une note technique.
Si plus de 3 dossiers sur 30 jours demandent de retirer un document déjà diffusé, alors le seuil de qualité support est dépassé et la règle de purge est à corriger avant extension.
Sous-estimer la recherche différentielle
La troisième erreur consiste à lancer un différentiel large sans stratégie de fenêtre, sans endpoint count, sans curseur fiable et sans contrôle des trous. Le flux fonctionne en démonstration puis devient fragile au premier volume.
Le connecteur doit conserver fenêtre, `pageSize`, `searchAfter`, dernier SIREN, compteur, erreurs, poids téléchargé et heure de reprise. Cette discipline transforme une boucle API en processus exploitable.
Si plus de 1 fenêtre différentielle sur 7 jours doit être rejouée manuellement, alors la reprise est à corriger. Le flux doit pouvoir repartir sans perdre ni dupliquer la preuve juridique.
Questions fréquentes API INPI
Que faut-il cadrer avant une intégration API INPI Entreprises ? Il faut cadrer SSO, token Bearer, SIREN, formalités JSON, actes PDF, comptes annuels, états historiques, différentiel, `pageSize`, `searchAfter`, `deleted`, diffusion commerciale, habilitation, stockage et purge.
API INPI Entreprises remplace-t-elle API Sirene ? Non. API Sirene porte le référentiel SIREN/SIRET INSEE, tandis que les APIs INPI/RNE portent les formalités, actes, comptes et données légales issues du Registre national des entreprises.
Pourquoi le champ deleted est-il critique ? Parce qu'un document supprimé doit être retiré s'il avait été téléchargé. Le connecteur doit donc traiter la suppression comme une instruction de cycle de vie, pas comme une simple métadonnée.
Dawap peut-il industrialiser API INPI dans un workflow conformité ? Oui. Dawap peut cadrer accès, mapping, différentiel, PDF, comptes annuels, rediffusion, suppression, monitoring, retries, tableaux de bord et passation support pour rendre l'API exploitable sans dette de run.
Guides complémentaires API INPI
Pour distinguer l'identité administrative de l'entreprise du cycle de vie RNE, relisez l'intégration API Sirene. Sirene sécurise SIREN, SIRET et établissement; INPI ajoute formalités, actes, comptes annuels et règles de rediffusion.
Pour les démarches publiques proches, consultez aussi l'intégration API Entreprise, l'intégration API Particulier et l'intégration API data.gouv.fr. Ces lectures aident à séparer open data, habilitation, données protégées et preuve documentaire.
La landing API services publics et Open Data permet ensuite de rattacher API INPI aux autres briques publiques, tandis que la page intégrateur INPI Entreprises précise l'accompagnement possible sur RNE, actes, comptes annuels, synchronisation, rediffusion et gouvernance.
La priorisation doit rester pragmatique: commencer par le workflow où l'absence de preuve coûte le plus, où la purge est la plus sensible, où le support perd le plus de temps et où la décision peut être relue simplement par juridique, achats, finance, conformité, audit, assistance et pilotage.
Conclusion: intégrer API INPI sans dette de run
Une intégration API INPI fiable ne se juge pas au nombre de documents récupérés. Elle se juge quand chaque formalité, acte, compte, suppression, habilitation, fenêtre différentielle et décision peut être expliqué par les équipes qui exploitent le RNE au quotidien.
Le bon ordre reste clair: sécuriser le SSO, protéger le token Bearer, choisir les endpoints, limiter les téléchargements, traduire les erreurs, sauvegarder les curseurs, traiter `deleted` et documenter la conservation minimale.
La valeur vient aussi du refus des raccourcis. Il faut laisser en attente les documents sans finalité, les données non rediffusables, les fenêtres trop larges et les décisions qui nécessitent une habilitation ou une revue juridique.
Dawap peut vous aider à transformer API INPI Entreprises en workflow légal robuste, observable et utile au métier avec notre accompagnement en intégration API, depuis l'accès SSO et les endpoints RNE jusqu'aux actes PDF, aux comptes annuels, aux suppressions, aux dashboards et aux runbooks de production.
