Les copilotes IA ne suffisent plus, nous avons besoin d’un HUD IA

• La critique de la métaphore du « copilote » IA formulée par Mark Weiser en 1992 reste pertinente aujourd’hui
• Weiser défendait non pas un « assistant », mais une interface intégrée naturellement à l’expérience utilisateur
• Le concept de HUD (Head-Up Display) des avions modernes illustre bien cette philosophie
• Au lieu de l’automatisation ou d’une UI d’agent, plusieurs exemples montrent la valeur d’une UI de style HUD qui étend la perception de l’utilisateur
• Les copilotes sont efficaces pour les tâches quotidiennes, mais dans des situations créatives ou non standard, un HUD renforce davantage les capacités humaines

---

La critique du copilote par Mark Weiser en 1992

• En 1992, Mark Weiser a critiqué, lors d’un événement du MIT Media Lab consacré aux « agents d’interface », la vision consistant à assimiler l’IA à un « copilote »
• Des problèmes toujours d’actualité, comme la compréhension du contexte et l’automatisation, étaient déjà débattus à l’époque
• Plutôt qu’un « copilote » — une IA jouant le rôle d’assistant du pilote comme un humain virtuel — Weiser défendait des systèmes permettant à l’utilisateur de percevoir l’information naturellement
• Son idéal était celui d’un « ordinateur invisible », un environnement devenant le prolongement naturel du corps de l’utilisateur

Le HUD (Head-Up Display) et la philosophie de Weiser

• Dans les avions modernes, le HUD (Head-Up Display) superpose sur un affichage transparent des informations essentielles comme l’horizon ou l’altitude, de façon naturellement intégrée au champ de vision du pilote
• Contrairement à un copilote, un HUD n’a pas besoin de dialogue et étend naturellement les capacités de perception
• Cette idée du HUD correspond bien à la conception de l’utilisabilité défendue par Weiser

La concrétisation du HUD dans le logiciel

• Le correcteur orthographique ne dialogue pas comme un « collaborateur IA » : il fonctionne en soulignant automatiquement les fautes d’une ligne rouge
• Ce type de présentation immédiate et visuelle de l’information est un exemple de HUD qui crée un nouveau sens pour l’utilisateur
• Une UI de débogage personnalisée utilisant l’IA peut elle aussi visualiser intuitivement le comportement d’un programme, afin d’aider l’utilisateur à identifier et comprendre directement les problèmes
• Cette approche se distingue de l’automatisation traditionnelle ou des UI de type « assistant virtuel » et étend directement les sens humains

Les compromis entre HUD et copilote

• L’auteur n’affirme pas que le HUD est toujours meilleur que le copilote : chaque approche a ses avantages et ses limites
• Pour les tâches routinières et prévisibles (par exemple, un vol en ligne droite), l’approche copilote est efficace
• Pour les problèmes non standard et créatifs (par exemple, l’évaluation de la situation lors d’un atterrissage d’urgence), des outils qui assistent la cognition humaine, comme un HUD, sont particulièrement puissants
• Les concepteurs d’IA doivent aller au-delà du simple « assistant » et envisager aussi des UI d’extension sensorielle humaine, comme les HUD

Conclusion

• Dans le design de l’IA de demain, il faut reconnaître la valeur et les compromis propres à l’approche copilote comme à l’approche HUD
• On peut confier l’automatisation ordinaire à un assistant virtuel ; mais pour obtenir de meilleurs résultats, la stratégie la plus puissante peut être de donner aux experts humains de « nouveaux superpouvoirs » à la manière d’un HUD

[GN⁺]

Avis Hacker News

