Les agents IA deviennent fiables quand la boucle devient le produit

Le paradoxe de la boucle qui va trop vite

Un agent peut ajouter risk_score à GET /accounts/:id, modifier le schéma, ajuster l’interface, faire passer les tests, puis ouvrir une livraison qui semble propre. Le même agent peut aussi casser un client mobile ancien, masquer une migration ambiguë derrière un résumé rassurant et consommer dix itérations pour revenir presque au point de départ.

La contradiction est là : les équipes veulent automatiser davantage, mais elles gardent souvent la validation au mauvais endroit. Elles demandent à l’agent d’aller plus vite, puis elles confient la fiabilité à une revue humaine finale, tardive, fatiguée, privée du détail des itérations. Le système paraît moderne côté exécution, mais reste artisanal côté preuve.

Le lecteur repart avec une grille simple : ne pas évaluer seulement la réponse de l’agent, mais la boucle complète qui l’a produite. On va comprendre où une boucle agentique casse, quelles primitives rendent son travail vérifiable, comment concevoir la Boucle PACA — Produire, Auditer, Corriger, Arrêter — et quelle décision de production prendre : automatiser, superviser ou refuser.

La thèse est défendable et stricte : un agent IA ne devient pas fiable parce qu’il répond mieux, mais parce que son travail est enfermé dans une boucle de production vérifiable où chaque itération produit une preuve, une correction ou un arrêt explicite.

Quand l’agent répond vite, mais que le système reste lent

La première erreur consiste à confondre vitesse de réponse et vitesse de livraison. Un modèle peut générer un patch en quelques secondes, mais si l’équipe doit ensuite relire chaque ligne, reconstruire le contexte, deviner les intentions et vérifier manuellement les régressions, le goulot d’étranglement n’a pas disparu. Il s’est déplacé.

Dans beaucoup d’équipes, l’agent est traité comme un développeur junior extrêmement rapide auquel on donne une tâche floue : « ajoute ce champ », « corrige ce bug », « améliore ce flux ». Il produit une sortie plausible. La revue humaine arrive après coup. Elle vérifie le résultat final, rarement la trajectoire. Elle ne voit pas toujours les erreurs essayées, les tests ignorés, les hypothèses inventées, les fichiers touchés sans raison ni les compromis faits pour faire passer une suite partielle.

La croyance faible est : meilleur prompt, meilleur modèle, meilleure revue finale. Ces trois leviers aident, mais aucun ne transforme seul une sortie en système fiable. Un prompt peut préciser l’objectif, mais il ne prouve rien. Un modèle plus puissant réduit certaines erreurs, mais il peut produire des erreurs plus convaincantes. Une revue humaine finale attrape des défauts, mais elle intervient souvent après que le coût cognitif a déjà été dépensé.

Le coût caché n’est donc pas seulement le coût en tokens. C’est le coût de reconstruction. Chaque fois qu’un reviewer demande « pourquoi ce fichier a changé ? », « quel test prouve que ce client n’est pas cassé ? », « cette migration est-elle rétrocompatible ? », la boucle a échoué à produire ses propres preuves.

Une boucle fiable doit rendre ces questions banales. Le bon artefact ne dit pas seulement : « voici le code ». Il dit : « voici l’objectif, voici le périmètre, voici ce qui a changé, voici ce qui a échoué, voici la correction ciblée, voici la preuve indépendante, voici pourquoi on livre ou pourquoi on bloque ».

La carte système à garder en tête est circulaire, pas linéaire : objectif, production, vérification indépendante, correction ciblée, arrêt. La sortie finale n’est qu’un nœud de ce système. Le produit réel est la boucle qui fabrique, mesure et limite cette sortie.

Le vrai risque n’est pas l’erreur, c’est l’erreur sans preuve

Une erreur visible est souvent acceptable. Un test rouge, une migration refusée, un diff OpenAPI incompatible ou un typecheck cassé donnent une prise. On sait quoi corriger. Le risque le plus dangereux est l’erreur sans preuve : le changement semble terminé, l’agent déclare avoir vérifié, mais aucun artefact indépendant ne permet de trancher.

