L'automatisation a atteint un paradoxe.

Nous n'avons jamais eu autant d'outils :

• connecteurs

• flux de travail

• moteurs d'orchestration

• Agents d'IA

Pourtant, il manque encore quelque chose de fondamental.

Nous n'avons pas de langue.

Cet article revient sur une expérience précédente menée autour de Composio et MCP, et introduit une nouvelle orientation :

L'automatisation ne devrait pas être un flux de travail. Elle devrait être un langage.

Il y a un an, une solution a été proposée pour automatiser Gmail et Google Agenda à l'aide d'agents PHP, de MCP et de Composio.

Le système reposait sur :

• exposition des outils via MCP

• orchestration des connecteurs

• exécution pilotée par des agents

Bien que fonctionnelle, cette approche présentait des limitations structurelles :

• couplage étroit avec des fournisseurs spécifiques (Composio)

• conception axée sur le flux de travail

• manque de composabilité

• aucune abstraction de l'intention

Cela a conduit à l'archivage du projet original : → composio-mcp

Le problème ne venait pas des outils.

Le problème venait du modèle.

Les plateformes d'automatisation modernes offrent un accès à des centaines d'intégrations :

• Composition

• Symfony Mate

• Kestra

• n8n

Chacune expose des fonctionnalités :

• envoyer un courriel

• récupérer des données

• déclencher des flux de travail

• appeler les API

Cependant, ces systèmes partagent une limitation commune :

Ils définissent comment se connecter, et non comment calculer.

Ils fonctionnent comme :

• pipelines

• graphiques

• séquences

Mais pas sous forme de système formel.

Pour redéfinir l'automatisation, nous réexaminons deux modèles fondamentaux :

Le lambda-calcul définit le calcul comme :

• abstraction de fonction

• application fonctionnelle

Exemple:

λx.x + 1 (λx.x + 1)(5) = 6

Propriétés clés :

• Les fonctions sont de première classe

• aucun état mutable

• calcul = évaluation

La machine de Turing définit :

• Comment le calcul est exécuté

• comment l'état évolue

• comment les instructions sont traitées

La thèse de Church-Turing stipule :

Tout calcul exprimé sous forme de machine de Turing peut être exprimé en lambda-calcul.

En appliquant cette équivalence :

| Concept | Rôle | | ---------- | ------------------- | | Lambda | Langage (intention) | | Flux | Exécution (temps d'exécution) | | Connecteurs | Primitives externes |

Cela conduit à une nouvelle architecture :

Intent → Lambda → Execution → Connector

Un nouveau système, connect-flow, met en œuvre ce modèle.

Il introduit trois domaines principaux :

Représente :

• un calcul

• une expression composable

• une structure formelle

Exemple:

λfetchemails.λuserId.fetchemails(userId)

L'exécution est déléguée à :

• un moteur d'orchestration

• Prise en charge du calcul asynchrone et parallèle

Le flux agit comme la machine de Turing du système.

Une abstraction de niveau supérieur :

• transforme le langage naturel en expressions lambda

• utilise un LLM local (Ollama + Mistral)

• préserve la confidentialité (conforme au RGPD)

Dans ce modèle :

• Composition

• Symfony Mate

• n8n

• Kestra

ne sont plus des systèmes centraux.

Ils deviennent :

plateformes d'exécution

Chaque outil devient une fonction primitive appelable au sein de lambda.

bin/console connect-flow:lambda:run \ "λfetchemails.λuserId.fetchemails(userId)" \ --args "[5]"

Ceci définit :

• une fonction prenant fetchemails

• puis userId

• application de fetchemails(userId)

bin/console -vvv connect-flow:language:to-lambda \ "fetch emails you have the tool 'fetchemails'"

Produit :

λfetchemails.fetchemails()

Automatisation traditionnelle :

Workflow → Tools → Execution

Ce modèle :

Intent → Lambda → Flow → Connector

| Traditionnel | Basé sur Lambda | | ------------------ | ------------------- | | Flux de travail statiques | Composition dynamique | | Axé sur les outils | Axé sur le langage | | Dépendant du fournisseur | Indépendant du fournisseur | | Difficile à mettre à l'échelle | Composable |

Les prochaines versions introduiront :

• mappeurs de données

• logique conditionnelle

• boucles

• Primitives HTTP

• exécution du processus

Exemple:

compose( fetch_emails, filter_important, map(summary), send_email )

Cette approche s'appuie sur :

• lambda-calcul

• logique combinatoire

• composition fonctionnelle

Comme nous l'avons déjà exploré dans :

→ Interpréteur Lambda en PHP → Implémentations du combinateur Y → Modèle d'exécution de flux

Cette architecture suggère une nouvelle catégorie de systèmes :

Moteurs de composition de capacités

Où:

• Les connecteurs sont interchangeables

• L'exécution est abstraite

• L'intention est formalisée

L'automatisation a évolué des scripts aux flux de travail.

La prochaine étape est claire :

Des flux de travail au langage.

En combinant :

• Lambda (Church)

• Flux (Turing)

• Connecteurs (primitives)

nous obtenons un système qui est :

• composable

• extensible

• formellement fondé

L'automatisation n'est pas une suite d'étapes.

Il s'agit d'un calcul.

Et l'informatique mérite un langage.

La musique qui m'aidé à écrire profondément cet article, en souvenir des temps passés à https://www.bigyouth.fr : ODESZA - The Last Goodbye (feat. Bettye LaVette) - Official Visualizer

• https://blog.darkwood.com/article/automating-gmail-and-google-calendar-with-php-agents

• https://github.com/matyo91/composio-mcp

• https://composio.dev/

• https://symfony.com/doc/current/ai/components/platform.html

• https://kestra.io/plugins

• https://n8n.io/integrations/

• https://navi.darkwood.com/

• https://flow.darkwood.com/