AUDIT DE TRAÇABILITÉ
Votre traduction arrive avec ses documents. Qui les a vérifiés ?
Quand une IA ou un intégrateur traduit du COBOL en Java, le code arrive avec des documents : d’où vient chaque morceau, à quoi correspond chaque champ, quels contrôles ont réussi. L’équipe qui révise, l’auditeur qui signe et la direction qui approuve la bascule s’y fient tous. Nous, on vérifie si ces documents disent vrai.
CE QU’ON VÉRIFIE
Chaque affirmation des documents, contre le vrai code.
Les sources citées
« Cette méthode vient de tel paragraphe COBOL. » Ce paragraphe existe-t-il dans le programme cité ?
La correspondance des données
« Ce champ Java est tel champ COBOL, de telle taille. » Les deux champs existent-ils, avec la taille annoncée et un type compatible ?
Les fiches de conformité
« Ce calcul est conforme à l’original : réussi. » Le calcul est-il vraiment dans le nouveau code ?
Ce sont des contrôles simples, pas une preuve : ils vous disent si les documents disent vrai. La preuve, elle, vous dit si le nouveau code fait la même chose.
CE QUE VOUS RECEVEZ
Chaque affirmation revient avec une de trois réponses.
Confirmée
Le code dit ce que le document dit. Le rapport indique le fichier et la ligne.
Ne tient pas
Le code dit autre chose : le paragraphe n’y est pas, le champ n’a pas la bonne taille, le calcul manque. Les deux, côte à côte.
Non vérifiable
Le document n’en dit pas assez pour le vérifier, ou le code qu’il cite n’a pas été livré. Toujours avec la raison, jamais compté comme réussi.
POUR QUI
Pour ceux qui signent sur des documents qu’ils n’ont pas écrits.
Les intégrateurs qui migrent du COBOL
Montrez à votre client que votre traçabilité tient, avec le rapport de quelqu’un qui n’a pas fait la traduction.
Les directeurs de migration des banques et assureurs
Approuvez la bascule sur des documents vérifiés, pas sur des documents qu’il faut croire sur parole.
L’audit interne et la conformité TI
Signez une traçabilité que vous pouvez vraiment contrôler : chaque affirmation, sa réponse, et où regarder.
COMMENT ON COMMENCE
Un module d’abord. L’application ensuite. Puis la preuve.
01
Un pilote sur un module
Un programme ou un module, avec sa traduction et ses documents. Le rapport revient en quelques jours.
02
L’application complète
Le même audit sur tous les programmes de l’application, à prix fixe par application.
03
Ensuite, la preuve de comportement
Une fois les documents vérifiés, on cherche où le nouveau code ne fait plus ce que faisait l’ancien. C’est un rapport à part.
CE QU’ON NOUS DIT
Bonnes questions.
« Nos tests suffisent. »
Vos tests vérifient le code. Nous, on vérifie ce que le fournisseur affirme sur le code. C’est pas la même chose.
« On fait confiance à notre fournisseur. »
Parfait. L’audit va le confirmer, et vous aurez une preuve écrite pour l’auditeur.
« On n’utilise pas l’IA pour traduire. »
Un intégrateur produit les mêmes documents. L’audit marche pareil.
Vous cherchez la preuve que le nouveau code fait la même chose ? Voir la vérification de code