Photo d’Abraham Wald (retouchée en mode super héros par une IA)

Je suis né il y a longtemps, en 1902 à Kolozsvár, en Transylvanie, dans le royaume de Hongrie. Kolozsvár en hongrois, Cluj en roumain ; aujourd’hui, ma ville de naissance se situe en Roumanie et se nomme Cluj-Napoca, le dictateur communisteNicolae Ceausescu ayant décidé d’adjoindre le nom antique de Napoca à notre ville. Qu’importe… Tout le monde continue à l’appeler simplement Cluj. Je m’égare ; pas sûr que la géopolitique transylvanienne vous intéresse…

Les mathématiques sont mon autre royaume ; après mes études à Vienne, je me suis lié d’une affection particulière pour les statistiques, via l’économie.
Quand les nazis ont annexé l’Autriche, avec toute ma famille, nous avons émigré aux Etats-Unis. La persécution que nous subissions devenait insupportable, intolérable.

Pendant la guerre, j'ai intégré le Statistical Research Group, un groupe de statisticiens au sein de Columbia University. A l’époque, nous, les alliés, perdions beaucoup d’avions lors des missions de bombardement sur l’Allemagne. On nous demanda alors d’étudier les dommages subis pour savoir ce qu’il convenait de faire.

- En rouge, les impacts de balles sur les avions de retour du front. Quelles consignes auriez-vous données aux mécanos pour mieux protéger nos pilotes ?

Illustration of hypothetical damage pattern on a WW2 bomber.
(Photo Credit: Martin Grandjean, McGeddon, Cameron Moll CC BY-SA 4.0)

- Il faut renforcer les parties les plus touchées par des tirs ennemis, on est d’accord ?
- Comme je vous pose la question, vous savez qu’il y a un piège.
Réfléchissez bien, la vie de nos pilotes en dépend !
Evidemment, si on renforce le bout des ailes, on perd en portance.
Donc on mise sur le pack rouge au niveau du fuselage, entre les moteurs. Bien vu !
Sauf que ce n’est pas du tout ça que j’ai mis dans mon rapport…
Pour être complet, certains ont bien essayé de renforcer les zones touchées et, à la stupeur générale, le taux de survie des avions a baissé. C’est à ce moment que notre groupe a été contacté. Revenons à notre problème…

En prenant du recul, je suis arrivé à une conclusion qui m’a surpris : il faut renforcer les parties non touchées par les tirs ennemis, c'est-à-dire celles restées intactes, en blanc sur le schéma.

Cette proposition contre-intuitive, quand je vous en révèlerai la teneur, vous semblera si évidente et si simple qu’elle pourrait même perdre une partie de son charme. Les gens aiment tellement les choses compliquées.

Je me suis rendu compte que les avions qui revenaient criblés de balles ne constituaient pas un échantillon représentatif de l'ensemble des avions engagés dans les missions de bombardement. Les avions touchés dans des zones critiques, comme les moteurs ou le cockpit, ne revenaient généralement pas et étaient perdus. Ainsi, les avions que nous examinions étaient essentiellement les survivants, ceux qui avaient survécu malgré les dommages subis.

A l’heure où vous me lisez, cette façon de penser peut vous sembler naturelle. Mais avec la pression rugissante de la guerre, croyez-moi, j’ai dû me battre contre moi-même pour affirmer mes convictions iconoclastes.

D’aucuns disent que, par un sinistre coup du sort, une fois la guerre finie, je suis mort dans un accident d’avion. En Inde. Le sort, vraiment ?

Assez parlé de moi, parlons de vous maintenant.

De là où je demeure, je vois bien que, vous aussi, avez des problèmes sympathiques. Il est vrai que l’informatique est un merveilleux piège pour l’intuition, un paradis pour les sophistes. Alors, explorons ensemble trois exemples pour titiller votre intuition.

> Paradoxe de la performance, ou la faute à Taylor Swift ?

J’aime beaucoup ce paradoxe. Il s’applique en informatique et généralement partout où il est question de flux.
Récemment, je me suis amusé à regarder les déboires du leader mondial de la billetterie qui n’arrivait pas à stabiliser sa plateforme face à l’affluence des fans de Taylor Swift.
Pourtant, il a bien essayé. En mettant en place une jolie usine à gaz, avec une loterie pour disposer d’un code donnant accès à la plateforme à une heure précise, puis en ajoutant un système de queue pour filtrer…
Malheureusement, quelle désillusion pour les fans ! Après avoir attendu une ou deux heures, après avoir ajouté le ticket dans leur panier...au moment de payer, crash !
Espérons que ce géant de la billeterie trouve à l’avenir une vraie solution, après le fiasco des tournées américaines et européennes.

