Dijkstra & programmation structurée : une discipline qui tient à l'échelle

Pourquoi Dijkstra compte encore quand le logiciel grandit

Les logiciels échouent rarement parce qu’ils ne peuvent pas être écrits. Ils échouent parce qu’un an plus tard, personne ne peut les changer en toute sécurité.

À mesure que les bases de code croissent, chaque ajustement « mineur » commence à se répercuter : une correction de bug casse une fonctionnalité lointaine, une nouvelle exigence force des réécritures, et un simple refactor se transforme en une semaine de coordination prudente. La difficulté n’est pas d’ajouter du code — c’est de maintenir un comportement prévisible pendant que tout autour évolue.

La promesse : correction et simplicité réduisent le coût à long terme

Edsger Dijkstra soutenait que la correction et la simplicité doivent être des objectifs de premier rang, pas de jolis bonus. Le gain n’est pas académique. Quand un système est plus facile à raisonner, les équipes passent moins de temps à circonscrire des incendies et plus de temps à construire.

• La correction réduit le coût des erreurs : moins d’incidents, moins de régressions, moins de code « n’y touchez pas ».
• La simplicité réduit le coût du changement : moins d’hypothèses cachées, moins de cas particuliers, moins de surprises en revue.

Ce que « monter en charge » signifie vraiment

Quand on dit qu’un logiciel doit « monter en charge », on parle souvent de performance. Le point de Dijkstra est différent : la complexité monte aussi.

La montée en charge se manifeste par :

• Plus de fonctionnalités : nouveaux flux, cas limites et attentes utilisateurs.
• Plus de personnes : transferts, styles variés et contextes différents.
• Plus d’intégrations : APIs externes, sources de données et modes de défaillance.
• Plus de temps : décisions héritées, exigences changeantes et réécritures partielles.

L’idée centrale : la structure rend le comportement plus prévisible

La programmation structurée n’est pas stricte pour elle-même. Il s’agit de choisir un flux de contrôle et une décomposition qui rendent facile de répondre à deux questions :

• « Que se passe-t-il ensuite ? »
• « Sous quelles conditions ? »

Quand le comportement est prévisible, changer devient une routine plutôt qu’un risque. Voilà pourquoi Dijkstra importe encore : sa discipline cible le vrai goulot d’un logiciel qui grandit — le comprendre suffisamment pour l’améliorer.

Une introduction simple à Edsger Dijkstra et à son objectif

Edsger W. Dijkstra (1930–2002) était un informaticien néerlandais qui a façonné la façon dont les programmeurs pensent la fiabilité logicielle. Il a travaillé sur des systèmes d’exploitation précoces, contribué à des algorithmes (dont l’algorithme du plus court chemin qui porte son nom) et — surtout pour les développeurs quotidiens — plaidé pour que la programmation soit quelque chose que l’on peut raisonner, et non juste quelque chose qu’on essaie jusqu’à ce que ça marche.

Son objectif central : raisonner plutôt que « ça marche sur ma machine »

Dijkstra se souciait moins qu’un programme produise la bonne sortie pour quelques exemples, et davantage que l’on puisse expliquer pourquoi il est correct pour les cas importants.

Si vous pouvez énoncer ce qu’un bout de code est censé faire, vous devriez pouvoir argumenter (pas à pas) qu’il le fait réellement. Cet état d’esprit mène naturellement à du code plus facile à suivre, à relire et moins dépendant d’un débogage héroïque.

Pourquoi il peut sembler strict — et en quoi cela aide

Certaines écrits de Dijkstra paraissent intransigeants. Il critiquait les astuces « intelligentes », les flux de contrôle négligés et les habitudes de codage qui rendent le raisonnement difficile. Cette sévérité n’est pas du règlement de style ; c’est une réduction de l’ambiguïté. Quand le sens du code est clair, on passe moins de temps à débattre des intentions et plus de temps à valider le comportement.

Ce que « programmation structurée » veut dire (haut niveau)

La programmation structurée consiste à construire des programmes à partir d’un petit ensemble de structures de contrôle claires — séquence, sélection (if/else) et itération (boucles) — au lieu de sauts emmêlés. Le but est simple : rendre le chemin à travers le programme compréhensible pour pouvoir l’expliquer, le maintenir et le modifier en confiance.

Correction : la fonctionnalité cachée sur laquelle vos utilisateurs comptent

