Philosophie de l'ingénierie : Thompson et Ritchie, faire une seule chose et bien la faire

L’essentiel à retenir

• Des outils petits et précis. Chaque programme fait une seule chose, et la fait bien, en refusant d’en faire une seconde ; un besoin nouveau appelle un outil nouveau, pas un drapeau de plus.
• La composition plutôt que les fonctionnalités. La puissance naît de l’assemblage des programmes via l’interface universelle qu’est le texte — les pipes — de sorte que la capacité émerge dans les jointures, et non à l’intérieur d’un programme isolé. La formule canonique « faire une seule chose et bien la faire » est de Doug McIlroy, pas de Thompson ni de Ritchie.
• La portabilité par le langage C. Réécrire Unix en C a permis de le porter sur un matériel nouveau en portant un compilateur plutôt qu’en réécrivant tout le système — c’est l’essentiel de la raison pour laquelle Unix s’est répandu partout.
• Ne faire confiance qu’à ce que vous avez construit. « Reflections on Trusting Trust » de Thompson montre qu’une porte dérobée peut vivre dans le binaire sans laisser la moindre trace dans le code source que vous inspectez — l’intuition fondatrice de la sécurité de la chaîne d’approvisionnement.

Le principe

« Écrivez des programmes qui font une seule chose et la font bien. Écrivez des programmes qui collaborent. Écrivez des programmes qui traitent des flux de texte, car c’est une interface universelle. » — Doug McIlroy, résumant la philosophie Unix¹

Cette phrase n’est ni de Thompson ni de Ritchie. Elle a été écrite par Doug McIlroy, leur collègue aux Bell Labs et l’inventeur du pipe Unix, dans sa préface au numéro spécial de 1978 du Bell System Technical Journal.¹ Mais c’est l’énoncé le plus limpide de ce que Thompson et Ritchie ont réellement bâti, et la raison de l’ouvrir avec elle plutôt qu’avec une formule de l’un des deux hommes est elle-même le cœur du propos : la philosophie Unix n’a jamais été un manifeste rédigé par un génie solitaire. C’était une culture, et la culture était l’artefact.

Le principe tient en trois gestes, et ils sont indissociables. Rendre chaque outil petit et précis — un seul travail, bien fait, sans ambition d’en accomplir un deuxième. Rendre les outils composables — la sortie de l’un devient l’entrée du suivant, de sorte que la capacité provient de la combinaison plutôt que de la croissance d’un programme. Et rendre l’interface entre eux universelle — du texte brut, afin que n’importe quel outil puisse se raccorder à n’importe quel autre sans que ni l’un ni l’autre ne sache que l’autre existe. La puissance loge dans les jointures, pas dans les pièces. Un programme qui trie des lignes ne sait rien des journaux web ; un programme qui compte les doublons ne sait rien des codes de statut HTTP ; reliés par un pipe, ils répondent à une question qu’aucun des deux n’a été conçu pour traiter.

C’est l’exact opposé de l’instinct qui produit la plupart des logiciels. La pente naturelle consiste à faire qu’un programme en fasse davantage — ajouter un drapeau, ajouter un mode, fondre l’exigence suivante dans ce que l’on possède déjà. La première règle de McIlroy nomme cette pente et la refuse : « Pour accomplir une tâche nouvelle, repartez de zéro plutôt que de compliquer d’anciens programmes en ajoutant de nouvelles “fonctionnalités”. »¹ Tout le système de Thompson et Ritchie est la démonstration que la simplicité est la condition préalable de tout le reste, et que la composition — pas les fonctionnalités — est la manière dont de petites choses deviennent puissantes.

Le contexte

Unix est né d’un échec. Au milieu des années 1960, les Bell Labs s’étaient associés au MIT et à General Electric autour de Multics, un système d’exploitation à temps partagé d’une ambition démesurée, censé tout faire ou presque. En 1969, il était devenu si complexe et si en retard que les Bell Labs s’en retirèrent, et les chercheurs qui y avaient travaillé — Ken Thompson, Dennis Ritchie, Doug McIlroy, Joe Ossanna — restèrent frustrés, privés d’un environnement informatique interactif confortable, mais forts d’une conviction nette sur la manière de ne pas construire un système.²

