06.10.2026 · Signal Titans Editorial

John Backus disait que la paresse guidait son travail. Le résultat fut FORTRAN.

Portrait de l’informaticien John Backus.

John Backus expliqua un jour l’une des inventions les plus importantes de la programmation avec une motivation étonnamment simple :

« Une grande partie de mon travail vient de la paresse. Je n’aimais pas écrire des programmes, alors j’ai commencé à travailler sur un système qui les rendrait plus faciles à écrire. »

Ce système devint FORTRAN.

Avant FORTRAN, programmer un ordinateur scientifique pouvait ressembler à un combat rapproché avec la machine.

Les programmeurs écrivaient de longues séquences d’instructions très bas niveau, géraient manuellement les détails matériels et passaient énormément de temps à déboguer du code lié à une machine précise.

Backus regarda tout cet effort et posa une question dangereuse.

Pourquoi les humains devraient-ils continuer à faire un travail que l’ordinateur pouvait faire à leur place ?

Il est entré chez IBM presque par hasard

Backus n’a pas suivi un chemin parfait vers l’informatique.

Il quitta une université après de nombreuses absences, essaya la médecine puis abandonna. Il finit par obtenir un master en mathématiques à Columbia.

En 1950, il entra presque par hasard au siège d’IBM à New York, où l’énorme Selective Sequence Electronic Calculator était exposé.

Il mentionna son intérêt pour les mathématiques.

Un employé d’IBM lui proposa plusieurs problèmes.

Backus les résolut.

IBM l’embaucha comme programmeur même si, selon son propre récit, il savait à peine ce que programmer voulait dire.

La programmation coûtait cher parce que les humains faisaient du travail de machine

La programmation des débuts obligeait les humains à penser constamment aux détails du matériel.

Les instructions étaient extrêmement bas niveau.

Les programmes devaient être adaptés à des machines spécifiques.

Les programmeurs passaient un temps énorme à traduire une intention mathématique en petites opérations compréhensibles par le processeur.

IBM expliqua plus tard qu’un problème pouvant demander jusqu’à mille instructions écrites à la main pouvait être exprimé en seulement 47 instructions FORTRAN.

La différence n’était pas que FORTRAN simplifiait les mathématiques.

Il permettait au programmeur d’exprimer plus directement le calcul voulu.

Le compilateur prenait en charge une grande partie de la traduction pénible.

L’objection évidente était : le code généré sera trop lent

C’était une objection sérieuse.

Dans les années 1950, le temps machine coûtait extrêmement cher.

Les programmeurs experts étaient fiers de produire du code machine efficace à la main.

Beaucoup pensaient qu’un compilateur ne pourrait jamais générer du code assez bon pour justifier le confort d’un langage de haut niveau.

L’équipe FORTRAN devait donc faire plus que rendre la programmation facile.

Elle devait produire des programmes rapides.

C’est ce qui rendit le compilateur si remarquable.

L’équipe de Backus développa des techniques d’optimisation capables de générer du code machine compétitif avec du code soigneusement écrit à la main.

Le confort n’exigeait pas l’abandon de la performance.

La productivité a explosé lorsque l’abstraction est devenue digne de confiance

Une fois que les programmeurs eurent confiance dans le compilateur, l’économie changea.

Scientifiques et ingénieurs pouvaient exprimer leurs formules dans une forme beaucoup plus proche de leur notation mathématique.

Les programmes prenaient moins de temps à écrire.

Le débogage dépendait moins des erreurs de bookkeeping bas niveau.

Le code pouvait être déplacé entre machines disposant de compilateurs FORTRAN compatibles.

La programmation cessa d’être une petite caste de personnes connaissant chaque détail d’un ordinateur précis.

Davantage d’experts métier purent programmer directement.

C’est ce qu’une bonne abstraction fait réellement.

Elle ne se contente pas d’économiser des frappes.

Elle change qui peut participer.

La « paresse » en ingénierie peut être une forme d’ambition

La phrase de Backus est amusante parce que la paresse semble être l’opposé de la réussite.

Mais il existe deux sortes de paresse.

L’une évite le travail nécessaire.

L’autre refuse le travail inutile.

La seconde peut être extraordinairement productive.

Pourquoi réécrire le même boilerplate ?

Pourquoi réconcilier des données manuellement si le système peut le faire ?

Pourquoi mémoriser un rituel opérationnel qui peut être encodé ?

Pourquoi laisser chaque nouvel ingénieur redécouvrir la même règle cachée ?

L’automatisation commence souvent par l’irritation.

Les meilleurs outils suppriment une catégorie entière de pensée

Un outil moyen rend une ancienne tâche légèrement plus rapide.

Un outil transformateur rend une partie de l’ancienne tâche inutile.

FORTRAN n’était pas simplement une syntaxe plus agréable pour du code machine.

Il déplaçait de la responsabilité du programmeur vers le compilateur.

Le programmeur pouvait penser davantage au problème.

Le compilateur pouvait penser davantage à la machine.

Cette division du travail est partout dans l’informatique moderne.

Les garbage collectors gèrent la mémoire.

Les moteurs de base de données choisissent les plans de requête.

Les plateformes cloud allouent les machines.

Les compilateurs réordonnent les instructions.

Les outils d’IA produisent du code et des transformations qui demandaient autrefois du travail manuel répétitif.

Chaque couche repose la question de Backus :

Quel détail exige réellement une attention humaine, et lequel n’existe encore que parce que l’ancien outil nous l’imposait ?

Backus n’a jamais cessé de remettre l’abstraction en question

Même après que FORTRAN soit devenu l’un des langages les plus influents de l’histoire, Backus ne l’a pas considéré comme la réponse finale.

Il critiqua ensuite les limites des styles conventionnels et explora la programmation fonctionnelle — une nouvelle tentative pour décrire les problèmes à un niveau plus élevé.

Il contribua aussi au développement de la notation appelée Backus-Naur Form pour décrire la grammaire des langages.

Le motif resta le même.

Faire prendre davantage de mécanique par la machine.

Laisser l’humain réfléchir à un niveau plus utile.

La vraie question de productivité n’est pas « comment travailler plus dur ? »

Les équipes répondent souvent à la surcharge par plus d’heures, plus de personnes, plus de checklists et plus de processus.

Parfois la meilleure question est de savoir si ce travail devrait exister.

Backus n’est pas simplement devenu meilleur en programmation bas niveau.

Il a aidé à changer le niveau auquel la programmation se faisait.

Quel travail essayez-vous d’accélérer alors qu’il serait plus précieux de le supprimer entièrement ?