💻 L'ordinateur portable, dernier goulot d'étranglement : des agents de codage aux flux de travail partagés

le 26 juillet 2026

Un seul agent de codage dans un terminal est gérable. On lui demande de modifier un fichier, on jette un coup d'œil aux différences, on exécute les tests dont on se souvient, et on passe à autre chose. La liste de vérification invisible tient toujours dans une seule tête.

Ensuite, vous ouvrez un deuxième agent. Puis un troisième. L'un travaille sur l'API. Un autre réécrit la documentation. Un troisième effectue un test de sécurité. Soudain, vous ne faites plus que programmer. Vous planifiez, vous vérifiez et vous vous souvenez. Cette exécution a-t-elle inclus une analyse statique ? Cette branche a-t-elle fait l'objet d'un contrôle de sécurité ? Que nous a appris l'échec d'hier que cette discussion a déjà oublié ?

Les agents ne sont pas nécessairement incompétents. Le processus qui les entoure reste personnel. Telle est la thèse de cet article, étayée par une petite expérience PHP : exposer une checklist de « revue des changements » d’ingénierie sous forme d’API HTTP avec Framework X comme environnement d’exécution asynchrone et Darkwood Flow comme couche d’orchestration.

L'idée technique centrale est simple :

Le framework X reçoit et exécute les requêtes. Le flux décrit et coordonne le travail déclenché par ces requêtes.

Ce ne sont pas des concurrents. Ils se situent à différents niveaux d'un même problème.

Le flux de travail caché

Le développement logiciel constitue déjà un flux de travail, même lorsque personne ne dessine les boîtes :

Change code
    ↓
Run tests
    ↓
Run static analysis
    ↓
Review security
    ↓
Update documentation
    ↓
Review result

Quand cette procédure n'est qu'une habitude – « Je lance toujours PHPUnit avant de pousser » – elle est fragile. Un vendredi matin fatigué, on oublie une étape. Un nouveau collègue ne l'a jamais apprise. Une conversation avec un agent, sortie de son contexte, est impossible à reconstituer.

L'étape manquante n'est pas une invite plus intelligente. Il s'agit de rendre le processus explicite : nommer les étapes, les entrées et les sorties, les modes d'échec et conserver une trace de ce qui a été réellement exécuté.

Pourquoi l'ordinateur portable devient le goulot d'étranglement

Dire que « l'ordinateur portable est le goulot d'étranglement » peut facilement être interprété à tort comme un problème matériel. L'argument intéressant est d'ordre organisationnel.

L'ordinateur portable renferme bien plus qu'un simple processeur. Il contient l'identité et les identifiants, l'accès aux référentiels, les invites et compétences privées, les scripts locaux, la configuration du modèle, l'historique des agents, les conventions du projet et les enseignements tirés des échecs de la semaine précédente. Il sert à la fois d'environnement d'exécution et de silo de connaissances.

Lorsque plusieurs agents travaillent en parallèle, tout ce qui compense leurs limites reste personnel :

• n'oubliez pas les tests, l'analyse statique, la sécurité, la documentation, la revue, les contraintes de déploiement ;
• souvenez-vous de ce que les courses précédentes ont appris ; — Conservez les secrets et les listes blanches sur une seule machine.

Cette solution n'est pas applicable à une équipe. Lorsque la personne (ou l'ordinateur portable) quitte l'entreprise, l'automatisation et sa mémoire disparaissent également.

Des commandes d'agent aux flux de travail

Le changement conceptuel s'opère à partir de :

Give one agent a large task

à:

Define a sequence of bounded steps

Chaque étape peut ensuite consister en du code PHP, une commande shell, un appel API, un agent de codage, un autre modèle, une validation humaine ou le déploiement d'un service. Dans l'expérience décrite ci-dessous, les étapes sont volontairement des services PHP locaux déterministes. L'important est la structure du processus, et non une simple démonstration de maîtrise en langage naturel.

Le flux de travail constitue la couche durable. Le modèle ou l'agent actuel est remplaçable.

L'expérience Framework X

Le prototype se trouve dans un petit projet, framework-x-flow. Ce n'est pas un produit. C'est un laboratoire pour une question : pouvons-nous transformer une liste de contrôle d'ingénierie privée en quelque chose de visible, inspectable et reproductible via HTTP, sans prétendre avoir construit une plateforme d'agent cloud ?

