Matt Novak se plonge dans un livre de 1982 qui pointait vers 17 emplois que la technologie devait rendre obsolète au XXIe siècle... mais les caissières sont toujours et les agriculteurs peinent à trouver suffisamment de main d'oeuvre pour ramasser les récoltes... En fait, on surestime souvent la capacité des machines à prendre totalement des emplois. En fait, la plus grande perturbation qu'introduisent les machines est dans la diminution du montant auquel on paye les gens qui travaillent.

A chaque fois qu’on retire de l’argent, l’automate de la banque doit décider si ce retrait est autorisé, s’il est “normal”. Il doit décider si c’est vraiment nous qui retirons de l’argent. Notre carte, notre code bancaire ne sont que des talismans pour en appeler à un complexe cerveau électronique résidant quelque part dans un datacenter climatisé. C’est lui le véritable gérant du guichet et c’est lui qui doit approuver ma transaction pour qu’elle soit autorisée. En fait, notre carte et notre code ne sont pas si importants que cela pour ce cerveau électronique. “Ce qu’il consulte avant tout c’est une vaste base de données d’enregistrements qui inclue ma localisation présumée, mes transactions récentes, le type de transaction que je demande, le temps qui s’est &eacut! e;coulé depuis ma précédente transaction, le montant que je demande, la date de cette transaction et quelques dizaines d’autres mesures dont je n’ai pas conscience. Il soupèse chacun de ces facteurs et décide si je suis vraiment celui que je prétends être. Il les soupèse et décide de me donner ou pas mon argent.” En fait, ces enregistrements, aussi factuels et minimaux soient-ils, par leur accumulation, dessinent une base de données de comportements, basée sur l’analyse de ces enregistrements. L’activité est une alternative à l’identité.

Le problème est que quand l’algorithme refuse la transaction, la machine ne nous dit jamais pourquoi. “Cela signifie que nous sommes constamment engagés dans une sorte de danse avec l’algorithme, une danse où je ne peux entendre la musique et où la seule réaction que je reçois est quand je marche sur les pieds de mon partenaire.” Nous ne connaissons ni les règles des algorithmes ni quand elles sont modifiées… Notre seul repère consiste à observer par essai/erreur, afin d’apprendre ce qui ne lui convient pas. Nous apprenons en dansant !

Car à mesure que nos sociétés s’informatisent, nous serons de plus en plus soumis à la possibilité du bug. Pour une raison simple : le bug est inévitable. Il est inévitable, car, jusqu’à maintenant, il est consubstantiel à l’informatique.

D’ailleurs, l’origine même du mot plonge dans la préhistoire de l’informatique. La légende veut que le terme de « bug » (insecte en anglais) remonte à 1947. La grande informaticienne Grace Hoper découvre dans l’un des premiers ordinateurs électromécaniques qui ne fonctionnait plus très bien, une mite qui a fait griller le système. C’est cette histoire qui popularise l’usage du terme en informatique. En fait, il semblerait que le mot bug pour désigner le défaut de fonctionnement d’une machine date de plus loin encore, Edison l’aurait employé.

Aujourd’hui, le bug n’est plus un insecte, mais une erreur de programmation qui va entraîner le mauvais fonctionnement du programme ou de la machine. Comment est-ce possible ? Comment est-ce encore possible aujourd’hui alors que nos machines sont si puissantes ? Parce que les logiciels sont les constructions les plus complexes jamais réalisées par l’homme et qu’à mesure que cette puissance augmente, la complexité augmente (on dit souvent qu’il est mathématiquement plus simple de concevoir le Viaduc de Millau qu’un système d’exploitation). Parce que ces logiciels sont constitués de millions de lignes de code qui interagissent les unes avec les autres, et qu’il est impossible d’assurer que le logiciel fonctionnera dans toutes les conditions de ces interactions. Pourquoi est-ce impossible ? Parce qu’il n’existe pas de machine assez puissante, ni asse! z de temps, pour tester un logiciel dans toutes les possibilités de son usage, et parce que pour l’instant, la « preuve formelle », c’est-à-dire la preuve mathématique qu’un logiciel va bien fonctionner, est un objet de recherche (alors que pour un pont, on connaît les lois physiques et mathématiques qui permettent d’assurer a priori qu’il va tenir).

Alors bien sûr, tous les logiciels ne sont pas égaux devant le bug. Si on le tolère aisément dans nos téléphones portables (et quand on y pense, c’est une expérience très courante que le bug dans nos téléphones ou nos ordinateurs), on le tolère beaucoup moins dans l’industrie aéronautique, où l’on investit des millions d’euros et de dollar pour en limiter au minimum la possibilité.