Qui gère les environnements hors production ?

Chez OCTO nous sommes très souvent focalisé sur l’environnement de production, celui qui attire souvent tous les regards car nous sommes confrontés à l'utilisateur final, au trafic réel et aux problèmes qui n’ont jamais été rencontrés avant la mise en production. Nous avons tendance à ne pas évoquer les environnements hors production (DEV, TEST, PREPROD…) alors qu’ils sont à la fois indispensables et source de tensions. Ils servent à développer, tester, valider et sécuriser les applications avant leur mise en production, mais leur gestion est souvent hétérogène, coûteuse et mal gouvernée.

Quels sont les environnements qui sont identifiés comme hors production ? Qui les gère réellement ? Faut-il un langage commun ? Quelles difficultés reviennent le plus souvent ? Vers quoi évolue-t-on ?

Je vous propose ici de faire un petit tour d’horizon.

Définition d’un environnement hors Production

Un environnement hors production est un environnement informatique utilisé en dehors de l’exploitation réelle d’un service ou d’une application par les utilisateurs finaux. Il sert à concevoir, tester, valider ou maintenir un système sans impacter le fonctionnement en production.

Concrètement, c’est un espace où l’on peut :

• Développer de nouvelles fonctionnalités
• Tester des correctifs ou des mises à jour
• Reproduire des incidents
• Former des équipes
• Valider des configurations techniques.

Quels sont les environnements hors production à disposition des équipes ?

Il existe une grande variété d’environnements selon les entreprises. Je cite les environnements que l’on retrouve le plus souvent chez nos clients. Vous trouverez ci-dessous une liste non exhaustive :

(*) il n’y a pas forcément un environnement de sécurité. Les Pentest se font par exemple sur l’environnement de pré-production et de production. L’un a pour objectif de représenter la production - où du moins de s’en rapprocher - et le dernier d’être l’environnement de référence.

Qui gère les environnements de hors production ?

Il n’existe pas de réponse unique, cela va dépendre de l’organisation, des pratiques, de la culture, de la maturité de l’entreprise, de ses activités,...

Les équipes les plus souvent impliquées :

Équipes de développement

Les développeurs sont généralement responsables de la gestion des environnements de développement. Cela inclut la configuration des outils de développement, la gestion des dépendances et des bases de données locales, la gestion de la config applicative, notamment identifier les changements de config qu'on embarque ou non dans une release ainsi que le déploiement de l'application en cours de développement.

Ils peuvent avoir la responsabilité de déployer leur code sur les environnement successifs : intégration, tests (User Acceptance Tests) aussi appelé recette. En fonction des entreprises, leur responsabilité s’arrête à l’environnement d’intégration, voir à celle de recette. Dans les entreprises où la culture de l’autonomie est forte “you build it, you run it”, elle va jusqu’à la mise en production.

Équipe dédiée sur les environnements d’intégration et de recette

Dans les grands groupes, notamment bancaires ou d’assurance, la gestion des environnements hors production relève souvent d’une équipe dédiée aux environnements et à l’intégration. Elles ont pour responsabilités de :

• Créer et maintenir des environnements partagés (INT, RECETTE)
• Coordonner des versions applicatives
• Planifier des campagnes d’intégration
• Rafraîchir et anonymiser des bases de données
• Gérer les changements de configuration

Cette équipe agit comme une entité transverse afin de coordonner des travaux techniques. Elle garantit la cohérence des environnements mutualisés utilisés par plusieurs projets simultanément.

A la Société Générale, des équipes spécialisées gèrent les environnements d’intégration et de recette afin d’assurer la stabilité et la conformité avant toute mise en production. La séparation des responsabilités répond ici à des exigences de contrôle interne et de gestion des risques.

Tous les grands groupes avec un fort découpage de responsabilité comme par exemple le milieu bancaire, les assurances, les grandes administrations sont dans ce cas-là. J’ai pu vivre ce modèle au PMU un acteur du jeu en ligne sur les paris sportifs ou chez des grands acteurs bancaires.

Équipes QA / Test

Dans certaines organisations, notamment lorsqu’une forte exigence de validation fonctionnelle s’impose, les environnements hors production sont pilotés par une équipe Assurance Qualité (QA) / Tests appelé aussi Usine de tests. Elles ont pour responsabilités de :