Ken Thompson, né le 4 février 1943 à La Nouvelle-Orléans, avait rejoint les Bell Labs en 1966 après une licence et un master en génie électrique et en informatique à l’université de Californie à Berkeley.³ Dennis Ritchie, né le 9 septembre 1941 à Bronxville, dans l’État de New York, intégra le Computing Sciences Research Center en 1967.⁴ En 1969, Thompson tomba sur un PDP-7 mis au rebut — un petit mini-ordinateur déjà obsolète — et entreprit d’y bâtir un minuscule système d’exploitation, en partie pour faire tourner un jeu qu’il avait écrit, Space Travel. Thompson a plus tard décrit la répartition des rôles sans détour : « J’ai réalisé tout seul les deux ou trois premières versions d’UNIX. Et Dennis est devenu un évangéliste. »³ La première version fut écrite en assembleur PDP-7.

Le nom est venu d’une plaisanterie. Là où Multics était « Multiplexed », le nouveau système était délibérément réduit, si bien que le groupe l’appela « UNICS » — Uniplexed Information and Computing Service — un calembour aux dépens de Multics. L’orthographe glissa vers « Unix », et Brian Kernighan, à qui l’on attribue habituellement le nom, a plus tard noté que personne ne se souvient vraiment de la manière dont la forme finale a émergé.² Cette petitesse n’était ni un accident ni une limite à dépasser. C’était le parti pris de conception.

Le travail

Unix et le système de fichiers

La première chose qu’Unix a su faire juste, c’est un modèle de ce que sont les ressources d’un ordinateur. Les systèmes antérieurs traitaient les fichiers, les périphériques et les canaux de communication comme des choses de natures différentes, chacune dotée de sa propre interface particulière. Unix les a fait fusionner. Il a présenté un système de fichiers hiérarchique unique — une arborescence de dossiers — puis a traité presque tout comme un fichier en son sein : non seulement les documents, mais aussi les périphériques et les canaux de communication entre processus.² Un programme capable de lire dans un fichier et d’y écrire pouvait, sans rien changer, lire depuis un terminal, un lecteur de bande ou un autre programme, car pour lui ce n’étaient là que des fichiers.

C’est l’interface universelle sous sa première forme. « Tout est un fichier » signifie qu’un petit outil n’a pas besoin d’une version différente pour chaque type d’entrée ; il lui en faut une seule. Le coût de la composition tombe à presque zéro, parce que chaque composant parle déjà la même langue. Le système de fichiers hiérarchique et l’interface uniforme open/read/write/close expliquent pourquoi le reste de la philosophie était même envisageable : on ne peut pas composer des outils qui réclament chacun un raccord sur mesure.

C et la portabilité

La deuxième percée fut de rendre le système portable, et cela exigeait un langage. Ritchie créa le langage C entre 1969 et 1973, en le faisant évoluer à partir du langage B de Thompson, lui-même descendu de BCPL.⁴ B était sans typage et interprété ; C ajouta des types de données et des structures, et compilait vers un code machine efficace, assez proche du matériel pour y écrire un système d’exploitation, assez abstrait pour passer d’une machine à l’autre.

Le moment décisif survint vers 1973, lorsque la version 4 d’Unix fut réécrite en C.² Jusque-là, un système d’exploitation, c’était de l’assembleur, soudé à jamais à l’unique machine pour laquelle il avait été écrit. Réécrire Unix dans un langage de haut niveau frôlait l’hérésie — la sagesse établie voulait que le code système soit de l’assembleur peaufiné à la main, sous peine d’être trop lent. Thompson et Ritchie le firent malgré tout, et le bénéfice fut la portabilité : Unix pouvait désormais être porté sur un matériel nouveau en portant un compilateur, plutôt qu’en réécrivant le système entier. Cette seule décision est l’essentiel de la raison pour laquelle Unix s’est répandu dans tous les recoins de l’informatique, tandis que ses contemporains restaient boulonnés à leur ferraille d’origine. En 1978, Ritchie et Kernighan publièrent The C Programming Language — le « K&R » — ce livre sobre et précis qui a appris à toute une génération à écrire du C et qui reste un modèle de prose technique.⁵ Thompson et Ritchie présentèrent le système lui-même au monde dans l’article « The UNIX Time-Sharing System », paru dans les Communications of the ACM de juillet 1974.⁶

Les pipes et le modèle de composition

Si le système de fichiers a fait parler les outils la même langue, les pipes les ont fait se parler entre eux. L’idée était de Doug McIlroy : pendant des années, il avait plaidé pour un moyen de relier les programmes bout à bout, la sortie de l’un s’écoulant directement dans le suivant, comme des tronçons de tuyau d’arrosage. Thompson le mit en œuvre en 1973 — en une seule nuit, raconte la légende — en ajoutant l’appel système pipe() et l’opérateur | au shell.⁷ McIlroy a décrit ce qui s’est passé ensuite : « Le lendemain fut le théâtre d’une orgie inoubliable de one-liners, chacun se laissant gagner par l’excitation de la plomberie. »⁷

