De nos jours, la gestion de projets en mode « agile » est de plus en plus utilisée dans les entreprises. Elle est même à la mode. En effet, ses principes, ou du moins certains de ses modes de fonctionnement sont même appliqués à des processus de transformation de l’entreprise qui se doit elle-même d’être de plus en plus agile, réactive.
Cependant, cette méthode est encore souvent employée dans un cadre qui n’est pas agile, avec, dès le départ, une demande du « client » d’avoir certaines fonctionnalités livrées à un moment donné (ce qui va en soi un peu à l’encontre du principe même des méthodologies agiles). Entre parenthèse, il me semble aussi assez souvent qu’une partie des quatre principes de base de la méthodologie (le focus sur les personnes et de leurs interactions, l’importance de livrer un logiciel opérationnel avant tout, l’implication forte du « client » dans le processus et l’adaptation continue aux changements) sont souvent ignorés ou minimisés, probablement de par la différence culturelle que cela implique au sein de l’entreprise.
Mais ce n’est pas là que je veux porter votre attention aujourd’hui. Parmi les méthodes « agiles », celle que je rencontre le plus souvent, pour ne pas dire exclusivement, est la méthode Scrum. Pourtant, ce n’est pas la seule méthode agile existante. XP, eXtreme Programming, développée en 1999, un peu après Scrum (en 1995), s’inspire aussi des principes de la méthode agile. Une des pratiques courantes de la méthode XP est le binômage, la programmation en binôme. Ce mode de programmation requière deux programmeurs: le conducteur (driver) et l’observateur (observer). Le conducteur programme pendant que l’observateur l’assiste en faisant une revue du code en direct. Déjà, du point de vue des bonnes pratiques de sécurité, telles celles édictées par la désormais incontournable OWASP, la case « revue du code source par une tierce partie » peut-être cochée. Mais de plus, cette pratique semble permettre d’augmenter la vitesse de livraison et la qualité du code fourni. Quand on connaît le coût et le temps passé à tester et re-tester les applications, une augmentation de la qualité du code devient très vite un avantage financier non-négligeable, sans compter la diminution de la frustration chez les utilisateurs quand ils tombent sur un « bug ». Parmi les autres avantages, celui qui doit théoriquement venir avec les méthodes agiles mais qui devient une condition sine qua non est l’amélioration de la communication au sein de l’équipe, tout au moins, au sein du binôme.
Alors, quand verra t’on le binômage dans nos exigences de sécurité pour les projets de développement?