Philosophie de l'ingénierie : Barbara Liskov, le contrat fait le type

L’essentiel à retenir

• L’abstraction porte sur le comportement, pas sur la structure. Un type est le contrat qu’il respecte — les opérations et leur signification — et non les bits qu’il stocke. On se sert d’une chose par ses promesses, jamais par sa représentation.
• Un sous-type doit honorer les promesses de son supertype. C’est le principe de substitution de Liskov : partout où un supertype est attendu, un sous-type doit fonctionner sans rompre les hypothèses de l’appelant — préconditions plus faibles, postconditions plus fortes, invariants préservés.
• La modularité, c’est raisonner sur une partie sans tenir le tout. La définition précise de Liskov : on peut comprendre et vérifier un module isolément, en faisant confiance à ses dépendances pour respecter leurs contrats. L’abstraction est ce qui rend cette confiance légitime.
• Elle a fait de l’abstraction de données une primitive de programmation. De CLU à Argus jusqu’au prix Turing 2008, une seule idée passe à l’échelle, d’une structure de données à une base de données distribuée : définir le contrat, masquer le mécanisme.

Le principe

« Soit φ(x) une propriété démontrable sur les objets x de type T. Alors φ(y) doit être vraie pour les objets y de type S, où S est un sous-type de T. » — Barbara Liskov et Jeannette Wing¹

Lue lentement, voilà l’énoncé formel de ce que le domaine appelle désormais le principe de substitution de Liskov, tiré de son article de 1994 écrit avec Jeannette Wing.¹ Dépouillé de sa notation, il dit quelque chose de presque sévère : un sous-type n’a pas le droit de vous surprendre. Tout ce que vous pourriez démontrer comme vrai à propos du supertype doit le rester lorsque vous remettez au programme un sous-type à la place. Le sous-type hérite des promesses du parent, pas seulement de sa forme — et s’il ne peut pas tenir ces promesses, ce n’est pas un sous-type, quoi qu’en dise le vérificateur de types.

Derrière cette sévérité, on trouve l’aboutissement d’une idée unique que Liskov a poursuivie pendant quarante ans : un type est défini par son comportement, et non par sa représentation. Un module est un contrat — un ensemble d’opérations dotées d’une signification spécifiée — et tout l’intérêt du contrat tient à ce que vous pouvez vous servir de la chose sans lire comment elle est construite. La substituabilité n’est que cette conviction appliquée à l’héritage : si S prétend être une sorte de T, alors partout où un T était promis, un S doit honorer la même promesse. La structure peut différer. Le comportement, non.

Pourquoi cela compte, c’est le fil qui traverse toute sa carrière : les grands programmes ne sont gérables que si l’on peut raisonner sur une pièce sans tenir l’ensemble dans sa tête. Le mot de Liskov pour cela était modularité, et elle lui donnait un sens précis : la capacité de comprendre et de vérifier un module isolément, en se fiant à ce que tout ce dont il dépend respectera le contrat annoncé. L’abstraction de données est ce qui rend cette confiance légitime, et le sous-typage comportemental est ce qui empêche l’héritage de la rompre en douce. C’est la même conviction qui sous-tend l’argument selon lequel les bons systèmes sont conçus pour que le goût soit un système technique que l’on peut examiner — un contrat que l’on peut énoncer et vérifier — plutôt qu’une tradition que l’on absorbe en lisant l’ensemble du code.

Le contexte

Barbara Jane Huberman Liskov est née le 7 novembre 1939 à Los Angeles, en Californie.² Elle a obtenu une licence de mathématiques, avec une mineure en physique, à l’université de Californie à Berkeley, en 1961.² Lorsqu’elle a postulé à des programmes de troisième cycle en mathématiques à Berkeley et à Princeton, Princeton n’admettait pas du tout les femmes ; elle s’est donc mise à travailler, et s’est retrouvée presque par hasard dans les débuts de l’informatique, programmant à la Mitre Corporation puis à Harvard, avant de décider qu’elle voulait finalement le doctorat.²

