Renaud Calle, auteur/autrice sur OUTSCALE blog https://blog.outscale.com Thu, 16 Jul 2026 15:02:29 +0000 fr-FR hourly 1 https://wordpress.org/?v=7.1.3 https://blog.outscale.com/wp-content/uploads/2021/04/SIGLE_LOGO-OSC_256x256.png Renaud Calle, auteur/autrice sur OUTSCALE blog https://blog.outscale.com 32 32 Plumber : renforcer la sécurité de nos workflows GitHub Actions https://blog.outscale.com/plumber-renforcer-la-securite-de-nos-workflows-github-actions/ Wed, 15 Jul 2026 14:19:06 +0000 https://blog.outscale.com/?p=15826 Chez OUTSCALE, au sein du service dédié à la création, à la maintenance et à l’évolution…

L’article Plumber : renforcer la sécurité de nos workflows GitHub Actions est apparu en premier sur OUTSCALE blog.]]>

Chez OUTSCALE, au sein du service dédié à la création, à la maintenance et à l’évolution de nos produits open source, nous gérons au quotidien de nombreuses chaînes d’intégration et de déploiement continu.

Ces workflows sont parfois simples, parfois beaucoup plus complexes. Certains déclenchent des tests, d’autres publient des artefacts ou construisent des images. Tous ont, cependant, un point commun : ils font partie intégrante de notre chaîne de livraison.

Pendant longtemps, nous avons utilisé des actions maison pour nous aider à sécuriser ces workflows. Elles répondaient à des besoins concrets : vérifier certaines pratiques, homogénéiser nos pipelines, éviter les erreurs les plus évidentes et garantir un niveau de sécurité cohérent sur l’ensemble de nos dépôts.

Mais comme souvent avec les outils internes, ces actions demandaient du temps de maintenance. Il fallait les faire évoluer, suivre les nouvelles bonnes pratiques, intégrer de nouveaux cas d’usage, puis s’assurer que chaque dépôt restait aligné. À mesure que notre périmètre open source grandissait, nous avions besoin d’une approche plus standardisée, plus lisible et plus durable.

C’est dans ce contexte que nous avons décidé de remplacer progressivement nos actions maison et d’étendre notre périmètre de vérification grâce à Plumber.

L’intégration continue est devenue une surface d'attaque à part entière

La sécurité d’un projet open source ne se limite plus au code applicatif. Les chaînes de CI/CD sont aujourd’hui au cœur du processus de livraison. Elles ont accès au code source, manipulent des secrets, interagissent avec des registres, publient des artefacts et déclenchent parfois des actions sensibles.

Une mauvaise configuration, une permission trop large, une action tierce non figée ou une dépendance insuffisamment maîtrisée peuvent devenir des points d’entrée pour une attaque de supply chain.

Dans ce contexte, il ne suffit plus de vérifier ponctuellement qu’un workflow « fonctionne ». Il faut également s’assurer qu’il respecte des règles de sécurité claires, reproductibles et vérifiables dans le temps.

C’est précisément ce que nous recherchions : un outil capable de nous aider à auditer nos workflows GitHub, à détecter les écarts et à garder une vision claire de notre niveau de conformité CI/CD.

Pourquoi Plumber ?

Plumber nous permet de vérifier le niveau de sécurité de nos chaînes CI/CD directement dans nos processus de livraison. L’objectif n’est pas seulement de bloquer un mauvais changement au dernier moment, mais de rendre les bonnes pratiques visibles, compréhensibles et actionnables par les équipes.

Avec Plumber, nous pouvons contrôler différents aspects de nos workflows : l’usage d’actions tierces, le niveau de permissions accordé aux jobs, les configurations potentiellement dangereuses ou encore le respect de règles définies dans une politique commune.

Cela nous permet de passer d’une logique artisanale, basée sur des scripts internes et des vérifications dispersées, à une approche plus structurée. Les règles sont centralisées, les rapports sont lisibles et les écarts peuvent être traités de manière plus simple.

