GUI, informatique personnelle et obsolescence logicielle

Le titre promet un vaste sujet mais cet article est là pour coucher sur papier quelques idées et références pour les partager et éventuellement revenir dessus plus sérieusement à l’avenir avec plus de précisions.

L’hypothèse

Dans un article à paraître pour la revue Azimuts, Timothée Goguely, Nolwenn Maudet, Guillaume Salagnac, Matthieu Moy et moi montrons que la nature des interfaces humain-machines entre en relation avec l’obsolescence des logiciels. Nous y montrons, très (trop) rapidement que ces relations découlent certes de propriétés techniques mais aussi de phénomènes sociaux/techniques et économiques. L’aspect économique y est très peu développé faute d’espace et de temps, pourtant je pense qu’il est essentiel dans cette affaire.

J’émets l’hypothèse suivante : les interfaces graphiques destinées au grand public ont été les outils idoines pour accompagner l’émergence du marché dé l’informatique personnelle et la quête d’obsolescence logicielle de l’industrie de l’électronique.

L’informatique personnelle comme un nouveau marché pour l’industrie de l’électronique

Je ne suis pas historien de l’informatique donc je ne vais évoquer qu’une toute petite partie de cette histoire que je pense pertinente pour mon hypothèse.

Début 1983 Apple sort le Lisa. L’ordinateur offre déjà un mode d’interaction type WIMP (Windown, Icons, Menus Pointer).

Le Lisa coûtait très cher, autour de 10 000$ de l’époque¹ et ne s’est pas bien vendu. En parallèle le Macintosh était en cours de développement, initialement conçu comme une machine plus faible sans GUI. Des efforts de R&D et la sortie de processeurs plus rapides ont permis à Apple de rediriger le projet vers une machine capable de faire tourner un environnement de bureau graphique pour moins de 3000$ d’époque. Ce changement s’est fait sous la direction de Steve Jobs qui percevait le Macintosh comme plus facilement marketable et capable de réussir là ou le Lisa plutôt échoué. In fine à sa sortie le Macintosh coûtera 2500$.

En 1983 l’annonce de la machine était accompagnée d’une grande opération de marketing. L’élément probablement le plus connu est une pub réalisée par Ridley Scott² présentant le Macintosh comme une machine permettant de lutter contre l’hégémonie des géants de l’électronique³ et leur surveillance. Ça fait sourire en 2026.

Un peu moins connue est la conférence qu’Apple tient en janvier 1984 que je paraphrase ici. Après avoir énoncé les spécifications techniques et montré une vidéo de démonstration Steve Jobs embraye sur le business. Il évoque le marché pour le Macintosh. D’une part les 25M de « knowledge workers », employé·es de bureaux, d’autre part les 11M d’étudiant·es, futur·es « knowledge workers ». Il dit ensuite s’être inspiré du téléphone, l’unique « appareil électro-ménager de bureau » ayant vraiment percé, et vouloir faire du Macintosh le second appareil de cette catégorie.

Le tableau est clair, l’ojectif de Macintosh est de mettre un ordinateur sur le bureau de tous les employé·es de bureaux, tous les étudiant·es mais aussi dans les salles de toutes les écoles⁴. Apple a même créé des partenariats avec 24 universités dans le cadre du « Apple University Consortium Program » permettant aux universités en faisant parti d’acheter des Macintoshs bien en dessous du prix du marché et de les revendre à ses étudiant·es. Lors de la conférence une personne demande si d’autres universités que celles présentes dans le consortium, qu’elle qualifie « d’élite », pourront acheter des Macs, Jobs répond que non. Certaines université iront même jusqu’à forcer les étudiant·es à acheter un Mac, une décision perçue plutôt positivement.

Quoi qu’il en soit, cette ambition d’en vendre un très grand nombre se confirme lorsque Jobs dit que, contrairement à l’Apple II conçu pour être fabriqué dans un garage au rythme de 50 par mois, le Macintosh a directement été conçu pour être fabriqué en usine, au rythme de 500 par jour et encore plus à l’avenir.