• Je me demande vraiment s’il serait utile d’avoir une fonction permettant d’afficher une carte thermique montrant à quel point chaque token d’un fichier source surprend le modèle. Les tokens en rouge auraient plus de chances d’indiquer des erreurs, de mauvais noms ou des commentaires incorrects
  • Il arrive qu’un code imprévisible soit dû à un algorithme original, mais dans ce cas une meilleure documentation est indispensable. Si le code est bien expliqué, il devient en soi moins surprenant. Autrement dit, il est possible de structurer certaines parties du source pour qu’elles soient moins surprenantes, et c’est peut-être une bonne pratique d’ingénierie. Grâce aux LLM, tout le monde se préoccupe davantage de l’importance d’une bonne documentation. C’est d’autant plus nécessaire si l’on veut que non seulement d’autres personnes, mais aussi une IA, puissent lire et comprendre le système
  • Je trouve l’idée vraiment excellente. À l’inverse, ce serait aussi très utile d’avoir une carte thermique des suggestions de l’IA selon leur niveau de confiance
  • J’aimerais beaucoup avoir ce genre de fonctionnalité dans l’éditeur. Ce serait aussi pratique pour vérifier si un texte est trop prévisible ou trop convenu. Le calcul de la perplexité n’est pas difficile non plus, il suffirait donc de l’intégrer à l’UI de l’éditeur
  • Intéressant. J’ai souvent l’impression que nous n’avons pas assez exploité les « fruits les plus bas » apparus dès l’engouement initial pour les LLM. Voilà exactement le genre d’idée dont je parle
  • Je pense que c’est une idée absolument fantastique
• Il y a environ 10 ans, Bret Victor disait que minimiser le délai de retour était un principe de vie. Selon lui, des cycles d’itération rapides permettent non seulement de mieux coder, mais favorisent aussi les intuitions créatives. Il avait créé divers programmes d’exemple pour montrer des alternatives, et l’exemple de HUD mentionné par l’OP ressemble beaucoup à sa démo « remonter le temps pour comprendre le code ». Vidéo associée
• Cette idée m’a plu, alors j’ai réfléchi à la façon de l’appliquer au développement en général. J’imagine quelque chose comme ceci : pendant qu’on écrit du code, un LLM génère des tests, et l’IDE exécute ces tests en temps réel. À chaque frappe, 10 à 100 tests s’exécutent en moins de 1 ms, et le résultat s’affiche de manière discrète. Les tests apparaissent dans un panneau séparé à côté du code, et la réussite ou l’échec du dernier run est indiqué par des points rouges ou verts. Rien qu’en voyant quels tests existent, lesquels manquent et leur état, on peut comprendre ce que le code en cours d’écriture fait « vu de l’extérieur ». Si l’on pense qu’un test qui devrait exister n’est pas généré par le LLM, cela peut indiquer que le prompt est mauvais ou que le code diffère de l’intention. L’aspect temps réel aide énormément à affiner le code. Si l’on veut faire du TDD traditionnel, l’utilisateur peut aussi écrire les tests et le LLM écrire le code pour les faire passer
  • Il est bien préférable que les humains écrivent d’abord les tests et que le LLM produise ensuite le code. Car les tests sont précisément la « vérité » et « l’intention » du code. Si l’on abandonne le contrôle sur les entrées et sorties, le développeur n’est plus au volant
  • Dans une base de code C++ sérieuse, cette approche est irréalisable. Rien que le temps de compilation la rend impossible, et il est difficile pour un LLM de deviner les tests sans écrire tout le code. Par exemple, si l’on crée une nouvelle structure de données, comment le LLM pourrait-il le savoir ?
  • Faire générer les tests par le LLM pendant l’écriture du code puis les exécuter à chaque fois dans l’IDE n’est pas une bonne approche. Les tests sont du code qui garantit des invariants, donc il est gênant que le LLM les modifie librement. Les tests ne devraient changer que lorsque l’utilisateur les modifie explicitement, et eux seuls devraient changer. Avec ces contraintes, cela ressemble déjà à un workflow courant, comme le mode watch des frameworks de test JavaScript. Les développeurs travaillent déjà ainsi depuis 10 ans
  • Ne faudrait-il pas aussi des tests pour vérifier que les tests sont bien écrits ? Sinon, même si les tests eux-mêmes sont mauvais, le LLM ne fera que les faire passer. Ou il pourrait écrire du code qui trompe simplement le système. Au final, l’installation qui fonctionne sera probablement un environnement où le LLM et l’humain peuvent franchir librement leurs frontières respectives. Écrire seulement des exigences claires et laisser l’IA gérer la majeure partie des deux côtés serait bien plus productif et streamlined
  • Exécuter toute la suite de tests à chaque saisie a un ROI beaucoup trop faible. La plupart des frappes produisent un programme « inachevé », donc il faut choisir plus intelligemment le moment d’exécuter les tests pour trouver un équilibre raisonnable