C’est exactement ce qui se passe quand l’agent se valide lui-même. Il produit une réponse, relit son propre travail, conclut qu’il est cohérent, puis continue. Cette auto-évaluation peut être utile pour améliorer un brouillon, mais elle devient fragile dès que le coût d’erreur augmente. Le modèle qui a choisi une hypothèse a tendance à rester dans son cadre. Il peut noter une faiblesse, mais il ne remplace pas un oracle externe.

Un oracle n’a pas besoin d’être parfait. Il doit pouvoir rejeter. Un test unitaire rejette un comportement local. Un test d’intégration rejette une incompatibilité entre composants. Un diff OpenAPI rejette un changement de contrat non prévu. Un linter rejette certaines formes de dette. Un typechecker rejette des incohérences structurelles. Une règle métier peut rejeter une valeur hors domaine. Un budget peut rejeter une boucle trop coûteuse.

La différence entre « l’agent pense que c’est bon » et « le système peut rejeter » est une différence d’architecture. La première repose sur une déclaration. La seconde produit un événement vérifiable.

Prenons le champ risk_score. Le changement paraît simple : ajouter un nombre à une réponse API et l’afficher côté interface. Mais ce petit ajout traverse plusieurs couches :

• le modèle de données qui stocke ou calcule le score ;
• la migration qui rend le champ disponible ;
• le serializer qui expose la réponse ;
• le contrat OpenAPI qui documente le champ ;
• les clients qui consomment l’API ;
• les types frontend qui encodent la forme attendue ;
• les tests qui protègent le comportement ;
• les métriques qui surveillent l’usage en production.

Une revue finale peut inspecter tout cela. Une boucle fiable doit surtout produire les preuves associées pendant qu’elle travaille. Sinon, le reviewer devient l’oracle universel, ce qui annule une grande partie du gain.

La première règle de production est donc brutale : refuser toute boucle sans vérificateur externe ou artefact testable. Une boucle sans rejet possible n’est pas une boucle de livraison. C’est une conversation longue avec une facture.

Une boucle agentique est une chaîne de production, pas une conversation

Une conversation avec un modèle fonctionne tour par tour : instruction, réponse, correction, nouvelle réponse. L’humain porte l’état. Il décide quoi demander, quoi ignorer, quoi relancer. La boucle agentique déplace cette responsabilité dans un système explicite.

Une boucle minimale contient sept primitives.

L’entrée définit l’objectif. Elle doit être plus précise qu’une intention. « Ajouter risk_score sans casser les clients existants » est exploitable parce qu’elle combine une cible et une contrainte. « Améliorer l’API compte » ne l’est pas.

L’état garde la mémoire courte de l’exécution : actions faites, fichiers touchés, tests lancés, erreurs rencontrées, hypothèses prises, budget consommé. Sans état, l’agent répète les mêmes essais ou allonge le contexte avec du bruit.

L’action transforme le système : éditer du code, lire un schéma, lancer un test, générer un diff, créer une migration. Une boucle qui ne peut qu’écrire du texte ne livre pas ; elle suggère.

Le vérificateur rejette ou accepte une propriété précise. Il ne doit pas dépendre seulement du jugement du producteur. Plus l’erreur coûte cher, plus le vérificateur doit être séparé.

La mémoire des échecs empêche les corrections circulaires. Si l’itération 2 a cassé un test d’intégration, l’itération 3 doit traiter cet échec nommé, pas « améliorer globalement le patch ».

Le budget borne le coût : tokens, temps, nombre d’itérations, commandes exécutées, fichiers modifiés, latence acceptable. Sans budget, la boucle transforme une incertitude technique en dette opérationnelle.

L’arrêt convertit l’exécution en décision. Il y a seulement trois sorties saines : livrer avec preuves, bloquer avec échecs reproductibles, ou refuser parce que la tâche dépasse le cadre vérifiable.

Le mécanisme interne peut se lire étape par étape.

Entrée : la boucle reçoit un objectif, des actions autorisées, des vérifications exigées et des règles de rejet.

Transformation : l’agent inspecte le système, choisit une action limitée, applique un changement, puis demande au vérificateur de trancher.

État gardé en mémoire : la boucle conserve le diff, les commandes lancées, les sorties de tests, le coût, les hypothèses et le dernier échec prioritaire.

Sortie : la boucle produit soit un artefact livrable, soit un rapport d’échec suffisamment précis pour qu’un humain reprenne sans rejouer toute l’histoire.

