Loi de Tesler sur une landing page : la complexité ne disparaît pas, elle change de camp

« On a simplifié le formulaire, il ne reste que l’email. » La phrase revient dans presque tous les projets de refonte, et elle est à moitié vraie. Le formulaire est plus court, c’est certain. Mais le budget, le secteur, l’effectif et l’échéance qui ont quitté l’écran n’ont pas cessé d’être nécessaires : quelqu’un devra les obtenir plus tard, par téléphone ou par email de relance. La complexité n’a pas disparu, elle a changé de propriétaire. C’est exactement ce que décrit la loi de Tesler — l’un des angles morts les plus coûteux de l’optimisation de landing pages.

La loi de Tesler, ou la conservation de la complexité

Cette loi porte le nom de Larry Tesler, informaticien américain passé par le Xerox PARC dans les années 1970 — où il a contribué aux travaux d’interaction homme-machine à l’origine du copier-coller et des interfaces sans modes — puis par Apple. C’est là, en défendant l’idée d’un cadre applicatif générique auprès de la direction et des éditeurs de logiciels, qu’il formule la loi de conservation de la complexité : dans tout système, il existe une part de complexité irréductible ; elle ne peut pas être éliminée par le design, seulement déplacée. La seule vraie question de conception devient alors : qui va la porter — l’utilisateur ou le concepteur ? Précision que la vulgarisation escamote souvent : ce n’est pas un résultat expérimental, mais un principe né de la pratique. Sa valeur n’est pas prédictive, elle est diagnostique. Elle fournit la question à poser devant chaque « simplification » : où est passée la complexité que nous venons de retirer de la page ?

Ce que la recherche apporte, en revanche, c’est la mesure de ce que coûte cette complexité une fois qu’elle atterrit chez l’utilisateur. Dans une étude publiée en 1988 dans la revue Cognitive Science, le psychologue John Sweller a posé les bases de la théorie de la charge cognitive : la mémoire de travail a une capacité limitée, et l’effort consacré à des opérations étrangères à la tâche — la charge cognitive extrinsèque — se fait au détriment des ressources disponibles pour la tâche elle-même. Sur une landing page, chaque décision que le visiteur prend à votre place — deviner dans quelle catégorie il entre, reconstituer un prix, arbitrer entre trois formules mal différenciées — consomme une attention qui n’ira pas à votre offre. Notre guide de la charge cognitive sur une landing page détaille ce mécanisme, et notre article sur la loi de Hick en donne la version chronométrée.

Le formulaire court ne supprime rien, il déménage

Le cas type. Une landing page B2B demandait sept champs : nom, email, téléphone, entreprise, effectif, budget, échéance. Après « simplification », il en reste deux. Le taux de soumission monte — c’est mécanique, et c’est l’arbitrage que chiffre notre article sur le nombre de champs d’un formulaire. Mais rien de ce qui a disparu n’était décoratif : l’effectif routait le lead vers le bon commercial, le budget écartait les demandes hors cible, l’échéance priorisait les rappels. Ces informations seront désormais obtenues lors d’un premier appel de dix minutes, multiplié par le nombre de leads — y compris ceux qui n’auraient jamais dû arriver jusque-là. La complexité a bien été conservée ; elle a quitté la page pour l’agenda de l’équipe commerciale. Ce n’est pas forcément une mauvaise décision : à faible volume et forte valeur de contrat, l’appel qualifie mieux qu’un menu déroulant et vend en même temps. L’erreur est de croire qu’on a supprimé quelque chose. Un formulaire raccourci sans que personne ne reprenne en aval ce qu’il ne demande plus produit le même résultat qu’un formulaire trop long : des leads qui n’aboutissent pas, pour une raison moins visible.

Trois allègements qui n’en sont pas

Le prix remplacé par « sur devis »

Retirer les prix est présenté comme une simplification : plus de grille à lire, un seul bouton « Demander un devis ». La complexité tarifaire n’a pourtant pas bougé d’un millimètre — elle est transférée au visiteur sous une forme bien plus coûteuse pour lui : évaluer si votre offre est dans ses moyens sans le moindre repère, laisser ses coordonnées pour le découvrir, puis attendre. Celui qui refuse ce marché ne se plaint pas, il va voir un concurrent qui affiche ses prix. Notre comparatif prix visible ou sur devis détaille les cas où le devis reste justifié — la justification tient alors à la structure de l’offre, jamais à un gain de simplicité.

Le tunnel en plusieurs étapes

Découper un formulaire de dix champs en quatre écrans courts fonctionne, et notre guide du formulaire en plusieurs étapes explique pourquoi. Mais soyons lucides sur ce que fait ce découpage : il ne retire aucune complexité, il l’étale dans le temps. Le total d’informations demandées est identique ; ce qui change, c’est l’effort perçu au départ et l’engagement progressif qui pousse à terminer. Déplacement légitime, mais contre-productif dès qu’on s’en sert pour cacher le volume réel de la demande : un visiteur qui découvre à l’étape trois sur six qu’on lui réclamera son SIRET et trois justificatifs abandonne avec le sentiment d’avoir été trompé.