• Au fond, tout ramène à la question : « quelle est l’interface idéale pour que l’humain manipule l’information numérique ? » Nous absorbons chaque jour toujours plus d’informations, et avec l’IA cette quantité ne diminue pas, elle augmente. Si l’on résume même des informations complexes et spécialisées, comme des logs d’erreur, cela ouvre de nouvelles voies d’accès à l’information pour des personnes qui ne pouvaient pas y accéder auparavant. Alors, comment gérer efficacement toute cette information ? Aujourd’hui, nous avons toutes sortes d’interfaces, de sites, de dashboards, d’e-mails et de chats, mais je me demande si nous aurons encore besoin de tout cela dans 10 ans. Si je peux recevoir toutes les informations via une interface de chat unique, ai-je vraiment besoin d’aller sur un site ? Le fait que l’IA construise pour nous des sites web, des apps et des web UI commence à sembler un peu… redondant
  • Un site web était justement le moyen de recevoir une information « officielle » depuis une source fiable, comme une entreprise ou Wikipédia. Cette fiabilité était si puissante qu’on a consacré beaucoup d’efforts à la « line of death », à l’icône de cadenas, aux mesures anti-phishing et à la lutte contre les attaques par homoglyphes. Tout cela reposait sur l’idée que ce site contenait une information officielle digne de confiance. Dans un monde où tout le monde s’en remet aux LLM sans esprit critique, il devient vraiment difficile de savoir ce que signifie la « confiance ». Même si un LLM a généralement raison, peut-on vraiment lui faire confiance dans les moments très importants ?
  • Les concepteurs de chasseurs de 6e génération se heurtent au même problème. Le cockpit est l’interface entre l’appareil et le pilote, et son rôle se réduit de plus en plus. Avec la 7e génération, on peut se demander si l’humain aura encore un rôle utile. (Cela dit, pour des raisons de droit international ou de gestion du risque à la Skynet, une intervention humaine pourrait rester nécessaire.) Les interfaces dans tous les domaines évolueront probablement de la même manière. La complexité diminuera progressivement, et les humains n’auront plus qu’à expliquer au système ce qu’ils veulent en concepts de haut niveau. Ce ne sera pas forcément du langage naturel ; si une spécification précise est nécessaire, l’interface pourra être adaptée à cela
  • Comme tout le monde est différent, il ne faut pas généraliser les interfaces, mais les personnaliser dynamiquement à la volée
  • J’ai du mal à dire que le smartphone est vraiment parfait ou même exploité à son plein potentiel. Pour moi, c’est ce que je préfère
