jonas18121/recherche-entreprises-bundle
PHP package for searching French companies through the recherche-entreprises API. Query by name, SIREN/SIRET, or location and receive structured business results for list cards, autocomplete, and search pages.
Architecture fit: The package is a thin API client wrapping the French government's Recherche d'entreprises (company search) API, exposed via three lookup dimensions (name, SIREN, postal code). Architecturally it is a peripheral data-access dependency, not a core domain component — it fits as an infrastructure adapter behind a service interface rather than being called directly from controllers or Livewire/Inertia components. The presence of a console command suggests the intended (and better) usage pattern is batch/enrichment jobs rather than synchronous request-path lookups.
Integration feasibility: Low friction to install (composer require jonas18121/recherche-entreprises-bundle) but several integration unknowns remain unresolved by the release notes. The package is published under a -bundle name — Symfony terminology — while being assessed for a Laravel stack; it is unclear whether it ships a Laravel service provider and config file or requires manual container wiring. Timeout is configurable, which is a good signal, but there is no stated support for retries, rate limiting, caching, pagination, or authentication headers.
Technical risk: Elevated for a v0.1.0, single-maintainer package. Key risks: (1) upstream API dependency — the Recherche d'entreprises API has usage quotas and is a public-sector service subject to change; the client offers no abstraction for schema drift; (2) no declared Laravel/PHP version support matrix; (3) unknown test coverage and no CI signal mentioned; (4) no caching layer, so every lookup is a live network call against a rate-limited public API; (5) abandoned-package risk is real for a personal-namespace v0.1.0.
Key questions:
Stack fit: Compatible in principle with any Laravel 9+/PHP 8.x codebase — it is a plain HTTP client wrapper with no exotic dependencies implied. The natural placement is a dedicated CompanyLookup service class that owns the package client, is bound in a service provider, and is the only thing application code touches. This keeps the third-party namespace out of controllers, jobs, and domain logic, and makes later replacement a one-file change.
Migration path: Greenfield — no incumbent implementation to migrate from. Recommended path: wrap first, adopt second. Build the internal interface against the operations we actually need (lookup by SIREN for enrichment, search by name for admin/onboarding flows), then implement it with this package. That sequencing means the v0.1.0 API surface is never load-bearing; if the package stalls, we swap the adapter without touching callers. Persist fetched company records locally so lookups are not repeated per request.
Compatibility: Pin to an exact version (0.1.0) and commit the lockfile — do not use a caret constraint on a 0.x package, where minor bumps are permitted to break. Validate PHP/Laravel compatibility in CI before merge. Since the package name implies Symfony bundle conventions, confirm early whether framework bootstrapping is automatic or manual; if manual, the effort is trivial but the config surface must be documented internally.
Sequencing:
Maintenance: The heaviest operational cost is not the package code but the upstream API. Assume we own the wrapper and the upgrade path; budget a recurring review (quarterly) of the pinned version and the upstream API changelog. Treat this as a dependency with a plausible exit, not a foundation — the abstraction layer is the mitigation, and it should be in place before the first production call.
Support: Single-maintainer, personal namespace, v0.1.0. Internal support burden falls on us: no vendor SLA, no guaranteed response on issues. Escalation path is effectively "fork it." Confirm the licence permits forking and that the repository is public before relying on that fallback. Designate one engineer as the internal owner.
Scaling: Every uncached lookup is an outbound HTTPS call to a rate-limited public API. At low volume (admin search, nightly enrichment of a few hundred companies) this is fine. At request-path volume it becomes a latency and quota problem — p95 will be dominated by network time and 429s will surface to users. Mandatory mitigations: cache in Redis/DB with per-lookup-type TTLs, batch via the console command for bulk enrichment, and never call synchronously from a user-facing page without a cache check in front.
Failure modes:
Ramp-up: Roughly half a day for a Laravel developer to integrate and wrap; the real time is in the spike (verifying live API behaviour and error shapes) and in building caching and fixtures. Documentation is currently the release notes only, so write a short internal README covering config, the three lookup modes, error handling contract, and the caching policy before this is used by anyone beyond the original integrator.
How can I help you explore Laravel packages today?