Un précédent article nous a permis de détailler les gains attendus de la mise en œuvre de déploiement automatisé. Mais il est évident que tout ceci ne se fait pas tout seul : au-delà du coût de mise en œuvre, il faut prendre en compte des aspects plus généraux.
Qu’implique le déploiement automatisé ?
Un des avantages attendu est l’uniformisation des habitudes de travail de toutes les équipes ; cela implique inévitablement de changer ces au préalable les dites habitudes. Tous les acteurs des projets concernés sont affectés : MOE, MOA bien sûr, mais aussi les gestionnaires de services, les exploitants ou infogérants, et même les utilisateurs finaux qui participent aux tests. Ce changement d’habitude peut se faire progressivement, au fur et à mesure de l’implication pratique des équipes : d’abord la MOE et la MOA, et ensuite les autres équipes jusqu’à la production.
Pour que les habitudes deviennent uniformes, il faut aussi que la plate-forme de déploiement soit disponible en amont, prête avant que chaque équipe en ait besoin, et surtout qu’elle gère les fonctionnalités dont chaque équipe aura besoin.
Il peut aussi y avoir des aspects contractuels à traiter, notamment avec l’exploitant. Un exploitant qui facture à l’acte ne sera pas forcément enclin à coopérer à la mise en place d’un outil destiné à réduire drastiquement le nombre d’actes impliqués dans une installation !
Tout ceci implique qu’il faille un pilotage par le haut, et qu’il faut donc convaincre la direction du bien-fondé d’un projet de déploiement automatisé avant sa finalisation. Surtout dans un grand SI, il arrivera toujours un moment où la persuasion ne suffit pas, et il faudra imposer certaines façons de faire : ce n’est pas possible sans l’appui de la direction.
Le jeu en vaut-il la chandelle ?
Nous avons vu en première partie les gains qualitatifs et organisationnels qu’on peut attendre d’un déploiement automatisé : principalement une certaine indépendance vis-à-vis du réalisateur, une qualité technique maîtrisée, des déploiements rapides et sans risque, des habitudes communes à toutes les équipes. On aboutit ainsi à la possibilité de mettre en place des cycles rapides, avec peu de friction technique dans les allers-retours entre l’expression d’un besoin et sa mise en œuvre effective.
On reconnaît ici un aspect facilitateur d’un des principes de l’agilité : l’acceptation du changement. S’il est simple de mettre en œuvre des modifications (ce qui ne préjuge pas de la complexité de réalisation des modifications), si la distance entre un projet tel qu’il est sur le poste d’un développeur et le même projet livré de façon à être utilisable par les équipes de recette, c’est un élément de friction en moins pour des itérations rapides dans le processus de développement. La maîtrise de la qualité, notamment par des tests automatisés, réduit de plus les risques liés aux changements, et accroît d’autant l’agilité du projet.
On reconnaît également des aspects d’une autre méthodologie : le mouvement devops. Traditionnellement les objectifs de stabilité du SI s’opposent aux besoins de changement ; le mouvement devops encourage la coopération entre équipes dans le but de réduire cette opposition. Le déploiement automatisé s’inscrit tout à fait dans cette démarche : avec le partage des habitudes, les changements apportés au SI tiennent compte des exigences d’exploitation dès le début, et la stabilité ne vient plus de l’absence de changement mais de la maîtrise de ses impacts.
Qui n’a pas rêvé d’un SI adaptable, où toutes les équipes travaillent ensemble pour le bien de l’entreprise ? Le déploiement automatisé ne répond pas à toutes les problématiques derrière ce rêve, mais il constitue un bon premier pas : même s’il s’agit d’un projet à forte teneur technique, ses avantages sont tangibles à la fois pour la direction SI et pour les métiers. Il ne reste plus qu’à trouver les bons acteurs !
