DEV Community: nicolasT

Les européens ont-ils vraiment perdu la guerre du cloud ?

nicolasT — Mon, 22 Dec 2025 08:00:00 +0000

Le contexte géopolitique récent a relancé une question qui s'est posée à partir de 2013 : est-ce que les européens ont perdu la guerre du cloud ?
Autrement dit, peut-on se passer des hyperscalers américains pour travailler dans le cloud public ?

Nous sommes en 2025, qu'en est-il ?

TL;DR
Oui, ils ont perdus de nombreuses batailles... mais peut-être pas la guerre. La rebellion se réorganise.
L’IA est l’occasion de relancer une dynamique en Europe.
La solution pour les offres IaaS, PaaS, SaaS pourrait passer par une fédération des acteurs.

La naissance d’un empire

Quand on évoque le "cloud public", bon nombre, pour ne pas dire tous, pensent immédiatement aux trois mastodontes américains. La raison ? La puissance marketing de ces derniers. Il faut reconnaitre que sur cet aspect, les américains semblent avoir une culture marketing que les européens n’arrivent pas à rattraper. Ajoutez à cela l’admiration toujours présente de la Silicon Valley qui place ces acteurs comme les fers de lance de l’IT.

De leur côté, les européens paraissent avoir eu besoin de digérer cette nouvelle notion. Le cloud public n'est qu'une forme de maturité et une évolution du métier de l'hébergement Internet. Pourtant, ce terme marketing est vite devenu un élément différenciant pour les acteurs nord-américains. Les hébergeurs européens n’ont peut-être par perçu ce terme comme étant vecteur d’une évolution de leur métier.

Par ailleurs, le marché, bien qu’admiratif, ne s’est pas rué sur ces nouvelles offres. Dans les premières années, les DSI avaient du mal à se projeter dans ce nouveau paradigme : quel coût à la fin du mois, de l’année ? Comment maitriser mon infra ? L’IaC (infrastructure as code) et l’éducation ont répondu à ces questions, à grand renfort de meet-ups sponsorisés et/ou présentant des démonstrations s’appuyant sur AWS.

La seconde défaite européenne vient de la technologie. Là où les européens étaient très présents et sur un marché dynamique de l’hébergement Internet, les clouds sont arrivés avec une réponse technologique innovante : des API et des outils pour automatiser la gestion des infrastructures dynamiques. Dans le même temps, Heroku, encore un acteur américain, propose une solution allégée pour déployer les applications : un PaaS.

Certains acteurs européens ont tenté de suivre, voir rattraper les solutions : les initiatives ratées Cloudwatt et Numergy de l’État français ; la tentative de résistance du cloud gaulois ;
platform.sh, PCextreme B.V. (racheté par versio), Digital Ocean, etc. Toutes ces initiatives n’ont pas réussi à faire de l’ombre à l’hégémonie naissante du futur trio omniprésent du cloud public, bien que proposant des solutions cohérentes, tant au niveau technique que financier.

Le dernier rapport sur les parts de marché des fournisseurs de cloud du Synergy Research Group fait état de 63% occupées par le trio AWS, GCP et Azure. Derrière cette domination se trouvent d’autres acteurs, dont de grands noms de la tech américaine, ainsi que le fournisseur chinois Alibaba.

source https://www.srgresearch.com/articles/cloud-market-share-trends-big-three-together-hold-63-while-oracle-and-the-neoclouds-inch-higher

Derrière le terme "neoclouds" se trouvent de nouveaux acteurs : CoreWeave, Crusoe, Nebius et Lambda.

La menace fantôme

Technologiquement, les acteurs de l'hébergement français paraissent avoir raté le virage du cloud. OVHcloud, acteur incontournable en France et en Europe, propose peu de services concurrents à AWS, GCP et Azure. Ceux proposés sont arrivés tardivement et ne semblent pas leur permettre d'être vus comme alternative.

