Histoire de l’informatique et projet transversal : enquêter, relier, construire et prouver

Une frise n’est pas encore une explication. Pour chaque ligne, demande quel est l’objet, qui produit la trace, quelle date porte-t-elle et quelle conclusion autorise-t-elle. « 1936 : Turing » ne suffit pas. Dans le programme de Terminale, l’article de 1936 sert à situer un modèle théorique de calcul. Il ne prouve ni qu’une machine identique est alors construite, ni que toute l’informatique découle d’un seul texte.

Le Manchester Baby fournit une trace différente. La notice de conservation consultée date au 21 juin 1948 l’exécution d’un programme par cette machine expérimentale. Cette source répond à une question précise : une machine à programme enregistré a-t-elle exécuté un programme à cette date ? Elle ne permet pas de transformer cette machine en origine unique de tous les ordinateurs ni d’effacer les autres projets.

Écris une affirmation atomique : « La notice consultée attribue au Baby l’exécution d’un programme le 21 juin 1948. » Attache une URL, une date d’accès, le type de document et une portée. Une phrase telle que « le programme enregistré a remplacé les circuits » mélange au contraire une comparaison technique, une histoire longue et un jugement sans source unique. Les mots « premier », « inventeur » et « a rendu possible » exigent une vigilance accrue.

Le laboratoire n’authentifie pas une archive : il vérifie seulement la forme d’un registre fictif. Une entrée comporte une revendication, un objet, une date ISO, une URL HTTPS et une portée. Les doublons deviennent des alertes au lieu d’écraser une entrée ; une référence absente n’est jamais inventée. Les booléens sont refusés quand le contrat demande un entier strict.

Les autres chapitres de NSI donnent les outils de cette enquête : algorithmique pour traiter une liste, structures pour organiser le registre, bases de données pour les contraintes, réseaux pour l’URL, langages pour exécuter le contrôle. Aucune de ces opérations ne décide de la vérité historique. Elles rendent seulement le raisonnement vérifiable et obligent à nommer les lacunes du dossier.

Un circuit câblé réalise une fonction par ses connexions : changer la fonction impose de modifier le dispositif. Une machine à programme enregistré place instructions et données dans une mémoire lue par le processeur. Le programme n’est pas une explication complète : il faut encore du matériel, un jeu d’instructions et une convention de lecture. La distinction utile est la possibilité de changer une suite d’instructions sans recâbler chaque opération.

La démonstration du Baby en 1948 est un repère historique situé. Elle ne signifie pas que toutes les machines sont identiques, ni que les circuits cessent d’exister. Une architecture combine composants, mémoire, entrées-sorties et logiciels. L’histoire est donc une coévolution : les composants ouvrent certaines réalisations ; les logiciels organisent des opérations et créent de nouveaux besoins matériels.

Le schéma suit un pas de mini-machine fictive. Une case contient ADD 3, une autre le nombre 7 ; le compteur lit l’instruction, l’adresse mène à la donnée et l’accumulateur passe de 5 à 12. Cette géométrie montre que la mémoire contient ici un encodage d’instruction et une donnée. Ce n’est ni une photographie du Baby ni la description entière d’un processeur réel.

Le modèle est fermé : mémoire de trois à huit cases, entiers stricts et une instruction ADD observée. Il valide la forme avant de calculer afin qu’un booléen, une adresse négative ou une instruction inconnue ne deviennent pas un résultat vraisemblable. Il rend un instantané sous forme de tuple : une mutation de la liste d’appel ne change pas la trace déjà produite.

Architecture, algorithmique et langages apportent chacun une vue : composants, procédure et notation. L’histoire relie ces objets sans les ordonner en un progrès automatique. Dis toujours si tu décris un mécanisme du modèle, une propriété du document ou une hypothèse sur le changement technique.

Un fichier aligne des enregistrements selon une convention. Un modèle relationnel organise relations, attributs et contraintes pour raisonner sur des données partagées. L’article de Codd publié en juin 1970 est une proposition de modèle : cite-le comme telle. Il ne date pas l’usage de chaque SGBD et ne transforme pas un dictionnaire Python en base de données.

Notre modèle possède une liste d’affirmations et une liste de sources. La fonction vérifie d’abord les clés et construit ensuite une jointure locale. Cette opération est utile pour faire voir identifiant, référence et contrainte d’unicité. Un SGBD ajoute toutefois stockage durable, requêtes, concurrence, journalisation et reprise selon son implantation.

Ici, la fonction valide les deux listes avant de construire son tuple de résultat local. Si une référence est inconnue, elle lève une erreur et ne renvoie pas une jointure partielle. Ce choix rend le contrat lisible, mais ne modélise ni transaction, ni atomicité de SGBD, ni verrouillage concurrent, ni journalisation, ni reprise après panne.

Deux affirmations de même id ne doivent pas être remplacées par la dernière. Une clé étrangère inconnue ne devient pas une chaîne vide. True n’est pas l’identifiant 1 dans ce contrat, même si Python traite souvent le booléen comme entier. Ces cas frontières départagent une fonction qui conserve les contraintes d’une fonction qui produit une réponse apparemment plausible.

Les cours de structures et bases de données donnent les outils de liste, clé, dictionnaire, jointure et contrainte. L’histoire pose une question supplémentaire : quel problème un texte cherchait-il à formuler ? Relier un extrait, un mécanisme et une limite vaut mieux qu’une chronologie de mots-clés.

