Même principe sur les deux technologies : tout lab doit être identifiable. Son propriétaire, son projet et sa nature de lab doivent être lisibles sans avoir à demander à quiconque. Seule la mécanique diffère.
| Tag | Contenu attendu | Contrôle |
|---|---|---|
owner |
Personne ou équipe ayant créé le lab | Refus si absent |
projectName |
Nom du projet ou du lab | Refus si absent |
creationDate |
Date de création, au format dd.MM.YYYY |
Refus si absent |
expirationDate |
Expiration prévue (au maximum +3 mois) | Audité si absent (recommandé) |
Client |
Projet client concerné, pour la refacturation | Aucun contrôle (optionnel) |
Trois tags sont bloquants, et eux seuls : owner, projectName et creationDate. La création de la ressource est
refusée si l’un des trois manque. L’absence d’expirationDate ne bloque pas, mais elle est relevée à l’audit.
| Tag | Contenu attendu |
|---|---|
lab |
Marque la ressource comme appartenant à un lab |
owner-{trigramme} |
Identifie le consultant propriétaire |
env-lab |
Confirme l’environnement comme un lab |
En complément, des métadonnées au format YAML sont à renseigner dans les Notes/Description du Pool. Elles donnent aux administrateurs le contexte, l’objectif et le propriétaire du lab lors de la revue mensuelle.
Les tags owner, projectName et creationDate (format dd.MM.YYYY) sont requis sur le Resource Group et sur chaque ressource qu’il contient. La création est refusée si l’un d’eux est absent.
Le tag expirationDate indique l’expiration prévue du lab (au maximum +3 mois). Son absence n’est pas bloquante mais elle est auditée : renseignez-le pour faciliter le suivi de fin de vie.
Le tag Client identifie le projet client concerné, pour permettre la refacturation. Il est optionnel et n’est ni bloqué ni audité.
Tags requis : lab, owner-{trigramme} et env-lab.
Renseigner les métadonnées YAML dans les Notes/Description du Pool.
