Artisanat logiciel, la qualité 2.0 ?

Ceux qui suivent ce blog savent que je n’en suis plus à faire mes premières armes en matière de développement logiciel ; sur plus d’une vingtaine d’années d’expérience, j’ai vu passer quelques mutations dans notre métier, et pas seulement du point de vue technologique. Notre secteur est encore jeune et cherche encore à se structurer, à s’outiller, à se professionnaliser. Le mouvement de l’artisanat logiciel (ou Software Craftsmanship), né il y a quinze ans, commence à se faire entendre et ses principes sont de plus en plus largement adoptés au sein des entreprises. Deux présentations du dernier Devoxx France (« Le Craft : des concepts au déploiement à l'échelle » par Matthieu VINCENT et Guillaume LE DAIN de Sopra Steria) ; et « Du bonheur dans le Craft » par Cédric MAGNE et Hippolyte DURIX de Ippon Technologies) abordent le sujet du « craft » avec des points de vue différents mais également de nombreux points communs. L’un de ces points communs est la mise en avant de la qualité. L’évocation régulière de la qualité logicielle dans les médias qui abordent la question du craft serait-il le signe que l’artisanat logiciel est le fer de lance du renouveau de la qualité ?

Le fait que je mentionne un « renouveau » suggère que la qualité serait tombé en désuétude après une période faste. En effet, au début des années 2000, au moment où je débutais ma carrière, la qualité logicielle était au cœur des préoccupations des sociétés de services informatiques et de leurs clients. Aux efforts que ces sociétés consacraient à l’obtention ou au renouvellement des certifications ISO s’ajoutaient ceux qui permettaient d’afficher la maturité la plus élevée possible sur des échelles telles que le Capability Maturity Model Integration (CMMI). Cet âge d’or de la qualité s’inscrivait alors dans une quête d’industrialisation des métiers de l’informatique. Les recette fordiennes qui avaient assuré le succès des industries classiques devaient pouvoir s’appliquer à l’informatique : il fallait fixer des objectifs parfaitement spécifiés, et définir des processus et les outils associés pour supporter et mesurer l’avancement des projets. L’assurance qualité s’occupait de la définition des processus pendant que le contrôle qualité s’assurait de leur bonne mise en œuvre. Pourtant au tournant du nouveau millénaire, le constat est décevant : trop de projets échouent encore, soit parce qu’ils ne délivrent pas le bon produit, soit parce qu’ils ne respectent pas les budgets.

Le premier tournant qui me semble mettre à mal la qualité logicielle est celui de l’essor du mouvement agile, ou plus exactement de certaines de ses dérives. En 2001, le manifeste agile est rédigé et propose quatre piliers qui viennent remettre en cause les orientations suivies jusque là pour mener les développements logiciels. L’assurance et le contrôle qualité, au cœur de ces approches, sont indirectement mis en cause par trois des quatre principes :

Les individus et leurs interactions plutôt que les processus et les outils. L’assurance qualité est justement au cœur de la définition des processus et outils qui viennent cadrer les projets de développement. Redonner de la place aux individus et à leurs interactions consiste d’une certaine manière à accepter les limites de la standardisation des processus en reconnaissant l’individualité, la spécificité des individus. Elle invite également à ne pas contraindre les échanges entre les membres du projet avec des outils collaboratifs rigides.
Un logiciel fonctionnel plutôt qu’une documentation exhaustive. La documentation est au cœur de l’industrialisation du développement informatique au début des années 2000. On documente tout ce qu’on souhaite faire, tout ce qu’on doit faire, tout ce que l’on fait. Cette documentation exhaustive est essentielle à la fois pour l’assurance qualité (ce qu’on doit faire) et le contrôle qualité (ce que l’on a fait).
L’adaptation au changement plutôt que l'exécution d’un plan. Ce principe vise très directement le cycle en V qui suppose, vœu pieux, de connaître parfaitement le besoin pour le transformer successivement en exigences logicielles, en documentation de conception, et en logiciel et documentation d’usage. Le référentiel qualité est là pour cadrer ce processus. Suggérer qu’il faille s’adapter aux changements revient à accepter que l’on ne sait pas tout et que le processus de développement ne peut être un automatisme sans boucle de rétroaction. Ces hypothèses ne sont pas celles sur lesquels les référentiels qualité des années 2000 étaient construits.

Non seulement ces principes de l’agilité ont bousculé les piliers de la qualité logicielle, mais leur application déséquilibrée en a renforcé l’impact. En effet, la diffusion du manifeste agile, souvent orale, s’est accompagnée d’une déformation des principes. Et plutôt que de lire « Un logiciel fonctionnel plutôt qu’une documentation exhaustive », certains ont entendu « Pas de documentation » ; cette remarque s’applique aux autres principes qui ont ainsi été compris « Pas de processus » et « Pas de plan ». Plutôt qu’une adaptation des principes de la qualité logicielle aux méthodes agiles, ces excès ont conduit à éliminer purement et simplement la qualité de nombreux projets.

Le second tournant qui a fragilisé la qualité logicielle telle qu’elle existait au tournant des années 2000 est celle de l’émergence de ce qu’on regroupe aujourd’hui sous le nom de DevOps et qui ne portait alors que le nom d’Intégration Continue. L’émergence progressive de l’outillage associé au DevOps a en effet consisté à automatiser les activités qui permettent de projeter l’application de son code source vers un logiciel exécutable dans son environnement de production. Pour mitiger le risque de remplacer accidentellement une version opérationnelle du système par une version inopérante, les chaînes d’intégration, de livraison et de déploiement continu ont progressivement intégré des mécanismes de contrôle, eux aussi automatiques. Or, une partie de ces contrôles correspond à l’activité de contrôle qualité qui était portée par des ingénieurs qualité et leur outillage. Autrement dit les activités de contrôle et les outils des ingénieurs qualité ont été intégrés dans des chaînes automatiques, donnant le sentiment que les ingénieurs qualité n’étaient plus utiles qu’à contrôler des artefacts documentaires (pour les projets qui ne pensaient pas par ailleurs que l’agilité leur dictait « Pas de documentation »).

Après ces deux tournants, le rôle des qualiticiens sur les projets a de moins en moins été apprécié. Le gardien du temple en a été chassé et de mauvaises choses sont arrivées. De plus en plus nombreux furent les projets à partir sur une démarche d’improvisation permanente avec le faux sentiment de sécurité de contrôles automatiques qui avaient exclu tout jugement humain. Et la question s’est alors posée : pourquoi, alors que nous appliquons des méthodes agiles et que nous outillons nos développements, nos projets ne sont-ils pas plus souvent des succès ? Certains signataires du manifeste agile n’ont pas tardé à mettre le doigt sur le problème : on avait progressivement négligé les fondamentaux techniques de notre métier du développement logiciel. Le manifeste du Software Craftsmanship propose un rééquilibrage des valeurs de l’agilité pour renforcer la valeur technique. Et certains de ces rééquilibrages ressemble à ce que la qualité proposait d’apporter aux projets :

Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus. La conception du logiciel, ou la question de sa structure, est l’un des éléments qui était mis en avant par la qualité logicielle. En effet, les exigences non fonctionnelles auxquelles les ingénieurs qualité prêtaient attention sont davantage liées aux choix de conception du logiciel qu’à son comportement.
Pas seulement l'adaptation aux changements, mais aussi l'ajout constant de valeur. La question de l’ajout constant de valeur est connexe à cette la conception logicielle. Ce qui vient en général freiner l’ajout de valeur est aujourd’hui communément appelé « dette technique » et correspond à l’ensemble des compromis de qualité qui ont été faits pour délivrer rapidement de la valeur en début de projet.
Pas seulement les individus et leurs interactions, mais aussi une communauté professionnelle. La professionnalisation revient aussi sur ce qu’il est légitime d’accepter en matière d’individualisation des pratiques. Certes, il reste important de garder à l’esprit que la création logicielle est l’œuvre d’individus ayant des sensibilités et pratiques différentes, mais ce principe du manifeste nous rappelle également notre aspiration à former une profession, c’est-à-dire à nous réunir derrière un consensus de valeurs et de pratiques. C’est à une autre échelle ce que se proposait un référentiel qualité : sur un projet, des pratiques recommandées ou imposées.

En notant cette convergence entre les principes de l’artisanat logiciel et la qualité des années 2000, on serait tenté de conclure à un renouveau qui se contente d’appeler « artisan logiciel » ce qu’on appelait anciennement « ingénieur qualité ». Ce raccourci n’aurait pourtant pas de sens :

L’artisan logiciel n’agit pas uniquement en support du projet mais est au cœur de la réalisation logicielle. Alors que le DevOps tend à briser les barrières entre les rôles, il serait contreproductif de vouloir réinstaurer une telle séparation des rôles. Par contre, l’artisanat logiciel responsabilise le développeur non seulement sur sa production mais sur la production de l’équipe entière. Les pratiques de renforcement de la propriété collective du code (« code ownership ») que sont les revues de code (« peer review »), le binômage (« pair programming » ) et la programmation en groupe (« mob programming ») sont là pour rappeler, au-delà de leur rôle de communication, que le jugement humain reste un complément nécessaire au contrôle automatisé.
Par ailleurs, les bonnes pratiques généralement véhiculées dans la culture de l’artisanat logiciel ne sont pas toujours strictement alignées sur les règles qualité d’autrefois. L’exemple du « taux de commentaire » est à ce titre particulièrement révélateur. Alors que la qualité imposait la documentation du code avec des commentaires, la présence de commentaire est maintenant vue comme suspecte ; comme, pour reprendre les termes de Martin Fowler, un déodorant pour du code qui sent mauvais.

Si l’artisanat logiciel ne peut pas simplement être qualifié de « qualité 2.0 », ce mouvement culturel porte en lui un facteur décisif : alors que l’ingénieur logiciel en 2000 pouvait s’astreindre à respecter un certain niveau de qualité par contrainte, l’artisan logiciel d’aujourd’hui fait le choix de la qualité par professionnalisme et par souci du « travail bien fait ». Comme tout courant culturel, l’artisanat logiciel est menacé de dérives dogmatiques et l’avenir nous dira si un nouveau rééquilibrage doit s’opérer. Mais ce mouvement est aujourd’hui celui qui nous rappelle, qu’en tant que professionnels du développement, nous ne pouvons pas travailler sans prêter attention à la qualité logicielle.