Le champ optionnel de trop : la loi de Tesler appliquée à vos formulaires web

Un formulaire de contact avec cinq champs. Rien de méchant, en apparence. Nom, prénom, email, téléphone, message. Le développeur ajoute un menu déroulant "Objet de votre demande" avec douze options. Puis un champ "Société" marqué comme optionnel. Puis un captcha. Le taux de conversion du formulaire chute de 40 %. Le dirigeant demande pourquoi personne ne le contacte via le site. Le développeur répond que le formulaire fonctionne parfaitement.

Les deux ont raison sur leur terrain. Le formulaire marche, techniquement. Mais il échoue, commercialement. Ce décalage porte un nom : la loi de Tesler, ou loi de conservation de la complexité. Elle pose un principe simple et mesurable : dans tout système, il existe un seuil de complexité irréductible. La seule question qui compte, c'est qui la supporte. Le code, ou l'utilisateur.

Cette question n'est pas théorique. Elle a un impact direct sur le chiffre d'affaires, le coût du support client et la rentabilité de chaque euro investi dans un site web.

Ce que dit vraiment la loi de Tesler (et ce qu'on en retient mal)

Larry Tesler, ancien chercheur chez Xerox PARC puis chez Apple, a formulé ce principe dans les années 1980 : la complexité totale d'un système est constante. On ne la supprime pas, on la déplace. Soit le développeur absorbe la complexité dans le code, soit l'utilisateur la subit dans l'interface.

L'erreur fréquente consiste à réduire cette loi à un slogan de design : "faites simple". Le vrai message est plus nuancé. Il ne s'agit pas de tout simplifier à outrance. Il s'agit de choisir délibérément qui porte le poids de chaque décision.

Prenez un formulaire d'adresse. Vous pouvez demander à l'utilisateur de saisir manuellement son code postal, sa ville et son pays dans trois champs séparés. Trois champs, trois sources d'erreur, trois validations. Ou vous pouvez investir du temps de développement pour qu'une autocomplétion détecte la ville à partir du code postal. La complexité n'a pas disparu. Elle a migré de l'interface vers le code serveur. Le coût a changé de nature : moins d'abandons, plus de développement initial.

La loi de Tesler n'est pas un dogme de simplification. C'est un outil d'arbitrage économique.

Anatomie d'un formulaire qui tue la conversion

Chaque élément ajouté à un formulaire a un coût cognitif pour l'utilisateur. Ce coût est rarement évalué. Il devrait l'être.

Un champ obligatoire demande une action. Un champ optionnel demande une décision : "Est-ce que je dois le remplir ? Qu'est-ce que ça change si je ne le fais pas ?" Cette micro-décision, multipliée par trois ou quatre champs optionnels, crée une charge mentale mesurable. Des études en UX montrent qu'un formulaire passant de 4 à 8 champs peut perdre entre 25 % et 40 % de ses soumissions.

Les coupables les plus courants :

• Le menu déroulant de 200 pays alors que 95 % de votre audience est en France.
• Le champ "objet de la demande" avec des catégories que seul votre service interne comprend.
• Les messages d'erreur flous du type "Ce champ est invalide" sans préciser pourquoi.
• Le captcha visuel qui punit l'utilisateur pour prouver qu'il est humain.

Chacun de ces éléments déplace la complexité de votre back-office vers le cerveau du visiteur. C'est un transfert de charge qui se paie en taux d'abandon. Ce sujet a été traité en profondeur dans un article dédié sur les formulaires web qui tuent les conversions par rigidité, et les mécanismes détaillés ici en sont le prolongement direct.

Le vrai coût d'un champ : une équation à trois termes

La plupart des décideurs raisonnent en coût de développement : "Ajouter un champ, ça prend dix minutes." C'est exact pour le code. C'est faux pour le bilan global.

Le coût réel d'un champ dans un formulaire se calcule sur trois axes :

• Coût de développement et maintenance. Le champ lui-même, sa validation, le stockage de la donnée, son traitement en back-office. Faible à l'unité. Cumulatif sur la durée.
• Coût d'abandon. Chaque champ superflu réduit le taux de soumission. Si votre formulaire génère des demandes de devis et que chaque devis a une valeur moyenne de 500 euros, une baisse de 10 % du taux de conversion est directement chiffrable.
• Coût de support. Les champs mal conçus produisent des données inexploitables. Votre équipe recontacte le prospect pour clarifier. Temps passé, énergie gaspillée, image dégradée.

Additionner ces trois lignes change la perspective. Un champ "gratuit" en développement peut coûter des milliers d'euros par an en opportunités perdues et en temps de SAV. Le rapport de l'IGF sur la numérisation des démarches administratives souligne d'ailleurs que la complexité des formulaires numériques est identifiée comme un facteur direct de non-recours aux services en ligne, y compris dans le secteur public. Le problème n'est pas propre au privé : il est structurel.

Cette logique de coût caché touche d'ailleurs bien au-delà des formulaires. C'est le même mécanisme qui transforme un projet web prometteur en déception numérique qui érode le ROI quand les arbitrages techniques sont faits sans recul.

Où placer la complexité : la grille de décision

La question n'est jamais "faut-il supprimer la complexité ?" mais "qui est le mieux placé pour la gérer ?"

Voici une grille de décision applicable à chaque élément d'un formulaire ou d'une interface :

• L'utilisateur peut-il raisonnablement fournir cette information sans effort ? Si oui, le champ se justifie. Nom, email : légitime. Numéro de SIRET pour une demande de contact : disproportionné.
• L'information peut-elle être déduite automatiquement ? La ville à partir du code postal. Le pays à partir de l'adresse IP. Le format de téléphone à partir de l'indicatif. Chaque déduction automatique est de la complexité retirée à l'utilisateur et absorbée par le code.
• L'information est-elle réellement utilisée en aval ? Si personne ne lit le champ "Comment avez-vous entendu parler de nous ?", il n'a aucune raison d'exister. Auditez vos formulaires : dans beaucoup de PME, 30 % à 50 % des champs collectent des données jamais exploitées.

Cette grille a un corollaire important : sur-simplifier est aussi coûteux que sur-compliquer. Un formulaire réduit à un seul champ email génère du volume, mais des leads inutilisables. Votre commercial passe alors vingt minutes à qualifier ce que deux champs bien pensés auraient trié en amont. La complexité ne disparaît pas. Elle se déplace vers votre équipe de vente.

C'est un principe qui prend tout son sens dans le développement d'un outil métier sur mesure, où chaque champ, chaque écran et chaque automatisation est calibré pour que la complexité repose sur le système, pas sur les personnes qui l'utilisent.

L'UX excluante : quand la complexité devient un filtre invisible

Déplacer la complexité vers l'utilisateur ne fait pas que baisser la conversion. Dans certains cas, cela exclut des segments entiers de clientèle.

Un menu déroulant avec 200 options est difficile pour tout le monde. Il est inutilisable pour une personne qui navigue au clavier ou avec un lecteur d'écran. Un message d'erreur qui ne précise pas le problème bloque un utilisateur pressé. Il décourage définitivement un utilisateur peu à l'aise avec le numérique.

Le rapport de l'Assemblée nationale sur l'inclusion numérique rappelle que 13 millions de Français sont en difficulté face aux outils numériques. Ce chiffre ne concerne pas uniquement des personnes âgées ou isolées. Il inclut des dirigeants de TPE, des artisans, des commerçants. Votre formulaire trop complexe ne filtre pas seulement les prospects "pas motivés". Il filtre aussi des clients potentiels à forte valeur qui n'ont simplement pas la patience ou la compétence numérique pour se battre contre une interface mal conçue.

L'UX excluante est un budget caché qui ne figure sur aucun tableau de bord, mais qui impacte directement la rentabilité.

Je le constate régulièrement sur les projets que j'audite : les formulaires les plus performants ne sont pas les plus courts ni les plus longs. Ce sont ceux où chaque interaction est justifiée et chaque effort de l'utilisateur est récompensé par un retour clair.

Auditer ses formulaires : méthode concrète en cinq étapes

La loi de Tesler n'a de valeur que si elle se traduit en actions mesurables. Voici une méthode applicable à n'importe quel formulaire existant :

• Lister chaque champ et son usage réel. Pour chaque champ, identifiez qui utilise la donnée collectée et à quelle fréquence. Si la réponse est "personne" ou "on ne sait pas", le champ est un candidat à la suppression.
• Mesurer le taux d'abandon par étape. Un outil d'analyse comme Google Analytics ou Matomo permet d'identifier à quel champ les utilisateurs décrochent. Le champ problématique est rarement celui qu'on imagine.
• Calculer le coût par champ. Appliquez l'équation à trois termes : développement, abandon, support. Même une estimation grossière suffit à faire apparaître les aberrations.
• Tester la suppression ou l'automatisation. Retirez un champ optionnel pendant deux semaines. Mesurez l'impact sur le volume et la qualité des soumissions. Le résultat est souvent sans appel.
• Réécrire les messages d'erreur. Chaque message doit indiquer précisément le problème et la solution. "L'adresse email doit contenir un @" est utile. "Champ invalide" est une abdication.

Cette démarche ne prend pas des mois. Sur un formulaire de contact standard, une demi-journée d'audit et une demi-journée de corrections suffisent à produire des résultats visibles en quelques semaines.

Le piège de la sur-simplification

Il faut le dire clairement : la loi de Tesler ne justifie pas de tout supprimer. J'ai vu des refonte de formulaires aller trop loin. Un formulaire de demande de devis réduit à "Nom + Email" génère du volume, mais des leads si peu qualifiés que l'équipe commerciale passe plus de temps à trier qu'à vendre.

La complexité irréductible existe. Un formulaire de demande de prêt professionnel doit collecter des informations financières. Un formulaire de réclamation SAV doit identifier le produit concerné. Retirer ces champs sous prétexte de simplicité, c'est déplacer la complexité vers le service client, qui devra relancer chaque demande pour obtenir les informations manquantes.

Le bon arbitrage est toujours contextuel. Il dépend de la valeur du lead, du coût du traitement humain et de la capacité technique à automatiser la qualification. Un site qui reçoit 50 demandes par mois n'a pas les mêmes contraintes qu'une plateforme qui en traite 5 000.

Mon conseil : commencez par retirer les champs dont personne ne peut justifier l'existence. Puis mesurez. Puis ajustez. La méthode empirique vaut toujours mieux que le dogme, dans un sens comme dans l'autre.

La loi de Tesler ne dit pas que la simplicité est gratuite. Elle dit que la complexité a toujours un porteur. Le rôle du décideur est de choisir lequel. Celui qui coûte le moins cher au total n'est pas toujours celui qu'on croit.

Et vous, si vous additionniez le coût réel de chaque champ de vos formulaires, quel serait le premier que vous supprimeriez ?

Sources : Rapport de l'Assemblée nationale sur l'inclusion numérique Rapport IGF sur la numérisation des démarches administratives Rapport du Sénat sur la régulation numérique