Ce que les équipes techniques demandent avant de nous confier du code.

Quels fichiers faut-il nous transmettre ?

Les sources COBOL (.cbl, .cob), les COPYBOOKS (.cpy) et, quand ils existent, les JCL. Une archive ZIP est acceptée. Plus les COPYBOOKS référencés sont fournis, plus les structures de données peuvent être résolues ; ceux qui manquent sont listés dans le rapport plutôt que devinés.

Quels dialectes COBOL sont couverts ?

L'analyse porte sur la structure standard du langage : divisions, sections, paragraphes, clauses PIC, instructions de contrôle et d'entrée-sortie. Cette base est commune à IBM Enterprise COBOL, Micro Focus et GnuCOBOL. Les extensions propres à un compilateur ou à un atelier interne sont relevées et signalées comme à confirmer avec vos équipes.

Traitez-vous le SQL embarqué ?

Oui. Les blocs EXEC SQL … END-EXEC sont relevés : tables lues et modifiées, type d'opération, curseurs déclarés, variables hôtes. C'est souvent la partie la plus riche en information métier, parce qu'elle nomme les données réelles derrière les variables de travail.

Et CICS, VSAM, JCL ?

Les commandes EXEC CICS et les accès fichiers déclarés en SELECT … ASSIGN sont relevés dans le code fourni. Le JCL est analysé quand il est transmis : enchaînement des étapes, programmes appelés, fichiers en entrée et en sortie.

En revanche, ce qui vit en dehors des sources — définitions CSD, tables de paramétrage, conventions d'exploitation — n'est pas déductible du code seul. Ces éléments sont identifiés comme dépendances externes non résolues, et c'est précisément le genre de zone que l'entretien avec vos experts sert à combler.

Comment traitez-vous un appel de programme dynamique ?

Un CALL dont la cible est une variable ne peut pas être résolu de façon certaine par lecture du code. Il est signalé comme dépendance non résolue, avec le programme, le paragraphe et la variable concernés, ainsi que les valeurs éventuellement affectées à cette variable ailleurs dans le source. Il n'est jamais deviné.

Analysez-vous des programmes de plus de 10 000 lignes ?

Oui, avec un devis ajusté. Le seuil de 10 000 lignes correspond au format standard du Diagnostic Express ; au-delà, la charge de lecture et de validation augmente et le périmètre est arrêté au cadrage.

Où va notre code source ?

Le transfert se fait en HTTPS vers un espace dédié à votre organisation. Les données d'un client ne sont jamais mélangées à celles d'un autre. Les conditions exactes — lieu de traitement, personnes ayant accès, durée de conservation — sont écrites et acceptées avant tout envoi.

Notre code sert-il à entraîner un modèle d'IA ?

Non. Aucun code client n'est utilisé pour entraîner, affiner ou évaluer un modèle, ni par Bosqweb ni par un tiers.

Combien de temps conservez-vous les fichiers ?

La durée est fixée au cadrage, avant l'envoi, et inscrite au contrat. Elle dépend de la prestation : un diagnostic ponctuel n'appelle pas la même rétention qu'un mandat de documentation continue. La suppression est confirmée par écrit à l'issue du mandat.

Faut-il un accès à nos environnements ou à la production ?

Non. L'analyse est statique et porte uniquement sur les sources transmises. Aucune exécution de code, aucune compilation, aucun agent installé chez vous, aucun accès à vos systèmes. C'est ce qui permet de démarrer sans passer par une validation d'infrastructure.

Signez-vous un accord de confidentialité ?

Oui, avant tout transfert. Votre modèle de NDA est accepté ; à défaut, Bosqweb en fournit un. Aucun code n'est demandé tant que cet accord n'est pas signé.

Peut-on travailler sur du code anonymisé ?

Oui, mais avec une conséquence à connaître : renommer les programmes, les champs et les tables retire une grande partie du sens métier, qui est justement ce que le diagnostic cherche à reconstituer. Un périmètre réduit sur du code réel donne un meilleur résultat qu'un large périmètre anonymisé.

Comment distinguez-vous ce qui est certain de ce qui est supposé ?