• Préparer des environnements de test
• Gérer des jeux de données
• Automatiser des campagnes de tests
• Organiser des recettes métiers

L’environnement hors production devient alors un espace de validation. Le métier passe par une phase de tests approfondie avant de donner son GO en production. Cette phase s’appelle une VABF (Vérification d’Aptitude du Besoin Fonctionnel) dans une approche cycle en V. En général, elle dépend des équipes d'exploitation qui leur mettent à disposition ces environnements.

Nous retrouvons ce modèle dans beaucoup d’entreprises du CAC 40 mais également dans de grandes administrations françaises où le passage en production est une grande source de stress. En effet, les tests sont souvent manuels et rarement automatisés. Il faut alors multiplier les process afin de s’assurer que tout le monde aura bien testé l’application.

Équipes Infrastructure / Cloud

Dans les organisations en transformation qui cherchent à grandir à l’échelle, la gestion des environnements hors production peut relever d’une équipe Cloud. Elles ont pour responsabilités de :

• Mettre à disposition des comptes cloud sandbox
• Définir des standards de sécurité
• Gérer des coûts d'infrastructure
• Encadrer des expérimentations techniques

Des entreprises comme Air France ont structuré des équipes cloud chargées de fournir des environnements sécurisés et conformes aux standards du groupe. C’est également le cas chez Hermès ou Imerys : vous devez faire des demandes aux équipes infrastructures pour disposer de vos environnements.

Équipes DevOps / Plateforme

Dans les entreprises technologiques à forte culture d’automatisation, la gestion des environnements hors production est généralement assurée par une équipe Platform Engineering ou DevOps. Elles ont pour responsabilités de :

• L’automatisation du provisioning des environnements (Infrastructure as Code)
• Standardisation des architectures techniques
• Gestion des pipelines CI/CD
• Contrôle des accès et des secrets
• Supervision et observabilité hors production
• Optimisation des coûts cloud
  

Dans ce modèle, l’équipe plateforme conçoit un cadre technique réutilisable et industrialisé. Les équipes Produits consomment ces environnements en autonomie, souvent via des mécanismes de self-service. Nous retrouvons ce modèle chez Carrefour, Décathlon,.. qui utilisent des IDP (Internal Developper Plateform) comme Backstage afin de permettre aux équipes de les rendre plus autonomes. C’est quelque chose qui a été mis en place récemment au sein de l’APHP.

Chez Spotify, les équipes « Platform » fournissent des environnements standardisés et automatisés permettant aux squads de développer et tester rapidement leurs fonctionnalités. La responsabilité est partagée : Les équipes plateformes fournissent l’infrastructure et les équipes Produits installent et exploitent leurs environnements dessus.

Vous retrouvez dans ce modèle les équipes Devops qui gèrent la plateforme de pré-production afin de répéter les gestes avant une mise en production.

Dans beaucoup d’entreprises cela est vu aussi au nom de la séparation des responsabilités entre développeurs et les équipes OPS.

Construire un langage commun

Une fois les environnements définis et qui devait les gérer, il est à mon sens essentiel d’utiliser un langage commun pour pouvoir les opérer sous peine de ne pas pouvoir déployer infine sur l’environnement de production.

Pour une digital factory chez Engie, un acteur mondial de l’énergie qui comportait une dizaine de plateformes, il a été décidé sur l’une d’elle d’identifier systématiquement les versions en recourant classiquement au formalisme du Semantic Versioning (SemVer) : X.Y.Z où X est le numéro de version majeure, Y est le numéro de version mineure et Z est le numéro de correctif pour une version corrective. Ce formalisme commun a permis de facilement décompter les combinaisons X.Y.Z différentes amenées en production et d’ainsi compter les mises en production.

De même les développeurs et les OPS ont définit plusieurs sujets :

• Qu’est-ce qu’un environnement ? C'est quoi une "promotion" (pour passer de DEV à UAT, de UAT à PPROD, ...) ?
• Qu’est-ce qu’une release ? Qu'est-ce qu'une release note ? Qu'est-ce qui la caractérise ?
• Qu’est ce qu’un DoD (Definition Of Done) d'une release ?
• Quand est-ce qu'une release démarre (qui donne le top départ) ?
• Quand est-ce que ça s'arrête ?
• ...

Ce langage commun n’est pas figé, il évolue dans le temps avec les pratiques des équipes. Il a été par la suite été diffusé aux autres plateformes de la digital factory.

