Le problème classique du formulaire unique
Un manager procurement abandonne une commande de 12 000 € parce que le champ « Raison sociale » réclame un numéro de TVA. Pendant ce temps, un particulier qui achète un T-shirt à 19 € se retrouve face à six champs professionnels obligatoires. Ce scénario, tiré d'un article publié sur DEV Community, illustre parfaitement le piège du formulaire de checkout universel : trop générique pour être efficace, trop rigide pour être maintenable.
La réaction instinctive ? Dupliquer le template. Un checkout pour les particuliers, un pour les professionnels. Résultat : chaque mise à jour fiscale ou changement de gateway de paiement doit être répercutée deux fois, la cohérence s'érode, et le taux d'abandon mobile explose.
Il existe une approche plus solide : la divulgation progressive pilotée par la logique conditionnelle.
Concevoir pour l'intention, pas pour le cas universel
Le principe est simple : afficher d'abord le minimum vital (nom, adresse, paiement), puis révéler les champs métier uniquement lorsque l'acheteur indique explicitement qu'il achète pour une entreprise.
Cette séquence — simplicité consommateur d'abord, conformité professionnelle ensuite — repose sur trois règles opérationnelles :
- Défaut minimaliste : le checkout de base n'expose que les champs nécessaires à 90 % des acheteurs.
- Déclenchement explicite : une case à cocher ou un toggle « Achat professionnel » active dynamiquement les champs TVA, SIRET, raison sociale.
- Validation contextuelle : les règles de validation (champs requis, formats) s'appliquent uniquement aux champs visibles au moment de la soumission.
Sur WooCommerce, ce pattern se met en place efficacement via un plugin dédié comme Advanced WooCommerce Checkout Field Editor, qui permet de gérer la visibilité conditionnelle des champs sans toucher aux templates PHP.
Trois points techniques à ne pas négliger
1. Valider côté serveur, toujours
La logique conditionnelle côté client (JavaScript) améliore l'UX, mais elle ne constitue jamais une validation suffisante. Un utilisateur peut désactiver JS, un bot peut poster directement sur l'endpoint. Il est impératif de répliquer les règles de validation en PHP, dans un hook woocommerce_checkout_process :
add_action('woocommerce_checkout_process', function () {
if (!empty($_POST['is_company_purchase'])) {
if (empty($_POST['billing_vat_number'])) {
wc_add_notice(
__('Le numéro de TVA est obligatoire pour un achat professionnel.', 'mulertech'),
'error'
);
}
}
});
Cette double validation garantit la cohérence des données en base et évite les commandes incomplètes qui bloquent la comptabilité.
2. Prévoir un fallback sans JavaScript
Sur des connexions dégradées ou des navigateurs restrictifs, le JS peut ne pas s'exécuter. Le fallback consiste à rendre les champs professionnels visibles par défaut en CSS, puis à les masquer via JS au chargement. Ainsi, sans JS, l'utilisateur voit tous les champs — dégradé gracieux plutôt qu'erreur silencieuse.
/* Visible par défaut (fallback no-JS) */
.company-fields { display: block; }
/* JS masque au chargement si non sélectionné */
document.addEventListener('DOMContentLoaded', () => {
const companyFields = document.querySelector('.company-fields');
if (companyFields) companyFields.style.display = 'none';
// Rétablir à l'activation du toggle
});
3. Tester en mobile-first, pas en dernier recours
Le taux d'abandon sur mobile est systématiquement plus élevé que sur desktop. Testez le checkout conditionnel sur des vrais appareils (pas uniquement dans le DevTools du navigateur) en vérifiant :
- Le comportement du clavier virtuel lors de l'apparition dynamique des champs
- Le scroll automatique vers les champs révélés
- La lisibilité des messages d'erreur inline
Un champ qui apparaît en dehors du viewport sans scroll automatique est aussi invisible qu'un champ absent.
Mesurer l'impact : les KPI à suivre
Mettre en place la logique conditionnelle sans mesurer revient à optimiser à l'aveugle. Voici les indicateurs à suivre avant/après le déploiement :
| KPI | Outil recommandé | Objectif |
|---|---|---|
| Taux d'abandon checkout global | GA4 / Funnel | Baisse significative |
| Taux d'abandon par segment (B2B vs B2C) | Segment / Matomo | Alignement des deux courbes |
| Temps moyen de complétion du formulaire | Hotjar / FullStory | Réduction sur mobile |
| Taux d'erreur de validation | Logs WooCommerce | Proche de zéro côté serveur |
Un delta de quelques points de pourcentage sur l'abandon checkout peut représenter des dizaines de milliers d'euros de chiffre d'affaires récupéré sur un site à volume modéré.
Conclusion : un seul formulaire, bien pensé
La logique conditionnelle n'est pas une astuce cosmétique — c'est une décision d'architecture. Un formulaire unique, adaptatif, avec validation serveur robuste et fallback sans JS, est infiniment plus maintenable que deux templates divergents. Il est aussi plus honnête vis-à-vis de l'expérience utilisateur : on ne pénalise pas un particulier pour les besoins d'un acheteur professionnel.
Si vous gérez un checkout WooCommerce hybride et que vos taux d'abandon restent élevés, c'est souvent le bon endroit pour commencer l'investigation.
💡 Source originale : How Conditional Logic Fixed a Hybrid WooCommerce Checkout Mess — NEXU WP sur DEV Community.