Article 1 sur 8 de la série consacrée à la refonte de l’usine de développement logiciel d’une banque à l’ère des agents.

Il y a 3 ans, j’ai publié ici un long guide sur la conception d’une usine de développement logiciel pour une banque. 9 chantiers, Team Topologies, les capacités Accelerate, les métriques DORA, une fonction IT-GOV détentrice du catalogue de contrôles, et un composite fictif appelé XYZ Financial Services pour porter l’étude de cas. On me pose encore des questions dessus, ce qui est soit bon signe, soit le signe que personne n’a écrit mieux depuis.

Je vais consacrer les huit prochains articles à reconstruire cette conception pour les agents de code. Avant cela, une chose doit être dite, et la plupart des textes sur le sujet refusent de la dire.

L’usine de 2023 fonctionne toujours.

Team Topologies explique toujours pourquoi l’équipe paiements de XYZ ne devrait pas avoir à ouvrir un ticket auprès de l’équipe risque pour livrer. Les capacités Accelerate prédisent toujours la performance de livraison mieux que n’importe quelle métrique d’adoption de l’IA publiée à ce jour. Le cycle de vie applicatif en douze étapes sous Azure DevOps, avec ses portes d’approbation entre test, recette et production, reste la raison pour laquelle la dernière inspection ICT de la BaFin a produit des observations plutôt que des constats. Rien de tout cela n’a été rendu obsolète par une sortie de modèle, et une organisation qui jette tout ça pour avoir l’air moderne passera les deux prochaines années à le reconstruire sous un autre nom.

Alors qu’est-ce qui a changé ?

Le plus intéressant n’est pas le code

La génération de code est la chose la moins intéressante dans cette bascule, et je dis ça en y passant l’essentiel de mes semaines.

Ce qui a changé, c’est que le travail de coordination qu’une structure d’usine existe pour accomplir peut désormais être fait par un système qui lit directement les artefacts de livraison. Savoir ce qui est en cours de construction, ce qui est bloqué, ce qui dépend de quoi, quel changement menace quel contrôle : tout cela exigeait jusqu’ici que des gens se résument mutuellement des artefacts en réunion, faute d’autre mécanisme.

Block a publié cette année un essai, « From Hierarchy to Intelligence », qui pose l’argument mieux que je ne saurais le faire. Leur thèse : la hiérarchie organisationnelle est un protocole de routage de l’information construit autour d’une seule contrainte humaine, l’éventail de subordination, et l’IA est la première technologie capable d’assurer elle-même la fonction de routage. Toutes les tentatives antérieures d’échapper à l’arbitrage, de la matrice aux squads Spotify jusqu’à l’holacratie, ont reculé ou n’ont pas passé l’échelle, parce que réduire l’éventail de subordination revient à ajouter des couches, et qu’ajouter des couches ralentit l’information. Il n’a jamais existé de routeur alternatif.

C’est une thèse sur le design organisationnel, pas sur la productivité des développeurs. C’est aussi celle sur laquelle une banque supervisée a le plus de mal à agir, et l’essentiel de cette série porte sur le pourquoi, et sur ce qu’il faut faire à la place.

Trois choses ont bougé chez XYZ. Je les prends une par une, parce que les remèdes ne sont pas les mêmes.

La connaissance que l’usine a d’elle-même quitte la tête des gens

En 2023, l’usine de XYZ se connaissait à trois endroits.

Des tableaux de bord alimentés par Jira et Azure DevOps portaient des agrégats retardés. Des documents FactSheet, maintenus par IT-GOV, portaient ce que chaque projet déclarait de lui-même au moment de la revue, ce qui n’est pas la même chose que ce qui était vrai. Et le modèle réel, celui que tout le monde utilisait effectivement pour décider, vivait dans la tête des team leads et des delivery managers.

Ce troisième endroit explique pourquoi toute décision non triviale exigeait une réunion. La réunion ne servait pas à décider. Elle servait à rassembler les personnes qui détenaient collectivement le tableau, pour qu’une décision devienne possible.

Un modèle du monde de la livraison disposant d’un accès en lecture aux dépôts, aux pipelines, aux boards, au registre des changements et des incidents et à la CMDB tient ce tableau en continu et répond à des questions dessus. La réunion de statut cesse d’être la façon dont l’organisation sait les choses. Au mieux elle devient la façon dont l’organisation décide, ce qui est une réunion beaucoup plus courte avec des participants différents.