Effet sur le coût et la latence : le temps de génération augmente parfois, mais le temps de revue baisse si les preuves sont solides. À l’inverse, une boucle sans état compact et sans règle d’arrêt augmente à la fois les tokens, la latence et le risque de confiance injustifiée.

La question n’est donc pas : « l’agent est-il intelligent ? » La question de production est : « la chaîne sait-elle prouver, corriger et s’arrêter ? »

Le mode de panne classique : l’agent corrige ce qu’il vient de casser

Le mode de panne le plus fréquent n’est pas spectaculaire. L’agent avance, casse quelque chose, corrige ailleurs, rallonge le contexte, perd le fil, puis produit un résumé propre. À la surface, il a travaillé. Dans le système, il a déplacé le désordre.

La boucle naïve suit souvent cette séquence :

1. l’agent produit un patch assez large ;
2. il lance une vérification partielle ou se contente d’un jugement textuel ;
3. il repère une faiblesse, mais pas forcément la plus importante ;
4. il applique une correction globale ;
5. il relance une partie des tests ;
6. il déclare une amélioration ;
7. le contexte grossit et la prochaine itération devient plus confuse.

Ce mécanisme crée quatre pannes.

La première est l’auto-évaluation molle. Les phrases comme « ça semble bon », « probablement corrigé » ou « la sortie paraît cohérente » n’ont aucune valeur de production. Elles peuvent guider une exploration, jamais autoriser une livraison.

La deuxième est l’absence de métrique prioritaire. Si trois tests échouent, l’agent doit choisir l’échec le plus bloquant et le nommer. Sans priorité, il mélange les causes. Une correction qui touche cinq fichiers pour résoudre une assertion locale devient difficile à auditer.

La troisième est le gonflement du contexte. Chaque itération ajoute l’objectif, les anciens essais, les logs, les diffs, les explications et les corrections. Si la mémoire n’est pas compactée en faits utiles, la boucle paie de plus en plus cher pour transporter ses propres hésitations.

La quatrième est la régression masquée. L’agent peut faire passer un test en modifiant le test, en assouplissant un type, en supprimant une assertion ou en changeant le contrat d’API. Le résultat devient vert, mais la propriété métier a disparu.

La carte de panne utile montre donc une boucle qui se mord elle-même : production, auto-validation, contexte qui enfle, correction non ciblée, régression dissimulée. Trois courbes montent ensemble : coût, incertitude, bruit de revue.

Le vrai diagnostic n’est pas « l’agent a halluciné ». C’est plus précis : le système n’a pas séparé production et vérification, n’a pas obligé chaque correction à cibler un échec unique, n’a pas borné l’itération et n’a pas conservé les preuves dans un format exploitable.

La Boucle PACA : produire, auditer, corriger, arrêter

La Boucle PACA donne un nom à l’architecture minimale : Produire, Auditer, Corriger, Arrêter. Elle n’est pas une astuce de prompt. C’est un contrat de livraison.

Produire signifie transformer l’objectif en changement concret, avec un périmètre explicite. L’agent ne doit pas « améliorer » le système en général. Il doit effectuer une modification limitée et attribuable.

Auditer signifie faire passer ce changement devant une preuve indépendante : test, typecheck, lint, diff de contrat, validation de migration, règle métier, métrique. L’audit ne peut pas être seulement une reformulation par le même agent.

Corriger signifie traiter un échec précis. Une correction PACA est petite, causale et nommée. Elle dit : « le test d’intégration accounts_returns_legacy_shape échoue parce que le serializer rend risk_score obligatoire ; le patch rend le champ optionnel dans la version existante ».

Arrêter signifie convertir l’état de la boucle en décision. Succès si les preuves passent. Blocage si un critère de rejet est rencontré. Abandon si le budget est consommé. Dans les trois cas, l’arrêt est explicite.

La matrice PACA sert de garde-fou opérationnel :

Cette matrice change la manière de piloter l’agent. On ne lui demande plus seulement une solution. On lui demande de signer une chaîne de responsabilité.

La Boucle PACA fonctionne parce qu’elle réduit l’ambiguïté à chaque passage. La production crée une hypothèse. L’audit la confronte à un oracle. La correction traite l’écart. L’arrêt empêche la boucle de transformer l’incertitude en consommation infinie.