Vu d’Amérique du Nord
https://www.lapresse.ca/arts/spectacles/2023-01-24/ticketmaster-devant-le-senat-americain/examen-d-un-fiasco.php#:~:text=Des%20s%C3%A9nateurs%20am%C3%A9ricains%20ont%20tenu,prochaine%20tourn%C3%A9e%20de%20Taylor%20Swift

Vu de France
https://www.bfmtv.com/tech/concerts-de-taylor-swift-pourquoi-ticket-master-est-si-peu-fiable_AV-202307120353.html

Joe Berchtold, président de Live Nation 

Reprenons avec un cas concret, plus terre à terre.
Considérons une application web, avec une base de données pour faire bonne mesure. Je vous avais bien dit que c’était concret !

Vous mettez en production, tout va bien.

Puis, sous l’effet d’une annonce, ou bien lors d’une clôture mensuelle, l’application connait une hausse soudaine des fréquentations. Le système monte en charge, puis on commence par observer des dysfonctionnements locaux, et rapidement le système s’effondre !

Vos ingénieurs système vous fournissent de belles courbes montrant les fréquentations, et les temps de réponse de la base de données (ou d’un système de billetterie ? ).
- « Bien sûr, il faut augmenter le pool de connexions à la base. Comme la base ne répond plus, c’est qu’il manque des connexions ! CQFD » Le diagnostic est posé rapidement par votre administrateur système.La solution est simple : il suffit d’augmenter le nombre de connexions.
Simple ou simpliste ?

Combien de fois ai-je vu de projets résoudre ainsi ce problème ?
ou celui équivalent, du pool de connexions web, du pool d’accès à la CRM, à la billetterie...
Pourtant, c’est comme cette vieille carte d’impacts de balles de 1945, les évidences sont trompeuses et j’aime trop la simplicité pour la pervertir dans le simplisme.

En réalité, lorsqu’une base est saturée, il est nécessaire de diminuer le nombre de connexions pour fluidifier le trafic. Les temps de réponses vont certes s’allonger, et les utilisateurs devront attendre une libération de ressources, mais une fois celles-ci disponibles, les requêtes s’exécuteront rapidement.

C’est la même raison qui pousse les magasins en période de soldes à retreindre les entrées ou les exploitants autoroutiers à fermer des voies et réduire la vitesse lors des départs en vacances pour éviter les embouteillages dus aux irrégularités du trafic.

Je reprends mon chapeau du professeur que je fus : les performances d’un système (qu’il soit routier, informatique, hydraulique…) sont régies par leur point le plus critique. En cas de saturation du système, toute action qui vise à augmenter les ressources des points non critiques peut engendrer une pression encore plus forte sur le point critique et donc rendre encore plus difficile l’écoulement, voire l’interrompre complétement. Il est souvent plus intéressant de limiter le trafic en amont du point critique, de façon à fluidifier l’écoulement. Retenez qu’en cas de problème de performance, ajouter ou libérer des ressources, si elles ne sont pas les ressources critiques elles-mêmes, peut aggraver vos problèmes au lieu de les résoudre.

> Paradoxe de la sécurité, ou la faute à Voltaire
 

Quand je pense au second cas, je me dis qu’il ressemble à une vieille maxime. « Le mieux est l’ennemi du bien » écrivait Voltaire au XVIIIe siècle.
 

J’ai bien compris que vos systèmes étaient de plus en plus complexes. Ah ce mot, « complexe », que vous utilisez à tout propos et qui signifie, hélas, votre assujettissement à un système que vous ne comprenez plus.

Je vois aussi que vos mots de passe contiennent des caractères dont je ne soupçonnais parfois même pas l’existence.
Il vous faut 8 caractères dont au moins 3 chiffres, 2 majuscules, 2 caractères spéciaux parmi… et le mot ne doit pas ressembler aux 5 derniers, ni correspondre à la liste noire des mots de passe évidents.
Choisir un mot de passe nécessite désormais une gymnastique intellectuelle d’une intensité force 9 niveau sudoku.
Les administrateurs, voulant à tout prix sécuriser le système dont ils sont les gardiens, définissent des politiques de mots de passe de plus en plus contraignantes, avec obligation de changement tous les 3 à 6 mois.

Cette course à la complexité est hélas contre-productive, car elle se heurte à la limite humaine.
Dès lors, les utilisateurs ne vont plus retenir les mots de passe mais user de stratégies d’évitement.
Or, l’objet initial d’un mot de passe est d’être mémorisé et non d’être conservé sur un quelconque papier ou partagé sur plusieurs sites !
Il est donc préférable d’opter pour un mot de passe robuste, que l’on conservera plus longtemps, que d’ajouter des règles à des règles pour, à la fin, avoir des mots de passe soi-disant robustes et changés tous les 3 mois. Bien sûr, l’autre solution consiste à disposer d’un gestionnaire de mots de passe… Mais qui en possède un ? Et les dernières attaques réussies contre les sociétés éditrices de ces gestionnaires posent la question de la confiance.

