[7]
Titre : Décryptualité du 26 octobre 2020 - L'informatique est-elle devenue trop compliquée à développer ?
Intervenants : Manu - Luc
Lieu : April - Studio d'enregistrement
Date : 26 octobre 2020
Durée : 16 min
Écouter ou enregistrer le podcast [7]
Revue de presse pour la semaine 43 de l'année 2020 [8]
Licence de la transcription : Verbatim [9]
Illustration : Mannequin of a human figure sitting [10], Free SVG - Licence Creative Commons CC0 1.0 Universal Public Domain Dedication [11]
NB : transcription réalisée par nos soins, fidèle aux propos des intervenant·e·s mais rendant le discours fluide.
Les positions exprimées sont celles des personnes qui interviennent et ne rejoignent pas nécessairement celles de l'April, qui ne sera en aucun cas tenue responsable de leurs propos.
Description
Plus de lignes de codes, plus de technologies, plus de plateformes. Et si le développement informatique était devenu trop compliqué pour rester fun ?
Transcription
Luc : Semaine 43. Salut Manu.
Manu : Salut Luc.
Luc : Sommaire de la revue de presse.
Manu : Quelques jolis articles.
Luc : Gomet.
Manu : Tu es sûr que c’est Gomet ?
Luc : Oui, il y a une petite apostrophe à la fin, g, o, m, e, t.
Manu : Très bien !
Luc : Gomet, « Ateliers, plateforme, usages… la stratégie open data de Christophe Hugon pour Marseille », un article de Lena Cardo.
Manu : C’est une interview de Christophe Hugon, un conseiller municipal à Marseille et ça parle de transparence, open data, un peu de logiciel libre et même d’April. On aime bien, allez jeter un œil, c’est plutôt intéressant.
Luc : Silicon, « Open Source : les 5 engagements de la Commission européenne », un article de Ariane Beky.
Manu : Superbe idée : la Commission européenne avance sur les sujets qu’on aime, qu’on adore, il y a de super trucs qui s’ouvrent en ce moment. On en avait parlé dans le passé, des appels à aller creuser sur les bugs des logiciels pour essayer d’aider à les rendre plus solides. Là il y a des engagements. Je pense qu’on va en reparler dans les semaines qui viennent parce qu’il y a pas mal de choses qui se décantent autour de ça.
Luc : Clubic.com, « Google en justice : Mozilla ne veut pas être un dommage collatéral d'une éventuelle sanction », un article de Guillaume Belfiore.
Manu : La sanction c’est quoi ?
Luc : C’est la menace de se faire exploser par une procédure antitrust.
Manu : Anti-monopole, anti abus de position dominante, il y a plein de termes.
Luc : On se souvient que Microsoft avait échappé à ça il 10, 20 ans
Manu : De justice !
Luc : Et maintenant c’est Google qui est en quasi monopole sur le moteur de recherche, qui est dans la ligne de mire
Manu : Et ça peut poser problème à Mozilla parce que ?
Luc : Ils sont dépendants de l’argent de Google.
Le Monde.fr, «La justice américaine ouvre une procédure contre Google pour abus de position dominante ».
Manu : Eh bien voilà !
Luc : Il aurait fallu le mettre avant !
Developpez.com, « Le Conseil d'État autorise Microsoft à héberger les données de santé des Français », un article de Stéphane le Calme. Consternation !
Manu : Il n’y a aussi un souci, on peut faire héberger les données de santé par Microsoft aux États-Unis. En plus, les raisons qu’ils ont données pour cela sont très bonnes et bien solides. On s’attendait forcément à des trucs brillants.
Luc : En gros c’est : on n’a aucune preuve que le gouvernement américain va demander à Microsoft de faire fuiter les données.
Manu : Et que Microsoft ne va pas résister à cette demande. Après tout, peut-être que c’est dans la loi américaine, non !
Luc : Et puis ce n’est pas comme si on avait fait sauter le Privacy Shield1 récemment en mode on n’a plus trop confiance en nos bons alliés. Donc décision du Conseil d’État assez incompréhensible.
Manu : Dépitant ! Ça pue ! En plus de ça, ils disent : « Il n’y a pas de souci, les données vont être anonymisées, il n’y a aucun risque, ne vous inquiétez pas ! » Ce n’est pas comme s’il y avait la NSA avec des équipes de mathématiciens qui sont capables d’enlever cette anonymisation facilement. Non, il n’y a pas de risque.
Luc : Même anonymement, ce sont des statistiques, ce sont beaucoup d’informations qui peuvent être intéressantes d’un point de vue industriel, commercial.
Manu : Stratégique !
Luc : On rappelle que la première activité de la NSA ce n’est pas de combattre le terrorisme, c’est de faire de l’espionnage industriel.
Manu : C’est toi qui le dis !
Luc : Oui ! Manifestement.
Manu : C’est quoi le sujet de cette semaine ?
Luc : C’est compliqué.
Manu : Comment ça c’est compliqué. Tu n’as pas de sujet ?
Luc : Si, si, c’est compliqué.
Manu : Tu n’as pas compris !
Luc : Si, j’ai compris. L’idée c’était de parler de la complexification de l’informatique. Je suis tombé sur un petit article qui explique, une étude qui dit qu’aujourd’hui les développeurs doivent travailler sur des projets beaucoup plus complexes qu’avant. Déjà parce qu’il y a beaucoup plus de lignes de code, ça s’est beaucoup enrichi, souvent avec plusieurs technos, sur plusieurs plateformes, notamment s’ils travaillent sur du mobile ou des choses comme ça, et que les informaticiens d’aujourd’hui sont bien plus mis à l’épreuve et ont beaucoup plus de choses à gérer que les informaticiens du passé.
Manu : Je ne peux que aller dans ce sens-là, effectivement avec le temps, je constate qu’on doit maîtriser et j’essaye de maîtriser de plus en plus de technologies. C’est un panel de choses à connaître et à comprendre, d’outils, de logiciels, de techniques, qui ne fait qu’évoluer. Et quand il y a une évolution de ce type-là, c’est souvent une évolution par l’addition : on additionne des nouvelles technologies, des nouveaux outils, qu’il faut maîtriser à un moment donné. J’ai 20 ans d’expérience derrière moi, c’est mon boulot à temps plein.
Luc : Une espèce de vieux con !
Manu : Exactement. Là je peux le réclamer, 20 ans c’est de l’expertise ! Eh bien je constate que je continue à rajouter des techniques sur les anciennes et je ne perds pas complètement de vue ce que j’ai déjà appris dans le passé, ça se complexifie dans ce sens-là.
Luc : Oui et il y a aussi le fait que l’informatique fait des trucs de plus en plus compliqués. On additionne petit à petit. Aujourd’hui, si on sort un logiciel qui ressemble à ce qui se faisait il y a 20 ans, tout le monde rigole et personne ne l’utilise. De fait, on a des outils et on se dit « tiens, on va remettre de l’argent pour refaire quelque chose », mais on veut gérer plus de choses, on veut faire communiquer des systèmes différents, on veut gérer des volumes de données de plus en plus importants. Et c’est assez naturel puisqu’on construit sur les fondations de ce qu’on a déjà, donc on va forcément dans le mouvement de plus en plus de complexité.
Alors, avant c’était mieux ?
Manu : Avant ? Tu penses à quoi ? Les années 80, les années 60, les années 40 où il fallait utiliser des machines physiques et les bugs étaient des insectes qui se promenaient derrière les diodes ou les lampes à incandescence ?
Luc : Je ne sais pas jusqu’où il faut remonter.
Manu : Il y avait des cartes perforées.
Luc : Ce n’était peut-être pas plus simple, mais le code était beaucoup plus facile.
Manu : Il était plus court parce qu’il y en avait moins.
Luc : J’avais un collègue qui était assez âgé, il travaillait encore à 65 ans, il y a quelques années de ça, et il m’expliquait que quand, jeune étudiant, il avait étudié l’informatique, en fait il n’y avait qu’un seul ordinateur dans l’école. Ils écrivaient leur code sur du papier, le donnaient à la secrétaire de l’école qui tapait le soir les codes dans l’ordinateur et qui, le lendemain, leur donnait des sorties papier en disant « voilà ce que ça a donné ».
On imagine le chemin parcouru et à l’époque, effectivement, le code n’était pas important. On cite par exemple le code de la mission Apollo sur le peu d’informatique qui était embarquée, aujourd’hui c’est ridicule ! La moindre calculette embarque plus !
Manu : Oui, c’est assez sidérant et je sais que les gars de l’époque qui se sont replongés sur ça ont refait des simulations, des outils qui permettent de faire tourner ce code, eh bien ils se rendent compte que c’était d’une simplicité énorme parce que c’était tout petit. Et c’était nécessairement petit parce qu’il n’y avait pas beaucoup de stockage possible. Même dans les années 80, on disait « on n’aura jamais besoin d’une taille énorme – je ne sais plus ce que c’était – de 600 kilooctets, au-delà ça ne servira à rien parce que de toute façon on peut tout faire dans ce genre de taille. »
Luc : On a encore aujourd’hui des systèmes qui sont assez anciens, notamment dans l‘aviation, on en parlait la semaine dernière, notamment du Boeing 737 Max et une des difficultés qu’ils ont avec cet avion-là, c’est que les calculateurs embarqués sont de très vieux machins, qui ont je ne sais plus combien.
Manu : Quelques dizaines d’années probablement.
Luc : Quelques dizaines d’années, à qui, du coup, on demande tellement de trucs et tellement de trucs nouveaux qu’ils sont ras la gueule.
Manu : Ce sont d’ailleurs les mêmes problématiques dans l’espace, parce que dans l’espace on ne peut envoyer que du matériel qui est solide face aux radiations, donc on ne prend pas du matériel hyper-récent.
Luc : Et qui consomme très peu en plus.
Manu : Voilà. Et qui doit être fiable, donc il a tellement de requis qu’on utilise souvent des vieux microprocesseurs. Je sais que les 486 ont tourné pendant longtemps dans l’espace.
Luc : Il y a une unité de mesure de la complexification qui s’appelle le Doom, tu connais ?
Manu : Le quoi ?
Luc : Ce n’est pas une vraie unité de mesure, mais assez souvent on voit des gens qui font des tests. Il y a quelques années, on avait dit que la taille d’une page web moyenne est supérieure à Doom, au code du jeu Doom qui était le premier jeu en 3D.
Manu : Duke Nukem 3D2.
Luc : Non !
Manu : C’était le nom du jeu.
Luc : Doom3, c’était le nom du jeu. Pour la petite anecdote ce n’était pas vraiment un jeu 3D, même si la représentation était de la 3D, en fait ça gérait de la 2D.
Manu : En gros il fallait tuer des monstres et des nazis. Il y avait peut-être des nazis ? C’était ce jeu-là ?
Luc : Non, ce sont des monstres.
Manu : Des monstres. D'accord.
Luc : Ce n’est déjà pas mal. Du coup on avait dit ce jeu qui avait été un grand succès, sur lequel des gens, dont je fais partie, ont passé de heures.
Manu : J’ai dû y jouer aussi, mais ça date trop, j’ai oublié.
Luc : Voilà ! Tu n’assumes pas ! Aujourd’hui une page moyenne sur Internet est plus lourde que ce jeu qui a occupé des gens et sur lequel on a bossé, etc. Récemment, il y a eu un autre exemple où des gens ont réussi à faire tourner Doom, c’est pour ça que c’est une unité de mesure, sur un test de grossesse.
Manu : Un test… Le petit bâton qu’on doit mettre sous l’urine pour vérifier…
Luc : C’est ça, dans lequel il y a une petite puce, je ne sais pas comment ça marche, mais il y a un petit peu d’électronique embarquée et les gens ont mis dessus et ont dit « est-ce qu’on peut faire tourner Doom ? » Il y a un petit écran, minuscule, du coup ils ont réussi à faire tourner Doom dessus.
Manu : Waouh ! On fait vraiment n’importe quoi avec son temps aujourd’hui.
Luc : Ce qui démontre qu’aujourd’hui on a évidemment une puissance de calcul très importante, mais la taille des logiciels a explosé. Par exemple, je me souviens qu’au début des années 2000, il y avait toute la question de la gestion des bugs. C’est-à-dire qu’avant, quand les logiciels étaient plus petits, on était dans un mode de développement plutôt artisanal.
Manu : Largement artisanal !
Luc : Il y a eu un moment, dans le monde informatique, où il a fallu mettre en place des outils et des méthodes pour gérer les bugs. C’est-à-dire qu’avant on disait « il y a un bug, ça ne marche pas » ; il y avait relativement peu de tests à faire parce qu’il y avait relativement peu de fonctionnalités, les gens connaissaient leur code et quand quelque chose plantait hop, hop ils retrouvaient. Avec des logiciels de plus en plus complexes, cette question de la quantité de bugs, un, on est sûr qu’il y en aura, il y en aura toujours, et deux, la quantité de bugs fait qu’on ne pouvait plus les gérer en disant je note ça dans un coin et je vais regarder.
Manu : Un, non, il n’y a pas toujours des bugs ! Moi, dans mes logiciels, il n’y a pas de bugs. Je te demanderai de prouver qu’il y en a et de les reproduire devant moi !
Luc : D’accord, c’est comme les données de la Sécurité sociale chez Microsoft, il va falloir prouver que ça peut se passer.
Manu : C’est ça ! Effectivement, il y a toujours des bugs et on se rend compte qu’ils ont développé des forges, des outils et des méthodologies qui permettent de prendre en compte des méthodes de travail qui permettent d’évoluer avec la taille des logiciels.
Souvent, on partait sur des gros logiciels et des grosses équipes, sur des cycles en V, c’est comme ça qu’on disait, mais effectivement il y a eu beaucoup d’évolutions sur ça et on fait changer les choses pour faciliter la vie.
Luc : Le cycle en V4, rien à voir avec le col en V du pull, c’est un système d’organisation et de conduite de projet issu de l’industrie, où on va avoir une phase « descendante », entre guillemets, où on va tout spécifier, mettre sur le papier en disant « je veux ceci, je veux cela ».
Manu : En allant du général au détail.
Luc : C’est ça, en rentrant dans le détail, en faisant des plans de gestion des risques, en disant « qu’est-ce qui peut mal se passer, etc. » Une fois qu’on a tout bien écrit, c’est la phase montante où on réalise. C’est un cycle qui a du sens quand on est dans le domaine de la construction, de l’industrie, etc., parce que, si on fait par exemple un bâtiment, au moment où on a commencé à couler le béton, c’est un peu tard pour dire « en fait je voulais mettre un escalier là. »
Manu : Je trouve qu’en informatique c’est même pire parce que souvent on code en bas du V, le reste ce sont ce sont les tests, l’intégration, la documentation qui est souvent mise après. Et ça c’est un système qui était affreux parce qu’on se rendait compte qu’on entrait dans des tunnels de travail pendant un an ou deux et, au bout de deux ans, on sortait avec un produit que personne n’attendait. On avait oublié ce qu’on avait exactement demandé au départ.
Luc : Archétype de ce projet lourdingue qui va dans le mur c’est Louvois [logiciel unique à vocation interarmées de la solde] qu’on aime bien critiquer.
Manu : Oui, ça fait toujours plaisir parce que c’est un gros projet de l’État français pour gérer les payes.
Luc : La paye des militaires.
Manu : Donc un sujet qui apparaît quand même assez cadré, assez solide, parce qu’on maîtrise normalement.
Luc : Normalement oui, mais très compliqué parce que les militaires se promènent à droite, à gauche, ils partent en opération, ils vont faire ceci, ils vont faire cela. À chaque fois, du coup, il y a des primes et des systèmes de paiement qui sont différents et c’est un gros merdier administratif.
Manu : Et le logiciel Louvois, qu’est-ce qu’il a donné une fois qu’il a été développé ?
Luc : Eh bien ça a été une catastrophe. Tout a été jeté, ça a coûté vraiment très cher, ça se compte, je crois, en centaines de millions d’euros. Le pire est qu’au départ du projet il y a eu un audit qui a dit « ça ne marchera pas ». En fait, personne n’a pris la décision de ne pas y aller, ça a été développé, des fortunes d’argent public ont été déversées là-dedans, les militaires n’ont pas été payés, trop payés, etc., c’était un merdier.
Manu : Je crois même qu’ils sont repassés au papier pour certains parce qu’ils voulaient être sûrs de les payer. Tout simplement.
Luc : Oui. Ils n’en pouvaient plus tout ça pour tout jeter à la poubelle. Et des projets de ce type-là il y en a eu d’autres.
Manu : Il y en a plein. On sait qu’en Grande-Bretagne ils ont eu des problèmes avec des projets qui tournent autour de la sécurité sociale et puis il y a sûrement plein de choses qu’on oublie, qu’on va se dépêcher d’oublier.
Luc : Trop compliqué ! Est-ce qu’il n’y a pas un seuil au-delà duquel on n’arrive plus à rien ? En plus de ça c’est trop compliqué pour le faire et, en plus, ça devient chiant pour les gens. C’est-à-dire que c’est tellement lourdingue, il faut rentrer dans le détail que ça devient difficile de motiver des gens pour bosser là-dessus parce que c’est juste pas fun.
Manu : Effectivement, on se rend compte qu’on arrive à des limites. Heureusement il y a des évolutions et il y a des innovations, notamment sur la méthodologie. Tu parlais notamment du cycle en V tout à l’heure, on a inventé des nouvelles choses qui sont largement portées par le logiciel libre et Internet en général. Il y a une dont on aime parler régulièrement…
Luc : La méthode agile5.
Manu : Ce n’est pas Gilles Vervisch ou autre. C’est une méthode qui recommande l’agilité. Effectivement on est orienté sur peu de procédures, des petites équipes, une responsabilité individuelle qui est mise en avant. Et puis il y a quelques caractéristiques qui peuvent se décliner, parce que la méthode agile est quelque chose de très général et très générique. Ensuite on la décline et il y a plein de manières de la mettre en place. Un des avantages de ça c‘est qu’on a beaucoup simplifié la manière de travailler. Déjà, on ne travaille plus dans ce système de tunnel où on donne des spécifications générales détaillées, ensuite on implémente et finalement on teste et on met en place. Non ! On met en place le plus vite possible, parfois en quelques jours ou quelques semaines, ça peut aller très vite.
Luc : Il y a également au niveau de la technique, de l’informatique, des choses qui simplifient le boulot avec notamment les frameworks.
Manu : Par exemple, c’est-à-dire que c’est de l’outillage. En gros un framework être un échafaudage qui va nous mettre en place tout de suite des mécanismes de base.
Luc : Et des modules.
Manu : Oui. En veux-tu en voilà, il y a de quoi faire. Il y a aussi une évolution, je ne sais plus comment on dit, mais il y a du code qui est de bas niveau et on va monter en niveau dans le code et dans les langages.
Luc : C’est-à-dire qu’au lieu de dire à la machine « tu vas gérer la mémoire comme ça, là tu vas faire ceci, là tu vas faire cela », ce sont des choses qui vont être prises en charge par du code déjà existant et on va se concentrer sur un niveau plus près de la fonctionnalité.
Manu : Exactement. Et cette façon de voir les outils et de les appréhender c’est une évolution qui est assez considérable. En gros on ne travaille plus avec des petits Lego, on travaille avec de plus grosses briques qui vont nous permettre d’aller beaucoup plus vite et de ne pas avoir à se soucier à des détails. Et c’est souvent dans les détails, notamment parce qu’on a fait plein de lignes de code, qu’on va introduire plein de bugs, plein de problèmes. Effectivement aujourd’hui, avec la méthode agile et en se concentrant sur des petits projets qui en rassemblent d’autres, eh bien on peut faire des projets qui sont quasiment sans bug.
Luc : On rappelle que la Cour des comptes avait audité, en gros, l’informatique de l’État et avait dit « faites de l’agile, faites des petites équipes, réintégrez des compétences au sein de l’État », parce que, et c’est typique du cycle en V, il avait tendance à dire « on spécifie, on n’a pas besoin de connaître et on demande à des gens de faire ». En fait, quand on veut bien faire, il faut connaître. « Faites des petits projets qui sont agiles, qui vont vite, qui permettent de gagner du temps. »
Manu : En râteau, avec peu de chefs, avec peu d’administration.
Luc : Oui, et sans essayer de faire un énorme paquebot et à la fin on arrivera peut-être à faire, justement, que tous ces systèmes se parlent et à faire quelque chose qui fonctionne mieux.
Manu : J’ai l’exemple d’un truc qui marche largement comme ça, c’est le noyau Linux6 qui est développé par des milliers de personnes dans le monde entier, des experts, qui arrivent, bon an mal an, à le faire évoluer. On l’a aujourd’hui dans nos poches sous la forme d’Android.
Luc : Et aussi plein de grosses entreprises qui sont normalement concurrentes et qui arrivent à contribuer ensemble au noyau en dépit de la complexité du projet.
Du coup l’informatique reste toujours un truc intéressant malgré la lourdeur, la complexité ?
Manu : Non, parce que ça se simplifie en permanence. On a de nouvelles manières de l’accaparer. J’adore justement faire évoluer ma manière de travailler pour me simplifier la vie, c’est un peu le but, ça fait 20 ans que je cherche à simplifier toujours plus et à toujours moins faire en préparant mieux, en organisant mieux, en ayant plus de facilité avec mes outils.
Luc : On va se simplifier la vie en ne faisant pas de petite blague pour la conclusion. On se retrouve la semaine prochaine.
Manu : À la semaine prochaine.