Chaque élément du rapport porte un statut : observé dans le code, déduit avec justification, à confirmer, ou non déterminable avec les sources fournies. Un constat observé cite son emplacement exact — fichier, paragraphe, ligne. Un constat déduit explique le raisonnement qui y mène.

Utilisez-vous l'IA, et est-ce fiable ?

L'extraction de la structure — divisions, paragraphes, variables, COPYBOOKS, fichiers, tables, appels — est déterministe : c'est de la lecture de code, pas de la génération. L'IA intervient pour formuler en langage clair ce que le code fait, et cette formulation est systématiquement rattachée à l'extrait qui la justifie, puis relue avant livraison.

Ce qui vous est facturé n'est pas une sortie de modèle, mais un diagnostic validé.

Garantissez-vous d'avoir trouvé toutes les règles métier ?

Non, et personne ne peut le garantir honnêtement. Une partie de la logique d'un système critique ne vit pas dans le code : elle est dans les tables de paramétrage, dans les procédures d'exploitation, dans des correctifs dont personne n'a gardé la trace. Le rapport documente ce que le code établit et délimite explicitement ce qu'il ne permet pas d'établir.

Que se passe-t-il si notre documentation existante contredit le code ?

L'écart est signalé, avec les deux versions et l'emplacement dans le source. C'est un résultat en soi : un document de référence faux est plus dangereux qu'une absence de documentation, parce que des décisions ont pu être prises en s'y fiant.

Nous n'avons plus tous les COPYBOOKS ni tous les JCL. Est-ce bloquant ?

Non, et c'est fréquent. Le rapport documente ce qui est déterminable avec les sources fournies, et liste séparément ce qui manque et pourquoi cela empêche de conclure. Cette liste est souvent le résultat le plus utile du diagnostic, parce qu'elle mesure ce que l'organisation a réellement perdu.

Qui valide les conclusions ?

Vos experts. Le diagnostic prépare le travail — il rassemble, structure et cite les preuves — mais la validation métier appartient à ceux qui connaissent le système en production. C'est aussi ce qui rend le rapport défendable devant un comité.

Combien de temps prend un diagnostic ?

72 heures ouvrées pour un Diagnostic Express sur un programme. 5 à 10 jours ouvrés pour un flux métier, selon le nombre de programmes et la disponibilité de vos experts pour l'entretien de validation. Un périmètre applicatif complet suit un calendrier convenu.

Que devons-nous mobiliser de notre côté ?

Pour un Diagnostic Express : les sources, et trente minutes pour la restitution. Pour un diagnostic de flux : un entretien avec une personne qui connaît techniquement le traitement, un entretien avec un représentant métier ou applicatif, et une heure de restitution. C'est l'essentiel de la charge interne.

Peut-on commencer petit ?

C'est même recommandé. Le Diagnostic Express existe pour cela : un programme, une question précise, un livrable qui permet de juger sur pièces avant d'engager un périmètre plus large.

Comment se passe la facturation ?

Facture, bon de commande et virement. Les prix sont publics et fixés avant le début des travaux ; le devis n'évolue pas en cours de mandat sans accord écrit sur un changement de périmètre.

Travaillez-vous en sous-traitance pour une ESN ?

Oui, y compris en marque blanche pour une phase de découverte ou une reprise applicative. Les conditions de confidentialité s'appliquent alors dans les deux sens.

Convertissez-vous le COBOL en Java ou vers le cloud ?

Non. Le diagnostic sert à comprendre un système avant de décider quoi en faire. Il peut alimenter un projet de migration en réduisant l'incertitude initiale, mais il ne réécrit aucune ligne de code.

Optimisez-vous la consommation mainframe ?

Non. Réduire une facture MSU suppose des mesures d'exécution en production, ce qui sort du cadre d'une analyse statique en lecture seule.

Le diagnostic nous met-il en conformité ?

Non. Aucune cartographie ne rend conforme à un référentiel réglementaire. Elle peut en revanche fournir des éléments de traçabilité utiles à un audit : quelles données sont lues et modifiées, par quels traitements, et sur quelles preuves ces constats reposent.

Remplacez-vous nos experts COBOL ?

Non. Le diagnostic réduit le temps qu'ils passent à retrouver l'information et met par écrit ce que seuls quelques-uns savent. Leur jugement reste la référence, en particulier sur tout ce qui relève du comportement en production.