Analogies numériques

Il est difficile de résister à la tentation de recourir à des analogies lorsqu'on souhaite expliquer certains principes en informatique (et de manière générale en sciences). Les analogies doivent pourtant être manipulées avec précaution, chacune d'elles ayant ses limites et pouvant induire de fausses idées lorsqu'on les dépasse. Je recours pourtant sans trop hésiter aux analogies avec le monde du bâtiment lorsqu'il s'agit de présenter certains concepts clés d'architecture. D'autres analogies provoquent au contraire chez moi un certaine questionnement.

Cette semaine, à l'occasion d'un afterwork réunissant les architectes toulousains de Capgemini, j'ai été saisi par la divergence entre deux conceptions de notre métier et de son système de valeurs.

I love craftsmanship

"I love craftsmanship", c'est le message qu'on pouvait deviner sur le T-Shirt d'un participant du dernier forum Devoxx. Voilà un message auquel j'adhère mais qui m'a semblé en décalage avec le vocabulaire utilisé dans d'autres présentations qui font référence à l'industrie: "foundry", "production line", "robot", "automation", "factory"... L'informatique relève-t-elle actuellement davantage de l'artisanat ou de l'industrie ? Et vers quel modèle souhaite-t-on la voir tendre ?

De nombreuses années, j'ai entendu dire que "notre industrie est jeune" comparée à l'automobile ou encore l'aéronautique mais que nous allons progressivement "gagner en maturité" avec de meilleures méthodes, de meilleurs outils, de meilleurs processus, une meilleure organisation. La voie semblait alors toute tracée vers une industrialisation de notre métier jusqu'à ce qu'on commence à entendre un message dissonant: la manifeste agile, publié en février 2001, devait s'inscrire dans le paysage au cours la première décennie du nouveau millénaire, et devenir un modèle de référence incontesté en une petite dizaine d'années.

Les individus et leurs interactions plus que les processus et les outils

Des logiciels opérationnels plus qu’une documentation exhaustive

La collaboration avec les clients plus que la négociation contractuelle

L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

http://agilemanifesto.org/iso/fr/manifesto.html

Les processus, les outils et le suivi d'un plan ne devaient plus être mis en avant ? Voilà des objectifs et une philosophie qui ne ressemblent pas à ce que signifie "industrie" dans d'autres domaines.

En 2008, l'oncle Bob, signataire du manifeste de 2001, propose de le compléter avec une cinquième valeur: "l'artisanat plus que l'exécution" ("Craftsmanship over Execution" dans sa version originale). Le mot est lancé et ne permet plus d'avoir le moindre doute sur ce qui est souhaitable pour notre métier: se développer sur le modèle de l'artisanat.

Le modèle agile ayant triomphé de l'ancien monde et ses démons, au premier rang desquels le modèle "waterfall", la réponse à la question posée en introduction de ce billet a trouvé sa réponse: artisanat, toujours artisanat.

Pourtant, dès 2009, on pouvait lire un billet sur le blog de Martin Fowler, autre signataire du manifeste de 2001, que les principes de l'agilité étaient mal compris et mal appliqués. L'avertissement n'a certainement pas été entendu et j'ai pu noter que certains projets revendiquant une adhésion aux principes agiles ne faisaient qu'appliquer le Flaccid Scrum. Dans son article, Fowler met en avant l'importance de ne pas s'attacher uniquement au pilotage des projets mais également à leur dimension technique, notamment à la gestion de la dette technique.

On retrouve cette volonté de réaliser des logiciels "bien conçus" dans le manifeste pour l'artisanat logiciel de l'oncle Bob. 

Pas seulement des logiciels opérationnels,
mais aussi des logiciels bien conçus.

Pas seulement l'adaptation aux changements,
mais aussi l'ajout constant de la valeur.

Pas seulement les individus et leurs interactions,
mais aussi une communauté de professionnels.

Pas seulement la collaboration avec les clients,
mais aussi des partenariats productifs.

http://manifesto.softwarecraftsmanship.org/#/fr-fr

Les avertissements répétés des initiateurs du mouvement agile (Robert Martin, Martin Fowler, Andy Hunt, Jared Richardson ou encore Ron Jeffries) doivent questionner nos pratiques actuelles et les orientations que nous projetons de suivre. Aujourd'hui Safe vous garantit le passage à l'échelle pendant que DevOps s'inscrit dans la continuité de l'agilité en promettant une réduction des délais de mise en production des nouvelles fonctionnalités. Ce dernier s'appuie pour cela sur des processus et des outils, au premier rang desquels l'intégration continue et la livraison continue. Cette démarche favorise l'automatisation de nombreuses activités et le recours à des infrastructures de production reconfigurables, car virtualisées, qui poussent notre métier à converger à nouveau vers un modèle industriel traditionnel. Safe apporte, pour sa part, des processus et des outils complémentaires pour étendre la taille des équipes Scrum.

En soi, ces tendances ne sont pas mauvaises; elles exigent même que certaines pratiques indispensables, telles que les tests unitaires, soient renforcées (l'absence de tests automatisés rend impossible la mise en place de chaînes de CI/CD... à moins que vous n'acceptiez de pousser en production du code qui n'aurait été que peu ou pas testé). Mais nous ne devons pas oublier qu'adhérer à l'agilité suppose de préférer les individus et leurs interactions aux processus et aux outils. Et si nous ne gardons pas à l'esprit ces fondamentaux, nous ferons réellement de notre activité une industrie, de notre rôle le rouage d'une mécanique, de notre métier celui d'un ouvrier de l'informatique. Ce que vous entendrez alors en arrivant sur votre prochain projet sera "Bienvenu à l'usine".

Le choix d'une analogie est aussi celui d'un système de valeurs. Je suis heureux de voir le logo de Capgemini à côté du message "I love craftsmanship", parce que j'ai choisi celuil-là.