Von Neumann et l'ordinateur à programme stocké qui a rendu le logiciel possible

Pourquoi l'idée du programme stocké est importante

Au cœur de l'informatique moderne se trouve une question simple : qu'est-ce qui a rendu possible qu'une même machine réalise bien des tâches différentes sans être reconstruite à chaque fois ? Les premiers ordinateurs électroniques calculaient vite, mais « changer de mission » signifiait souvent modifier physiquement la configuration de la machine. L'idée du programme stocké est le tournant qui a rendu les ordinateurs vraiment programmables.

Le programme stocké, en termes simples

Un ordinateur à programme stocké conserve les instructions d'une tâche (le programme) dans le même type de mémoire interne que les données sur lesquelles le programme travaille. Au lieu de recâbler le matériel ou de reconfigurer manuellement des panneaux, on peut charger un nouvel ensemble d'instructions en mémoire et lancer un travail différent.

Cela paraît évident aujourd'hui, mais c'est un changement profond :

• L'ordinateur devient un outil polyvalent, pas une machine à usage unique.
• Les programmes deviennent des informations : quelque chose qu'on peut éditer, sauvegarder, copier et partager.
• Le développement logiciel devient une activité pratique : écrire, tester et améliorer des instructions sans reconstruire la machine.

Ce que couvrira cet article (et pourquoi c'est toujours pertinent)

Ce n'est pas qu'une curiosité historique. Le concept du programme stocké explique pourquoi le « logiciel » existe séparément du « matériel », et pourquoi mettre à jour un appareil aujourd'hui peut débloquer de nouvelles fonctions sans changer les puces à l'intérieur.

Dans les sections suivantes, nous reviendrons sur le problème auquel faisaient face les premiers ordinateurs, ce que le programme stocké a changé, les personnes et documents qui ont clarifié l'idée (y compris le célèbre rapport EDVAC), et comment le terme « architecture de von Neumann » en est venu à représenter un modèle largement utilisé.

Une rapide précision sur les crédits

Bien que le nom de John von Neumann soit fortement associé au programme stocké, le mérite est partagé au sein d'une équipe et d'une époque plus larges. De nombreux chercheurs convergeaient vers des idées similaires en construisant les premiers ordinateurs électroniques. Cet article garde ce contexte en vue, car comprendre l'effort collectif aide à expliquer comment l'idée s'est rapidement diffusée et est devenue le modèle par défaut pour la plupart des ordinateurs qui ont suivi.

Avant les programmes stockés : quand changer de tâche signifiait recâbler

Avant l'idée du programme stocké, beaucoup de premiers ordinateurs ne « lançaient pas de logiciels » au sens actuel. Ils pouvaient calculer à des vitesses impressionnantes, mais indiquer quoi faire signifiait souvent modifier physiquement la machine elle‑même.

Le « programmation matérielle » en pratique

Une approche courante consistait à utiliser des tableaux de connexions, des câbles de liaison et des panneaux à interrupteurs. Les opérateurs reliaient des prises entre elles, positionnaient des rangées d'interrupteurs et ajustaient parfois des unités de synchronisation pour que les signaux arrivent dans le bon ordre. Le « programme » n'était pas un fichier qu'on chargeait : c'était un schéma de câblage temporaire.

Ce montage fonctionnait, mais il avait un coût caché : chaque nouvelle tâche devenait un mini projet d'ingénierie. Si vous vouliez changer la séquence d'opérations (additionner, multiplier, comparer, boucler), vous auriez pu devoir déplacer des dizaines ou des centaines de connexions. Un seul câble mal placé pouvait créer des erreurs subtiles difficiles à diagnostiquer, parce que la logique était répartie dans les connexions matérielles plutôt qu'écrite sous forme d'étapes lisibles.

Pourquoi changer de tâche était coûteux

La reconfiguration pouvait prendre des heures voire des jours, surtout si la machine devait être soigneusement mise hors tension, recâblée et testée. Cela signifiait une flexibilité limitée : ces machines étaient souvent planifiées pour un type de calcul sur de longues périodes parce que changer de travail était trop perturbant.

Un exemple simple

Imaginez une machine configurée pour calculer des tables de tir d'artillerie : des calculs longs et répétitifs avec une formule fixe. Si des chercheurs voulaient ensuite que la même machine résolve un problème différent, comme compiler des résultats statistiques pour un recensement, ce n'était pas un simple « modifier le programme et relancer ». L'ordre d'opérations, les étapes de stockage intermédiaire et les contrôles conditionnels pouvaient tous différer, nécessitant une refonte complète du tableau de connexions et une nouvelle vérification.

C'est ce monde que l'ordinateur à programme stocké était conçu pour dépasser.

L'ordinateur à programme stocké, expliqué simplement

Un ordinateur à programme stocké est une machine où les instructions (le programme) vivent dans la même mémoire de travail que les données utilisées par le programme. Autrement dit, l'ordinateur ne considère pas « ce qu'il faut faire » comme distinct de « sur quoi il faut travailler » : les deux sont stockés comme des motifs de bits en mémoire.

Ce que « mémoire » signifie ici

Quand les pionniers de l'informatique parlaient de mémoire, ils entendaient le stockage interne rapide et directement utilisable de l'ordinateur — ce qu'on associerait aujourd'hui le plus à la RAM. C'est l'endroit où le processeur peut lire et écrire rapidement pendant l'exécution.

C'est différent du stockage à long terme comme un disque dur ou un SSD. Un disque est excellent pour conserver des fichiers hors tension, mais ce n'est pas le cahier de brouillon immédiat que le processeur utilise en permanence pour chercher la prochaine instruction et mettre à jour des résultats intermédiaires.

La conséquence clé : changer la tâche sans changer la machine

Une fois les instructions stockées en mémoire, changer de tâche devient beaucoup plus simple : vous pouvez charger un nouveau programme en mémoire et l'exécuter, sans reconstruire, recâbler ou reconfigurer physiquement le matériel. La même machine polyvalente peut faire la paie le matin et des calculs balistiques l'après‑midi — parce que le « comment » du travail n'est qu'un autre ensemble de bits que l'on peut remplacer.

Une analogie de tous les jours

Imaginez une cuisine où la recette et les ingrédients sont rangés ensemble dans le même garde‑manger. Le cuisinier (le processeur) va régulièrement au garde‑manger (la mémoire) pour lire l'étape suivante de la recette (l'instruction) et prendre ou mettre à jour des ingrédients (les données).

