Aller au contenu principal

Articles · Architecture

Architecture logicielle : concevoir des applications web durables

Articles sur l'architecture des applications web : multi-tenant, intégration au SI, migration de legacy, API et découplage.

À lire en premier

19 articles · page 1/2

Décideurs · Architecture · Stratégie · · 11 min

Comment fonctionne une synchronisation ERP ↔ e-commerce

Connecter un ERP à un site e-commerce paraît simple vu de loin : « il suffit de synchroniser les stocks ». En pratique, c'est une architecture à part entière — trois patterns d'intégration (push, pull, event-driven), une gestion fine des deltas, des reprises sur incident et des règles métier qui débordent toujours du standard. Cet article explique comment fonctionne réellement une synchronisation ERP ↔ e-commerce, quels pièges guettent (surventes, doublons, casse silencieuse) et comment cadrer et chiffrer un projet d'intégration sans mauvaise surprise.

Technique · Architecture · · 15 min

Application multi-tenant : quel modèle d'isolation ?

Concevoir une application SaaS impose tôt une décision structurante : comment isoler les données de chaque client. Cet article compare les quatre modèles multi-tenant, du plus mutualisé au plus cloisonné — base partagée avec discriminant tenant_id, schéma par client, base par client (silo) et instance par client. Pour chacun, les vrais arbitrages : cloisonnement et risque de fuite, RGPD, coût d'infrastructure et de migrations, noisy neighbor, personnalisation et passage à l'échelle. Avec une grille de décision, le côté concret côté Symfony (résolution du tenant par le host, filtre Doctrine en pooled, bascule de connexion DBAL en silo), un rappel que l'isolation ne s'arrête pas à la base mais s'étend aux fichiers et au stockage objet, au cache, à la recherche et aux files de messages, trois cas terrain anonymisés positionnés sur l'axe d'isolation, et un parti pris assumé : l'isolation par construction dès que les données sont sensibles.

Technique · Développement · Architecture · · 12 min

Mettre une API externe en cache sans servir de données périmées

Beaucoup d'applications dépendent d'une API qu'elles ne maîtrisent pas — un annuaire, un référentiel, un ticketing maison — lente et parfois indisponible. Le réflexe est de mettre un cache devant ; le piège est de cacher sans discernement et de servir des tickets fermés comme ouverts. Ce retour d'expérience montre que cacher une API externe n'est pas un problème de cache mais de classification : trier chaque donnée entre ce qui peut vieillir (l'annuaire) et ce qui doit rester vivant (les tickets). Avec, autour de cette décision, une façade qui centralise les appels — une couche anti-corruption —, une clé de cache normalisée par tri avant hachage, une dégradation gracieuse qui renvoie une valeur neutre quand l'API tombe, et une interface qui rend toute la chaîne testable hors-ligne.

Technique · Développement · Architecture · · 12 min

Un transport Symfony Mailer sur mesure pour une API d'emails interne

En grande entreprise, le SMTP direct est fermé : tous les emails passent par une API maison, authentifiée en OAuth2 et capable de signer ou chiffrer en S/MIME. Le réflexe est d'écrire un service qui appelle cette API partout — et de coupler cinquante endroits du code à une plomberie spécifique, en perdant au passage l'objet Email, les templates Twig et la file d'attente. Ce retour d'expérience montre le bon point d'extension : un transport Symfony Mailer derrière un DSN api://, qui traduit l'Email en payload, met son token OAuth2 en cache avec une marge et un retry sur 401, et reçoit ses options de signature par des en-têtes MIME consommés en chemin. Une centaine de lignes isolées dans la librairie partagée, et tout le code métier ignore que l'API existe.

Technique · Développement · Architecture · · 12 min

Un moteur de formules métier sans Excel ni eval()

« Il nous faudrait juste des formules, comme dans Excel. » Cette demande mène soit à eval() et ses failles, soit à un parseur maison ingérable — soit à Symfony ExpressionLanguage, un composant discret qui fait exactement ce travail. Ce retour d'expérience croise deux mises en production très différentes : une application de reporting d'un grand opérateur télécom qui a remplacé un classeur Excel — fonctions null-safe à la sémantique tableur, solveur itératif de vingt lignes qui converge sans graphe de dépendances — et une plateforme SaaS PIM où les utilisateurs écrivent eux-mêmes leurs règles — vocabulaire métier de soixante fonctions, validation à la saisie, cache d'AST partagé et dépendances déduites de l'arbre syntaxique. Avec, en fil rouge, la frontière que ce montage offre au métier : changer ses règles sans déploiement.

Technique · Architecture · · 13 min

Partager du code entre cinq applications sans les coupler

