Développement Durable (DD ?)

Je me suis forgé une conviction que j’aimerai partager le plus largement possible, aussi ai-je décidé de la confier ici sur LinkedIn. Je lui ai trouvé un chouette branding : le Développement Durable. Evidemment, il ne s’agit pas de la conviction écologique bien connue (quoique…), mais d’une démarche qui vise à fabriquer du logiciel (d’où le terme Développement) vraiment pérenne (donc Durable).

L’enjeu est considérable. Après, en gros, vingt années de développement Web (et Java), les entreprises ont constitué un actif composé d’applications qui, comme leurs aïeules, sont devenues du Legacy. Entendez : applications vieillissantes mais essentielles, partiellement sous contrôle, dont une grande part de la mémoire est perdue. Bref, l’actif est devenu un encombrant passif : la maintenance est chère, le métier grogne et l’inquiétude monte car ce même métier doute que le « bousin » puisse faire face aux défis d’un avenir de plus en plus rapide.

L’histoire est peu ou prou toujours la même : un beau projet fut lancé un beau jour dans l’enthousiasme et s’est terminé bien plus tard dans davantage de douleur. Il a été ensuite maintenu dans la réticence, et donc par un personnel moins « noble », plus jeune, moins qualifié, moins entraîné, moins managé… Conséquence : pas forcément en grande forme au moment de sa mise en production initiale, l’application s’est dégradée au cours du temps jusqu’à devenir un « monstre » de plus en plus affamé de soins, mais toujours aussi indispensable. Je suis sidéré de constater (de visu !) à quel point, des entreprises, y compris de grands noms, sont aujourd’hui en danger dans leur activités essentielles, du fait de cette non-maitrise et de la lente agonie de leurs solutions digitales 1.0, 2.0, 3.0...

Manifestement la leçon n’est pas retenue et les développements d’aujourd’hui sont partis pour répéter les mêmes erreurs. Je sais que les acteurs sont conscients des problèmes à venir. Mais fatalistes, ils déplorent l’inéluctable : nous sommes condamnés à la médiocrité car il ne serait pas possible, parait-il, de faire autrement.

Eh bien, SI ! Il est possible de faire autrement ! J’en suis absolument convaincu. Et non, ce n’est pas une fièvre juvénile : j’ai passé l’âge (trente ans de métier…). Je suis convaincu, donc, de détenir maintenant un ensemble de pratiques cohérentes entre-elles et qui permettent, utilisées ensemble, de fabriquer du logiciel de très haute qualité, documenté efficacement, performant et … d’un coût compétitif, inférieur en tout cas, à celui du logiciel médiocre produit aujourd’hui. « Whaaa ! » êtes-vous en train de vous dire, amusé : « En voilà un qui se prend pour Gandalf ou Merlin ! Où est sa baguette magique ? Si c’était possible, ça se saurait ! ». Bon, je sais que je vais avoir du mal à vous convaincre en quelques lignes, aussi, si une faille se dessine quand même dans votre scepticisme, contactez-moi, je suis tout disposé à en discuter, débattre, démontrer, etc. Afin néanmoins de créer ladite fissure, je me permets de donner les grandes lignes de la démarche :

• Couverture de code complète (100%). Oui, c’est possible et Non, ce n’est pas hors de prix. Les retours d’expérience montrent, au contraire, que nos équipes qui pratiquent un très haut niveau de testing de code (>99%) ont la même productivité que celles qui ne font rien sur ce sujet. Cependant, – autre idée reçue – le test automatisé n’est pas d’abord une question de discipline, mais un sujet de savoir-faire, un savoir-faire qui n’est absolument pas trivial, qui ne se découvre pas par hasard, bref qui est la marque d’un haut niveau d’ingénierie logicielle. Cela s’explique, cela s’enseigne, y compris aux plus jeunes, puisque mes équipes de stagiaires savent faire désormais (facilement). Pour des raisons sur lesquelles je ne m’étends pas ici mais qui sont connues de tous ceux qui pratiquent le test de codage automatisé à des niveaux de couverture très élevés, ce test implique et garantit un niveau tout aussi élevé de qualité.
• Généralisation-extension. L’idée est de rester DRY (don’t repeat yourself) en pratiquant un refactoring inlassable pour toujours :

