Product Decisions This Supports
- Build vs. buy for French identifier validation. All nine checks (Siren, Siret, Nir, Rib, Iban, Bic, Vat, Naf, Phone) are checksum/format algorithms with non-obvious edge cases (Luhn, mod-97, NIR month/department rules, La Poste SIRET special cases). This package makes "buy" the default answer and frees engineering from maintaining hand-rolled validators that quietly drift.
- French market entry / expansion roadmap. A single dependency unblocks the compliance-sensitive parts of a France launch: B2B onboarding, supplier master data, invoicing, payroll/HR, and payment setup. If France is on the roadmap, this is a cheap de-risking move; if it is not, this is not a decision you need to make.
- Funnel design and error-message quality. Because each constraint exposes the core library's typed failure reason as both a message parameter and the violation code, PMs can decide to validate at the point of entry vs. defer, show a precise, human message ("SIRET checksum invalid" vs. "SIRET does not correspond to a registered establishment"), and still branch programmatically on the failure type for retries, help text, or support escalation.
- Compliance-adjacent feature scoping. French invoices require a valid SIRET; SEPA direct debits require a valid IBAN/BIC; HR onboarding touches NIR. Having these as first-class rules means compliance requirements can be scoped as validation work rather than bespoke integrations.
- Localization and support tooling. Machine-readable violation codes are the substrate for translated messages, analytics on which identifiers fail most, and self-serve correction flows — decisions that are painful to retrofit once validators return only booleans.
- Architecture choice: Symfony Validator constraints inside a Laravel codebase. This is the strategically interesting part of the release. It signals the constraints are usable outside Laravel's native validator, which matters if you have Symfony services, shared PHP packages, queue workers, or a future non-Laravel surface that must enforce the same rules. That is a build-vs-buy and an architecture-consistency decision, not just a feature.
Important scope boundary for PMs: these constraints validate form and checksum, not existence. A passing SIRET is not proof the company is registered (that is INSEE/SIRENE), and a passing VAT number is not VIES verification. Any product copy, onboarding gate, or trust signal must not overstate what a green check means.
When to Consider This Package
Adopt when:
- You collect French company identifiers (SIREN/SIRET/VAT), supplier or customer bank details (IBAN/BIC/RIB), French phone numbers, or employee NIR — especially in more than one of these areas, where the shared core pays for itself.
- You are on Laravel and want validation rules that fit existing form requests and validator pipelines with no new infrastructure.
- You also have Symfony Validator in the stack and want one rule set across both, rather than two divergent implementations.
- You need to act on why validation failed — differentiated messaging, retry logic, analytics, or support tooling — and a boolean is not enough.
- You would otherwise write these checks yourself, or you are currently shipping regex-only validation that lets bad identifiers through.
Look elsewhere or wait when:
- You only need one identifier. A single checksum is a small function; the dependency is not worth the supply-chain and upgrade surface.
- You need coverage beyond France (other national ID schemes, EU-wide VAT verification). The package is explicitly French.
- You need authoritative verification against a registry, name/address matching, or company enrichment. This is offline format validation; you need an API (INSEE, VIES, a KYC vendor) alongside it.
- You are sensitive to maturity risk. This is v0.1.0 — the first tagged release. The API surface is young, the changelog has no deprecation history, and the maintenance bus factor is unproven. Pin the version exactly, wrap it behind your own thin adapter or custom rule so you can swap it, and expect possible breaking changes before 1.0.
- Your platform cannot take a new Composer dependency, or your team has no appetite for a third-party validator in a regulated flow.
Adoption checklist: confirm PHP/Laravel and Symfony Validator version compatibility; confirm the package's own test coverage for the nine checks; verify behavior on the known awkward cases (La Poste SIRET, monégasque SIRET, NIR with 2A/2B departments, foreign IBANs); decide the fallback when validation fails in a flow that must not hard-block (e.g. allow submission with manual review).
How to Pitch It (Stakeholders)
For executives (30 seconds): "We need to validate French business identifiers — company registration numbers, VAT numbers, bank details, phone numbers — for onboarding, invoicing, and payments. Getting these checksums subtly wrong creates compliance exposure and bad data that's expensive to clean up later. A maintained open-source package now covers all nine checks with a standard interface, so we can add this in days instead of building and indefinitely maintaining it ourselves. Cost is one small dependency; the main caveat is that it's an early v0.1.0 release, so we'll pin the version and isolate it behind our own wrapper."
For engineering: "It's a thin, typed wrapper over a maintained core library, exposed as Symfony Validator constraints — so it works with Laravel's validator and with any Symfony Validator surface we have or add later. Every violation carries a typed failure reason as both a message parameter and the violation code, so we get precise user messaging and programmatic branching for free. Small surface, no new services, no runtime calls to external registries. It is v0.1.0: pin the exact version, add characterization tests for the nine checks and the known edge cases, and keep it behind our own rule/adapter so a swap or a breaking 0.x change is a one-file fix."
The one thing to say out loud in any stakeholder review: a passing check means the identifier is well-formed, not that the company, account, or number exists or is valid in a registry. If we communicate it any other way in the product, we own that overclaim.