La sortie du Macintosh représente donc, en plus d’un accomplissement technique, un problème marketing et économique à résoudre pour Apple. Est-il possible, suite à l’Apple II et l’IBM PC, de faire de l’informatique personnelle milieu de gamme un marché à l’échelle nationale à l’image des téléphones ?

Les GUI comme vecteur d’obsolescence culturelle

Jobs dit que fut un temps certaines personnes proposaient de mettre un télégraphe sur tous les bureaux pour augmenter la productivité. Selon lui le problème avec cette idée est que peu de personnes allaient prendre les dizaines d’heures nécessaires pour apprendre le morse. La bonne solution était d’attendre une innovation technologique, en l’occurrence le téléphone, pour satisfaire le même besoin et effectivement le déployer partout grâce à son usage plus facile. Il utilise en anglais l’expression « radical ease of use » à plusieurs reprises.

Jobs présente l’IBM PC comme le télégraphe et le Macintosh comme le téléphone. Il aurait été, selon lui, inutile de mettre un IBM PC sur tous les bureaux parce que peu de personnes allaient lire le manuel de 400 pages de Wordstar. Avec le Macintosh tout est si simple qu’il est possible d’en faire un produit de masse. Ce pari, il faut le dire, s’est révélé gagnant pour Apple. Le Macintosh s’est très bien vendu et les produits d’Apple ont longtemps bénéficié d’une aura de facilité d’utilisation.

Pourtant cette facilité d’utilisation n’était pas une évidence. La présentation que Clémence Imbert a donné à la journée d’étude Quand le code rencontre l’interface, nommée Apprendre à cliquer, était-il si facile de débuter sur un logiciel de PA0 dans les années 1980 ? met en lumière la diversité des vécus face à l’arrivée des GUI dans les métier de l’édition. En partant de la promesse formulée dans les pubs pour Macintosh, disant littéralement « Si vous savez pointer, vous savez utiliser un mac”, elle raconte les surprises, frustrations et longues sessions de formations nécessaires à la migration vers ces outils que certain·es profession·nelles ont vécues.

Je ne pense évidemment pas que ce travail remette en question des décennies de recherche en IHM sur les bonnes propriétés des GUI (bien faites) pour l’apprentissage et l’aisance d’usage. Il participe cependant à la non-naturalisation et systématisation des conséquences de ces propriétés. Oui une interface graphique est davantage découvrable, non ce n’est pas un fait immédiat, total et en dehors de tout contexte économique et social. Il est facile de surestimer la puissance et l’universalité de ces principes de designs. On oublie les difficultés des utilisateurices d’antan lorsque ces principes ne s’étaient pas encore imposés en monopole radical des IHM⁵ ou les efforts publicitaires et de formations investis dedans. Clémence Imbert évoquait des cycles de formations de plusieurs jours, répétés deux fois.

Pour caricaturer je pourrais dire « Donnez moi deux fois trois jours complets avec des personnes qui doivent apprendre à utiliser des CLI pour faire leur métier et je vous garantis qu’iels sortiront de la formation en sachant utiliser des CLI. Peut-être même que certain·es trouveront ça chouette ! ». La comparaison ayant ses limites sachant que Clémence Imbert parle spécifiquement de mise en page, un problème complexe qu’il soit informatisé ou pas. L’apprentissage des CLI aujourd’hui, par des personnes sachant par ailleurs utiliser des GUI, n’implique pas la même chose que la découverte des ordinateurs dans les années 80.

