De nos jours, les équipes informatiques n’ont pas le rôle le plus facile dans les grandes entreprises. Les DSI essaient de rivaliser avec la réactivité et la capacité d’innovation des start-ups pour les nouveaux projets, et s’efforcent de moderniser les applications vers “le(s) cloud(s)”, tout en travaillant à l’échelle inhérente à une grande entreprise. De nombreuses entreprises se tournent vers l’approche DevOps en espérant réduire les délais de livraison en intégrant des ingénieurs d’exploitation dans leurs équipes de développement produit - type “you build it, you run it” (celui qui conçoit est aussi celui qui déploie).

Mais à l’échelle d’une grande entreprise, cette approche simpliste de modèle DevOps est souvent vécue comme un problème. Les grandes entreprises ont besoin de niveaux de stabilité et de sécurité qui ne constituent pas forcément des impératifs immédiats pour les start-ups. Elles doivent aussi maintenir un juste équilibre entre rapidité et sécurité, généralement dans un environnement aux budgets contraints et pas souvent révisables à loisir. Bien que le modèle d’immersion des Ops vers les Dev soit un bon point de départ pour gagner en agilité et améliorer le flux de fonctionnalités ou l’empathie des équipes, l’adoption d’un outillage et d’une plateforme applicative et l’évolution vers des pratiques d’ingénierie orienté fiabilité (SRE) représente bien souvent une meilleure approche pour les grandes entreprises modernes.

Modèle DevOps : une solution aux silos... mais de courte durée

Pour bien comprendre où nous en sommes aujourd’hui, il est important de se rappeler d’où nous venons. Entre la fin des années 90 et le début des années 2000, les DSI ont mis en place des structures organisationnelles avec des pratiques de livraison cloisonnées (développement, analyse, contrôle qualité, opérations, etc.). Le but était d’exercer un contrôle sur la livraison des applications et de réaliser des économies.

Dans la pratique, cette démarche a souvent eu l’effet inverse. Les équipes se sont naturellement concentrées sur l’optimisation de leurs silos respectifs et ont collectivement perdu de vue le véritable objectif : optimiser l’ensemble du processus de livraison des applications et du flux de fonctionnalités. Les équipes informatiques ont commencé à concevoir de nombreuses applications sur mesure, avec pour conséquences une augmentation des coûts et des problèmes de sécurité. C’est ce qui a poussé les dirigeants à adopter le modèle DevOps, dont les principes, en théorie, semblaient être la solution miracle au problème des silos. L’idée était qu’en fusionnant les équipes de développement et d’exploitation pour gérer le cycle de livraison des logiciels, celles-ci contrôleraient l’ensemble du processus, et assureraient une livraison plus rapide et sécurisée.

Les failles du modèle

Rabobank, une grande entreprise de services financiers qui a fait la preuve de son avance en matière de nouvelles technologies, est ainsi partie du principe que l’affectation de personnel d’exploitation à chaque équipe produit lui conférerait suffisamment de contrôle sur le processus pour accélérer les changements et la livraison. Elle a donc mis en place des équipes produit autonomes comprenant chacune des ingénieurs d’exploitation. Tant qu’une seule équipe était en charge du développement de la plate-forme et de la pile technologique, tout se passait bien étant donné le nombre minime de dépendances. Mais d’autres équipes se sont constituées et sont devenues interdépendantes. Chacune poursuivait des objectifs différents, avec des livrables différents pour des clients finaux différents, si bien que leurs pratiques et outils ont divergé.

En fait, le principe « You build it, you run it » a fonctionné pour une dizaine de personnes résidant au même endroit. À mesure qu’elles se sont étoffées ou décentralisées, les équipes ont commencé à faire cavalier seul et à ignorer les problèmes de leurs homologues. Le point de rupture survenait généralement lorsque plus de dix personnes dépendaient de la même infrastructure d’exploitation.

Les portails Web interne et externe de l’entreprise sont un bon exemple de ce point de rupture. L’entreprise avait décidé de les fusionner, estimant à juste titre qu’il était inutile d’exécuter deux sites différents pour présenter en partie les mêmes données. Le problème est qu’elle n’a pas fusionné les équipes. Résultat : l’équipe responsable du portail interne n’employait pas les mêmes stratégies de sécurité, de tests d’intrusion et de conformité que l’équipe externe. L’équipe du portail interne a perdu en rapidité en héritant d’un patrimoine construit différemment. Pire encore, des frictions sur des questions telles que le choix des outils, le calendrier des déploiements et la duplication des micro-services ont engendré des frustrations tant sur le plan métier que technique. C’est seulement après que l’entreprise ait entamé un processus de 3 à 4 mois visant à éliminer certaines inefficacités et à accélérer les cycles de déploiement que le chantier a porté ses fruits. Résultat : le nombre de personnes nécessaires à l’exploitation de la plate-forme est passé de 30 à 10 et la productivité des développeurs est passée de 30 à 75 %.

Tous les modèles DevOps ne sont pas une solution miracle

Il était clair que les pratiques initiales de livraison d’applications, c’est-à-dire pré-DevOps, de cette société devaient changer mais pas à travers n’importe quel modèle de DevOps. La leçon à retenir est qu’en matière de DevOps, il n’existe pas de solution universelle. L’expérience de cette entreprise reflète probablement celle de nombreuses organisations modernes. Sur un marché de plus en plus concurrentiel où l’innovation s’accélère, les modèles DevOps classiques ou tirées de la littérature ne sont pas toujours adaptés à la culture et aux pratiques propres aux entreprises et leur patrimoine et histoire - quelque soit les secteurs tels que la finance, le commerce de détail, la santé ou le secteur public.

Il est important de faire preuve de flexibilité et d’identifier constamment et régulièrement toute pratique étroitement codifiée et dogmatique susceptible de se révéler préjudiciable. La flexibilité des outils modernes faisant émerger une API entre Dev et Ops - par le biais d’outil de plate-forme applicative et container peut jouer un rôle clé. Il faut aussi appliquer des modèles tels que l’ingénierie de plate-forme en tant que produit et s’attacher à l’approche orientée fiabilité (SRE - site reliability engineering) pour équilibrer les activités DevOps d’une part entre innovation et déploiement et d’autre part entre réduction des taux d’erreur ou augmentation de la résilience et observabilité. C’est dans la combinaison de ces approches que des solutions peuvent être trouvées pour de nombreuses organisations et que leur modèle DevOps pourra passer à l’échelle sans accumuler de la dette technique dans des nouveaux silos “you build it, you run it”.