Elle a obtenu son doctorat à Stanford en 1968 — l’une des premières femmes aux États-Unis à recevoir un doctorat délivré par un département d’informatique.² Son directeur de thèse était John McCarthy, l’inventeur de Lisp et l’un des fondateurs du domaine de l’intelligence artificielle ; sa thèse construisait un programme pour jouer les finales d’échecs, et chemin faisant elle a imaginé l’heuristique du tueur (killer heuristic), une astuce d’ordonnancement des coups encore utilisée dans la recherche dans les arbres de jeu.² Ce détail mérite qu’on le retienne : elle est venue par l’IA, sous la direction de l’homme qui a forgé le terme, puis s’en est détournée vers le problème qui allait la définir — non pas comment faire penser une machine, mais comment rendre un grand programme compréhensible.

Après Stanford, elle est retournée à Mitre, où elle a dirigé la conception du système d’exploitation Venus — un petit système interactif en temps partagé, à faible coût, bâti pour explorer comment une architecture matérielle et logicielle soignée pouvait simplifier un système.²³ En 1972, elle a rejoint le corps enseignant du MIT, où elle est restée depuis, désormais Institute Professor, le rang le plus élevé que l’institution décerne.² Venus lui avait appris la question. L’angoisse de la « crise du logiciel » du début des années 1970 — la prise de conscience naissante que les programmes étaient devenus trop volumineux pour que quiconque puisse raisonner à leur sujet — l’a aiguisée. La réponse fut CLU.

L’œuvre

L’abstraction de données et le langage CLU

À partir de 1973, Liskov et ses étudiants au MIT ont conçu et construit CLU, l’un des langages les plus discrètement influents jamais réalisés — un langage dans lequel presque personne n’a écrit de code de production, mais dont les idées se retrouvent aujourd’hui dans pratiquement tout.⁴ Son concept organisateur était le cluster, qui a donné son nom au langage : une unité qui regroupe une représentation de données avec les opérations autorisées sur elle, et masque entièrement la représentation derrière cet ensemble d’opérations.⁴ Le cluster était la réalisation concrète du type de données abstrait — l’idée qu’un type ne devrait être connu de ses utilisateurs que par ce qu’il fait, jamais par la façon dont il stocke ses bits.⁴⁵

CLU ne s’est pas arrêté là. Il a inventé ou popularisé un ensemble remarquable de fonctionnalités aujourd’hui incontournables : les itérateurs, implémentés sous forme de coroutines avec une instruction yield, permettant de parcourir une collection sans exposer sa structure interne ; la gestion structurée des exceptions avec signal et except, traitée comme une partie du flot de contrôle normal plutôt que greffée après coup ; le polymorphisme paramétrique — des types paramétrés avec contraintes et sûrs du point de vue des types, l’ancêtre des génériques ; des types variants sûrs ; et le renvoi de valeurs multiples par affectation parallèle.⁴ Les itérateurs ont réapparu dans Python, C# et Ruby. Les types paramétrés sont devenus les génériques de Java et de C#. La gestion des exceptions a façonné Java et C++. Les concepteurs de Swift ont cité CLU nommément.⁴ Le langage était une banque de graines.

Mais les fonctionnalités étaient en aval du principe. L’argument de Liskov était que l’abstraction est le mécanisme par lequel nous maîtrisons la complexité — on construit une chose difficile en définissant une frontière nette, en spécifiant ce qui la franchit, puis en n’ayant plus jamais à penser aux deux côtés à la fois. CLU était la preuve qu’un langage de programmation pouvait faire respecter cette frontière, et non seulement la permettre. Le compilateur devenait un allié du contrat.

Le principe de substitution de Liskov

