I. La Querelle Grecque

Les anciens Grecs posaient une question qui paraît simple jusqu’à ce que vous tentiez d’y répondre : Qu’est-ce qui est réel ? Non pas ce qui existe, mais ce qui compte comme être—ce qui a une substance, ce qui mérite notre attention.

Socrate, errant dans l’agora d’Athènes, disait que c’était le processus. Non l’objet—la statue, la loi, la définition gravée dans la cire. Ce qui importait, c’était la méthode : comment pensions-nous ? Comment questionnions-nous ? Comment arrivions-nous à ce qui pouvait être vrai ? Les dialogues platoniciens, désespérément circulaires pour les lecteurs modernes, en sont la preuve. Socrate acculait quelqu’un, le laissait trébucher sur ses affirmations assurées, et lui montrait les failles. Le faire était la philosophie. Le dialogue lui-même était le but.

Platon, son élève, n’était pas d’accord. Il voyait les objets éternels—les Formes, les modèles parfaits et immuables qui flottaient au-delà du monde matériel. Une action juste particulière participait à la Justice même. Un beau visage reflétait la Beauté. Le monde du processus et du changement était une simple ombre. La chose réelle était l’idée, le modèle, la forme.

Aristote partageait la différence, mais quand la poussière se déposa, il se rangea du côté du processus. Tout, pour Aristote, a une ergon—une fonction, une activité, une manière d’opérer. L’essence d’un couteau n’est pas ses atomes de bronze mais ce qu’il fait : il tranche. Un bon couteau tranche bien. Un être humain bon agit bien. L’être est activité. L’être est devenir. C’est ce qu’il a voulu dire par actualité—non un état statique mais le déploiement continu du potentiel vers l’action. Une chose est ce qu’elle fait, encore et encore, au fil du temps.

Le Moyen Âge et la Renaissance ont enterré la philosophie du processus sous des couches de scolastique et de métaphore mécanique. Quand l’ère moderne est arrivée, nous avions hérité d’un monde divisé en objets discrets : des atomes, des corps, des esprits, des âmes, des faits. Nous nettoyons ce désordre depuis.

II. L’Inversion Moderne

Voilà la partie douloureuse : nous commettons l’erreur inverse aujourd’hui.

Nous nous sommes fixés sur l’objet. Le modèle d’IA. L’algorithme. L’outil. ChatGPT-4. Claude. Llama. Nous en parlons comme s’ils étaient ce qui importe—comme si l’intelligence elle-même était un objet que vous pouviez acheter, autoriser, affiner, brancher dans votre système. Nous en avons fait la Forme moderne : l’intelligence parfaite, abstraite et immuable quelque part dans le nuage.

Et nous manquons complètement le processus.

Quand vous utilisez réellement l’automatisation au travail—du vrai travail, pas du battage publicitaire—ce que vous faites, c’est externaliser une méthode. Vous prenez un flux de travail, vous l’examinez, vous le divisez en étapes, vous trouvez quelles étapes une machine peut gérer, lesquelles nécessitent un jugement humain, où l’information circule, où les décisions se prennent. Vous modélisez le processus. Puis vous le codifiez.

Mais nous n’en parlons pas de cette manière. Nous parlons de « déployer l’IA », comme si l’intelligence était portable et stable. Nous parlons de « remplacer les travailleurs », comme si le travail était une simple machine d’entrée-sortie. Nous manquons que l’automatisation est la philosophie du processus en action. Elle vous oblige à penser comme Socrate—à examiner ce que vous faites réellement, à trouver les règles non énoncées, à rendre visible l’invisible. Elle vous oblige à respecter le principe aristotélicien : l’essence du travail est la façon dont il s’écoule et se transforme au fil du temps.

III. Encoder la Méthode

Quand quelqu’un dit « tout le monde a besoin d’apprendre à programmer », ce qu’il dit réellement—s’il pense clairement—c’est que tout le monde doit penser comme un architecte de processus.

Non la syntaxe. Non les boucles, les variables et les motifs de conception orientés objet. Ce sont des outils ; ce n’est pas le but. Le but est : Pouvez-vous cartographier un flux de travail ? Pouvez-vous voir où une décision se produit par rapport à où une règle s’applique ? Pouvez-vous identifier la différence entre un appel de jugement humain et une étape mécanique ? Pouvez-vous modéliser comment l’information cascade à travers un système ?

Ce sont des questions anciennes vêtues de vêtements modernes. Socrate était un architecte de processus—il le faisait simplement par le dialogue. Il cartographiait les étapes implicites de la façon dont quelqu’un pensait. Il trouvait les contradictions. Il restructurait l’ensemble. Il automatisait la méthode en une forme répétable : poser les bonnes questions, écouter les réponses, trouver les lacunes.

Aristote était un penseur de systèmes. Il regardait les processus naturels—comment les organismes se développent, comment les villes se forment, comment les sociétés s’organisent—et trouvait les motifs sous-jacents. Fonction, potentiel, actualisation. Les parties et l’ensemble travaillant ensemble.

L’automatisation au sens moderne est le même exercice : externaliser le processus pour qu’il puisse être partagé, examiné, amélioré et délégué. Quand vous mettez en place un flux de travail—un pipeline, une liste de contrôle, un arbre de décision—vous faites ce que les Grecs faisaient quand ils passaient de la culture orale à l’écriture. Vous déplacez la connaissance en dehors du crâne, la rendez reproductible, la rendez collaborative.

