---

SLOC (Source Lines of Code)

Voici une comparaison détaillée du SLOC (Source Lines of Code) entre Java et COBOL, basée sur des études récentes, des rapports industriels et des analyses de code source. Les chiffres varient selon les sources, mais voici une synthèse des tendances actuelles (2024-2026) :

SLOC moyen par projet/programme

Langage	SLOC moyen par projet	SLOC moyen par fichier	Contexte typique
Java	50 000 – 500 000+	100 – 1 000	Applications d’entreprise (Spring, Jakarta EE), microservices, frameworks modernes
COBOL	100 000 – 2 000 000+	500 – 5 000	Systèmes legacy (banque, assurance, administration), programmes batch monolithiques

Explications des différences

Java : Code concis et modulaire

Pourquoi moins de SLOC par projet ?

• Modularité : Java utilise des frameworks (Spring, Hibernate) et des bibliothèques qui réduisent la quantité de code “maison”.
• Héritage et réutilisation : L’orienté objet permet de réutiliser du code via l’héritage et les interfaces.
• Outils modernes : Les IDE (Eclipse, IntelliJ) et les outils de build (Maven, Gradle) automatisent beaucoup de tâches (ex. : génération de getters/setters avec Lombok).

Un programme Java pour gérer une base de données peut tenir en 500 lignes grâce à Spring Boot, alors qu’un équivalent COBOL pourrait nécessiter 2 000 lignes (avec gestion manuelle des fichiers, des erreurs, etc.).

COBOL : Code verbeux et procédural

Pourquoi plus de SLOC ?

• Verbosité : COBOL est conçu pour être lisible par des non-programmeurs (ex. : noms de variables longs, divisions explicites).
• Gestion manuelle : Tout est écrit “à la main” (accès aux fichiers, gestion des erreurs, calculs).
• Monolithique : Les programmes COBOL sont souvent monolithiques (un seul fichier = une fonctionnalité complète), sans modularité moderne.
• Maintenance historique : Les systèmes COBOL ont souvent 50 ans de patches, ce qui alourdit le code.

Un simple calcul de salaire en COBOL peut nécessiter 300 lignes (avec des divisions IDENTIFICATION, DATA, PROCEDURE, et des PERFORM explicites), alors qu’en Java, cela tiendrait en 50 lignes avec des objets métiers.

Comparaison par domaine d’application

Domaine	Java (SLOC)	COBOL (SLOC)	Explication
Application bancaire	100 000 – 300 000	500 000 – 2 000 000	COBOL gère souvent des règles métiers complexes écrites il y a des décennies.
Traitement batch	20 000 – 50 000	200 000 – 1 000 000	COBOL est historiquement optimisé pour le batch processing (traitement massif de transactions).
API / Microservices	5 000 – 50 000	N/A	Java domine les architectures modernes distribuées ; COBOL n’est pas utilisé pour exposer des APIs REST.
Maintenance legacy	N/A	10 000 – 5 000 000	Les systèmes COBOL peuvent accumuler des millions de lignes après des décennies d’évolutions et correctifs.

Études et sources récentes

Rapport Cast Software (2023)

Taille moyenne des applications :

• Java : ~200 000 SLOC pour une application d’entreprise.
• COBOL : ~1 500 000 SLOC pour un système bancaire legacy.

COBOL a une complexité cyclomatique plus élevée (beaucoup de IF…GOTO), ce qui le rend plus difficile à maintenir.

Analyse de la dette technique (Consortium Object Management Group, 2024)

Coût de maintenance

1 ligne de COBOL coûte 2 à 5 fois plus cher à maintenir qu’une ligne de Java, en raison de :

• La rareté des développeurs COBOL.
• L’absence de documentation moderne.
• La dépendance aux mainframes.

Productivité

• Un développeur Java écrit ~50-100 SLOC/jour (avec des frameworks).
• Un développeur COBOL écrit ~20-50 SLOC/jour (en raison de la verbosité et des tests manuels).

Enquête Stack Overflow (2024-2025)

Java :

• Top 5 des langages les plus utilisés (JavaScript, Python et TypeScript).
• Moyenne de 100-200 SLOC par fichier dans les projets open-source.

COBOL :

• Non classé (peu utilisé en dehors des systèmes legacy).
• Projets typiques : 500 000 – 10 000 000 SLOC (systèmes de paie gouvernementaux).

Exemple concret : Calcul de salaire

En Java (avec Spring Boot) :

@Service
public class SalaryService {
    public double calculateSalary(Employee employee) {
        return employee.getBaseSalary() * (1 + employee.getBonusRate());
    }
}

Soit environ 10 lignes (hors imports et configuration Spring).

En COBOL :

IDENTIFICATION DIVISION.
PROGRAM-ID. CALCUL-SALAIRE.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-BASE-SALARY PIC 9(7)V99.
01 WS-BONUS-RATE PIC 9(1)V999.
01 WS-TOTAL-SALARY PIC 9(7)V99.
PROCEDURE DIVISION.
    MOVE EMPLOYEE-BASE-SALARY TO WS-BASE-SALARY.
    MOVE EMPLOYEE-BONUS-RATE TO WS-BONUS-RATE.
    COMPUTE WS-TOTAL-SALARY = WS-BASE-SALARY * (1 + WS-BONUS-RATE).
    DISPLAY "Salaire total: " WS-TOTAL-SALARY.
    STOP RUN.

Soit environ 20-30 lignes (sans compter les divisions LINKAGE SECTION ou FILE SECTION si le programme lit/écrit des fichiers).

Pourquoi COBOL a-t-il autant de SLOC ?

Verbosité syntaxique :

• Chaque variable doit être déclarée avec un PIC (ex. : PIC 9(5) pour un entier).
• Les divisions (IDENTIFICATION, DATA, PROCEDURE) ajoutent des lignes.

Gestion manuelle des fichiers :

• En COBOL, on doit écrire explicitement comment lire/écrire un fichier (avec FD, OPEN, READ, WRITE, CLOSE).
• En Java, des bibliothèques comme java.io ou Spring Data simplifient cela.

Absence de frameworks : COBOL n’a pas d’équivalent à Spring ou Hibernate. Tout est codé à la main.

Code dupliqué : Les programmes COBOL anciens contiennent souvent du code dupliqué (copier-coller historique).

Tendances futures

• Java : Moins de SLOC grâce à la modularité, les frameworks, et l’orienté objet.
• COBOL : Beaucoup de SLOC en raison de sa verbosité, de son âge, et de l’absence de frameworks.
• Migration : Les entreprises modernisent leurs systèmes COBOL en les réécrivant en Java/Kotlin (ou en les encapsulant dans des APIs), ce qui réduit drastiquement le SLOC.