Le système de templates de Go, souvent appelé go template, sert à séparer proprement les données et la présentation sans alourdir un backend. Je m’en sers surtout quand je veux générer du HTML, du texte, un email ou un fichier de configuration avec une logique lisible et peu de dépendances. Dans cet article, je vais expliquer comment il fonctionne, quand choisir `text/template` ou `html/template`, comment structurer des templates maintenables, et quels pièges j’évite systématiquement en revue de code.

Ce que fait vraiment le moteur de templates de Go

Le point clé est simple: un template Go n’est pas un mini-framework de présentation, c’est un moteur d’assemblage entre une structure de données et une sortie finale. Le texte hors balises est copié tel quel, et tout ce qui se trouve entre `{{` et `}}` devient une action qui lit des champs, appelle une fonction, exécute une condition ou parcourt une collection. La documentation de Go insiste sur ce découplage: le template reçoit des données, puis il navigue dans la structure via le point `.`.

Dans la pratique, je l’utilise pour trois cas très différents: un site web généré côté serveur, un email transactionnel, ou un fichier texte à produire automatiquement. Le même mécanisme reste utile tant que la sortie finale est du texte et que la logique métier reste dans le code Go, pas dans le template. C’est précisément ce qui rend l’outil sobre et durable. Une fois ce modèle en tête, la syntaxe devient beaucoup moins intimidante.

Comprendre la syntaxe sans se perdre

Le langage de template est compact, mais il faut assimiler quelques repères: `.` pour les données courantes, `$` pour une variable, `if` pour une condition, `range` pour itérer, `with` pour réorienter le point courant, et les pipelines pour chaîner les opérations de façon lisible. Je conseille de commencer par ces briques avant d’ajouter des fonctions personnalisées, parce qu’elles couvrent déjà une grande partie des besoins quotidiens.

Ce que je trouve le plus utile, c’est la lisibilité du pipeline. Au lieu d’écrire de la logique imbriquée, on peut enchaîner des étapes courtes et explicites. Un template comme {{.Title | printf "%q"}} dit immédiatement ce qu’il fait: il récupère la valeur, puis la formate. C’est simple, mais très efficace quand le projet grandit. Reste à choisir le bon package selon la sortie visée.

Choisir entre texte brut et HTML sécurisé

Go fournit deux paquets proches, mais leur objectif n’est pas le même. text/template rend du texte brut et n’ajoute aucun échappement automatique; html/template reprend la même API, mais ajoute un échappement contextuel pensé pour le HTML. Pour toute page web, la règle que je garde est presque binaire: si la sortie est du HTML, j’utilise html/template; sinon je pars sur text/template.

Le vrai intérêt de html/template n’est pas seulement l’échappement du texte. Il comprend aussi les contextes HTML, JS, CSS et URI, donc il adapte la sortie à l’endroit où la donnée apparaît. C’est pratique, mais je ne traite jamais ça comme un remplaçant de la validation serveur: un champ mal formé reste un problème métier, même s’il est correctement encodé à l’affichage. Le vrai sujet devient alors l’organisation du code.

Organiser des templates maintenables dans un vrai projet

Quand un projet grossit, le sujet n’est plus la syntaxe. Le vrai enjeu devient le chargement, le nommage et la réutilisation. Je préfère charger tous les templates au démarrage, les nommer clairement, puis rendre des sous-templates avec ExecuteTemplate plutôt que de concaténer du HTML à la main dans les handlers.

• ParseFiles convient quand vous avez quelques fichiers locaux et un chargement direct.
• ParseGlob devient utile quand vous organisez plusieurs vues par motif de fichiers.
• ParseFS est très pratique si vous embarquez les templates avec embed pour un déploiement autonome.
• ExecuteTemplate permet de cibler un layout ou un fragment nommé sans ambiguïté.
• Funcs doit être appelé avant le parsing si vous voulez utiliser des helpers comme upper, truncate ou un formateur de devise.

//go:embed templates/*.html
var templatesFS embed.FS

var tpl = template.Must(
    template.New("base").
        Funcs(template.FuncMap{
            "upper": strings.ToUpper,
        }).
        Option("missingkey=error").
        ParseFS(templatesFS, "templates/*.html"),
)

{{define "base"}}


  
    {{template "content" .}}
  

{{end}}

{{define "content"}}
{{.Title}}
{{.Body}}
{{end}}

Cette structure évite la duplication et garde le rendu lisible. Elle a aussi un autre avantage: on peut tester plus facilement les layouts, les blocs de contenu et les helpers sans relire du HTML généré à la main dans un handler. Même bien structurés, les templates ont pourtant des pièges qu’il vaut mieux verrouiller tôt.

Les pièges qui ressortent en production

Le second piège est plus architectural: vouloir faire porter au template trop de logique. Je garde les boucles, les conditions simples et le formatage léger, mais je laisse la transformation métier au code Go. La documentation de Go rappelle aussi un point important: le moteur suppose les auteurs de templates dignes de confiance, alors que les données passées à l’exécution ne le sont pas forcément. Autrement dit, je n’ouvre jamais la porte à des templates modifiables par des utilisateurs non fiables, et je n’emploie les types “sûrs” comme template.HTML ou template.JS qu’avec un contenu réellement maîtrisé. À ce stade, la question n’est plus seulement technique, elle devient architecturale.

Le niveau d’abstraction que je recommande pour un backend Go durable

Dans un backend classique, j’utilise les templates tant que l’interface reste surtout déclarative: pages serveur, mails, PDF simple, exports textuels. Dès que l’écran devient très interactif, avec état client, interactions riches et composants réutilisables complexes, je bascule plutôt vers une séparation plus nette entre API Go et frontend dédié. Les templates Go restent alors excellents pour la couche de rendu, mais ils ne doivent pas porter tout le poids du produit.

• Je prépare les données côté Go avant de les envoyer au template, au lieu de disperser des calculs dans le HTML.
• Je centralise le chargement des fichiers au démarrage pour détecter les erreurs tôt.
• Je garde les helpers petits, purs et prévisibles, sinon ils deviennent une source de dette silencieuse.
• Je teste les templates importants avec des cas réels, surtout ceux qui touchent la sécurité ou les parcours critiques.
• J’utilise l’embarquement des fichiers quand je veux un déploiement simple et reproductible.