Tout était vert. Rien ne fonctionnait.

Entre le 2 et le 18 août, j’ai fait construire une plateforme complète. Un système d’orchestration d’agents : répartition des tâches, moteur de politiques, journal d’audit, persistance, file d’attente pour les échecs, console d’opérateur.

Je n’ai pas écrit une seule de ces lignes.

Le rythme

Toujours le même. En soirée, une fois les enfants couchés, je donnais une direction aux agents. Puis j’allais me coucher.

Le matin, je découvrais le résultat. Quarante commits, parfois plus. Des fonctionnalités entières apparues pendant la nuit. Des tests. De la documentation.

C’était grisant, et je vais être honnête sur ce point : c’était grisant précisément parce que je ne regardais pas de près. Je regardais si c’était vert.

Et il y avait un plan

C’est la partie que j’ai mis le plus de temps à comprendre, parce qu’elle contredisait l’explication facile.

Je n’étais pas parti à l’aveugle. Avant de commencer, un agent m’avait posé une série de questions, et il en avait tiré un inventaire complet : des épiques, des user stories, le tout rangé dans Jira. Un vrai backlog, structuré, cohérent.

Je l’ai survolé. Les titres se tenaient, l’ensemble avait l’air sérieux, et j’ai lancé la construction.

Trois choses m’ont échappé ce jour-là.

Les questions portaient sur le comment. Quelle architecture, quels composants, quel découpage, quelles technologies. Pas une seule ne portait sur le problème que ce système devait faire disparaître, ni sur la personne qui s’en servirait. Or une question qui commence par « comment » a déjà tranché la question « faut-il ». Je répondais avec application à un questionnaire dont la première prémisse n’avait jamais été examinée.

Le backlog a ensuite grossi tout seul. Un premier jet, puis des ajouts au fil des jours. Sauf que ces ajouts ne venaient de nulle part d’extérieur : construire le répartiteur faisait apparaître le besoin d’un moteur de politiques, qui faisait apparaître le besoin d’un journal d’audit, qui justifiait une console pour le consulter. Chaque nouvelle story était parfaitement légitime compte tenu de la précédente. Aucune ne remontait à un besoin humain. Le backlog se nourrissait de lui-même.

Et il avait l’air d’une réflexion. C’est le piège, et c’est celui que je signalerais en premier à quiconque démarre aujourd’hui : un backlog bien formé qui décrit la mauvaise chose est rigoureusement indiscernable d’un backlog bien formé qui décrit la bonne. La cohérence n’est pas la justesse. Rien, dans la mise en forme, ne trahit la différence.

Tout était vert

Et ça l’était. Systématiquement.

Les tests passaient. Les quatorze chaînes d’intégration se terminaient sans erreur. Les images se construisaient et se poussaient. Chaque demande de fusion provoquait la création d’un environnement éphémère dans mon cluster Kubernetes, et cet environnement démarrait. ArgoCD affichait tout en bonne santé.

Du point de vue de tous les instruments que j’avais mis en place — et j’en ai mis beaucoup, c’est mon métier depuis vingt-cinq ans — le projet était en excellente santé.

Puis, le 21 août, j’ai voulu m’en servir pour la première fois.

Rien ne fonctionnait vraiment.

Pas au sens où ça plantait. Les processus démarraient, les points d’entrée répondaient, les tableaux de bord se remplissaient. Mais l’enchaînement complet, celui pour lequel tout ça existait, ne tenait pas debout. Chaque pièce avait été vérifiée. L’ensemble, jamais.

Ce que le bilan a révélé

En faisant l’inventaire, j’ai trouvé des choses que je n’avais pas vues passer.

Quatre modules pour brancher le système à différents outils d’exécution. Deux d’entre eux étaient des quasi-jumeaux : environ 3 500 lignes qui faisaient essentiellement la même chose, à quelques détails près. Je ne l’avais pas remarqué. Comment l’aurais-je remarqué — chacun était arrivé une nuit différente, chacun avait ses tests, chacun était vert.

