Un sujet dont je n’entends que très peu parler dans les nombreux articles et conférences sur le numérique : l’ingénierie logicielle. Comme si la « collaboration » et « embaucher les bonnes personnes et les laisser bosser tranquillement » étaient des piliers éprouvés d’une stratégie opérationnelle efficace. Près de trente années d’expérience en IT dont douze consacrés à une analyse minutieuse de l’avènement du numérique m’ont montré que c’était rarement suffisant.

Car derrière les promesses du numérique il y a un engagement : celui de la satisfaction complète du client. Penser que l’on y parviendra sans soulever à un moment le capot du moteur du numérique, pour comprendre la stratégie d’ingénierie logicielle, est faire preuve d’une candeur coupable. Les géants du web nous ont montré que la satisfaction du client passe par une efficacité opérationnelle redoutable. Et donc par une ingénierie logicielle alignée qui porte elle aussi le sujet de la qualité.

Qu’est-ce donc que la qualité en ingénierie logicielle ? Ce billet essaye d’apporter quelques éclairages et de vous donner les clefs pour comprendre où se situe votre organisation IT sur ce sujet fondamental dans votre transition numérique …

Quelle définition de la qualité ?

Il s’agit d’un malentendu que je retrouve dans de nombreuses organisations IT dans lesquelles j’interviens. Quelle est la définition de la qualité pour l’ingénierie logicielle ? On entend parler de « qualité de code », de « l’état de l’art », qualité du design ou de l’architecture, couverture de tests etc …

Ainsi, je suis souvent confronté à des situations où ces principes de qualité sont appliqués et où pourtant la qualité perçue par le client est médiocre : nombreuses anomalies, performances poussives, prise en main très compliquée …. Ce qui est un problème car dans le lean, la qualité perçue par le client est celle qui nous intéresse en premier lieu.

Avant de nous lancer dans des grands principes pontifiants, appuyons-nous tout d’abord sur quelques observations sur le terrain.

Les périls de l’état de l’art

Un éditeur de progiciel d’entreprise. L’équipe d’architectes et de Tech Leads est très fière de l’architecture de la solution qui regroupe l’ensemble des bonnes pratiques de l’état de l’art. Généricité, découplage, composants standards Java Entreprise (JEE), Design Patterns, etc … Résultat : la suppression d’un objet métier prend quarante minutes durant lesquelles le CPU du serveur est utilisé à 100% et plus personne ne peut utiliser la solution.

Le système est tellement lent que les utilisatrices vont pleurer aux toilettes de la frustration. Lorsque l’on remonte ce point à l’un d’un tech lead, sa réponse fuse : « oui mais l’objet est bien supprimé non ? ». L’ensemble de l’équipe d’architecture quittera l’entreprise d’elle même en moins d’un an laissant à ceux qui restent le soin de réparer les dégâts.

La trajectoire d’architecture et le fantasme de la refonte

Un projet d’extranet dans une grande DSI. Le projet devait coûter 1400 jours, il en coûtera finalement 3400 et sera livré avec un an de retard. Là encore, nous sommes à la pointe en terme d’état de l’art architecture JEE etc …La solution initiale faisait le job mais la cellule d’architecture profite de ce projet pour refondre la solution et avancer sur sa « trajectoire d’architecture ». Tout le monde est content : un beau projet à démarrer et les achats ont bien mis la pression aux fournisseurs pour qu’ils baissent leur taux journalier (car bien entendu le développement est externalisé). Le retard augmentant, l’équipe décide de gagner du temps en supprimant les tests unitaires qui représentent un coût supplémentaire de +30%.

Stratégie gagnante : au final, la solution est 5 fois plus lente que la solution mainframe qu’elle remplace et sera qualifiée de « grosse m… » par les métiers. Comme le code ne comprend pas de tests automatisés, cette grande entreprise vient d’investir plus d’un million et demi d’euros dans du Legacy Code, comme le définit Michael Feathers auteur du classique d’ingénierie logicielle Working Effectively With Legacy Code : « Legacy Code is code without tests ». Là encore le responsable de l’architecture quittera le navire pour aller infliger ses compétences « d’urbanisation de SI » à une autre DSI.

