Aristote contre les Balles d'Argent

C’est drôle, on sait tous qu’il n’y a pas, en informatique, de « silver bullet ». L’idée qu’une solution technique va tomber du ciel — ou du carquois d’un consultant — relève du voeu pieu, du deus ex machina, voire de la pensée magique. Vous n’avez probablement pas obtenu vos diplômes parce que soudain quelques jours avant l’épreuve, vous avez trouvé LA technique idéale de mémorisation.

Vous savez que, statistiquement, l’EuroMillion n’enrichit pas ses clients (sinon les riches joueraient à l’EuroMillion).

Mais si vous êtes développeur, chef de projet, directeur d’études ou DSI, en revanche, vous êtes déjà probablement tombé dans le piège d’un nouvel outil ou d’une nouvelle technologie en vous disant : « Cette solution innovante va probablement marcher; en tout cas il le faut absolument (ou: en tout cas j’en ai vraiment envie). Je signe. » 

Le Transfert de l’Agile

Prenez les méthodes agiles, par exemple. Elles sont en train de révolutionner — paraît-il — la façon dont on crée du logiciel en entreprise. Info ou intox ? Si vous laissez de côté la part de sur-médiatisation via internet pour observer la démarche sur le terrain, l’agile en tant que tel ne touche qu’une minorité d’entreprises, et ce contact ne se transforme pas automatiquement en réussite.

Est-ce que ça veut dire que l’agile ne marche pas ? Non plus. Ceux qui témoignent et transmettent leur expérience de l’agile sont sans doute de bonne foi. L’agile fonctionne dans leur contexte. Ce qui ne signifie pas que l’agile tel qu’ils ont appris à le pratiquer peut se transférer, intact, dans mon contexte.

Nous l’avons tous observé, le transfert d’une technologie ou d’une méthodologie d’une entreprise à l’autre représente un projet de changement complexe, parfois chaotique, et toujours risqué. Mais si votre projet est en difficulté depuis des mois, connaît des problèmes insurmontables de qualité, un planning intenable, un budget en dépassement, alors la tentation est trop forte : soit tous ceux qui racontent leur succès avec l’agile sont des menteurs, soit l’agile est précisément la solution miracle qui vous manque. Sa promotion au rang de silver bullet est donc imminente.

Pourtant faut-il systématiquement se déjuger à propos de ces idées nouvelles ? « Sur le papier, ça marche, dans la vraie vie.. ».

Non. Il faut simplement les adapter, pour les adopter. Si nous ne voulons pas jeter le bébé (des principes de développement pragmatiques utilisant le retour d’information, la collaboration, et l’amélioration continue) avec l’eau du bain (les discours sensationnels), il faut peut être faire tomber quelques illusions avant que celles-ci ne se transforment en clichés, voire en mythes.

Quelques Mythes en Puissance

« Avec l’agile, mes équipes vont être bien plus performantes. » Avec le développement itératif, les problèmes et les difficultés de l’équipe vont apparaître rapidement, ce qui devrait permettre de les résoudre assez tôt pour limiter leur impact sur le projet.

« Avec l’agile, mon planning ambitieux tient la route. » En constatant la vélocité de l’équipe à chaque itération nous pourrons réajuster rapidement et régulièrement le planning.

« La vélocité, très faible au début, progresse au bout d’une ou deux itérations. » La vélocité est faible lorsque l’équipe se trouve face à des problèmes, et elle augmente après que ces problèmes sont résolus.

« Avec l’agile, les équipes sont autonomes. » L’autonomie d’une équipe est fonction des relations à l’intérieur et à l’extérieur de cette équipe; une méthode de développement ne définit qu’une partie (la partie formelle) de ces relations.

« Avec l’agile, j’ai des tests automatisés. » Les techniques de tests s’acquièrent indépendamment de la méthode choisie pour le développement. La majorité des développeurs ignorent d’ailleurs ces techniques, que l’on peut apprendre en 3 jours et maîtriser en quelques semaines de pratique.

« Pour faire de l’agile il faut d’excellent développeurs. » L’agile repose (comme toutes les autres démarches) sur le travail en équipe. Une équipe apporte la diversité, la cohésion et le dépassement de soi nécessaires pour surmonter des difficultés extraordinaires. Si l’équipe fonctionne bien, ses résultats dépasseront de loin la somme des résultats des meilleurs développeurs.

« Avec l’agile, ça va marcher! » Si la volonté d’améliorer la qualité du développement et la volonté de travailler en vision partagée ne sont pas là, adopter une méthode agile n’est d’aucune utilité pratique.

Contre les Balles d’Argent

Un jour, les méthodes dites agiles seront peut être monnaie courante dans la majorité des DSI. Pourquoi pas. Nécessairement, elles auront été adaptées, et progressivement adoptées (et non sans peine). Mais d’abord elles doivent être démystifiées.

On pourrait se demander entre informaticiens d’où nous vient cette propension à fondre, forger et façonner des balles d’argent.

Certains diront : le marketing! Mais le marketing automobile ne nous vend pas des voitures qui peuvent s’envoler au dessus des embouteillages.

D’autres diront: c’est une science jeune! Mais justement une science s’appuie sur des observations que l’on peut reproduire.

Alors pourquoi toutes ces balles d’argent dans le folklore informatique ? Peut-être parce que le but ultime de cette discipline, son rêve et son saint-graal, c’est de terrasser et de maîtriser une fois pour toute la complexité. Or ce monstre renaît de chaque nouvelle victoire technologique, car en informatique chaque nouveau succès engendre de nouvelles ambitions.

Conclusion

La balle d’argent, c’est une solution immédiate et définitive à un problème, autant dire un rêve. Et l’alternative au rêve, c’est un progrès lent, rigoureux, jamais définitif: une discipline.

Fred Brooks a montré qu'il n'existe pas de « Silver Bullet ». Inutile de rêver. Il reste à trouver comment se discipliner. Mais ça nous le savons depuis Aristote: « L’excellence est un art que l’on n’atteint que par l’exercice constant. Nous sommes ce que nous faisons de manière répétée. L’excellence n’est donc pas une action mais une habitude ».