L’objet (l’IA, l’outil) n’est que le médium. Ce qui importe, c’est le processus codifié en son sein.

IV. La Philosophie des Points de Remise

C’est ici que ça devient réel : l’automatisation révèle toujours quelque chose de douloureux sur notre manière de travailler.

Vous ne pouvez pas automatiser ce que vous ne comprenez pas complètement. Vous pensez comprendre votre travail, votre processus, la façon dont vous prenez des décisions. Puis vous essayez de l’expliquer à une machine—ou à un système, ou à un collègue—et vous réalisez qu’il vous manque des étapes. Vous faites des hypothèses. Vous sautez des choses qui semblaient trop évidentes pour mentionner, sauf qu’elles n’étaient pas du tout évidentes. Elles étaient enterrées.

C’est le moment socratique. C’est l’avantage.

Le point de remise—où une décision humaine rencontre un processus automatisé—est l’endroit où l’architecture devient visible. Dans une automatisation bien conçue, la machine gère le travail répétitif et déterministe : récupérez les données, formatez-les, vérifiez-les contre les règles connues, passez-les. L’humain prend l’appel de jugement : Est-ce intéressant ? Mérite-t-il l’attention ? La règle s’applique-t-elle dans ce cas particulier ? Que devrait-il se passer ensuite ?

La conception de ce point de remise est la philosophie du processus. C’est demander : Qu’est-ce qui peut être délégué ? Qu’est-ce qui demande une présence ? Qu’est-ce qui demande du jugement ? Où gagner en efficacité, et que perdons-nous si nous ne sommes pas prudents ?

Certains des meilleurs systèmes automatisés du monde—les flux de travail hospitaliers, les opérations aériennes, les systèmes de négociation financière—sont ceux où le point de remise entre l’humain et la machine est clairement pensé. Le processus est net. Les rôles sont clairs. Les points de jugement sont explicites.

Et certains des pires sont ceux où les entreprises ont tenté de remplacer la philosophie du processus par un objet : Nous avons acheté ce système d’IA ; nous l’exécutons simplement. Ils n’ont pas codifié la méthode. Ils n’ont pas modélisé le flux de travail. Ils espéraient simplement qu’un objet intelligent résoudrait des problèmes qui sont fondamentalement des problèmes de structure, non de capacité.

V. Pourquoi Automatisation, Pas IA

C’est pourquoi le mot importe. « IA » pointe vers l’objet. Cela suggère l’intelligence comme une marchandise transférable—quelque chose que vous avez ou n’avez pas, quelque chose que vous pouvez acheter et déployer. Cela aplatit le vrai travail, qui est la conception des processus.

« Automatisation » est honnête sur ce qui se passe réellement. Vous créez un système, un flux de travail, une méthode reproductible. Vous codifiez les connaissances qui étaient dans la tête de quelqu’un en règles qu’une machine (ou une équipe, ou un système) peut exécuter. Vous êtes un architecte de processus. Vous pensez comme les anciens le faisaient quand ils demandaient : Qu’est-ce qui est réel ? Que se passe-t-il réellement quand nous travaillons ? Comment le faire différemment, mieux, plus justement ?

La philosophie est que le travail lui-même peut être examiné, modélisé, amélioré, partagé. Non pas remplacé. Non pas optimisé jusqu’à l’oubli. Mais compris avec assez de clarté pour qu’il puisse être repensé—rendu plus humain, plus efficace, plus aligné avec ce qui importe vraiment.

Ce sont les Grecs en nous. C’est le travail que nous faisons quand nous automatisons tout ce qui vaut la peine d’être automatisé. L’objet n’est que le véhicule de la méthode.

Note sur l’histoire : Ceci est un argument philosophique, mais il a une histoire concrète. Des cartes perforées à travers Cobol, C, la révolution de la POO des années 80-90, et jusqu’aux architectures microservices et serverless d’aujourd’hui, le logiciel a oscillé entre ces pôles—Grady Booch et le Gang of Four ont fait de l’objet l’étoile ; maintenant les langages fonctionnels, les systèmes event-driven, et l’extraction de processus montrent que le pendule bascule. Cet arc de quatre-vingts ans mérite son propre article, à venir très bientôt.

Note sur le DDD : La tentative la plus claire du domaine logiciel pour corriger cette erreur est le Domain-Driven Design—le correctif d’Eric Evans en 2003 à l’ère de la POO, qui s’était enfoncée si profondément dans les patterns et les couches que le problème métier s’était trouvé enseveli sous la structure technique. Evans a dit : le domaine est le moteur, la technologie est le moyen. Contextes délimités, agrégats, langage ubiquitaire—tout cela sont des outils pour rendre le domaine lisible dans le code, non pour célébrer le code lui-même. Cela semble évident. Toute autre ingénierie—mécanique, électrique, civile—a toujours su que le problème physique conduit la conception, non le tour ni l’oscilloscope. Le logiciel a passé des décennies à croire qu’il était l’exception. Il ne l’était pas, et ne l’est pas. Un article dédié au DDD et à ce qu’il révèle sur la relation particulière du logiciel avec ses propres outils arrive bientôt.

Lectures Complémentaires