Argy
Demander une démo

Concevoir des modules

Comment les équipes plateforme emballent schéma + templates + garde-fous + docs dans des modules versionnés (golden paths).

Cette page décrit le modèle mental de conception de modules dans Argy.

Le but n’est pas de masquer vos outils. Le but est de les orchestrer dans une interface produit cohérente et versionnée.

Un module, ce n’est pas “juste de l’IaC”

Un module Argy doit être traité comme une capacité de plateforme :

  1. Interface : un schéma de configuration (paramètres typés).
  2. Implémentation : templates (IaC, workflows CI/CD, scripts).
  3. Garde‑fous : policies, validations, workflows d’approbation.
  4. Documentation : ce que fait le module, comment l’utiliser, ownership.
  5. Run : runbooks + baselines d’observabilité.

Si vous ne livrez que de l’IaC, vous livrez de la complexité. Si vous livrez un module complet, vous livrez un golden path.

Structure recommandée

1) Concevoir le schéma d’abord

Pensez le schéma comme un contrat :

  • minimal,
  • defaults sûrs,
  • contraintes explicites (enums, ranges).

2) Garder les templates “boring”

Préférez des outils éprouvés (Terraform/OpenTofu, Kubernetes, votre CI/CD) et des templates lisibles.

3) Mettre la gouvernance au bon endroit

Les policies doivent être évaluées dans le flow, pas “après coup”.

Voir : Policies & garde‑fous.

4) Versionner avec intention

Traitez les modules comme des produits versionnés :

  • améliorer sans casser les consommateurs,
  • documenter les breaking changes,
  • proposer des chemins de migration.

Voir : Versionnage & cycle de vie.

Aller plus loin