Livraison agentique : de 530 à 3 jointures pour vérifier un accès

En bref

Contrôle	Résultat
Taille de la requête principale	530 → 3 jointures et 486 177 → 3 467 octets sur 264 identifiants synthétiques
Préservation du comportement	12 tests d’équivalence passent sur une base PostgreSQL embarquée
Sensibilité du test d’expiration	La mauvaise horloge passe avec l’ancien test. Avec le nouveau, elle renvoie 0 accès là où 1 doit subsister
Livraison	Correctif fusionné puis livré dans une version dont le contrôle navigateur de production a réussi

Une requête qui répète la règle pour chaque intervenant

L’application doit déterminer quels dossiers un intervenant peut encore consulter. La décision combine deux conditions qui expirent séparément. L’affectation au dossier doit être active au moment du contrôle métier. Pour certains accès, une autorisation supplémentaire doit aussi être valide à l’instant où elle est contrôlée.

L’ancienne implémentation construisait un prédicat par intervenant. Pour une liste de 264 identifiants, l’ORM répétait les filtres relationnels et leurs jointures dans la même instruction SQL. Le correctif garde la liste d’identifiants comme filtre, puis vérifie l’existence de l’autorisation pour l’affectation courante avec un EXISTS corrélé.

Pour comparer les deux versions, j’ai repris le même scénario synthétique avec le vrai client ORM et une base PostgreSQL embarquée. J’ai relevé les instructions exécutées et comparé leurs résultats. Le tableau donne la plus grosse instruction émise pour chaque parcours.

Les jointures comptées sont celles du texte SQL émis par le client. Les mesures portent sur la structure de la requête en local. La latence, la charge et les erreurs en production restent à mesurer.

Le test vert qui laissait passer la mauvaise horloge

J’ai ajouté une deuxième affectation. Elle reste active à l’instant du contrôle métier, mais son autorisation expire entre les deux lectures. Le résultat attendu contient encore cette affectation, car l’autorisation était valide au moment prévu pour son contrôle.

Pour le rejeu, j’ai volontairement remplacé l’horodatage du contrôle d’autorisation par celui du contrôle métier dans une copie isolée. Le test renforcé a détecté cette seule substitution. Le code a ensuite été restauré et le test relancé.

Ce que les agents ont fait et comment la livraison a avancé

Codex a préparé le correctif et les tests dans une copie isolée. Deux sous-agents ont travaillé sur l’équivalence et la relecture du prédicat. La relecture a soulevé le cas d’un identifiant vide. Le correctif le traite, avec un test qui compare le résultat à celui de l’implémentation d’origine.

J’ai autorisé séparément l’envoi de la branche et sa fusion. Sur la révision finale, les contrôles requis de CI, de changelog et de détection de secrets étaient verts. La revue automatisée restait consultative et son verdict agrégé était indisponible. Le premier déploiement de staging a échoué lors de la transmission de l’URL au pipeline. Une révision ultérieure, qui contient le même code pour la requête, a été déployée en production et a passé le contrôle navigateur.

Le harness de vérification de ce changement tient dans des preuves concrètes. Un scénario mesure la requête émise, d’autres comparent le comportement, puis une mutation vérifie que le test sait échouer. Pour transposer cette démarche à un dépôt d’équipe, voir l’offre Outillage et le guide des Agentic Software Factories.

À retenir

(Ce que vous savez maintenant)

• Une règle d’accès répétée par identifiant peut faire grossir une requête
• Un EXISTS corrélé permet d’évaluer le droit sur l’affectation courante
• L’équivalence se vérifie sur les cas visibles autant que sur les refus
• Une mutation volontaire vérifie qu’un test vert couvre bien la frontière d’expiration
• Le déploiement et la mesure des effets en production sont deux vérifications distinctes