Pourtant, dès 2011, des acteurs de l'hébergement Internet se lancent dans la fourniture de services de cloud moderne. Ikoula propose des VMs avec une facturation à l'usage. Modèle clé des acteurs du cloud moderne, par lequel ils ont secoué le marché. Ikoula récidive en 2013 avec une offre plus complète basée sur CloudStack. À l'époque, Gandi lance une offre de VPS concurrente. OVH, quant à lui, tarde à lancer son offre basée sur OpenStack. Digital Ocean émerge, avec une stratégie marketing agressive pour séduire les développeurs. Platform.sh se propose comme alternative à Heroku. PCextreme se crée aux Pays-Bas en s’appuyant également sur CloudStack. Scality, qui se concentre sur le stockage objet, voit le jour en 2009, et lance un appel à une fédération d’acteurs, pour proposer rapidement une offre multizone.
Il y a certainement d’autres initiatives à mentionner. Cependant, aucune n’arrive à se frayer un chemin face à ce qui se trame outre Atlantique. Amazon fait cavalier seul, ou presque. Malgré un départ en deux temps, Google et Microsoft réussissent à combler leur retard.

Après s'être laissé dépasser / déborder par les américains, les européens se concentrent visiblement sur le marché public, sécuritaire et la régulation.

Un nouvel espoir

Le cloud souverain. Terme très utilisé parmi les régulateurs et autres personnalités politiques et représentants d’entreprises publiques. Le terme n’est pas nouveau, cependant, en France la première initiative (Cloudwatt et Numergy) fut un échec. Pardon, je devrais dire qu’elle n’a pas marché.
Fort de cette expérience, cette fois les acteurs existants du marché de l’hébergement Internet sont contactés, comme OVH ou Online (ancien nom de Scaleway). Concrètement, peu de choses en sort, mis à part des initiatives orientées réglementation :

Gaia-X. L’idée première de cette initiative : fournir un standard pour favoriser l’émergence d’infrastructures fédérées.
European Union Cybersecurity Certification Scheme for Cloud Services. Projet de loi définissant les exigences en matière de cybersécurité entre les différents membres de l'UE.
SecNumCloud. Qualification de sécurité délivrée par l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information).

Comme toute rébellion, les choses ne se passent pas aussi facilement que prévu. Il ne faut pas attendre longtemps avant de voir Microsoft, Google ou Amazon entrer dans les discussions autour de Gaia-X. Ce projet est un tel succès que nombreux sont ceux à en avoir oublié son existence. Eurostack est lancée pour tenter d’apporter une réponse plus concrète.

Les normes EUCS et SecNumCloud sonnent la seconde vague de cette rébellion. Deux normes pour une même raison, l’une européenne, l’autre française. Bien entendu, la norme française est la plus contraignante. Encore une fois, les solutions d’envergures sont apportées via un modèle législatif.

Est-ce suffisant pour faire basculer des parts de marché vers des acteurs européens ? Dans le cadre de solutions avec de fortes contraintes de sécurité et de gouvernance, certainement. Bien que, par leur nature, ces contraintes orientent d’elles-mêmes vers une offre dite souveraine. Encore que… la décision par dépit de la CNIL concernant le Health Data Hub montre que ce n’est pas si simple.

L’empire contre-attaque

Oui, le marché européen du cloud public semble se contracter vers des offres de niche avec des contraintes fortes de souveraineté. En France, des partenariats "souverains" avec les opérateurs américains sont créés : Bleu pour Capgemini / Orange avec Microsoft Azure ; S3NS pour Thales avec Google Cloud.

Tandis que le lobbying a fait son œuvre dans les commissions, la réponse technologique passerait par un aveu d’échec : nous avons trop de retard, alors créons une offre qui permettrait de fusionner les produits américains avec les contraintes légales françaises. Dans les deux partenariats, la promesse est que les données sont toutes hébergées en France, dans des datacenters opérés par des entreprises française. Pour ajouter une couche de confiance, les données sont chiffrées par des clés inaccessibles aux entreprises américaines parentes des solutions technologiques.

Sur le papier, ça ressemble à un accord avec le meilleur des deux mondes. Oui, mais... un rapport juridique à destination du Ministère fédéral de l’Intérieur allemand vient quelque peu confirmer mes doutes. Ces offres ne protègent pas vraiment des lois extraterritoriales américaines.

Le retour du Jedi (ou du jet AI)

Les pannes récentes chez AWS, Google, Azure et CloudFlare démontrent une forte dépendance mondiale envers ces acteurs. Certains ont eu une prise de conscience de cette dépendance et regardent les alternatives. Ces alternatives existent et ne manquent pas. Par contre, elles sont souvent méconnues ou ne couvrent pas tout le périmètre technique que peuvent proposer le trio dominant.