Cette orgie de one-liners est la philosophie à l’œuvre. Personne n’eut à écrire un nouveau programme ; on découvrit que les petits programmes que l’on avait déjà pouvaient être enchaînés pour répondre à des questions qu’aucun n’avait été conçu pour traiter. Une chaîne comme grep puis cut puis sort puis uniq -c puis sort -rn puis head est faite de six étapes, chacune ignorante des autres, chacune faisant une seule chose, composées de gauche à droite à travers un flux de texte. La capacité est émergente. Elle vit dans le |, pas dans aucune commande isolée.

C’est l’idée la plus profonde de tout le système. La plupart des logiciels croissent par accrétion : un programme absorbe chaque nouvelle exigence jusqu’à devenir un monolithe que seuls ses auteurs comprennent. Unix croît par composition : le système reste une trousse de petites pièces, et la capacité nouvelle vient de nouveaux agencements de pièces anciennes. Le flux de texte est l’interface universelle qui rend l’agencement gratuit. C’est pourquoi un shell Unix, cinquante ans plus tard, demeure l’un des environnements de programmation les plus expressifs qui soient — non pas malgré le fait d’être composé de minuscules programmes à usage unique, mais grâce à cela.

« Trusting Trust » et l’héritage tardif

En 1983, Thompson et Ritchie reçurent conjointement le prix Turing de l’ACM. La citation salue « le développement d’une théorie générique des systèmes d’exploitation et, plus précisément, l’implémentation du système d’exploitation UNIX », et la déclaration du comité nomme le principe avec exactitude : « Le succès du système UNIX tient à sa sélection pleine de goût de quelques idées clés et à leur implémentation élégante. »⁸ Une sélection pleine de goût de quelques idées clés — le prix fut, en effet, décerné pour la retenue.

La conférence Turing de Thompson lui-même, publiée en 1984 sous le titre « Reflections on Trusting Trust », tourna la même rigueur minimaliste vers la sécurité. Il démontra qu’un compilateur pouvait être instruit à insérer une porte dérobée dans le programme login, et à insérer l’insertion de la porte dérobée dans tout compilateur futur qu’il compilerait — de sorte que le code malveillant ne vivait que dans le binaire, sans laisser la moindre trace dans un code source inspectable. Sa conclusion est l’une des phrases les plus citées de l’informatique : « On ne peut pas faire confiance à du code que l’on n’a pas entièrement créé soi-même… Aucune vérification ni aucun examen au niveau du code source ne vous protégera de l’usage de code non fiable. »⁹ C’est le texte fondateur de la réflexion sur la sécurité de la chaîne d’approvisionnement — la reconnaissance que ce à quoi vous faites confiance n’est pas le code source, mais l’ensemble de la chaîne d’outils qui a produit le binaire.

Les carrières ultérieures des deux hommes prolongèrent les mêmes instincts. Thompson resta agité : aux Bell Labs, il bâtit le système d’exploitation Plan 9 (poussant « tout est un fichier » encore plus loin, à travers un réseau), l’éditeur ed, ainsi que la théorie pratique des expressions régulières et grep. En 1992, avec Rob Pike, il conçut UTF-8 — l’encodage de texte à largeur variable qui transporte aujourd’hui la quasi-totalité du texte mondial — en une seule soirée, esquissé, dit la légende, sur un set de table.³ Et en 2007, chez Google, Thompson co-conçut le langage de programmation Go avec Robert Griesemer et Rob Pike, annoncé publiquement en 2009 : un langage délibérément réduit, à compilation rapide et composable, qui se lit comme un retour conscient aux valeurs d’Unix.¹⁰ Ritchie, mort le 12 octobre 2011, a laissé une empreinte plus discrète mais plus envahissante ; comme l’a formulé l’historien Paul Ceruzzi, « si vous aviez un microscope et pouviez regarder à l’intérieur d’un ordinateur, vous verriez son travail partout dedans ».⁴

La méthode

La méthode est constante sur quarante ans, et chez deux hommes qui eurent rarement besoin de l’expliquer.

Construire des outils petits et précis. Chaque programme fait un seul travail. La discipline est le refus : quand un besoin nouveau apparaît, la réponse est un outil nouveau, pas un drapeau de plus boulonné sur un ancien. « Repartez de zéro plutôt que de compliquer d’anciens programmes. »¹

Composer plutôt qu’accumuler. La capacité est censée émerger de la combinaison. Un système reste compréhensible tant qu’il est une trousse de petites pièces et qu’il croît par réagencement, et non par le gonflement de l’une d’elles en monolithe.

