Le cadre institutionnel
Hamming a prononcé son discours « You and Your Research » des dizaines de fois dans diverses institutions, de Bell Labs à la Naval Postgraduate School. Son conseil central restait constant : travailler sur des problèmes importants, pas seulement sur des problèmes occupés. Garder 10 problèmes importants en tête. Lorsqu’une nouvelle technique apparaît, se demander si elle résout l’un de ces 10 problèmes.
Mais tout au long du discours se cache une hypothèse implicite : vous travaillez au sein d’une institution. Bell Labs payait le salaire de Hamming. Il pouvait passer ses vendredis après-midi à réfléchir sans produire de résultat facturable. Il avait des collègues dans d’autres étages et bâtiments avec lesquels il pouvait engager la conversation. Il disposait d’une bibliothèque avec des revues physiques. Il avait accès à des ressources informatiques sur simple signature d’un formulaire.
Quand il disait « gardez votre porte ouverte », il supposait une porte donnant sur des collègues au bout du couloir. Quand il disait « investissez en vous-même », il supposait des voyages de conférence subventionnés par l’employeur. Quand il disait « capitalisez vos connaissances », il supposait un contexte d’emploi stable permettant à cette capitalisation de porter ses fruits.
En 1986, lorsque Hamming a prononcé ce discours pour la première fois chez Bell Communications Research, cela était presque universel pour les chercheurs sérieux. En 2026, l’open-source a complètement brisé cette hypothèse. Un chercheur peut produire un travail conséquent depuis un simple répertoire personnel, un dépôt git public et une communauté de personnes qu’il ne connaît pas mais qui partagent un même problème.
Cette leçon étend les meilleures idées de Hamming dans ce cadre — non pas pour le remplacer, mais pour actualiser l’environnement dans lequel ses conseils s’inscrivent.
Traduire la porte ouverte
Hamming à propos de la porte ouverte : « Je remarque que si vous laissez la porte entrouverte, vous travaillez moins, mais vous entendez ce qui est important. Les grands scientifiques ont tendance à laisser leur porte ouverte — pas tout le temps, mais une partie du temps. »
Il le disait littéralement. Un collègue passant dans le couloir pouvait mentionner un problème. Hamming captait un fragment de conversation sur une nouvelle technique. Ces collisions se produisaient dans l’espace physique, au déjeuner, dans les couloirs, près de la machine à café.
La technique des 10 problèmes hors d’une institution
La technique des 10 problèmes de Hamming : maintenez une liste des problèmes non résolus les plus importants de votre domaine. Lorsqu’une nouvelle méthode, un nouvel outil ou un nouveau résultat apparaît, demandez-vous s’il répond à l’un de ces 10 problèmes. Cela concentre l’attention et crée ce qui ressemble à des coups de chance : une nouvelle technique apparaît dans un séminaire et, en quelques minutes, Hamming voit quel problème elle résout.
Dans l’open-source, les problèmes vivent dans des endroits publics : les traqueurs de tickets, les bases de données de sécurité (CVE, CWE), les présentations de conférences, les fils Stack Overflow jamais résolus, les journaux de modifications des bibliothèques qui signalent « limitation connue ». Un pipeline MOAD applique la technique de Hamming de manière systématique : recherche de CWE-407 dans tous les écosystèmes, mise en correspondance des résultats confirmés avec les projets amont, ouverture de tickets, soumission de correctifs.
Le pipeline ne nécessite aucun salaire. Il exige : une liste de problèmes (MOAD), une méthode de scan (motifs grep, analyseurs statiques) et un accès amont (git, listes de diffusion, GitHub, GitLab). Toute personne disposant d’un terminal et d’une connexion Internet peut l’exécuter.
La connaissance composée de Hamming : travailler sur les problèmes les plus importants et chaque nouvelle technique apprise peut potentiellement en résoudre un. L’open-source compose différemment : chaque correctif fusionné en amont se propage automatiquement à tous les forks en aval. Le correctif se répand sans effort supplémentaire du chercheur initial. Un correctif soumis à la bibliothèque email de Python en 2020 a atteint toutes les installations Python en 2021.
L’institution fournissait : continuité salariale, ressources informatiques, accès à la bibliothèque, réseau de collègues, prestige comme validation. En 2026, la plupart de ces éléments arrivent gratuitement à la périphérie du réseau : calcul cloud, archives de revues ouvertes, GitHub, Stack Overflow, Twitter académique. La rareté restante est l’attention et le jugement, pas l’accès.
Appliquer la technique des 10 problèmes
La question de Hamming, appliquée à votre domaine :
Ce que les institutions offrent, ce qu’elles n’offrent pas
Hamming : « Il faut du courage pour travailler sur des problèmes importants. La plupart des gens ne travaillent pas sur des problèmes importants. Si vous ne travaillez pas sur des problèmes importants, il est peu probable que vous accomplissiez un travail important. »
Le soutien institutionnel procure une forme de courage : la titularisation (tenure) supprime la menace de licenciement. La continuité du salaire élimine l’anxiété liée aux revenus. La reconnaissance des pairs valide que le problème mérite d’être abordé. L’institution absorbe le coût des tentatives infructueuses.
Travailler en dehors d’une institution supprime chacun de ces soutiens. Un patch que vous soumettez peut être ignoré par des mainteneurs qui ont d’autres priorités. Une divulgation que vous faites peut être rejetée comme n’étant pas une véritable vulnérabilité. Un projet que vous maintenez pendant des années peut ne jamais attirer de contributeurs. Personne ne garantit que vos efforts aboutissent quelque part.
Mais l’open source supprime aussi une peur spécifique que les institutions créent : vous ne pouvez pas être licencié d’un projet que vous maintenez. Aucun manager ne peut vous réorienter vers un problème moins important parce qu’un client l’a demandé. Aucun bilan de performance ne vous pénalise pour avoir travaillé sur quelque chose qui a mis cinq ans à porter ses fruits. Un patch dans le domaine public n’a pas besoin d’autorisation pour exister. Il suffit qu’il soit correct.
Principe du permacomputer : publiez le patch en domaine public. Le patch n’a pas besoin de crédit pour survivre. Il n’a pas besoin d’une affiliation institutionnelle pour être adopté. Il doit être correct et accessible. Si un mainteneur amont l’ignore, forkez le dépôt et publiez la correction dans le fork. La justesse persiste indépendamment de la réception.
La porte fermée de l’open source
Hamming a observé que les scientifiques qui ferment la porte de leur bureau accomplissent davantage à court terme, mais prennent du retard à long terme car ils cessent d’entendre ce qui compte.