I. Le triomphe de l’objet

Descartes avait posé la règle dans le Discours de la méthode : pour résoudre un problème difficile, décompose-le en ses parties les plus simples, analyse chaque partie séparément, puis remonte vers le complexe. C’est l’instinct analytique de l’Occident — et c’est, à sa manière, la préhistoire de la programmation orientée objet.

Le nom de Grady Booch sert à fixer quelque chose qui s’est produit dans les années 1980 et 1990 : le triomphe de l’objet. Avant cela, le logiciel était processus — verbes COBOL, sous-routines Fortran, fonctions C. Tu décrivais ce que le système fait, non ce qu’il est. Les programmes avaient des flux, des instructions, des verbes.

Puis vinrent le Langage de Modélisation Unifié, les patrons de conception, l’idée que l’on pouvait abstraire la réalité en classes, en hiérarchies, en responsabilités. Le catalogue du Gang des Quatre promettait l’ordre : Observer, Strategy, Adapter. Chaque patron était une forme d’objet, une manière d’organiser le code autour de noms plutôt que de verbes. L’Object-Oriented Analysis and Design de Booch devint la grammaire d’une nouvelle façon de penser le calcul.

Cela a fonctionné. La POO a mis à l’échelle des systèmes suffisamment grands pour nécessiter structure et hiérarchie. IBM, Microsoft, Java. L’objet devint l’unité de pensée.

II. Les fissures

Mais observe ce qui s’est passé en marge. À mesure que les systèmes grandissaient, le problème était les connexions entre objets. Les données ont commencé à vivre ailleurs — une base de données relationnelle, un autre système, le réseau. On ne pouvait plus le cacher. Alors on a inventé l’architecture orientée services, puis les microservices. Qu’est-ce que c’est ? Un retour aux processus. Des systèmes qui font des choses, qui communiquent, qui ont des frontières, qui exposent un comportement au lieu de cacher un état.

Le mouvement des microservices a commencé comme une libération — libère le monolithe, laisse chaque service faire une chose. Ce qui a suivi fut un cauchemar de systèmes distribués : pannes partielles, latence réseau, cohérence éventuelle, le théorème CAP planer sur chaque décision de conception. Les objets avaient caché la complexité dans des hiérarchies. Les microservices ont distribué cette complexité sur le réseau. On avait échangé un type de désordre contre un autre.

III. L’autre côté n’a jamais disparu

Pendant ce temps, les langages fonctionnels — Lisp, Haskell, Scheme — n’ont jamais abandonné le processus. Ils insistaient sur les fonctions comme transformations, les données comme immuables, la composition comme opération fondamentale. Pendant des décennies, ils semblaient être le camp perdant, la préférence des universitaires sans systèmes réels à livrer.

Puis quelque chose a changé. Les goroutines de Go, le modèle de propriété de Rust, la dérive lente de Python vers l’immuabilité, l’adoption par JavaScript de map et reduce — tout cela signale que le pendule revient. L’intuition selon laquelle des données immuables et des fonctions composables produisent moins de surprises que des objets avec état n’est pas nouvelle ; Lisp le savait en 1958. Il a simplement fallu cinquante ans de bogues accumulés pour en convenir.

IV. L’arc complet

Le stockage des données raconte la même histoire. Les cartes perforées étaient processus pur — instructions, verbes, séquences. Les fichiers étaient des noms : on pouvait les stocker, les déplacer, les organiser. Les bases de données relationnelles ont tenté d’être les deux : données organisées par schéma et interrogeables par SQL, un langage de processus. NoSQL a reculé vers la pensée documentaire sans schéma — puis a dû reconstruire le moteur de requêtes car personne ne pouvait vivre sans processus. GraphQL est presque processus pur : tu demandes ce qui coule, non ce qui existe.

Les méthodologies ont oscillé aussi. La cascade définissait le flux du système, puis le construisait. La conception orientée objet promettait que tu pourrais spécifier la chose et que le flux suivrait. Agile a soutenu que le processus est ce qui compte — itérer, parler, livrer. DevOps a fait le pas supplémentaire : le processus est le système. Ton infrastructure, ton déploiement, ta surveillance — c’est le produit, pas le code qu’ils exécutent.

L’arc complet : assembleur (processus pur), COBOL (processus avec données), C (données avec pointeurs de fonctions), C++ (objets avec membres de données), Java (les objets comme toute l’histoire), Python (objets qui agissent comme des fonctions), Go (fonctions qui se composent), microservices (processus qui parlent), serverless (processus qui s’adaptent), observabilité (la visibilité du processus comme produit).

V. Ce qu’enseigne le pendule

Nous ne sommes pas plus intelligents maintenant qu’en 1985. Nous apprenons de nouveau la leçon.

Bergson l’avait compris autrement. Dans L’Évolution créatrice, il attaque précisément l’instinct cartésien : l’intelligence humaine découpe le réel en solides distincts, en objets stables, parce que c’est pratique pour agir sur lui — mais la réalité est durée, flux continu, devenir. Nos catégories ne sont pas des découpages du monde ; ce sont des arrêts sur image dans un film qui ne s’arrête jamais. Les objets sont des processus auxquels nous avons décidé, pour notre confort, de donner des noms.

L’intuition réelle n’est pas qu’un côté a raison. C’est qu’ils posent la même question depuis des angles opposés. Les objets sont des processus figés. Les processus sont des objets en mouvement. Tu as besoin des deux. L’erreur est de prétendre que tu peux choisir l’un et gagner.

Grady Booch et les années 1980 n’avaient pas tort. Ils ont simplement perdu de vue à quoi servaient les objets — ce qui a toujours été de rendre le processus plus clair, plus testable, plus maintenable. Quand l’objet est devenu le but au lieu du moyen, le pendule a commencé à revenir. Comme toujours.

Le travail est ce qui compte. Les modèles, les paradigmes, les langages — ils essaient tous de rendre le travail visible. Quatre-vingts ans d’oscillation, et la leçon n’a pas changé : comprends ce que tu fais réellement, et la question de comment le représenter se répondra d’elle-même.

Le même argument, appliqué à l’automatisation et pourquoi l’appeler « IA » obscurcit ce qui compte vraiment, est dans Processus sur objets.

Lectures complémentaires

Pour Eduardo : quarante ans dans ce métier, et la technologie court toujours. Le pendule nous doit des excuses.