Le monde du logiciel est en train de se détruire… Manifeste pour un développement plus durable

Posted on by Olivier PHILIPPOT
Reading Time: 21 minutes

Le monde du logiciel va mal et si l’on n’agit pas, on risque de le regretter. Environnement, qualité, exclusion… Software Eats The World (Le logiciel mange le monde…) ? Oui un peu trop.

Le monde du logiciel va mal. Enfin, en surface, tout va bien. Comment un domaine porteur d’autant de promesses économiques pour le bien-être de l’humanité pourrait aller mal ? Se poser la question pourrait être une remise en question de tout cela. Alors tout va bien. On avance, et on ne se pose pas trop de question.

Le monde du logiciel va mal. Pourquoi ? 20 ans d’expérience dans le monde du logiciel en tant que développeur, chercheur ou CTO m’ont donné la chance de côtoyer différents domaines et d’avoir ce sentiment qui se renforce d’année en année. J’ai passé en particulier les 6 dernières années à essayer de pousser des pratiques, des outils de qualité logicielle afin de sensibiliser les développeurs sur l’impact du logiciel sur l’environnement. Il faut être sévèrement motivé pour penser améliorer le monde du logiciel. Les bonnes pratiques ne passent pas aussi facilement que les nouveaux framework Javascript. Le monde du logiciel n’est pas perméable aux améliorations. Ou en tout cas seulement à celles de surface, pas en profondeur.

Le monde du logiciel va mal. Tout est lent, et cela ne va pas dans le bon sens. Certaines voix s’élèvent. Je vous invite notamment à lire « Le désenchantement du logiciel ». Tout est insupportablement lent, tout est ÉNORME, tout finit par devenir obsolète… La taille des sites web explose. Un site web est aussi gros que le jeu Doom. Le phénomène ne touche pas que le Web mais aussi l’IoT, le mobile… Le saviez-vous ? Il faut 13% de CPU pour faire clignoter un curseur…

Ce n’est pas le message d’un vieux développeur fatigué par les constantes évolutions et nostalgique du bon vieux temps des disquettes… C’est plutôt un appel à une profonde remise en question de la façon dont nous voyons et développons le logiciel. Nous sommes responsables de cette « non-efficience »(Développeurs, chefs de projet, commerciaux…). Dire que tout va bien ne serait pas raisonnable, mais dire que tout va mal sans proposer de piste d’amélioration le serait d’autant plus.

Disclaimer : Vous allez surement bondir, appeler au FUD, au troll, contredire… en lisant cet article. C’est très bien mais SVP, allez jusqu’au bout !

On grossit (trop)

Tout grossit : la taille des applications, les données stockées, la taille des pages web, la mémoire des téléphones… Les téléphones ont maintenant 2 Go de mémoire, échanger une photo de 10 Mo par mail est maintenant classique… À la limite, cela ne serait peut-être pas un problème si tous les logiciels étaient utilisés, efficaces et performants… Mais cela n’est pas le cas, je vous laisse parcourir l’article « Le désenchantement du logiciel » pour avoir plus de détail. Il est difficile de dire si beaucoup de personnes ont ce sentiment de lourdeur et de lenteur. Et en même temps, tout le monde s’est habitué à cela. C’est l’informatique. Comme les bugs, « votre salaire n’a pas été versé ? Ahh… cela doit être un bug informatique ». L’informatique, c’est lent, et on n’y peut rien. Si on y pouvait quelque chose, c’est sûr, on aurait déjà résolu le problème.

