La douleur du processus manuel
Un agent immobilier passe en moyenne 45 minutes à assembler chaque exposé de bien : photos importées une par une, prix saisis à la main, logo repositionné, plan d'étage annexé, PDF exporté, classé, envoyé. Et si le prix change ? On recommence depuis le début.
C'est exactement le problème qu'a soumis un cabinet immobilier à Joshua, le développeur à l'origine de cette solution. L'agence utilisait déjà WordPress avec JetEngine pour gérer ses biens comme des custom post types. La voie était tracée : générer l'exposé directement depuis les données, en un clic, avec un rendu pixel-perfect conforme à la charte graphique.
C'est le type de mission où MulerTech intervient régulièrement : transformer un processus répétitif et chronophage en automatisation robuste, sans sacrifier la qualité visuelle.
La stack technique : WordPress, Dompdf, FPDI… et un problème inattendu
Les 80 % du plugin se sont construits rapidement :
- JetEngine expose les données du bien (adresse, prix, surface, photos) via les custom post types WordPress
- Un template HTML/CSS définit la mise en page de l'exposé
- Dompdf convertit ce template en PDF côté serveur
- FPDI fusionne les plans d'étage en PDF existants dans le document final
Une semaine de développement. Propre, maintenable, extensible.
Mais les 20 % restants ont failli tout faire capoter.
Le problème d'opacité de Dompdf
La page de couverture d'un exposé immobilier suit un standard visuel bien établi : une photo hero du bien, avec un dégradé sombre en overlay pour garantir la lisibilité du titre. En CSS, c'est trivial. En Dompdf… c'est une autre histoire.
Dompdf gère mal — voire pas du tout — certaines combinaisons d'opacity, de background avec transparence alpha et de superposition de calques complexes. Le rendu en production ne correspondait pas au design attendu. L'overlay s'affichait mal, les couleurs étaient faussées, et la charte graphique du client n'était plus respectée.
Plutôt que de chercher un contournement CSS fragile ou de changer de moteur PDF (avec tout ce que cela implique en refactorisation), le développeur a opté pour une approche chirurgicale : traiter l'image directement en PHP avant de l'injecter dans le template.
La solution : un blend Multiply pixel par pixel en PHP-GD
L'idée est simple dans son principe, exigeante dans son exécution :
- Charger la photo du bien avec PHP-GD
- Générer le dégradé overlay programmatiquement
- Appliquer un Multiply blend mode pixel par pixel — la même opération que fait Photoshop ou Figma quand on pose un calque en mode "Produit"
- Exporter l'image résultante et l'injecter dans le template HTML
La formule du Multiply blend est mathématiquement simple : pour chaque canal de couleur (R, G, B), résultat = (source × destination) / 255. Appliquée pixel par pixel sur toute l'image, elle produit un assombrissement naturel et fidèle à ce que le designer avait prévu.
// Principe du Multiply blend sur un pixel
$r = ($srcR * $overlayR) / 255;
$g = ($srcG * $overlayG) / 255;
$b = ($srcB * $overlayB) / 255;
La performance ? Sur une image de taille raisonnable (exposé immobilier, pas un poster 4K), le traitement reste largement dans les temps acceptables pour une génération à la demande. Pour les cas critiques, Imagick offre une alternative plus rapide via ses fonctions natives de compositing — mais GD suffit ici, et réduit les dépendances serveur.
Note : Cette approche est un excellent exemple de pragmatisme technique. Plutôt que de refactoriser toute la chaîne PDF pour contourner une limitation d'un composant, on résout le problème précisément là où il se pose, avec les outils disponibles.
Le ROI concret pour une TPE/PME
Mettons des chiffres sur la table.
| Situation |
Temps par exposé |
Volume mensuel estimé |
Coût mensuel (temps) |
| Avant (manuel) |
45 min |
40 biens |
~30 heures |
| Après (automatisé) |
< 1 min |
40 biens |
< 1 heure |
29 heures économisées par mois. Sur un salaire chargé de 35 €/h, c'est plus de 1 000 € de productivité récupérée chaque mois. Un plugin sur-mesure de ce type s'amortit en quelques semaines.
Au-delà du temps, les gains sont aussi qualitatifs :
- Zéro erreur de saisie : les données viennent directement de la base, pas d'une ressaisie manuelle
- Mise à jour instantanée : un prix change dans JetEngine, le prochain PDF généré est à jour
- Cohérence visuelle : la charte graphique est appliquée de façon identique sur chaque exposé
- Scalabilité : 10 biens ou 500, le process est le même
Ce que MulerTech peut faire pour vous
Ce type de projet — automatisation métier, génération documentaire, intégration de données — est au cœur de notre expertise PHP/Symfony et WordPress.
Nous intervenons sur plusieurs axes :
Audit de processus : identifier les tâches répétitives dans votre workflow qui peuvent être automatisées, estimer le ROI et prioriser les développements.
Développement de plugin sur-mesure : conception, développement et tests d'un plugin WordPress ou d'un module Symfony adapté à votre métier, avec rendu PDF, intégration de données et gestion des cas limites (comme le problème d'opacité Dompdf décrit ici).
Hébergement Docker optimisé : déploiement de votre solution sur une infrastructure conteneurisée, pour des performances stables et une maintenance simplifiée — un aspect souvent négligé mais critique quand la génération PDF est sollicitée en production.
Conclusion
Automatiser la génération d'exposés immobiliers depuis WordPress, c'est un cas d'école de ce que peut apporter un développement sur-mesure bien pensé. La stack est accessible (PHP, Dompdf, FPDI, GD), les gains sont immédiats et mesurables, et les obstacles techniques — comme les limites de rendu de Dompdf — se surmontent avec de l'ingéniosité plutôt qu'avec des outils coûteux.
Si vous avez un processus métier qui ressemble à celui décrit ici — répétitif, manuel, source d'erreurs — parlons-en. Un audit de quelques heures suffit souvent à identifier où automatiser en priorité.
Source originale : Why I Wrote a Pixel-by-Pixel Multiply Blend in PHP-GD to Beat Dompdf par Joshua sur DEV Community.