Mon analogie avec la trilogie Star Wars s’arrête, car nous n’avons pas un Jedi européen pour aider la rébellion à gagner cette guerre. Est-ce sans espoir pour autant ? Peut-être pas.

Ma vision des choses et qu’il faut continuer de faire confiance aux acteurs européens. L’Europe ne possède pas (encore ?) d’hyperscaler pouvant proposer toute la panoplie de services que l’on trouve chez AWS, GCP ou Azure. Pourtant, rien qu’en France il existe des offres cohérentes. OVH cloud et Scaleway, par exemple, progressent fortement sur cet aspect. Leurs API permettent un usage dans la logique IaC. NumSpot se présente comme un nouveau challenger intéressant et ambitieux. Outscale possède également un catalogue intéressant, bien que plus restreint. Mais est-ce bien important ? Qui a besoin de l’ensemble de ces solutions ?

Il faut peut-être repenser l’adoption du cloud en se rapprochant de l’usage dont on a besoin. Une autre vision serait d’opter pour une stratégie cloud hybride ou multi-clouds.

Les entreprises du continent asiatiques semblent plutôt se tourner vers leurs champions : Alibaba, Tencent, Huawei, etc. Leur socle technologique ? Des solutions open source, qui sont également utilisées chez les acteurs cités précédemments.

Par ailleurs, l’IA est venue mélanger les cartes. Même si le marché est encore une fois dominé par des entreprises américaines, les européens ne sont pas en reste, notamment avec le français Mistral AI.

Et si

Et si la solution européenne pour les offres IaaS, PaaS, SaaS passait par une fédération des acteurs ?
Nous sommes en 2025 et l’IaC est devenu un standard dans la gestion des infrastructures. AWS, GCP et Azure proposent des API pour administrer leurs produits. Les solutions européennes aussi. Dans une stratégie multi-clouds il ne serait pas si complexe de répartir sur infrastructure sur les différents fournisseurs. Bien entendu, cela peut poser des défis au niveau de la connectivité et des performances. Nul doute que les architectes chevronnés sauront trouver les réponses !
Restera le point contractuel et financier. À ce niveau, il faut peut-être regarder du côté des réflexions FinOps, certains outils permettent d’avoir une vision multi-clouds.

Cette stratégie ne va peut-être pas vous convaincre. Alors à grand minima, nous avons besoin d’une cartographie des services clouds, à la manière du landscape de la CNCF. Mais ce sera sûrement le sujet d’un autre billet, plus court, je vous rassure ;)

Les acronOps et leurs amis

nicolasT — Mon, 16 Dec 2024 14:28:30 +0000

Les acronOps se sont infiltrés dans notre quotidien depuis quelques années. Vous en connaissez sûrement. Il y en a même parmi vous !

Qui sont-ils ? Que veulent-ils ? À quoi servent-ils ? Peut-on les apprivoiser ?

1. DevOps
       1.1. DevOps : les 3 voies
             1.1.1. Vision globale du flux / système
             1.1.2. Amplifier les boucles de retour d’information
             1.1.3. Culture de l’expérimentation et de l’apprentissage
       1.2. Dev(x)Ops
2. (x)Ops
       2.1. NoOps
       2.2. NetOps / NetOps 2.0 / DevNetOps
       2.3. SecOps
             2.3.1. NetSecOps
       2.4. ChatOps
       2.5. DataOps / MLOps / AIOps
       2.6. GitOps
       2.7. FinOps / GreenOps
3. Leurs amis
       3.1. Site Reliability Engineering
       3.2. Platform Engineering
4. Conclusion

Commençons par découvrir ce qui se cache derrière ce mot.

acronOp nom masculin
: mot valise faisant la contraction du mot "acronyme" avec le terme "ops".

Tout débute avec un Ops. Comprenez un opérateur, autrement dit : gestionnaire de production ; membre du support technique. Son rôle est simple, il déploie les applications, les maintient en condition opérationnelle, surveille que tout se passe bien, résout les incidents, assure la communication aux clients et à la direction. On parle des équipes qui coûtent de l’argent à l'organisation, surtout s'il y a des astreintes ou du 24/7, mais ne produisent pas de valeur.

