COBOL
Fiche rapide
- Nom : COBOL
- Signification : Common Business-Oriented Language
- Début du projet : 1959
- Première spécification : COBOL 60, 1960
- Organisation initiale : CODASYL, Conference on Data Systems Languages
- Domaine : informatique de gestion et traitement de données
- Influences majeures : FLOW-MATIC, AIMACO et COMTRAN
- Personnalités associées : Mary K. Hawes, Jean Sammet, Grace Hopper, Charles Phillips et de nombreux représentants des constructeurs et administrations
- Première norme américaine : ANSI X3.23-1968
- Norme internationale actuelle : ISO/IEC 1989:2023
- Paradigmes : impératif, procédural et, dans les versions modernes, orienté objet
- Domaines d’utilisation : banques, assurances, administrations, comptabilité, gestion de fichiers et systèmes transactionnels
Pourquoi créer un nouveau langage en 1959 ?
À la fin des années 1950, l’industrie informatique se développe rapidement. Les entreprises commencent à utiliser des ordinateurs pour la paie, la comptabilité, les stocks, les assurances ou la gestion des clients.
Cependant, chaque constructeur possède sa propre architecture. Les programmes conçus pour une machine UNIVAC ne fonctionnent pas automatiquement sur un ordinateur IBM ou RCA.
Le problème devient économique autant que technique.
Une grande entreprise peut consacrer des mois à développer ses traitements. Lorsqu’elle change d’ordinateur, elle risque de devoir reprendre une grande partie de ce travail. La dépendance vis-à-vis du matériel ralentit donc la diffusion de l’informatique.
Par ailleurs, les langages disponibles répondent mal aux besoins de la gestion. FORTRAN, apparu quelques années plus tôt chez IBM, convient très bien aux calculs scientifiques et aux formules mathématiques. Les entreprises manipulent pourtant surtout des fichiers contenant des noms, des références, des dates, des quantités et des montants.
Il faut donc un langage adapté à cette autre informatique.
Mary Hawes : l’idée d’un langage commun
Au printemps 1959, l’informaticienne Mary K. Hawes, qui travaille alors chez Burroughs, contribue à lancer une réflexion sur la création d’un langage commun pour les applications commerciales.
L’idée consiste à réunir constructeurs et utilisateurs plutôt que de laisser chaque entreprise développer son propre langage.
Le département américain de la Défense s’intéresse rapidement au projet. Le DoD possède lui-même de nombreux ordinateurs provenant de constructeurs différents et doit supporter le coût de logiciels incompatibles.
Les 28 et 29 mai 1959, plusieurs dizaines de représentants de l’industrie, de l’administration et du monde informatique se réunissent au Pentagone.
Ils s’accordent sur plusieurs objectifs : le futur langage doit être orienté vers les problèmes de gestion, rester aussi indépendant que possible des machines et employer largement un vocabulaire anglais.
La Conference on Data Systems Languages, plus connue sous le nom de CODASYL, prend forme autour de ce projet.
Un langage conçu par un comité
Contrairement à FORTRAN, fortement associé à John Backus et à son équipe chez IBM, COBOL n’a pas un inventeur unique.
Plusieurs groupes travaillent sur le projet. Un Short Range Committee doit notamment produire rapidement une première proposition utilisable.
Le travail est ensuite réparti entre plusieurs spécialistes. Jean Sammet, alors chez Sylvania Electric Products, joue un rôle majeur dans la définition des instructions du langage. Mary Hawes travaille notamment sur la description des données.
D’autres femmes participent également au projet, parmi lesquelles Gertrude Tierney, Betty Holberton et Nora Taylor.
Cette présence est remarquable dans une histoire de l’informatique souvent racontée presque exclusivement à travers des figures masculines.
Le travail reste néanmoins difficile. Les participants représentent des constructeurs concurrents. Chacun arrive avec ses propres machines, ses propres langages et ses propres intérêts.
Il faut donc construire un compromis.
FLOW-MATIC, l’une des influences majeures
Parmi les langages étudiés figure FLOW-MATIC, développé quelques années auparavant par l’équipe de Grace Hopper pour les ordinateurs UNIVAC.
FLOW-MATIC a déjà démontré qu’un langage destiné à la gestion peut utiliser des mots anglais comme :
READ-ITEM
COMPARE
TRANSFER
WRITE-ITEMLe système permet également de donner des noms explicites aux données et de séparer leur description des opérations qui les manipulent.
Ces principes influencent directement COBOL.
D’autres travaux comptent également, notamment COMTRAN, développé chez IBM sous l’impulsion de Bob Bemer, ainsi qu’AIMACO.
COBOL ne constitue donc pas une simple nouvelle version de FLOW-MATIC. Il résulte d’une synthèse entre plusieurs expériences.
Grace Hopper a-t-elle créé COBOL ?
Grace Hopper est souvent présentée comme la « mère de COBOL ». Cette expression résume son influence, mais elle donne une vision trop simple de l’histoire.
Hopper ne rédige pas seule les spécifications du langage.
Son apport se situe principalement en amont. Depuis le début des années 1950, elle défend l’idée que le programmeur ne devrait pas avoir à travailler directement avec les codes internes de la machine. Ses systèmes A-0, puis FLOW-MATIC, montrent qu’un compilateur peut effectuer une partie de cette traduction automatiquement.
FLOW-MATIC prouve également qu’un langage commercial utilisant des mots anglais est techniquement réalisable.
Lorsque COBOL apparaît, plusieurs de ces principes sont donc déjà expérimentés.
En revanche, la définition concrète du nouveau langage résulte du travail collectif des différents comités de CODASYL. Jean Sammet compte notamment parmi les principales personnes ayant participé à cette définition.
Dire que Grace Hopper « invente COBOL » est donc incorrect.
Dire que ses travaux ont profondément préparé et influencé COBOL est beaucoup plus juste.
1959 : le premier brouillon
Les équipes avancent rapidement.
En novembre 1959, un petit groupe se réunit à New York afin de préparer une version détaillée du futur langage.
Le Smithsonian conserve aujourd’hui un exemplaire abondamment annoté de ce premier brouillon. Les corrections manuscrites montrent que COBOL ne naît pas sous une forme parfaitement définie : vocabulaire, syntaxe et règles font l’objet de nombreuses discussions.
À la fin de l’année, le Short Range Committee dispose néanmoins d’une première définition suffisamment complète.
Le document est transmis à la direction de CODASYL, qui l’approuve au début de 1960.
Après plusieurs corrections éditoriales, le rapport est diffusé sous le nom de COBOL 60.
Une idée fondamentale : décrire le problème, pas la machine
COBOL repose sur une séparation essentielle.
Le programmeur décrit le traitement qu’il souhaite effectuer :
- lire un fichier ;
- examiner un enregistrement ;
- comparer des valeurs ;
- effectuer un calcul ;
- écrire un résultat.
Le compilateur se charge ensuite de traduire cette description vers les instructions propres à l’ordinateur.
L’objectif n’est évidemment pas de rendre toutes les machines identiques. Un compilateur COBOL doit être développé pour chaque architecture.
En revanche, le programme source peut rester beaucoup plus proche d’une machine à l’autre.
Cette distinction entre langage source et architecture matérielle représente l’une des évolutions fondamentales de l’histoire du logiciel.
1960 : le même programme sur deux ordinateurs différents
La véritable épreuve arrive en 1960.
Il ne suffit pas d’affirmer qu’un langage est indépendant des constructeurs. Il faut le démontrer.
Des équipes développent donc des compilateurs COBOL pour différentes machines. Remington Rand travaille sur UNIVAC tandis que RCA développe sa propre implémentation.
En décembre 1960, des programmes tests identiques sont exécutés avec succès sur un UNIVAC II et un RCA 501.
L’un des programmes produit un état de profits et pertes pour une entreprise. L’autre traite des ventes au comptant et des comptes de crédit.
Le résultat est historiquement important : un même programme source peut être compilé et exécuté sur des ordinateurs provenant de deux constructeurs différents.
L’objectif fixé en 1959 n’est donc plus seulement théorique.
Un langage qui ressemble à l’anglais
La caractéristique la plus visible de COBOL est son vocabulaire.
Un programme emploie des mots comme :
MOVE
ADD
SUBTRACT
MULTIPLY
DIVIDE
IF
PERFORM
READ
WRITE
OPEN
CLOSE
STOPUne instruction peut par exemple ressembler à ceci :
ADD MONTANT TO TOTAL.ou :
IF SOLDE < ZERO
DISPLAY "SOLDE NEGATIF".Cette syntaxe paraît très longue comparée à celle de langages plus récents.
Cependant, cette verbosité est volontaire.
Les concepteurs veulent qu’un programme puisse être lu par des personnes qui connaissent le traitement administratif sans nécessairement maîtriser le fonctionnement électronique de l’ordinateur.
COBOL ne parle pourtant pas « anglais » au sens naturel du terme. Il dispose d’un vocabulaire défini et d’une grammaire précise. Une phrase grammaticalement correcte en anglais n’est pas automatiquement une instruction COBOL valide.
Les quatre divisions d’un programme COBOL
Un programme COBOL classique est organisé en grandes parties appelées divisions.
La structure traditionnelle comprend :
- IDENTIFICATION DIVISION : identifie le programme ;
- ENVIRONMENT DIVISION : décrit certains éléments liés à l’environnement d’exécution ;
- DATA DIVISION : définit les fichiers et les données utilisées ;
- PROCEDURE DIVISION : contient les instructions exécutées.
Un programme minimal moderne peut ainsi ressembler à ceci :
IDENTIFICATION DIVISION.
PROGRAM-ID. BONJOUR.
PROCEDURE DIVISION.
DISPLAY "BONJOUR".
STOP RUN.La séparation entre les données et les opérations qui les manipulent constitue une caractéristique fondamentale du langage.
Elle vient directement des préoccupations de l’informatique de gestion.
La DATA DIVISION : décrire précisément les informations
COBOL accorde une place considérable à la description des données.
Imaginons un enregistrement contenant un numéro de client, un nom et un solde :
01 CLIENT.
05 NUMERO-CLIENT PIC 9(6).
05 NOM-CLIENT PIC X(30).
05 SOLDE PIC S9(7)V99.Les nombres placés devant les champs indiquent leur niveau hiérarchique.
Le niveau 01 représente ici l’ensemble de l’enregistrement. Les éléments de niveau 05 constituent ses différents champs.
Le mot PIC, abréviation de PICTURE, décrit la forme de la donnée.
9(6) indique six chiffres numériques.
X(30) réserve trente caractères.
Enfin, S9(7)V99 décrit un nombre signé possédant sept chiffres avant une virgule décimale implicite et deux après.
Cette description très précise des données explique en partie le succès de COBOL dans les applications de gestion.
Pourquoi le calcul décimal est-il si important ?
Dans une banque ou un système comptable, les erreurs d’arrondi sont problématiques.
Un langage scientifique peut privilégier les nombres en virgule flottante, adaptés à de nombreux calculs mais pouvant introduire de petites approximations dans certaines représentations décimales.
COBOL accorde au contraire une grande importance au calcul décimal à précision fixe.
Un montant monétaire peut être représenté avec un nombre déterminé de chiffres avant et après la virgule.
Par exemple :
01 PRIX PIC 9(5)V99.
01 QUANTITE PIC 9(4).
01 TOTAL PIC 9(9)V99.
MULTIPLY PRIX BY QUANTITE GIVING TOTAL.Cette capacité correspond directement aux besoins de la comptabilité, de la banque et de la facturation.
La conception du langage est donc intimement liée au type de données qu’il doit manipuler.
Des fichiers et des enregistrements
Dans les années 1960, une grande partie des données commerciales se trouve sur des bandes magnétiques puis, progressivement, sur des disques.
Le traitement s’effectue souvent en parcourant de très nombreux enregistrements.
COBOL intègre donc directement des opérations permettant d’ouvrir, lire, écrire et fermer des fichiers :
OPEN INPUT FICHIER-CLIENTS.
READ FICHIER-CLIENTS
AT END
MOVE "O" TO FIN-FICHIER
END-READ.
CLOSE FICHIER-CLIENTS.Cette orientation vers les fichiers constitue l’une des grandes différences avec les langages principalement destinés au calcul scientifique.
Pour COBOL, la donnée commerciale n’est pas un détail ajouté au langage : elle se trouve au centre de sa conception.
Un exemple de traitement
Un programme simplifié peut parcourir des opérations commerciales et accumuler leur montant :
IDENTIFICATION DIVISION.
PROGRAM-ID. TOTAL-VENTES.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 PRIX PIC 9(5)V99.
01 QUANTITE PIC 9(4).
01 MONTANT PIC 9(9)V99.
01 TOTAL PIC 9(10)V99 VALUE ZERO.
PROCEDURE DIVISION.
MOVE 19.95 TO PRIX.
MOVE 3 TO QUANTITE.
MULTIPLY PRIX BY QUANTITE GIVING MONTANT.
ADD MONTANT TO TOTAL.
DISPLAY "TOTAL : " TOTAL.
STOP RUN.La syntaxe paraît longue, mais son déroulement reste facile à suivre : le programme calcule un montant, l’ajoute au total puis affiche le résultat.
Cette lisibilité constitue précisément l’un des objectifs historiques du langage.
Pourquoi les anciens programmes COBOL ont-ils des colonnes ?
Les vieux listings COBOL présentent une caractéristique étrange : le texte semble aligné dans des colonnes très précises.
Cette organisation vient directement des cartes perforées et des méthodes de programmation de l’époque.
Dans le format classique, une ligne COBOL comporte différentes zones :
- colonnes 1 à 6 : numéro de séquence ;
- colonne 7 : indicateur particulier, par exemple pour un commentaire ou une continuation ;
- colonnes 8 à 11 : zone A ;
- colonnes 12 à 72 : zone B ;
- colonnes 73 à 80 : zone autrefois utilisée notamment pour l’identification ou la documentation.
Certaines constructions doivent commencer dans la zone A, tandis que la majorité des instructions prennent place dans la zone B.
Cette contrainte peut sembler arbitraire sur un écran moderne. Elle devient beaucoup plus compréhensible lorsqu’on se souvient que les programmes étaient préparés sur des supports physiques de largeur fixe.
Les compilateurs modernes proposent heureusement des formats plus libres.
Les niveaux : représenter la structure d’un enregistrement
Les nombres placés devant les déclarations COBOL permettent de décrire une structure hiérarchique.
Par exemple :
01 EMPLOYE.
05 IDENTITE.
10 NOM PIC X(30).
10 PRENOM PIC X(20).
05 SALAIRE PIC 9(7)V99.
05 DEPARTEMENT PIC 9(3).L’enregistrement EMPLOYE contient ici un groupe IDENTITE, lui-même composé d’un nom et d’un prénom.
Cette organisation ressemble à ce que l’on appellerait aujourd’hui une structure ou un enregistrement.
Elle permet de manipuler soit une donnée élémentaire, soit tout un groupe.
Par exemple, le programme peut déplacer une structure complète vers une autre structure compatible.
Cette capacité facilite considérablement le traitement des enregistrements commerciaux.
Les copybooks : partager les descriptions
Dans les grands systèmes, plusieurs programmes utilisent souvent les mêmes structures de données.
Plutôt que de recopier leurs descriptions dans chaque fichier source, COBOL permet d’utiliser des éléments externes souvent appelés copybooks.
Une instruction peut ainsi demander :
COPY CLIENT.Le compilateur insère alors le texte correspondant lors de la compilation.
Cette méthode facilite la réutilisation des définitions.
Cependant, elle peut également créer de fortes dépendances entre de nombreux programmes lorsque les mêmes structures sont utilisées pendant plusieurs décennies.
Les copybooks sont ainsi devenus une caractéristique familière des grandes applications COBOL.
COBOL devient un standard
L’un des objectifs fondamentaux du projet consiste à empêcher le langage de devenir la propriété d’un constructeur particulier.
Cette volonté conduit progressivement à sa normalisation.
Une première norme américaine importante paraît en 1968 sous la référence ANSI X3.23-1968.
Le langage continue ensuite d’évoluer.
Une révision majeure paraît en 1974, puis une nouvelle version en 1985. Cette dernière est généralement appelée COBOL 85.
La normalisation joue un rôle essentiel. Un constructeur peut proposer ses propres extensions, mais une base commune permet de préserver une partie de la portabilité recherchée dès 1959.
Un langage qui continue d’évoluer
COBOL n’est pas resté figé dans les années 1960.
La norme internationale évolue régulièrement afin de prendre en compte de nouvelles pratiques.
La version ISO/IEC 1989:2002 constitue notamment une évolution importante et standardise de nouvelles possibilités, dont des mécanismes de programmation orientée objet.
Une nouvelle révision paraît en 2014.
Puis, en janvier 2023, l’ISO publie ISO/IEC 1989:2023, qui constitue la norme internationale publiée de référence.
Le langage moderne conserve donc ses caractéristiques historiques tout en intégrant des mécanismes qui auraient été difficiles à imaginer en 1959.
En 2026, une nouvelle révision de la norme est déjà en préparation.
Le passage à l’an 2000 : COBOL au centre du problème Y2K
À la fin des années 1990, les anciens systèmes informatiques reviennent brutalement au premier plan avec le problème de l’an 2000, ou Y2K.
Pendant des décennies, de nombreux programmes ont enregistré l’année sur seulement deux chiffres afin d’économiser de la mémoire et de l’espace de stockage.
Ainsi, 1987 devient simplement 87.
Cette méthode fonctionne tant que tous les traitements concernent le même siècle. À l’approche de l’année 2000, elle devient dangereuse : 00 peut être interprété comme 1900 au lieu de 2000.
COBOL n’est pas responsable de cette pratique et le problème touche de nombreux langages. Cependant, la quantité de logiciels de gestion anciens écrits en COBOL place le langage au cœur des opérations de correction.
Banques, assurances, administrations et grandes entreprises doivent examiner d’immenses ensembles de programmes.
Le passage à l’an 2000 rappelle alors une réalité fondamentale : un logiciel peut rester en production beaucoup plus longtemps que ne l’imaginaient ses concepteurs.
Pourquoi ne pas simplement remplacer tous les programmes COBOL ?
À première vue, la solution semble évidente : réécrire les anciennes applications dans un langage moderne.
En pratique, l’opération est beaucoup plus difficile.
Un grand programme COBOL ne contient pas seulement du code. Il matérialise parfois plusieurs décennies de règles métier : calculs de primes, conventions comptables, règles fiscales, tarification, procédures administratives ou traitements exceptionnels.
Certaines de ces règles ne sont plus documentées ailleurs.
Le programme lui-même devient donc une forme de documentation du fonctionnement de l’organisation.
Une réécriture complète risque de perdre certains comportements acquis au fil des années.
À cela s’ajoutent les interfaces avec les bases de données, les fichiers, les transactions et de nombreux autres programmes.
La modernisation d’un système COBOL constitue donc davantage un problème d’architecture et d’ingénierie que de simple traduction syntaxique.
COBOL et les mainframes
COBOL est aujourd’hui fortement associé au mainframe, en particulier aux systèmes IBM.
Cette association est logique. Les grandes organisations qui utilisent COBOL ont souvent besoin de traiter d’importants volumes de transactions et de données avec une grande disponibilité.
Cependant, COBOL n’est pas techniquement limité aux mainframes.
Des compilateurs ont existé pour de nombreuses architectures et plusieurs environnements permettent encore aujourd’hui d’exécuter des programmes COBOL sur d’autres systèmes.
Il faut donc distinguer le langage de la machine.
COBOL décrit le programme.
Le mainframe constitue l’une des plateformes sur lesquelles ce programme peut fonctionner.
Cette séparation était justement l’un des objectifs recherchés dès la création du langage.
COBOL est-il encore utilisé ?
Oui.
Il serait cependant difficile de donner un nombre exact de programmes ou de lignes de code encore en exploitation. Les chiffres spectaculaires souvent repris sur Internet reposent généralement sur des estimations dont la méthodologie varie fortement.
Un fait est néanmoins documenté : des administrations et de grandes entreprises utilisent toujours des applications COBOL.
En 2025, le Government Accountability Office américain signalait encore plusieurs systèmes fédéraux critiques utilisant COBOL et le langage assembleur. Certains de ces systèmes doivent désormais faire face à une difficulté supplémentaire : le nombre décroissant de spécialistes capables de les maintenir.
COBOL n’est donc pas seulement un objet historique.
Le langage continue d’exécuter des traitements réels, parfois au cœur d’organisations qui dépendent de ces applications depuis plusieurs décennies.
Un paradoxe : un langage ancien mais un logiciel toujours actif
L’âge de COBOL produit une situation particulière.
Un programme développé dans les années 1970 ou 1980 peut avoir été modifié des centaines de fois. Il peut aujourd’hui communiquer avec une application Web, une API ou un service écrit en Java sans que sa logique centrale ait été remplacée.
Le système devient alors un empilement de plusieurs générations informatiques.
Le langage historique cohabite avec des interfaces modernes.
Cette évolution explique pourquoi la modernisation ne consiste pas toujours à supprimer COBOL. Certaines organisations conservent la logique métier existante tout en construisant de nouveaux services autour d’elle.
Dans ce cas, le programme COBOL cesse progressivement d’être l’interface visible du système mais continue d’effectuer une partie essentielle des traitements en arrière-plan.
Pourquoi COBOL a-t-il duré aussi longtemps ?
Plusieurs raisons expliquent cette longévité.
Tout d’abord, COBOL correspond très bien aux traitements pour lesquels il a été conçu : fichiers, enregistrements, calcul décimal, volumes importants de données et traitements commerciaux.
Ensuite, les programmes ont accumulé une quantité considérable de logique métier.
Les remplacer représente donc un coût et un risque.
Enfin, la standardisation a permis au langage d’évoluer sans abandonner complètement son héritage.
Cette compatibilité constitue à la fois une force et une contrainte. Elle permet de conserver des programmes anciens, mais elle oblige également les nouvelles versions à tenir compte de décisions prises plusieurs décennies auparavant.
Un langage trop verbeux ?
COBOL est souvent critiqué pour sa longueur.
Une opération qui nécessiterait quelques caractères dans un langage moderne peut demander plusieurs mots.
Cette critique est justifiée si l’objectif consiste uniquement à écrire le programme le plus court possible.
Mais ce n’était pas la priorité des concepteurs.
Le langage vise d’abord à produire des programmes que l’on peut relire et maintenir.
Dans une application destinée à rester en service pendant vingt ou trente ans, quelques caractères économisés lors de l’écriture peuvent avoir beaucoup moins d’importance que la possibilité de comprendre le code plusieurs années plus tard.
Le débat reste d’ailleurs très actuel : un programme doit-il privilégier la concision ou l’explicitation de son intention ?
COBOL a clairement choisi la seconde voie.
Ce que COBOL change dans l’histoire du logiciel
L’importance historique de COBOL dépasse largement son domaine commercial.
Le langage matérialise plusieurs transformations fondamentales.
Tout d’abord, le logiciel commence à devenir indépendant du constructeur. Le programmeur n’écrit plus nécessairement pour une machine unique.
Ensuite, les données prennent une place centrale dans la conception du langage. Leur structure, leur taille et leur représentation sont décrites explicitement.
Enfin, le programme devient plus lisible pour un être humain. La syntaxe cherche à exprimer une opération plutôt qu’à refléter directement les circuits du processeur.
Ces principes deviendront familiers dans les générations suivantes de langages.
COBOL n’est pas seulement un vestige des années 1960
Il serait facile de présenter COBOL comme une curiosité survivant uniquement parce que personne n’ose supprimer les vieux programmes.
La réalité est plus complexe.
Le langage a effectivement hérité d’une syntaxe et de contraintes provenant d’une autre époque. Pourtant, son domaine d’origine — le traitement fiable de grandes quantités de données commerciales — reste essentiel.
Surtout, les systèmes existants contiennent souvent une connaissance métier accumulée pendant plusieurs décennies.
COBOL pose donc une question intéressante dans l’histoire de l’informatique : à quel moment un ancien programme cesse-t-il d’être un héritage technique pour devenir une infrastructure ?
Dans de nombreuses organisations, cette frontière a depuis longtemps été franchie.
Pourquoi COBOL est important
- Portabilité : COBOL est conçu dès l’origine pour réduire la dépendance des programmes vis-à-vis d’un constructeur particulier.
- Informatique de gestion : il place les fichiers, les enregistrements, les montants et les traitements commerciaux au centre du langage.
- Lisibilité : sa syntaxe utilise volontairement de nombreux mots anglais afin de rendre le programme plus explicite.
- Description des données : la DATA DIVISION et les clauses PICTURE permettent de définir précisément la structure des informations.
- Calcul décimal : ses mécanismes conviennent particulièrement aux montants monétaires et à la comptabilité.
- Standardisation : son développement s’effectue dans le cadre d’organisations communes plutôt que sous le contrôle d’un seul constructeur.
- Longévité : de nombreux programmes développés plusieurs décennies auparavant continuent à remplir des fonctions importantes.
- Héritage : COBOL contribue à faire du logiciel une couche capable de séparer progressivement le problème à résoudre du fonctionnement interne de la machine.
COBOL n’est donc pas seulement le symbole des vieux mainframes.
Son importance historique tient surtout à l’idée qui motive sa création en 1959 : une entreprise devrait pouvoir décrire ses traitements dans un langage commun sans devoir réinventer entièrement ses programmes à chaque changement d’ordinateur.
En décembre 1960, l’exécution des mêmes programmes sur un UNIVAC II et un RCA 501 montre que cette ambition peut devenir réalité.
Plus de six décennies plus tard, le langage continue d’évoluer.
Peu de technologies informatiques peuvent revendiquer une telle continuité.
Repères chronologiques
- 1957 : FLOW-MATIC démontre la possibilité d’un langage commercial utilisant un vocabulaire proche de l’anglais.
- Printemps 1959 : Mary K. Hawes participe au lancement d’une initiative en faveur d’un langage commercial commun.
- 28–29 mai 1959 : réunion au Pentagone autour du projet d’un langage commun indépendant des constructeurs.
- 1959 : constitution des groupes de travail de CODASYL.
- Novembre 1959 : préparation à New York d’un premier brouillon détaillé du langage.
- 1960 : diffusion de la spécification connue sous le nom de COBOL 60.
- Décembre 1960 : les mêmes programmes COBOL sont exécutés sur un UNIVAC II et un RCA 501.
- 1968 : première grande normalisation américaine avec ANSI X3.23-1968.
- 1974 : nouvelle révision importante du standard.
- 1985 : publication de COBOL 85.
- 2002 : publication d’ISO/IEC 1989:2002, qui modernise largement le langage et inclut notamment la programmation orientée objet.
- 2014 : nouvelle édition de la norme internationale.
- 2023 : publication d’ISO/IEC 1989:2023.
- 2026 : une nouvelle édition de la norme COBOL est en cours d’élaboration à l’ISO.
Sources principales
- CODASYL, COBOL — Initial Specifications for a Common Business Oriented Language, 1960.
- Jean E. Sammet, The Early History of COBOL, History of Programming Languages.
- Smithsonian National Museum of American History, First Draft of the Programming Language COBOL.
- Smithsonian National Museum of American History, documentation du test COBOL réalisé sur RCA 501 et UNIVAC II en décembre 1960.
- Computer History Museum, documentation historique sur COBOL, Grace Hopper et Jean Sammet.
- National Bureau of Standards / NIST, normes fédérales COBOL et documentation sur ANSI COBOL.
- ISO/IEC JTC 1/SC 22, normes internationales du langage COBOL.
- U.S. Government Accountability Office, rapports consacrés aux systèmes informatiques anciens et à leur modernisation.
Illustration de couverture : à compléter selon l’image retenue.
