Recherche Entreprises Bundle Laravel Package

Technical Evaluation

Architecture fit — recherche-entreprises-bundle is a Symfony bundle wrapping the French government's recherche-entreprises API (company search, association flag, and now company directors). For a Laravel codebase this is a framework mismatch: bundle conventions (Kernel registration, Extension/Configuration trees, compiler passes) do not map onto Laravel's service providers. The value is in the underlying API client, not the bundle wiring. The package is also pre-1.0 (v0.1.1), so the public surface is not yet stable.

Integration feasibility — Composer-installable and small, so a spike is cheap. Two viable paths: (a) install the bundle and reuse its client classes behind a thin Laravel service provider, or (b) skip the bundle and call the same API via Laravel's HTTP client. Path (b) is usually lower-friction for a Laravel team and avoids Symfony version constraints leaking into the app. The new dirigeants feature and the corrected isAssociation flag broaden the use cases (KYC, compliance screening, B2B enrichment), which raises the payoff of doing the spike.

Technical risk — Medium. Risks: (1) pre-1.0 semver — a feature landed in a patch release (0.1.0→0.1.1), signaling loose versioning discipline; (2) single-primary-maintainer project with two total contributors; (3) hard runtime dependency on a third-party public API (availability, rate limits, schema/ToS changes); (4) dirigeants returns personal data, so GDPR/PII handling and log redaction must be designed in; (5) the isAssociation fix confirms the upstream data model has had correctness bugs, so validation/fallbacks are warranted.

Key questions — What are the package's PHP/Symfony version constraints, and do they conflict with the target Laravel version? Does the upstream API require an auth key, and what are its documented rate limits and SLA? Is there a Laravel-native wrapper or first-party SDK? What is the test coverage behind the CI added in v0.1.1? How is isAssociation now derived, and is the old incorrect behavior cached anywhere downstream? What is the data-retention policy for dirigeants payloads?

Integration Approach

Stack fit — Poor-to-moderate out of the box (Symfony bundle in a Laravel app), good at the API-contract level. Best fit is to treat it as an API client, not a framework plugin: either consume the bundle's client services via a Laravel provider or reimplement the calls with Http:: and a small DTO layer. Avoid registering the bundle itself in a Laravel app.

Migration path — Phase 0: sandbox spike (1–3 days) installing v0.1.1, exercising search, isAssociation, and dirigeants, and recording actual response shapes and rate-limit behavior. Phase 1: wrap the client in a Laravel service provider with config publishing, caching, and retry/backoff. Phase 2: introduce a feature flag and route a single low-risk consumer (e.g., internal admin lookup) through the adapter. Phase 3: promote to production consumers; add dirigeants only after the core search path is stable.

Compatibility — Verify PHP constraint against the app's runtime, and Symfony component versions against what Laravel already pulls in (Laravel ships several Symfony components, so conflicts are possible but often resolvable). Pin the exact version and lock it in CI. Expect to own a fork or a shim if a constraint conflict arises.

Sequencing — Correctness fix (isAssociation) → CI signal → new feature (dirigeants) is a sensible upstream order, and our integration should mirror it: stabilize the basic lookup and data validation first, then add directors. Do not adopt dirigeants in the same release as the initial integration; separate the risk.

Operational Impact

Maintenance — Low code volume but high vendor risk: early-stage project, two contributors, French-language issues/PRs, and no long-term support commitment. Mitigate with version pinning, an internal adapter layer that isolates the dependency, and a documented exit path to direct HTTP calls if the package stalls. Budget a small recurring review of upstream releases given the 0.x churn.

Support — Community-only. No commercial backing identified. Internal ownership must be explicit: one engineer accountable for the adapter and its tests. Upstream bug reports will be in French; plan for translation overhead on issues.

Scaling — Scaling is dominated by the upstream API, not by the package: rate limits, latency, and payload size (especially dirigeants) will gate throughput. Introduce response caching keyed by SIREN/SIRET, queue non-interactive lookups, and apply circuit breaking. The package itself adds negligible overhead.

Failure modes — Upstream API downtime or schema change; rate-limit exhaustion under bursty traffic; silent data-correctness regressions (the isAssociation bug is the template — add assertion tests on known entities); PII leakage of dirigeants into logs or analytics; Composer resolution breakage on Symfony/Laravel upgrades. Each needs a defined fallback (cached/stale response, degraded UI, alerting).

Ramp-up — Expect 1–2 sprints for a mid-level Laravel engineer to spike the API, build the adapter with caching and tests, and document contracts. The Symfony bundle conventions are the main learning cost and are largely avoidable by going adapter-first. French API documentation adds minor friction.