La qualité logicielle se décrit souvent par « rapide », « beau » ou « riche en fonctionnalités ». Les utilisateurs vivent la correction différemment : comme l’assurance tranquille que l’application ne va pas les surprendre. Quand la correction est là, personne ne la remarque. Quand elle manque, tout le reste cesse d’avoir de l’importance.

« Ça marche maintenant » vs « ça continue de marcher »

« Ça marche maintenant » signifie souvent que vous avez essayé quelques chemins et obtenu le résultat attendu. « Ça continue de marcher » signifie que le comportement reste conforme aux intentions au fil du temps, des cas limites et des changements — après des refactors, de nouvelles intégrations, une montée en charge et de nouveaux membres d’équipe.

Une fonctionnalité peut « marcher maintenant » tout en étant fragile :

• Elle dépend d’entrées toujours propres.
• Elle suppose qu’un appel réseau renvoie vite.
• Elle passe des tests qui couvrent uniquement le happy path.

La correction consiste à supprimer ces hypothèses cachées — ou à les rendre explicites.

Comment de petits bugs se multiplient dans de grands systèmes

Un bug mineur reste rarement mineur quand le logiciel grandit. Un état incorrect, un décalage d’un indice ou une règle de gestion d’erreur floue se retrouve copié dans de nouveaux modules, enveloppé par d’autres services, mis en cache, relancé ou « contourné ». Avec le temps, les équipes arrêtent de se demander « qu’est‑ce qui est vrai ? » et se mettent à demander « qu’est‑ce qui arrive généralement ? ». C’est alors que la réponse aux incidents devient de l’archéologie.

Le multiplicateur, c’est la dépendance : un petit mauvais comportement devient de nombreux mauvais comportements en aval, chacun avec son correctif partiel.

La clarté est un outil de correction (pas seulement un choix stylistique)

Un code clair améliore la correction parce qu’il améliore la communication :

• Les revues de code détectent les vrais problèmes quand l’intention est évidente.
• L’intégration des nouveaux est plus rapide quand les règles sont lisibles, pas du savoir tribal.
• Les incidents se résolvent plus vite quand le flux de contrôle et les modes de défaillance sont faciles à tracer.

Une définition pratique de la correction pour les équipes produit

La correction signifie : pour les entrées et situations que nous affirmons supporter, le système produit de manière consistante les résultats promis — et échoue de façon prévisible et explicable quand il ne peut pas.

La simplicité comme stratégie, pas comme préférence de style

La simplicité n’est pas rendre le code « mignon », minimal ou astucieux. Il s’agit de rendre le comportement facile à prévoir, expliquer et modifier sans crainte. Dijkstra valorisait la simplicité parce qu’elle améliore notre capacité à raisonner sur les programmes — surtout lorsque la base de code et l’équipe grandissent.

Ce qu’est (et n’est pas) la simplicité

Un code simple maintient un petit nombre d’idées en action à la fois : flux de données clair, flux de contrôle clair et responsabilités nettes. Il n’oblige pas le lecteur à simuler de nombreux chemins alternatifs dans sa tête.

La simplicité n’est pas :

• moins de lignes à tout prix
• des astuces « smart », des one-liners denses ou des abstractions excessives
• éviter la structure pour paraître flexible

La complexité accidentelle : ce que vous n’aviez pas voulu ajouter

Beaucoup de systèmes deviennent difficiles à changer non pas parce que le domaine est intrinsèquement complexe, mais parce qu’on introduit de la complexité accidentelle : drapeaux qui interagissent de façon inattendue, correctifs de cas particulier qui ne partent jamais, couches existant surtout pour contourner des décisions antérieures.

Chaque exception supplémentaire est une taxe sur la compréhension. Le coût réapparaît plus tard, quand quelqu’un tente de corriger un bug et découvre qu’un changement dans une zone casse subtilement plusieurs autres.

Les designs simples réduisent le besoin d’héroïsme

Quand un design est simple, le progrès vient du travail régulier : changements relisables, diffs plus petits et moins de corrections d’urgence. Les équipes n’ont pas besoin de développeurs « héros » qui se souviennent de chaque cas historique ou qui déboguent sous pression à 2h du matin. Au lieu de cela, le système supporte l’attention humaine normale.

Règle pratique : moins de cas particuliers, moins de surprises