En 1987, Liskov a donné une keynote à OOPSLA intitulée « Data Abstraction and Hierarchy », publiée l’année suivante dans SIGPLAN Notices.⁶ La programmation orientée objet était en plein essor, et avec elle l’idée de sous-types — des types qui héritent d’autres types et les étendent. La question de Liskov était celle, évidente, que personne n’avait énoncée avec précision : quand est-il réellement sûr de traiter un sous-type comme son supertype ? Sa réponse, dans les termes mêmes de la keynote, était une propriété de substitution : « Ce que l’on veut ici, c’est quelque chose comme la propriété de substitution suivante : si pour chaque objet o1 de type S il existe un objet o2 de type T tel que, pour tous les programmes P définis en termes de T, le comportement de P reste inchangé lorsqu’on substitue o1 à o2, alors S est un sous-type de T. »⁶

La paraphrase populaire que l’on voit partout — « si S est un sous-type de T, alors les objets de type T peuvent être remplacés par des objets de type S sans altérer aucune des propriétés souhaitables du programme » — en est une compression fidèle.⁷ En 1994, Liskov et Jeannette Wing l’ont rendue rigoureuse dans l’article « A Behavioral Notion of Subtyping », posant les conditions qu’un véritable sous-type doit remplir : ses méthodes ne doivent rien exiger de plus (préconditions plus faibles ou égales) et ne rien promettre de moins (postconditions plus fortes ou égales) que celles du supertype, et il doit préserver les invariants et les propriétés d’historique du supertype.¹ Ces conditions, prises ensemble, sont ce qu’on entend par sous-typage comportemental — et c’est pourquoi les formulations familières du type « si ça ressemble à un canard et que ça cancane comme un canard » ne sont pas d’elle et passent à côté de l’essentiel : ressembler et cancaner relèvent de la forme ; le principe porte sur les promesses tenues.

Le contre-exemple classique est le carré qui hérite du rectangle. Un Rectangle vous laisse fixer indépendamment la largeur et la hauteur ; un client peut fixer la hauteur et se fier à ce que la largeur reste inchangée. Un Square qui en hérite doit forcer les deux à être égales — si bien que fixer la hauteur modifie silencieusement la largeur, et l’hypothèse raisonnable du client est violée.⁷ Le carré est un rectangle au sens du dictionnaire, passe toutes les vérifications de types, et n’est pourtant pas un sous-type comportemental, parce qu’il ne peut pas tenir les promesses du rectangle. Toute la leçon tient dans cette seule figure : hériter de la structure n’est pas hériter du contrat.

Les systèmes distribués : Argus et Thor

Liskov n’en est pas restée à la conception de langages. Au début des années 1980, elle a construit Argus, décrit comme le premier langage de haut niveau à prendre en charge l’implémentation de programmes distribués — des programmes répartis sur des machines qui tombent en panne indépendamment les unes des autres.²³ Argus, une extension de CLU, a introduit les guardians (des objets qui encapsulent un état distribué, accessibles via des handlers) et les actions atomiques (des transactions qui se terminent entièrement ou pas du tout, même à travers des pannes, coordonnées par une validation à deux phases), et il a démontré le pipelining de promesses, où l’on peut émettre un appel et continuer à travailler avant que son résultat ne revienne.⁹ Le problème difficile de la distribution, c’est la panne partielle — un nœud meurt pendant que les autres vivent — et Argus y a appliqué l’abstraction de données : un guardian est un contrat qui tient même lorsque le réseau, lui, ne tient pas.

Thor, dans les années 1990, était une base de données distribuée orientée objet, offrant un stockage persistant fiable et hautement disponible d’objets accédés par des programmes écrits dans de nombreux langages.²³ Le fil conducteur depuis CLU est exact. Un cluster masque une représentation derrière des opérations ; un guardian masque un état distribué derrière des opérations atomiques ; un objet Thor masque la persistance derrière une interface typée. À chaque échelle — une structure de données, un service réseau, une base de données — le geste de Liskov est le même : définir le contrat, masquer le mécanisme, et laisser le reste du système raisonner sur le seul contrat.

