L’échelle de Kardashev appliquée à l’informatique, partie II

Certes, si le bug est inhérent au logiciel, l’on n’est pas pour autant totalement démuni face à ce genre de dysfonctionnement ; il va être nécessaire, dans certains cas, de doubler les dispositifs : l’un qui « fait », et le second qui « contrôle » le premier. Dans le cas du NHS par exemple, il serait possible de détecter ce genre de bug en réalisant une simple règle de trois : on sait que, chaque année, x femmes doivent être convoquées (du fait de la taille de la population et de la pyramide des âges, x est calculable avec un bon niveau de précision), et donc le résultat du nombre global de convocations produites à l’année est vérifiable à epsilon près. 

Dans un registre un peu semblable, je pense aux PC de procédure dégradée du DPI que la plupart des établissements de santé déploient dans les unités de soins : ces PC sont censés héberger les dossiers des patients présents dans l’unité (et mis à jour par exemple toutes les heures) afin qu’en cas de panne totale du DPI les professionnels de l’unité aient au moins accès, en lecture, aux données des patients présents au moment de la panne. Problème : ces dispositifs ne sont utilisés que lors d’une panne, donc jamais testés. Et bien évidemment, le théorème de la tartine beurrée stipule de manière certaine que lors de la prochaine panne la majorité de ces PC ne fonctionnera pas (soit une panne matérielle franche, soit plus simplement une désynchronisation des données). Or, ces PC sont au DPI ce que la roue de secours est à votre voiture : on n’en a jamais besoin, sauf au moment de la panne et, à ce moment-là, vous êtes certain que cette fichue roue de secours sera à plat (je fais régulièrement le test dans mes cours et conférences : sur 50 à 80 personnes, on compte rarement plus d’un individu qui vérifie régulièrement la pression du pneu de sa roue de secours).

Conséquence logique : les PC de procédure dégradée ne suffisent pas ; il faut un système centralisé destiné à les contrôler (soit dit en passant, il faudrait que l’on m’explique pourquoi, dans une voiture avec une roue de secours, les constructeurs ne pourraient pas installer un capteur de pression avec remontée d’alarme sur le tableau de bord).

On voit donc apparaître un niveau additionnel sur l’échelle précédente, ce qui donne :

• au niveau 0, une panne de l’informatique n’impacte en rien la vie du patient (les hôpitaux en étaient à ce stade dans les années 1970) ;
• au niveau 1, seule une panne des systèmes dans les secteurs critiques (salles de réveil, soins intensifs, etc.) peut impacter la vie du patient ;
• au niveau 2, une panne des systèmes DPI (comprenant les briques Dossier de soins et Médicaments) peut impacter la vie du patient ;
• au niveau 3, une panne ou un bug dans un système administratif périphérique (convocation à des consultations de prévention, par exemple) peut impacter la vie du patient ;
• au niveau 4, une panne ou un bug dans un système de supervision d’un système de production impacte la vie du patient.

Avec le bug de la NHS, on était déjà au niveau 3, mais nous sommes de facto au niveau 4.