Tout ce que Block écrit sur le management intermédiaire découle de ce seul déplacement, et j’y reviendrai dans le troisième article, y compris sur la partie qui entre en collision avec MaRisk et n’en sort pas intacte.

L’unité de travail passe du ticket à la spécification

En 2023, l’unité de travail d’ingénierie était une personne qui prenait une story. En 2026, l’unité est une spécification qu’une personne ou un agent exécute, et l’économie du truc s’est inversée en chemin.

Les agents produisent des diffs plus vite que les humains ne peuvent les relire. Le goulot remonte donc en amont, dans l’écriture d’une intention non ambiguë, et redescend en aval, dans la vérification des résultats. Le milieu, la frappe au clavier, c’est là que vit l’agent. J’ai comparé ici même les frameworks pilotés par la spécification en juillet, et le constat qui m’est resté est banal : il est plus facile de relire une page de spécification en markdown que 800 lignes de diff, et les équipes basculent de la revue de code à la revue de plan parce qu’un changement coûte peu dans une spécification et cher dans du code.

Il existe une troisième raison, qui compte davantage dans une banque, et c’est celle que je mettrais dans une note au comité. Une spécification qui vit dans git, qui relie exigences, tâches et commits, et qui survit à la session de chat, est un artefact qu’un auditeur peut parcourir de bout en bout. Un historique de prompts, non.

Le développement piloté par la spécification est arrivé sur le marché général comme une pratique qualité. Dans un établissement supervisé, il arrive comme une pratique de traçabilité. Cela change qui le sponsorise, donc cela change s’il est financé.

La contrainte passe de la capacité au contexte

C’est celle que je dois toujours expliquer deux fois.

En 2023, la contrainte de l’usine était la capacité d’ingénierie, et la roadmap était une négociation sur cette capacité rare. Pour une classe croissante de changements, ce n’est plus vrai. La contrainte, c’est le contexte : le système qui exécute le changement peut-il savoir ce que le code signifie, quelle règle métier il implémente, quelle obligation le module satisfait, et quelle preuve un changement doit produire.

La capacité, ça s’achète. Le contexte, non. Il faut le fabriquer.

Chez XYZ, l’essentiel se trouve aujourd’hui dans des spécifications Word de 2011, dans des comptes rendus SharePoint dont les points d’action ne pointent vers rien, et dans la mémoire de travail des trois ingénieurs qui comprennent le cœur comptable de portefeuille. Ce système est en production depuis 1997. Il valorise chaque position que la banque détient et alimente chaque reporting client qu’elle envoie. Les trois personnes qui savent pourquoi il arrondit comme il arrondit ont 58, 61 et 54 ans.

Je trouve ce fait plus intéressant que n’importe quel benchmark, parce qu’il a une horloge dessus.

L’asymétrie qui fait que copier Block est une erreur

C’est ici que l’essai cesse de se transposer, et il vaut mieux être précis sur le pourquoi plutôt que d’agiter le mot réglementation.

Block obtient son modèle du monde quasiment gratuitement. Ils sont remote-first et, comme l’essai le dit clairement, tout ce qu’ils font crée des artefacts : décisions, discussions, code, designs, plans, problèmes, avancement, le tout déjà enregistré et lisible par machine. La matière première existe à cause de leur façon de travailler.

XYZ est une banque privée européenne hybride où les décisions se prennent dans des salles, se consignent en prose, se classent par date et s’ancrent sémantiquement chez des collaborateurs à forte ancienneté. La décision d’architecture qui a déterminé comment le service d’entrée en relation traite le filtrage des personnes politiquement exposées a été prise un jeudi en comité de design, écrite dans un fichier Word, et rangée dans un dossier organisé par mois, sans aucun lien vers l’epic qu’elle gouverne ni vers le service qu’elle contraint. Environ la moitié des exigences non fonctionnelles de l’équipe risque n’existent que sous forme de souvenirs, ce qui explique qu’elles resurgissent en recette, à chaque fois, à la surprise générale, indéfiniment.

Pointez un modèle du monde vers XYZ aujourd’hui et il modélisera fidèlement les artefacts en ratant l’essentiel des décisions.