Vous voulez préparer un plat différent ? Vous ne rénovez pas la cuisine. Vous changez juste de recette — tout en utilisant les mêmes plans de travail, le même four et les mêmes outils.

Le rôle de John von Neumann (et pourquoi son nom est resté)

John von Neumann n'a pas « inventé l'ordinateur », et il n'a pas créé seul l'idée du programme stocké. Ce qu'il a fait — brillamment — fut d'aider à transformer un concept prometteur en une conception clairement formulée et largement diffusée que d'autres ingénieurs et laboratoires pouvaient reprendre.

Un contributeur majeur — et un communicateur hors pair

Von Neumann a été profondément impliqué dans des projets informatiques de guerre et d'après‑guerre, conseillant des équipes et affinant la structure logique des premiers designs. Il avait le don d'expliquer des choix techniques complexes de manière claire et organisée, ce qui importait parce que l'informatique électronique évoluait rapidement, et plusieurs groupes résolvaient des problèmes similaires en parallèle.

Tout aussi important, il a rédigé et diffusé des descriptions influentes de la façon dont un ordinateur pouvait stocker les instructions de programme dans la même mémoire que les données. Ce cadrage clair a facilité la discussion, l'enseignement et la reproduction de l'approche par d'autres.

Pourquoi son nom s'est attaché à l'architecture