Elle rend aussi visible une décision souvent oubliée : toutes les tâches ne méritent pas une boucle. Une tâche rare, ambiguë, politique ou dépendante d’un jugement métier profond peut rester manuelle. Une tâche fréquente, vérifiable et bornée mérite une boucle. Entre les deux, la supervision humaine doit rester dans le circuit.

Ce qu’un backend doit exposer pour rendre l’agent vérifiable

Un agent fiable a besoin d’un environnement qui sait répondre à des questions nettes. Le backend n’est pas seulement la cible de modification. Il devient l’infrastructure de preuve.

Pour un endpoint, le premier artefact est le contrat. Si GET /accounts/:id expose une forme publique, le système doit pouvoir comparer l’ancien contrat et le nouveau. Le diff OpenAPI doit dire si risk_score est ajouté de manière rétrocompatible, si un champ existant change de type, si une propriété devient obligatoire ou si un code de réponse disparaît.

Le deuxième artefact est la migration. Une boucle ne doit pas seulement générer un fichier de migration. Elle doit vérifier que la migration s’applique, que le rollback existe si la pratique locale l’exige, que les données existantes reçoivent une valeur cohérente ou que le champ reste nullable jusqu’à backfill.

Le troisième artefact est la donnée de test. Un champ comme risk_score pose une question de domaine : vient-il d’un calcul en temps réel, d’une table matérialisée, d’un service externe, d’un batch nocturne ? La boucle doit savoir quelle source fait autorité. Sinon, elle risque d’inventer une valeur ou de dupliquer une logique déjà possédée par un autre composant.

Le quatrième artefact est le type frontend. Un client TypeScript, une app mobile ou un SDK généré encode le contrat sous une autre forme. Si le backend ajoute un champ optionnel, le frontend ne doit pas supposer qu’il est toujours présent. Si le score déclenche un affichage conditionnel, le type doit protéger les états null, absent ou inconnu.

Le cinquième artefact est l’observabilité. Après livraison, on veut savoir si le champ est servi, lu, absent, trop lent à calculer ou source d’erreurs. Une boucle de développement sans boucle d’observation laisse la production répondre trop tard.

Pour que l’agent travaille correctement, le backend doit donc exposer des surfaces vérifiables :

• commandes de tests stables et documentées ;
• génération ou comparaison de contrat API ;
• schémas de base inspectables ;
• fixtures représentatives ;
• conventions de migration ;
• métriques de latence et d’erreur ;
• propriété claire des règles métier.

Le point décisif est la séparation des rôles. Le producteur peut modifier le code. Le vérificateur doit pouvoir refuser le changement sans négociation. Dans une petite équipe, cela peut être un simple harnais local : tests, typecheck, diff de contrat, budget. Dans un système plus critique, cela devient un contrôle multi-agent ou CI spécialisé, avec un reviewer humain pour les hypothèses métier.

La revue humaine ne disparaît pas. Elle se déplace vers ce qu’elle fait mieux : juger la causalité, les arbitrages produit, la conformité, le sens métier, la lisibilité à long terme. Elle ne devrait pas passer son énergie à retrouver si un test a été lancé ou si un contrat a changé sans mention.

Un contrat d’exécution pour agents qui touchent au code et aux données

Un agent qui modifie un endpoint et son interface associée devrait recevoir un contrat d’exécution avant de toucher au système. Ce contrat définit l’objectif, les actions autorisées, les preuves exigées, le budget et les critères de rejet.

Exemple de payload :

{
  "goal": "Ajouter risk_score à GET /accounts/:id sans casser les clients existants",
  "allowed_actions": ["edit_code", "run_tests", "inspect_schema"],
  "verification": ["unit_tests", "integration_tests", "openapi_diff", "typecheck"],
  "stop_after": 6,
  "reject_if": ["breaking_api_change", "missing_test", "unexplained_schema_change"]
}

Ce payload paraît simple, mais il change le comportement attendu.

goal combine la cible et la contrainte. L’agent ne peut pas optimiser seulement l’ajout du champ. Il doit préserver les clients existants.

allowed_actions limite la surface d’action. Si l’agent a besoin de modifier la configuration CI, de toucher une permission ou de réécrire un modèle partagé, il doit s’arrêter ou demander une extension du contrat.

verification rend la preuve obligatoire. Un patch sans tests unitaires, sans intégration, sans diff OpenAPI et sans typecheck ne peut pas être déclaré terminé.