Copier-coller les mêmes utilitaires entre projets fait diverger le code ; la librairie commune mal conçue couple tout ce qu'elle touche. Entre ces deux échecs, il existe une voie étroite et documentée. Ce retour d'expérience décortique une librairie PHP interne partagée entre cinq applications Symfony d'un grand opérateur télécom : trois ans de vie, vingt-sept versions, un seul changement cassant dans l'API du quotidien. Au programme, les quatre décisions qui rendent la mutualisation rentable — soft dependencies pour ne payer que ce qu'on consomme, bridges interface + fake déterministe, rétrocompatibilité additive par défaut et changelog qui remplace les réunions — ainsi que les critères, tout aussi importants, pour savoir ce qu'il ne faut pas mutualiser.

Décideurs · Stratégie · Architecture · · 13 min

Akeneo vs PIM sur mesure : les limites du standard

Akeneo est le PIM open source de référence, mais il ne couvre pas tous les besoins. En tant que CTO d'un PIM sur mesure intégrant PIM, DAM, CMS et Hub, je compare les deux approches sur des critères concrets : flexibilité du modèle de données, intégration multi-canal, coût total sur 5 ans, dépendance éditeur et écosystème. L'article propose aussi l'approche hybride qui fonctionne le plus souvent : Akeneo pour le cœur PIM, du sur mesure pour les 20 % restants.

Décideurs · Architecture · Stratégie · · 14 min

Vendre sur les marketplaces via PIM et Shopping Feed

Vendre sur cinq marketplaces en parallèle, c'est maintenir cinq catalogues, synchroniser cinq stocks et traiter cinq flux de commandes. Cet article documente l'architecture Hub d'une plateforme PIM SaaS : flux produit vers Amazon, ManoMano, eBay et Cdiscount, import centralisé des commandes, synchronisation des stocks en quasi temps réel et orchestration des tâches planifiées. Un retour d'expérience de quatre ans sur l'automatisation du e-commerce multi-canal.

Technique · Architecture · Développement · · 15 min

Connecter un PIM à PrestaShop et Magento : REX

En tant que CTO d'une plateforme PIM/DAM SaaS, j'ai conçu et maintenu pendant quatre ans les connecteurs qui synchronisaient les catalogues des clients vers PrestaShop et Magento. Cet article détaille l'architecture en quatre couches (source → mapping → format → adapter), le traitement des variantes et déclinaisons, le streaming par générateurs PHP pour les gros catalogues, et les patterns de gestion d'erreurs qui ont survécu à la production.

Décideurs · Architecture · Stratégie · · 14 min

Connecter un SI à une application web sur mesure

Une application web sur mesure n'existe jamais en isolation. Elle doit s'intégrer au SI existant : ERP, CRM, SIRH, outils comptables. Cet article détaille les stratégies d'intégration (point à point, middleware, ESB, iPaaS), les patterns de synchronisation (temps réel vs batch, source de vérité, gestion des conflits), les contraintes techniques (formats hétérogènes, authentification, volumétrie) et les erreurs classiques (couplage fort, absence de monitoring, synchronisation bidirectionnelle mal maîtrisée).

Technique · Architecture · Infrastructure · · 12 min

Webhooks vs polling : intégrations temps réel

Quand deux systèmes doivent communiquer en temps réel, deux approches s'opposent : le polling (interrogation périodique) et les webhooks (notification push). Cet article compare les deux sur des critères concrets — latence, charge serveur, fiabilité, complexité d'implémentation — et détaille l'architecture d'un récepteur de webhooks robuste (idempotence, retry, signature, file d'attente). Il propose une stratégie hybride pour les cas où ni l'un ni l'autre ne suffit seul.

Technique · Architecture · Développement · · 15 min

Concevoir une API REST maintenable

Une API REST bien conçue est un investissement. Mal conçue, elle devient un frein pour chaque évolution et chaque nouveau consommateur. Cet article détaille les principes concrets d'une API maintenable : conventions de nommage des ressources, stratégie de versioning (URL vs header), pagination et filtrage, gestion d'erreurs standardisée (RFC 7807), documentation automatisée (OpenAPI), authentification (OAuth2, API keys) et bonnes pratiques de performance (cache HTTP, compression, rate limiting).

À propos de cette sélection

Une architecture se juge sur la durée : la facilité à faire évoluer l'application, à l'intégrer au système d'information, à la migrer sans tout arrêter.

Ces articles comparent les options (isolation multi-tenant, découplage, migration progressive) et expliquent dans quel contexte chacune se justifie.

Contact

Un sujet vous intéresse ?

Vous avez une question technique ou souhaitez approfondir un sujet abordé dans ces articles ? N'hésitez pas à me contacter pour en discuter.

Me contacter arrow_forward