Les noms restent souvent attachés non pas à la première personne ayant eu l'idée, mais à celle dont la description devient le point de référence. Les écrits de von Neumann ont été largement lus, copiés et cités : les lecteurs ultérieurs ont donc naturellement associé l'organisation « programme stocké » à son nom.

Cette appellation simplifie aussi l'histoire : il est plus facile de dire « architecture de von Neumann » que d'énumérer tous les contributeurs et rapports. Mais cette abréviation peut estomper ce qui s'est réellement passé.

Un effort collectif, pas une percée solitaire

L'informatique électronique naissante était un effort collaboratif et inter‑institutions impliquant mathématiciens, ingénieurs et premiers programmeurs. Le concept du programme stocké a mûri à travers des discussions, des brouillons, des prototypes et des révisions entre équipes. Le rôle durable de von Neumann fut d'aider à cristalliser et diffuser l'idée — accélérant ainsi son adoption — plutôt que de la créer seul.

Le rapport EDVAC et une formulation claire du concept

EDVAC (Electronic Discrete Variable Automatic Computer) fut l'un des projets informatiques d'après‑guerre visant à dépasser les machines « une seule fois ». Tout aussi important que l'effort matériel fut la décision de consigner les idées de conception dans un document clair et partageable. À l'époque, la construction d'ordinateurs était encore proche de l'ingénierie expérimentale : le savoir vivait dans des carnets de laboratoire, des réunions et la tête de quelques spécialistes. Un rapport pouvait transformer ces intuitions dispersées en quelque chose que d'autres équipes pouvaient discuter, critiquer et réutiliser.

Ce que disait le rapport EDVAC — sans la mathématique

Le First Draft of a Report on the EDVAC (souvent appelé « rapport EDVAC ») exposait, en termes conceptuels accessibles, l'idée du programme stocké : un ordinateur doit conserver les instructions de programme dans le même type de mémoire interne que les données. Cette mémoire n'est pas seulement un endroit pour garder des nombres pendant un calcul : elle contient aussi les étapes indiquant à la machine quoi faire ensuite.

Ce cadrage fait de l'ordinateur moins un dispositif à objet fixe et davantage une machine générale qu'on peut « reconfigurer » en changeant ce qui est en mémoire. On ne recâble pas le système pour passer d'une tâche à une autre : on charge une séquence différente d'instructions.

Pourquoi ça a compté pour tout le monde

Au‑delà du concept lui‑même, le rapport a aidé à normaliser la façon dont on parlait des ordinateurs : mémoire, contrôle, arithmétique et entrée/sortie comme parties fonctionnelles distinctes travaillant ensemble. Disposer d'un vocabulaire partagé et d'une description largement diffusée n'a pas seulement expliqué EDVAC : cela a donné au domaine un modèle mental commun pour construire, comparer et améliorer les ordinateurs à programme stocké.

Crédits partagés : l'équipe derrière la pensée des premiers programmes stockés

Il est tentant de demander « qui a inventé l'ordinateur à programme stocké ? » en attendant un seul nom. Mais la science et l'ingénierie fonctionnent rarement ainsi. Les idées se développent souvent en parallèle, se précisent par la discussion, et ne deviennent convaincantes qu'une fois démontrées dans du matériel fonctionnel.

Collaborateurs clés et efforts parallèles

Le nom de John von Neumann est fortement associé au concept du programme stocké, mais les travaux initiaux impliquaient de nombreuses personnes et groupes :

• J. Presper Eckert et John Mauchly (travail ENIAC/EDVAC) : au cœur de la poussée d'ingénierie vers des ordinateurs électroniques pratiques et des améliorations de conception.
• Herman Goldstine : organisateur crucial et pont entre mathématiciens et ingénieurs, joua un rôle clé dans la documentation et la diffusion des idées.
• Arthur Burks : contribua à la conception logique initiale et aux récits ultérieurs de la formalisation de ces architectures.
• Alan Turing : rédigea des réflexions influentes, antérieures à EDVAC, sur la computation à usage général et les machines contrôlées par programme.
• Maurice Wilkes (EDSAC) et Frederic Williams & Tom Kilburn (Manchester) : aidèrent à démontrer que les systèmes à programme stocké pouvaient effectivement fonctionner, avec des démonstrations pratiques et des avancées en mémoire.

