La plupart des gens ne sont pas entrés dans l’informatique par une seule porte. Selon le moment et le lieu, il y avait une console, une ligne de commande, un bureau graphique, ou plusieurs à la fois, empilés comme des strates géologiques. Pour l’utilisateur ordinaire, l’interface graphique fut un acte d’hospitalité : elle a rendu la machine lisible sans exiger un vocabulaire de commandes, de chemins, d’options et de permissions. On pointait, on cliquait, la machine répondait en images.

Le problème commence quand l’interface conçue pour accueillir les nouveaux venus devient la seule langue disponible pour les personnes responsables du bon fonctionnement des systèmes. Techniciens, administrateurs et développeurs se sont parfois tellement habitués à l’immédiateté de l’interface graphique qu’ils ont cessé de pratiquer les disciplines plus anciennes — le shell, le fichier de configuration, le petit programme enchaîné à un autre. La perte n’était pas la nostalgie d’un écran noir aux lettres vertes. C’était la perte d’une forme particulière d’agentivité : la capacité de transformer une action en quelque chose qui survit au moment où elle a été effectuée.

I. Le Bouton comme Hospitalité

L’interface graphique mérite un récit plus généreux que la plainte habituelle du technicien selon laquelle elle rendrait les gens dépendants. Menus, icônes et retour visuel traduisent la structure interne d’une machine en actions qui peuvent être découvertes sans instruction préalable. Le Sketchpad d’Ivan Sutherland, construit en 1963 sur le TX-2 du MIT, est généralement crédité comme la première démonstration réelle qu’une personne pouvait manipuler un ordinateur directement, avec un crayon optique, plutôt qu’à travers une pile de cartes perforées soumises puis restituées des heures plus tard. L’idée que l’informatique puisse être une conversation plutôt qu’une requête a à peine soixante ans, et elle était alors radicale.

Douglas Engelbart a poussé la même intuition plus loin, et avec plus d’ambition, dans son rapport de 1962 Augmenting Human Intellect: A Conceptual Framework. Engelbart ne voulait pas que les ordinateurs remplacent le raisonnement humain ; il voulait qu’ils le prolongent, comme un levier prolonge une main. La souris, l’hypertexte et l’écran à fenêtres qu’il a démontrés lors de la célèbre « Mère de toutes les démos » de 1968 n’étaient pas de simples commodités. C’était un pari : de meilleures interfaces produisent une meilleure pensée. Alan Kay et Adele Goldberg ont porté ce pari jusqu’à Xerox PARC et, dans leur article de 1977 Personal Dynamic Media, ont esquissé le Dynabook — un ordinateur personnel pensé pour un enfant, ne nécessitant aucune caste de spécialistes pour le faire fonctionner. Cette filiation n’est pas une note de bas de page dans l’histoire de la ligne de commande. C’est un argument parallèle sur l’agentivité, formulé dans la direction opposée : l’agentivité par la simplicité plutôt que l’agentivité par l’exposition.

Une personne qui retouche une photo, compose de la musique ou gère le budget d’un foyer ne doit rien à la machine en matière d’éducation à la ligne de commande. L’abstraction est l’une des grandes réussites de l’ingénierie : l’utilisateur ne devrait pas avoir à porter toute l’implémentation dans sa tête simplement pour s’en servir. Mais l’abstraction a un coût quand la tâche cesse d’être de la consommation pour devenir de l’intendance. La couche qui protège un utilisateur de la complexité peut aussi dissimuler les objets, les dépendances et l’ordre des opérations qu’un technicien a besoin de contrôler.

II. La Commande comme Petit Programme

On décrit souvent la ligne de commande comme hostile parce qu’elle exige de la précision. Sa vertu la plus profonde est qu’elle transforme une action en artefact. Une commande tapée aujourd’hui peut devenir un script shell demain, une tâche planifiée la semaine prochaine, et une étape documentée d’un pipeline de déploiement plus tard. Les tubes et la redirection permettent à de petits outils, chacun conçu pour une seule tâche, de coopérer sans demander à aucun d’eux d’anticiper chaque usage futur — l’éthique de conception qu’Eric Raymond a répertoriée dans The Art of UNIX Programming : écrire des programmes qui font une seule chose, et bien, et qui fonctionnent ensemble, parce que les flux de texte sont une interface universelle qu’aucun fournisseur ne peut révoquer.

