Agilité : de l’incantation à la mise en oeuvre, un changement de culture

Bernard Ourghanlian
Directeur technique et sécurité chez Microsoft France

Si l’on admet avec le Wall-Street Journal et Forbes que le « logiciel dévore le monde », la cinétique du logiciel accélère tout sur son passage et les entreprises doivent s’adapter pour survivre dans une logique toute darwinienne. Dans ce monde digital, le mantra des entreprises tient désormais en un seul petit mot, « agilité », qui est répété ad nauseam dans tous les médias traitant du sujet. Pourtant, force est de constater qu’aujourd’hui encore les approches « agiles » ont peine à se frayer un chemin dans des entreprises où l’on utilise toujours les approches « en cascade » passant par des phases séquentielles : recueil des besoins, analyse détaillée, conception détaillée, développement, tests et intégration. Cette approche, outre sa rigidité qui ne permet pas le retour arrière, conduit immanquablement à un effet tunnel. Combien de fois voiton, en effet, les directions informatiques réfléchir à un cahier des charges pendant plusieurs mois avec les métiers, le proposer au marché puis sélectionner un fournisseur qui passera les premiers mois du projet à réaliser l’analyse et la conception détaillées de ce que ce dernier développera avant de le faire valider par son client ? Une telle approche conduit inévitablement à laisser s’écouler des mois, voire même des années dans le cas de grands projets, entre l’idée initiale et le début du développement. Pendant ce temps, l’équipe projet produit généralement une documentation pléthorique qui ne sert pas à grandchose hormis rassurer artificiellement son client et…repousser le moment où il va falloir démarrer la phase de codage qui, elle, est irréversible… Pendant tout ce temps, les technologies auront évolué de manière substantielle, et les besoins en auront fait tout autant… Autrement dit, la probabilité est grande qu’un écart significatif s’établisse entre les besoins des utilisateurs et ce qui sera délivré en fin de projet et donc qu’au final le projet échoue.

Pourquoi, alors que les approches agiles ont vu le jour aux Etats-Unis en 2001 avec la publication du « Manifeste pour le développement logiciel agile¹», semble-t-il si difficile de mettre en oeuvre de telles approches en France ? Il suffit de lire quelles sont les quatre valeurs mises en avant dans ce manifeste pour le comprendre :
– des 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égo ciation contractuelle ;
– l’adaptation au changement plus que le suivi d’un plan.

Quand on lit ces valeurs, on se rend compte que celles-ci placent l’homme au centre du dispositif, tout en insistant sur la nécessaire collaboration entre client et fournisseur. Ainsi, le développeur devient un artisan qui exprime sa créativité et se réalise dans son art tout en interagissant avec ses pairs et avec son client. Dans un tel environnement, la prise de décision est effectuée au sein des équipes de développement produit, leur management étant à leur service pour créer un environnement facilitant la créativité et la productivité. On n’est plus dans la vision traditionnelle du manager qui contrôle et donne de « la carotte et du bâton » ; bien au contraire, le manager doit pratiquer le « lâcher prise » en encourageant la responsabilisation et la prise de décision de ses équipes qui s’auto-organisent tout en stimulant le développement de synergies, et l’amélioration continue.

On voit bien qu’une telle approche remet en cause le modèle taylorien où la hiérarchie et le cloisonnement règnent en maîtres.

C’est en ce sens que l’irruption des approches agiles au sein des entreprises est si difficile. Si l’on y ajoute le fait que celles-ci reposent sur une collaboration entre clients et fournisseurs, on se rend compte que l’on évoque ici un véritable changement culturel. Que celui-ci concerne les entreprises elles-mêmes, si elles réalisent elles-mêmes leurs logiciels, ou les ESN (Entreprises de Services du Numérique) qui réalisent ces logiciels pour leurs clients. En se souvenant que le développeur est l’artisan qui donne vie au logiciel, ce qui veut dire que ce n’est pas un ouvrier du code, un col bleu de l’informatique, un « pisseur de code » surveillé par son manager… mais un contributeur clé de l’entreprise qu’il convient de reconnaître et de développer.

Par ailleurs, les approches agiles sont généralement couplées au « DevOps » qui invite à transcender la frontière classique entre études (« Dev ») et production (« Ops ») et au « Continuous Delivery » où l’on déploie en continu. Autant de changements de paradigmes au sein de la DSI…

C’est au prix de ce changement de culture que les entreprises deviendront vraiment agiles. « Ce n’est pas parce que les choses sont difficiles que nous n’osons pas. C’est parce que nous n’osons pas qu’elles sont difficiles. » [Sénèque].

1- http://www.agilemanifesto.org/