La qualité de code

Nous sommes chez un éditeur logiciel. Je suis avec Abdelkader, un développeur talentueux travaillant depuis leur site offshore. Abdelkader est une personne affable et compétente. Il connait bien l’application, très bien l’environnement technique, il m’explique clairement son contexte. Il est en train d’investiguer un problème épineux retourné par le client. Alors qu’il investigue et teste plusieurs choses, je vois un problème métier lier à un calcul de durée suite à une mise à jour de calendrier. Je lui demande si le comportement de l’application est normal. Il me répond que non et qu’effectivement il s’agit d’un bug métier qu’il note sur son cahier et sur lequel il reviendra plus tard (il n’y reviendra pas).

Nous sommes toujours dans un contexte technologique JEE et le problème est dans un composant logiciel métier (les fameux EJBs dont on sait au moins depuis 2008 qu’il s’agit d’une aberration en termes d’architecture logicielle). Pour pouvoir reproduire le problème et tester des corrections, Abdelkader subit le temps de build et du déploiement (21 mns sur 2 heures d’observation) de son composant. Ce qui prendrait quelques secondes s’il y avait des tests unitaires sur cette classe, permettant de déterminer très rapidement si les modifications sont OK ou KO.

Abdelkader finit par valider sa correction et là il se passe quelque chose d’étonnant. Un autre principe qu’il doit appliquer est que dans chaque fichier java modifié, les règles de qualité de code de l’outil Sonar doivent être appliquées. Il procède donc à la modification d’une vingtaine de lignes de code et, sous mes yeux, introduit 9 régressions (pour les techos : dans un switch case, il remplace une concaténation de String par un StringBuffer dans chacune des 9 lignes du switch : il oublie le #CRLF en fin de chacune des 9 lignes). Je lui demande s’il n’a rien oublié et il me dit « non, non » puis je lui parle du #CRLF et il s’exclame alors « oui bien sûr ! » Il corrige les 9 lignes puis modifie ensuite une quinzaine d’autres lignes de code dont des règles métiers (des if). À la fin des modifications je lui demande si c’est bon et il me dit « oui, oui », sans pour autant procéder à des tests (il n’y a pas de tests unitaires sur cette classe). Il a donc, pour des besoins de conformités logicielles (la fameuse « qualité de code »), modifié des lignes de code qui sont des règles métier sans les tester. Ce qui est revient à peu près, en termes de taux de réussite, à sauter à l’élastique sans élastique.

La qualité perçue du client

Voilà donc un éditeur logiciel dont les développeurs privilégient la « qualité de code » (l’utilisation des règles de Sonar) à la qualité perçue par le client alors même que les clients se plaignent inlassablement des nombreuses régressions (nouvelles erreurs dans une fonctionnalité qui fonctionnait auparavant) introduites dans les différentes versions livrées de la solution. Non seulement ces modifications de « qualité de code » lui ont pris 20 mns (alors qu’il n’a créé de la valeur pour le client que durant 5 minutes – la correction de l’anomalie) mais 1/ elles introduisent des régressions fonctionnelles et 2/ sont faites au détriment du problème client qu’il a identifié mais sur lequel il n’est pas revenu.

À ce stade, il est important de comprendre le pourquoi de cette pratique. Dans le lean nous sommes convaincus que les personnes font du mieux qu’elles peuvent dans le contexte qui est le leur. Si Abdelkader n’avait pas procédé à ces modifications de code, Alexandre, le développeur senior qui relit son code lui aurait demandé de le faire. En revanche, il ne lui aurait dit rien sur le problème fonctionnel trouvé.

Je n’ai rien de particulier contre l’outil Sonar. Cela peut-être un bon outil il s’agit juste du contexte de l’utilisation. Une des règles d’or du logiciel est la suivante : « If it ain’t broke, don’t fix it ». Cela peut sembler conservateur mais ce que nous apprend le développement des pratiques d’ingénierie logicielle issues des géants du web est ceci : on ne change pas du code s’il n’a pas de tests automatisés – i.e. si on ne peut se mettre en situation de s’assurer que l’on n’a rien cassé. Si l’on veut le modifier, on rajoute d’abord des tests puis on modifie le code. Un des principes majeurs du lean : mettre chacun en condition de déterminer à son étape du processus que son travail est OK et qu’il ne laisse pas passer de problème de qualité. L’équipe a décrété qu’elle n’avait pas le temps de faire des tests automatisés, elle a donc décidé d’utiliser Sonar en plan B pour améliorer « la qualité du code ». Décision qui peut sembler tactiquement judicieuse mais qui s’avère, dans les faits, désastreuse.

Continuous Delivery et Qualité

Dans le cadre du Lean IT Summit, j’ai eu la chance d’assister à la masterclass de Jez Humble, auteur de nombreux ouvrages, enseignant à Berkley et, avant tout,  ingénieur de développement qui a inventé le principe d’ingénierie logicielle à l’oeuvre chez les géants du Web : le Continuous Delivery (parce qu’il est en avait marre d’être en astreinte le week-end lors des mises en production nous avouera-t-il). Le premier principe de cette approche est le suivant : build quality-in, construire de la qualité à l’intérieur du produit, en en garantissant l’intégrité par l’automatisation de nombreux tests. Si un test ne passe pas, la version ne pourra tout simplement pas être réalisée. Le fameux principe lean de l’arrêt au défaut.

Ce que nous apprennent les géants du web est que la résilience des systèmes IT (i.e. la capacité à pouvoir les modifier sans compromettre leur intégrité) vient moins d’une approche de réflexion et de conception poussée en phase amont (approche rationaliste et Tayloriste que nos-organisations.fr affectionnent particulièrement) que d’une stratégie de tests automatisés qui va permettre de s’assurer, à chaque étape du processus de développement produit, que la qualité est intégrée dans le produit.

Jez n’a en outre pas insisté sur les outils ou méthodes si ce n’est sur bash l’outil de scripts Unix qui est son outil favori, et sur les principes d’eXtreme Programming (XP) vieux de 20 ans. J’ai bien prêté attention et à aucun moment je ne l’ai entendu évoquer « l’urbanisation du SI », « l’état de l’art », « la qualité de code » ou encore « Java Entreprise ». Ses seuls sujets sont : comment livrer de la qualité en continu au client, comment ne pas introduire de régressions, et comment avoir des solutions qui sont performantes en termes de temps de réponse : des sujets qui importent au client.

De quelle qualité parle-t-on ?

Le lean est peu commode et incarne pour le management ce que la romancière Donna Tartt appelle l’esprit classique : étroit, résolu et implacable. La qualité est son premier sujet car c’est ce qui va permettre :

1. de réduire de façon significative les coûts (avec les gaspillages liés aux retouches),
2. de satisfaire les clients (car être sérieux avec la qualité perçue par le client est un avantage concurrentiel significatif)
3. de développer l’expertise des équipes alors qu’elles travaillent sur la qualité.

C’est pour cela que la seule qualité qui nous intéresse est celle perçue par le client. C’est aussi le premier principe d’ingénierie logicielle de la Continuous Delivery, à l’oeuvre chez les géants du web, principes d’ingénierie qu’il va vous falloir considérer si vous voulez survivre à l’heure du numérique.

Les questions que vous devez vous poser sont celles-ci : la qualité est elle un sujet au sein de mon organisation IT ? De quelle qualité parle-t-on : celle perçue par les équipes d’ingénierie ou celle perçue par le client ? Ces deux notions de qualité sont-elles alignées ? Pour quelles raisons ne le sont-elles pas ? Comment allez vous parvenir à les réconcilier, en donnant toujours la primauté à la qualité perçue par le client ? Quels sont les obstacles qui vous en empêchent aujourd’hui ?