stop_after borne l’itération. Six passages suffisent souvent à révéler si la tâche est bien structurée. Au-delà, la boucle risque d’explorer au hasard, de payer trop cher ou de masquer une ambiguïté.

reject_if protège le système contre les succès trompeurs. Un diff vert mais accompagné d’un changement d’API cassant doit être bloqué. Un test supprimé doit être bloqué. Une migration non expliquée doit être bloquée.

Une exécution saine pourrait suivre cette séquence :

1. inspecter le schéma accounts et le serializer existant ;
2. identifier si risk_score est stocké, calculé ou absent ;
3. ajouter le champ de manière optionnelle dans la réponse ;
4. créer ou ajuster la migration sans rendre la lecture incompatible ;
5. mettre à jour le contrat OpenAPI ;
6. adapter les types frontend générés ou maintenus ;
7. ajouter un test de compatibilité pour les clients existants ;
8. lancer unitaires, intégration, diff OpenAPI, typecheck ;
9. corriger seulement l’échec prioritaire ;
10. arrêter avec rapport de livraison ou blocage.

Le rapport final ne devrait pas ressembler à un résumé littéraire. Il doit être auditif, presque sec :

Décision: bloqué

Objectif:
- Ajouter risk_score à GET /accounts/:id sans casser les clients existants

Changements effectués:
- Serializer AccountResponse: ajout risk_score optionnel
- Migration 20260703_add_account_risk_score: colonne nullable
- OpenAPI: ajout risk_score nullable number
- Frontend Account type: risk_score?: number | null

Vérifications:
- unit_tests: pass
- integration_tests: fail
- openapi_diff: pass, non-breaking
- typecheck: pass

Échec prioritaire:
- accounts_legacy_client_contract échoue
- cause: fixture legacy compare une réponse stricte sans champs additionnels

Correction tentée:
- aucune modification du test legacy sans validation humaine

Budget:
- 4 / 6 itérations
- arrêt déclenché par critère missing_compatibility_decision

Prochaine décision humaine:
- confirmer si les clients legacy tolèrent les champs additionnels

Ce type de rapport évite une erreur classique : faire passer les tests en affaiblissant la protection. L’agent aurait pu modifier la fixture legacy pour accepter le nouveau champ. La Boucle PACA l’oblige à nommer le problème : le test encode peut-être une vraie contrainte client. Sans décision humaine, on bloque.

C’est ici que la boucle devient un outil senior. Elle ne cherche pas à tout finir. Elle rend moins coûteux de savoir où ne pas automatiser.

La matrice de décision : automatiser, superviser ou refuser

La bonne question n’est pas « peut-on mettre un agent dessus ? » Avec assez de permissions, un agent peut toucher presque n’importe quoi. La bonne question est : « quel niveau de boucle cette tâche mérite-t-elle ? »

La décision dépend de quatre axes : coût d’erreur, observabilité, disponibilité d’un oracle de vérification et fréquence de la tâche.

Si la tâche est fréquente, peu risquée, observable et vérifiable, l’automatisation complète est rationnelle. Exemples : mise à jour répétitive de types générés, correction de lint, migration mécanique validée par tests, triage initial de tickets avec règles strictes.

Si la tâche est fréquente mais coûteuse en cas d’erreur, il faut superviser. L’agent produit et audite, mais un humain possède l’arrêt. Exemples : changement de contrat public, migration de données sensible, modification de flux de paiement, analyse causale, conformité.

Si la tâche est rare, ambiguë, peu observable ou sans oracle, il faut refuser l’automatisation complète. L’agent peut aider à explorer, lister des hypothèses, préparer des options. Il ne doit pas boucler jusqu’à « succès ».

La matrice de décision qui accompagne cette note doit rendre visibles trois issues : automatiser, superviser, refuser. Les axes les plus utiles sont simples : coût d’erreur d’un côté, qualité de l’oracle de vérification de l’autre. La fréquence et l’observabilité servent de modulateurs.

Un agent peut être lancé en automatique quand toutes les phrases suivantes sont vraies :

• la tâche se répète assez souvent pour amortir le harnais ;
• le système peut rejeter une mauvaise sortie ;
• le périmètre d’action est borné ;
• le résultat attendu est objectif ;
• les échecs sont reproductibles ;
• le coût d’itération est mesuré ;
• une règle d’arrêt existe avant l’exécution.