Le travail de Clémence Imbert nous invite à regarder l’usage des GUI par Apple d’un autre angle que celui de l’étude des IHM. Si le mode WIMP changait effectivement la donne mais pas systématiquement en allant faire plus de facilité alors à quoi d’autre pouvait-il bien servir ? J’émets l’hypothèse, pour l’instant totalement infondée, que les GUI et l’interaction par la souris a au moins autant servi à Apple à se démarquer d’un point de vue marketing qu’à faciliter la manière dont les personnes interagissaient avec l’ordinateur. Il aurait été difficile pour Steve Jobs de vendre le Macintosh comme une révolution aussi grande que le passage du télégraphe au téléphone sans un changement d’interaction immédiatement palpable et visuel. Vu comme ça c’est peut-être la nouveauté⁶ du mode d’interaction et sa capacité à générer des métaphores propices à une bonne campagne de pub qui en a fait la force. Il fallait une rupture pour vendre une nouvelle ère et déprécier ce qui est venu avant, il se trouve que l’on a eu celle des GUI. Pourquoi rester sur son vieux PC sur lequel il faut taper des commandes alors que la nouveauté, l’avenir et le progrès est graphique et utilise une souris⁷ ?

L’autre élément pour lequel les GUI pourraient être favorables à la fabrique de l’obsolescence culturelle est justement son côté éminemment graphique. Dans cette vidéo pour Blast Bolchegeek, le fils de pub et Jeanne Guien expliquent que l’attrait pour la nouveauté n’a pas toujours existé, en particulier pour le textile, hormis les aristocrates. La classe bourgeoise émergente, alors aux commandes de machines de textiles et disposant d’une grande quantité de main-d’œuvre prolétarienne pour les opérer, était en position pour proposer une énorme offre de textile. Seulement, il fallait y associer une demande. C’est pour cela que naitra « la mode », rythmée sur des saisonnalités et des cycles incitant au renouvellement des pièces. Cela sera codifié dans le langage à travers des formules comme « prévision des tendances » plutôt que « planification industrielle », « création » plutôt que « surproduction » ou encore « démocratisation du luxe » plutôt que « ciblage du portefeuille de part de marché identifiée ». Formules largement répandues à l’aide d’une autre industrie émergente, la publicité.

Le reste des secteurs industriels utiliseront les mêmes techniques pour écouler plus facilement les produits dans des volumes toujours plus grands. Le design⁸ a servi aux industriels à créer, parfois de manière artificielle, de la nouveauté de façon à rouvrir des marchés saturés. Pas besoin d’en dire beaucoup plus pour voir comment plaquer cela sur l’industrie du numérique. Mon intuition est qu’au milieu des années 80, en plus d’être un nouveau paradigme d’interaction réellement utile, les GUI ont permis 1. de mettre en scène une rupture pour vendre l’ordinateur personnel comme une révolution et 2. de rendre nos écrans plus perméables au design et à la nouveauté et donc potentiellement à l’obsolescence. Je ne sais pas si quiconque à Apple l’a pensé explicitement comme une stratégie de vente et je doute que l’on puisse trouve des sources l’attestant.

En cherchant d’éventuels exemples d’obsolescences culturelles permises strictement par l’interface graphique des Macinstoshs durant les toutes premières années de sa vie je n’ai rien trouvé de très probant. Dans le Macworld de mai 1991 on peut lire :

When I look back at the last seven years, I realize how few major changes or improvements there have been in the Mac design over that period. There’s been the Hierarchical File System (which should have been there in the first place), slots, color, varying screen sizes, the virtual desktop, and some limited I/O processing in the IIfx (currently unusable under the Mac OS).

Plusieurs de ces changements ont bien un rapport avec l’aspect graphique de Mac OS mais apportent des modifications significatives qui seraient malhonnête de qualifier d’uniquement « marketing ». Il y a par contre de longs articles sur les fonctionnalités et la rapidité permises par le matériel plus puissant. Mais puisque l’on sait que bien plus tard le redesign d’interface sans ajout fonctionnalité sera une pratique assez courante une autre lecture pourrait être faite : Tant que les progrès électroniques étaient suffisament fréquents et rapides, le recours à l’obsolescence culturelle via le design d’UI était minoritaire face à l’ajout de fonctionnalité ou plus de rapidité. Cela en ferait un phénomène assez similaire à ce que l’on a pu voir dans le marketing pour smartphones.

Les GUI vecteur d’obsolescence logicielle

Même si le but ici était d’ouvrir la question des relations entre économie, marketing et GUI, je ne résiste pas à partager des découvertes un peu plus techniques.

