Contexte et objectifs
Tomoko, responsable marketing régionale pour GitHub au Japon et en Corée, a transformé la chaîne de production d'événements – webinars, meet‑ups, sessions exécutives – en un processus entièrement scriptable. Chaque événement nécessite la duplication d’une page d’atterrissage, la génération de liens UTM pour chaque canal, la rédaction d’un e‑mail d’invitation, la mise à jour de deux tableaux de projet, le nettoyage quotidien de la liste des inscrits et, après la session, l’export vers le CRM et la rédaction d’un rapport. Bien que chaque tâche soit simple, l’enchaînement manuel expose à des erreurs de lien, de nommage ou de timing, qui se répercutent sur quinze rapports en aval.
Architecture basée sur les Issues
Le système repose sur trois primitives GitHub : les formulaires d’Issue, les labels et les workflows GitHub Actions. Un formulaire d’Issue collecte des champs structurés – titre, date, région, nom de campagne, audience cible – et remplace le texte libre habituel. L’ajout d’un label tel que event-setup agit comme un déclencheur conditionnel : chaque workflow s’exécute uniquement si le label correspondant est présent. Les actions analysent le corps de l’Issue, extraient les valeurs du formulaire et invoquent les API ou CLI des outils externes (plateforme d’événement, CRM). Ainsi, le dépôt GitHub fournit l’historique, la visibilité et la traçabilité habituels du code, tout en orchestrant le flux marketing.
Rôle de GitHub Copilot et du runbook
Avant la création de l’Issue, Tomoko interagit avec GitHub Copilot via le terminal ou l’application desktop. Copilot lit un fichier AGENTS.md situé à la racine du dépôt ; ce runbook décrit les conventions de nommage, la correspondance des trimestres fiscaux, les fuseaux horaires régionaux et le modèle d’e‑mail d’invitation. En s’appuyant sur ces règles, Copilot propose un nom de campagne conforme, génère deux variantes d’e‑mail et pose les questions définies dans le runbook. L’utilisateur valide ou ajuste chaque proposition, puis Copilot crée l’Issue avec les labels appropriés. Cette « conversation » garantit que les données saisies sont correctement formatées tout en conservant la flexibilité nécessaire pour des ajustements ponctuels.
Impacts opérationnels et limites
L’automatisation réduit le temps de préparation d’un événement de plusieurs jours à quelques minutes, élimine les fautes de frappe et assure la cohérence des métadonnées entre les systèmes. Le modèle repose sur la disponibilité d’une API ou d’une CLI authentifiée ; le CRM utilisé par l’équipe ne nécessite même pas de clé API, la CLI gérant l’authentification via le navigateur. Cependant, la solution dépend fortement de la stabilité des API externes : toute modification de l’interface du service d’événement ou du CLI du CRM oblige à mettre à jour les workflows. De plus, la logique de décision reste dans le runbook Markdown, ce qui rend la maintenance manuelle indispensable lorsqu’une nouvelle région ou un nouveau type d’événement apparaît.
