POURQUOI TANT DE BUGS ?
Ces technologies de l’information récalcitrantes qui chiffonnent les entreprises
Elle est supposée être la “tueuse de Tesla”. La nouvelle ID.3 de Volkswagen est la première voiture entièrement électrique produite en série, et la première étape des tentatives du constructeur allemand de se réinventer pour un monde électrifié. Cela en fait peut-être le modèle le plus important depuis la Golf originale, lancée en 1976. L’ID.3 est également en retard. Sur le plan mécanique, la voiture est en parfait état. Mais certains gadgets logiciels qui sont un argument de vente important de nos jours – dont on dit qu’ils incluent la connectivité pour smartphones et l’assistance au stationnement en réalité augmentée – pourraient manquer au début, et être ajoutés plus tard. Prévu à l’origine pour cet été, le lancement a été reporté au moins jusqu’en septembre.
VW n’est pas la seule grande entreprise à avoir du mal à faire fonctionner ses ordinateurs.
L’année dernière, les banques britanniques ont été mises sur la sellette par les autorités de régulation en raison de pannes en ligne et de mises à niveau informatiques bâclées qui ont laissé des millions de clients dans l’incapacité d’effectuer ou de recevoir des paiements.
L’année dernière, les banques britanniques ont été mises sur la sellette par les autorités de régulation en raison de pannes en ligne et de mises à niveau informatiques bâclées qui ont laissé des millions de clients dans l’incapacité d’effectuer ou de recevoir des paiements. Certains problèmes sont beaucoup plus graves. Les Boeing 737 MAX ont été cloués au sol en 2019 après deux crashs mortels causés en partie par une faille logicielle. Les enquêteurs ont depuis trouvé des bugs moins importants. On conseille maintenant aux compagnies aériennes d’éteindre et de rallumer l’avion tous les 51 jours, pour empêcher leurs ordinateurs d’afficher de fausses données en plein vol. Un problème similaire découvert en 2017 sur certains avions fabriqués par Airbus, le concurrent européen de Boeing, a incité l’Agence européenne de la sécurité aérienne à exiger que ces avions soient redémarrés au moins toutes les 149 heures. La responsabilité des problèmes informatiques des entreprises remonte au niveau des conseils d’administration. Parfois, c’est justifié ; Dennis Muilenberg a été contraint, à juste titre, de démissionner de son poste de PDG de Boeing après les tragiques catastrophes du 737 Max. Mais ce n’est pas toujours le cas. Car les logiciels sont difficiles à suivre. Et les employés qui sont censés les fabriquer sont souvent les produits d’une discipline qui est, à bien des égards, étrangement surannée. Lorsque les logiciels “mangent le monde” – la Silicon Valley parle d’une situation où la plupart des entreprises sont, dans une plus ou moins grande mesure, des sociétés de logiciels – cela compte. Commencez par le code informatique lui-même. La programmation exige un mélange d’hyper-littérature et de créativité. De petites erreurs, comme un signe de ponctuation mal placé, peuvent changer complètement le comportement d’un système. Une règle empirique de l’industrie est que, selon le soin avec lequel ils travaillent, les programmeurs font entre 0,5 et 50 erreurs toutes les 1 000 lignes de code qu’ils écrivent. Comme les voitures et les avions contiennent des dizaines de millions de lignes, les chances qu’un système soit exempt d’erreurs sont en fait nulles. Même lorsque les bugs ne conduisent pas à une catastrophe, ils freinent constamment la productivité d’une entreprise. Une enquête commandée par Stripe, un processeur de paiement numérique, a révélé que le développeur moyen passe 21 heures par semaine à réparer du code ancien ou mauvais. La difficulté inhérente à la programmation est aggravée par les lacunes du génie logiciel en tant que profession. Celles-ci sont exposées dans un livre, ‘The Problem With Software : Why Smart Engineers Write Bad Code’. L’auteur, Adam Barr, a passé 20 ans comme développeur pour le géant du logiciel Microsoft. De nombreux codeurs, note-t-il, sont au moins en partie autodidactes. Cela entraîne de mauvaises habitudes, que les cours d’ingénierie logicielle ne parviennent pas à corriger. Il y a trop peu de communication entre le monde universitaire et l’industrie, et aucun véritable accord sur ce qu’il faut enseigner ou sur les habitudes à inculquer. Il en résulte, selon M. Barr, un domaine dans lequel le folklore et les modes prennent trop souvent la place des normes professionnelles.
Pour illustrer les fondements fragiles de ce domaine, M. Barr évoque la pratique, très répandue dans les entreprises technologiques comme Google ou Apple, qui consiste à donner aux candidats à un emploi un problème de programmation à résoudre sur un tableau blanc. Peu d’autres domaines se comportent ainsi, car ils supposent qu’à force d’être diplômés, les candidats ont déjà atteint un niveau de compétence de base. Les médecins n’attendent pas de quiz d’anatomie avant d’être embauchés. Les ingénieurs en mécanique ne sont pas tenus de noter les lois du mouvement de Newton pour prouver leur bonne foi.
Tous ces problèmes sont aggravés par le rythme effréné des changements dans le domaine du génie logiciel. Même lorsqu’un système fonctionne, il devient rapidement obsolète. Les malheurs des banques britanniques sont en grande partie dus à la tentative de maintenir de tels systèmes “hérités”, écrits par des programmeurs de longue date (souvent externalisés) dans des langages informatiques à moitié oubliés pour satisfaire des critères dont personne ne se souvient vraiment. Les codeurs soumis à la pression pour ajouter de nouvelles fonctions ingénieuses font souvent l’impasse sur les problèmes existants, les gardant pour plus tard (un futur toujours moins lointain).
Le résultat, selon un expert ayant des dizaines d’années d’expérience, est que les nouveaux systèmes informatiques brillants peuvent rapidement se transformer en des engins bancals, à moitié compris, tenus ensemble par du ruban adhésif et une prière. Les coûts finissent par devenir trop importants pour être ignorés, et les entreprises doivent mettre leurs systèmes à niveau. Mais c’est le moment où le danger est maximal, car le nouveau logiciel doit faire tout ce que l’ancien, à moitié compris, fait, et même plus. C’est, pour reprendre une analogie courante mais pertinente, comme la reconstruction d’un avion en vol.
La vie d’un bug
VW fait de son mieux pour aplanir les difficultés grâce aux fonctionnalités élégantes de l’ID.3. L’entreprise veut ramener la plupart des développements logiciels en interne et a dépensé 7 milliards d’euros pour une nouvelle et brillante “digital unit”. C’est probablement une bonne idée. Cependant, comme le soutient M. Barr, les problèmes structurels liés à l’écriture de logiciels font que le fait de dépenser de l’argent pour ces logiciels ne garantit pas, en soi, le succès. L’un des grands avantages que possèdent les jeunes pousses comme Tesla ou Monzo, une banque en ligne récente en Grande-Bretagne, est que leurs programmeurs reçoivent une feuille de papier vierge. Comme elles n’ont pas de systèmes à maintenir et qu’elles ont moins de bugs à éliminer, leurs logiciels sont plus robustes et les développeurs peuvent consacrer plus de temps aux fonctionnalités que les clients souhaitent. C’est une maigre consolation pour les entreprises plus anciennes qui n’ont pas de moyen facile de repartir à zéro, mais les informaticiens à l’ancienne offrent un certain réconfort. Les avantages des start-up s’avéreront, selon eux, temporaires. Des bugs s’installeront. Les bugs de l’entreprise ne seront pas réparés. Les développeurs partiront, emportant avec eux leurs connaissances. Les exaltés toutpuissants d’aujourd’hui deviendront les sortants maladroits de demain, retenus par leur informatique archaïque et peu fiable – et mûrs pour les perturbations à leur tour.
Les codeurs soumis à la pression pour ajouter de nouvelles fonctions ingénieuses font souvent l’impasse sur les problèmes existants, les gardant pour plus tard. Le résultat est que les nouveaux systèmes informatiques brillants peuvent rapidement se transformer en des engins bancals, à moitié compris, tenus ensemble par du ruban adhésif et une prière.