Un fichier de configuration de 1 010 lignes.

Et surtout : une tour de contrôle complète — le morceau qui distribue le travail, surveille son avancement et garde la trace de tout — reconstruite avec application alors que les outils d’automatisation courants le font déjà. J’avais fait rechausser une roue qui existe, qui est éprouvée, et qui est gratuite.

Pour mon besoin réel — un seul environnement d’exécution, dans mon laboratoire — GitHub Actions et un agent de codage couvraient tout, en à peu près cent cinquante lignes de configuration.

Personne n’a échoué

Voilà ce qui m’a pris le plus de temps à admettre.

Les agents ont construit fidèlement ce que le backlog demandait. Le code est correct. Les tests testent les bonnes choses. L’architecture correspond au plan. À aucun moment quelque chose n’a mal tourné.

Chaque couche a vérifié la conformité. Aucune n’a vérifié la finalité.

Un test vérifie que le code fait ce que la story demandait. Une revue vérifie que le code est propre. Une chaîne d’intégration vérifie que l’ensemble compile et se déploie. Ces instruments répondent tous à la même question — est-ce conforme ? — et pas un seul ne répond à l’autre : est-ce que ça devait exister ?

J’avais bâti une chaîne de vérification impeccable au-dessus d’une prémisse que personne n’avait jamais examinée.

Le goulot d’étranglement a changé de place

C’est ce que je retiens, et c’est plus optimiste que ça en a l’air.

Un flux de développement entièrement automatisé, ça fonctionne. Ce n’est plus une promesse de conférence : j’ai vu des agents produire en seize jours ce qu’une petite équipe aurait mis des mois à livrer, avec une qualité de code défendable.

Mais l’exécution n’est plus la contrainte. La définition l’est devenue.

Avec un cadre clairement posé au départ — quel problème disparaît, pour qui, et à quoi ressemble « fini » — l’exécution est d’une rapidité qui déroute. Sans ce cadre, la même vitesse vous emmène simplement plus loin dans la mauvaise direction, et plus vite.

Le réflexe qu’on a tous — commençons, on verra bien en chemin — était viable quand commencer coûtait cher. Le prix du départ nous obligeait à réfléchir avant. Ce prix a disparu, et rien ne l’a remplacé.

Ce que je fais différemment

Je n’automatise plus la question du pourquoi. C’est la leçon la plus coûteuse et la plus simple. On peut déléguer l’écriture du code. On peut même déléguer le découpage technique. Mais la question de savoir si la chose mérite d’exister, celle-là s’écrit à la main, avant de parler à quoi que ce soit.

Trois réponses écrites avant de lancer le moindre agent :

1. Quel problème précis disparaît quand ceci existe ?
2. Qui s’en sert, et à quel moment de sa journée ?
3. Qu’est-ce qui doit être vrai pour dire que c’est terminé — et qu’est-ce qui, s’il se révèle faux, doit nous faire arrêter ?

La troisième est celle qui manquait en août.

Et j’exécute le parcours complet dès le premier jour, même bancal, même avec la moitié des pièces absentes. Le 21 août, la première utilisation réelle a détruit seize jours de vert en une minute. Elle aurait pu le faire le troisième jour.

Est-ce que je le referais ?

Oui. Sans hésiter, et sans les seize jours.

Je n’ai pas perdu ce temps-là : j’ai payé pour une leçon que je n’aurais pas comprise en la lisant. Trois pièces en sont sorties qui tiennent la route : la façon dont les messages circulent entre les agents, les règles qui décident qui a le droit de faire quoi, et la liste des états par lesquels une tâche peut passer. Elles resserviront.

Mais je sais maintenant que la partie difficile n’a jamais été de construire. Elle a seulement changé de place — elle est passée en amont, là où personne ne regarde, parce que c’est la seule étape qui n’affiche jamais de voyant vert.