Alors tout le monde se cale sur une lenteur. Tout est uniformément lent. On se cale sur cela et tout va bien. Être performant aujourd’hui, c’est arriver à atteindre un ressenti utilisateur qui correspond à cette lenteur uniforme. On élague les choses qui pourraient être trop visibles. Une page qui met plus de 20 secondes à se charger, c’est trop lent. Par contre, 3 secondes c’est bien. 3 secondes ? Avec les multicoeurs de nos téléphones/PC et les data centers partout dans le monde, le tout relié par des supers technologies de communication (4G, fibre…),c’est un peu bizarre non ? Si on regarde la débauche de ressources pour le résultat obtenu, 3 secondes, c’est énorme. D’autant plus que les bits circulent dans nos processeurs avec des unités de temps du niveau de la nanoseconde. Donc oui, tout est uniformément lent. Et cela convient à tout le monde (du moins, en apparence.) La performance Web (suivez le hashtag #perfmatters) est nécessaire mais c’est malheureusement un domaine qui ne va pas assez loin. Ou peut-être que la réflexion dans ce domaine ne peut pas aller plus loin parce que le monde du logiciel n’est pas assez perméable ni sensibles à ces sujets.

On trouve même maintenant des pratiques pour ne pas résoudre le problème mais le contourner, et c’est un domaine à part entière : travailler sur la « performance perçue » oucomment utiliser la perception du temps par l’utilisateur pour mettre en place des mécanismes pour ne pas trop optimiser. Le domaine est passionnant du point de vue scientifique et humain. Du point de vue performance et efficience logicielle, un peu moins. « Trouvons pleins de mécanismes pour ne pas optimiser trop ! ».

Tout cela serait à la limite acceptable dans un monde avec des exigences médiocres sur la performance de nos applications. Le problème est que pour absorber cette non performance, on « scale« . Verticalement en rajoutant des processeurs ultra-puissants et plus de mémoire, horizontalement en rajoutant des serveurs. Vive la virtualisation qui nous a permis d’accélérer cette course à l’armement ! Sauf que sous les bits, il y a du métal et le métal c’est coûteux, et c’est polluant.

Oui, cela pollue : il faut beaucoup d’eau pour construire des puces électroniques, de produits chimiques pour extraire des terres rares, sans parler des allers-retours partout dans le monde… Oui, la lenteur uniforme a quand même un coût certain. Mais nous y reviendrons plus tard.

Il est nécessaire de revenir à plus d’efficience, de « challenger » les besoins en matériel, de redéfinir ce qu’est la performance. Tant que l’on se satisfera de cette lenteur uniforme avec des solutions pour ne pas ralentir plus (comme l’ajout de matériel), nous n’avancerons pas. La dette technique, notion largement assimilée par les équipes de développement, n’est malheureusement pas adaptée à ce problème (on y reviendra). Nous sommes sur une dette de ressources matérielles et de mauvaise adéquation entre le besoin utilisateur et la solution technique. On parle ici d’efficience et non pas uniquement de performance. L’efficience est une histoire de mesure du gaspillage. L’ISO définie l’efficience avec comme domaine : Time behaviour, Resource utilization et Capacity. Pourquoi ne pas pousser plus ces concepts ?

On est (trop) virtuel

Une des problématiques est que le logiciel est considéré comme « virtuel ». Et c’est bien là, le problème.« Virtuel » définit ce qui n’a pas d’effet (« Qui n’est qu’en puissance, qu’en état de simple possibilité par opposition à ce qui est en acte » selon le Larousse). Peut-être que cela vient du début des années 80 où le terme virtuel était utilisé pour parler du Numérique (par opposition au monde du Matériel). « Numérique » est relatif à l’usage des nombres (les fameux 0 et 1). Mais bon, numérique , ce n’est pas assez in et cela inclut un peu trop le matériel. Utilisons le terme Digital ! Digital/Numérique, c’est une discussion en France qui peut sembler idiote mais qui est importante dans la problématique dont nous discutons. En effet, le digital cache encore plus cette partie matérielle.

Or, il ne faut pas le cacher : les services numériques sont bien composés de code et de matériel, de 0 et 1 qui circulent sur du matériel bien réel. On ne peut pas programmer sans oublier cela. Un bit qui va rester sur le processeur ou traverser la terre ne va pas prendre le même temps, ni utiliser les mêmes ressources :

Développez du code Java pour un serveur J2EE ou pour un téléphone Android, ce n’est pas pareil. Des structures spécifiques existent par exemple pour traiter des données en Android mais les structures classiques sont toujours utilisées. Les développeurs ont perdu le lien avec le hardware. C’est malheureux car c’est passionnant (et utile) de savoir comment fonctionne un processeur. Pourquoi : abstraction et spécialisation (nous verrons cela plus loin). Car en perdant ce lien, on perd une des forces du développement. Ce lien est important chez les hackers ou chez les développeurs d’informatique embarquée mais malheureusement de moins en moins présent chez les autres développeurs.

Les pratiques devops pourraient répondre à cette perte de lien. Là, c’est pareil, nous n’allons pas jusqu’au au bout : généralement le devops va se focaliser à bien gérer le déploiement d’une solution logicielle sur une infrastructure mixte (matérielle et un peu logicielle). Il faudrait aller plus loin en remontant par exemple les métriques de consommation, en discutant sur les contraintes d’exécution… plutôt que de « scaler » juste parce que c’est plus simple.

On pourra toujours justifier cet éloignement du matériel : productivité, spécialisation… mais il ne faut pas confondre séparation et oubli. Séparer les métiers et se spécialiser, oui. Mais oublier qu’il y a du matériel sous le code, non ! Une première étape serait de remettre des cours sur le matériel au sein des écoles. Ce n’est pas parce qu’uneécole forme à la programmation qu’une sensibilisation sérieuse au matériel et à son fonctionnement n’est pas nécessaire.

On est (trop) abstrait

On est trop virtuel et éloigné du matériel parce que l’on a voulu s’en abstraire. Les multiples couches d’abstraction ont permis de ne pas se préoccuper des problématiques matérielles, de gagner du temps… Mais à quel prix ? Celui de la lourdeur et de l’oubli du matériel, comme on l’a vu, mais bien plus encore. Comment comprendre le comportement d’un système avec des stacks d’appels supérieurs à 200 ? :

Certaines technologies ont une utilité mais sont maintenant systématiquement utilisées. C’est le cas par exemple des ORM qui sont devenus systématiques. Aucune réflexion n’est faite sur son intérêt en début des projets. Résultat : on a rajouté une surcouche qui consomme, qu’il faut maintenir et des développeurs qui n’ont plus l’habitude d’effectuer des requêtes natives. Cela ne serait pas un problème si chaque développeur connaissait très bien le fonctionnement des couches d’abstraction : comment fonctionne HIBERNATE par exemple ? On s’appuie hélas de façon aveugle sur ces frameworks.

Ceci est très bien expliqué dans la loi de Joel Spolsky « The Law of Leaky Abstractions »

And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder. (…) Ten years ago, we might have imagined that new programming paradigms would have made programming easier by now. Indeed, the abstractions we’ve created over the years do allow us to deal with new orders of complexity in software development that we didn’t have to deal with ten or fifteen years ago (…) The Law of Leaky Abstractions is dragging us down.

On attend (trop) la solution miracle

Le besoin d’abstraction est lié à un autre défaut: nous attendons toujours des outils miracles. La silver bullet qui améliorera encore plus nos pratiques. Le langage idéal, le framework pour aller plus vite, l’outil de gestion miracle des dépendances… C’est la promesse à chaque fois d’un nouveau framework : gagner du temps en développement, être plus performant… Et on y croit, on fonce. On abandonne les frameworks sur lesquels nous avions investi, sur lesquels on avait passé du temps… et on passe au nouveau. C’est le cas actuellement des frameworks JS. L’histoire du développement est pavé de framework oubliés, non maintenus, abandonnés… Nous sommes les champions pour réinventer ce qui existe déjà. Si on le gardait suffisamment longtemps, on aurait le temps de maîtriser un framework, de l’optimiser, de le comprendre. Mais ce n’est pas le cas. Et que l’on ne me dise pas que si on n’avait pas continuellement réinventé la roue, on aurait encore des roues en pierre… Innover serait d’améliorer les frameworks existants .

C’est aussi le cas pour les gestionnaires de paquets : Maven, NPM… Au final, on arrive à un enfer. Le lien avec l’abstraction ? Plutôt que de gérer ces dépendances en dur, on met une couche d’abstraction qu’est le gestionnaire de paquets. Et l’effet de bord : c’est que l’on intègre (trop) facilement du code extérieur que l’on ne maîtrise pas. Là encore, nous y reviendrons.

Sur les langages, c’est la même rengaine. Attention, je ne préconise pas de rester sur l’assembleur et sur le C… C’est le cas par exemple dans le monde Android, pendant plus de 10 ans les développeurs ont pu travailler sur des outils et des frameworks Java. Et comme cela, par magie, le nouveau Langage de la communauté est Kotlin. On imagine l’impact sur les applications existantes (si elles doivent changer), il faut recréer des outils, retrouver des bonnes pratiques… Pour quel gain?

Today the Android team is excited to announce that we are officially adding support for the Kotlin programming language. Kotlin is a brilliantly designed, mature language that we believe will make Android development faster and more fun. Source« 

On y reviendra sur le « fun« …

Sincèrement, on ne voit aucun ralentissement sur les cycles de renouvellement des technologies. C’est toujours un rythme frénétique. Nous trouverons bien le Graal un jour. Le problème est ensuite l’empilement de ses technologies. Comme aucune ne meurt vraiment et que l’on en maintient toujours des parties, on développe d’autres couches pour s’adapter et continuer à maintenir ces bouts de code ou ces librairies. Le problèmen’est pas le code legacy,, c’est la glue que l’on développe autour qui pêche. En effet, comme le récitait l’article sur « le désenchantement logiciel » :

@sahrizv :

2014 – On doit adopter les #microservices pour résoudre tous les problèmes liés aux monolithes.

2016 – On doit adopter #docker pour résoudre tous les problèmes liés aux microservices.

2018 – On doit adopter #kubernetes pour résoudre tous les problèmes avec Docker.

Au final, on passe du temps à résoudre des problèmes techniques internes, on recherche des outils pour résoudre les problèmes que l’on ajoute, on passe son temps à s’adapter à ses nouveaux outils, on ajoute des surcouches (voir chapitre précédent…) … et on n’a pas améliorer la qualité intrinsèque du logiciel ou les besoins auxquels on doit répondre.

On n’apprend pas (assez)

Au final, le rythme frénétique des changements ne nous permet pas de nous stabiliser sur une technologie. J’avoue qu’en tant que vieux développeur que je suis, j’ai été découragé par le changement Java vers Kotlin pour Android. C’est peut-être pour certains de véritables challenges, mais quand je repense au temps que j’ai passé sur l’apprentissage, sur la mise en place d’outils.. Il faut partir d’assez loin mais pas de 0. Il est normal, dans un métier, de continuellement apprendre et ếtre curieux. Mais cela reste dans le cadre d’itération pour expérimenter et s’améliorer. Ce n’est pas le cas dans la programmation. En tout cas dans certains domaines de la programmation, car pour certaines technologies, les développeurs continuent à expérimenter (.Net, J2EE..). Mais ce n’est effectivement pas fun…

Enfin, on apprend : on passe notre temps sur les tutoriels, getting started, les conférences, les meetups… Pour finalement n’en expérimenter que 10% dans un project side ou même un POC, qui deviendra sûrement un projet en production.

Ensuite, comme aucune solution ne meurt vraiment, que de nouvelles arrivent… on se retrouve avec des projets avec des multitudes de technologies à gérer avec les compétences associées aussi… On s’étonne ensuite que le marché du recrutement de développeur soit bouché. Pas étonnant.. Il y a énormément de développeurs mais il est difficile de trouver un développeur React avec 5 ans d’expérience qui connaîsse le Go. Le marché est fractionné, comme les technologies. C’est peut-être bon pour les développeurs car cela crée de la rareté et cela fait monter les prix, mais pas pour le projet !

Pour revenir au chapitre précédent (Recherche des outils miracle…), on le voit dans le monde Javascript avec la « JS fatigue ». Le développeur doit faire son chemin dans le monde du Javascript et des outils associés. C’est le prix de la multitude d’outils. C’est une approche compréhensible (voir par exemple une très bonne explication de cela). Cependant, cet apprentissage continu des technologies pose le problème d’apprentissage de domaines transverses : accessibilité, agilité, performance… En effet, qu’est-ce qui nous prouve que les outils et les langages que nous allons choisir ne vont pas changer dans 4 ans ? Rust, Go… dans 2 ans ? Rien ne tend à donner une tendance.

On s’amuse (trop) et on ne se remet pas (assez) en cause

Enfin, sauf si c’est dans l’objectif de remettre une technologie en cause pour en trouver une autre. Le troll est chose commune dans notre monde (et, je l’avoue, j’en use aussi). Mais ce n’est que pour mettre une technologie en cause pour une autre. Et continuer le cycle infernal du renouvellement des outils et langages. Une vraie remise en cause, c’est se demander avec sincérité : allons-nous dans le bon sens ? Ce que je fais est-il durable ? Est-ce de qualité ? Mais la remise en cause n’est pas chose simple car elle est associée soit à du troll (justement ou injustement) soit à une image rétrograde. Comment critiquer un mode associé à une avancée technologique ?

Les voix s’élèvent peu contre cet état de faits : Le désenchantement du logiciel, Contre le développement logiciel… et c’est dommage car la remise en question est une pratique saine pour un domaine. Elle permet de « performer » encore plus.

On ne se remet pas en question car on veut s’amuser. Le fun est important, car si l’on s’ennuie dans son boulot, on va déprimer. Par contre, on ne peut pas, sous prétexte de vouloir du fun tout le temps, changer nos outils continuellement. Il y a un déséquilibre entre l’expérience du développeur et l’expérience de l’utilisateur. On veut du fun, mais qu’est-ce que cela va réellement apporter à l’utilisateur ? Un produit plus « joyeux » ? Non, nous ne sommes pas des acteurs. On peut aussi critiquer l’effort que l’on met à réduire les temps de build et autre commodités du développeur. C’est important mais il faut toujours équilibrer nos efforts : j’accélère mon temps de build mais ce n’est valable que si j’utilise le temps gagné pour améliorer l’expérience utilisateur. Sinon ce n’est que du tuning pour son propre plaisir.

Il est nécessaire d’accepter la critique, de s’autocritiquer et d’éviter de se cacher dernière des barrières. La dette technique est une notion importante mais si c’est une excuse pour faire du mauvais refactoring et surtout pour changer vers une nouvelle techno à la mode, autant acquérir de la dette. Il faut aussi arrêter les guerres de chapelles. A quoi bon défendre son langage vis-à-vis d’un autre ? Arrêtons de répéter que « l’optimisation prématurée est la cause de tous les maux… » Cela vient de l’informatique des années 70 où tout était optimisé. Or, il n’y a plus d’optimisation prématurée, ce n’est qu’une excuse pour ne rien faire et continuer comme cela.

Nous sommes (mal) gouvernés

On ne se pose pas de question sur l’éthique de notre domaine, sur sa durabilité… Cela vient peut-être du fait que notre domaine n’a pas réellement de code éthique (comme par exemple les médecins ou les avocats). Mais sommes-nous en tant que développeurs réellement libres si l’on ne peut pas avoir une autocritique ? Nous sommes peut être asservis à une cause portée par d’autres personnes ? Le problème n’est pas simple mais nous avons dans tous les cas une responsabilité.
Sans code éthique, c’est le plus fort et le plus malhonnête qui est le plus fort. Le buzz et les pratiques pour manipuler les utilisateurs sont de plus en plus répandus. Sans Dark Pattern ton produit ne sera rien. Les plus gros (GAFA…) n’en sont pas arrivés là pour rien.

Est-ce que la solution est politique ? Il faut légiférer pour mieux gouverner le monde du logiciel. On le voit avec les dernières réponses législatives aux problèmes concrets : RGPD, notification des cookies… la source du problème n’est pas résolue. Peut-être parce que les politiques ne comprennent que très mal le monde du logiciel.

Il serait préférable que le monde du logiciel se structure, mette en place un code d’éthique, s’autorégule… Mais en attendant, c’est la règle du plus fort qui continue … Au détriment d’une meilleure structuration, d’une meilleure qualité, d’une véritable professionnalisation…

Car si cette structuration n’est pas faite, les développeurs vont perdre la main sur ce qu’ils font. Or le manque d’éthique de la profession est critiqué à l’extérieur. Rachel Coldicutt (@rachelcoldicutt) directrice de DotEveryOne, un think tank britannique qui promeut une technologie plus responsable, encourage à former des diplômés non-informaticiens qui traiteraient de ces problèmes (Voir plus précisément dans l’article d’Internet Actu). Pour poursuivre sur ce dernier article, cela serait dans la droite ligne de l’informatique, domaine issu du monde militaire où les ingénieurs et développeurs seraient formés à suivre des décisions et des commandements.

Un propos qui fait écho, notamment, à celui que tenaient David Banks (@da_banks) dans l’insolent « The Baffler ». D.Banks soulignait combien le monde de l’ingénierie est lié à l’autoritarisme. La raison est certainement à chercher du côté de l’histoire. Les premiers ingénieurs étaient d’origine militaire et concevaient des armes de siège, rappelle-t-il rapidement. Ils sont d’ailleurs toujours formés pour « se brancher sur les structures décisionnelles de la chaîne de commandement ». Contrairement aux médecins ou aux avocats, les ingénieurs n’ont pas d’autorités éthiques qui les surveillent ou de serment à respecter. « C’est pourquoi les ingénieurs excellent dans l’externalisation des reproches » : si cela ne marche pas, la faute incombe à tous les autres (utilisateurs, managers…) « On leur enseigne dès le début que la chose la plus morale qu’ils puissent faire est de construire ce qu’on leur dit de construire au mieux de leurs capacités, afin que la volonté de l’utilisateur soit réalisée avec précision et fidélité. »

Avec cette vision, on peut se poser la question : pourrons-nous intégrer des bonnes pratiques et de l’éthique de façon structurelle et interne dans notre domaine ?

Le développement suit (trop) comme toute organisation des décisions absurdes

Le monde du logiciel s’intègre dans un système organisationnel classique. Grands groupes, sous-traitances via des ESN, web agencies… Tous suivent les mêmes techniques de gestion des projets informatiques. Et tout le monde va « dans le mur ». Aucune analyse sérieuse n’est faite sur le coût global d’un logiciel (TCO), sur son impact sur la société, sur son bénéfice, sa qualité… C’est la rapidité de release(Time to Market), la surcharge featurale (fonctionnelle), la productivité immédiate, qui comptent. Premièrement car les gens externes à ce monde ne connaissent que trop peu la technicité du logiciel et son monde. Il est virtuel donc simple (sic). Mais ce n’est pas le cas. Les écoles de commerce et autres usines de managers n’ont pas de cours de développement. Comment peuvent-ils bien diriger et piloter des projets ?

On continue a vouloir chiffrer des projets informatiques comme de simples projets alors que des mouvements comme le no estimate propose des approches innovantes. Les projets continuent d’échouer : le chaos report rapporte que simplement 30% des projets réussissent bien. Et face à cette mauvaise gouvernance, les équipes techniques continuent de se battre sur les technologies. Dommages collatéraux : la qualité, l’éthique, l’environnement… et au final l’utilisateur. Cela ne serait pas si critique si le logiciel n’avait pas un impact aussi fort sur le monde. Software eats the world… et oui, on le « bouffe »…

On peut se poser la question de la bienveillance des entreprises : sont-elles uniquement intéressées par leur profit, quel qu’en soit le prix, et laissent le monde du logiciel dans ce marasme ? La réponse vient peut-être de la sociologie. Dans son livre « Les Decisions Absurdes » Christian Morel explique que les individus peuvent collectivement prendre des décisions qui vont totalement dans le sens contraire du but recherché. En particulier, l’autolégitimation de la solution.

Morel explique ce phénomène avec le « pont de la rivière Kwai » où un héros bâtit un ouvrage avec zèle pour son ennemi avant de le détruire.

Ce phénomène du « Pont de la rivière Kwai », où l’action est autolégitimée, où l’action est le but ultime de l’action, existe dans la réalité plus qu’on ne pourrait le penser. Il explique que des décisions sont vides de sens parce qu’elles n’ont pas d’autre but que l’action elle-même. « Il s’est fait plaisir » : c’est ainsi que des cadres d’entreprises s’expriment avec humour et pertinence lorsque l’un des leurs a construit un « pont de la rivière Kwai » (…) L’action comme but en soi suppose l’existence de ressources abondantes (…) Mais lorsque les ressources sont abondantes, l’organisation peut supporter le coût de moyens humains et financiers qui tournent dans le seul objectif de fonctionner ». Et, dans le monde du logiciel, elle met globalement les moyens pour fonctionner : levée de fond gigantesque, librairies qui permettent de releaser très rapidement, ressources infinies… Avec cette abondance, nous construisons énormément de Ponts de la rivière Kwai.

Dans ce cadre, le développeur est responsable de cette abondance.

Le développement est (trop) mal piloté

Si ces décisions absurdes arrivent, ce n’est pas uniquement la faute du développeur mais bien de l’organisation. Et qui dit organisation dit management (sous-différente forme). Si l’on revient au livre de Morel, il parle de piège cognitif dans lesquels les managers et les techniciens tombent souvent. C’est le cas de la navette Challenger qui a été quand même lancée malgré la connaissance du problème d’un joint défectueux. Les managers ont sous-évalué les risques et les ingénieurs ne les ont pas prouvés. Chacun a reproché à l’autre de ne pas fournir assez de preuves scientifiques. C’est souvent ce qui se passe dans les entreprises : des warnings sont levés par certains développeurs mais le management ne les prend pas assez au sérieux.

C’est ce qui s’est passé aussi dans beaucoup d’organisations qui ont voulu rapidement développer des applications mobiles universelles. En l’occurrence, la solution miracle (on y revient) adoptée par les décideurs a été le framework Cordova : pas besoin de recruter des développeurs spécialisés iOS et Android, possibilité de récupérer du code Web… Le calcul (ou pas) simple ne montrait que des avantages. Par contre, côté technique, il était clair que les applications natives étaient beaucoup plus simples et efficaces. 5 ans plus tard, les conférences sont pleines de retours d’expériences sur des échecs de ce type de projet et le redémarrage « from scratch » de ceux-ci en natif. Le lien avec Challenger et les pièges cognitifs ? Les équipes de management avaient sous-estimé les risques, le coût réel et n’avaient pas pris en compte les remarques des équipes techniques. Les équipes techniques n’avaient pas assez étayé et prouvé les tenants et aboutissants d’un tel framework.

En même temps, on revient aux causes précédentes (silver bullet, on s’amuse…), il est nécessaire d’avoir une vraie ingénierie et une vraie analyse des technologies. Sans cela, les équipes techniques seront toujours non-écoutées par le management. Des outils et benchmark existent mais ils sont encore trop peu connus. Par exemple, Technologie Radar qui classe les technologies en terme d’adoption.

Il est dans le même temps important que le management des entreprises cesse de penser que les solutions miracles existent (on revient à la cause du « virtuel »). Il faut réellement calculer les coûts, le TCO (Total Cost of Ownership) et les risques sur les choix de technologie. On continue à choisir des solutions BPM et Low-code qui permettent de générer du code. Mais les risques et les coûts cachés sont importants. Selon ThoughtWorks :

Low-code platforms use graphical user interfaces and configuration in order to create applications. Unfortunately, low-code environments are promoted with the idea that this means you no longer need skilled development teams. Such suggestions ignore the fact that writing code is just a small part of what needs to happen to create high-quality software—practices such as source control, testing and careful design of solutions are just as important. Although these platforms have their uses, we suggest approaching them with caution, especially when they come with extravagant claims for lower cost and higher productivity.

On se divise (trop)… pour mieux règner?

Ce phénomène de décision absurde est renforcé par le tissu complexe du développement logiciel : Les sociétés historiquement hors du numérique sous-traitent à des entreprises du numérique, les ESN sous-traitent aux freelances… Le partage de responsabilité technique / management est encore plus complexe et les décisions absurdes plus nombreuses.

Mais cela ne s’arrête pas là. On peut aussi voir l’usage de l’open-source comme une sorte de sous-traitance. Idem pour l’usage de framework. On est juste consommateur passif, on se déleste de plein de problématiques (qui ont un impact sur les ressources, la qualité…).

C’est d’autant plus facile que le domaine est passionnant et que la pratique des sides-projects, du temps passé sur les projets open-source hors des horaires de bureau est chose commune… La recherche de « fun » et le temps passé bénéficient alors plus aux organisations qu’aux développeurs. Difficile dans ce cas de chiffrer le coût réel d’un projet. Et pourtant, cela ne serait pas un problème si on arrivait à des logiciels « au top ». Cela ne change pas la qualité, au contraire, l’organisation étendue qui est composée du gros des groupes, des ESN, des freelances, des communautés n’a plus de limite pour construire les fameux ponts de la rivière Kwai.

Le développeur n’est ici plus un artisan du code, mais plutôt un pion dans un système critiquable du point de vue humain. Cela n’est pas visible, tout va bien et on s’amuse. En apparence seulement, car certains domaines du développement logiciel vont plus loin et rendent beaucoup plus visible cette exploitation : Le domaine du jeux-vidéo où les heures explosent.

Dans ce contexte, une meilleure professionnalisation, un code d’éthique ou toute autre chose serait utile. En effet, ceci permettrait de mettre des garde-fous sur des dépassements ou des pratiques (directement ou indirectement) critiquables. Mais je n’ai jamais entendu parler de la corporation des développeurs ou autre rassemblement qui permettrait cette défense du code.

On perd (trop) souvent le but final : l’utilisateur

Et donc, toutes ces maladresses (logiciel trop lourd, sans qualité…) se retrouvent chez les utilisateurs. Comme on doit releaser au plus vite les logiciels, que l’on ne tente pas de résoudre les inefficiences internes, et que l’on ne met pas plus de ressource pour faire de la qualité, on arrive à des logiciels médiocres. Mais on a tellement d’outils de monitoring et de suivi des utilisateurs pour détecter ce qui se passe directement chez eux qu’au final, on pense que ce n’est pas grave. Cela serait une bonne idée si les outils étaient bien utilisés. Or la multitude d’informations récoltées (en plus des bugs remontés par les utilisateurs) n’est que faiblement utilisée. Trop d’information, difficulté de cibler la vraie source du problème… on s’y perd et au final, c’est l’utilisateur qui trinque. Tous les logiciels sont maintenant en bêta-test. A quoi bon faire de la sur-qualité, autant attendre que l’utilisateur le demande. Et on revient ainsi au premier chapitre : un logiciel uniformément lent … et médiocre.

En prenant un peu de recul, chacun peu le ressentir au quotidien que ce soit au bureau ou la maison. Heureusement, on est sauvé par la non-sensibilisation des utilisateurs au monde du logiciel. C’est un monde effectivement virtuel et magique qu’ils ont l’habitude d’utiliser. On leur a mis en main les outils mais sans notice explicative. Comment évaluer la qualité d’un logiciel, les risques sur l’environnement, les problèmes de sécurité… si l’on n’a pas des notions d’informatique, même rudimentaires ?

L’informatique du 21ème siècle est ce que l’agroalimentaire était pour les consommateurs au 20ème siècle. Pour des raisons de productivité, on a poussé des solutions médiocres avec un calcul court-termiste : mise sur le marché de plus en plus rapide, profit en hausse constante… agriculture intensive, malbouffe, pesticides… avec des impacts importants sur la santé, sur l’environnement… Les consommateurs savent maintenant (de plus en plus) les conséquences désastreuses de ces dérives, l’industrie agroalimentaire doit donc se réinventer, techniquement, commercialement et éthiquement. Pour le logiciel, quand les utilisateurs comprendront les tenants et les aboutissants des choix techniques, l’industrie du logiciel devra gérer les mêmes problèmes. En effet, le retour au bon sens et aux bonnes pratiques n’est pas une chose simple pour l’agroalimentaire. Dans l’IT, on commence à le voir avec ses conséquence sur la vie privée des utilisateurs (mais nous n’en sommes qu’aux balbutiements).

Il est important de réintroduire l’utilisateur dans les réflexions de conception des logiciels (et pas seulement en faisant juste des workshops de réflexion UX et marketing…) Il faut repenser tout le monde du logiciel : la gestion des projets, les impacts du logiciel, la qualité… C’est le but de certains mouvements : software craftmanship, éco-conception, accessibilité… mais les pratiques sont beaucoup trop confidentielles. A qui la faute ? On revient aux causes du problème : on se fait plaisir d’un côté (développement) et on a une recherche uniquement de profit (coté management). Pratique pour bâtir des ponts de la rivière Kwai… où se trouvent les utilisateurs (nous, en fait).

On tue notre industrie (et plus)

On va dans la mauvaise direction. L’industrie de l’informatique a déjà effectué dans les années 70 des erreurs avec des impacts non-négligeables. L’exclusion des femmes de l’informatique en fait partie. Non seulement cela a été fatal pour certaines industries mais on peut se poser la question de comment on peut maintenant adresser des réponses à seulement 50% de la population informatique, avec une représentativité très faible. Le chemin est maintenant difficile à retrouver.

Mais l’impact du monde IT ne s’arrête pas là. La source et le modèle d’une grosse partie de l’informatique sont issus de la Silicon valley. Si l’on écarte les gagnants de la Silicon Valley, les populations locales subissent la montée des prix, le déclassement, la pauvreté… Le livre Mary Beth Meehan met en image cela :

« La fuite vers un monde virtuel dont on peine encore à jauger l’utilité nette, elle, coïnciderait avec l’éclatement des communautés locales et la difficulté à se parler entre voisins. Personne ne peut dire si la Silicon Valley préfigure en miniature le monde qui vient, pas même Mary, qui termine pourtant son ouvrage autour du mot « dystopie ». »

Dans sa lancée vers le progrès technique, le monde du logiciel crée aussi sa dette environnementale…

Les exemples sont nombreux mais les voix encore trop faibles. Peut-être que nous allons trouver la silver bullet, que les bénéfices du logiciel vont effacer ses torts… rien ne montre cela pour l’instant, bien au contraire. Car il est difficile en effet de critiquer le monde du logiciel. Comme le dit Mary Beth Meehan :

« mon travail pourrait tout aussi bien être balayé ou considéré comme une propagande de gauche. J’aimerais penser qu’en montrant ce que nous avons décidé d’occulter, nous avons servi à quelque chose, mais je ne suis pas très confiante. Je ne crois pas que les gens qui, en première instance, ne sont pas d’accord avec nous pourraient changer d’avis.».

Par contre, si des voix se font de plus en plus nombreuses, et qu’elles viennent de personnes qui connaissent le logiciel (développeurs, architectes, testeurs…), le système pourra changer. Le développeur n’est ni un artisan, ni un héros : il est juste une cheville ouvrière d’un monde sans sens. Alors, il est temps de bouger…