Lorsqu’on conçoit une interface numérique, une application ou un produit technologique, l’objectif est souvent de simplifier l’expérience utilisateur. Mais jusqu’où peut-on réellement simplifier sans altérer la finalité de l’interaction ? C’est précisément à cette question que répond la loi de Tesler, aussi appelée loi de la conservation de la complexité. Formulée par Larry Tesler, informaticien et designer chez Apple dans les années 1980, cette loi met en lumière un principe souvent méconnu du design : toute tâche complexe implique un minimum irréductible de complexité. Si elle n’est pas visible pour l’utilisateur, c’est qu’elle a été déplacée ailleurs, souvent du côté des développeurs ou des concepteurs. Comprendre cette loi, c’est reconnaître que le design ne peut pas tout simplifier sans conséquences. C’est aussi une invitation à équilibrer les charges cognitives entre les différentes parties prenantes d’un système d’interaction, en tenant compte des besoins réels des utilisateurs et des limites techniques des produits numériques.

L’origine et le fondement de la loi de Tesler

La loi de Tesler, également appelée « loi de la conservation de la complexité », a été formulée dans les années 1980 par Lawrence Gordon Tesler, plus connu sous le nom de Larry Tesler. Né en 1945 à New York et diplômé de l’université de Stanford, Tesler a commencé sa carrière au sein du célèbre Xerox PARC (Palo Alto Research Center), un laboratoire pionnier dans le développement de l’informatique moderne. C’est dans cet environnement d’innovation intense qu’il travaille sur des concepts qui deviendront la base des interfaces graphiques telles que nous les connaissons aujourd’hui, en particulier les notions de copier-coller et de manipulation directe.

En 1980, Larry Tesler rejoint Apple, à une époque où l’entreprise est en pleine effervescence autour du projet Lisa, puis du Macintosh. C’est dans ce contexte qu’il formalise sa réflexion sur la complexité des interactions homme-machine. En travaillant sur les interfaces utilisateurs, il constate que certaines fonctions, pour paraître simples en surface, nécessitent des traitements en coulisses de plus en plus sophistiqués. Il énonce alors un principe fondamental : « Toute complexité nécessaire dans un système ne disparaît pas — elle est simplement déplacée d’un point à un autre ». Cette idée deviendra plus tard connue sous le nom de loi de Tesler.

Cette loi s’inscrit dans une époque où l’informatique quitte le monde des ingénieurs pour entrer dans les foyers. L’objectif d’entreprises comme Apple ou Microsoft était alors de rendre les ordinateurs accessibles au grand public. Mais plus on cherchait à simplifier l’expérience utilisateur, plus les développeurs devaient assumer une charge technique importante. Tesler, en tant que designer et ingénieur, était aux premières loges pour observer ce transfert de complexité. Contrairement à d’autres lois de l’interaction comme :

• La loi de Hick : qui mesure le temps nécessaire pour faire un choix en fonction du nombre d’options disponibles.
• La loi de Fitts : qui prédit la vitesse d’un mouvement en fonction de la distance et de la taille de la cible à atteindre.

la loi de Tesler ne s’intéresse pas à un aspect ponctuel de l’interaction, mais à une dynamique globale : la répartition inévitable de la complexité dans l’ensemble du système. Elle dépasse le simple cadre du design pour englober l’architecture logicielle, la logique métier, la maintenance et l’expérience utilisateur dans son ensemble. Pour illustrer ce concept de manière concrète, on peut considérer plusieurs situations où la simplicité apparente cache une grande sophistication technique :

• Application mobile de messagerie : Pour l’utilisateur, envoyer un message semble instantané. En réalité, des protocoles de chiffrement, des règles de synchronisation multi-appareils et des mesures de sécurité renforcées sont activés à chaque action ;
• Formulaire simplifié de souscription : Seuls trois champs sont visibles pour l’utilisateur (nom, e-mail, mot de passe), mais le système vérifie en arrière-plan les doublons, la validité syntaxique, les critères de sécurité, et génère automatiquement un compte avec des permissions précises ;
• Recherche prédictive dans un site e-commerce : l’utilisateur tape quelques lettres, et des suggestions intelligentes apparaissent en temps réel. Ce résultat suppose un traitement algorithmique complexe, une indexation constante de la base de données produits et des capacités d’analyse linguistique avancées.

Dans chacun de ces cas, l’interface masque la complexité, mais elle ne l’élimine pas. Celle-ci est simplement absorbée par le code, l’infrastructure ou les processus métier. La loi de Tesler agit ici comme un rappel : toute décision de simplification doit être pensée dans un cadre systémique. On ne supprime pas la difficulté, on choisit simplement qui (ou quoi) en portera la charge.

La pertinence de cette loi ne s’est pas estompée avec le temps. Au contraire, dans une ère numérique dominée par l’intelligence artificielle, les objets connectés et les interfaces vocales, la tentation de rendre tout « invisible » ou « intuitif » est plus forte que jamais. Pourtant, plus les interfaces deviennent simples à utiliser, plus elles sont souvent complexes à concevoir, sécuriser et maintenir. C’est là toute la valeur de la pensée de Larry Tesler : Rappeler que la complexité n’est jamais un défaut en soi, mais un facteur qu’il faut apprendre à maîtriser et redistribuer intelligemment au sein d’un système d’interaction.

