Trois évolutions majeures convergent depuis peu et poussent à une transformation de la DSI des entreprises:
- La pression du time to market : l’accélération du rythme d’évolution des applications, en particulier web, pour sortir au plus vite de nouvelles fonctionnalités et répondre aux besoins du marché
- Le DevOps : pour livrer plus vite, les équipes de Dev font évoluer leurs méthodes pour rendre les déploiements plus rapides, fréquents et fluides, et attendent que l’infrastructures, les « Ops » évoluent au même rythme.
- Le cloud public : il a atteint un niveau de maturité et d’efficacité tel qu’une majorité des DSI travaille maintenant à l’intégrer, souvent sous la pression des équipes de développement,
Ces trois évolutions doivent s’imbriquer comme des engrenages pour donner une nouvelle efficacité à la DSI, c’est un chantier majeur de transformation.
La pression du time to market
Le développement des interfaces web dans les SI a permis la multiplication de nouveaux usages qui sont devenus des avantages concurrentiels. Non seulement la fonctionnalité doit être là, mais elle doit être rapide, intuitive et son efficacité est mesurée en temps réel. Si elle ne rencontre pas le succès, elle doit être modifiée sans attendre au risque de voir le trafic partir chez un concurrent. La pression de la concurrence et des nouveaux entrants est accentuée par cette dimension web. L’utilisateur devant son navigateur peut sanctionner immédiatement une offre non satisfaisante. L’accès immédiat à l’information par le web impose un rythme de mise à jour très rapide. L’arrivée de nouvelles techniques alimente cette course à l’évolution :
- La géolocalisation permet de développer des applis spécifiques sur mobile pour géo-localiser les offres présentes autour de sa position ;
- Le big data permet de personnaliser les offres et l’interface en fonction de votre historique de navigation ;
- Les outils de langage et les chatbots permettent d’effectuer des recherches en posant des questions en langage naturel ;
- L’intelligence artificielle va permettre, au delà des outils de langage et des chatbots, de proposer des réponses à des requêtes complexes, de modéliser des chaînes de traitement.
Et l’on pourrait multiplier les exemples, mais il suffit d’observer l’interface des applications récentes de transport partagé, de recherche de services, ou de tourismes pour mesurer le ryhtme de ces évolutions.
Une autre conséquence de ce mouvement de fonds est l’exigence de flexibilité: on doit pouvoir engager un projet sans forcément en avoir figé tous les contours et exigences. Ceux-ci seront peut être amenés à évoluer en cours de route. On accepte d’engager une réalisation avec une part d’expérimentation et d’incertitude bien plus importante.
Dans cette mouvance, la DSI doit s’adapter et faire évoluer son organisation pour capter et répondre plus rapidement aux besoins du métier tout en restant garante de la sécurité, de la disponibilité et de la performance. Ce qui est nouveau, c’est que la DSI ne peut plus résister à la pression du time-to-market en s’abritant derrière ses méthodes.
Le mode DevOps
C’est cette pression du time-to-market qui a conduit à la généralisation récente du mode DevOps. Livrer en continu et en flux tendu des fonctionnalités a fait émerger une nouvelle organisation des équipes de développement. Le fameux cycle en V, long et incompressible, est progressivement remplacé par une organisation en « feature team », ou « 2 Pizzas team », et par les méthodes agiles. L’équipe est réduite, mais elle est responsabilisée sur toute la chaîne jusqu’à la mise en production, elle travaille par lots de développement moins importants et porteurs de moins de risques, avec des livraisons plus fréquentes.
Cette organisation a pour objectif de pouvoir sortir plus rapidement de nouvelles fonctionnalités sans atteindre le train d’une version majeure tous les 6 mois. C’est une évolution considérable des métiers de développement, développeurs, manageurs et testeurs. Mais cela les conduit aussi à s’intéresser à la fin de la chaîne au déploiement et à la mise en production.
De leur côté, les équipes « Ops » d’infrastructures doivent s’intégrer à cette nouvelle chaîne DevOps et se rapprocher des Dev. On leur demande de davantage automatiser les déploiements, et de mieux comprendre l’architecture logiciel et de travailler davantage à l’optimisation du fonctionnement de l’applicatif. Le métier n’est plus de peaufiner à la main une configuration serveur, un cluster de base de données, ou une baie de stockage, mais d’automatiser la mise à disposition d’un environnement et de participer à l’optimisation de la performance applicative. Bien sûr, il ne faut rien lâcher sur la disponibilité et le contrôle, mais ce ne sont plus les seuls objectifs. Les Ops doivent s’intégrer à la chaîne Devops pour fluidifier les livraisons.
Dans l’état actuel du marché, cette transformation s’est engagée dans l’ensemble plus rapidement chez les Dev que chez les Ops. Les technologies web ont accéléré l’arrivée massives de nouvelles générations de développeurs qui n’auront jamais connu le cycle en V. Il est frappant de constater l’écrasante majorité des profils développement dans les promotions d’écoles d’informatiques. Bien sûr, de nombreux développeurs plus seniors devront gérer la transition, mais le flux de jeunes formés aux nouvelles méthodes est tel que la transformation peut aller vite. Dans les structures où les recrutements auront été rares, inversement, l’évolution sera peut-être moins naturelle.
Pour les Ops, les choses vont moins vite. Logiquement la pression des nouvelles fonctionnalités a d’abord touché les Dev. Ensuite, on a tellement demandé aux Ops de sécuriser la production, de verrouiller leurs processus, que l’adaptation au mode agile et DevOps est presque contre-nature. Encore en plein déploiement d’Itil, ils sont pris à contrepied par des exigences qui paraissent contradictoires. Par ailleurs, les profils Ops sont devenus très rares dans les promotions informatiques et donc le renouvellement est beaucoup plus lent, sans compter que de nombreux cursus n’ont même pas encore intégré les nouvelles approches dans les formations. On peut en 2017 sortir d’une école d’informatique sans avoir pratiqué un cloud public, encore moins une plateforme PaaS pour développeur, ou automatisé une configuration et un déploiement !
Dans ces conditions, on voit que la conduite du changement est indispensable, et l’accompagnement par un prestataire externe spécialisé peut être un accélérateur.
Le cloud public
Troisième facteur d’évolution , le cloud public arrive comme une déferlante depuis 2015-2016. L’arrivée à maturité de Azure et la multiplication des services applicatifs prêts à l’emploi chez AWS ou Google, conduisent à une explosion du marché. L’étape des « early adopters » est dépassée, toutes les entreprises sont amenées à engager un projet de cloud public. Les motivations sont innombrables: renouvellement des infras, besoin de scalabilité à la hausse ou à la baisse, rachat d’une entreprise avec dans ses bagages une application développée sur le cloud, déploiement à l’international, accélération des développements web et besoin d’agilité…
Il est difficile de résister à la facilité de déploiement et la scalabilité du cloud public. La richesse des plateformes proposées (services managés de base de données , plateforme IoT, big data, intelligence artificiel) est aussi un accélérateur de développement fantastique et attire de manière irrésistible les développeurs. En plus la sécurité n’est plus techniquement une objection, car on trouve sur le cloud tous les outils nécessaires. Enfin, le cloud public est un accélérateur pour les projets, par sa flexibilité, il permet de s’engager avec une feuille de route encore fluctuante, il permet de corriger le tir en cours de route et d’expérimenter.
Prendre la décision de rester à côté du cloud public peut encore paraître prudent aujourd’hui, ce sera injustifiable dans 2/3 ans. Au minimum, il faut l’évaluer pour rester en prise avec le marché. Là encore, la gestion des compétences est compliquée. Les Dev y vont volontiers mais sans culture Ops, elles mesurent assez rapidement leurs limites. Les Ops engagés sur le Cloud public sont encore très rares, et c’est un vrai changement de culture, de concepts et de vocabulaire.
Engager la transformation DevOps de la DSI
Evidemment la conclusion est qu’il faut s’y engager sans attendre, mais aussi sans appréhension. Le chantier est le même pour tout le monde, et rares sont ceux qui ont vraiment de l’avance.
Il y a de multiples manières d’y aller mais une démarche graduelle est le moyen le plus sûr d’engager la transformation sans attendre et sans mettre en péril l’organisation. De premiers projets pilotes , avec une équipe dédiée pluridisciplinaire, doivent permettre de former une partie des équipes, et par effet tache d’huile d’étendre graduellement le périmètre tout en accélérant la cadence au fur et à mesure que l’on a gagné en confiance et en maîtrise. Rapidement, les 1ers succès facilitent l’adhésion des réticents.
L’accompagnement par un prestataire peut être un accélérateur et un catalyseur: cela permet de franchir les obstacles plus vite, qu’ils soient techniques, sécurité ou méthodes. Cela permet aussi d’assurer un transfert plus rapide de compétences. Le plan de recrutement est également important pour faire rentrer de nouveaux profils rapidement compétents sur ces nouveaux environnements.
Se contenter de d’envisager le passage sur le cloud public comme une migration technique avec un plan de formation , c’est prendre le risque de ne faire que la moitié du chemin. Les gagnants seront bien les entreprises qui sauront gérer cette évolution comme un projet global de transformation de la DSI en sachant mobiliser leurs équipes.
A lire également le retour d’expérience de voyage-sncf qui est passé en 4 ans de 3 release/an à 230 mises en production sur plusieurs milliers de points fonctionnels : cliquer ici.
