Les développeurs de logiciels ne peuvent se qualifier d’ingénieurs

Le développement de logiciels est aujourd’hui encore et toujours une activité assez amateur. Les développeurs semblent encore et toujours trop faire de leur mieux pour sortir un bon produit, mais sans aucune garantie, alors que le secteur évolue trop peu vers une approche plus mature. Et si ingénieur civil essayait une fois lui aussi de créer un pont pour lequel il ‘a fait autant que possible de son mieux’.

De mémoire d’homme, le développement de logiciels est aux prises avec les mêmes symptômes: trajets de travail longs et complexes, et pareil pour le code. Il en résulte que le résultat final se caractérise souvent par de nombreux bugs et s’avère toujours plus coûteux que prévu. Le développement de logiciels est du reste aussi qualifié de software engineering. Selon moi, il s’agit là d’une présentation incorrecte des choses. L’ingénierie porte sur la création d’éléments en faisant appel à des techniques connues et éprouvées avec un sens profond de la fiabilité. Si les ‘vrais‘ ingénieurs construisaient leurs ponts comme nous créons encore et toujours nos logiciels, peu de véhicules pourraient les franchir.

Le développement de logiciels semble à mains égards ne pas encore avoir atteint la maturité. Il existe évidemment des langages fantastiques permettant d’écrire des applications tout aussi remarquables. Mais si l’on considère l’amateurisme avec lequel certains trajets de développement se déroulent, il y a de quoi se poser des questions. Depuis l’introduction de la programmation orientée objet dans les années 80, il n’y en outre pas grand-chose de fondamentalement changé.

Développement agile

Je prendrai ici l’exemple frappant de l’agile development, qui est en soi déjà une énorme amélioration et un premier pas vers des trajets de développement plus professionnels. A en croire la rumeur insistante, selon laquelle l’Agile Manifesto (reprenant tous les principes du développement agile) a été rédigé après que son auteur ait absorbé une solide dose de bière et de whisky, il nous faut quand même froncer les sourcils. Car en fin de compte, les bases sous-jacentes au développement agile ne sont en fait rien de plus que, d’une par, l’acceptation que l’on ne peut développer en une seule fois qu’une quantité complexe très limitée et que, d’autre part, la prise de conscience que le développement de nouvelles demandes et exigences va toujours plus vite que celui du logiciel proprement dit.

La ‘réponse’ d’Agile est pourtant quelque peu décevante: la vitesse d’un projet agile est conditionnée par la rapidité avec laquelle une équipe peut fournir une solution minimale, et la réponse au changement se résume à “soyez-y prêt”. Voilà qui éveille quand même la sensation que tout le concept du ‘software engineering’ se réduit à “nous faisons de notre mieux”. Pour en revenir une fois encore à nos constructeurs de ponts: franchiriez-vous un pont en y découvrant un écriteau portant la mention “nous avons fait de notre mieux”…?

Amélioration possible

Le manque de maturité dans le secteur du développement se traduit par diverses formes de dérive. D’une part, les entreprises se sentent soumises au bon vouloir des développeurs et des ‘software engineers’, parce qu’elles n’ont pas la moindre vision sur le processus de développement et sur tout ce qui n’y est pas possible. D’autre part, les développeurs et fournisseurs de logiciels et de services sont harcelés par les entreprises qui virent de bord et confient le travail à celui qui remet l’offre la plus intéressante. On peut aussi miser massivement sur les produits COTS (Common of the Shelf, alias les logiciels standard), caractérisés par un tas de particularités et de problèmes. Comme le fait qu’ils ne font pas exactement ce qu’on souhaite qu’ils fassent. Puis, maintes organisations se tournent vers la “customisation”, ce qui entraîne souvent une situation qui ressemble étonnamment au trajet de développement d’un logiciel: trop tard, trop cher et à côté de la plaque.

Cela peut pourtant évoluer. La génération actuelle de langages de programmation n’a peut-être pas été améliorée de manière spectaculaire, mais elle permet néanmoins d’encoder beaucoup plus efficacement. La toute dernière vogue ici a pour nom “Low code” et promet plus de fonctionnalité avec moins de lignes de code. Or qui dit moins de lignes de code, dit moins de risques d’erreur et un travail fini plus rapidement, pas vrai? Certes, en théorie du moins. Si l’on jette toutefois un regard sous le capot moteur, on découvre encore pas mal de vieilles choses reconditionnées: librairies définies et API, retour du développement visuel “drag & drop” et surtout beaucoup de promesses.

En outre, il n’est pas non plus certains que tout le monde attende cela Aussi longtemps que les lignes de code ou les heures prestées représenteront des critères utilisés pour la productivité d’un développeur, il y aura peu de motivation à effectuer des changements structurels.

Tout est-il donc si mauvais? Sûrement pas. Il y a incontestablement du progrès. Principalement sur le plan du concept de ce qui est disponible pour la création d’une application IT: comment agencer mon infrastructure, comment réaliser son déploiement, qu’en est-il de la sécurité et du ‘networking’. Tous ces aspects ont fait l’objet de changements fondamentaux et sont de plus en plus “software driven” (pilotés par logiciel) en recourant à des techniques “low code” encore bien.

Néanmoins, il y a encore du pain sur la planche. Aujourd’hui, on voit encore et toujours trente pour cent de tous les projets logiciels échouer (selon le rapport CHAOS de Standish Group). Aujourd’hui, on voit encore et toujours trente pour cent de tous les projets logiciels échouer. Cela ne serait accepté dans aucun autre secteur, et on ne devrait pas le tolérer non plus dans celui du développement de logiciels.

Le choix radical d’une nouvelle technologie et de nouveaux modes de travail conduira peut-être à court terme à une crise temporaire, mais si nous voulons continuer de progresser à un bon rythme à plus longue échéance, il faudra quand même passer par des changements. Le véritable ‘ingénieur’ qui parvient à lancer un pont entre le passé amateur et un avenir professionnel, méritera un prix Nobel, si vous voulez mon avis.