Il peut se créer par les pratiques d’équipes pour ensuite être diffusé. Il peut être incarné par un Release Manager (gestionnaire de versions).

Dans certaines entreprises ce rôle est central dans la gestion des environnements de production et hors production. Il doit veiller à ce que les déploiements, les tests et la gestion des versions se fassent de manière cohérente, sécurisée et en respectant des standards bien définis.

Ces standards visent à minimiser les risques, garantir la qualité du logiciel et assurer une transition fluide entre les différentes étapes du cycle de vie de l'application.

Ce rôle n’existe pas toujours dans ce cas : c’est l’équipe de développement qui le prend en compte. Il se retrouve souvent dans les entreprises qui grandissent rapidement sans réelles mises en œuvre de pratique commune.

Attention, ce rôle n’empêche pas de se confronter à des difficultés diverses.

Les difficultés rencontrés pour gérer ce type d’environnements

Représentativité entre environnement de production et hors production

Quand les équipes gèrent de plus en plus d’environnements cela crée de la complexité. L’un des problèmes les plus criants est la divergence progressive entre les environnements hors production et l’environnement de production. Cette dérive peut concerner :

• Les versions logicielles différentes
• Le paramétrages système ou middleware
• Les règles de sécurité et politiques réseau
• La volumétrie de données

Gouvernance floue

Cette situation engendre des écarts de comportement imprévus lors du déploiement en production, compromettant la fiabilité des tests réalisés en amont.

Dans les organisations traditionnelles, la séparation entre équipes de développement, d’exploitation et de sécurité peut entraîner une dilution des responsabilités :

• Qui provisionne les environnements ?
• Qui valide leur conformité ?
• Qui en assure la maintenance ?
• Qui en contrôle les coûts ?

L’absence de modèle de gouvernance explicite crée des frictions inter-équipes et ralentit les cycles de livraison.

Garantir la conformité des habilitations

Les environnements hors production tendent à être moins strictement contrôlés que la production. Cela peut conduire à :

• Une multiplication des comptes à privilèges
• Des accès persistants non révoqués
• Une traçabilité insuffisante des actions
  

Ces faiblesses constituent un vecteur de risque de sécurité important. Dans le cadre d'une de mes missions avec mon collègue OCTO pour une banque, elle était confrontée à ce type de problématique tant pour la partie hors production que production.

Dans un autre cas, les équipes avaient des difficultés à créer de nouvelles habilitations. La méthode de contournement était de recycler des comptes, des mots de passe ou des certificats (mots de passes de bases de données, certificats serveurs recyclés en certificats clients, compte d’accès aux environnements hors production) afin d’éviter à devoir les créer. Ce type d’opérations prenait plusieurs jours ce qui n’était pas compatible avec le rythme des demandes de changements.

Réplication des données de production dans les environnements hors production

L’utilisation de données issues de la production dans les environnements de test pose des enjeux juridiques majeurs. Les obligations réglementaires telles que le RGPD imposent :

• L’anonymisation ou le pseudonymisation des données
• La limitation des accès
• La traçabilité des traitements
  

Toute défaillance peut entraîner des sanctions financières et réputationnelles significatives. Les environnements hors production nécessitent des rafraîchissements périodiques de données. Ces opérations sont complexes et peuvent générer :

• Des interruptions de service
• Des incohérences référentielles
• Des conflits entre équipes utilisant simultanément l’environnement

Il est indispensable d’outiller ses équipes afin d’automatiser ce type de travaux et disposer ainsi de données représentatives de la production dans les environnements hors production.

Les coûts

Dans les architectures cloud, les environnements hors production peuvent représenter une part significative des dépenses IT :

• Multiplication des environnements parallèles
• Instances surdimensionnées
• Environnements non supprimés
• La non automatisation des environnements.
  

Dans une filiale informatique d’une banque française, ils avaient une multitude d’environnements à disposition des équipes qui n'étaient pas utilisés depuis 6 mois.

Dans d’autre cas, les équipes disposaient de très nombreux environnements dédiés à un seul rôle. Il n’était pas possible de les ré-affecter alors que le taux d’utilisation était très faible (quelques jours par mois) et la création d’un environnement prenait environ un mois.