Le prix Turing 2008 et l’héritage

En 2009, l’ACM a décerné à Liskov le prix A.M. Turing 2008 — la plus haute distinction de l’informatique — avec la citation : « Pour ses contributions aux fondements pratiques et théoriques de la conception des langages de programmation et des systèmes, en particulier en lien avec l’abstraction de données, la tolérance aux pannes et l’informatique distribuée. »⁸ La citation détaillée nomme le fil conducteur avec précision : elle a fait progresser « l’abstraction de données, la modularité, la tolérance aux pannes, la persistance et les systèmes d’informatique distribuée. »⁸ Elle avait déjà reçu la médaille IEEE John von Neumann en 2004 « pour ses contributions fondamentales aux langages de programmation, à la méthodologie de programmation et aux systèmes distribués », et elle a ensuite été intronisée au National Inventors Hall of Fame (2012) et a reçu la médaille Benjamin Franklin (2023).²

L’héritage n’est pas un langage ou un système que l’on pourrait désigner et exécuter. C’est que la manière dont les programmeurs en activité pensent aujourd’hui — « programmer pour une interface », « dépendre de contrats, pas d’implémentations », « cette classe viole le LSP » — relève du vocabulaire de Liskov, absorbé si complètement que la plupart des gens qui l’emploient n’ont jamais lu l’article. C’est le type d’influence le plus profond : quand votre idée cesse d’être attribuée parce qu’elle est devenue l’air qu’on respire.

La méthode

La méthode est cohérente sur trente ans — systèmes d’exploitation, conception de langages et bases de données distribuées.

Définir le type par son comportement, pas par sa représentation. Le geste récurrent consiste à tracer une frontière, à spécifier exactement ce qui la franchit, puis à refuser que l’un ou l’autre côté dépende des entrailles de l’autre. Un cluster, un guardian, un objet Thor sont tous le même acte : un contrat qui masque un mécanisme.⁴⁵

Rendre la modularité littérale, puis la faire respecter. La modularité, pour Liskov, n’est pas une préférence d’organisation du code — c’est la capacité de raisonner sur un module isolément, en se fiant à ce que ses dépendances respectent leurs contrats. Le compilateur de CLU faisait respecter la barrière d’abstraction au lieu de la suggérer poliment. La discipline n’est réelle que si l’outil la vérifie.⁴

Un sous-type doit tenir les promesses de son supertype. Le sous-typage comportemental est le principe selon lequel l’héritage est un contrat, pas une commodité. Préconditions plus faibles, postconditions plus fortes, invariants préservés — le sous-type peut faire plus, mais il ne peut jamais exiger plus ni promettre moins que son supertype.¹

Attaquer le problème difficile à la frontière. La panne partielle dans les systèmes distribués est brutale précisément parce qu’elle brise votre capacité à raisonner localement. La réponse d’Argus a été de pousser l’abstraction jusque dans le modèle de panne lui-même — actions atomiques et guardians — pour qu’un programmeur puisse encore raisonner sur une pièce sans simuler toutes les façons dont le réseau pouvait s’effondrer.²³

Porter une seule idée jusqu’au bout. L’abstraction de données à l’échelle d’une pile, d’un service réseau et d’une base de données est reconnaissablement la même idée. Liskov n’a pas inventé une nouvelle philosophie pour chaque domaine ; elle a trouvé celle qui passait à l’échelle et l’a chevauchée d’un système de types des années 1970 à un magasin distribué des années 1990.

Chaîne d’influence

Qui l’a façonnée

John McCarthy. Son directeur de thèse à Stanford, l’inventeur de Lisp et un fondateur de l’IA, lui a donné à la fois la rigueur de l’informatique mathématique et — par son éloignement de l’IA vers la structure des programmes — le problème qui allait devenir l’œuvre de sa vie.² (Influence directe)