Nous utilisons Plumber à deux niveaux.

D’abord, à chaque livraison, pour vérifier que les workflows restent conformes aux règles attendues. Cela permet de détecter rapidement une régression ou une configuration risquée introduite dans un dépôt.

Ensuite, de manière périodique, avec un rapport mensuel qui nous aide à prendre du recul sur l’ensemble de notre périmètre. Ce rapport nous permet de vérifier que nos dépôts restent alignés, même lorsque les projets évoluent, que les workflows changent ou que de nouvelles pratiques apparaissent.

Moins de maintenance, plus de sérénité

L’un des bénéfices les plus immédiats a été la simplification de nos processus.

En remplaçant progressivement nos actions maison, nous réduisons la quantité de code interne à maintenir. Nous évitons aussi de devoir réimplémenter nous-mêmes des contrôles déjà identifiés, documentés et suivis par une communauté plus large.

Cela ne veut pas dire que nous abandonnons notre responsabilité. Au contraire, Plumber nous donne une base plus solide pour formaliser nos attentes, ajuster nos politiques et suivre les écarts dans le temps. Nous gardons la maîtrise de notre niveau d’exigence, mais nous nous appuyons sur un outil pensé pour ce besoin précis.

Le résultat est assez simple: moins de friction, moins de dette interne, plus de visibilité et davantage de sérénité.

Pour une équipe qui maintient plusieurs produits open source, c’est un point important. Nous devons rester efficaces, tout en continuant à garantir un bon niveau de sécurité à chaque contribution, chaque commit et chaque release.

Un projet open source auquel nous voulons contribuer

Un autre point important dans notre choix est la nature même du projet. Plumber est open source. Pour nous, ce n’est pas un détail.

Nous travaillons nous-mêmes sur des produits open source,et nous savons à quel point la transparence, la collaboration et les retours d’expérience sont précieux pour faire progresser un outil. Utiliser Plumber, ce n’est pas seulement consommer une solution existante, c’est aussi rejoindre une dynamique communautaire autour d’un sujet qui nous concerne directement.

Le fait qu’il s’agisse d’un projet français rend également l’initiative particulièrement intéressante à nos yeux. Dans un domaine aussi stratégique que la sécurité de la supply chain logicielle, voir émerger des outils open source ambitieux, proches de nos problématiques et ouverts aux contributions est une excellente nouvelle.

Nous avons donc fait notre choix : Plumber va nous accompagner dans la sécurisation et la standardisation de nos workflows GitHub Actions.

Et nous ne comptons pas nous arrêter à son simple usage. Nous souhaitons également contribuer au projet du mieux que nous le pourrons : par des retours d’expérience, des idées d’amélioration, de la documentation, des issues ou lorsque ce sera pertinent, du code.

Parce que la sécurité de la chaîne CI/CD n’est plus un sujet secondaire. C’est un élément essentiel de la confiance que nous voulons apporter à nos utilisateurs, à nos contributeurs et à l’ensemble de notre écosystème open source.

L’article Plumber : renforcer la sécurité de nos workflows GitHub Actions est apparu en premier sur OUTSCALE blog.]]>
OCTL : la nouvelle génération de CLI OUTSCALE https://blog.outscale.com/octl-la-nouvelle-generation-de-cli-outscale/ Fri, 15 May 2026 10:09:39 +0000 https://blog.outscale.com/?p=13816 Chez OUTSCALE, les interfaces en ligne de commande occupent depuis longtemps une place centrale dans l’expérience…

L’article OCTL : la nouvelle génération de CLI OUTSCALE est apparu en premier sur OUTSCALE blog.]]>

Chez OUTSCALE, les interfaces en ligne de commande occupent depuis longtemps une place centrale dans l’expérience utilisateur. Elles sont le point d’entrée privilégié des équipes techniques qui souhaitent automatiser, intégrer et piloter leurs ressources cloud avec efficacité.

