Vu la grande complexité des applications interactives, des modèles ont été
rapidement proposés afin de séparer les différents aspects fonctionnels et
structurels des interfaces, et de guider leur conception et leur
implémentation. Les premières approches de type vertical comme Seeheim
ou Arch décomposent l'interface en plusieurs couches d'abstraction, de
l'utilisateur jusqu'au noyau fonctionnel. Malgré leurs apports théoriques, ces
modèles sont peu détaillés et encapsulent l'interaction en entrée et en sortie
bas-niveau dans une seule entité monolithique. Afin de rendre mieux compte des
caractéristiques des interfaces modernes et du paradigme de programmation
orientée-objet, les approches horizontales « à agents » comme MVC,
PAC et les interacteurs formels décomposent les interfaces en
réseaux d'entités de même nature. Les entrées, dispersées parmi les agents,
restent cependant confinées dans des objets monolithiques et ne sont toujours
pas décrites. Elles restent en outre confondues avec les sorties, hormis dans
le modèle MVC qui sépare les entrées des aspects graphiques mais sans
expliquer comment mettre en 
uvre cette séparation. Le modèle des
interacteurs de CNUCE suggère néanmoins des flux d'entrée qui transitent
d'un agent à l'autre pour être converties en données abstraites interprétables
par l'application.
Deux types de modèles se sont spécifiquement attachés à décrire l'interaction en entrée bas-niveau. Les modèles logiques de dispositifs comme GKS et PHIGS, dont l'objectif est l'indépendance vis-à-vis du matériel, divisent les dispositifs d'entrée en six classes. Les tâches d'interaction de Foley séparent de façon similaire les tâches applicatives en six classes génériques. Malgré leurs apports pratiques, et en dehors du fait qu'elles ont été construites pour des besoins d'interaction qui ne sont plus les mêmes aujourd'hui, ces classifications sont excessivement simplificatrices au vu de la grande variété des dispositifs (pour les premières) et des tâches existantes (pour les secondes). Les modèles physiques de Buxton et Card mettent au contraire l'accent sur la spécificité de chaque dispositif. Le premier propose une taxonomie basée sur des caractéristiques pragmatiques (nombre de dimensions, propriétés physiques captées) et le second décrit un dispositif d'entrée comme une composition de dispositifs élémentaires qui convertissent des grandeurs physiques en valeurs numériques. Ces modèles sont utiles pour comparer différents dispositifs ou en concevoir de nouveaux, mais n'ont eu que peu d'impact sur les applications et les outils de développement, où l'on recherche surtout la généricité et la portabilité. Seules les librairies d'accès bas-niveau aux dispositifs emploient des représentations de nature physique, où chaque dispositif concret est habituellement exposé comme une combinaison de dimensions continues et discrètes.
Aujourd'hui, le développement des applications interactives repose exclusivement sur les boîtes à outils graphiques, qui gèrent la majeure partie de l'interaction en entrée de façon interne. Les boîtes à outils conventionnelles, câblées pour une utilisation exclusive et stéréotypée de la souris et du clavier, sont les principales responsables de la rigidité des applications en termes d'entrées. Des boîtes à outils WIMP avancées comme Subarctic et Garnet/Amulet ont été proposées afin de décrire la gestion des entrées et l'interaction standard de manière claire et extensible, mais l'intégration de nouvelles techniques d'interaction nécessite en pratique des remaniements importants, et les dispositifs non-standard sont ignorés. Un certain nombre de boîtes à outils plus spécialisées prennent en charge des paradigmes d'interaction Post-WIMP spécifiques, telles les boîtes à outils gestuelles (Satin), parfois en exploitant des entrées non-standard comme l'extension multimodale de Subarctic (entrées de nature ambiguë) ou les boîtes à outils multi-pointeurs (MMM, Bimanual Whizz et MID). Le modèle d'interaction à base d'outils transparents a également donné lieu à un remaniement de la boîte à outils MMM et au développement de l'architecture CPN2000. Ces boîtes à outils emploient toutes cependant un modèle à événements conventionnel adapté à des dispositifs de type spécifique, et exploitent ces dispositifs de manière efficace mais figée.
Les boîtes à outils spécialisées dans l'interaction tangible (Phidgets) et la sensibilité au contexte (Context Toolkit), peu nombreuses vu la jeunesse de ces paradigmes, offrent une prise en charge souple mais de bas-niveau de senseurs et dispositifs simples de nature hétérogène. Le domaine de l'interaction 3D, plus mûr, offre depuis un certain temps des boîtes à outils permettant de connecter librement des canaux individuels de dispositifs d'entrée sophistiqués à des structures abstraites, habituellement à travers des flots de données (UGA, Inventor, TBAG, WorldToolkit). Ces structures sont cependant toujours des attributs d'objets 3D, les dispositifs pris en charge sont tous des périphériques 3D, et les techniques d'interaction qu'il est possible de décrire sont bien moins variées que celles de la 2D. Le modèle à flot de données sur lequel elles reposent offre néanmoins une grande liberté d'expression et se prêtent bien à des outils d'édition visuelle (Maya RTA, Blender, Virtools Dev) qui rendent la spécification de l'interaction en entrée en partie accessible à des non-programmeurs.
Le domaine de l'interaction 2D a également produit des éditeurs de comportements, mais qui reposent pour la plus grande part sur des modèles à contraintes peu adaptés à la description de l'interaction en entrée bas-niveau (Thinglab, Fabrik). Seul l'éditeur Whizz'Ed a su exploiter la grande souplesse offerte par les flots de données, initialement pour construire des interfaces animées, puis pour décrire certains mécanismes propres à l'interaction bimanuelle. Notons que des systèmes à transitions (automates à états finis, réseaux de Petri) ont été également employés pour décrire l'interaction de manière visuelle ou non: Petshop, par exemple, permet de construire interactivement des spécifications ICO à base de réseaux de Petri. Cependant, les systèmes orientés-contrôle que ces formalismes se proposent de décrire caractérisent mieux les techniques WIMP que les interactions Post-WIMP, essentiellement amodales et fortement concurrentes.
Pour résumer simplement, aucun modèle et aucun outil à ce jour ne prend en compte l'adaptabilité en entrée sous ses trois angles. Deux types d'approche ont été proposées pour améliorer la contrôlabilité : celle des boîtes à outils Post-WIMP, qui consiste à implémenter un modèle d'interaction efficace pour un certain type d'entrées, et celle des boîtes à outils 3D, qui consiste à profiter de manière simple de la richesse des dispositifs à dimensions multiples. La voie vers la configurabilité a été ouverte par les éditeurs d'interaction 2D et surtout 3D. Aucun de ces éditeurs, cependant, ne permet d'exploiter des techniques d'interaction Post-WIMP sophistiquées, ni de tirer parti de dispositifs multiples de nature hétérogène (par exemple, geste, parole et dispositifs 3D). Enfin, ni les outils de programmation ni les éditeurs interactifs n'offrent de solution adaptée à l'interaction avec des entrées appauvries.
Le problème de l'adaptabilité en entrée peut néanmoins être résolu en approfondissant les approches existantes et en tirant parti de leurs avantages respectifs. Dans le chapitre suivant, nous introduisons une métaphore pour décrire des interfaces intégralement configurables en entrée, et nous verrons comment cette métaphore mène tout naturellement à un modèle à flot de données, similaire à ceux des outils 3D ou de Whizz'Ed. Nous montrerons également en quoi les particularités de notre modèle et de nos outils en font une solution particulièrement efficace au problème de l'adaptabilité en entrée.