Un test pratique : si vous ajoutez sans cesse des exceptions (« sauf si… », « excepté quand… », « seulement pour ce client… »), vous accumulez probablement de la complexité accidentelle. Préférez des solutions qui réduisent le branching comportemental — une règle cohérente vaut mieux que cinq cas particuliers, même si la règle cohérente est un peu plus générale que votre première idée.

Programmation structurée : un flux de contrôle clair en qui vous pouvez avoir confiance

La programmation structurée est une idée simple aux grandes conséquences : écrivez du code de sorte que son chemin d’exécution soit facile à suivre. En termes simples, la plupart des programmes peuvent se construire avec trois blocs de base — séquence, sélection, répétition — sans s’appuyer sur des sauts emmêlés.

Les trois blocs de construction (en termes humains)

• Séquence : faire l’étape A, puis l’étape B, puis l’étape C.
• Sélection : choisir un chemin selon une condition (par ex. if/else, switch).
• Répétition : répéter un ensemble d’étapes tant qu’une condition est vraie (par ex. for, while).

Quand le flux de contrôle est composé de ces structures, on peut généralement expliquer ce que fait le programme en lisant de haut en bas, sans « téléporter » son attention autour du fichier.

Ce que cela a remplacé : des chemins d’exécution en spaghetti

Avant que la programmation structurée ne devienne la norme, beaucoup de bases de code s’appuyaient sur des sauts arbitraires (style goto). Le problème n’est pas que les sauts soient toujours mauvais ; c’est que le saut non restreint crée des chemins d’exécution difficiles à prédire. On finit par se demander « Comment en sommes-nous arrivés là ? » et « Quel est l’état de cette variable ? » — et le code n’y répond pas clairement.

Pourquoi la clarté importe pour des équipes réelles

Un flux de contrôle clair aide les humains à se construire un modèle mental correct. Ce modèle est ce sur quoi vous vous appuyez quand vous déboguez, relisez une PR ou changez un comportement sous pression.

Quand la structure est cohérente, la modification devient plus sûre : vous pouvez changer une branche sans affecter une autre ou refactorer une boucle sans manquer une sortie cachée. La lisibilité n’est pas que de l’esthétique — c’est la base pour modifier le comportement en confiance sans casser ce qui marche déjà.

Outils de raisonnement : invariants, préconditions et postconditions

Dijkstra défendait une idée simple : si vous pouvez expliquer pourquoi votre code est correct, vous pouvez le changer avec moins de crainte. Trois petits outils rendent cela pratique — sans transformer votre équipe en mathématiciens.

Invariants : « des faits qui demeurent vrais »

Un invariant est un fait qui reste vrai pendant l’exécution d’un morceau de code, surtout dans une boucle.

Exemple : vous faites la somme des prix d’un panier. Un invariant utile est : « total est la somme de tous les articles traités jusqu’ici. » Si cela reste vrai à chaque étape, alors quand la boucle se termine, le résultat est digne de confiance.

Les invariants sont puissants parce qu’ils focalisent l’attention sur ce qui ne doit jamais se casser, pas seulement sur ce qui devrait arriver ensuite.

Préconditions et postconditions : des contrats quotidiens

Une précondition est ce qui doit être vrai avant l’exécution d’une fonction. Une postcondition est ce que la fonction garantit après son exécution.

Exemples courants :

• Précondition : « Vous ne pouvez retirer de l’argent que si votre compte a suffisamment de fonds. »
• Postcondition : « Après le retrait, le solde est réduit de ce montant et ne devient jamais négatif. »

Dans le code, une précondition peut être « la liste d’entrées est triée », et la postcondition « la liste de sortie est triée et contient les mêmes éléments plus l’élément inséré ».

Comment les écrire change le codage et les revues

Quand vous les notez (même informellement), la conception devient plus nette : vous décidez ce qu’une fonction attend et ce qu’elle promet, et vous la rendez naturellement plus petite et plus ciblée.

En revue, la discussion se déplace du style (« je ferais autrement ») vers la correction (« ce code maintient-il l’invariant ? » « impose‑t‑on la précondition ou la documente‑t‑on ? »).

Pratique légère : commenter là où les bugs s’agglutinent

Vous n’avez pas besoin de preuves formelles pour en tirer profit. Choisissez la boucle la plus boguée ou la mise à jour d’état la plus délicate et ajoutez un invariant d’une ligne au-dessus. Lorsqu’on éditera le code plus tard, ce commentaire servira de garde‑fou : si un changement casse ce fait, le code n’est plus sûr.

