Recherche Entreprises Bundle Laravel Package

Technical Evaluation

Architecture fit — framework mismatch is the headline. Despite the Laravel-shaped framing of this assessment series, philippe2463/recherche-entreprises-bundle is a Symfony bundle, not a Laravel package. For a Laravel shop the adoption question is effectively answered: there is no ServiceProvider, no auto-discovery, no facade contract, and no illuminate/* constraint to satisfy. The only transferable value is the source code as a reference implementation of an API client — endpoint paths, query parameters, pagination semantics — which the MIT license permits us to copy. For a Symfony shop the fit is conventional: a container-registered service wrapping symfony/http-client, sitting in the infrastructure layer as a read-only adapter to an external data source.

What product capability it actually unlocks. The package is a thin client over the French government's Recherche d'entreprises API, exposing lookup by name, SIREN, or SIRET with pagination and configurable client settings. In product terms that is a lookup primitive, not a compliance product. It plausibly supports:

• KYB / business onboarding (verify a company exists and matches the claimed identity)
• Vendor and supplier master-data validation
• CRM/account enrichment and deduplication
• Invoice and accounting validation for French B2B transactions
• Internal tooling and back-office search

It explicitly does not provide SIREN Luhn validation, legal-form normalisation, director/beneficiary data, financial statements, change monitoring, or any assurance layer. Any roadmap item promising "verified business identity" needs those built on top; the package shortens the first mile only.

Integration feasibility. High on technical surface area (small, framework-native, no published migrations or assets implied), low on verifiability. We have no composer.json, no changelog, no release notes, no stated Symfony/PHP version range, and no evidence of a test suite or CI. Feasibility should be treated as unproven, not "likely fine because it's small."

Technical risk.

• Adoption signal is at floor. Zero stars, zero dependents, single maintainer. There is no community hardening to inherit and no observable cohort of production users.
• Pre-1.0 churn. Semver permits breaking changes in minor bumps; pin exactly and assume a break before 1.0.
• Thin abstraction value. The wrapper is a few hundred lines at most. Its marginal value over an in-house client is days, not weeks — which lowers the risk tolerance it deserves, not raises it.
• The real dependency is the API, not the bundle. The upstream service is a government-run public API with no commercial SLA, no contractual uptime, and a rate-limit policy we cannot negotiate. That risk is incurred the moment we ship the feature, with or without this package.
• Data obligations. The underlying dataset is published under an open licence (Etalab/Licence Ouverte) with attribution expectations; the API also returns dirigeants (directors), which is personal data. If any roadmap item surfaces officer names, GDPR review is a gating item, not a checkbox.

Key questions.

1. Are we a Symfony or Laravel shop — and if Laravel, are we evaluating the API rather than this package?
2. What are the composer.json constraints for php, symfony/framework-bundle, and symfony/http-client, and do they intersect our runtime and our next upgrade target?
3. What does the service actually return — typed DTOs, arrays, or a raw response passthrough? Raw passthrough means we own all mapping and the abstraction is cosmetic.
4. How are API errors, empty result sets, and 429/503 responses distinguished? This determines whether we can safely gate onboarding on it.
5. Is there a test suite and CI at the tagged commit, and does it use recorded fixtures rather than live calls?
6. Which roadmap items depend on company lookup, and what is our manual fallback if the API is unavailable at the moment of onboarding?
7. Does the maintainer respond to issues, and is there a security disclosure path?

Integration Approach

Stack fit. Symfony 6/7 with symfony/http-client and PHP 8.1+ is the likely target and must be confirmed from composer.json, not the README. For a Laravel application: do not attempt to install it. Use Laravel's Http facade with a ~100-line client informed by the bundle's source, or wrap the API behind an interface we own. This is the cheaper and lower-risk path by a wide margin and should be the default recommendation unless the team is already on Symfony.

Migration path. Greenfield — nothing is installed. There is no migration, only an adoption decision. Run it as a two-track evaluation: (a) prove the API works for the roadmap item using a throwaway client, and (b) prove the bundle works using a timeboxed spike. If (a) succeeds and (b) fails, we still have a shippable feature and a reference implementation.

Compatibility. Verify against the exact Symfony and PHP patch versions we run, not just the major. Confirm whether the bundle auto-registers via config/bundles.php conventions or requires manual registration, and whether it publishes config. Do not call bundle classes directly from controllers or domain services — put our own CompanyLookup interface in front of it and let the implementation be swappable.

Sequencing.

1. Due diligence (half day): composer.json, service class inspection, test/CI status, license of both code (MIT) and data (Etalab), GDPR read on any officer data surfaced.
2. API-first spike (one sprint, one engineer): implement the lookup directly against the API on a scratch branch using recorded fixtures; measure latency, rate-limit behaviour, and result quality on real French company names.
3. Bundle spike (same sprint, second half): install behind the interface behind an APP_ENV=local guard; assert behaviour, not just container resolution.
4. Decision gate: named owner, explicit go/no-go criteria — the bar for adopting the wrapper should be "it demonstrably saves work over our own client and passes contract tests," which it likely will not clear on a Laravel stack.
5. Productionisation: interface + adapter, exact version pin, lockfile committed, fixture-backed contract tests, caching layer, kill switch to disable the feature if the upstream API degrades.
6. Fallback recorded: if no-go, document the rationale and the in-house client so the question is not reopened next quarter without new information.

Operational Impact

Maintenance. Assume we own the upgrade burden regardless of path. At 0.x with no changelog, breaking-release cadence is unknowable; budget a recurring line item for tracking and re-validation and add the repo to Dependabot/Renovate from day one. The larger maintenance surface, however, is the API contract and data model, which we own either way — plan for annual review of field semantics as the government dataset evolves.

Support. Two support relationships exist: the package maintainer (weak signal — single maintainer, thin docs, no visible triage) and the upstream public API (no commercial support, best-effort availability, community-known rate limits). The second matters more. Determine our acceptable outage behaviour before shipping: an onboarding flow that hard-blocks on this API converts a government-side incident into our own support queue.

Scaling. The load profile is dominated by external latency, not package overhead. Design accordingly: cache aggressively (company registry data changes slowly — 24h to 7d TTL is defensible; invalidate on write paths only), enforce a per-tenant rate limit, and never fan out N lookups inside a single request or job without bounding concurrency. If lookups sit in the signup path, they multiply across every new account; if in a queue, they scale with worker count and become a throughput lever.

Failure modes.

• Empty results indistinguishable from errors. The most dangerous failure for a KYB flow: an API error rendered as "no such company" blocks a legitimate business or, worse, a timeout rendered as "not found" silently degrades a compliance check. Force explicit three-state handling: match / no-match / upstream-unavailable.
• Fuzzy-match false positives. Name search returns similarly named entities; never assert identity from a name query — require an exact SIREN/SIRET confirmation with Luhn validation on SIREN.
• Stale status. A company may be dissolved or radiée while still present in our cached or stored copy. Store the observation timestamp and refresh before any compliance-relevant decision.
• Rate limiting and throttling. A retry storm during onboarding peaks can turn a soft limit into a hard block. Backoff with jitter, and degrade to manual review rather than failing closed with a wrong answer.
• Silent non-registration (Symfony only): bundle fails to register after a framework upgrade and the service stops resolving; guard with a behavioural smoke test.
• Abandonment. No upstream fix for a future Symfony release; we inherit the fork. MIT makes that tractable, and the code is small enough that forking is a genuine option rather than a bluff.

Ramp-up. Low. A competent Symfony engineer absorbs the package in an afternoon; the real ramp is domain literacy — SIREN vs. SIRET, Luhn validation, legal categories, and the fuzzy-match trap — which the package does nothing to teach. Budget a short internal write-up plus one demo so the constraint (use behind the interface; treat results as candidates, not facts) outlives the engineer who ran the spike.

Recommendation. Do not adopt the package as a dependency; do mine it as a reference implementation. Zero stars, zero dependents, a single maintainer, no changelog, and a framework mismatch with our stack mean the wrapper saves days while adding a permanent 0.x dependency with unverifiable upgrade cost — a poor trade. The underlying API is worth adopting for the lookup use cases above; build a thin, tested client behind our own interface, cache it, and treat every result as a candidate requiring SIREN-level confirmation. Re-evaluate the bundle only if we move to Symfony, the project reaches 1.0 with a changelog and CI, or it acquires verifiable dependents.