Pourquoi la question « qui l'a inventé » est compliquée

Un ordinateur à programme stocké n'est pas une seule idée isolée. Il combine (1) le saut conceptuel que les instructions peuvent habiter la mémoire comme les données, (2) l'ingénierie nécessaire pour construire des mémoires et unités de contrôle fiables, et (3) les pratiques de programmation qui rendent le design utilisable. Différentes personnes ont contribué à différentes pièces.

Proposer vs construire

Autre raison du partage du crédit : proposer une idée n'est pas la même chose que construire une machine qui fonctionne quotidiennement. Les rapports et discussions initiaux ont clarifié le concept ; les prototypes et systèmes de production ont prouvé sa faisabilité. Une histoire équilibrée respecte ces deux types de contributions, sans forcer un verdict simpliste du « premier inventeur ».

Ce que signifie généralement « architecture de von Neumann »

Quand on dit « architecture de von Neumann », on fait généralement référence à un modèle simple et largement enseigné de l'organisation d'un ordinateur à programme stocké. Ce n'est pas une marque ni une machine historique unique : c'est une étiquette commode pour un plan de base qui réapparaît, sous une forme ou une autre, sur de nombreux ordinateurs.

Le diagramme bloc courant : CPU, mémoire et entrée/sortie

Au niveau conceptuel, le schéma ressemble à :

• CPU (unité centrale de traitement) : le « travailleur » qui effectue les opérations.
• Mémoire : l'endroit où l'ordinateur garde à la fois les instructions de programme et les données utilisées.
• Entrée/Sortie (I/O) : moyens d'entrer et de sortir l'information : claviers, disques, écrans, réseaux, capteurs, etc.

L'idée clé est que la CPU n'a pas de lieu physique séparé pour « le programme » et « les nombres ». Elle puise tout ce dont elle a besoin depuis la mémoire.

Comment les instructions circulent : récupérer–décoder–exécuter

La CPU exécute un programme en répétant une boucle souvent décrite comme récupérer–décoder–exécuter :

1. Récupérer : lire la prochaine instruction en mémoire.
2. Décoder : interpréter ce que demande l'instruction (additionner, comparer, charger, stocker, sauter…).
3. Exécuter : réaliser l'action, qui peut impliquer la lecture/écriture en mémoire ou l'interaction avec l'I/O.

Cette description est simplifiée, mais elle capture l'essentiel : le programme est une séquence d'instructions stockées en mémoire, et la CPU les parcourt.

Pourquoi « instructions et données dans la même mémoire » est puissant

Mettre instructions et données dans la même mémoire rend un ordinateur généraliste de manière très pratique :

• Pour changer le comportement, on change généralement le programme en mémoire, pas le câblage.
• Les programmes peuvent traiter des instructions comme de l'information : les copier, les charger, les modifier (même si les systèmes modernes restreignent souvent cela pour des raisons de sécurité).
• Il devient plus facile de construire des outils comme assembleurs, compilateurs et systèmes d'exploitation, parce qu'« un programme » est juste une autre forme d'information stockée.

Une étiquette commode, pas une revendication d'invention unique

Donc, « architecture de von Neumann » est mieux comprise comme un raccourci pour le modèle du programme stocké avec une CPU, une mémoire partagée contenant instructions et données, et une I/O : une idée fortement associée aux explications claires de von Neumann, bien que l'histoire initiale ait impliqué plusieurs contributeurs.

Von Neumann vs Harvard : deux façons d'organiser instructions et données