D’autres mettent à disposition tout le temps les mêmes environnements anté-prod sans chercher à comprendre l’utilisation réelle. Les utilisateurs peuvent par exemple déployer uniquement en recette et les environnements de dev et d’intégration ne sont jamais utilisés.

Tout cela représente un coût non négligeable alors que des environnements sont présents et ne peuvent pas être utilisés pour des raisons purement organisationnelles.

Vers quoi évolue-t-on ?

Je vois deux tendances émergées.

Les environnement éphémères et automatisés

Il s’agit de donner la possibilité à des équipes de créer un environnement à la volée afin d’effectuer des tests dans un environnement isolé, sans impacter la production ou les autres développements et de le détruire une fois celui-ci terminé. La création à la demande peut se faire via Terraform, Kubernetes, pipelines GitOps…

Leurs principaux avantages sont :

• L’isolation des tests
• La réduction des conflits entre équipes
• L’optimisation des coûts (ressources utilisées uniquement pendant la durée nécessaire)
• Une meilleure rapidité de validation et de mise en production

Il peut également s'agir d’une excellente occasion de valider des procédures rarement utilisées comme la création d’un environnement, la restauration du contenu d’une base de données et surtout sa suppression automatique.

Mehdi Houacine ancien consultant chez OCTO le décrit très bien dans son article de blog : Environnements éphémères anté-production : arrêtez de faire du "pet" 🐈, faites du "cattle" 🐄

La mise à disposition de Plateform Engineering (IDP)

Une Internal Developer Platform (IDP) est une plateforme interne conçue pour faciliter le travail des équipes de développement en leur fournissant des outils, des environnements et des services standardisés en libre-service.

Elle centralise et automatise l’accès aux infrastructures, aux pipelines CI/CD, aux templates applicatifs et aux bonnes pratiques, afin de réduire la complexité opérationnelle et d’accélérer la livraison logicielle.

Une IDP repose souvent sur des technologies comme Kubernetes pour l’orchestration, Terraform pour l’infrastructure as code, ou encore Backstage comme portail développeur.

Il s’agit d’une équipe interne qui fournit par exemple la création des éléments suivants :

• Des templates d’environnements
• Des services aux développeurs : Accès à un API Management, des radars sur les standards des technologies utilisées,...
• Des standards d’architecture

Son objectif principal est d’améliorer l’expérience développeur (DevEx), d’augmenter la productivité et de garantir la cohérence et la sécurité des déploiements.

Conclusion

Les environnements hors production ne sont pas juste une porte d’entrée vers la production Ils sont devenus :

• Un enjeu majeur de sécurité et de conformité
• Un levier pour expérimenter sans impacter le quotidien d’une production
• Un centre de coûts significatif (humain, technique, organisationnel)
  

Tout ceci implique de la part des équipes de plus en plus d’automatisation pour sécuriser les applications et les produits. La vraie question n’est plus seulement qui les gère ? Mais plutôt : comment les transformer en accélérateur business plutôt qu’en contrainte organisationnelle ?

Références

Livres

Site Reliability Engineering: How Google Runs Production Systems – Niall Richard Murphy, Betsy Beyer, Chris Jones, Jennifer Petoff - Ce livre est principalement orienté vers la gestion des systèmes de production, il couvre également les bonnes pratiques en matière de tests, d'intégration continue, et de gestion des environnements qui se rapportent directement à la gestion des environnements hors production.

DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations – Gene Kim, Patrick Debois, John Willis, Jez Humble - Ce livre explique comment adopter les pratiques DevOps et automatiser les processus de développement, d'intégration, de test et de déploiement. Il est riche en détails sur la gestion des environnements, l'automatisation des tests et des déploiements, ainsi que sur l'importance de garantir la qualité tout au long du cycle de vie des applications.

Articles

The Twelve-Factor App – https://12factor.net/ : Ce site web présente un ensemble de 12 principes pour construire des applications cloud natives. Bien que le site soit axé sur les bonnes pratiques de développement et de déploiement, plusieurs des principes, comme la gestion des configurations, la séparation des environnements, et le versionnage, sont directement applicables à la gestion des environnements hors production.

DevOps and the Role of the Release Manager – Atlassian Blog (https://www.atlassian.com/devops) - Cet article explore le rôle du Release Manager dans le contexte DevOps et présente les meilleures pratiques pour gérer des environnements de test et de production de manière fluide et cohérente.