Le contexte
L'établissement diffuse des formations médicales à une audience internationale de praticiens. Son activité mélange deux mondes qui cohabitent rarement dans un même produit : d'un côté une boutique en ligne avec catalogue, stock, paiement, expédition physique et TVA ; de l'autre une plateforme pédagogique avec examens, suivi de progression et certifications nominatives.
Il s'agit d'une base de code déjà en production, vivante, avec de vrais clients : mon travail y est autant d'évolution et de fiabilisation que de développement de nouvelles fonctionnalités.
Ce que j'ai construit et fait évoluer
Catalogue profond
livres, cours, cycles, modules, packs et billets d'événements, avec taxonomie sur trois niveaux, étiquettes, avis et traductions par produit.
Double chaîne de paiement
PayPal et Revolut, avec webhooks de confirmation, gestion des commandes invité et validation des codes promotionnels.
Expédition internationale
intégration de deux transporteurs, calcul des frais selon la destination, bordereaux et enlèvements.
Moteur d'examens
questions à réponses prédéfinies, passage en ligne, correction, statistiques par étudiant et génération des certificats PDF.
Rapports planifiés
envoi automatique de synthèses d'activité configurables.
Marketing
synchronisation avec les outils d'e-mailing pour les campagnes et les messages transactionnels.
Documentation d'API auto-générée
un contrat toujours à jour pour les deux applications front (espace client et back-office).
Architecture & choix techniques
L'API Laravel sert deux applications distinctes — l'espace client et le back-office administrateur. Elle est donc pensée comme un produit à part entière, avec une documentation générée depuis le code plutôt que maintenue à la main : sur un projet où le front et le back évoluent à des rythmes différents, c'est ce qui évite les régressions silencieuses.
La génération documentaire est un sujet en soi. Selon la nature du document — facture, bordereau d'expédition, certificat — les contraintes de mise en page diffèrent radicalement, ce qui a conduit à faire coexister plusieurs moteurs PDF : un moteur léger pour les documents simples à fort volume, un moteur basé sur un navigateur sans interface pour les rendus complexes fidèles au HTML.
Les intégrations externes (paiement, transport, e-mailing) sont encapsulées derrière des services dédiés. Un transporteur qui change son API ne doit impacter qu'un seul fichier, pas l'ensemble du tunnel de commande.
Les défis techniques
Deux modèles économiques dans un seul produit. Un livre s'expédie, un cours se suit, un séminaire se réserve : trois cycles de vie qui partagent le même panier et le même tunnel de paiement.
Le calcul des frais de port. Les tarifs négociés varient selon la destination, le poids et le service — une logique de tarification à part entière, testée séparément du reste du tunnel.
L'internationalisation du catalogue. Les contenus produits sont traduits en base, pas seulement l'interface, avec un repli propre lorsqu'une traduction manque.
Faire évoluer une base vivante. Intervenir sur une application déjà utilisée en production impose des changements incrémentaux, réversibles, et une attention constante aux effets de bord.
La conformité des certificats. Un certificat nominatif doit être reproductible à l'identique des mois plus tard : les données de génération sont conservées, pas seulement le fichier produit.