La crise du logiciel et l’ère de la programmation structurée. Liskov est devenue chercheuse exactement au moment où le domaine a admis que les programmes avaient dépassé la compréhension humaine. Le mouvement de la programmation structurée — Dijkstra, Hoare, Wirth — avait soutenu que le flot de contrôle devait être discipliné pour qu’on puisse raisonner à son sujet. Liskov a étendu la même conviction aux données : il ne suffit pas de discipliner la façon dont un programme se déplace ; il faut discipliner ce que ses données signifient et qui est autorisé à voir comment elles sont stockées. (Influence formatrice)

C.A.R. Hoare et la discipline de la spécification. Les travaux de Hoare sur les préconditions, les postconditions et les invariants — raisonner sur les programmes comme sur des assertions logiques — sont l’ancêtre intellectuel direct des conditions de sous-typage comportemental qu’elle et Wing ont rendues précises. (Influence formatrice)

Qui elle a façonné

Tout système de types moderne. Les génériques en Java et C#, les itérateurs en Python et C#, la gestion des exceptions dans toute la famille du C, la conception de Swift — les fonctionnalités inventées par CLU constituent aujourd’hui le mobilier par défaut de presque tous les langages.⁴

La pratique orientée objet. « Programmer pour une interface, pas pour une implémentation », l’inversion des dépendances et le « L » de tout le vocabulaire SOLID, c’est le principe de Liskov, rendu opérationnel. Une génération a appris à repérer une mauvaise sous-classe sans jamais apprendre de qui était l’idée.⁷

L’ingénierie des systèmes distribués. Les actions atomiques, les garanties transactionnelles à travers des nœuds défaillants, et la pratique consistant à traiter un service distant comme un contrat qui survit à une panne partielle remontent à Argus et à Thor.²³

Le fil conducteur

Edsger Dijkstra a soutenu qu’un programme doit être structuré de façon qu’un humain puisse raisonner à son sujet — la programmation structurée était la discipline du flot de contrôle au service de la correction. Liskov en est la lignée directe : elle a fait pour les données ce que Dijkstra a fait pour le contrôle, en insistant sur le fait que le raisonnement modulaire exige des barrières d’abstraction disciplinées, et pas seulement des boucles disciplinées. Et là où Thompson et Ritchie ont bâti Unix et C autour de petits composants qui « font une seule chose, mais bien » et se composent par des interfaces nettes, Liskov a fourni la théorie du pourquoi cette composition est digne de confiance : un composant sur lequel on peut compter est un composant dont on peut énoncer le contrat et dont les sous-types l’honorent. Même le compilateur de Grace Hopper était un acte d’abstraction — déplacer la traduction dans la machine pour qu’un humain puisse raisonner dans ses propres termes ; Liskov a fait de l’abstraction elle-même l’unité de conception des programmes, plutôt qu’une commodité fournie par le compilateur. (Passerelle de la série)

Ce que j’en retiens

La leçon que je garde, c’est qu’une interface est une promesse, et que les seules interfaces qui valent quelque chose sont celles que l’on tient réellement. Il est facile d’écrire une signature de type ; il est difficile d’honorer tout ce que cette signature implique et de ne jamais la violer en douce sous une nouvelle sous-classe ou un refactoring. Le principe de Liskov est l’exigence à laquelle je soumets une frontière : non pas « la vérification de types passe-t-elle ? » mais « un appelant peut-il se fier à cette chose partout où l’on se fiait à son parent, sans lire comment elle est construite ? » C’est la même barre que la qualité comme seule variable — la question n’est jamais de savoir si le code compile, mais si le contrat est réel.

