Guide pratique · Audit COBOL
Checklist d’audit COBOL : 25 points à contrôler avant de décider
Cette grille aide à rendre visibles les risques fonctionnels, techniques et humains d’une application COBOL avant de choisir entre maintien, modernisation ou migration.
Mode d’emploi
Un audit COBOL doit dépasser la simple revue de code
Le code n’est qu’une partie du système. Un diagnostic utile examine aussi les règles métier, les données, les flux, la production, les procédures de changement et la disponibilité des compétences. Utilisez les 25 contrôles ci-dessous pour préparer vos entretiens, identifier les zones inconnues et prioriser les analyses.
1. Valeur métier et périmètre
Comprendre ce que l’application doit absolument préserver
- Inventaire des applications et composantsDisposez-vous d’une liste fiable des programmes, traitements, bases, fichiers, interfaces et outils associés ?
- Propriétaires métier et techniquesChaque domaine possède-t-il un responsable capable de valider les règles, les priorités et les impacts ?
- Niveau de criticitéLes conséquences d’une indisponibilité, d’une erreur de calcul ou d’un retard de traitement sont-elles formalisées ?
- Règles métier sensiblesLes calculs, exceptions, contrôles réglementaires et décisions spécifiques sont-ils identifiés et explicables ?
- Cycles et saisonnalitéLes clôtures, pics d’activité, échéances réglementaires et traitements exceptionnels sont-ils connus ?
2. Code et architecture
Mesurer la maintenabilité du patrimoine COBOL
- Structure et dépendances du codeLes appels, copies, bibliothèques, transactions, jobs et dépendances entre programmes peuvent-ils être cartographiés ?
- Code mort et doublonsLes composants inutilisés, variantes anciennes et règles dupliquées sont-ils distingués du périmètre réellement actif ?
- Accès aux donnéesLes usages de DB2, VSAM, fichiers séquentiels ou autres stockages sont-ils documentés et cohérents ?
- Gestion des erreursLes codes retour, rejets, reprises et traitements des anomalies sont-ils homogènes et exploitables ?
- Filet de testsExiste-t-il des cas de référence permettant de comparer les résultats avant et après une modification ?
3. Données et interfaces
Identifier les dépendances que le code ne montre pas toujours
- Cartographie des flux entrants et sortantsLes fichiers, messages, APIs, écrans, échanges partenaires et traitements indirects sont-ils inventoriés ?
- Contrats de donnéesLes formats, longueurs, encodages, valeurs autorisées et règles de transformation sont-ils explicites ?
- Qualité des donnéesLes doublons, valeurs manquantes, incohérences historiques et corrections manuelles sont-ils mesurés ?
- Référentiels et sources de véritéSavez-vous quelle application fait autorité pour chaque information partagée ?
- Conservation et sécuritéLes exigences d’archivage, de confidentialité, de traçabilité et de suppression sont-elles appliquées ?
4. Production et performance
Vérifier la capacité à exploiter et à restaurer le service
- Chaîne batch et ordonnancementLes dépendances entre jobs, fenêtres, calendriers, reprises et contrôles de fin sont-ils maîtrisés ?
- Engagements de serviceLes objectifs de disponibilité, de temps de réponse et de fin de batch sont-ils définis et suivis ?
- Historique des incidentsLes causes, contournements, récurrences et temps de résolution peuvent-ils être analysés ?
- Capacité et performanceLes volumes, temps CPU, accès aux données et goulets d’étranglement sont-ils mesurés dans le temps ?
- Retour arrière et repriseLes procédures de restauration, rejeu, correction de données et reprise après incident sont-elles testées ?
5. Organisation et compétences
Évaluer la dépendance aux personnes et aux pratiques implicites
- Cartographie des compétencesQui connaît le code, les règles métier, la production, les données et les procédures exceptionnelles ?
- Documentation réellement utiliséeLa documentation est-elle à jour, accessible et suffisamment concrète pour traiter une demande ou un incident ?
- Processus de changementLes demandes, analyses d’impact, validations, recettes et autorisations de mise en production sont-elles traçables ?
- Transfert de connaissancesLes revues croisées, binômes, supports de formation et exercices de reprise sont-ils organisés ?
- Plan en cas de départUne autre personne peut-elle diagnostiquer un incident critique et livrer une correction sans dépendre d’un unique sachant ?
Priorisation
Transformer les constats en décisions
Tous les écarts ne justifient pas le même niveau d’urgence. Croisez chaque point avec la criticité métier et la probabilité de défaillance.
Les preuves existent, un propriétaire est identifié et le contrôle est régulièrement vérifié.
L’information existe mais reste incomplète, ancienne ou concentrée chez une seule personne.
Le périmètre, la règle ou la procédure ne peut pas être démontré. Une action de sécurisation est nécessaire.
Questions fréquentes
Préparer un audit COBOL exploitable
Combien de temps faut-il prévoir ?
La durée dépend du périmètre, de la documentation et du nombre d’interfaces. Un pré-cadrage doit d’abord isoler les applications et les risques prioritaires.
Faut-il analyser tous les programmes ?
Pas nécessairement au départ. Un échantillon représentatif et une cartographie des dépendances permettent de cibler les composants les plus critiques.
Qui doit participer ?
Au minimum un responsable métier, un référent applicatif, un interlocuteur production et les personnes qui connaissent les données et les traitements clés.
Quel livrable attendre ?
Une cartographie compréhensible, un registre de risques, des priorités argumentées et une feuille de route distinguant les actions immédiates des transformations.
Passer à l’action
Besoin d’adapter cette checklist à votre patrimoine ?
Le diagnostic de 30 minutes permet de qualifier le périmètre, le niveau d’urgence et la première analyse utile sans engager immédiatement un audit complet.