Colissimo Bundle Laravel Package

Technical Evaluation

Architecture fit. Despite being catalogued as a PHP package, this is a Symfony 2 bundle, not a Laravel package. Its functional surface is deliberately thin: it registers lexik/ws-colissimo — a SOAP client for La Poste's WSColiPosteLetterService — as a dependency-injection service and exposes credentials/sender config. There is essentially no domain logic in the bundle itself. For a Laravel stack, the bundle is architecturally irrelevant; the only reusable asset is the underlying SOAP library, which can be instantiated directly (constructor args: WSDL URL, WS-Security login/password, SOAP options) and wrapped in a Laravel service provider. That reframing matters for roadmap conversations: the decision on the table is "adopt a thin, unmaintained SOAP client for a single French carrier", not "adopt a package."

Integration feasibility. Low as shipped, moderate with adaptation. On Laravel: composer require lexik/colissimo-bundle will not boot (no AppKernel, no bundle registration, Symfony 2 container conventions). The viable path is to depend on lexik/ws-colissimo directly, verify it installs on the target PHP version, and require ext-soap in every deploy image. Feasibility then hinges entirely on two external factors outside engineering's control: holding a commercial La Poste/Colissimo contract that authorizes this SOAP service, and the WSDL still matching the live endpoint. Both must be validated with a sandbox spike before any estimate is credible.

Technical risk. High, on several independent axes. (1) Maintenance: 17 stars, 0 dependents, a 0.175 composite score, and a Symfony 2 target EOL since 2018 — treat as abandoned; we own the fork. (2) Platform: PHP 5.x/7.x-era code; PHP 8 compatibility is unverified and likely to require patching. (3) Vendor: La Poste can change WSDL, auth flow, rate limits, or endpoint with no notice to us. (4) Procurement: credentials are contract-bound, so this is a commercial dependency masquerading as a technical one. (5) Correctness: a 200 SOAP response can still carry business-level rejection messages in messages, so "integration works" is not the same as "labels are valid" — that gap is where support tickets live.

Key questions. Do we hold an active Colissimo contract, and does it authorize WSColiPosteLetterService specifically? Is La Poste steering new integrations to a REST/JSON API instead, which would make this investment obsolete on arrival? Does an existing OMS/3PL/aggregator already own label generation, and is this integration being proposed in the wrong system? What is our launch geography and volume — is direct-carrier integration justified versus an aggregator (Sendcloud, Boxtal, Shippo)? Who owns customs declarations and international address rules, and are they documented in French only? What is the sandbox and certification process with La Poste, and how long does it take? Is a private fork acceptable under our dependency policy, and who signs up to maintain it?

Integration Approach

Stack fit. Poor for Laravel as packaged. Good only for a legacy Symfony 2 app that already ships Colissimo parcels. For Laravel, the realistic shape is: lexik/ws-colissimo (or a hand-rolled WSDL client) behind a ShippingProvider interface inside our own service, with ext-soap provisioned in the runtime image and credentials in the secrets manager rather than config files.

Migration path. Recommend replace outright over contain and extract. Because the bundle contributes no logic, "migrating off it" is not a migration — it is writing a small adapter around the SOAP contract. Concretely: define ShippingProvider with createLabel(), track(), cancel(), quoteRate(); implement ColissimoProvider using a modern WSDL-driven client; keep an AggregatorProvider stub so the roadmap option of switching carriers stays open without a rewrite. If an existing Symfony 2 app must be kept alive, the inverse applies: pin the bundle, containerize, and wrap it behind the same interface so it can be excised later.

Compatibility. Gate the work on a checklist: PHP version supported by the client, ext-soap in all deploy targets including CI and worker images, valid WSDL reachable from the runtime network (egress/firewall), and credentials issued for the correct environment. Contract-test against the La Poste sandbox — authenticate, generate one DOM label as PDF, decode the base64 bordereau, retrieve tracking — before committing to a schedule.

Sequencing. (1) Confirm commercial access, credentials, and sandbox endpoint — this is the long-lead item and should start first because it is procurement, not engineering. (2) Spike the three core calls end-to-end. (3) Define the ShippingProvider interface and the Address/Parcel value objects that isolate Colissimo's associative-array payload shape. (4) Move label generation into a queued job at shipment creation, not the checkout request. (5) Persist decoded labels to object storage keyed by order ID; stream from there on reprint. (6) Ship behind a feature flag with a documented manual fallback (carrier portal) for the first weeks of volume. (7) Record a dated build-vs-aggregator decision so this does not become permanent by inertia.

Operational Impact

Maintenance. Effectively zero upstream. Budget recurring (not one-time) effort for patching an unmaintained SOAP client onto current PHP, monitoring La Poste WSDL/endpoint changes, certificate and credential rotation, and re-certifying after carrier-side changes. Treat the dependency as an internal fork with a named owner and a stated review cadence; an unowned fork is the most likely failure mode here.

Support. No vendor support, negligible community. Escalation splits into two distinct queues that must not be conflated in the runbook: our integration broke (internal engineering) versus carrier API changed or is down (La Poste API support, gated on our contract). Colissimo's own business error messages are the primary debugging signal, so log and surface them verbatim — silently swallowed messages will make every incident a fishing expedition.

Scaling. Throughput is governed by La Poste token lifetime and rate limits, not by application capacity — horizontal scaling of the app tier buys little. The real bottleneck is label/PDF generation latency, so design for token caching, bounded concurrency, and idempotency keys so a retry does not mint a duplicate bordereau (duplicates are billable and operationally messy). Do not regenerate labels on demand; generate once, persist, reprint from storage.

Failure modes. Expect SOAP timeouts, token/session expiry, WSDL drift, address-validation rejections, ext-soap missing from a newly built image, and credential-rotation outages. None are handled by the bundle or the thin library — retry with backoff, idempotent requests, and a dead-letter queue for failed shipments must be built by us. A failed label at dispatch time is directly customer-facing (missed pickup, delayed delivery), so a documented manual fallback is a launch requirement, not a nice-to-have. Also watch for silent-success on business rejections; validate that a decoded PDF is actually generated, not just that the call returned.

Ramp-up. The code surface is small — days for a competent PHP engineer to reach a working spike. The expensive part is domain knowledge: Colissimo product/service codes, French address rules, international customs declarations, label formats (PDF vs ZPL), and tracking-status semantics, much of it documented only in French. Realistically, a multi-week hardening effort once queueing, retries, observability, secrets handling, and the adapter boundary are included. The highest-leverage TPM action is forcing the interface boundary and the written build-vs-aggregator decision early — that converts what would be a permanent unmaintained dependency into a swappable, time-boxed bet.