On parle souvent de « von Neumann » et « Harvard » comme si c'étaient des philosophies opposées. Ce sont en réalité deux manières pratiques d'organiser instructions de programme et données pour que l'ordinateur puisse les récupérer.

Style von Neumann : une mémoire, une voie partagée

Dans une conception de type von Neumann, instructions et données résident dans la même mémoire et circulent souvent sur la même voie principale vers la CPU.

C'est conceptuellement simple : un programme est juste des octets en mémoire, à côté des nombres, textes et images sur lesquels il travaille. Cela facilite aussi l'informatique polyvalente : le logiciel se charge, se modifie et se stocke avec les mêmes mécanismes que les données.

L'inconvénient : lorsque instructions et données partagent la même « route », elles peuvent se concurrencer pour la bande passante. (On parle parfois de « goulot d'étranglement », l'idée clé étant le partage.)

Style Harvard : stockage séparé (et souvent voies séparées)

Une approche Harvard garde le stockage des instructions séparé du stockage des données, souvent avec des voies distinctes pour récupérer chacun.

Cette séparation peut faciliter la récupération simultanée de la prochaine instruction tout en lisant ou écrivant des données — utile dans des systèmes petits et prévisibles. Un exemple simple est de nombreux microcontrôleurs, où le code du programme peut résider en mémoire flash tandis que les variables vivent en RAM.

Pourquoi de nombreux systèmes réels mélangent les deux

Les CPU modernes apparaissent souvent comme « von Neumann » du point de vue logiciel (un espace d'adressage, un modèle de programme), tout en empruntant des idées Harvard en interne. Exemple courant : caches séparés pour instructions et données (I‑cache et D‑cache). Pour votre programme, cela ressemble toujours à une seule mémoire, mais le matériel peut récupérer code et données plus efficacement.

À retenir : il n'y a pas de gagnant universel. Von Neumann privilégie la simplicité et la flexibilité ; Harvard privilégie la séparation et le débit. Beaucoup de machines mélangent les deux pour trouver un compromis entre programmabilité, coût, consommation et performance.

Comment les programmes stockés ont rendu la programmation moderne possible

Un ordinateur à programme stocké ne se contente pas de lancer des calculs : il peut charger un ensemble d'instructions depuis la mémoire, les exécuter, puis charger un autre ensemble plus tard. Ce changement a rendu le logiciel réutilisable et partageable : un programme pouvait être écrit une fois, sauvegardé, copié, amélioré et distribué sans toucher au matériel.

De « cette machine » à « n'importe quelle tâche »

Quand le programme vit en mémoire, la même machine physique peut accomplir de nombreuses tâches simplement en échangeant les instructions qu'elle lit. C'est ce que signifie vraiment « polyvalent » : une machine, plusieurs programmes. L'ordinateur n'est plus défini par un seul flux de travail ; il devient une plateforme.

Un exemple moderne parlant est votre ordinateur portable qui exécute un client mail, des jeux et un tableur. Au fond, c'est la même idée : le matériel reste identique tandis que différents programmes stockés sont chargés et exécutés lorsque vous changez d'application.

Pourquoi cela a permis de vrais outils de programmation

Une fois que les instructions sont traitées comme des données en mémoire, il devient pratique de construire des couches logicielles qui aident à écrire du logiciel :

• Assembleurs : permettent d'écrire des mnémoniques plus lisibles que des codes numériques bruts.
• Compilateurs : traduisent des langages de niveau supérieur en instructions machines, rendant les programmes plus faciles à écrire et maintenir.
• Systèmes d'exploitation : gèrent le chargement des programmes, le partage de la mémoire et des périphériques, et l'ordonnancement pour que plusieurs programmes s'exécutent harmonieusement.

Ces outils reposent sur l'hypothèse que les programmes peuvent être stockés, déplacés et manipulés comme les autres informations. C'est ce qui a transformé le logiciel en un écosystème plutôt qu'en un artefact unique lié à un câblage particulier.

Une façon utile de voir l'arc historique : les programmes stockés ont rendu possibles compilateurs et OS, qui ont permis des outils de développement modernes — et aujourd'hui nous voyons une autre couche d'abstraction où l'on peut décrire une application en langage naturel et laisser des outils générer du code exécutable. Par exemple, Koder.ai est une plateforme de vibe‑coding où l'on construit des applications web, backend ou mobiles via une interface conversationnelle, s'appuyant sur des LLM et un flux de travail agent‑basé pour accélérer le passage de l'intention (« que doit‑elle faire ? ») aux instructions exécutables (du code source que l'on peut exporter, déployer et restaurer via des instantanés).