Architecture en un seul diagramme :

HTTP request
    ↓
Framework X route + middleware
    ↓
Flow workflow (jobs over Ip payloads)
    ↓
Steps (validate → analyse → quality → docs → review → retrospective)
    ↓
Trace + retrospective
    ↓
JSON response (+ atomic file under var/runs/)

Répartition des responsabilités, telle que mise en œuvre :

Comment fonctionne le Framework X (juste ce qu'il faut)

Framework X (clue/framework-x, actuellement 0.17.x) est un microframework basé sur ReactPHP. Une même App peut fonctionner comme un serveur HTTP CLI persistant ou derrière une API PHP traditionnelle.

Le choix du runner est compatible avec SAPI : en ligne de commande, HttpServerRunner établit une connexion socket (par défaut 127.0.0.1:8080, modifiable avec X_LISTEN) et exécute la boucle d'événements de ReactPHP ; derrière FPM ou Apache, SapiRunner traite une requête provenant des variables globales. Pour les tests et l'intégration, App::__invoke() traite une seule requête PSR-7 et attend la résolution des promesses.

Les gestionnaires peuvent renvoyer une réponse PSR-7 synchrone, une PromiseInterface ou un générateur de promesses. Sous PHP 8.1 et versions ultérieures en mode CLI, HttpServerRunner encapsule également chaque requête dans un FiberHandler, permettant ainsi à React\Async\await() de paraître synchrone sans perturber la compréhension du code. Les erreurs sont conçues pour être traitées comme des réponses HTTP et non pour interrompre le processus : ErrorHandler normalise les exceptions, les promesses rejetées et les types de retour invalides.

L'injection de dépendances est un petit Conteneur : configuration de tableau, fabriques, paramètres de type ENV, PSR-11 optionnel. Les contrôleurs de classe-chaîne sont résolus de manière paresseuse.

C’est pourquoi Framework X est important pour cet article : il permet d’exposer des flux de travail via HTTP et de maintenir un processus asynchrone actif. Il ne s’agit ni d’un planificateur, ni d’une file d’attente, ni d’un environnement d’exécution mutualisé, ni d’un moteur d’exécution d’agent.

Il présente également des imperfections qu'il convient de mentionner. Le gestionnaire d'erreurs par défaut intègre systématiquement la classe d'exception, le message et l'emplacement du fichier dans le corps des réponses 500 HTML ; il n'existe pas d'option pour passer du mode débogage au mode production. Le gestionnaire de routes conserve son propre chemin d'accès aux erreurs 404/405 HTML. Le package est encore en version 0.x. Un processus CLI de longue durée partage la mémoire entre les requêtes : les singletons mutables, les appels bloquants et les Loop::stop() imbriqués sont des pièges. Un environnement d'exécution asynchrone ne rend pas le PHP bloquant non bloquant ; sleep(), les clients HTTP synchrones et les opérations importantes sur le système de fichiers continuent de bloquer la boucle.

Comment Flow s'adapte

Darkwood Flow (darkwood/flow v8.1.1, PHP ≥ 8.5) est un pipeline de tâches basé sur des pilotes. Vous créez une chaîne avec FlowFactory::create(), y insérez des tâches sous forme de valeurs Ip et appelez await() jusqu'à ce que le flux soit vidé. Chaque tâche reçoit $ip->data et renvoie la valeur de données suivante. En cas d'échec, une exception Flow\Exception\RuntimeException est levée ; une tâche errorJob optionnelle est alors exécutée à chaque étape, et le pipeline s'interrompt à l'étape suivante.

Dans la démo, le flux de travail de révision des modifications est assemblé à peu près comme ceci (les fermetures encapsulent les objets d'étape invocables — Flow accepte Closure|JobInterface, et non des objets invocables nus) :

return (new FlowFactory($driver))->create(static function () use (…) {
    yield [static fn (ChangeReviewContext $ctx) => $validate($ctx), $errorJob];
    yield [static fn (ChangeReviewContext $ctx) => $analyse($ctx), $errorJob];
    // concurrent quality adapter, or sequential tests / static / security stages
    yield [static fn (ChangeReviewContext $ctx) => $docs($ctx), $errorJob];
    yield [static fn (ChangeReviewContext $ctx) => $final($ctx), $errorJob];
    yield [static fn (ChangeReviewContext $ctx) => $retro($ctx), $errorJob];
}, ['driver' => $driver]);

Étapes conceptuelles :

validate
    ↓
analyse
    ↓
tests | static-analysis | security-review
    ↓
documentation
    ↓
final-review
    ↓
retrospective

Surface HTTP (routes Framework X) :

$app->get('/health', HealthHandler::class);
$app->get('/workflows/change-review', DescribeWorkflowHandler::class);
$app->post('/workflows/change-review/runs', RunWorkflowHandler::class);
$app->get('/workflows/change-review/runs/{runId}', GetWorkflowRunHandler::class);
$app->get('/analysis/framework-x-flow', AnalysisHandler::class);
$app->get('/experiments/sequential-vs-concurrent', ExperimentHandler::class);

Ce que Flow fournit : chaînes de tâches, adresses IP, pilotes, stratégies telles que MaxIpStrategy et hooks errorJob.

Ajouts de la démo : représentation HTTP, identifiants d'exécution, suivi du temps d'exécution, persistance atomique JSON sous var/runs/, formatage rétrospectif, indicateurs d'échec contrôlés et, surtout, un EmbeddedReactDriver. La fonction native Flow\Driver\ReactDriver::await() appelle Loop::run() et Loop::stop(). Le HttpServerRunner du framework X gère déjà la boucle ; appeler la fonction native await() dans une requête arrêterait le serveur HTTP. Le pilote intégré conserve la sémantique asynchrone/de délai de React, mais résout une promesse sans interrompre la boucle partagée. Cet adaptateur fait partie du code du projet et n'est pas intégré à Flow.

Le mode qualité par défaut regroupe trois vérifications dans une seule tâche Flow via Promise::all de ReactPHP (ConcurrentQualityChecksStep). Il s'agit également d'un adaptateur. Le modèle de concurrence natif de Flow repose sur plusieurs IP au sein d'une même étape avec MaxIpStrategy, et non sur un DAG parallèle d'étapes enfants au sein d'une seule IP.

Exécution séquentielle versus simultanée

L'expérience en ligne de commande (php bin/experiment) compare trois adresses IP, chacune avec un délai de 0,05 s :

Ces durées sont données à titre indicatif et ne constituent pas une valeur scientifique. Elles correspondent à la forme attendue : trois retards successifs contre trois retards qui se chevauchent.

Une observation subtile : LinearIpStrategy seule provoque toujours des chevauchements entre les tâches asynchrones sous ReactDriver, car la boucle de récupération peut démarrer l'IP suivante pendant que la tâche précédente est en cours. Un véritable contrôle séquentiel est nécessaire avec MaxIpStrategy(1). C'est le genre de détail qui ne se révèle qu'après des mesures.

La concurrence n'est utile que lorsque les tâches sont indépendantes et non bloquantes. Encapsuler une tâche bloquante dans une promesse ne libère pas la boucle d'événements.

L'échec fait partie du flux de travail

L'orchestration ne se limite pas à l'ordonnancement des scénarios nominaux. La démonstration accepte les indicateurs d'erreur contrôlés dans le corps de la requête POST (exception, promise, async, security), rejette les JSON invalides avec un code 400 sécurisé et intègre les échecs d'étape dans un rapport d'exécution structuré.

Étant donné que les erreurs par défaut du Framework X sont au format HTML et détaillées, l'application utilise un JsonErrorHandler qui étend ErrorHandler. Cette sous-classe est importante : un middleware simple placé « en amont » reçoit toujours un ErrorHandler HTML standard, non modifié par l'initialisation de l'application. Le journal d'accès, lorsqu'il est présent, doit être immédiatement suivi d'une instance de ErrorHandler. Les clients voient des codes tels que internal_error ou invalid_json ; les détails sont consignés dans un fichier journal local.

Par exemple, un contrôle de sécurité ayant échoué a généré un rapport contenant :

{
  "code": "quality_check_failed",
  "message": "Security check failed: no dependency audit result was supplied."
}

et s'est poursuivi suffisamment loin pour qu'une rétrospective puisse proposer un changement concret de flux de travail — et non une simple trace de pile dans le navigateur.

L'étape rétrospective

La dernière tâche consiste à établir une rétrospective déterministe : étapes lentes, échecs de vérification, avertissements, enseignements et modifications suggérées du flux de travail. Concernant la faille de sécurité mentionnée ci-dessus, la proposition était la suivante :

{
  "target": "security-review",
  "reason": "The security check failed because no dependency audit result was supplied.",
  "proposal": "Add a dependency audit step before final review."
}

La note qui accompagne chaque rétrospective est intentionnelle :

Propositions uniquement — cette étape ne modifie pas le code de l'application ni les définitions de flux de travail.

Proposer une modification du flux de travail ne revient pas à le réécrire en catimini. Une amélioration continue et contrôlée est préférable à une modification incontrôlée. L'apprentissage automatique, la génération automatique de propositions et l'évolution autonome de l'automatisation de la production sont trois concepts distincts ; ce prototype ne met en œuvre que le concept intermédiaire.

Ce que signifie réellement la migration vers le cloud

Déployer le même script PHP sur un serveur ne constitue pas une collaboration. Une plateforme de gestion des flux de travail d'équipe nécessite une exécution partagée, un historique durable, la gestion des identités et des permissions, l'isolation des secrets, un environnement isolé (sandbox), une politique réseau, des quotas, l'auditabilité, le nettoyage et, souvent, des files d'attente ou une planification distribuée.

Les produits existants dans ce secteur – Upsun Dispatch, par exemple, s'inscrit dans le débat plus large sur l'exécution d'agents à distance – existent précisément parce que ces problèmes sont complexes. Mentionner ce contexte ne constitue en aucun cas une approbation d'un fournisseur. Pour Darkwood, l'objectif est plus précis : l'orchestration (explorée par Flow) et l'hébergement sécurisé d'agents mutualisés (que ce prototype ne propose pas) sont deux couches distinctes. Framework X et Flow ne fournissent actuellement aucun environnement d'exécution sécurisé ; affirmer le contraire serait faux.

Ce que ce prototype ne prouve pas

• Aucun environnement de test sécurisé dans le cloud, aucun courtier d'identifiants ni aucune liste blanche de commandes.
• Pas de planificateur distribué ni de file d'attente de messages durable.
• Pas d'isolation multi-locataires ni de gouvernance d'équipe automatique.
• Aucune modification autonome et sécurisée des flux de travail.
• Rien ne prouve que chaque tâche de codage doive devenir un flux de travail formel.
• Aucune preuve que Framework X soit le seul ou le meilleur environnement d'exécution pour ce modèle.
• Rien ne prouve que le simple fait d'encoder une liste de contrôle sur un ordinateur portable en fasse automatiquement un flux de travail d'équipe — le partage nécessite toujours un déploiement, un stockage partagé et un processus social.

Cela montre qu'un rapport d'exécution explicite est plus facile à examiner qu'une transcription de conversation privée, que les moteurs d'exécution asynchrones et les moteurs de flux de travail résolvent des problèmes différents, et que les adaptateurs honnêtes (EmbeddedReactDriver, qualité concurrente via Promise::all) sont meilleurs que d'inventer des fonctionnalités que les bibliothèques n'ont pas.

Conclusion

Les modèles vont évoluer. Les agents de codage vont évoluer. Les fournisseurs vont renommer les mêmes problèmes d'infrastructure.

Ce qui reste utile, c'est le processus qu'une équipe peut nommer, exécuter, inspecter, dans lequel elle peut échouer en toute sécurité et qu'elle peut améliorer intentionnellement : valider, analyser, vérifier la qualité, documenter, examiner, rétrospectivement – ​​encodé sous forme de données, et non sous forme de folklore sur un ordinateur portable.

Framework X peut être le point d'entrée de la requête. Flow peut être le graphe qui coordonne le travail. Aucun des deux ne remplace les aspects techniques de l'exécution d'un agent cloud. Ensemble, dans cette petite expérience, ils rendent la liste de contrôle visible.

L'artefact utile n'est plus l'invite de commande privée. C'est le flux de travail que vous pouvez exécuter à nouveau demain et dont vous pouvez discuter dans une demande de fusion.