Bill Atkinson était développeur chez Apple. Il a principalement travaillé sur les fonctions graphiques du Lisa puis du Macintosh. Le système était nommé QuickDraw.

Atkinson a également créé Hypercard d’après lui suite à un trip sous LSD durant lequel il a réalisé que c’est en mettant en relation les connaissances de divers domaines (ingénieurie, artistique etc) que l’on allait résoudre les problèmes du monde. Vraiment la Silicon Valley des débuts quoi. On trouve également Ted Nelson disant que son projet Xanadu est une inspiration pour Hypercard de l’aveu d’Atkinson lui-même. Après avoir regardé plusieurs heures d’interview du principal intéressé je ne l’ai jamais entendu référencer ce logiciel. Peut-être que l’échange d’information a eu lieu en privé, qu’Atkinson préfère se vendre en cool psychonaute qu’en mec normal qui s’inspire directement de ce qu’il trouve autour de lui ou que Ted Nelson cherche à s’octroyer une part de la gloire d’hypercard à défaut d’avoir eu du succès avec son propre logiciel. À vous de choisir.

Quoi qu’il en soit le logiciel permettait de produire des applications sous forme de piles de « cartes » programmables, adossées à une base de donnée de fichiers et avec une interface graphique que l’on pouvait construire à l’aide de la souris.

Récemment en scrollant hackernews je suis tombé sur ce commentaire à propos d’Atkinson, Jobs et Hypercard :

Hypercard lore has it that Jobs asked Atkinson to stop writing fit-to-use software that fits on a floppy and instead write something that requires lots of graphics and has no real functional limits, so Jobs could sell people a mac with an unimaginably large 20MB hard drive.

Très intéressé par cette affirmation j’ai demandé à l’auteurice si iel avait une source. Ma question est restée sans réponse. Atkinson étant mort l’année dernière cela réduit considérablement les chances de savoir si effectivement Jobs avait explicitement formulé la volonté d’utiliser le logiciel comme mécanisme d’obsolescence programmée.

Quelques rapides recherches ne m’ont pas permis de mettre la main sur une autre source exprimant cette rumeur. En revanche j’ai trouvé quelques témoignages d’employé·es d’Apple au sujet du développement des routines graphiques pour Lisa et Macintosh et les limitations matérielles allant avec. Ces témoignages sont particulièrement intéressants puisque l’histoire du développement du Macintosh s’inscrit à la fois dans une industrie électronique produisant du matériel plus performant très rapidement et la volonté d’en faire une machine moins puissante que Lisa tout en en reprenant les logiciels graphiques, impliquant des contraintes inédites.

Dans le premier témoignage Atkinson parle du coût en mémoire et en calcul de produire une GUI :

The Apple II displayed white text on a black background. I argued that to do graphics properly we had to switch to a white background like paper. It works fine to invert text when printing, but it would not work for a photo to be printed in negative. The Lisa hardware team complained the screen would flicker too much, and they would need faster refresh with more expensive RAM to prevent smearing when scrolling. Steve listened to all the pros and cons then sided with a white background for the sake of graphics.

The Lisa and Macintosh were designed with full bitmap displays. This gave tremendous flexibility in what you could draw, but at a big cost. There were a lot of pixels to set and clear anytime you wanted to draw a character, line, image, or area. I wrote the optimized assembly language QuickDraw graphics primitives that all Lisa and Macintosh applications called to write the pixels. QuickDraw performance made the bitmap display and graphical user interface practical (see I Still Remember Regions).

To handle overlapping windows and graphics clipping, I wrote the original Lisa Window Manager. I also wrote the Lisa Event Manager and Menu Manager, and invented the pull-down menu. Andy Hertzfeld adapted these for use on the Mac, and with these and QuickDraw, my code accounted for almost two thirds of the original Macintosh ROM.

On voit que la volonté de produire des GUI impactaient les spécifications techniques du Mac allant jusqu’à nécessiter de la RAM plus rapide et chère. Le code gérant les graphismes et les menus représentait presque 2/3 de l’OS du premier Macintosh.