Dans cette impasse, quelle est-donc la solution ? Délicat de le dire avec assurance…

- Miser sur de multiples facteurs dont votre satané smartphone ? Sûrement !
En revanche, chercher à faire porter sur les mots de passe une complexité inhumaine, au sens premier, me semble une approche vaine.

D’ailleurs, l’ANSSI, votre organisme de référence en matière de sécurité, corrobore cette analyse.

Dans le guide publié par l’ANSSI : https://www.ssi.gouv.fr/uploads/2021/10/anssi-guide-authentification_multifacteur_et_mots_de_passe.pdf

> Paradoxe de la résilience, ou la faute à Faust

Clusters, systèmes distribués, micro-services...

En informatique, ils sont perçus comme une sorte de Graal permettant de résoudre les problèmes de résilience, de montée en charge et de performances.
Cela est vrai, mais il y a un prix à payer.

Vous avez un système qui fonctionne avec un SLA de 99% (SLA = taux de disponibilité). Un ingénieur vient vous voir et vous propose de « simplement » évoluer vers un cluster, ce qui accroitra significativement votre disponibilité à 99,9%…

Par exemple, passer sur une architecture avec un cluster de bases de données, opter pour une architecture répartie des traitements…

Votre ingénieur a raison, mais vous a-t-il tout dit ?
Sans le savoir, vous venez de pactiser avec la complexité, une sorte de pacte faustien vous lie désormais ou bien s’agit-il du fameux pizzo qu’il convient de payer pour être « protégé ».
 

S’il existe des exemples où ces bascules sont effectives et fonctionnent, il y a beaucoup d’autres cas où elles sont mises en œuvre sans les moyens appropriés (le fameux prix).
Gérer un système distribué demande des compétences pointues, rares.
Ces compétences sont chères. Il est, de surcroit, nécessaire de les conserver et qu’elles aient une expérience significative pour être efficaces.
La solution qui souvent s’entend sur un plan technologique, revêt un aspect organisationnel certain. Ce qui, in fine, se traduit par des coûts récurrents élevés.
Quant aux technologies en question… Un système distribué nécessite une supervision qui sache réconcilier les requêtes distribuées…
Et si vous ne payez pas le pizzo, alors le moindre écart risque d’être fatal à votre architecture.
Sans une connaissance complète des impacts techniques et organisationnels, la proposition de votre ingénieur se révèlera contre-productive, la disponibilité de votre système allant même jusqu’à baisser !

Je me souviens de ce projet qui voulait tellement garantir la disponibilité de ses données, que la direction a opté, sans tenir compte des faibles compétences disponibles, pour un cluster.
Et ce qui devait arriver, arriva. Un dysfonctionnement sur le cluster a occasionné un arrêt de plusieurs jours, nécessitant de faire venir des spécialistes de l’éditeur. On est très loin des 8,76 h acceptables d’arrêt annuel pour un SLA de 99, 9 %.

> Le survivant et la fontaine de jouvence
 

Pour terminer, revenons sur le biais du survivant.

Depuis mon poste d’observation privilégié, je remarque que, dans vos projets informatiques, il y a, parfois, un certain mépris pour les anciens projets. Que n’ai-je entendu de critiques, sur des technologies dépassées pour des applications qui avaient dix voire vingt ans d’existence. Je vois bien depuis mon repaire que vos technologies ont des durées de vie plus proches de celle d’un lapin que d’un humain. Moi qui viens d’une ville perdue (« Notons qu’Abraham exagère car Cluj est une vraie capitale culturelle en Roumanie » Note de l’éditeur), je trouvais que l’automobile et l’électricité bousculaient les habitudes quand j’ai débarqué aux Etats-Unis. Mais les changements permanents qu’imposent l’informatique donnent un coup de vieux à tout ce qui a précédé.

Certes, les critiques envers les technologies dépassées ne sont pas injustifiées, car elles peuvent présenter des vulnérabilités, des inefficacités ou des limitations. Cependant, il est crucial de se rappeler que ces technologies ont été pionnières ; elles ont permis de résoudre des problèmes et de répondre à des besoins de manière satisfaisante. Si une application est encore en production 10, 15 ou 20 ans après son lancement, c’est qu’elle doit avoir certaines qualités. Alors oui, on peut se focaliser sur les cicatrices de la vie des survivants… Pourtant ne serait-il pas plus sage de chercher quelles ont été les caractéristiques qui ont permis à certaines applications de passer les âges ? J’ai la faiblesse de croire que plonger vos applications dans la simplicité, c’est aussi les baigner dans une fontaine de jouvence…

Et que, bienheureux les écumeurs de nouvelles technologies, au défi du temps, ils ne font que passer…

« SOLDATS, SONGEZ QUE, DU HAUT DE CES PYRAMIDES, QUARANTE SIÈCLES D'HISTOIRE VOUS CONTEMPLENT » BONAPARTE, 1798