# Expertise > Twenty skill areas described in the present tense: what I take on, how I actually work, and where the limits of each type of assignment sit. This section answers the question of choosing a supplier, not that of a live failure. - Source canonique : [https://allaux.fr/en/expertises](https://allaux.fr/en/expertises) - Langue : EN - Dernière mise à jour : 2026-08-03 ## You are comparing, and rightly so An expertise page gets read at a particular moment: the project is still open, several people are in the running, and someone has to decide who gets the work. At that stage, what separates candidates is not the length of a skills list — anyone can write "PrestaShop expert". What separates them is precision: does the person describe the problem like someone who has met it, and do they say where the difficulties are rather than smoothing them over. These twenty pages are therefore written in the present tense and in the first person, with no client reference. Each sets out a category of assignment: what it covers, how I go about it, what governs feasibility, and what falls outside the scope. A stated refusal is part of the useful information. ## How the section is organised The twenty skill areas fall into five domains. PrestaShop modules and payment: bespoke payment module, bespoke carrier module, point-of-sale payment integration. Performance and migrations: large catalogues, platform changes, multilingual sites and international search. Integrations and APIs, the largest domain: connecting to B2B supplier APIs, reverse-engineering undocumented APIs, API-first full-stack architecture, generating code from an OpenAPI specification, real-time multi-platform syncing, stock shared between several shops. Applications: bespoke Shopify apps, a controllable MCP server, a programmatic site generator. And applied AI and media: generated product FAQs, generated product video, agent orchestration, media extraction and processing, social distribution from a CRM. ## What this section is not It is not a portfolio of references. None of these pages says "I built this for such-and-such a brand": that register belongs to the delivered work section, which tells the story of projects actually built and put live. The separation is deliberate and strict. Mixing the two produces the most common pitch in the trade — theoretical skill presented as experience — and that is exactly what an informed buyer is trying to see through. In practice: if you want to know what I can handle, stay here. If you want to see what already exists, go to the delivered work. The two sections answer each other, and several expertise pages link to a project in the same domain. One more useful point: I work alone, on the code, the database and the server. That naturally bounds the kind of commitment possible. An assignment that assumes several people working in parallel does not fit, and I say so before the quote rather than after. ## Four common types of assignment - **E-commerce platform migration** — Changing platform while keeping catalogue, customers, orders and rankings: the method and the breaking points. ([/expertises/migration-de-plateforme-ecommerce](/expertises/migration-de-plateforme-ecommerce)) - **Bespoke PrestaShop payment module** — Integrating a payment method with no official module, including asynchronous callbacks. ([/expertises/module-paiement-sur-mesure-prestashop](/expertises/module-paiement-sur-mesure-prestashop)) - **Performance on a large catalogue** — What actually slows a shop with a high number of references down, and where to act first. ([/expertises/performance-catalogue-volumineux-prestashop](/expertises/performance-catalogue-volumineux-prestashop)) - **B2B supplier API integration** — Pulling stock, pricing and product data from supplier systems, including where documentation is missing. ([/expertises/integration-api-fournisseurs-b2b](/expertises/integration-api-fournisseurs-b2b)) ## Expertise or delivered work? > Here, skills in the present tense: what I take on and how. There, projects in the past tense: what was built and put live. The two sections do not overlap, and that is on purpose. ## FAQ ### How do I know whether my project fits one of these areas? Look at the nature of the problem rather than your sector. Syncing two systems, holding a large catalogue or integrating an unusual payment method works the same way whatever is being sold. If you hesitate between two pages, the project usually calls on both. ### Do these apply to PrestaShop, WooCommerce and Shopify alike? It depends on the subject. Payment and carrier modules, overrides and large-catalogue questions are tightly bound to PrestaShop. API integrations, syncing and automated processing are platform-independent. Each page says which. ### What happens if my need goes beyond what you take on? I say so. Some requests assume a team, a specific accreditation or permanent on-call cover, and I do not accept those. A reasoned refusal saves you more time than an accommodating quote. ### Do I need a written specification to start? No, a formal document is not required. What is required is being able to describe the business action: who does what, in what order, with which data and under what time constraint. Turning that into technical form is part of the job. ### Do you work as a subcontractor for agencies? Yes, that is a regular part of the work, particularly when an agency needs PrestaShop skill or an API integration for a one-off project. The frame is the same: I handle the technical part, end to end.