C’est pourquoi le shell reste disproportionnellement utile à côté des langages d’automatisation modernes et des systèmes d’infrastructure-as-code. JSON, YAML et TOML rendent l’état descriptible. Bash, Zsh et PowerShell rendent les transformations répétables. Un fichier de configuration peut être relu avant d’être appliqué ; un script peut être comparé à sa version précédente ; un environnement peut être reconstruit à partir d’une définition plutôt que réassemblé de mémoire. Rien de tout cela n’oppose vraiment le texte à l’image. C’est le geste éphémère contre la procédure inspectable. Un outil graphique peut exporter un script ou exposer une API ; un outil en ligne de commande peut être opaque et mal conçu. La vraie question est de savoir si le système permet à ses propres opérateurs de comprendre et de reproduire ce qu’il vient de faire.

III. Quand la Facilité Devient Dépendance

Le technicien qui ne travaille qu’à travers une interface graphique peut rester très compétent à l’intérieur de cette interface et devenir malgré tout étrangement démuni le jour où elle change, disparaît, ou doit passer à une échelle que la souris ne peut plus atteindre. Un bouton intitulé « synchroniser » ne révèle pas quels fichiers ont été comparés, quels conflits ont été résolus en silence, où résident les identifiants, ni comment effectuer la même opération sur un serveur sans écran.

Cette dépendance se manifeste le plus nettement dans l’infrastructure, où le public d’une interface n’a jamais vraiment été le grand public. Les systèmes de production doivent être reconstruits après une panne, dans l’urgence, par quiconque est d’astreinte. Une équipe doit savoir non seulement qu’un service tourne, mais pourquoi il tourne, à partir de quelle définition, avec quelles versions et quelles permissions. Le chemin de clics conservé dans la mémoire d’un administrateur n’est pas un registre opérationnel. Un script versionné, si. Il y a aussi une dimension politique ici, que la graine de ce texte jugeait bon de nommer directement : la personne qui seule sait quels boutons presser détient une autorité qui ne peut être ni auditée ni transmise. Une commande, un fichier de configuration, une définition déclarative — cela peut être lu par quelqu’un d’autre avant de prendre effet, ce qui signifie que cela peut être contesté avant qu’il ne soit trop tard. La procédure cachée ferme cette conversation par défaut ; la procédure lisible l’invite.

IV. Recul, ou Avancée ?

La ligne de commande peut ressembler à un recul, un retour à une interface austère et exigeante après des décennies passées à rendre les ordinateurs plus accueillants. En pratique, elle représente plus souvent un passage de l’exécution des actions à leur description — faire une chose une fois, correctement, à écrire ce que « correctement » signifie pour qu’elle puisse être refaite sans vous. L’interface graphique excelle à aider quelqu’un à agir dans le présent, avec un contexte complet et un retour immédiat. Le shell, allié aux scripts et à la configuration, excelle à exprimer ce qui doit se produire à travers le temps, à travers les machines, et après que la personne qui l’a écrit est passée à autre chose.

La position mature n’est de s’enrôler dans aucun des deux camps. Garder l’interface graphique pour la découverte, le travail visuel et l’accès humain — ce n’est pas une forme inférieure d’informatique, seulement un rapport différent à la machine. Garder la ligne de commande à portée de main pour tout ce qui doit être compris, répété, automatisé, révisé, ou récupéré sous pression. Le super-pouvoir n’a jamais été l’écran noir lui-même. C’était l’habitude de transformer ce qu’on venait de faire en quelque chose qu’une autre personne — ou soi-même, six mois plus tard, à trois heures du matin — pourrait lire, en qui faire confiance, et relancer.

Pour aller plus loin