By Yann Albou.
Le DevOps est bien plus qu’une simple tendance technologique. C’est une approche qui révolutionne la façon dont les équipes IT collaborent, innovent et répondent aux besoins de l’entreprise. Mais est-ce vraiment la solution miracle pour toutes les entreprises ? Dans cet article, nous explorons les principes fondamentaux du DevOps, ses avantages, mais aussi ses limites et les raisons pour lesquelles certaines implémentations échouent.
J’espère que cette article vous permettra d’appréhender les enjeux du DevOps, et de vous aider à prendre des décisions éclairées pour votre propre contexte.
Le mouvement DevOps ou DevSecOps a émergé à la fin des années 2000 comme une réponse aux défis posés par la collaboration entre les équipes de développement (Dev) et d’opérations (Ops) dans le domaine de l’informatique et des logiciels.
Il existe beaucoup de définition du devops mais pour simplifier on peut dire que le DevOps ou DevSecOps est une approche culturelle, organisationnelle et technologique qui vise à améliorer la collaboration, la communication et l’efficacité entre les équipes de développement, de sécurité et d’opérations (et d’autres équipes). L’objectif principal est de réduire le « time to market » (temps de mise sur le marché) des produits logiciels, d’améliorer la qualité des produits logiciels et de répondre plus rapidement aux besoins des utilisateurs.
On y retrouve clairement de forts liens avec l’agilité et en particulier une réponse aux problèmes des modèles de développement en cascade (Waterfall).
De manière non exhaustif, plusieurs livres ont marqué l’histoire du DevOps :
On pourrait ajouter beaucoup d’autres livres et en particulier toute la litérature Agile et Lean.
Les pratiques du DevOps sont soutenues par des outils et des technologies spécifiques. Voici quelques-unes des principales approches technologiques liées au DevOps :
Cette liste n’est pas du tout exhaustive mais représente bien le paysage Cloud Native lié aux approches DevOps.
Il existe beaucoup d’outils/produits autour de ces sujets: voir le landscape de la CNCF 😱
Pour rappel, la Cloud Native Computing Foundation (CNCF) est une organisation qui soutient et promeut les technologies open source pour le cloud computing et les conteneurs. Elle a été fondée en 2015 par plusieurs entreprises technologiques de premier plan, dont Google, Red Hat et VMware. La CNCF est devenue l’une des organisations les plus influentes dans le domaine du cloud computing et des conteneurs, avec plus de 200 projets open source sous son égide dont Kubernetes.
Cet écosystème est très riche et n’est même pas exhaustif.
A noter que Sokube est membre « silver », KCSP (Kubernetes Certified Service Provider) et KTP (Kubernetes Training Partner) de la CNCF.
Il faut voir ces outils comme des briques qui permettent de construire des solutions adaptées aux besoins des équipes et de l’entreprise et pensés pour répondre aux modes de fonctionnement du DevOps: Automatisation, Sécurité, Everything-as-code, Simplification du partage entre les différents départements, …
Je ne rentrerai pas davantage en détail sur ces aspects technologiques.
Pas du tout !
Commençons par clarifier un point : Kubernetes n’est pas la solution à tous vos problèmes. Il existe de nombreux cas où Kubernetes n’est tout simplement pas recommandé en raison de sa complexité, de son coût, du fait qu’il est plus adapté à des environnements de taille moyenne ou large, … Par exemple et pour certains besoins, des alternatives comme les solutions CaaS (Container as a Service) peuvent être plus appropriées.
Kubernetes est avant tout un facilitateur pour les pratiques DevOps. Cependant, si vous l’utilisez avec des applications mal adaptées ou que vous reproduisez des approches « legacy » (en termes de livraison, sécurité, observabilité, etc.), il y a de fortes chances que votre projet rencontre des difficultés, voire échoue.
« Je fais du container, du kubernetes, alors je suis DevOps »
Je constate fréquemment que certaines entreprises pensent faire du DevOps simplement parce qu’elles utilisent des outils comme les conteneurs ou Kubernetes. Cette approche est erronée : adopter des outils ne suffit pas à transformer vos pratiques DevOps.
Le DevOps promet une véritable transformation : livrer plus rapidement, avec une meilleure qualité, tout en renforçant la sécurité et en apportant une valeur business accrue. Cela se résume souvent par le mantra “Faster, Better, Stronger”.
Cependant, malgré toutes ces promesses de rapidité, de qualité et de sécurité, la mise en œuvre du DevOps n’est pas toujours un succès. Cela nous amène à poser une question cruciale : Le DevOps, un échec ?
J’ai accompagné de nombreuses entreprises dans leur démarche de mise en place du DevOps. Cependant, il arrive que l’on constate des échecs dans l’implémentation d’un modèle DevOps véritablement opérationnel. Alors, pourquoi ces « transformations » échouent-elles parfois ? Quels sont les défis sous-jacents à ces échecs ?
D’abord, parlons de transformation. Ce terme, bien que souvent employé, est chargé de sens et peut sembler intimidant. Il rappelle des décennies de méthodes de travail qui ne sont plus adaptées aux besoins et contextes actuels.
Nous sommes souvent habitués à fonctionner dans un mode de gestion de projet en Waterfall. Ce modèle, hérité de l’industrie manufacturière, fonctionne par étapes linéaires et rigides : chaque phase doit être terminée avant de passer à la suivante. Si cela a longtemps bien servi des secteurs où les processus sont prévisibles et figés, dans le monde des logiciels et des services numériques d’aujourd’hui, cette approche devient problématique.
Pourquoi ? Parce que le monde numérique est fondamentalement incertain et évolutif. Les besoins des utilisateurs changent constamment, et la concurrence impose une réactivité accrue. Le modèle Waterfall ne permet pas d’adapter les projets en cours de route, rendant la livraison lente et souvent déconnectée des attentes réelles. En conséquence, les projets prennent du retard, et les équipes se retrouvent avec des produits obsolètes avant même qu’ils ne soient finalisés.
La véritable agilité ne se limite pas à casser le modèle Waterfall en réduissant le nombre de sprints : elle commence en se concentrant sur la création de valeur pour le client, en recueillant ses retours et en résolvant ses problèmes, plutôt que de simplement livrer plus vite.
Bien qu’il existe des cas où le modèle Waterfall peut être approprié (projets aux exigences très stables et figées, environnements fortement réglementés, etc.), l’agilité reste généralement préférable pour s’adapter en continu aux changements et maximiser la création de valeur pour les utilisateurs finaux.
Ainsi, il est essentiel d’abandonner ces pratiques au profit de méthodes plus agiles et itératives, qui favorisent l’adaptation continue et la collaboration entre les équipes en se focalisant sur le besoin client.
L’adoption DevOps représente une promesse de « transformation » profonde pour les directions des systèmes d’information (DSI). Cependant, l’un des principaux obstacles auxquels ces DSI sont confrontées est la lourdeur organisationnelle. Dans ces situations, les processus décisionnels longs et complexes constituent souvent un frein majeur, et s’accompagnent de silos fonctionnels qui empêchent la collaboration et l’agilité nécessaires à la mise en œuvre efficace des approches DevOps et Agile.
Les entreprises d’aujourd’hui sont des environnements en perpétuelle évolution, avec des besoins qui changent rapidement. Pour rester compétitives, elles doivent se transformer en organisations “anti-fragiles” : des structures non seulement capables de résister aux changements constants, mais aussi d’en tirer parti pour se renforcer.
La norme est désormais le changement, et les équipes IT doivent s’adapter à cette réalité en devenant plus agiles, flexibles et résilientes.
Le concepte « Antifragile » a été popularisé par Nassim Nicholas Taleb dans son livre du même nom. Il décrit un système capable de s’adapter et de se renforcer face au changement, plutôt que de se briser ou de rester statique.
De plus, tout s’accélère ! Le changement se produit désormais à un rythme bien plus rapide qu’auparavant. La pandémie du Covid nous a fait prendre conscience que nous devons être capables de réagir toujours plus vite.
L’arrivée de l’intelligence artificielle va encore amplifier cette dynamique. Qu’on le veuille ou non, l’impact de l’IA sur nos métiers sera profondément disruptif. Nos systèmes IT devront s’adapter à ce rythme effréné et aussi devenir “antifragiles” !
Mais l’IT peut aussi être un élément clé différenciateur !
“Every Company is Now a Software Company”
Satya Nadella (PDG de Microsoft)
Cette citation souligne un point essentiel : dans l’économie numérique d’aujourd’hui, la technologie et les systèmes d’information ne sont plus des fonctions de support. L’IT devient un différenciateur clé capable d’apporter une valeur ajoutée directe au business. Que ce soit pour optimiser les opérations, améliorer l’expérience client ou favoriser l’innovation, une IT agile et réactive peut transformer une entreprise en leader de son marché.
Un exemple concret est celui d’Amazon, qui a su faire de son infrastructure IT un levier stratégique. Grâce à des pratiques DevOps et agiles bien établies, Amazon est capable de déployer des milliers de microservices en continu, permettant une innovation rapide et une adaptation constante aux demandes du marché.
Mais on pourrait citer des entreprises plus petites qui ont réussi à se transformer en adoptant des pratiques DevOps:
Comme nous l’avons vu, l’IT joue aujourd’hui un rôle central dans la compétitivité des entreprises, quelles que soient leur taille ou leur secteur. Toutefois, nous ne sommes pas tous des géants comme Netflix, Amazon ou Google, avec des ressources humaines et financières massives. Alors, est-il pertinent pour des structures plus modestes d’adopter ces approches ?
La réponse est oui, mais pas de la même manière. Même pour une start-up, les pratiques DevOps apportent une réelle plus-value. Il ne s’agit pas de viser une automatisation complète ou un modèle de continuous deployment dès le début, mais de comprendre les principes clés pour bâtir une IT intelligente, évolutive et adaptée à vos besoins. Il est important de progresser étape par étape, en fonction de la maturité de votre organisation et de votre contexte spécifique.
Exemple d’une matrice de maturité Cloud Native:
En effet, en adoptant progressivement ces pratiques, vous préparez votre IT à évoluer avec votre business. Votre entreprise grandira, que ce soit par vos ambitions, les opportunités ou des contraintes externes, et le DevOps vous permettra d’accompagner cette évolution en apportant de la valeur à chaque étape, sans vous précipiter dans des transformations trop brusques.
Commencer par la technique ne suffit pas. Le véritable objectif est de répondre aux besoins business grâce à la technologie, et non de la mettre en œuvre pour elle-même. Bien entendu, des chantiers techniques peuvent être lancés en parallèle, mais il est crucial de se concentrer sur la valeur ajoutée pour l’entreprise.
Et de la même manière, il est important de vous entourer d’experts en pratiques agiles et technologies liées au DevOps. Ces spécialistes jouent un rôle clé dans la diffusion des bonnes pratiques et l’accompagnement de vos équipes afin d’éviter les pièges courants et à accélérer la montée en compétences, tout en maximisant la valeur de vos initiatives.
Dans un monde où tout s’accélère, l’écart entre les “low performers” et les “high performers” se creuse. Pour réduire cet écart, voici quelques points de départ :
Dans cette démarche d’amélioration continue, Mesurer dès le départ est essentiel.
Voici quelques indicateurs DevOps incontournables (issus de l’étude DORA) :
Ces indicateurs ne sont pas suffisants, il est également nécessaire d’avoir des indicateurs au niveau de la plateforme :
Enfin, je souhaite aussi mensionner les pratiques du « The Lean Tech Manifesto » de Fabrice Bernhard et Benoît Charles-Lavauzelle qui mettent en avant certains principes :
Tout cela n’est pas exhaustif, mais sont des éléments déterminants sur lesquels il faut s’appuyer en y mettant votre ADN !
On nous pose souvent la question : “Combien coûte une transformation DevOps ?” Evidemment si nous parlons de « transformation numérique » cela implique généralement un investissement conséquent. Ce qui sera mal perçu par le business, notamment en raison des dettes techniques et organisationnelles accumulées au fil des années.
Il est donc crucial de démarrer de manière ciblée, en se concentrant sur des cas d’utilisation précis. Comme pour un développement logiciel, on peut commencer avec un MVP (Minimum Viable Product) et itérer progressivement, afin de générer du feedback sur un ensemble réduit de fonctionnalités.
Cependant, il est important de maintenir une plateforme “lean”, souvent appelée TVP (Thinnest Viable Platform), pour garantir que la solution reste minimaliste et facile à maintenir sur le long terme.
Cela dit, il ne faut pas se leurrer : toute transformation représente un coût supplémentaire, notamment parce qu’il faut gérer l’existant tout en montant en compétence et en absorbant les nouvelles approches technologiques et organisationnelles. L’essentiel est de maîtriser ce coût par itérations successives, toujours au service d’un objectif clair.
Si ce domaine est nouveau pour vous, nous vous recommandons de vous former en démarrant par notre formation DevSecOps overview d’une journée vous permettant de vous familiariser avec les concepts et les bonnes pratiques.
Il n’existe pas de solution universelle : ce qui fonctionne pour une entreprise ne peut pas être reproduit de manière identique chez vous, car chaque organisation a ses particularités. C’est justement ce qui rend cette aventure passionnante ! Il y a cependant des principes et concepts fondamentaux qu’il est essentiel de s’approprier, puis d’adapter selon la structure, la taille, le contexte et les objectifs de votre entreprise.
L’intelligence artificielle va véritablement bouleverser l’adoption de ces approches et des technologies qui continuent d’évoluer. Les entreprises qui resteront ancrées dans un mode legacy risquent de se retrouver rapidement dépassées.
Ce qui me fascine avec le DevOps, c’est que ses principes transcendent les technologies : l’amélioration continue ne s’applique pas seulement aux projets, mais aussi au DevOps lui-même !