Le résultat reste le même cycle vertueux : les programmes stockés ont permis de meilleurs outils, et de meilleurs outils ont permis des programmes plus ambitieux — transformant les ordinateurs en machines polyvalentes.

La limitation célèbre : le « goulet d'étranglement de von Neumann »

L'idée du programme stocké a rendu les ordinateurs flexibles, mais elle a aussi mis en lumière une contrainte pratique dont les ingénieurs parlent encore : le « goulet d'étranglement de von Neumann ». En termes courants, c'est comme un embouteillage sur la route entre la CPU (le travailleur) et la mémoire (l'entrepôt).

Un embouteillage entre CPU et mémoire

Dans un design typique à programme stocké, instructions et données vivent en mémoire. La CPU récupère une instruction, puis récupère les données nécessaires, puis écrit les résultats — souvent via la même connexion. Si cette connexion ne peut pas acheminer l'information assez rapidement, la CPU se retrouve à attendre alors qu'elle pourrait autrement calculer plus vite.

Pourquoi la vitesse et la bande passante comptent

Deux facteurs liés façonnent ce goulet d'étranglement :

• Latence mémoire (vitesse) : le temps nécessaire pour obtenir le premier morceau d'information après en avoir fait la demande.
• Bande passante mémoire : la quantité d'information pouvant être transférée par seconde une fois que les transferts sont lancés.

Un processeur peut exécuter des milliards d'opérations par seconde, mais si la mémoire ne fournit pas un flux soutenu d'instructions et de données, la performance est limitée par l'étape la plus lente : récupérer les octets.

Atténuations courantes (pas des solutions magiques)

C'est une préoccupation d'ingénierie largement discutée, et les ordinateurs modernes utilisent plusieurs techniques pour réduire l'impact :

• Caches : petites mémoires rapides proches du processeur qui conservent les instructions/données récemment utilisées.
• Préchargement (prefetching) : deviner ce qui sera nécessaire ensuite et le charger à l'avance.
• Parallélisme : faire plusieurs choses en même temps (cœurs multiples, chevauchement des accès mémoire et du calcul).

Ces approches n'éliminent pas la « route » sous‑jacente, mais elles aident à la désengorger — pour que la CPU passe plus de temps à travailler et moins de temps à attendre.

Où vous voyez l'idée dans les ordinateurs que vous utilisez aujourd'hui

Le concept du programme stocké n'est pas une pièce de musée : c'est la façon dont l'informatique quotidienne reste flexible. Vos appareils n'ont pas besoin d'être « recâblés » pour faire quelque chose de nouveau ; ils chargent simplement des instructions différentes en mémoire et les exécutent.

Téléphones, portables et serveurs : même astuce de base

Sur un téléphone, taper une icône d'application fait que le système d'exploitation charge le code de l'application (les instructions) depuis le stockage vers la mémoire, puis la CPU l'exécute. Sur un portable, la même chose se produit quand vous ouvrez un navigateur, éditez un document ou lancez un jeu. Dans les serveurs, c'est encore plus visible : la machine peut exécuter des milliers de charges de travail changeantes — requêtes web, requêtes de base de données, tâches en arrière‑plan — sans changer le matériel du tout.

Même des fonctionnalités que l'on considère comme « matérielles » sont souvent définies par logiciel. Routage réseau, chemins de décodage vidéo, amélioration photo et politiques de gestion d'énergie sont fréquemment mis à jour via le firmware et le logiciel système : nouvelles instructions, même appareil.