De l’autre côté, il y le Dev. Comprenez un développeur, autrement : création d’application, traducteur des besoins clients, fournisseur de fonctionnalités. À travers leurs lignes de code, les équipes de développement produisent de la valeur.

Le problème est que l’Ops n'apprécie pas le changement, alors que le Dev en crée régulièrement. Ces derniers doivent collaborer. Bien souvent, ils ne comprennent pas.
Le Dev se demande fréquemment : pourquoi ne livre-t-on pas plus vite ? Quand pourrais-je commencer à travailler sur l'environnement de dev ? Mon code fonctionne sur mon environnement, pourquoi il ne fonctionne pas en prod ?
Et l’Ops de rétorquer : pourquoi est-ce en panne ? Vous avez encore introduit un bug. Votre plateforme n’est pas ISO prod, c’est normal que ça ne fonctionne pas de la même manière !

Face à ce qui semble être une impasse de communication, s'ensuivit une longue réflexion puis un jour, LA solution !

DevOps

On a mis un Dev et un Ops dans une centrifugeuse, on a mélangé très fort. Tadam ! Le premier acronOp est né : le DevOps. On peut dire qu'il s'agit du Guizmo des acronOps.

Plus concrètement, Patrick Debois, Gene Kim et John Willis ont donné naissance à ce terme en 2007, pour tenter d’apporter une réponse aux silos caricaturés plus haut. Leur but, pousser la coopération au sein de l’organisation. Notamment au niveau des équipes IT.

Dans l’industrie, différentes philosophies ont émergé tel le taylorisme, le toyotisme, l’approche rugby ou le lean. En s’inspirant de ces dernières, ils ont imaginé une organisation dans laquelle les équipes IT réussiraient à travailler ensemble, en réduisant les points de friction.

DevOps : les 3 voies

La philosophie DevOps repose sur 3 principes :

Vision globale du flux / système
Amplifier les boucles de retour d’information
Culture de l’expérimentation et de l’apprentissage

Vision globale du flux / système

Source : IT Revolution

Le premier principe se focalise sur la performance de l’ensemble du système. Un système peut être une organisation entière, une division, une équipe, un individu. Le focus est placé sur le flux de création de valeur qui est réalisé par l’IT. Cela démarre par l’identification des prérequis, passant par le développement, le déploiement et termine quand la valeur est livrée au client sous forme de service.

Les résultats de ce principe sont de :

atteindre une compréhension profonde du système
ne jamais livrer un problème à l'étape suivante
ne jamais autoriser une optimisation qui crée une dégradation globale
toujours chercher à améliorer le flux

DevOps encourage l'automatisation mais ce n'est pas une fin en soi. Le premier pilier a pour but principal l’identification des processus et des points de blocage ou d’engorgement. Automatiser ce qui est possible vient après.

Amplifier les boucles de retour d’information

Source : IT Revolution

Le second principe repose sur la création de boucles de retour d’information de la gauche vers la droite. Il est courant d’entendre l’expression "shift left" pour exprimer le fait d’anticiper certains éléments dans la chaîne de production qui est représentée par un déroulé de gauche à droite. Ici, il est question de raccourcir et amplifier les communications permettant d’apporter continuellement des correctifs.

Le résultat de ce principe est de comprendre et de répondre à tous les clients, internes et externes.

Culture de l’expérimentation et de l’apprentissage

Source : IT Revolution

Le troisième principe veut créer une culture qui encourage l’expérimentation continue et la compréhension de l’intérêt de la répétition et de la pratique pour atteindre la maîtrise. L’expérimentation continue pousse à prendre des risques et apprendre des échecs. Quand la répétition et la pratique sont les fondements pour la maîtrise.

Ces deux éléments permettent de progresser et de réduire les risques quand ils sont rencontrés. Leur allouer du temps régulier est essentiel pour la réussite de cette voie.

Dev(x)Ops

Comme évoqué plus haut, DevOps est le Guizmo des acronOps. Il a suffi de l’asperger un peu pour le voir se multiplier. Parmi les plus courants, nous avons :

