07.10.2026 · Signal Titans Editorial

Douglas McIlroy voulait faire communiquer les programmes. Les pipes Unix l’ont rendu pratique.

Grand portrait de Douglas McIlroy sur panneau sombre à gauche, avec symbole pipe, titre et pipeline de commandes à droite.

L’une des idées les plus puissantes d’Unix tient dans un seul caractère : |. Un pipe permet à la sortie d’un programme de devenir l’entrée d’un autre, de sorte que de petits outils puissent être combinés en workflows que leurs auteurs n’avaient jamais explicitement prévus. Cette idée est étroitement associée à M. Douglas McIlroy, qui dirigeait le département de recherche de Bell Labs où Unix est né et qui a longtemps défendu la communication entre programmes par flux de données.

Le problème n’était pas l’absence de programmes puissants

Les premiers systèmes informatiques rassemblaient souvent de nombreuses fonctions dans de gros programmes. Trier des données, transformer du texte, compter des enregistrements ou formater une sortie pouvait revenir à choisir différents modes d’un même utilitaire monolithique. McIlroy préférait une autre direction : construire de petits programmes aux responsabilités claires, puis rendre leur connexion facile. Sa formulation ultérieure de la philosophie Unix est devenue célèbre : des programmes qui font une chose et la font bien, qui peuvent travailler ensemble et qui traitent les flux de texte comme une interface universelle.

Ce principe était philosophique mais aussi pratique. Les premiers ordinateurs imposaient de sévères contraintes de mémoire, et les petits programmes étaient plus faciles à construire et à faire tenir dans la machine. Mais une fois l’idée éprouvée, Unix la conserva même lorsque le matériel devint plus puissant. Une culture logicielle naquit dans laquelle la composition était une fonctionnalité à part entière.

McIlroy insistait pour relier directement les processus

Avant même l’existence des pipes Unix, McIlroy s’intéressait au stream processing et aux moyens de faire passer directement les données d’un programme à un autre. À Bell Labs, il plaida à plusieurs reprises pour un mécanisme permettant à un processus d’alimenter le suivant sans imposer des fichiers temporaires entre chaque étape. Ken Thompson finit par implémenter les pipes dans Unix, transformant l’idée en une fonction simple du système d’exploitation utilisable depuis le shell.

Le changement conceptuel dépassait largement le symbole. Grâce aux pipes, le shell devint un environnement où l’utilisateur pouvait créer de nouveaux comportements en chaînant des commandes existantes. Un outil n’avait pas besoin de savoir qui avait produit son entrée ni où sa sortie irait. Il devait seulement respecter une convention commune. Ce faible couplage explique pourquoi des utilitaires aussi simples que grep, sort, uniq, tr et wc peuvent être recombinés de tant de façons.

Le pipe a transformé une interface étroite en levier puissant

La contribution de McIlroy rappelle que l’architecture logicielle dépend souvent des frontières entre composants, pas seulement des composants eux-mêmes. Le pipe Unix fonctionne parce que les commandes acceptent une interface simple : un flux d’octets, souvent interprété comme du texte. Cette interface est étroite, mais c’est précisément cette étroitesse qui la rend réutilisable.

Cette approche est partout aujourd’hui. Les data pipelines relient des étapes de traitement indépendantes. Les services web communiquent via des API. Les systèmes de build passent des artefacts d’un outil au suivant. Les architectures événementielles permettent aux producteurs et consommateurs d’évoluer séparément. Les conteneurs et outils en ligne de commande sont encore fréquemment assemblés grâce au même modèle de flux Unix.

Le travail de McIlroy dépassait largement un seul opérateur

Sa biographie à Dartmouth mentionne les macro processors, les langages de programmation, les expressions régulières, la gestion mémoire, la sécurité, les graphiques, les projections cartographiques, la documentation et de nombreux utilitaires Unix. Il dirigeait un département de Bell Labs où travaillaient plusieurs créateurs centraux d’Unix tout en contribuant lui-même des outils et des idées. Son parcours illustre une forme d’influence technique facile à sous-estimer : concevoir des environnements dans lesquels les autres peuvent créer.

Il accordait aussi une grande importance à la clarté. La tradition Unix issue de Bell Labs privilégiait les manuels courts, les outils réutilisables et les interfaces simples à comprendre localement. McIlroy expliqua plus tard que le principe « faire une chose » était en partie né de contraintes matérielles sévères, mais qu’il avait survécu parce qu’il favorisait des programmes faciles à composer.

Un minuscule connecteur a changé la façon dont le logiciel peut grandir

Le pipe n’a pas rendu chaque commande plus intelligente. Il a rendu leur relation plus utile. Cette distinction reste importante. Les systèmes complexes évoluent souvent mieux lorsque l’intelligence est répartie entre de petits composants dotés d’interfaces stables plutôt que concentrée dans un énorme programme.

Chaque fois qu’un développeur écrit cat log | grep error | sort | uniq -c, il utilise une idée de conception née dans une époque bien plus ancienne de l’informatique. Le matériel est différent, l’échelle est différente et le logiciel environnant est infiniment plus sophistiqué. Mais le principe reste très moderne : construire de petites choses qui peuvent se connecter, puis laisser la composition créer la complexité.