Interpréteurs et machines virtuelles exécutent aussi des instructions stockées

Des langages comme Python et JavaScript fonctionnent en général via un interprète ou une machine virtuelle. Au lieu que la CPU exécute directement votre code source, votre programme est traduit en une forme structurée (bytecode ou instructions internes) qui est stockée en mémoire et exécutée pas à pas. La JVM de Java, .NET, les runtime WebAssembly et les moteurs JavaScript des navigateurs reposent tous sur ce principe : des instructions deviennent des structures de données que la machine peut charger, déplacer et exécuter.

Une note de sécurité : quand les données deviennent instructions

Parce que les instructions ne sont que des informations, des attaques tentent souvent d'introduire du code malveillant via des données — injections de code classiques. Des défenses comme la protection mémoire, la signature de code et des régions non exécutables existent pour empêcher que des données non fiables soient traitées comme des instructions exécutables.

Tout cela revient à la promesse centrale des programmes stockés : la flexibilité par le logiciel — un nouveau comportement sur le même matériel.

Principaux points à retenir et lectures suggérées

Points clés

• Un ordinateur à programme stocké conserve les instructions de programme dans le même type de mémoire lecture/écriture que les données, de sorte qu'on change ce que la machine fait en changeant la mémoire — pas en recâblant le matériel.
• Le label « architecture de von Neumann » désigne généralement une organisation pratique (CPU + mémoire + entrée/sortie) où instructions et données partagent des voies, et non une affirmation selon laquelle une seule personne a tout inventé.
• La réflexion initiale sur les programmes stockés fut un travail d'équipe : les discussions autour d'EDVAC et le rapport ont aidé à formuler clairement l'idée, et plusieurs projets ont montré comment la construire et l'exploiter de façon fiable.
• Les programmes stockés ont rendu la programmation moderne possible parce qu'ils supportent le code réutilisable, les bibliothèques, les compilateurs et les systèmes d'exploitation, tous fondés sur l'hypothèse que le logiciel est une donnée que la machine peut charger et exécuter.

Questions rapides pour reconnaître une architecture

Quand vous regardez un ordinateur (ou lisez une spécification), ces questions vous aident à repérer le modèle de base :

• Où sont stockées les instructions à l'exécution : dans la même mémoire que les données ou dans une mémoire séparée ?
• Les instructions et les données circulent‑elles sur la même voie/bus, ou y a‑t‑il des chemins séparés (comme souvent en Harvard) ?
• Le système peut‑il modifier ou générer du code puis l'exécuter (capacité classique d'un système à programme stocké), ou le stockage du code est‑il fixe/isolé ?
• La « mémoire programme » est‑elle décrite comme flash/ROM tandis que la « mémoire données » est RAM (indice d'une séparation de type Harvard dans de nombreux microcontrôleurs) ?

Lectures suggérées

• Livres : The Computer from Pascal to von Neumann (Herman H. Goldstine) ; enquêtes générales d'histoire de l'informatique couvrant ENIAC/EDVAC/IAS.
• Musées : Computer History Museum ; Science Museum (collections informatiques) ; Smithsonian (histoire de la technologie).
• Archives et revues : articles d'histoire IEEE et ACM (y compris des histoires orales), et collections universitaires spécialisées qui hébergent des papiers sur l'informatique ancienne.

Si vous voulez d'autres articles accessibles comme celui‑ci, parcourez /blog.

Remarque : si vous expérimentez des façons modernes de transformer des « instructions » en systèmes exécutables — que ce soit en écrivant du code directement ou en utilisant des plateformes conversationnelles de build comme Koder.ai — pensez à documenter ce que vous apprenez. Koder.ai propose aussi un programme de crédit pour le contenu publié et les parrainages, ce qui peut être un moyen pratique de financer davantage d'expériences et de tutoriels.