Standardiser l’interface, pas les outils. Le geste unificateur — « tout est un fichier », des flux de texte brut entre les programmes — consiste à rendre la connexion universelle pour que les composants puissent rester ignorants les uns des autres. Des jointures peu coûteuses, voilà ce qui rend de petites pièces puissantes.

Choisir quelques idées clés, avec goût. La formule du comité Turing n’était pas une flatterie ; c’était la méthode. Unix est célèbre pour ce qu’il a laissé de côté. La portabilité par le C, l’abstraction du fichier, le pipe — une poignée de décisions, chacune porteuse d’un poids énorme, avec le superflu délibérément absent.

Se méfier de ce que vous ne pouvez pas inspecter. « Trusting Trust » est la méthode tournée vers l’intérieur : la simplicité et la lisibilité ne sont pas seulement des vertus esthétiques, mais le seul fondement réel de la confiance, car la complexité est l’endroit où peut se cacher ce que vous ne voyez pas.

La chaîne d’influence

Qui les a façonnés

Multics, par contre-exemple. L’influence la plus formatrice de toutes fut un système qu’ils contribuèrent à bâtir avant de s’en détourner. Multics a appris à Thompson et Ritchie, de la manière la plus coûteuse qui soit, ce que coûte l’excès d’ambition — et Unix est, pour une large part, une réaction disciplinée contre lui. (Influence formatrice)

Doug McIlroy. À la tête du Computing Sciences Research Center, McIlroy a inventé le pipe, formulé par écrit la philosophie du « faire une seule chose et bien la faire », et joué le rôle du critique de goût implacable du groupe. Le modèle de composition est autant le sien que celui de quiconque, et c’est à lui qu’il faut attribuer l’énoncé canonique de la philosophie. (Influence directe)

La culture de recherche des Bell Labs. Un petit groupe de pairs, à qui l’on accordait liberté et bonnes machines, optimisant pour l’élégance entre eux plutôt que pour une feuille de route produit. Unix ne fut pas spécifié par la direction ; il s’est accrété à partir d’une culture qui prisait ce qui avait du goût et raillait ce qui était surchargé. (Influence formatrice)

Qui ils ont façonné

Tous les descendants d’Unix. Linux, les BSD et macOS en sont les héritiers directs en ligne directe ; le système que Thompson et Ritchie ont écrit sur un PDP-7 mis au rebut fait tourner aujourd’hui la plupart des serveurs, des téléphones et des appareils embarqués de la planète.

Tous les shells et toutes les lignes de commande. Le pipe et le modèle de composition constituent l’environnement de travail quotidien de pratiquement tout programmeur et tout administrateur système, cinquante ans plus tard — inchangés dans leur essence, parce que cette essence était juste.

Le C et ses enfants. Le C est devenu la lingua franca de la programmation système, et sa syntaxe comme sa sémantique résonnent à travers C++, Java, Go, Rust et l’essentiel de ce qui s’écrit aujourd’hui. Le K&R reste le modèle de la manière de documenter un langage.

La philosophie Unix elle-même. « Faire une seule chose et bien la faire » a débordé Unix pour devenir un principe de conception général — pour les microservices, pour les outils en ligne de commande, pour l’approche du web sans build, faite de petites pièces, et pour la manière de garder les systèmes d’IA assez petits pour rester sûrs et lisibles.

Le fil conducteur

Thompson et Ritchie sont l’expression au niveau système de la même conviction qui traverse cette série. Edsger Dijkstra soutenait que la simplicité est le préalable de la fiabilité ; Unix, c’est cet argument compilé et livré — un noyau de quelques idées clés, gardé assez petit pour qu’on puisse lui faire confiance. Le « bon goût » de Linus Torvalds, la réécriture où le cas particulier disparaît, c’est « faire une seule chose et bien la faire » à l’intérieur d’une seule fonction plutôt qu’à travers une chaîne de traitement ; et Torvalds a bâti Linux et Git directement sur les fondations que ces deux-là ont posées. Le cœur rapide et simple de John Carmack est la même soustraction, visant cette fois le plafond du matériel. Et la conception de Ruby par Yukihiro Matsumoto pour le bonheur humain est l’instinct Unix — de petites pièces composables et expressives — porté jusque dans un langage de haut niveau. Le fil conducteur tient en une phrase : la puissance doit venir de la composition de petites pièces compréhensibles à travers une interface universelle, et non de la croissance d’une pièce isolée. (Pont entre les articles de la série)

Ce que j’en retiens

