Plus le niveau de la technique est élevé, plus les avantages que peuvent apporter des progrès nouveaux diminuent par rapport aux inconvénients.
Simone Weil.
Nous sommes désormais entourés par de multiples dispositifs électroniques qui reposent tous et de plus en plus sur la programmation numérique. Et force est de constater deux choses : d’une part, ces dispositifs sont très attachants (pour ne pas dire addictifs !) ; dès qu’on s’en sert et qu’on en constate l’efficacité, on a ensuite du mal à s’en passer (notamment les smartphones). Mais, d’autre part, on se rend vite compte que ces appareils ont une fiabilité “aléatoire”, pour le dire gentiment… Or, la question de la fiabilité (ou de la non-fiabilité dans le cas présent) va se poser de manière de plus en plus appuyée, voire douloureuse.
L’informatique (et la technique en général) est jugée sur ce qui ne fonctionne pas !
Que ce soit juste ou pas, il faut bien l’admettre, l’informatique des organisations est d’abord et avant tout jugée sur ce qui ne fonctionne pas, point. Surtout depuis que cette informatique est exposée aux regards de tous dans ses relations avec ses clients via les interfaces Web et mobiles…
On peut toujours rêver de mettre en place des avantages concurrentiels formidables, la réalité est plus prosaïque et elle vous rattrape vite : vos utilisateurs veulent que leurs applications fonctionnent, les bons jours comme les mauvais jours (surtout les mauvais jours en fait !).
Et le “bon” fonctionnement ne se limite pas à répondre présent lors d’une sollicitation technique (en clair, lorsqu’on demande la page d’accueil de l’intranet -par exemple-, celle-ci s’affiche dans un délai raisonnable), il faut aussi que la facilité d’utilisation soit au rendez-vous. Or, l’ergonomie de l’interface utilisateur est un point qui est toujours négligé. Combien de fois se retrouve-t-on sur la page d’une application où l’étape suivante est impossible à atteindre ou que les choix possibles sont trop confus pour être utilisables ?
Surtout aujourd’hui où l’on vous impose de plus en plus de faire toutes vos démarches en ligne (qu’elles soient administratives ou commerciales), le vécu utilisateur s’apparente trop souvent à un “parcours du combattant” qui est stressant et frustrant. Bref, vous l’aurez compris, l’informatique est critique (et il est critique qu’elle réponde correctement quand on en a besoin) et on a l’impression que les décideurs n’ont pas encore tout à fait intégré cette caractéristique majeure.
Les nouvelles voitures stoppées par les bugs !
Pourtant, il n’y a pas besoin d’être un grand visionnaire pour s’apercevoir que, dans notre monde ultra technique, les choses qui ne fonctionnent pas sont plus la règle que l’exception… Que ce soit dans votre voiture (où l’électronique est de plus en plus présente) ou que ce soit dans votre usage personnel de votre smartphone (applications qui déraillent, périphériques bluetooth non-reconnus, j’en passe et des pires…), on en vient à regretter l’époque où on se plaignait de son imprimante (ah ça, ça n’a pas changé…) !
Je n’exagère même pas : au fur et à mesure que le temps passe, nos voitures sont de plus en plus des “ordinateurs avec des roues” et les inévitables bugs les rendent souvent inutilisables. Un exemple : en mai 2020, le groupe Volkswagen a été obligé de retarder (encore) la sortie de sa nouvelle Golf 8 à cause d’un problème de logiciel. En cause, un problème lié au système d’appel d’urgence eCall qui a retardé l’arrivée effective sur le marché de la nouvelle Golf. Devenu obligatoire en Europe depuis le 31 mars 2018, le système d’appel d’urgence doit être fonctionnel et nécessitait donc une mise à jour pour les véhicules déjà produits. La Golf 8 n’est pas la seule à poser problème chez VW, la nouvelle ID.3 est elle aussi frappée par les bugs : des ingénieurs affirment que le développement a été « trop hâtif » et que les logiciels ont du mal à communiquer entre eux, entraînant de nombreux bugs électroniques. Des centaines de testeurs rapportent près de 300 erreurs par jour (en février 2020), obligeant Volkswagen à revoir sa copie.
Bien entendu, VW n’est pas le seul constructeur à souffrir de cette complexité logicielle, mais ces retards successifs ont fait grand bruit en Allemagne où l’on s’étonnait de voir la commercialisation de produits importants retardés pour des questions qui n’ont rien à voir avec ce que les constructeurs automobiles ont l’habitude de traiter.
Le mur de la complexité
On pourrait ainsi s’avancer à tracer une courbe en cloche avec en abscisse la complexité et en ordonnée le bien-être général :
La partie croissante représente le progrès garant de l’avenir, c’est-à-dire la complexité maîtrisée donc déterministe, la partie décroissante représente la chute où règne le chaos.
Source http://arnienathalaud.unblog.fr/divagations/3-de-la-complexite/
Erreur mineure, grandes conséquences potentielles
Un exemple du chaos entraîné par cet excès de complexité : une erreur logicielle mineure qui aurait pu compromettre le décollage d’un avion. C’est ce qui aurait pu se produire en juillet 2020 lors d’un vol reliant le Royaume-Uni et l’Espagne. Avant chaque vol, les passagers s’enregistrent et doivent préciser leur sexe. En fonction de la réponse, le logiciel estime un poids moyen en fonction de si on est un homme, une femme ou un enfant. Des informations importantes pour le pilote puisqu’avec une connaissance du poids total des passagers, le commandant de bord peut ajuster la vitesse et déterminer quelle puissance il doit mettre lors du décollage.
Lors de ce vol commercial du 21 juillet 2020 reliant Birmingham à Palma, il y avait 187 passagers à bord ainsi que 6 membres d’équipage. Après plusieurs mois sans être utilisé à cause du Covid-19, le logiciel d’enregistrement de l’opérateur TUI Airways a obtenu une mise à jour qui présentait un gros problème. L’ensemble des passagères qui avaient choisi le titre de « Mademoiselle » ont été considérées comme des enfants. Et c’est ici que réside le problème : le logiciel a considéré que les « Miss » étaient des enfants, estimant donc un poids moyen qui n’était pas le bon. Effectivement, la classification attribue un poids de 34 kg pour un enfant et de 69 kg pour une femme. À bord du Boeing, il y avait normalement 29 enfants de prévus or, avec cette erreur, la feuille de charge considérait qu’il y en avait 65 !
Générant ainsi au passage une différence de 1244 kg par rapport à la charge réelle de l’avion.
Une capture de l’écran du cockpit servant à définir les paramètres de la poussée au décollage…
Même si le pilote trouvait étonnant le nombre anormalement élevé d’enfants à bord, il s’est quand même basé sur cette information erronée pour préparer son décollage. Du coup, la vitesse programmée pour décoller était un poil trop faible…
En soi, les passagers à bord n’ont pas risqué leur vie, mais l’organisme britannique en charge des accidents aériens a tout de même qualifié cet incident de « grave ». Par ailleurs, sur la même journée, trois vols au départ de Birmingham ont également été victimes de ce bug. Plus grave, la compagnie aérienne avait connaissance du problème qui a duré une dizaine de jours. Des équipes avaient corrigé les erreurs sauf pour celles concernant les passagers qui s’étaient enregistrés 24 heures avant le vol en raison du départ en week-end des équipes. Cette histoire est emblématique des petits problèmes qui s’accumulent (mise à jour erronée, équipe non disponible, etc.) et qui finissent par déboucher sur une situation qu’on n’aurait jamais imaginée au départ (une erreur mineure sur le logiciel de gestion de l’embarquement qui impacte le décollage de l’avion…).
La civilisation de la panne
Bref, nous sommes passés d’une “civilisation de la peine” (où l’effort physique était prédominant et où tout le travail s’effectuait laborieusement “à la main et à la sueur de son front”…) à une “civilisation de la panne” (où la machine qui est censée nous soulager est trop souvent défaillante).
Partant du principe que l’automatisation croissante induit de plus en plus de complexité et démultiplie d’autant la probabilité de la panne, l’avenir serait donc pavé de… dysfonctionnements, comme on dit aujourd’hui par euphémisme. D’où cet axiome : La panne est consubstantielle à la technologie.
Yves Lasfargue recense des “points de fragilité” qui sont autant de causes de panne dans les systèmes d’informatisation et d’automatisation actuels. La multiplication et la complexité des composants dans les machines : la probabilité pour que la faucille tombe en panne est infiniment moindre que pour la moissonneuse-batteuse !
La fragilité apparaît donc comme la rançon de la complexité… et du confort, toute la question étant de savoir si le taux de pannes est supportable. L’intégration locale des composants explique qu’une panne de l’un des composants se répercute inéluctablement sur l’ensemble du système jusqu’à le paralyser.
Chacun connaît aujourd’hui les limites des systèmes automatisés : plus ils sont récents, plus ils sont intégrés, c’est-à-dire que les machines dépendent de plus en plus les unes des autres. Les systèmes « hautement intégrés », genre atelier robotisé ou réseau de communication, sont fragiles, délicats et présentent des risques de pannes non négligeables du fait des interrelations entre chaque composant.
Yves Lasfargue, directeur du Créfac dans “Robotisés, rebelles, rejetés”. Les éditions de l’Atelier, Paris, 1993.
La fiabilité des systèmes complexes
La fiabilité des systèmes complexes est devenue une denrée rare, car on ne laisse pas le temps à ces systèmes de mûrir. Un exemple parlant : les fusées. Les lanceurs utilisés pour mettre des satellites et des hommes en orbite autour de la Terre ne sont pas très nombreux et font l’objet de grandes attentions. Cela peut facilement se comprendre : les lancements coûtent très cher et les échecs sont le plus souvent des désastres complets (mort des astronautes et/ou perte totale de la charge utile).
Et pourtant, en dépit de ces enjeux, la fiabilité de ces lanceurs dépasse rarement les 50% (en clair, un lancement sur deux échoue). Il y a pourtant une exception : la fusée russe Soyouz affiche une fiabilité record. À fin 2017, plus de 1 880 lanceurs Soyouz ont été lancés, avec un taux de réussite proche de 98 %.
Comment expliquer cela ?
Eh bien, justement parce que les Russes ne sont pas repartis d’une feuille blanche pour faire évoluer leur fusée fétiche. Le lanceur Soyouz est mis en service en 1966. Il s’agit d’une évolution du lanceur Voskhod lui-même dérivé du missile balistique intercontinental R-7 Semiorka par adjonction d’un troisième étage. Quand on sait que le missile R-7 est lui un dérivé du fameux V2 conçu dans les années quarante par Von Braun, on comprend que la technologie embarquée dans les lanceurs russes bénéficie déjà d’un certain recul. On voit tout de suite la différence : dans ce domaine, la fiabilité ne s’obtient pas en quelques mois, mais bien en années, voire même en décennies.
La seconde crise du logiciel
Bien qu’il existe une littérature pertinente sur le sujet (j’ai déjà cité Jacques Ellul et je viens de le faire avec Yves Lasfargue), les risques liés à la croissance de la complexité sont trop souvent ignorés ou niés. En conséquence, je pense que nous allons droit vers une nouvelle “crise du logiciel”.
Cette seconde crise va être très différente de la première. Il y a soixante ans, la première crise du logiciel s’est déclarée quand on s’est rendu compte que le développement des programmes devenait le goulot d’étranglement de la mise en place des systèmes (les ordinateurs dans les organisations, principalement des mainframes). Aujourd’hui, cette nouvelle crise ne concerne pas la vitesse de développement, mais la fiabilité des systèmes qui repose sur une part croissante de logiciels.
Une première crise il y a 60 ans
Revenons rapidement sur les effets et les causes de ce qu’on a appelé “la crise du logiciel” dans les années 60 et 70. Au début des années soixante et avec le lancement de chaque nouvelle machine, le logiciel système fourni par IBM pour accompagner ses ordinateurs augmentait -en taille- d’un facteur dix tous les cinq ans !
En conséquence de cette “enflure”, on a estimé que la part du coût de développement des logiciels de base est passée de 10% en 1960 à 40% en 1965 sur le total du coût de mise en œuvre d’un nouveau système… C’est ainsi que s’est révélée la première « crise du logiciel » : le nombre d’installations de systèmes augmentait bien plus vite que le nombre de programmeurs formés, le logiciel devenait ainsi le goulot d’étranglement principal qui menaçait de mettre fin à la croissance de cette industrie.
Une première crise qui dure encore
Cette crise ne s’est jamais vraiment tout à fait résorbée, mais le secteur a appris à vivre avec jusqu’à aujourd’hui. La liste d’attentes pour les nouvelles applications a toujours été très (trop) longue dans toutes les organisations reposant sur l’informatique et c’est aussi la raison du développement du “shadow IT” : les départements lassés de devoir attendre leurs applications se sont souvent mis à les développer par eux-mêmes avec des outils no-code.
Une nouvelle crise, tu es sûr ?
Aujourd’hui, tout le monde est en train de réaliser que le logiciel est un élément essentiel dans les systèmes modernes. Le premier à l’avoir affirmé est Marc Andreessen dans son célèbre article “le logiciel mange le monde” (source https://a16z.com/2011/08/20/why-software-is-eating-the-world/) en 2011 dont voici un extrait :
Six décennies après la révolution informatique, quatre décennies depuis l’invention du microprocesseur et deux décennies après l’avènement de l’Internet moderne, toutes les technologies nécessaires pour transformer les industries grâce au logiciel fonctionnent enfin et peuvent être largement diffusées à l’échelle mondiale.
Plus de deux milliards de personnes utilisent aujourd’hui l’Internet haut débit, contre peut-être 50 millions il y a dix ans, lorsque j’étais chez Netscape, la société que j’ai cofondée. Au cours des 10 prochaines années, je m’attends à ce qu’au moins cinq milliards de personnes dans le monde possèdent des smartphones, donnant à chaque individu doté d’un tel téléphone un accès instantané à toute la puissance d’Internet, à chaque instant de chaque jour.
En arrière-plan, les outils de programmation logicielle et les services Internet facilitent le lancement de nouvelles start-ups mondiales basées sur des logiciels dans de nombreux secteurs, sans avoir besoin d’investir dans une nouvelle infrastructure et de former de nouveaux employés. En 2000, lorsque mon partenaire Ben Horowitz était PDG de la première entreprise de cloud computing, Loudcloud, le coût d’un client exécutant une application Internet de base était d’environ 150 000 $ par mois. L’exécution de cette même application aujourd’hui dans le cloud d’Amazon coûte environ 1 500 $ par mois.
Et, effectivement, tous ou quasiment tous les systèmes développés désormais contiennent systématiquement une part de logiciel, une part de plus en plus importante.
Après la version optimiste contenue dans l’article d’Andreessen, il est temps de passer à la version réaliste : le logiciel est de nouveau en crise parce que sa généralisation démontre son instabilité. La liste est longue des bugs rencontrés par ces “nouveaux consommateurs de logiciels” (constructeurs automobiles ou d’avions, entre autres). On pourrait en faire une liste, mais c’est inutile : tous les secteurs sont concernés, oui, tous !
Que ce soit VW ou Boeing (Boeing est en crise depuis les accidents affectant son 737 Max, encore une histoire de logiciels mal-conçus), leurs déboires avec les logiciels qui gèrent leurs voitures ou leurs avions font régulièrement les titres des journaux. Les professionnels de l’informatique sont habitués à rencontrer des bugs (et à tenter de les corriger), mais, cette fois, la nature même de ces bugs est différente.
La toujours délicate intégration de systèmes
En effet, il ne s’agit plus simplement d’ordinateurs isolés ou fonctionnant en réseau… Cette fois, on touche du doigt la limite induite par la toujours délicate intégration de systèmes. Pour commencer, ces logiciels s’exécutent dans des contextes où les tests et les corrections sont difficiles à réaliser à cause de la nature même des systèmes embarqués (allez donc traquer un bug qui ne se manifeste que dans certaines conditions d’un avion en plein vol…). Ensuite, les systèmes en question ne sont pas des éléments isolés (comme le sont les ordinateurs, qu’ils soient en réseau ou non), mais bien des éléments profondément dépendants des autres systèmes qui les entourent et les alimentent en données et mesures. Enfin, les organisations qui développent ces logiciels ne sont pas spécialisées en informatique, mais font cela en plus de leur domaine d’expertise habituel. Tout cela explique, au moins en partie, pourquoi ces bugs sont si fréquents, si bloquants et si difficiles (et coûteux !) à corriger.
Une situation qui est significative d’un nouveau contexte
Je pense que cette situation est significative d’un nouveau contexte. Il ne s’agit pas d’un épiphénomène qui apparaît brusquement pour disparaître une fois qu’on en aura pris la mesure. Je crois au contraire que c’est juste le début de nos difficultés en la matière. Il est possible, voire probable, que ce type de logiciel ne soit jamais totalement fiabilisé (tout comme il reste toujours des bugs dans nos programmes habituels). Dans le secteur informatique, on s’est adaptés à cette réalité souvent pénible, quelquefois douloureuse, mais qu’on sait inamovible. Dans les secteurs industriels cités, en revanche, je doute qu’on s’attendait à une telle non-fiabilité et qu’on n’ait pas encore réalisé qu’elle était quasi-impossible à améliorer radicalement.
La situation ne va donc pas s’améliorer, mais va empirer et le logiciel va devenir le facteur bloquant de l’évolution vers le toujours plus d’intégration et de fonctions intelligentes tout comme il a représenté le goulot d’étranglement des débuts de l’informatique.
Les tests logiciels sont lents et complexes
Écrire un logiciel est -relativement- rapide, mais le mettre au point est terriblement plus long, car les tests logiciels sont lents et complexes. Lents, car il y a de nombreuses possibilités à vérifier et il faut tout revérifier à chaque modification (tests de non-régression). Complexes, car le contexte est important et pour un logiciel système (par exemple), il faut pouvoir tester chaque plate-forme dans toutes les configurations possibles… On imagine vite ce que cela représente !
Logiciels et turbines à gaz, même combat !
Prenons un exemple, celui d’un « accident industriel » célèbre : les turbines à gaz GT24/GT26 d’Alstom qui se sont avérées défectueuses au début des années 2000. Pourquoi des engins aussi coûteux et complexes ont-ils été mis sur le marché sans être testés de fond en comble (ce qui aurait évité de commercialiser des turbines de grande puissance comportant un défaut de conception) ?
Tout simplement parce qu’il aurait fallu laisser tourner ces turbines pendant des années (quatre à cinq ans minimum !) avant que le défaut ne se manifeste… La rentabilité du programme ne pouvait s’accommoder de tests aussi longs, la direction de l’époque a donc pris le risque de se contenter des tests habituels qui étaient tout à fait satisfaisants…
Le schéma des turbines à gaz GT24/GT26 d’Alstom.
On est plus ou moins face au même dilemme avec les logiciels embarqués : il faudrait pouvoir les tester sur l’ensemble du cycle de vie et sur toutes les variations de plateformes possibles et il suffit de lire cette phrase pour penser immédiatement que ce n’est pas près d’arriver !
Les conséquences de la seconde crise du logiciel
La nouvelle crise du logiciel que nous sommes en train de vivre produit déjà des conséquences en cascade : la vague des ransomwares qu’on connaît depuis quelques années et qui va en s’amplifiant n’en est qu’un exemple.
Nous avons déjà évoqué les déboires du Boeing 737 Max mais imaginez cet exemple à l’échelle d’un système déployé globalement et concernant des millions d’unités… Du jour au lendemain, suite à une attaque ou à une mise à jour maladroite (ou à une attaque permise par une mise à jour mal-conçue…) deviendrait totalement inutilisable pour une période plus ou moins longue. Le futur sera sans doute fait de ces “tempêtes logicielles” qui vont rendre inopérants des pans entiers de notre infrastructure globale pendant des jours, des semaines voire des mois.
Qui n’est pas en faveur des smart grid ?
Une logique qui se comprend, mais qu’il faut éviter
Injecter du logiciel partout vient d’une logique facile à comprendre : pour augmenter la souplesse et la performance des systèmes distribués (distribution d’eau ou d’électricité par exemple), on va vers les fameuses smart grid qui promettent beaucoup, mais représentent aussi un réel danger latent. Le fait d’ajouter de la complexité à la complexité est rarement un bon calcul, comme on va s’en rendre compte douloureusement à l’avenir…