DevSecOps : une organisation DevOps qui intègre un focus sur la sécurité
DevGreenOps : une organisation DevOps qui intègre un focus sur la sobriété numérique
DevTestOps : une organisation DevOps qui intègre un focus sur le test Etc.

(x)Ops

Cette multiplication n’a pas suffi à assouvir le besoin d’envahissement des acronOps, tels des Pokémons, d’autres sont apparus au fil du temps. Certains sont des évolutions, d’autres des nouveautés.

La plupart présentent une déclinaison des pratiques issues de la culture DevOps apportés à un élément spécifique de la chaîne de production.

Bien souvent leur nom est explicite et permet de comprendre le sujet principal. Alors que la partie Ops résume la gestion des opérations autour du sujet préfixé. Ces acronOps se présentent comme inspirés par la culture DevOps, ou comme réponse à une organisation non prise en compte par cette dernière. La plupart découlent d’une mécompréhension ou d’un besoin d’apporter une terminologie pour (re)lancer une mode. Les Dev(x)Ops étaient clairs sur le fait d’apporter une accentuation de la culture sur un axe particulier. Les (x)Ops se montrent un peu plus flous et sont même présentés en opposition à leur parent.

NoOps

Celui-là est à la fois le vilain canard de la bande et mon préféré. Présenté par Forrester Research, son but est de supprimer l'Ops. À peine quatre ans après la publication de la culture DevOps, il est temps d’aller au bout de l’idée, l’Ops devient une histoire du passé.

Si les Dev ne veulent pas s'asseoir avec les Ops pour déployer plus efficacement, pourquoi les embêter avec une culture de collaboration. Allons au bout de l’idée : les Ops sont un frein, retirons-les. Comment ? Grâce aux automates, les systèmes de résilience, les clouds et leurs infrastructure-as-a-service ou platform-as-a-service.

Bien que très alléchante pour certains, cette vision ne s’est jamais réalisée. Il faut tout de même reconnaître qu’il y a des pistes de réflexions à creuser derrière cette idée. Comment rendre la vie des utilisateurs la plus simple possible ?

L’auteur, Mike Gualtieri est avant-gardiste. À l’époque, l’IA n’est pas un phénomène de mode omniprésent. ChatGPT, Copilot, Gemini, Claude et Le Chat sont très loin de leur couffin. Depuis leur apparition, certains remettent cette théorie au goût du jour : l’IA finira par remplacer l’Ops et pas seulement lui. Le terme AIOps est venu remplacer le NoOps, en y apportant quelques variations.

L’avenir nous dira ce qu’il en est.

NetOps / NetOps 2.0 / DevNetOps

Un acronOp à trois noms pour désigner une évolution dans la gestion des réseaux. Le but du NetOps est d’apporter les pratiques encouragées par le DevOps à l’administration réseau.

Les réseaux sont des composants d’infrastructures moins dynamiques que les applications. En dehors des structures d’hébergement Internet ou des clouds, les besoins en modification et automatisation sont assez faibles.

La démocratisation des clouds privés et publics a apporté un besoin de flexibilité et de réactivité. Les équipes ont dû s’adapter en s’inspirant notamment des outils et pratiques incitées par le DevOps.

La particularité du NetOps est qu’il est désigné sous trois termes qui recoupent la même idée. La désignation NetOps 2.0 est dérivée du Web 2.0. Tandis que le terme DevNetOps est un Dev(x)Ops qui indique que la gestion du réseau est intégrée dans la logique DevOps.

SecOps

De la même manière que le NetOps, la naissance du SecOps est une application de la culture au domaine de la sécurité. Il n’est pas rare de voir la sécurité évoquée en fin de chaîne de production. On y pense une fois l’application déployée. Ce qui n’est pas sans causer des problèmes, en termes de communication et de technique. Aujourd’hui, la sécurité est très médiatisée. La plupart des acteurs du numérique ont une sensibilité à ce sujet. Ce qui n’était pas le cas il y a quelques années. Le SecOps est donc une réponse à ce besoin de démocratiser et sensibiliser l’ensemble des acteurs à la sécurité.

Par ailleurs, son autre rôle est d’apporter aux équipes en place, une méthode de travail leur permettant de limiter les points de friction. Notamment en intervenant plus tôt.