Dans le monde où je construis aujourd’hui — agents, boucles d’outils, systèmes d’IA — la conviction de Liskov est plus porteuse que jamais, parce que les composants que j’assemble sont opaques par nature. Un outil, un sous-agent, un appel de modèle est un module : on l’invoque sur un contrat et on ne peut pas lire ses entrailles. Tout l’enjeu est de savoir si ce contrat tient — si un outil qui prétend « chercher dans le code » renvoie réellement ce que sa spécification promettait, ou si remplacer un modèle par un autre affaiblit silencieusement une postcondition dont le reste du système dépendait. C’est le principe de substitution de Liskov en habits de 2026 : un composant substitué doit tenir les promesses de celui qu’il remplace. La discipline qui consiste à énoncer des contrats et à vérifier que les sous-types les honorent est exactement celle qui fait de la barrière de la preuve plus qu’un slogan — un système sur lequel on peut raisonner par morceaux, parce que chaque morceau tient parole.

FAQ

Quelle est la philosophie d’ingénierie de Barbara Liskov ?

La conviction centrale de Liskov est qu’un type est défini par son comportement, et non par sa représentation, et que c’est ce qui rend les grands programmes gérables. Un module est un contrat — un ensemble d’opérations dotées de significations spécifiées — et le but du contrat est que l’on puisse se servir du module sans comprendre comment il est construit. Cette idée d’abstraction de données traverse tout ce qu’elle a construit, du langage CLU au système distribué Argus, et elle a produit son résultat le plus célèbre : le principe selon lequel un sous-type doit honorer chacune des promesses faites par son supertype.⁴⁵¹

Qu’est-ce que le principe de substitution de Liskov ?

C’est l’exigence qu’un sous-type soit utilisable partout où son supertype est attendu, sans rompre les hypothèses de l’appelant. Formellement, dans l’énoncé de Liskov et Wing de 1994 : « Soit φ(x) une propriété démontrable sur les objets x de type T. Alors φ(y) doit être vraie pour les objets y de type S, où S est un sous-type de T. »¹ Dans sa keynote OOPSLA de 1987, elle l’a formulé comme une propriété de substitution : si substituer un objet de type S à un objet de type T laisse inchangé le comportement de tout programme, alors S est un sous-type de T.⁶ En pratique, un véritable sous-type ne doit rien exiger de plus que son supertype (préconditions plus faibles ou égales), ne rien promettre de moins (postconditions plus fortes ou égales), et préserver ses invariants. Les formulations populaires du type « si ça ressemble à un canard » ne sont pas de Liskov et passent à côté de l’essentiel : le principe porte sur les promesses tenues, pas sur la ressemblance de surface.⁷

Qu’a inventé Barbara Liskov ?

Elle a conçu et dirigé l’implémentation du langage de programmation CLU (commencé en 1973), qui a introduit ou popularisé les types de données abstraits, les itérateurs, la gestion structurée des exceptions et le polymorphisme paramétrique — des fonctionnalités aujourd’hui standard en Java, C#, Python, Swift et d’autres.⁴ Auparavant, elle avait construit le système d’exploitation en temps partagé Venus ; plus tard, elle a créé Argus, le premier langage de haut niveau pour les programmes distribués, et Thor, une base de données distribuée orientée objet.²³ Avec Jeannette Wing, elle a formalisé le sous-typage comportemental, aujourd’hui appelé principe de substitution de Liskov.¹

Pourquoi Barbara Liskov a-t-elle reçu le prix Turing ?

L’ACM lui a décerné le prix A.M. Turing 2008 « pour ses contributions aux fondements pratiques et théoriques de la conception des langages de programmation et des systèmes, en particulier en lien avec l’abstraction de données, la tolérance aux pannes et l’informatique distribuée. »⁸ La reconnaissance couvre toute sa carrière : avoir fait de l’abstraction de données une primitive de langage de programmation grâce à CLU, avoir fait progresser la modularité et la théorie du sous-typage, et avoir mis ces idées au service du problème difficile de la construction de systèmes fiables sur des machines qui tombent en panne indépendamment les unes des autres. Elle a été l’une des premières femmes aux États-Unis à obtenir un doctorat en informatique (Stanford, 1968) et elle est Institute Professor au MIT.²

Sources