5 idées reçues qui feraient échouer votre transformation DevOps
Contrairement à d’autres démarches de transformation, DevOps n’est pas un référentiel de bonnes pratiques. C’est un principe opérationnel qui invite chaque organisation à repenser son cycle de vie applicatif au regard de ses objectifs stratégiques.
Ces dernières années, « s’aligner avec les métiers » était le mot d’ordre à suivre. Puisque l’informatique était un mal nécessaire, il fallait limiter son emprise au minimum et en réduire à tout prix les coûts par la rationalisation, la standardisation et l’industrialisation. Mais avec l’irruption du digital, tout a changé. Pourtant, l’IT est un vecteur de croissance et de différenciation, donc un élément central de la stratégie de l’entreprise. C’est en réponse à cet enjeu qu’est né DevOps.
Contrairement à d’autres démarches de transformation, DevOps n’est pas une norme ou un référentiel de bonnes pratiques qu’il suffirait d’implémenter ; c’est un principe opérationnel qui invite chaque organisation à repenser son cycle de vie applicatif au regard de ses propres objectifs stratégiques.
La difficulté à assimiler cette différence fondamentale est à l’origine de quelques idées reçues dont l’expérience montre qu’elles sont aussi des facteurs d’échec certain d’une transformation DevOps. Voici les 5 idées reçues que nous vous invitons à ne pas mettre en œuvre :
1. L’essentiel, c’est de commencer par avoir les bons outils !
C’est un réflexe de longue date dans l’IT : quand on ne sait pas exactement par où débuter, on met en place des outils. Or, comme l'expliquent les experts du sujet, « DevOps ne peut se réduire aux outils, ni même aux pratiques agiles et à l’automatisation. C’est plus que cela. La finalité de DevOps est de rendre l’entreprise plus compétitive, plus profitable et plus saine grâce à la livraison continue de logiciels de haute qualité. » Autrement dit, l’outillage n’est qu’un moyen. Le point de départ de la réflexion, ce doit être la stratégie de l’entreprise et la part du logiciel dans son modèle de création de valeur.
Pour les pères fondateurs de DevOps, la transformation se déroule d’ailleurs en quatre temps que l’on peut résumer ainsi : identification des impacts, examen de la chaîne de valeur de l’entreprise, configuration et déploiement agile et lean et, enfin seulement, implémentation et déploiement de la chaîne d’automatisation. DevOps apparaît bien comme un sujet d’entreprise et, à ce titre, il requiert le sponsorship de la direction générale.
2. Inutile de tester. Ce qui compte, c’est d’être agile !Au prétexte d’être agile et de vouloir aller vite, certains sont parfois tentés d’éliminer des tâches jugées secondaires et fastidieuses, comme les tests ou la documentation. Après tout, si cela ne fonctionne pas, il sera toujours possible de corriger plus tard. À confondre ainsi agilité et agitation, vitesse et précipitation, le risque est d’engendrer un monstre de complexité et de faire exploser les coûts d’exploitation. Pour remédier à des problèmes qui auraient pu être anticipés, il faudra en effet mobiliser des experts en phase de run, donc en urgence. Google lui-même a dû mettre le holà en responsabilisant ses développeurs face à l’explosion de micro-services.
DevOps ne signifie donc pas la fin des tests mais leur décalage « vers la gauche », c’est-à-dire plus en amont afin de fiabiliser au plus tôt ce qui est livré. Au lieu d’être une étape à part, le test doit être une pratique et une préoccupation continue tout au long du cycle de développement.
3. Pour faire du DevOps, il faut recruter des « DevOps » !Les compétences et l’état d’esprit particuliers que requiert DevOPs ne sont pas réservés à quelques profils atypiques qui auraient pour mission de réaliser tout ce qui s’écarte de l’ordinaire des équipes en place. La transformation DevOps peut au contraire s’appuyer sur des ressources « Dev » ou « Ops » et les faire évoluer pour peupler les rôles et les métiers de la nouvelle chaîne de delivery : intégration continue, déploiement continu, testing, gestion des versions…
Plus encore qu’une mise à jour des compétences techniques, DevOps est une transformation culturelle car il s’agit de réunir autour d’une démarche et de préoccupations communes des populations – développeurs et exploitants – jusqu’alors cloisonnées et aux priorités antagonistes. C’est pourquoi il est impératif d’associer les ressources humaines et d’accepter que l’implémentation de DevOps prenne du temps.
4. Le seul objectif, c’est la vitesse !Certes, accélérer le time-to-market est souvent l’un des
principaux objectifs d’une démarche DevOps, mais cela ne signifie pas qu’il
faille oublier toute prudence. Pour aller deux fois plus vite, il faut aussi
être deux fois plus vigilant. Étant donné son caractère stratégique, la
livraison continue doit être conçue comme un moteur puissant qui devra
impérativement rester sous contrôle. C’est pourquoi la solution doit prendre en
compte la vitesse cible afin de mettre en place les garde-fous appropriés pour résister
à l’inévitable pression des métiers. Sinon, gare au surrégime et à la sortie de
route !
Le référentiel Safe, par exemple, organise des sprints de deux semaines ainsi
que des sprints réguliers de consolidation et d’innovation pour traiter les
back logs et les évolutions. Dans ce cadre, la vitesse est élevée mais bridée,
et elle ne risque pas de devenir une quête effrénée à laquelle tout serait
sacrifié.
Les habitudes ayant la vie dure, DevOps est souvent perçu comme une nouvelle étape dans la perpétuelle quête de réduction des coûts engagée par l’IT depuis plus de vingt ans. Par réflexe, la DSI va donc bien souvent structurer sa transformation autour des seuls gains opérationnels. C’est une erreur fondamentale.
En effet, DevOps a été conçu pour servir directement la stratégie de l’entreprise et c’est donc au regard de sa contribution au business que doivent être mesurés ses bénéfices. Bien entendu, la DSI doit maîtriser ses coûts, tenir ses budgets et rationaliser ses ressources, mais, désormais, ces dépenses peuvent être confrontées à une valeur créée. Expliciter et mesurer cette dernière est l’une des clés du succès de DevOps.
En conclusion, beaucoup d’entreprises cherchent aujourd’hui à adopter DevOps car elles y voient, à juste titre, une réponse adaptée aux défis posés par le digital. Les premiers retours d’expérience et la maturité croissante des acteurs leur permettent désormais de se garder de ces idées fausses et d’aborder avec méthode et sérénité les différents aspects de cette transformation. Toutefois, un enjeu particulier est de parvenir à faire cohabiter cette transition avec les processus bien rôdés de la mise en production du legacy. Car en transformant la DSI, il faut veiller à ne pas créer deux entités parallèles. Ce point crucial fera d’ailleurs l’objet d’un article spécifique, à découvrir prochainement…