Architecte de banque : dans le test METR, l'IA a allongé de 19% le temps de travail de développeurs expérimentés

Le responsable de la fonction architecture d'une banque russe a publié sur Habr une analyse de la façon dont l'IA générative et les agents LLM transforment l'architecture d'entreprise. Son argument principal s'appuie sur un test randomisé de METR datant de 2025 (METR est une organisation indépendante qui évalue les capacités de l'IA) : des développeurs expérimentés qui travaillaient avec l'IA sur des bases de code matures ont passé 19% de temps en plus sur leurs tâches que sans elle. Ils étaient pourtant convaincus d'avoir accéléré de 20%, soit un écart de 39 points de pourcentage entre perception et réalité.

Selon l'auteur, cela montre que l'écriture de code n'a jamais été le goulot d'étranglement de l'entreprise. La vraie difficulté consiste à intégrer une nouvelle logique dans un paysage fait de legacy, de réglementation et de contraintes de sécurité de l'information.

L'illusion de l'accélération et le prix du code bon marché

Le réseau de neurones fait disparaître l'angoisse de la page blanche : le développeur obtient instantanément un morceau de code. Mais l'intégration commence ensuite. Le code généré paraît syntaxiquement impeccable, mais il ignore souvent les dépendances implicites des systèmes legacy et plante à l'exécution. L'ingénieur passe des heures à déboguer ce qui n'a que l'apparence d'un code fonctionnel.

Les données de GitClear le confirment indirectement : le volume de code copié a dépassé celui de code refactorisé, et le churn rate (part du code récent réécrit peu après son commit) est passé de 3,3% avant l'adoption massive de l'IA à 7,1%. Les rapports DORA dressent le même constat : le débit augmente, la stabilité des livraisons baisse.

La conclusion de l'auteur est pragmatique : on ne peut pas se reposer sur la revue de code faite par des humains. Il faut des capteurs déterministes dans le pipeline (fitness functions, linters et contrats) qui empêchent le code halluciné ou structurellement tordu d'arriver sur la branche principale. Les documents d'architecture cèdent la place aux guardrails-as-code.

Réglementation russe et modèle comme acteur

Les annonces occidentales de report d'échéances ne changent presque rien pour une banque russe. L'EU AI Act Omnibus a repoussé les exigences applicables aux systèmes à haut risque au 2 décembre 2027, et la Fed et la FDIC américaines ont, par le document SR 26-2, soustrait l'IA générative et agentique à la gestion standard du risque de modèle. En Russie, l'architecture dépend de la loi 187-ФЗ sur les infrastructures d'information critiques (КИИ), du règlement 850-П sur la résilience opérationnelle et de l'échéance de migration des objets significatifs de КИИ vers une pile nationale : le 1 janvier 2028.

Chaque décision passe par le filtre du registre des logiciels russes, de la catégorie de criticité des objets de КИИ et de la localisation des données personnelles au titre de la loi 152-ФЗ.

Le point 2.5 du document 3-МР de la Banque de Russie, publié en juin 2026, recommande que l'opération soit obligatoirement validée par un employé, avec la possibilité de la modifier. Cela concerne l'IA dans les processus critiques, comme les paiements présentant des risques élevés pour la sécurité de l'information. Le human-in-the-loop est donc devenu une couche obligatoire de la conception. Au-dessus des LLM, la banque met en place une abstraction de type routeur, afin qu'un changement de modèle imposé par la loi sur l'IA (243-ФЗ) ne paralyse pas l'activité.

La revue de conception commence par une question : le modèle est-il un composant ou un acteur ? S'il est enfermé dans une application et affiche sa réponse à l'écran, l'OWASP GenAI LLM Top 10 suffit. S'il dispose de mémoire, d'un accès aux API et d'appels de fonctions, c'est l'OWASP Agentic Top 10 qui s'applique, où le risque d'agentivité excessive (Excessive Agency) est monté à la troisième place. Pour ces agents, la banque construit des sandbox d'exécution de code, limite strictement les appels d'outils et ferme l'accès direct aux bases de données.

Un agent n'est pas un compte de service. Une clé API statique aux droits étendus ouvre la voie à une attaque de type confused-deputy : un prompt habile pousse un agent autorisé à exécuter une action malveillante avec les privilèges maximaux. C'est pourquoi chaque agent a sa propre identité, et ses droits sont délivrés sous forme de jetons de délégation à courte durée de vie, valables pour un appel précis. Les logs d'audit montrent où un humain a agi et où un agent a agi en son nom.

Le troisième risque est celui de l'IA « héritée » : par leurs mises à jour, les éditeurs de SaaS, d'ERP et d'ITSM activent des Copilot intégrés et modifient la cartographie des flux de données, ce qui touche au secret bancaire (art. 26 de la loi « Sur les banques et l'activité bancaire », art. 857 du Code civil de la Fédération de Russie). La politique de la banque est le default-off pour les fonctions d'IA externes : l'activation est assimilée à un changement majeur, et le suivi est tenu dans un registre distinct.

Documentation pour les machines, fin des ARB et nouveaux NFR

La documentation d'architecture (ADR, schémas C4, descriptions d'API) vit dans Git sous forme de Markdown, PlantUML et Structurizr. Les agents lisent mieux le texte brut d'un dépôt que les exports de systèmes propriétaires. Les fichiers de contexte RULES.md et ARCHITECTURE.md se trouvent donc dans le dépôt. Pour y donner accès, la banque a écrit une couche interne au-dessus des dépôts, avec prise en charge de MCP. Les comités ARB ont été dissous : c'est désormais un advice process qui s'applique, où la décision revient à l'architecte de solution du domaine, tandis que les périmètres réglementaires restent des contraintes obligatoires.

Les modèles d'ADR incluent désormais la frontière entre logique déterministe et sortie probabiliste, la topologie des flux de données à l'intérieur du périmètre de la banque, les déclencheurs de passage de relais à un humain et un exit path en cas de dégradation du fournisseur ou de changement de licence. Les exigences non fonctionnelles intègrent des métriques de comportement en cas de défaillance : un « refus correct » vaut mieux qu'une hallucination risquée. En FinOps, un plafond de coût en tokens est fixé pour chaque transaction métier, et la latence se mesure sur tout le cycle, y compris les appels de l'agent à des systèmes externes.

L'auteur laisse ouverte la question des métamodèles : ArchiMate ne peut pas décrire correctement un prompt, un seuil de validation ou une chaîne de délégation dynamique. Sa conclusion : un plan promet comment le système fonctionnera, alors qu'un composant probabiliste ne fait aucune promesse de ce type. Reste à le borner à l'avance, à l'intercepter au moment de l'action et à prouver après coup avec quels pouvoirs il a agi.