À l’image du NetOps, le SecOps est un acronOp que l’on retrouve sous la dénomination DevSecOps pour indiquer que la sécurité est intégrée dans la logique DevOps.

NetSecOps

Le NetSecOps peut être considéré comme un mariage du NetOps avec SecOps. Il témoigne d’une volonté de collaboration étroite entre la gestion de réseau et la sécurité.

ChatOps

Le ChatOps est différent des autres acronOps, ici point de méthodologie, nous sommes face à un outil. Jesse Newland, de GitHub, a donné naissance à cet acronOp en 2013. L’idée est de fluidifier les échanges entre les équipes en passant par un chat bot. Les commandes lancées dans le chatbot permettent de lancer des scripts, des actions, des vérifications, etc. L’usage n’est pas réservé aux acteurs techniques. Il suffit de créer des commandes qui répondent aux différents besoins.

L’intégration de commandes dans un canal de communication est inspirée des pratiques d’automatisation que l’on trouve dans les clients IRC. Il s’agit d’une application de la culture DevOps. Aujourd’hui, il est courant de voir des outils de ChatOps, notamment dans Slack, Discord, GitHub et GitLab.

DataOps / MLOps / AIOps

La fratrie suivante est presque indissociable. Pourtant, chacun a sa spécificité. Nés à un an d’intervalle, le DataOps, le MLOps et l’AIOps traitent des pratiques DevOps autour des données.

Le DataOps est la pierre angulaire de ses frères. Il commença par apporter des pratiques au milieu de l’analyse de données pour évoluer vers une approche spécifique à la gestion des données.

Grâce à cela, le MLOps a pu se concentrer sur la gestion des modèles d’apprentissage automatique. Il apporte des pratiques DevOps pour la gestion des modèles, de leur déploiement et de leur maintenance. Dans ce domaine, la gestion de la donnée est primordiale. C’est pourquoi le DataOps est souvent un point de départ pour les équipes qui veulent se lancer dans le MLOps.

Le cadet de la fratrie, l’AIOps s’appuie sur les données issues de l’observabilité, analysées via les modèles de Machine Learning, pour apporter des réponses, voire des actions pour la résolution de problèmes de production. Il est l’écho du NoOps mentionné plus haut.
Sans DataOps et MLOps, point d’AIOps. Il est, à date, peu probable que son avènement découle sur le NoOps. Par contre, il s’avère être un compagnon de plus en plus utile.

Source : unravel

GitOps

Voilà un autre acronOp particulier : le GitOps. Théorisé par Weaveworks, il est une proposition de flux de travail autour de l'IAC (Infrastructure As Code). L’infrastructure est déclarée dans des fichiers. Ces fichiers sont versionnés dans un dépôt Git. L’infrastructure est déployée à partir de ces fichiers. Les changements sont gérés via des pull-requests. Les déploiements sont automatisés avec un déclencheur humain ou automatique selon le niveau de maturité des contrôles. Le schéma ci-dessous illustre ce flux.

Source : Rafay

Bien entendu, la culture DevOps a influencé la création de GitOps, qui est aujourd’hui très répandu, pour ne pas dire omniprésent, dans les écosystèmes clouds.

FinOps / GreenOps

Que dire des siamois FinOps et GreenOps. Ils partagent leur Genèse, bien que nés en décalage : l’usage des ressources des infrastructures incitées par la flexibilité que le DevOps veut apporter doit être maîtrisé. Tous deux regardent ces ressources. L’un, tel Picsou, ne jure que par le sou. L’autre, tel Captain Planet, se focalise sur l’empreinte environnementale. Pourtant, leurs actions apportent souvent les mêmes conséquences, via les mêmes méthodes. Seule la grille de lecture change.

Il faut reconnaître que leur naissance était nécessaire pour calmer l’euphorie encouragée par les clouds publics.

Leurs amis

Depuis 2020, aucun nouvel acronOp. Du moins aucun qui n’ait pris le focus. Peut-être que la pandémie a eu raison de leur créativité. Ou sont-ils suffisants pour apporter les variations que l’on souhaite pour exprimer la culture DevOps ?
Pour autant, ils sont toujours présents et ne sont pas seuls. Deux amis les accompagnent : SRE et Platform Engineering.

Site Reliability Engineering

