Une extension de réservation pour restaurants que nous avons développée affichait, juste après son activation, un simple écran de réglages avec une vingtaine de champs vides : nombre de tables, horaires d’ouverture, délai minimum de réservation, adresse e-mail de notification, et ainsi de suite. Sur les premiers retours clients, plus de la moitié des utilisateurs abandonnaient cet écran sans le terminer, laissant l’extension à moitié configurée, avant de nous contacter en pensant qu’elle « ne marchait pas ».
Le problème n’était pas la quantité de réglages, raisonnable pour ce type de fonctionnalité, mais la façon dont ils étaient présentés d’un seul bloc, sans aide ni valeur par défaut suggérée. Remplacer ce formulaire par un assistant de bienvenue en plusieurs étapes a changé la donne, en particulier en s’appuyant sur ce que WordPress sait déjà du site avant même de poser une question.
Étape 1 : rediriger sans bloquer
La première brique consiste à rediriger l’utilisateur vers l’écran d’onboarding immédiatement après l’activation, sans pour autant bloquer l’accès normal à l’administration. Ce comportement s’accroche sur register_activation_hook(), en positionnant un indicateur temporaire lu ensuite par admin_init :
register_activation_hook( __FILE__, function() {
set_transient( 'reservation_rediriger_onboarding', true, 30 );
} );
add_action( 'admin_init', function() {
if ( ! get_transient( 'reservation_rediriger_onboarding' ) ) {
return;
}
delete_transient( 'reservation_rediriger_onboarding' );
if ( wp_doing_ajax() || isset( $_GET['activate-multi'] ) ) {
return; // ne jamais rediriger lors d'une activation groupée
}
wp_safe_redirect( admin_url( 'admin.php?page=reservation-bienvenue' ) );
exit;
} );Le transient à courte durée de vie évite qu’une activation groupée de plusieurs extensions ne déclenche une redirection intempestive pour chacune d’elles, un piège fréquent que WordPress lui-même documente dans ses recommandations pour ce type d’écran.
Étape 2 : détecter avant de demander
Avant d’afficher le moindre champ, l’assistant interroge l’environnement du site pour proposer des valeurs déjà pertinentes plutôt que des cases vides. Pour l’extension de réservation, cela consistait à détecter le fuseau horaire déjà configuré dans les réglages généraux, la langue du site, et la présence éventuelle d’une extension de paiement déjà active.
$fuseau_detecte = wp_timezone_string();
$langue_detectee = get_locale();
$paiement_detecte = is_plugin_active( 'woocommerce/woocommerce.php' )
? 'woocommerce'
: 'aucun';
$suggestions = array(
'fuseau_horaire' => $fuseau_detecte,
'delai_min_minutes' => 30, // valeur par défaut raisonnable
'notif_email' => get_option( 'admin_email' ),
'integration_paiement'=> $paiement_detecte,
);Ce simple travail de détection réduit le nombre de champs réellement à remplir par l’utilisateur de plus de la moitié : le fuseau horaire, la langue et l’e-mail de notification n’ont plus besoin d’être ressaisis, seulement confirmés ou ajustés si nécessaire.
Étape 3 : des étapes courtes, une seule décision à la fois
Plutôt qu’un formulaire unique, l’assistant se découpe en trois écrans successifs, chacun avec une seule décision structurante à prendre : d’abord les horaires et le délai de réservation, puis les notifications, enfin un choix entre configuration manuelle complète ou import d’un fichier de tables existant si le restaurant utilisait déjà un autre système.
- Chaque étape valide uniquement ce qui la concerne, avec un état d’avancement clairement visible en haut de l’écran.
- Un bouton « configurer plus tard » reste visible à chaque étape, qui applique les valeurs suggérées par défaut et renvoie directement vers le tableau de bord principal de l’extension.
- La dernière étape termine toujours par une action concrète et immédiatement utile, ici la création automatique d’un premier créneau de réservation type, plutôt qu’un simple message de confirmation.
Ne jamais rendre l’assistant obligatoire
Un piège que nous avons rencontré sur une première version de cet assistant : bloquer l’accès au reste de l’administration tant que l’onboarding n’était pas terminé. Certains clients avaient besoin d’accéder immédiatement à une autre fonctionnalité du site et se retrouvaient coincés sur un écran qu’ils ne voulaient pas encore remplir. La version corrigée laisse l’assistant accessible à tout moment depuis le menu de l’extension, sans jamais forcer son passage.
Mesurer l’effet réel
Sur les projets où cet assistant a remplacé un formulaire de réglages classique, le taux de configuration complète dès le premier jour d’utilisation est passé d’environ 45 % à plus de 80 %, mesuré simplement en comptant les sites ayant renseigné au moins un créneau de réservation actif dans les vingt-quatre heures suivant l’activation. Le nombre de tickets de support liés à une extension perçue comme non fonctionnelle a baissé dans les mêmes proportions.
Une règle qui s’est imposée à nous projet après projet : chaque champ demandé à l’activation devrait pouvoir justifier pourquoi WordPress ne pouvait pas déjà le déduire lui-même. Si la réponse est « il aurait pu », le champ ne devrait pas figurer dans le formulaire initial.
En résumé
Un assistant de bienvenue bien conçu ne se limite pas à un habillage plus séduisant d’un formulaire de réglages : il s’appuie sur ce que le site sait déjà pour réduire la charge cognitive au strict nécessaire, tout en laissant toujours une porte de sortie vers une configuration manuelle ultérieure. C’est un investissement modeste en développement, mais dont l’effet se mesure directement sur le nombre de clients qui abandonnent avant d’avoir terminé leur première configuration.