Plus intéressant encore, dans un autre témoignage Andy Hertzfled, un autre ingénieur chez Apple à l’époque, raconte les relations entre développement, performance et matériel :

But as we started to get some software going on the prototype, it became increasingly clear that we didn’t have enough RAM for the kind of graphic intensive applications that we wanted to build; after all, just the frame buffer for the bit-map display took up almost one third of the available memory. And furthermore, Bill Atkinson’s graphics routines alone had recently exceeded the size of the 8K ROM. So, when the digital board was redesigned to incorporate the SCC chip in June 1981, Burrell added another row of 8 memory chips, doubling the RAM size to 128K, and added another ROM chip as well, doubling the ROM size to 16K. We vowed that we would fight hard to keep that the last increase (in contrast with the Lisa, whose memory requirement’s were growing considerably faster than Moore’s Law)

[…]

One day, in early 1982, Burrell returned from a meeting with a semiconductor company’s sales representative really excited, almost running into my office. “OK, you say that you won’t be able to fit in 24K, right? Be honest - how much will we really need?”

We always seemed to need just a little more ROM that we had available. “I think we’d definitely make it if we had 32K”, I responded.

Burrell laughed. “No you won’t. It’s clear that won’t be enough, since the software isn’t close to being finished yet. But I just heard that the 256Kbit ROMs are really close, and they’ll be ready if we ship in early 1983. So I can use two 256Kbit chips, connected up to the 16-bit bus, and we’ll have 64K bytes of ROM. 64K! ROM is half the price per bit of RAM, so it makes sense to use as much as we can. I know you’ll be asking for even more someday, but that should keep you busy for a while.”

At first, 64Kbytes seemed boundless. We were already trying to write as tight code as we could, and it seemed like it would be plenty, since we weren’t even using 32K yet. But sure enough, as the system came together in the spring of 1983, we were beginning to strain against the size limit.

Plusieurs choses intéressantes ici. Premièrement c’est en construisant les premiers prototypes du Mac que l’équipe se rend compte qu’elle aura besoin de plus de puissance. Le rapport dev↔matériel est donc à double sens. On développe d’une certaine manière parce que l’on a du matériel qui nous le permet mais on choisit également son matériel en fonction de l’objectif de développement que l’on s’est donné (ici avoir un OS avec une GUI). Un autre exemple de cette relation est ce témoignage de Bill Gates dans MacWorld :

When you’re writing applications that are going to be simple to use, it’s important to have some boundaries that prevent you from throwing in an unlimited number of features; the memory size provides that limit. […]
When you do get more memory, you’ll be able to have multiple applications active or have more data space available. It’s partly these boundaries that have forced us to find more clever ways to do things and stay within the memory size.

Deuxièmement la croissance des besoins matériels pour le développement de l’OS pour Lisa, pensé dès le début comme un appareil cher et puissant, était plus rapide que ce que la loi de Moore, pourtant alors en pleinement satisfaite, pouvait fournir comme progrès. Ce fin n’est pas sans rappeler la loi de Wirth. Troisièmement les choix de développement et de matériel sont partiellement déterminés par des raisons économiques. Burrel mentionne le fait que la mémoire ROM, celle sur laquelle est stocké l’OS, est moins cher que la RAM, celle sur laquelle sont stockées les données des applications en cours. Il serait donc logique « d’en utiliser autant que l’on peut » et d’optimiser la RAM à la place. Quatrièmement il est difficile de prévoir à l’avance la quantité de mémoire nécessaire pour faire tenir et fonctionner un logiciel et, si estimation il y a, elle est probablement sous-estimée. Alors même qu’Hertzfeld pensait que 64Ko était énorme, à la sortie du Macintosh l’OS occupait presque la totalité de la place disponible sur la puce.