Terme inventé chez Google, derrière cet acronyme se cache un rôle, un état d’esprit et une somme de pratiques. Site Reliability Engineering, l’ingénierie de la fiabilité des sites en français, est une discipline considérant l’ensemble de la chaîne de production pour garantir la fiabilité des services. Historiquement, ces acteurs sont nommés ingénieurs de production.

Les éléments fondateurs de cette ingénierie sont très similaires, voire identiques à ceux du DevOps, à la différence que le SRE veut répondre aux problèmes de fiabilité de la production. Là où le DevOps veut fluidifier la chaîne de création de la valeur.
Centré sur l’expérience de ces clients, le SRE cherche à répondre au mieux à ses besoins. Pour cela, il s’appuie sur différents indicateurs, qu’il partage avec l’ensemble des équipes.

Très rapidement le SRE a vu la synergie avec la culture DevOps, c’est pourquoi il l’encourage et l’applique.

Platform Engineering

Ce n’est pas le dernier de la bande et pourtant, cet ami des acronOps est le dernier à occuper l’espace médiatique. Le Platform Engineering est une démarche qui vise à construire et maintenir une plateforme self-service pour les équipes de développement.
Cette plateforme fournit des outils et des services (comme l'infrastructure, les pipelines CI/CD, la supervision, etc.) qui automatisent et simplifient les tâches opérationnelles, permettant aux développeurs de se concentrer sur leur code plutôt que sur la gestion de l'infrastructure. L'objectif est de fournir une expérience utilisateur fluide et efficace, réduisant les frictions et accélérant le cycle de développement.

La création d'une plateforme de ce type nécessite une collaboration étroite entre les équipes de développement et les équipes d'opérations. Il s'agit de définir les besoins des développeurs, de concevoir une architecture robuste et évolutive, d'implémenter les outils nécessaires, et de maintenir la plateforme en état de fonctionnement optimal. Le Platform Engineering met l'accent sur l'automatisation, l'observabilité et la sécurité, afin de garantir la fiabilité et la performance des services fournis.

En résumé, il s'agit d'une approche qui favorise l'autonomie des développeurs, leur permettant de déployer et de gérer leurs applications plus rapidement et plus facilement, en utilisant une plateforme fiable et sécurisée.

Il n’est pas rare de voir çà et là des articles indiquant que le Platform Engineering remplace DevOps. Il n’en est rien. Nous sommes plutôt face à un complément. Le Platform Engineering est une réponse à une organisation qui veut aller plus loin dans la collaboration et l’automatisation.

Conclusion

Les acronOps sont nés pour apporter une réponse aux problèmes de fluidité dans la chaîne de production. Initialement ciblées entre les Dev et les Ops dans les entreprises tech, elles ont vite élargi le cadre de cette nouvelle culture à l’ensemble de l’organigramme.
Chaque nouvel acronOp apporte une déclinaison de la culture DevOps. Ils partagent tous leur vision sur la collaboration, la fluidification des échanges entre les équipes et les étapes de la chaîne de production. Toujours dans un but d'améliorer la qualité et la vélocité.

La plupart portent sur l’organisation des équipes. Quelques-uns représentent des pratiques spécifiques, comme GitOps et ChatOps. Il est intéressant de voir les différentes compréhensions de ce qu’ils véhiculent. Le site DevOps topologies présente les implémentations que l’on trouve couramment.

Si vous en croisez un, n’ayez pas peur. C’est un ami qui vous veut du bien. Essayez de le comprendre et de l'apprivoiser.
Retenez surtout qu’aucun ne s’oppose aux autres. Chaque variation veut apporter un focus sur une partie de l’organisation. Complémentaires, ils peuvent être introduits dans l’entreprise en même temps. Comme le mentionne Kadia Himeur :

Le DevOps est avant tout et surtout une histoire de collaboration, de process et de culture.

Quant à leurs amis, ce sont des compléments essentiels pour une organisation qui veut aller plus loin dans la collaboration et l’automatisation.

Platform Engineering supports SRE. Good SREs implement DevOps. cf. The New Stack & Google

📝 Cet article fait partie du "Advent of Tech 2024 Onepoint", une série d'articles tech publiés par Onepoint pour patienter jusqu'à Noël.
Voir tous les articles du Advent of Tech 2024 d'ici Noël.