Beaucoup de DSI estiment avoir fait le travail et être parvenu à un bon niveau d’agilité en mode DevOps, tout en menant leur transformation cloud.
Se montrant plutôt sceptique, Silicon titrait de manière provocante en janvier : « DevOps : les DSI se voient trop beaux ». Le site rappelle que 60% des DSI se considèrent suffisamment agile sur des projets de petite taille. Mais les chiffres s’effondrent à 18% sur des projets plus conséquents. On touche là l’une des problématiques de fond de l’agilité, et plus généralement de l’innovation.
Sur un périmètre réduit, au sein d’une petite équipe ou encore dans une start-up, il est très facile d’être en rupture (pour l’innovation) et d’être extrêmement fluide et réactif (pour l’agilité). Les ennuis commencent quand il s’agit de mettre à l’échelle et d’industrialiser l’une et l’autre, notamment dans les grandes entreprises. Paradoxalement, ce sont ces dernières qui sont les plus séduites par le mouvement DevOps. Elles doivent alors garder en tête quelques points clés :
1) La culture du changement, ce n’est pas que pour les métiers
L’accompagnement au changement est un facteur primordial de transformation. A sous-estimer le poids et l’inertie qu’ont les habitudes sur le fonctionnement quotidien, on rend vite superficiels les gains que l’on souhaite obtenir en changeant les processus.
Vis-à-vis des utilisateurs métiers, les DSI sont les premiers à reconnaitre que les contournements plus ou moins visibles, la résistance passive, et les effets de bords inattendus, sont une réalité systématique quand on introduit un nouvel outil ou un nouvel usage dans l’entreprise.
Ne nous leurrons pas, il en va de même pour les équipes de la DSI elle-même.
Partir du principe que les avantages promis (sur le papier ou dans le discours) sont suffisant pour emmener tout le monde dans le sillage de la transformation parait être une erreur de débutant, et pourtant…
L’agilité ne se décrète pas. Tout l’accompagnement qu’il est possible d’imaginer pour en faire une expérience quotidienne est donc bon à prendre.
2) N’oubliez pas trop vite les Ops !
C’est le problème quand on parle d’agilité. Historiquement, le sujet a d’abord séduit les équipes de développement. Scrum, Kanban et consorts sont partout et, pour les sujets concernés, cela fonctionne. Sauf que DevOps vise justement à éviter le décalage trop important qui peut se créer entre une partie de la DSI nourrie à la stratégie digitale et qui avance à tout vitesse sur l’innovation, et ceux qui doivent ensuite rattacher les wagons en production.
Dans une vision DevOps, il faut insister plus que jamais sur la deuxième syllabe, car ce sont justement les « Ops » qui vont être les garants de la capacité d’industrialisation de l’innovation dans l’entreprise. Or, dans beaucoup de situation, c’est bien la production informatique qui est mise devant le fait accompli de la « transformation digitale » décrétée par les hautes instances de l’entreprise et qui se sent comme la 5e roue du carrosse.
Pour schématiser : les efforts principaux d’une montée en puissance DevOps sont à consacrer aux Ops dont la priorité est que tout tourne sans accroc, plutôt qu’à des développeurs pour qui l’agilité est aujourd’hui un must-have du marché. Ce qui ne veut pas dire que la production n’est pas prête à changer, bien au contraire.
3) DevOps et stratégie cloud sont à lier intimement…
Dans le même ordre d’idée, gagner en agilité à tous les étages ne peut pas se limiter à un parti pris uniquement organisationnel. Sans retrouver la même flexibilité au niveau des infrastructures, même en étant de très bonne volonté, le fossé risque d’être trop important.
En tout logique, le cloud est censé apporter des réponses à ce niveau. En soi, la consommation à la demande, l’automatisation, la facilité de déploiement et la richesse des offres à disposition, semblent jouer en faveur d’une meilleure agilité sur la partie technique.
C’est oublier la complexité inhérente qui accompagne souvent le cloud dans les organisations de taille importante. On le sait, le sujet est hybride et la définition de la « bonne » gouvernance d’un système d’information, très étendu et parfois fragmenté, reste une priorité en matière de stratégie cloud. Les deux points sont donc à traiter en parallèle et en résonnance. L’agilité des hommes ne s’imagine pas sans mettre en musique celle de leurs outils… et vice-versa.
4) … et vos partenaires à challenger proactivement.
Or, la situation peut se corser, à partir du moment où l’on considère qu’un SI étendu, hybride, lie toujours plus votre agilité à celle d’éventuels prestataires. Dans le cas de consommation de services de cloud public « purs », la dimension de self-service fait que cet aspect ne se ressent pas. Mais d’autres approches IaaS, où l’accompagnement du partenaire infogéreur se doit d’être beaucoup plus important, posent la question différemment. A quoi vous servira d’avoir fait augmenter drastiquement la maturité DevOps de vos équipes si c’est pour déplacer le goulet d’étranglement, le « mur » qui risquait de se dresser entre études et production, un cran plus loin… au niveau dans la relation avec votre partenaire ?
Cette coopération par nature plus étroite est une conséquence d’un SI de plus en plus ouvert sur l’extérieur. Pour éviter les mauvaises surprises, il faut donc s’assurer dès le départ de la capacité des partenaires à savoir accompagner à leur niveau le mouvement DevOps : réactivité, fiabilité et disponibilité des interlocuteurs, capacité à calquer les processus sur les vôtres, etc. Et comme souvent, les premiers indices peuvent s’obtenir facilement : posez ouvertement la question. La clarté et la nature des réponses obtenues permettront de se faire une opinion rapide de la perception « DevOps » de votre partenaire.