1. Séparer les responsabilités (comportement / structure par exemple) en s’appuyant sur les nouveaux besoins qui s’expriment (donc rester YAGNI) pour challenger le code existant.
2. Etendre ensuite l’application en remplaçant / enrichissant une des responsabilités isolées.

• De toutes les pratiques présentées ici, c’est la plus difficile et celle qui demande le plus de savoir-faire. Le gain est d’apporter – assez paradoxalement, car on refactore beaucoup (>50% du temps !) – un gain considérable en productivité. Par rapport à une équipe standard, un doublement de la productivité est un minimum, et peut aller bien, bien au-delà.
• Auto-documentation. Là aussi il s’agit de pratiques qui s’apprennent et s’enseignent et qui font que le code – la manière dont il est écrit, la manière dont il est structuré, la manière dont il est testé – est porteur de sa propre documentation. Cette documentation étant exécutable, elle ne diverge pas de l’implémentation (puisqu’elle EST la documentation) et donc sa valeur est assurée dans le temps. Noter que le test – qui est une forme de code – participe à cette documentation.
• Ingénierie agile. Adoption globale d’XBread (Scrum+XP). Code review pairée piloté par des considérations d’ingénierie (performance, robustesse, sécurité, …). Contrôle des connaissances (design patterns, complexité algorithmique, algorithmes fondamentaux) et formation / entrainement si des manques sont constatés.

Le maître-mot pour réussir ce type de démarche est le savoir-faire d’ingénierie. Aller, comme ce maître-mot est important, décisif même, je le répète, je le souligne : le savoir-faire d’ingénierie. Ce savoir-faire ne s’acquière pas essentiellement dans les écoles d’ingénieurs, ni par l’expérience projet standard. Aussi, les développeurs, y compris expérimentés ne disposent pas, ou peu, ou mal, de ce savoir-faire. Ce savoir-faire s’obtient par un cursus enseignement / mentoring / entrainement (au sens du « training ») qui nécessite donc d’être réfléchi, structuré et organisé. Il ne peut donc que s’agir d’un savoir faire d’entreprise et donc d’une offre bien identifiée comme telle. Si on décline ce principe à une ESN (SSII), il s’implémente dans une vente différente, basée sur la valeur apportée au client et non sur le classique jour/homme. Bien sûr, ce schéma a besoin d’être expliqué et probablement démontré (comme l’a été dans son temps, sa première étape : l’agilité). Mais pour tout le monde – le donneur d’ordre au premier titre – l’intérêt est majeur. Il rétablit aussi l’ESN dans son essence : fournir efficacement les solutions logicielles dont ses clients ont vraiment besoin, et non être fournisseur d’un supplément d’effectif.

J’insiste sur un point : la valeur individuelle entre bien dans la combinaison, mais elle n’en est pas l’élément essentiel. Il est bien sûr, important d’avoir des ressources capables pour pouvoir les entraîner. Mais c’est bien de cet entrainement que l’on attend la décision. Autre manière de le dire : l’élitisme technique n’est pas nécessaire. Évitons un autre malentendu : entrainement ne veut pas dire immobilisation. Le projet, quand il réussit, est probablement l’entraînement le plus efficace qui soit.

Autre chose : un logiciel de qualité ne le reste que si on prend soin de lui. L’exigence doit rester la même après la phase de build. Un intervenant en TMA qui ne comprend pas le produit qu’il maintient le DÉTRUIT. Il aura peut-être apporté la petite fonctionnalité demandée, là, tout de suite, mais il a peut-être aussi, réduit la durée de vie de l’ensemble pour toujours. C’est l’effet papillon logiciel : une opération douteuse de quelques jours au début, peut provoquer des mois, des années plus tard, d’autres opérations nécessitant des mois de travail. La maintenance de ces applications ne doit pas être envisagée comme une sous-mission confiée à un personnel sous-qualifié.

Un dernier point : une solution réussie n’est pas qu’une question de construction de logiciel, j’en suis bien conscient. Le build n’est pas tout. Savoir définir le bon produit, savoir le présenter intelligemment au marché, savoir l’exploiter, le supporter sont tout aussi importants pour en faire un succès industriel ou commercial. On peut, c’est vrai, fabriquer un logiciel « durable » qui ne durera pas parce que qu’il ne rencontre pas son marché ou ses utilisateurs. Mais déjà, faisons au niveau de la fabrication, tout ce qu’il faut pour ne pas partir perdant.