Le sélecteur de plan et le choix de créneau

Deux composants où le transfert saute aux yeux. Un sélecteur qui aligne quatre formules SaaS, chacune avec quatorze lignes de fonctionnalités et une bascule mensuel/annuel, demande au visiteur le travail de modélisation que l’éditeur n’a pas voulu faire : deviner quel palier correspond à son usage. Le concepteur peut l’absorber en posant une question en amont (« combien d’utilisateurs ? »), en mettant en avant le plan correspondant et en reléguant le tableau comparatif plus bas. Même logique pour un rendez-vous : afficher un calendrier vide sur trois mois, c’est demander au visiteur d’arbitrer à votre place ; proposer trois créneaux concrets avec un lien « voir d’autres horaires », c’est absorber l’arbitrage et n’ouvrir la complexité qu’à ceux qui en ont besoin.

Qui doit absorber la complexité ?

La réponse par défaut est simple : le concepteur, parce qu’il ne paie le coût qu’une fois, là où l’utilisateur le paie à chaque visite. Écrire la fonction qui déduit le pays depuis l’adresse IP prend une heure ; une liste de deux cents pays coûte quelques secondes et un abandon marginal à chaque visiteur, indéfiniment. Il existe une raison plus profonde de ne pas compter sur sa bonne volonté : l’utilisateur ne fournit pas l’effort supplémentaire, même quand celui-ci lui serait bénéfique. Une étude de Wayne Gray et Wai-Tat Fu publiée en 2004 dans Cognitive Science a montré que des utilisateurs préfèrent s’appuyer sur une information approximative gardée en mémoire plutôt que d’aller consulter une information parfaite disponible à l’écran, dès lors que la consulter demande un effort perceptivo-moteur légèrement supérieur — et cela même lorsque ce raccourci augmente leur taux d’erreur. Les auteurs parlent de « contraintes souples » : de très petites différences de coût suffisent à orienter le comportement, souvent à l’encontre de ce que le concepteur avait prévu. Un visiteur ne cherchera donc pas votre grille tarifaire dans un PDF et ne comparera pas quatre offres ligne à ligne : il prendra le raccourci disponible — deviner, choisir au hasard, ou partir. Toute complexité laissée à sa charge est instable, elle sera contournée plutôt qu’absorbée.

Absorber côté concepteur : ce qui marche

• Des valeurs par défaut choisies, pas neutres — la formule la plus vendue pré-sélectionnée, la facturation annuelle cochée si c’est votre recommandation. Un bon défaut supprime une décision sans supprimer la liberté de la prendre.
• Le pré-remplissage depuis l’URL — campagne, ville, offre ou email connus passent en paramètres et s’injectent dans le formulaire, comme le détaille notre guide du pré-remplissage via l’URL : autant d’informations que le visiteur ne ressaisit pas alors que vous les déteniez déjà.
• La détection automatique — fuseau horaire, langue du navigateur, pays, format de numéro de téléphone : des données déductibles sans rien demander, à condition de pouvoir corriger une détection erronée.
• Les champs conditionnels — n’afficher la question sur le nombre de véhicules qu’aux visiteurs ayant coché « flotte d’entreprise ». Notre article sur le formulaire conditionnel montre comment rester court pour chacun tout en collectant, au total, plus d’informations qualifiées.
• Calculer plutôt que demander — le TTC à partir du HT, la mensualité à partir du montant et de la durée, l’économie annuelle à partir du plan choisi. Un calcul fait par la page est un calcul que le visiteur ne fait pas de tête, ou renonce à faire.
• Différer ce qui peut l’être — adresse de facturation, SIRET ou préférences détaillées se demandent après l’inscription, quand l’utilisateur est déjà engagé et que la complexité pèse beaucoup moins.

Le fil conducteur reste le même : ne jamais demander une information que l’on peut déduire, calculer, deviner correctement par défaut ou reporter à plus tard. C’est le sens exact de la loi de Tesler appliquée à la conversion — non pas « faire simple », qui est un vœu, mais « décider où va la complexité », qui est un arbitrage. Le template liste d’attente SaaS de LanderKit pousse cet arbitrage à l’extrême : une seule action possible, un champ visible, et tout le reste — source de trafic, langue, fuseau, contexte de campagne — capté sans que le visiteur ait quoi que ce soit à faire. Les 10 templates LanderKit (89 € l’unité, 229 € le pack complet) sont livrés en code source Next.js : la complexité y est déjà placée du côté du code, à l’endroit où elle ne se paie qu’une fois.