L’histoire de nos CLI reflète cette ambition continue : proposer des outils toujours plus simples, plus puissants et mieux adaptés aux usages modernes.

La première grande étape de cette histoire, c’est osc-cli. Véritable CLI historique d’OUTSCALE, elle a accompagné de nombreux utilisateurs dans l’administration de leurs ressources via l’API.

Distribuée sous forme de package Python, elle a constitué pendant des années la référence pour interagir avec notre environnement cloud en ligne de commande.

Aujourd’hui encore, elle reste maintenue pour garantir la continuité d’usage, mais son évolution est volontairement stabilisée : elle est désormais en mode maintenance, avec des correctifs mais sans nouvelles fonctionnalités.

Une nouvelle étape a ensuite été franchie avec oapi-cli. Pensée pour améliorer l’expérience utilisateur, cette CLI a introduit plusieurs avancées majeures : une syntaxe d’arguments plus riche, la possibilité de chaîner plusieurs appels, la prise en charge de fichiers JSON en entrée, ainsi qu’un système de variables internes permettant de réutiliser facilement le résultat d’une commande dans une autre. Elle est également fournie sous forme de packages auto-portés pour plusieurs environnements, facilitant son installation sur Linux, macOS et Windows. Avec oapi-cli, OUTSCALE a franchi un cap important en matière de souplesse et de productivité.

Aujourd’hui, cette évolution se poursuit avec octl, qui incarne la nouvelle génération de CLI OUTSCALE. Moderne, rapide et conçue pour répondre aux standards actuels, octl a vocation à devenir la CLI principale d’OUTSCALE. Là ou les générations précédentes répondaient à des besoins spécifiques ou historiques, octl porte une vision plus large: proposer une interface unifiée, cohérente et durable pour interagir avec l’écosystème OUTSCALE au complet.

Concrètement, octl se distingue par plusieurs atouts structurants. Écrite en Go, elle est distribuée sous la forme d’un binaire statique, ce qui simplifie fortement son installation et son déploiement. Elle permet de manipuler directement les champs des requêtes via des flags dédiés, sans imposer l’usage systématique de JSON. Elle propose également une autocomplétion avancée, non seulement pour les commandes, mais aussi pour les options et certaines valeurs, ce qui améliore sensiblement l’ergonomie au quotidien. A cela s’ajoutent des filtres de sortie inspirés de « jq », le chaînage de commandes, la mise en valeur syntaxique des résultats et la mise à jour automatique vers les dernières versions.

Mais la vraie force d’octl réside dans son ambition. Là où les outils précédents étaient avant tout associés à un périmètre plus limité, octl s’inscrit dans une logique plus transverse. Le projet est d’ores et déjà en capacité de gérer les ressources IaaS, le stockage OOS, ainsi qu’un support préliminaire pour OKS. Autrement dit, octl ne se contente pas d’être une nouvelle CLI: elle prépare le terrain pour une expérience unifiée à l’échelle des produits OUTSCALE.

C’est précisément ce qui en fait la CLI pour les gouverner toutes au sein de l’écosystème OUTSCALE. Notre objectif est clair : faire d’octl le point d’entrée principal pour les usages en ligne de commande. Les autres projets continueront d’être maintenus afin de garantir la stabilité et la compatibilité pour les utilisateurs existants, mais les évolutions fonctionnelles majeurs se concentreront désormais sur octl. Cette orientation permet de clarifier notre trajectoire, de concentrer nos efforts d’innovation et d’offrir à nos utilisateurs une expérience plus homogène sur le long terme. 

Avec octl, OUTSCALE affirme donc une vision plus simple : une CLI moderne, performante, extensible et pensée pour accompagner l’évolution de l’ensemble de ses services. Plus qu’un nouvel outil, octl est la fondation de la future expérience CLI OUTSCALE.