Tests vs raisonnement : ce que chacun peut (ou ne peut pas) garantir

Tests et raisonnement visent le même résultat — un logiciel conforme aux attentes — mais ils opèrent différemment. Les tests découvrent les problèmes en essayant des exemples. Le raisonnement prévient des catégories entières de problèmes en rendant la logique explicite et vérifiable.

Ce que les tests font bien

Les tests sont un filet de sécurité pratique. Ils attrapent des régressions, vérifient des scénarios réels et documentent le comportement attendu de façon exécutable par toute l’équipe.

Mais les tests ne prouvent pas l’absence de bugs. Aucun jeu de tests ne couvre chaque entrée, chaque variation temporelle ou chaque interaction entre fonctionnalités. Beaucoup d’échecs « ça marche sur ma machine » viennent de combinaisons non testées : une entrée rare, un ordre précis d’opérations ou un état subtil n’apparaissant qu’après plusieurs étapes.

Ce que le raisonnement peut garantir (et ce qu’il ne peut pas)

Le raisonnement vise à prouver des propriétés du code : « cette boucle termine toujours », « cette variable n’est jamais négative », « cette fonction ne renvoie jamais d’objet invalide ». Bien fait, il exclut des classes entières de défauts — en particulier autour des frontières et des cas limites.

La limite est l’effort et la portée. Des preuves formelles pour un produit entier sont rarement économiquement viables. Le raisonnement est surtout utile de façon sélective : algorithmes centraux, flux sensibles à la sécurité, logique financière et concurrence.

Une approche équilibrée qui tient à l’échelle

Utilisez les tests largement et appliquez un raisonnement approfondi là où l’échec coûte cher.

Un pont pratique entre les deux est de rendre l’intention exécutable :

• Assertions pour les hypothèses internes (par ex. « l’indice est dans l’intervalle »).
• Préconditions et postconditions (contrats) pour les entrées/sorties des fonctions.
• Invariants pour des vérités persistantes (par ex. « le total du panier égale la somme des articles »).

Ces techniques ne remplacent pas les tests — elles resserrent le filet. Elles transforment des attentes vagues en règles vérifiables, rendant les bugs plus difficiles à écrire et plus faciles à diagnostiquer.

Discipline : comment les équipes évitent la « dette d’astuce »

Le code « malin » semble souvent gagner du temps sur le moment : moins de lignes, un tour astucieux, un one-liner qui flatte l’auteur. Le problème, c’est que l’astuce ne se scale pas dans le temps ni entre les personnes. Six mois plus tard, l’auteur oublie l’astuce. Un nouveau coéquipier la lit littéralement, ignore l’hypothèse cachée et la modifie d’une manière qui casse le comportement. C’est la « dette d’astuce » : de la vitesse à court terme payée par de la confusion à long terme.

La discipline accélère l’équipe

Le propos de Dijkstra n’était pas « écrivez du code ennuyeux » par goût — mais que des contraintes disciplinées rendent les programmes plus faciles à raisonner. Sur une équipe, les contraintes réduisent aussi la fatigue décisionnelle. Si tout le monde connaît déjà les choix par défaut (nomenclature, structure des fonctions, règle de gestion des erreurs), on cesse de rejouer les mêmes débats à chaque PR. Ce temps retourne au travail produit.

La discipline se voit dans des pratiques routinières :

• Revues de code qui récompensent la clarté plutôt que la nouveauté (« Quelqu’un d’autre peut-il modifier ceci en toute sécurité ? »).
• Standards partagés (formatage, noms, gestion des erreurs) pour que la base de code parle d’une seule voix.
• Refactoring comme maintenance, pas comme mission de sauvetage — petites améliorations continues.

À quoi ressemble la discipline dans le code

Quelques habitudes concrètes préviennent l’accumulation de dette d’astuce :

• Fonctions petites qui font un seul travail, avec des entrées et sorties évidentes.
• Noms clairs qui expriment l’intention (préférer calculate_total() à do_it()).
• Pas d’état caché : minimiser les globals et les effets de bord surprenants ; passer les dépendances explicitement.
• Flux de contrôle direct : éviter la logique reposant sur un ordre subtil, des valeurs magiques ou « ça marche si vous connaissez l’astuce ».

