L'EUC en tant que produit : la prochaine étape après GitOps

Un article de blogue précédent, intitulé « Arrêtez de cliquer, commencez à déployer : pourquoi les administrateurs EUC devraient adopter l'IaC et GitOps » , plaidait pour une gestion des modifications EUC hors des consoles et intégrée au code. Celui-ci prolonge cette réflexion. Qu'arrive-t-il lorsque votre pipeline fonctionne, mais que vous êtes toujours le seul à pouvoir l'utiliser en toute sécurité ? Ce problème, et comment le résoudre, sera au cœur de ma prochaine session à EUC World Amplify 2026 à Milwaukee.

Un pipeline fonctionnel n'est pas la même chose qu'un pipeline utilisable.

Le billet de blogue précédent a défini cinq caractéristiques essentielles d'une modification durable : la possibilité d'effectuer des revues, la reproductibilité, l'observabilité, la possibilité de récupération et l'auditabilité. Voici les critères pertinents d'une bonne pratique d'ingénierie. Cependant, ils ne constituent pas, à eux seuls, les critères d'un bon produit. Une racine Terraform que vous seul pouvez planifier en toute sécurité, un pipeline dont le YAML est uniquement débogué par vous, un dépôt dont la structure de dossiers n'a de sens que si vous l'avez écrite – tout cela peut être entièrement vérifiable et auditable, et pourtant représenter un goulot d'étranglement, même avec une meilleure documentation.

C'est le problème que rencontrent la plupart des équipes juste après avoir adopté GitOps : les outils fonctionnent, mais l'adoption se bloque à une seule personne.

Qu'est-ce que « route asphaltée » signifie réellement ?

Les équipes de la plateforme, en dehors d'EUC, ont résolu une version de ce problème il y a des années, et elles ont opté pour l'expression « route goudronnée » : un petit nombre de chemins sécuritaires et bien balisés menant à un objectif commun, les zones dangereuses étant évitées, et la possibilité de s'en écarter en cas de réelle nécessité. Pas besoin d'être un expert de Terraform pour rester sur la bonne voie. Il suffit d'une requête facile à formuler.

Voici la différence entre un flux de travail et une plateforme. Un processus de travail est quelque chose que vous avez créé vous-même. Une plateforme est quelque chose que vous avez créé pour des personnes qui ne l'ont pas créée.

Trois ingrédients : éléments de base, interfaces et garde-fous

Transformer un pipeline en activité en une route goudronnée se résume à trois choses :

• Éléments constitutifs modulaires : les catalogues de machines, les groupes de livraison, la configuration ADC et autres modèles répétitifs sont conditionnés sous forme de modules réutilisables et versionnés au lieu de modules racines copiés-collés.
• Interfaces conçues pour les consommateurs : demander trois bureaux supplémentaires devrait ressembler à une saisie courte et évidente, et non à une leçon sur les boucles for_each et les blocs dynamiques.
• Des garde-fous intégrés au processus accéléré : les contrôles de qualité, la détection des dérives et les approbations par étapes que nous avons décrits comme des disciplines dans le dernier article deviennent le processus par défaut, et non une étape supplémentaire facultative que l’on peut sauter sous la pression des délais.

C'est là que réside la vraie tension entre la standardisation et la flexibilité. Trop rigide, et les utilisateurs contournent la plateforme comme ils contournaient auparavant le contrôle des modifications. Trop flexible, et on se retrouve avec un tas de scripts, certes mieux intégrés à la marque. Trouver le juste milieu relève du jugement, et non d’un paramètre prédéfini ; c'est un point que nous approfondirons en direct.

Ce que nous allons vraiment présenter à EUC World Amplify

Pour cette séance, on laisse tomber le schéma. Nous allons plutôt appliquer le concept de la route asphaltée à un déploiement Citrix DaaS multi-environnements réel. Nous parcourrons le dépôt sur GitHub et GitKraken, le modifierons dans VS Code et montrerons :

• Catalogues de machines Citrix et groupes de mise à disposition pour les environnements de développement, de test et de production : déployés sur Azure, joints à un ID Entra et utilisant le protocole Rendezvous, il n’y a donc aucune dépendance à gérer avec Cloud Connector.
• Promouvoir une version de développement vers les phases de test puis de production via une demande d'extraction plutôt que par un ticket de modification.
• Augmenter la capacité de production via ce même processus contrôlé par les demandes de fusion (sans console ni file d'attente de billets).
• Le cycle de reconstruction de 30 jours en action, étendant la pratique de reconstruction mensuelle du dernier article à un élément sur lequel toute une équipe s'appuie.
• Deux points d'approbation explicites, la mise en service et la mise hors service, qui maintiennent l'intervention humaine pour décider du moment, même si l'automatisation gère le comment.

Le dépôt de démonstration est public si vous voulez y jeter un coup d'œil avant ou après la session.

Détails de la séance

L'EUC en tant que produit : transformer l'automatisation de l'infrastructure en une « route asphaltée » pour les équipes de livraison

Conférencier : Rich Faulkner, Ferroque Systems

Événement : EUC World Amplify 2026, du 28 septembre au 1er octobre, Baird Center, Milwaukee, Wisconsin — worldofeuc.org/EUCWorld2026

Liste complète des sessions : worldofeuc.org/Amplify-Speaker-Sessions

On se voit là-bas ?

Cette session ne reviendra pas sur l'importance de GitOps ; je pars du principe que vous êtes déjà convaincus. Il s'agit d'aborder le problème plus complexe qui se pose ensuite : rendre cet investissement accessible à ceux qui n'ont pas participé à sa création. C'est généralement ce qui détermine si une plateforme survit à la personne qui a écrit son premier fichier Terraform.

Commencez par vous familiariser avec les bases : « Arrêtez de cliquer, commencez à déployer : pourquoi les administrateurs EUC devraient adopter l’IaC et GitOps » . Pour plus de ressources sur l’automatisation, consultez le manuel d’automatisation Citrix , GitKraken (notre client Git de référence pour ce flux de travail) et la bibliothèque de ressources de Ferroque Systems .

Si votre équipe a dépassé le stade de la discussion « pourquoi GitOps » et est bloquée sur la discussion « comment faire en sorte que le reste de l'organisation l'utilise réellement », c'est exactement ce que j'aborderai à Milwaukee — venez me trouver !