Agent de revue de code

Une équipe de validation qui reprend un modèle écrit il y a six ans passe l’essentiel de son temps à comprendre le code avant de pouvoir l’évaluer. Le programme fonctionne, personne ne sait exactement pourquoi, et l’auteur a quitté l’entreprise.

L’agent fait ce premier travail. Il lit le code, reconstitue ce qu’il fait, signale ce qui pose problème et rédige la documentation qui manquait. La revue commence alors sur un terrain connu.

La revue. L’agent analyse un programme ou un dépôt, relève les écarts aux standards, les risques fonctionnels et la dette accumulée, puis propose des corrections. Chaque observation est classée, ce qui permet de traiter les dix qui comptent avant les trois cents qui attendront.

La rétro-documentation. L’agent produit la documentation d’un code qui n’en a jamais eu : ce que fait chaque bloc, quelles données il consomme, quelles hypothèses il pose, ce qu’il produit. C’est souvent la demande la plus urgente, et la moins bien servie par les outils du marché.

Les deux premiers langages sont largement outillés. Le troisième l’est beaucoup moins, alors qu’il fait tourner une part considérable des chaînes actuarielles, des moteurs de scoring et des calculs réglementaires dans les banques et les assurances.

Ce code SAS a souvent quinze ans, il n’est pas versionné, sa documentation tient dans des commentaires épars, et les équipes qui l’ont écrit ont changé deux fois. C’est précisément là que l’agent rapporte le plus.

• Les écarts aux standards : nommage, structure, absence de commentaires, conventions internes non respectées.
• Les risques fonctionnels : divisions par zéro non traitées, valeurs manquantes absorbées silencieusement, jointures qui dupliquent des lignes sans que personne ne s’en aperçoive.
• Les écarts de reproductibilité : chemins de fichiers en dur, graines aléatoires non fixées, dépendances non versionnées. Un calcul qui ne se rejoue pas à l’identique est un calcul que vous ne pourrez pas défendre.
• La dette technique : code mort, duplication, fonctions dépassant plusieurs centaines de lignes, bibliothèques obsolètes.
• Les écarts de performance : boucles sur des volumes qui appellent une opération vectorisée, lectures répétées d’un même fichier.

• Le code, par dépôt ou par archive. Sans historique de versions si vous n’en avez pas, ce qui est le cas courant sur les programmes anciens.
• Vos standards internes, s’ils existent. Sinon l’agent applique les conventions du langage et vous proposez vos ajustements.
• Le contexte fonctionnel, même sommaire : à quoi sert ce programme et qui consomme sa sortie.
• Les contraintes de confidentialité, pour déterminer si le code peut sortir de votre infrastructure ou si l’agent doit s’y exécuter.

• Le rapport de revue, avec les observations classées par gravité et par effort de correction.
• Les corrections proposées, sous forme de code, prêtes à relire et à appliquer.
• La documentation reconstituée : description des traitements, des entrées, des hypothèses et des sorties.
• La trace de la revue : ce qui a été examiné, par quel moyen, et ce qui a été retenu ou écarté par le relecteur.

Rien ne s’applique automatiquement. L’agent propose, un développeur ou un valideur tranche, et sa décision est consignée. Sur du code qui porte un calcul réglementaire, cette traçabilité n’est pas une précaution de confort.

Quand le code implémente un modèle de risque de crédit, un calcul de provisionnement ou un moteur de tarification, la revue ne porte plus seulement sur la qualité du code. Elle porte sur la capacité à démontrer que le calcul fait ce que la documentation prétend.

Les équipes de validation indépendante et de gestion du risque de modèle attendent trois choses que cet agent produit : une description fidèle de ce que le code exécute, la liste des écarts entre le code et la spécification, et la preuve que le calcul se rejoue à l’identique.

C’est le prolongement naturel de ce que nous opérons en modélisation prédictive, sur les cadres bâlois, IFRS 9 et Solvabilité II.

• Le rapport de trois mille observations. Personne ne le lit. Sans classement par gravité et sans seuil, l’outil produit du bruit et l’équipe retourne à ses habitudes.
• La règle métier prise pour une erreur. Un filtre bizarre sur une population précise correspond neuf fois sur dix à une décision métier ancienne et parfaitement justifiée. L’agent la signale, il ne la corrige pas.
• La correction appliquée sans relecture. Un code qui fonctionnait et qu’on a nettoyé sans le comprendre produit des écarts que personne ne saura expliquer au moment du contrôle.
• L’absence de suite. Une revue livrée sans propriétaire ni échéance rejoint la pile des audits précédents.

Nous reparamétrons l’agent sur vos standards, vos langages et vos contraintes de confidentialité, y compris pour une exécution entièrement sur votre infrastructure. Comptez deux à quatre semaines entre le premier dépôt et un rapport exploitable.

À la livraison, vous détenez le code source, la documentation et le protocole d’évaluation. Le détail de notre méthode figure sur la page agents IA sur mesure.

• Agent d’exploration de données : même démarche appliquée aux données plutôt qu’au code, quand il faut comprendre un patrimoine hérité.
• Agent de détection d’anomalies : surveille en production ce que la revue a permis de fiabiliser.
• Agent de prédiction des besoins : illustre le type de modèle dont le code passe ensuite en revue.

Dites-nous quel programme vous n’osez plus toucher et depuis combien de temps. Nous vous dirons ce qu’une revue peut en tirer, et en combien de temps.