La leçon que je garde, c’est que l’interface est l’architecture. Quand je conçois quoi que ce soit aujourd’hui — un agent, une boucle d’outils, une chaîne de scripts — la tentation est toujours de rendre un composant plus intelligent, de fondre l’exigence suivante dans ce que j’ai déjà, jusqu’à ce que cela devienne un monolithe que je suis seul à comprendre. Le geste Unix est l’inverse : garder chaque pièce assez petite pour la comprendre entièrement, et placer l’intelligence dans la manière dont les pièces se connectent. Une jointure propre et universelle entre des pièces bêtes l’emporte, à tous les coups, sur une pièce astucieuse dépourvue de jointures propres. C’est la même exigence que la qualité comme seule variable — la question n’est jamais « ce programme peut-il en faire davantage ? », mais « ce système est-il toujours fait de pièces sur lesquelles je peux raisonner ? ».

Dans le monde où je construis désormais — des agents d’IA câblés ensemble par des outils et du texte — la conception de Thompson et Ritchie est plus pertinente qu’elle n’a le droit de l’être à plus de cinquante ans. Un agent est un petit programme ; un outil est un petit programme ; ce qui les rend puissants, c’est une interface propre et universelle entre eux, qui aujourd’hui est surtout du texte structuré. C’est le pipe, rebâti. Et « Trusting Trust » est l’avertissement que je prends le plus au sérieux : quand un système génère du code plus vite que quiconque ne peut le lire, le seul fondement durable de la confiance est de garder les pièces petites et les jointures lisibles, car la complexité est précisément l’endroit où ce que vous ne pouvez pas voir va se cacher. Cette conviction — que le goût est un système technique et que des pièces petites, composables et inspectables ne sont pas un agrément mais l’enjeu tout entier — court en ligne directe d’un PDP-7 de 1969 jusqu’à un cadre d’agent de 2026.

FAQ

Qu’est-ce que la philosophie Unix ?

La philosophie Unix est une approche de conception fondée sur de petits outils à usage unique qui se composent via une interface universelle. Son énoncé canonique, de Doug McIlroy en 1978, est le suivant : « Écrivez des programmes qui font une seule chose et la font bien. Écrivez des programmes qui collaborent. Écrivez des programmes qui traitent des flux de texte, car c’est une interface universelle. » Le premier principe consiste à construire un outil nouveau plutôt qu’à ajouter des fonctionnalités à un outil existant, et la puissance du système vient de la combinaison de petites pièces — via les pipes et le texte brut — et non de la croissance d’un programme isolé.¹

Ken Thompson a-t-il dit « faire une seule chose et bien la faire » ?

Non. La maxime « faire une seule chose et bien la faire » et la philosophie Unix au sens large ont été formulées par écrit par Doug McIlroy, à la tête du Computing Sciences Research Center des Bell Labs, dans sa préface au numéro spécial de 1978 du Bell System Technical Journal consacré à Unix.¹ Thompson et Ritchie ont bâti le système qui incarne la philosophie, et McIlroy — qui a aussi inventé le pipe Unix — en fut le formulateur le plus clair et le critique de goût attitré du groupe. Attribuer la maxime à Thompson est un raccourci courant, mais erroné.

Qu’ont réellement créé Thompson et Ritchie ?

Ken Thompson a bâti les premières versions du système d’exploitation Unix sur un PDP-7 à partir de 1969, puis a créé le langage B, l’éditeur ed, la recherche pratique par expressions régulières (grep), le système Plan 9, UTF-8 (avec Rob Pike), et a co-conçu Go chez Google.³ Dennis Ritchie a créé le langage de programmation C (1969-1973), s’en est servi pour réécrire Unix en 1973 afin de le rendre portable, et a co-écrit The C Programming Language avec Brian Kernighan en 1978.⁴⁵ Ils ont reçu conjointement le prix Turing de l’ACM 1983 pour Unix.⁸

Qu’est-ce que « Reflections on Trusting Trust » ?

C’est la conférence du prix Turing de l’ACM donnée par Ken Thompson en 1984, publiée dans les Communications of the ACM. Il y montrait qu’un compilateur pouvait être amené à insérer une porte dérobée cachée dans un programme, et à reproduire cette porte dérobée chaque fois qu’il compilait une nouvelle version de lui-même — de sorte que le code malveillant n’existait que dans le binaire et ne laissait aucune trace dans un code source lisible. Sa conclusion : « On ne peut pas faire confiance à du code que l’on n’a pas entièrement créé soi-même… Aucune vérification ni aucun examen au niveau du code source ne vous protégera de l’usage de code non fiable. » C’est un texte fondateur de la sécurité de la chaîne d’approvisionnement logicielle.⁹

Sources