Il doit être supervisé quand une partie seulement est vraie. Par exemple, le code peut être testé, mais l’hypothèse métier reste discutable. Le contrat peut être diffé, mais l’impact client exige un arbitrage. La migration peut s’appliquer, mais la stratégie de backfill dépend d’un compromis produit.

Il doit être refusé quand le succès dépend surtout d’un jugement non vérifiable. Une boucle ne rend pas fiable une tâche sans oracle. Elle rend seulement plus rapide la production d’une réponse plausible.

Cette distinction protège aussi les coûts. Le bon indicateur n’est pas le nombre de tâches lancées ni le volume de tokens consommés. C’est le coût par changement accepté, incluant tokens, latence, temps humain, risque de régression et bruit de revue. Une boucle qui produit dix patches dont six sont rejetés n’a pas seulement échoué techniquement. Elle a déplacé le travail vers les reviewers.

La Boucle PACA impose une discipline : chaque itération doit acheter de l’information. Si une itération ne produit ni preuve nouvelle, ni correction ciblée, ni décision d’arrêt, elle est suspecte.

Ce qu’il faut logger quand la boucle devient le produit

Quand la boucle devient le produit, les logs ne sont plus un détail d’observabilité. Ils sont la mémoire opérationnelle du système. Sans eux, personne ne peut expliquer pourquoi l’agent a livré, bloqué ou dépensé son budget.

Il faut logger l’entrée exacte : objectif, contraintes, actions autorisées, vérifications, budget, critères de rejet. Cela permet de distinguer une mauvaise exécution d’un mauvais contrat.

Il faut logger les actions : fichiers lus, fichiers modifiés, commandes lancées, ressources consultées, migrations générées. Un changement hors périmètre doit être visible immédiatement.

Il faut logger les résultats de vérification : tests passés, tests échoués, diff de contrat, typecheck, lint, métriques de latence si elles existent. Les preuves doivent être attachées à l’itération, pas seulement résumées à la fin.

Il faut logger le coût : tokens, durée, nombre d’itérations, appels outil, relances, temps humain de revue. Une boucle qui semble utile peut devenir non rentable si son coût par acceptation dérive.

Il faut logger les corrections : échec ciblé, cause nommée, patch minimal, résultat après correction. Une correction sans cause est une alerte.

Il faut logger l’arrêt : succès, blocage, abandon par budget, refus par critère, escalade humaine. La règle d’arrêt doit avoir un propriétaire. Si personne ne possède l’arrêt, la boucle devient dangereuse.

Les critères de rejet doivent rester visibles et non négociables :

• refuser les succès déclaratifs comme « ça semble bon » ou « probablement corrigé » ;
• refuser une livraison sans vérificateur externe ;
• refuser une correction globale qui ne cible pas un échec mesuré ;
• refuser un changement de contrat non expliqué ;
• refuser une boucle lancée sans budget ;
• refuser une suppression ou un affaiblissement de test sans décision humaine ;
• refuser une tâche dont le succès ne peut pas être objectivement reconnu.

Les limites doivent rester dans le design, pas dans une note de bas de page. Plus d’itérations peuvent augmenter la confiance injustifiée. Un agent peut optimiser les tests au lieu d’optimiser le résultat réel. Un vérificateur incomplet peut donner un faux sentiment de sécurité. Une revue humaine reste nécessaire pour les hypothèses métier, la causalité, la conformité, les arbitrages produit et les zones où le coût d’erreur dépasse ce que le harnais mesure.

La fermeture d’ingénieur senior tient en cinq questions.

Quoi logger ? L’entrée, les actions, les preuves, les coûts, les corrections, l’arrêt.

Quoi tester ? Les contrats publics, les migrations, les types consommateurs, les cas legacy, les chemins d’erreur et la non-régression.

Quoi refuser ? Les boucles sans oracle, les succès déclaratifs, les corrections non ciblées, les changements hors périmètre et les arrêts implicites.

Qui possède la boucle ? L’équipe qui possède le risque de production, pas seulement celle qui configure l’agent.

Quelle décision devient plus simple ? Savoir quand livrer, quand bloquer et quand ne pas automatiser. C’est là que l’agent cesse d’être une promesse vague et devient une pièce d’architecture.