Avant que XYZ puisse avoir une couche d’intelligence digne de ce nom, il lui faut donc construire le prérequis dont Block a hérité. Je l’appelle le socle de preuve et il se place sous tout le reste de l’architecture : les décisions comme enregistrements structurés reliés au travail qu’elles gouvernent, les spécifications comme artefacts versionnés avec leurs deltas explicites, les exigences traçables des tâches aux commits jusqu’aux déploiements, le registre des obligations exprimé comme donnée plutôt que comme tableur maintenu par une personne à la conformité.

C’est le chantier que les transformations sautent. Il ressemble à de la documentation, et la documentation n’est jamais financée.

La façon de le faire financer, c’est de refuser de le décrire ainsi. Sans lui, les agents travaillent à l’aveugle, le modèle du monde modélise des artefacts au lieu de décisions, et la production de preuve reste un exercice manuel mené trois semaines avant chaque revue. Son business case s’écrit entièrement dans la monnaie des couches supérieures.

La question à laquelle je ne réponds pas encore

L’essai de Block se termine par une question posée à toutes les autres entreprises, et elle est bonne. Qu’est-ce que votre entreprise comprend qui soit réellement difficile à comprendre, et cette compréhension s’approfondit-elle chaque jour ? Si la réponse est rien, alors l’IA n’est pour vous qu’une histoire d’optimisation de coûts.

Leur réponse à eux, c’est le graphe économique : les deux côtés de millions de transactions, observés en temps réel.

La réponse de XYZ ne peut pas être celle-là, et faire semblant du contraire produit une mauvaise architecture, parce que cela oriente l’investissement vers des données clients que le principe de limitation des finalités n’autorisera de toute façon pas une usine logicielle à exploiter à cette fin. L’actif qui se capitalise dans une banque est différent, et l’identifier correctement détermine où va l’argent pendant deux ans.

Je donnerai ma réponse à la fin de la série et je la défendrai. Version courte : ce n’est pas le code, et ce ne sont pas non plus les données clients.

Ce que couvrent les sept prochains articles

La facture de tokens. Ce qui s’est passé chez XYZ quand la direction a demandé à tout le monde d’utiliser l’IA massivement, que l’adoption est allée exactement là où le message pointait, et que la facture de consommation est arrivée. La cellule de crise, l’instance de gouvernance, et ma thèse selon laquelle la dépense en tokens est un indicateur retardé de la qualité du contexte, ce qui implique que couper le budget ne règle rien.

Ce qui survit au contact d’un régulateur. Le modèle de Block démonté élément par élément et trié en trois catégories : se transpose tel quel, se transpose après chirurgie, ne se transpose pas. Chaque placement argumenté contre une exigence nommée. C’est l’article dont j’attends qu’on me le conteste, ce qui est précisément la raison de l’écrire.

Le socle de preuve et les deux modèles du monde. L’architecture cible complète, avec un schéma que vous pourriez confier à un designer.

Des équipes qui possèdent leur contexte, et les cérémonies qui meurent. Ce que devient Team Topologies quand les frontières se tracent autour de la propriété du contexte plutôt qu’autour de la bande passante de communication, plus un verdict sur chaque cérémonie Scrum et une fonctionnalité de routine tracée de bout en bout dans l’usine cible.

Le choix du harnais. Pourquoi je n’en retiendrais qu’un seul comme harnais principal, et pourquoi je défendrais ce choix sur des arguments de gouvernance plutôt que de qualité de code, comment les couloirs d’agents autonomes s’ouvrent un par un, et pourquoi un agent qui ne peut pas exécuter le code vaut beaucoup moins que ce que la démo laisse croire.

Des tests qui mentent, des incidents qui se resserrent, des contrôles qui s’exécutent. La distinction entre un test qui décrit ce que le code fait et un test qui décrit ce qu’il devrait faire, pourquoi les agents sont excellents sur le premier et dangereux sur le second, et ce que devient le catalogue de contrôles d’une banque quand l’acteur n’est plus une personne.

D’où viendront les seniors de 2032. Toutes les tâches sur lesquelles un développeur junior apprenait sont désormais du travail d’agent. Personne ne décidera d’arrêter de recruter des juniors. Cela se fera par report, un cycle budgétaire après l’autre, et la facture arrive six ans plus tard.

Prochain article : la facture de tokens, parce que c’est celui que la plupart des lecteurs sont en train de vivre.