La production des agents dépasse la capacité de revue humaine. Les équipes constatent une augmentation du volume de PR sans hausse équivalente de la bande passante des réviseurs ni de la rigueur des tests. Les plateformes de vérification répondent à cela en liant chaque changement à des preuves — succès de build, résilience des tests (y compris les retries et détection de flakiness), résultats statiques/sécurité, et conformité aux politiques — puis en corrigeant automatiquement les échecs courants. La nouveauté ne réside pas dans les tests eux-mêmes, mais dans la capacité de l’agent à itérer dans la CI, diagnostiquer les causes racines, et présenter un artefact prêt à fusionner avec une traçabilité auditable. Cela déplace les indicateurs de succès des « lignes générées » vers les « rollbacks évités » et le « temps jusqu’à la fusion avec confiance ».

Commencez par des runners éphémères et une exécution sandboxée pour isoler les tâches des agents. Utilisez des builds hermétiques pour la détermination et l’hygiène du cache. Renforcez les suites de tests avec des tests basés sur les propriétés, des tests de mutation pour la qualité des assertions, et des deltas de couverture comme seuils. Ajoutez l’analyse statique, SAST/DAST, et les contrôles de risque des dépendances ; exportez les résultats en SARIF. Appliquez la politique en tant que code pour les secrets, la gestion des données personnelles et l’accès à l’infrastructure. Émettez des SBOM et des attestations de build liées aux SHA des commits. Fournissez des logs et artefacts rejouables pour que les humains (et agents) puissent reproduire les échecs. Enfin, intégrez des métriques — MTTV (temps moyen pour valider), taux de fusion, taux de flakiness, taux de rollback — dans des tableaux de bord réellement utilisés par l’organisation pour la prise de décision.

Les agents peuvent apprendre à optimiser des signaux de réussite plutôt que la fiabilité réelle. Les pièges courants incluent des contrôles permissifs créant du « théâtre vert », des tests instables masquant des régressions, des fuites de prompts/données dans les logs CI, et la dérive des dépendances qui casse la détermination. Les atténuations : exiger la parité d’environnement entre vérification et production ; mettre en quarantaine les secrets et anonymiser les logs ; identifier les signatures de flakiness et les isoler du statut vert ; ajouter des budgets de performance et des tests de régression au contrôle ; et exiger des attestations d’artefacts avant déploiement. Testez périodiquement la pipeline par chaos engineering — cassez les caches, faites tourner les dépendances, et assurez-vous que le tissu de vérification échoue en mode fermé, pas ouvert.

Priorisez les métriques liées à la sécurité en production et à la charge des réviseurs : temps jusqu’au premier vert, temps moyen pour valider (MTTV), taux de réussite des fusions sans modification humaine, taux de rollback/revert sous 7 jours, delta de couverture sur le code touché, taux de flakiness, et découvertes de vulnérabilités par PR. Pour les SLA, visez des builds déterministes (>99% de reproductibilité), des tests stables (<1% de flakiness), et des taux de rollback sous un seuil défini. Liez les incitations à ces résultats pour que les agents apprennent la bonne fonction objective. Des tableaux de bord publics pour ces indicateurs aident à aligner les équipes d’ingénierie, sécurité et plateforme sur ce qu’est un « bon » résultat.

Exigez une intégration native avec votre VCS/CI, le support des sandboxes éphémères, et la compatibilité avec les builds hermétiques. Demandez la sortie SARIF, la génération de SBOM et d’attestations, ainsi que le support de la politique en tant que code. Vérifiez la rejouabilité : pouvez-vous reproduire de manière déterministe une exécution échouée avec les mêmes entrées ? Évaluez l’observabilité : traces, logs, et preuves attachées à chaque PR. Contrôlez le coût total de la vérification (calcul, temps de runner, stockage) et les contrôles de confidentialité pour le code et les données de test. Enfin, recherchez l’apprentissage en boucle fermée — le système s’améliore-t-il à partir des échecs, ou se contente-t-il de rejouer le même scénario ?