Projet et histoire de l’informatique

Un projet commence par un besoin formulé du point de vue de son utilisateur. « Afficher un itinéraire entre deux salles » est un besoin ; « utiliser une classe Python » est déjà un choix de réalisation. Le premier travail consiste à préciser les entrées, les sorties, les situations d’échec et les limites. Sans ce contrat, deux programmes peuvent produire des réponses différentes tout en prétendant accomplir la même tâche.

Pour notre réseau, les salles sont des sommets et les passages autorisés des arêtes. On suppose que chaque passage compte pour une unité et que le réseau est non orienté. La fonction reçoit le graphe, un départ et une arrivée. Elle renvoie une liste de sommets décrivant un chemin de longueur minimale en nombre de passages, ou une valeur distincte indiquant l’absence de chemin. Un nom de salle inconnu doit être traité selon une règle annoncée.

Un prototype doit avoir une ambition réalisable. Une recherche sur cinq salles est suffisante pour vérifier les premiers choix. On pourra ensuite agrandir le réseau ou améliorer l’interface. Ajouter simultanément une carte, une connexion utilisateur et une optimisation de durée multiplie les causes d’erreur. Mieux vaut une fonction testée sur un périmètre clair qu’une démonstration séduisante dont le résultat n’est pas vérifiable.

La modularité sépare les responsabilités. Un module décrit les données du réseau ; un autre contient la recherche de chemin ; un autre présente le résultat. La fonction de calcul ne doit pas dépendre de la couleur d’un bouton ou du format d’une fenêtre. Une interface précise entre modules permet de modifier la présentation sans réécrire l’algorithme. Elle indique notamment les paramètres, les types attendus, le retour et les erreurs possibles.

Travailler en parallèle suppose de se mettre d’accord avant d’écrire des fonctions incompatibles. Une personne peut préparer les données, une autre le calcul et une troisième les tests, mais toutes utilisent le même contrat. Des points réguliers servent à vérifier ce qui fonctionne ensemble. Un planning doit réserver du temps pour l’intégration : assembler les parties seulement à la dernière séance transforme des désaccords simples en blocages difficiles à isoler.

Un gestionnaire de versions conserve une histoire des changements. Un commit correspond à un état enregistré avec un message explicatif. Une branche permet de préparer un changement séparément ; une fusion réunit ensuite des travaux. Un dépôt distant facilite le partage, mais il n’est pas identique au logiciel Git lui-même. Un changement présent sur une machine n’est pas automatiquement partagé avec le reste du groupe.

Un conflit de fusion signale que deux changements ne peuvent pas être réunis automatiquement. Il ne se résout pas en gardant arbitrairement la version la plus récente. Il faut comprendre les deux intentions, conserver le comportement demandé et relancer les tests. Les commentaires expliquent les raisons des choix difficiles ; ils ne compensent pas des noms de fonctions incohérents ou une documentation qui décrit une ancienne version.

Lorsqu’un test échoue, on conserve l’entrée qui reproduit le défaut, on compare le résultat obtenu au résultat attendu et on réduit la situation au plus petit exemple utile. On cherche ensuite la cause : indice hors limite, effet de bord, condition oubliée, structure modifiée pendant un parcours ou mauvaise interprétation du contrat. Corriger le symptôme d’affichage peut laisser intacte une erreur du calcul.

Une assertion exprime une propriété à vérifier. Elle est utile pendant la mise au point, mais n’est pas une preuve générale et ne remplace pas le traitement prévu des erreurs utilisateur. Un test peut aussi être faux : résultat attendu mal calculé, hypothèse absente du contrat ou comparaison trop stricte. Un échec indique un désaccord à analyser, pas automatiquement une faute dans la fonction testée.

En 1936, Alan Turing formalise un modèle abstrait de calcul et la notion de machine universelle. Une machine universelle peut simuler les calculs d’autres machines décrites dans ce modèle. Ce repère concerne les fondements du calcul, pas la construction d’un ordinateur portable avant l’heure. Il aide à comprendre pourquoi des matériels différents peuvent exécuter des programmes répondant aux mêmes principes algorithmiques.

Le 21 juin 1948, le Manchester Baby exécute un programme stocké dans sa mémoire électronique. Les travaux de Frederic Williams et Tom Kilburn sont associés à cette réalisation. Le repère porte sur une démonstration du programme enregistré dans une mémoire électronique accessible, et non sur l’affirmation vague qu’aucune machine à calculer n’existait auparavant. Stocker des instructions comme des données ouvre une grande souplesse de programmation.

En 1989, Tim Berners-Lee propose au CERN un système hypertexte à l’origine du Web. En 1993, le CERN rend le logiciel du Web librement disponible par une décision de mise dans le domaine public. Internet et le Web ne sont pas synonymes : Internet fournit une infrastructure de communication ; le Web organise notamment l’accès à des ressources reliées par des liens. Une application peut utiliser Internet sans être une page Web.

Ces étapes montrent des rôles complémentaires. Le matériel exécute et mémorise ; les modèles théoriques définissent ce qu’est un calcul ; les langages et les logiciels rendent les machines utilisables ; les réseaux permettent leur coopération. Une innovation ne découle donc pas seulement d’un processeur plus rapide. Les interfaces, les formats partagés et les conditions de diffusion influencent aussi les usages.

Pour documenter un repère historique, note le protagoniste, la date, la nature exacte de l’événement et la source consultée. Une archive contemporaine et une page rétrospective d’institution ne jouent pas le même rôle. Il faut vérifier ce que le document établit réellement et éviter les expressions absolues comme « premier ordinateur » sans préciser le critère. Plusieurs inventions répondent à des critères différents : mécanique, électronique, programmable ou à programme enregistré.

La restitution d’un projet suit une logique comparable : poser une question précise, montrer les choix et fournir une observation vérifiable. Une démonstration réussie n’établit pas que tous les cas fonctionnent. On présente le périmètre testé, les limites et une amélioration justifiée. Le groupe doit aussi expliquer la contribution de chacun et montrer comment les parties ont été réunies, plutôt qu’aligner des captures sans raisonnement.

Pour poursuivre ton entraînement, ouvre la rubrique S’entraîner du site, à l’adresse /exercices. Reprends d’abord les questions de cette leçon sans afficher les réponses, puis compare ton raisonnement à la correction.