La discipline n’est pas la perfection — c’est rendre la prochaine modification prédictible.

Modularité et frontières : garder le changement local

La modularité n’est pas juste « séparer le code en fichiers ». C’est isoler des décisions derrière des frontières claires, pour que le reste du système n’ait pas à connaître (ou se soucier) des détails internes. Un module cache les parties sales — structures de données, cas limites, optimisations — tout en exposant une petite surface stable.

Comment les modules réduisent le rayon d’impact

Quand une demande de changement arrive, l’issue idéale est : un seul module change et tout le reste reste intact. C’est le sens pratique de « garder le changement local ». Les frontières empêchent le couplage accidentel — où la mise à jour d’une fonctionnalité casse silencieusement trois autres parce qu’elles partageaient des hypothèses.

Une bonne frontière rend aussi le raisonnement plus simple. Si vous pouvez énoncer ce qu’un module garantit, vous pouvez raisonner sur le programme plus large sans relire toute son implémentation à chaque fois.

Les interfaces comme promesses (et comment elles permettent le travail parallèle)

Une interface est une promesse : « Donnez ces entrées, je produirai ces sorties et maintiendrai ces règles. » Quand la promesse est claire, les équipes peuvent travailler en parallèle :

• Une personne implémente le module.
• Une autre construit un appelant en se basant sur l’interface.
• QA conçoit des tests autour du comportement promis.

Il ne s’agit pas de bureaucratie — mais de points de coordination sûrs dans une base de code qui grandit.

Vérifications simples de module qui évitent la dérive

Pas besoin de revue d’architecture monumentale pour améliorer la modularité. Essayez ces vérifications légères :

• Entrées/sorties : pouvez-vous lister les entrées, sorties et effets secondaires du module en quelques lignes ? Si non, il fait probablement trop de choses.
• Propriété : qui est responsable de son comportement et de ses changements ? Les modules sans propriétaire deviennent des dépotoirs.
• Dépendances : dépend‑il de « tout » ou seulement de ce dont il a vraiment besoin ? Moins de dépendances signifie moins de ruptures surprises.

Des frontières bien dessinées transforment le « changement » d’un événement système‑large en une modification localisée.

Pourquoi ces idées gagnent à l’échelle (équipes, bases de code et temps)

Quand le logiciel est petit, vous pouvez « tout garder en tête ». À l’échelle, ce n’est plus possible — et les modes d’échec deviennent familiers.

Les symptômes courants ressemblent à :

• Des incidents qui remontent à un coin surprenant du code
• Des sorties qui ralentissent parce que chaque changement semble risqué
• Des intégrations fragiles où une mise à jour mineure casse trois systèmes en aval

La structure réduit la charge cognitive

Le pari central de Dijkstra était que les humains sont le goulot. Un flux de contrôle clair, des unités petites et bien définies et du code sur lequel on peut raisonner ne sont pas des choix esthétiques — ce sont des multiplicateurs de capacité.

Dans une grande base de code, la structure agit comme une compression de la compréhension. Si les fonctions ont des entrées/sorties explicites, les modules des frontières nommables et le « happy path » n’est pas mélangé à tous les cas limites, les développeurs passent moins de temps à reconstituer l’intention et plus de temps à faire des changements délibérés.

Ça évolue avec les équipes, pas seulement avec le code

Quand les équipes grandissent, les coûts de communication augmentent plus vite que le nombre de lignes. Du code discipliné et lisible réduit la quantité de savoir tribal nécessaire pour contribuer en toute sécurité.

Cela se voit immédiatement dans l’onboarding : les nouveaux ingénieurs suivent des patterns prévisibles, apprennent un petit ensemble de conventions et font des modifications sans visite guidée des « pièges ». Le code lui‑même enseigne le système.

Les incidents deviennent plus simples à déboguer — et plus sûrs à annuler

Pendant un incident, le temps est rare et la confiance fragile. Le code écrit avec des hypothèses explicites (préconditions), des vérifications significatives et un flux de contrôle simple est plus facile à tracer sous pression.

Tout aussi important, les changements disciplinés sont plus faciles à revenir en arrière. Des éditions plus petites et localisées avec des frontières claires réduisent la probabilité qu’un rollback déclenche de nouvelles défaillances. Le résultat n’est pas la perfection — c’est moins de surprises, une récupération plus rapide et un système qui reste maintenable au fil des années et des contributeurs.