Internet et Web ne désignent pas le même objet. Internet relie des réseaux par des protocoles ; le Web relie des ressources par identifiants, protocole de transfert et documents hypertextes au-dessus de réseaux existants. Le document RFC 1 porte la date du 7 avril 1969 et le titre Host Software. Son existence renseigne un document de travail du réseau ARPA ; elle ne suffit pas à établir une adoption immédiate par tous les hôtes.

La proposition de Tim Berners-Lee est intitulée Information Management: A Proposal, attribuée au CERN et datée de mars 1989, avec une date de mai 1990 dans la version consultée. Lis le mot proposal : le document cherche une solution à un problème de circulation de l’information. La page explique que le nom World Wide Web est choisi lors de l’écriture du code en 1990. Proposition, version du texte et logiciels sont donc des repères différents.

Un protocole est un contrat de communication, pas une date décorative. Le laboratoire réduit une négociation à des entiers positifs : il prend la plus haute version commune au-dessus d’un minimum. Le modèle n’est ni TLS, ni HTTP, ni une preuve de sécurité. Il rend visibles seulement une intersection, une politique minimale et un refus explicite.

Les frontières évitent les conclusions faciles : True n’est pas une version ; une liste vide ne doit pas provoquer max sur un ensemble vide ; un seuil supérieur aux versions communes donne None. La trace décrit les candidats du modèle. Elle ne démontre pas qu’un protocole réel a été déployé, ce qui demanderait d’autres documents ou observations.

Réseaux, architecture et langages se rejoignent : définir un format, l’implémenter et le tester. L’histoire ajoute contexte et prudence. Écris « ce document propose », « ce modèle calcule » ou « cette source rapporte », sans laisser croire qu’une date prouve adoption, sécurité ou causalité globale.

Lecture guidée. Ouvre la proposition conservée par le W3C et lis son en-tête : « Information Management: A Proposal », « Tim Berners-Lee, CERN », puis les repères « March 1989 » et « May 1990 ». Question : que permet d’affirmer le repère de mai ? Correction : la page consultée présente une version du texte rediffusée en mai 1990 ; ce repère ne prouve pas à lui seul un déploiement du Web.

Un logiciel durable rassemble conception, programmation, test, exploitation, documentation, traduction, maintenance et gouvernance. Ces rôles ne se déduisent pas d’un seul nom visible. Une archive peut mieux conserver le code que les essais, manuels ou tâches d’opération. L’enquête commence donc par les traces disponibles et leurs lacunes.

Dans un dossier complet, une contribution relie une personne ou un collectif, un rôle, un objet, une période et une référence. Le laboratoire se borne volontairement au sous-contrat personne_id, rôle, objet et reference : il ne prétend donc pas dater une contribution. Ne transforme pas l’absence de référence en absence de travail : écris plutôt « rôle non attribué par les documents consultés ». Cette formule évite de qualifier sans cas sourcé un travail de féminin, subalterne ou invisible, tout en gardant ouverte la recherche de nouvelles traces.

Le laboratoire manipule des entrées fictives. Une entrée sans URL de référence est signalée et n’entre pas dans l’index. Il ne classe personne et ne fusionne pas les homonymes : personne_id est distinct du nom affiché. Les sorties répondent seulement aux rôles et objets attestés par les données fournies.

Un historique de versions et une documentation donnent des prises pour maintenir un projet. Le chapitre About Version Control de Pro Git compare les modèles local, centralisé et distribué et rappelle l’intérêt de conserver les versions ; il ne décrit pas à lui seul les branches ni l’organisation de tous les collectifs. Licence, gouvernance et revue sont des documents à lire, non des étiquettes qui prouvent automatiquement une pratique.

Cette section rejoint langages et projet : un module compréhensible a un contrat, des noms et des tests ; une équipe doit aussi rendre ses décisions et contributions lisibles. Ton dossier peut reconnaître une lacune documentaire. Cette prudence protège les personnes citées et permet de corriger le dossier lorsqu’une nouvelle source apparaît.

Un projet transversal ne juxtapose pas API, authentification, interface et base de données. Commence par une question étroite : « Comment la proposition Web de 1989 distingue-t-elle liens et hiérarchie dans le problème décrit au CERN ? » Choisis deux sources consultables, note auteurs, dates et limites, puis formule ce que ton dossier cherchera à établir. Les données du prototype restent fictives : aucune identité réelle ni donnée de mineur.

Le prototype contrôle la forme d’un dossier. Il reçoit une liste d’exigences et un dictionnaire de preuves. Une preuve est recevable si son statut est réussite, sa référence HTTPS, sa date ISO et son périmètre sont présents. Il peut alors retourner True pour prêt pour revue. Il ne dit ni qu’un fait historique est vrai, ni qu’une interface a été observée, ni qu’une personne a approuvé.

Tests, capture et lecture de source établissent des choses différentes. Un test montre un comportement sur des données synthétiques. Une capture montre un rendu à un instant. Une source justifie un fait dans son champ. La présentation doit donc montrer, pour chaque conclusion, la pièce correspondante et la limite qui l’accompagne.

Les frontières sont concrètes. Une liste d’exigences vide est refusée : un dossier sans attente ne peut pas être prêt. Un booléen ne devient pas identifiant. Une preuve non HTTPS ou sans date est refusée avant l’annonce de revue possible. Cette règle corrige l’erreur où pret_pour_revue([], {}) renvoie True par effet de all sur une collection vide.

Ta production rassemble les sources consultées, les données fictives du prototype, un module Python, ses tests, une sortie textuelle et une présentation individuelle. Elle relie les six thèmes du cours sans confondre le contrôle de forme avec la lecture des archives ou la décision d’une personne.