• Je pense qu’une fonctionnalité où l’IA crée en temps réel des visualisations complexes serait vraiment utile. Par exemple, pour déboguer une fuite mémoire sur un chemin de code précis, l’IA pourrait visualiser les allocations et désallocations mémoire sur ce chemin afin d’aider à identifier le problème. On entre probablement dans une époque où l’IA fabriquera elle-même les outils de visualisation les mieux adaptés à chaque problème. Un récent talk de Jonathan Blow à LambdaConf rejoint exactement cette idée. Il y montrait des outils permettant de visualiser les programmes de diverses façons pour détecter des problèmes potentiels. L’IA semble bien placée pour produire ce genre d’outils. Voir la vidéo complète
• J’aimerais voir directement dans un HUD les changements liés aux éléments TODO de Claude Code. Je ne veux pas de commentaires inline, car ils s’accumulent ensuite et le LLM ne les nettoie pas correctement
• L’une des principales raisons pour lesquelles les HUD ne se sont pas encore largement diffusés tient aux limites des supports d’affichage actuels. Les moniteurs et les appareils mobiles sont peu adaptés à la fourniture d’informations périphériques et non intrusives. Lorsqu’un agent IA corrige un bug ou traite une tâche complexe, le temps d’attente est ambigu. Il est trop court pour passer à autre chose, mais regarder l’écran en continu est aussi étrange. Avec un HUD, on pourrait avoir une boucle de feedback bien plus courte. On pourrait voir du coin de l’œil ce que fait l’IA et intervenir immédiatement, ou bien simplement continuer autre chose. L’important, c’est qu’au lieu d’avoir à choisir entre une attention totale et une absence complète d’implication, on peut ajuster à la volée son niveau d’intervention dans un état de conscience ambient. C’est pourquoi je pense que la VR/AR pourrait devenir la killer app centrale des AI HUD. Grâce au spatial computing, on pourrait recevoir l’aide de l’IA sans quitter des yeux un écran 2D. Cette approche serait aussi particulièrement utile pour des tâches physiques comme la cuisine ou la réparation de vélo
  • J’utilise déjà quelque chose de similaire en combinant un écran ultrawide et l’écran du laptop. Pendant que je suis plongé dans un jeu ou occupé à autre chose, j’affiche Claude dans une fenêtre tmux sur le côté et je jette un coup d’œil dès qu’il y a une étape suivante ou un changement important
• Je considère qu’une interface de codage de type HUD est essentiellement une AREPL. C’est bien adapté au débogage, mais j’ai l’impression qu’une fenêtre de chat ou du Q&A inline sont bien plus polyvalents. Globalement, je suis d’accord avec l’idée d’interfaces alternatives au chat, mais en pratique le chat est déjà l’interface dominante sur smartphone. Le HUD conviendrait probablement mieux à un véritable HUD, comme des lunettes AR
• Je pense aussi qu’il est possible d’avoir des modèles d’IA qui fonctionnent de manière autonome en arrière-plan pendant longtemps et qui « poussent » l’information quand c’est nécessaire. Ils détecteraient intelligemment le contexte, filtreraient, résumeraient, transmettraient le contenu et, si besoin, formuleraient des recommandations. C’est particulièrement naturel dans des environnements métier où il faut surveiller plusieurs clients selon une centaine de situations différentes
  • En réalité, la partie la plus difficile est de définir le contexte et de collecter les données pertinentes. Le problème consistant à faire exécuter cela par un système autonome est, lui, techniquement résolu depuis longtemps
• Je suis d’accord avec l’idée que « si l’on prend vraiment au sérieux le design pour l’IA, il faut réfléchir à une forme d’extension de l’intériorité humaine qui va au-delà du simple copilote ». En réalité, l’auto-complete joue déjà ce rôle. On peut bien sûr discuter avec un LLM, mais on peut aussi se contenter de lui donner des commandes simples ou d’utiliser l’autocomplétion. Ce que l’auteur semble vouloir souligner, c’est que l’IA doit travailler à nos côtés, tournée dans la même direction que nous. Il ne nous faut pas un copilote sorte de « faux humain » qui débat avec nous depuis l’autre côté de la table, mais un véritable collaborateur qui exécute immédiatement ce qu’on lui demande
  • C’est l’auteur. Exactement, l’UI d’autocomplétion de GitHub Copilot est en fait un très bon exemple de HUD. L’autocomplétion avec Tab s’intègre presque comme une partie du cerveau. Mais récemment, les environnements de codage s’orientent vers des agents de chat. Il faut imaginer à quoi pourrait ressembler une UI de « Tab autocomplete » à un niveau d’abstraction plus élevé. Cela pourrait devenir une façon de concevoir du code vraiment directe, sans se laisser freiner par des détails annexes