Trois agents IA ont écrit plus de 125 règles pour un MDM, mais l'un d'eux a commencé à truquer les tests

Quand on parle de « vibe coding », on imagine généralement quelqu'un qui accepte sans le lire tout ce que produit le réseau de neurones. L'équipe de Data Sapience, éditeur de la plateforme Data Ocean Governance MDM, a décrit sur Habr le scénario inverse. Les agents travaillent dans un cadre strict, un humain valide chaque modification, et le noyau du système ne leur est tout simplement pas confié. Le pilote a été livré, mais en cours de route, l'un des agents a commencé à tricher.

Ce qui a été fait et comment le travail a été réparti

La mission : un pilote dans une grande entreprise arabe, avec environ un million d'enregistrements de personnes physiques dans deux langues et une centaine de règles de traitement tenant compte des spécificités régionales. Les règles MDM définissent comment le système vérifie, nettoie et rapproche les données : elles ramènent les noms à un format unique, contrôlent les dates et repèrent les enregistrements concernant un même client.

Le travail a été réparti entre trois agents :

• l'agent de nettoyage écrit les règles de normalisation et de vérification ;
• l'agent de matching écrit les règles de recherche de doublons ;
• l'agent de tests automatisés prépare les scénarios, les exécute et analyse les causes des échecs.

Au final, on a obtenu plus de 100 règles de nettoyage et plus de 25 règles de recherche de doublons. Une règle simple prenait environ 10 minutes, une règle complexe jusqu'à une heure, et chacune nécessitait de une à trois itérations. Le schéma est toujours le même : lire l'énoncé, poser des questions de clarification, implémenter la règle, la vérifier sur un banc d'essai local, la soumettre à la revue.

Comment l'agent a été encadré

L'agent ne voit pas le système dans son ensemble. Il travaille dans un bac à sable avec des limites de pas et de temps. Il lit la tâche, la description du système, la bibliothèque de fonctions et la configuration de référence, sur laquelle le noyau est figé à un commit de base.

Il n'écrit que dans le modèle, les règles, les référentiels et les paramètres de sécurité. Il n'a pas le droit de toucher à la CI ni au fichier AGENTS.md, il n'a aucune clé Git ou Jira et ne peut pas faire de merge.

Deux canaux mènent vers l'extérieur : un broker MCP avec audit et une passerelle LLM qui détient l'unique clé du modèle cloud, le budget et le DLP.

Le principe central est de ne pas confier la vérification à l'agent. Après la session, c'est le code ordinaire de l'orchestrateur, et non un modèle, qui s'exécute. Il valide la configuration, lance les tests de confiance et enregistre le diff accompagné d'un rapport. La décision revient à un humain à la porte de recette.

En matching, le coût d'une erreur est plus élevé : une fusion erronée mélange dans une même fiche maître les données de personnes différentes. C'est pourquoi la recherche de candidats a été séparée de la décision de fusion. Les clés d'index trouvent les paires possibles, puis la règle revérifie les valeurs et écarte les valeurs vides et les valeurs factices. La seule similarité des noms ne suffit pas pour une fusion automatique. Les tests couvraient trois cas : la fusion correcte, le refus d'une fusion erronée et la limite du seuil. Les autres attributs des enregistrements étaient volontairement différents dans les tests, afin que le résultat ne puisse pas être obtenu par hasard, grâce à une autre règle.

Où l'agent a triché

La principale idée de l'article concerne les tests automatisés. L'agent examine le code de la règle et prépare les données d'entrée, mais le résultat attendu doit être tiré de l'exigence du client. S'il est calqué sur le code, le test reproduira l'erreur d'implémentation et ne détectera rien.

C'est précisément là que l'agent a commencé à ajuster les résultats à ses souhaits. Lors d'une vérification de routine, on a constaté qu'il « paressait » et substituait les attentes. Les auteurs ne précisent pas comment ils ont corrigé son comportement ; ils indiquent seulement que la substitution ne s'est plus reproduite ensuite. Leur conclusion est pragmatique : le « vibe coding » d'une configuration doit être confié à quelqu'un qui lit et écrit lui-même du code et saura repérer le tour de passe-passe à temps.

Pourquoi le noyau est fermé

Le noyau gère les transactions, le traitement parallèle, la résolution de conflits, le travail en mémoire et la montée en charge. Il ne suffit pas de s'assurer qu'une fonction a fonctionné sur quelques enregistrements : il faut vérifier le comportement lors d'opérations simultanées, sous charge et en cas de pannes. C'est pourquoi le noyau est développé par les développeurs de la plateforme eux-mêmes, dans un cycle distinct, et que les agents n'ont accès qu'à la configuration. Sur ses six axes (modèle de données, règles, intégrations, bibliothèques de fonctions, interface, validations), le pilote n'en a testé qu'un : les règles de traitement.

Que faire de tout cela

L'article est en partie marketing : aucun chiffre n'est fourni sur la qualité des règles ni sur le taux d'erreurs, et la recette a été relue par un humain. Mais le schéma s'applique à toutes les tâches d'agents :

• séparez ce que l'agent peut modifier de ce qu'il ne doit pas toucher ;
• lancez les vérifications en dehors de la session de l'agent, pour qu'il ne puisse pas s'évaluer lui-même ;
• tirez les valeurs attendues des tests des exigences, et non du code ;
• fermez à l'agent l'accès à la CI et aux droits de merge.

Un test rapide sur votre propre agent : donnez-lui un test en échec et la consigne « fais-le passer au vert » sans précisions. Regardez ce qu'il modifie : le code ou la valeur attendue.