Implications concrètes de la loi de Tesler pour les designers et les développeurs

Appliquer la loi de Tesler dans un projet numérique, c’est comprendre que la simplicité ressentie par l’utilisateur n’est jamais le fruit du hasard, mais le résultat d’un arbitrage technique et conceptuel. Cette loi rappelle qu’il est illusoire de vouloir faire disparaître toute complexité : elle existe toujours quelque part dans le système. L’enjeu n’est donc pas de l’éliminer, mais de choisir délibérément où elle doit se loger. C’est cette répartition réfléchie de la complexité qui permet de créer des expériences fluides, sans pour autant compromettre la robustesse, la sécurité ou la cohérence du système.

Dans la pratique, cela signifie que les designers doivent collaborer en profondeur avec les développeurs, les ingénieurs systèmes et parfois même les équipes métier. Le design ne se limite pas à l’apparence visuelle : il doit intégrer une réflexion sur les contraintes techniques, les flux de données, les règles métier et les capacités du back-end. À l’inverse, les développeurs ne peuvent plus ignorer les impératifs d’ergonomie ou d’accessibilité. La loi de Tesler pousse à sortir d’une logique en silos pour adopter une approche globale, où chaque décision est évaluée à l’aune de ses effets sur l’ensemble du système. Voici quelques implications concrètes à intégrer dès la phase de conception :

• Limiter les décisions à l’utilisateur : Une interface bien pensée guide l’utilisateur en lui présentant uniquement les options pertinentes à un instant donné. Par exemple, afficher dynamiquement des champs en fonction des réponses précédentes peut alléger la charge cognitive. Mais cela nécessite une logique conditionnelle complexe côté interface et un suivi rigoureux des scénarios d’usage ;
• Anticiper les erreurs utilisateur : Une interface qui « pardonne » les erreurs (correction automatique, suggestions, messages de feedback clairs) doit intégrer des systèmes de validation puissants, capables d’identifier et de corriger les incohérences avant qu’elles ne perturbent l’expérience ou le traitement des données ;
• Concevoir des parcours guidés : Les assistants virtuels, les walkthroughs interactifs ou les formulaires étape par étape permettent de simplifier la navigation. Toutefois, leur conception requiert une cartographie précise des parcours utilisateurs, des scénarios alternatifs, et parfois des outils spécifiques pour le suivi et l’analyse de l’utilisation.

La logique de transfert de complexité peut être schématisée de manière simple à travers le tableau suivant :

Ce déplacement de la complexité doit être anticipé dès les premiers ateliers de conception fonctionnelle. Il est recommandé d’adopter des outils de prototypage avancés et des méthodologies agiles pour tester rapidement l’impact des choix de design. Un prototype peut sembler efficace sur le papier, mais révéler une explosion de complexité technique lors du développement. À l’inverse, certaines tâches complexes pour l’utilisateur peuvent s’avérer relativement simples à automatiser ou à prendre en charge en back-end. En ce sens, la loi de Tesler met en lumière une compétence souvent sous-estimée chez les concepteurs : la capacité à faire des compromis intelligents. Il ne s’agit pas seulement d’embellir une interface, mais de faire des choix stratégiques sur la manière dont le système va répartir les charges cognitives, les responsabilités et les risques. Un bon designer saura reconnaître qu’un raccourci offert à l’utilisateur peut impliquer une sophistication accrue du côté du système, et l’acceptera si cela améliore significativement l’expérience.

Pour les équipes de développement, cela suppose également une flexibilité et une communication continue avec le design. Il est souvent nécessaire d’ajuster l’architecture technique pour supporter une interface « propre », de gérer des exceptions multiples, ou encore de mettre en place des systèmes de contrôle qualité plus robustes pour éviter les effets de bord. Cette redistribution de la complexité exige des tests rigoureux, des phases de recette précises, et une documentation claire pour garantir la maintenabilité du projet à long terme. Enfin, il ne faut pas oublier que certaines formes de complexité sont bénéfiques. Par exemple, une légère difficulté à franchir une étape importante (comme la suppression d’un compte ou l’envoi d’un paiement) peut éviter des erreurs irréversibles. Dans ces cas, la complexité assumée devient une forme de friction positive, qui protège l’utilisateur et renforce la fiabilité du service.

Ainsi, la loi de Tesler n’est pas une contrainte, mais un cadre stratégique pour concevoir des produits numériques équilibrés. Elle invite à une coopération étroite entre design et développement, à une écoute attentive des besoins utilisateurs, et à une conscience aiguë des choix technologiques. Elle rappelle que la simplicité, si elle est bien pensée, est rarement le fruit d’une suppression, mais le résultat d’un déplacement judicieux de la complexité dans les couches invisibles du système.