Seulement neuf mois après la sortie du premier Macintosh, dit 128K pour sa quantité de RAM, sortait le second avec quatre fois plus de RAM, lui permettant surtout de faire tourner de nouveaux logiciels plus gourmands. En particulier Microsoft Excel⁹ nécessitait 512K de RAM pour fonctionner correctement. Le Macintosh Plus, sorti en 1986, propose 1Mo de RAM. Rapidement des améliorations vers un stockage d’OS de 128Ko seront proposées. Dans le Macworld d’octobre 1989 Thom Hogan écrit :

Many software developers stopped supporting the old 128K Mac within a matter of months. […] virtually every new (nongame) software product I’ve seen in the last year won’t run on [this] machine.

[…]

My suggestion to 128K and 512K owners: reach deep into your wallet and buy, at least, a new Plus.

Le premier Mac était donc tout juste capable de faire fonctionner les logiciels embarqués avec. Les logiciels de Microsoft ne pouvaient pas convenablement fonctionner dessus. Les logiciels les plus graphiques, de dessin notamment, fonctionnaient beaucoup mieux avec plus de RAM etc. Tout cela donnerait presque l’impression qu’Apple a fait « exprès » de produire un Macintosh juste assez puissant pour donner envie mais juste assez peu pour nécessiter presque instantanément des upgrades coûteuses. La vérité est qu’il n’était probablement pas vraiment possible de faire un ordinateur graphique, peu cher et durable compte tenu de l’électronique disponible pour l’époque. Du moins pas si l’on laisse libre cours à toutes ses envies en terme de fonctionnalités.

Je ne pense pas que les GUI soient fatalement obsolescentes techniquement. La preuve en est que l’équipe d’Apple est parvenue à faire entrer une GUI étonnamment similaire à ce que l’on utilise aujourd’hui dans 128Ko de ROM et 512Ko de RAM, à savoir à peu près autant que ce qu’il fallait pour faire tourner Unix SystemV¹⁰ et beauuuuuuuucoup moins que ce que nécessite un Linux moderne en mode texte. Leur pouvoir obsolescent n’est pas à comparer dans le temps mais à un moment donné, sinon la croissance généralisée des besoins en mémoire et en calcul dans le temps écraserait toute différence. Les références que j’ai trouvé ici tendent à montrer qu’à un moment donné, entre 1980 et 1986, l’implémentation de GUI était un moteur significatif d’obsolescence, rendant inutilisables les quantités de mémoire disponibles au début de la fourchette de temps. Je suppose que cet effet moteur est resté vrai encore quelques années.

J’ai conscience que de parler de tout ça à un moment où les logicielles générant le plus d’obsolescence sont les LLM, par nature orientés textes et se satisfaisant très bien du terminal, est un peu ironique. M’enfin.

Conclusion

L’obsolescence logicielle n’a pas été découverte ou inventée avec le Macintosh¹¹. Le projet était situé à un moment technique et un contexte économique qui en ont fait un bon cas d’étude sur le sujet. La volonté d’en vendre des millions et de créer un marché durable de l’informatique personnel, le passage des CLIs aux GUIs, le très rapide progrès des composants électroniques, tout cela constitue un bon combo pour créer un système propice à l’obsolescence.

Si l’on en revient à mon hypothèse du début on peut tracer un parallèle et raconter une petite histoire :

D’un côté les GUI auraient pris leur envol dans un contexte commercial où elles ont pu être utilisées de manière à créer artificiellement de la nouveauté pour vendre un produit à la recherche d’un nouveau marché. Elles auraient à ce moment également grandement participé à pousser vers le haut les besoins minimaux en puissance et mémoire des systèmes d’exploitation.
À l’inverse les CLI seraient restées assez largement cantonées à des contextes plus professionnels, en particulier du monde de l’informatique, dans lequel les marchés existaient déjà et le besoin de nouveauté peut-être moins fort ou moins efficace. Les GUI s’étant appropriées le monde des interfaces pour les utilisateurices finales, les CLI auraient prospérées en arrière plan, dans des rôles d’infrastructure, menant à plus de stabilité et moins d’obsolescence.

En comprenant les GUI et CLI d’aujourd’hui comme héritières de ces histoires là il est plus facile de comprendre leurs rapports avec les phénomènes d’obsolescence.