L’histoire étonnante du premier bug informatique
En 1947, un papillon de nuit bloque le Harvard Mark II. Le logbook scotché est réel, mais le mot « bug » existait déjà : voici pourquoi.
Table des matières
Le saviez-vous ? En 1947, “ordinateur” n’est pas encore un objet familier : dans les laboratoires et les administrations, on parle encore volontiers de “calculateurs” et, surtout, de programmes et de procédures bien avant que le terme “software” ne s’impose (son premier usage publié est souvent attribué à John W. Tukey en 1958). L’anecdote du “premier bug” existe bel et bien, et sa force vient d’un fait rare en histoire des techniques : on ne s’appuie pas seulement sur un souvenir, mais sur un registre conservé dans une institution muséale. Ce registre raconte une panne du Harvard Mark II et sa découverte la plus insolite : un papillon de nuit coincé dans un relais, retiré puis scotché dans le carnet de bord, avec une annotation devenue célèbre. L’incident du Mark II s’inscrit dans une culture très matérielle du calcul : on consigne tout, on étiquette, on archive, parce qu’une panne peut coûter des heures de travail et une crédibilité institutionnelle. Ce “bug” fascine parce qu’il renverse l’imaginaire : face à une machine pensée pour dompter des calculs immenses, le grain de sable vient du vivant, de l’imprévu, de ce qui se faufile. Le Mark II est alors testé à Harvard, dans un monde où se croisent recherche universitaire et exigences militaires : une alliance typique de l’après-guerre, quand le calcul devient une infrastructure stratégique. Ce qui suit ressemble à une enquête : diagnostiquer, isoler le composant fautif, produire une “preuve”, puis documenter la correction — une méthode qui annonce déjà la discipline moderne du dépannage. Et c’est justement parce que l’histoire est documentée et datée qu’elle mérite d’être racontée avec nuance, plutôt que répétée comme une fable sur “l’invention du bug”.
Pourquoi un papillon pouvait paralyser une machine géante
Le Harvard Mark II appartient à la famille des machines à relais électromécaniques, un entre-deux technologique : plus automatique que la mécanique pure, mais pas encore la vitesse et la stabilité de l’électronique. Un relais, c’est un contact commandé par électroaimant : la logique y devient une chorégraphie de pièces qui s’ouvrent et se ferment, sensible aux vibrations, aux impuretés, et aux micro-obstacles. Dans ces architectures, l’environnement compte : chaleur, poussière, humidité, et même les insectes attirés par la lumière ou les zones chaudes peuvent devenir des variables techniques. On comprend alors pourquoi la maintenance n’est pas un “service annexe” mais une activité centrale : la performance réelle d’une machine dépend autant de sa conception que de son entretien quotidien. Le Mark II est pensé pour une finalité très concrète : produire des calculs utiles à la balistique — autrement dit transformer des équations en portée, trajectoire et réglages, au bénéfice de la marine américaine et de ses centres de tir. La presse et les descriptions institutionnelles de l’époque insistent sur l’échelle : ces machines sont perçues comme des “cerveaux” mécaniques, lourds, bruyants, et suffisamment impressionnants pour symboliser une nouvelle ère du calcul. Il faut imaginer le travail autour : des équipes, des procédures, des registres, et une discipline quasi-industrielle pour que la machine reste fiable sur des séries de calculs longues. Le fait qu’il soit destiné au Naval Proving Ground de Dahlgren rappelle que l’innovation informatique naît aussi de besoins d’État : accélérer la production de résultats, réduire l’erreur humaine, standardiser les méthodes. Dans ce contexte, une panne n’est pas seulement un incident technique : c’est un risque opérationnel, ce qui explique la rigueur des logbooks et la volonté de “clore” une cause par une preuve.
Le 9 septembre 1947 : premier cas réel de bug trouvé
Le 9 septembre 1947, pendant un test, la machine se comporte mal ; la routine se met en marche : vérifier, isoler, remonter la chaîne des causes jusqu’au composant fautif. Et là, dans l’un des relais — ces points de passage où un contact peut être empêché par presque rien — l’équipe découvre l’intrus : un papillon de nuit coincé entre des contacts. La phrase notée dans le registre — “first actual case…” — sonne comme une blague d’atelier, mais elle révèle surtout une pratique : transformer un dysfonctionnement en événement traçable, puis en cas d’école. L’épisode se diffuse aussi parce qu’il est racontable : il associe une panne abstraite à une cause immédiatement compréhensible, ce qui le rend parfait pour transmettre la culture du dépannage. Programmer Grace Hopper est souvent associée à cette scène : les sources muséales et historiques la placent parmi les personnes travaillant sur le Mark II, et rappellent qu’elle a surtout contribué à rendre l’incident célèbre lors de conférences ultérieures, en s’en servant comme d’un exemple marquant. Et c’est ainsi que le logbook, initialement document de routine, bascule dans l’histoire : il ne sert plus seulement à réparer, mais à mettre en mémoire une naissance symbolique du “debugging” moderne.
Le détail qui change tout : l’insecte a été conservé
Le geste le plus décisif, historiquement, n’est pas de retirer le papillon : c’est de le conserver. Le Smithsonian décrit explicitement l’objet : un insecte scotché dans le registre, accompagné de la fameuse annotation, ce qui rend l’épisode vérifiable et stable — deux qualités précieuses quand une anecdote devient “mythe fondateur”. Le registre ne raconte pas une “invention” soudaine du débogage : il montre une équipe appliquant une méthode de diagnostic, puis fixant la preuve comme on le ferait d’un échantillon dans un dossier. Cette matérialité explique pourquoi, des décennies plus tard, l’histoire reste vivante : on peut littéralement pointer du doigt la page, l’encre, le ruban adhésif, l’insecte, et constater que le récit n’est pas un embellissement tardif.
Le mot bug vient-il de là ? Non, mais cette panne l’a rendu immortel
Pour rester rigoureux, il faut distinguer deux choses : l’origine du mot “bug” et l’origine de son mythe informatique — l’incident de 1947 relève surtout de la seconde. Bien avant les ordinateurs, Thomas Edison emploie “bug” pour parler de problèmes techniques ; dans une lettre de 1878 à William Orton (Western Union), il plaisante même sur le fait qu’il a trouvé un “bug” dans son appareil, en jouant ironiquement sur l’idée d’un insecte niché dans les dispositifs d’appel. Ce point est crucial : en 1947, l’équipe ne baptise pas un concept neuf, elle réutilise un jargon existant — mais, cette fois, la métaphore devient littérale. Autrement dit, le Mark II ne “crée” pas le bug : il crée l’image définitive du bug, celle qui survit parce qu’elle est concrète, datée, archivée. La diffusion du vocabulaire “debug / debugging” s’explique aussi par l’industrialisation du calcul : quand les équipes s’élargissent et que les machines entrent dans des organisations complexes, il faut des mots partagés pour nommer la recherche d’erreur et la correction. Cette nuance renforce l’histoire au lieu de l’affaiblir : elle montre comment un terme voyage de l’atelier d’inventeur (XIXe) au laboratoire de calcul (XXe), puis au monde du logiciel. En fin de compte, l’épisode du papillon sert d’exemple parfait de “preuve narrative” en histoire des techniques : un petit fait, solidement attesté, qui éclaire une transformation beaucoup plus vaste — la montée en puissance du calcul comme infrastructure scientifique, industrielle et stratégique.
Sources
- Emmanuel Lazard & Pierre Mounier-Kuhn, Histoire illustrée de l’informatique , EDP Sciences, 2022.
- Futura Sciences, Science décalée : le premier bug informatique de l'histoire ... , 2020.
Retrouvez-nous sur :
Les illustrations ont été générées par intelligence artificielle pour servir le propos historique et afin d’aider à l’immersion. Elles ont été réalisées par l’auteur et sont la propriété du Site de l’Histoire. Toute reproduction nécessite une autorisation préalable par e-mail.
Commentaires
Enregistrer un commentaire