L’article OCTL : la nouvelle génération de CLI OUTSCALE est apparu en premier sur OUTSCALE blog.]]>
Cluster API Provider OUTSCALE v1.0.0 : Une version stable pour les environnements de production https://blog.outscale.com/cluster-api-provider-outscale-v1-0-0-une-version-stable-pour-les-environnements-de-production/ Mon, 25 Aug 2025 10:15:13 +0000 https://blog.outscale.com/?p=7887 Cluster API Provider OUTSCALE (CAPOSc) accède à une maturité fonctionnelle et technique avec le lancement de…

L’article Cluster API Provider OUTSCALE v1.0.0 : Une version stable pour les environnements de production est apparu en premier sur OUTSCALE blog.]]>

Cluster API Provider OUTSCALE (CAPOSc) accède à une maturité fonctionnelle et technique avec le lancement de sa version v1.0.0, fruit de plusieurs mois d’itération continue pour l’environnement de production.

Un ancrage plus fort, une expérience utilisateur plus aboutie

La montée en puissance du provider amorcée dans la v0.4.0 a impliqué plusieurs changements majeurs :

  • Simplification du déploiement
  • Clarification de la gestion des images machines (OMIs)
  • Refonte des logs pour une lecture plus fluide
  • Contrôle fin des paramètres de sécurité
  • Un socle plus pérenne pour une expérience utilisateur plus fiable et intuitive.

Ces évolutions ont renforcé la stabilité de l’outil et posé les fondations d’une expérience plus fiable et intuitive pour les utilisateurs.

Ce que la v1.0.0 change concrètement…

Cette v1.0.0 intègre des avancées décisives pour adresser les besoins opérationnels des équipes cloud et DevOps, en offrant notamment :

  • Support du multi-AZ pour les clusters Kubernetes
  • Réutilisation de ressources existantes pour plus de flexibilité dans les workflows
  • Gestion des pools d’IP publiques pour les node pools
  • Renforcement du contrôle réseau en filtrant les accès entrants à l’API Kubernetes ainsi que les flux sortants
  • Optimisation des délais de déploiement

En parallèle, le code a été entièrement refondu, pour une meilleure maintenabilité et une plus grande capacité d’évolution.

“Avec la v1.0.0, on est sorti du mode expérimental. On a conçu un provider plus robuste, plus rapide et plus facile à prendre en main  sans sacrifier la sécurité. C’est une vraie base de confiance pour les équipes qui veulent industrialiser leur gestion de clusters Kubernetes sur OUTSCALE.”
Renaud Calle, manager d’équipe de développement dans l’univers de l’open source, OUTSCALE

Une feuille de route ambitieuse et ouverte

La publication de la v1.0.0 n’est qu’une étape. L’équipe travaille déjà sur les prochaines évolutions du provider, avec une logique de co-construction avec la communauté :

  • Support natif de l’offre managée OKS (OUTSCALE Kubernetes Service)
  • Refonte de l’API, conçue pour limiter les impacts utilisateurs et pilotée avec transparence
  • Fonctionnalité de multi-tenancy, pour permettre le déploiement de workloads sur plusieurs comptes OUTSCALE
  • Suivi régulier de la compatibilité avec les dernières versions de Kubernetes
  • Sécurité renforcée, en lien avec les exigences souveraines du cloud OUTSCALE

Rejoignez la communauté

CAPOSc progresse grâce à son écosystème d’utilisateurs, contributeurs et partenaires. Vous pouvez :

  • Tester la v1.0.0
  • Partager vos retours d’expérience
  • Rejoindre notre communauté sur Discord
  • Contribuer activement à la roadmap

Chaque usage compte. Chaque retour nous permet de faire évoluer un provider pensé pour les environnements critiques, aligné avec les exigences de souveraineté, de sécurité et de performance.

En savoir plus ou nous rejoindre : Github | Discord

L’article Cluster API Provider OUTSCALE v1.0.0 : Une version stable pour les environnements de production est apparu en premier sur OUTSCALE blog.]]>