L’équipe marketing de GitHub au Japon et en Corée du Sud a transformé les processus récurrents liés aux événements en flux de travail exécutables dans GitHub, au lieu de gérer manuellement chaque étape entre les pages d’inscription, les liens, les campagnes d’e-mail et les bases de données clients. Selon Tomoko Tanaka, le processus commence par une seule GitHub Issue, puis GitHub Actions se charge de préparer l’événement, de vérifier les listes d’inscrits et d’exécuter les tâches de suivi après sa clôture.
L’article ne présente pas le lancement d’un nouveau produit, mais décrit une pratique opérationnelle développée par Tanaka à l’aide d’outils GitHub déjà existants, avec l’aide de GitHub Copilot pour transformer les guides de procédures internes en automatisation. L’intérêt de cette expérience réside dans le rapprochement entre la gestion marketing et des concepts familiers aux équipes de développement, tels que la revue, l’historique des modifications, les déclencheurs et les flux de travail reproductibles.
Le problème : de petites étapes et des erreurs en cascade
Les événements de l’équipe comprennent des webinaires réguliers pour les développeurs d’entreprise, des rencontres communautaires à Tokyo et des sessions privées destinées aux cadres dirigeants à Séoul. Après l’approbation d’un événement, une série de tâches répétitives commence : copier la page de destination, créer des liens comportant des balises UTM pour chaque canal, préparer le message d’invitation, enregistrer la demande d’envoi, ajouter l’événement à deux tableaux de projets, puis télécharger et nettoyer quotidiennement la liste des inscrits jusqu’à la date de l’événement.
Après l’événement, il faut exporter la liste des participants, la reconfigurer pour qu’elle puisse être importée dans le système de gestion de la relation client, appliquer les balises appropriées aux enregistrements et préparer un rapport. Aucune étape ne semble difficile en soi, mais une erreur dans un lien, un nom de campagne ou une mise à jour quotidienne peut avoir une incidence sur les rapports et les opérations ultérieures.
Trois éléments pour construire le flux de travail
L’expérience repose sur trois fonctionnalités essentielles de GitHub :
- Issue Forms : elles servent de formulaires de demande structurés plutôt que de simples zones de texte vides, et recueillent des champs tels que le titre et la date de l’événement, la région, le nom de la campagne et le public cible. Des formulaires différents existent pour les webinaires et les événements en présentiel, mais ils alimentent le même mécanisme d’exécution.
- Labels : ils ne servent pas uniquement de balises descriptives, mais aussi de clés de déclenchement. Lorsqu’une balise comme event-setup est ajoutée, le flux de travail qui lui est associé démarre.
- GitHub Actions : elles exécutent les tâches, lisent les champs présents dans le texte de la demande, puis se connectent aux outils externes pour préparer l’événement, suivre les inscrits ou achever les tâches ultérieures.
Avec cette conception, l’Issue devient l’unité de travail qui rassemble le plan, la discussion et l’état d’avancement, tout en fournissant un historique visible des décisions et un lien vers chaque modification. Il est également possible de traiter la modification du flux de travail comme une modification logicielle soumise à une pull request et à une revue avant sa fusion.
Le rôle de GitHub Copilot dans la transformation des procédures en automatisation
Tanaka n’a pas commencé par écrire directement du code. Elle a plutôt rédigé les guides opérationnels de l’équipe, les a fournis à GitHub Copilot, puis a développé l’automatisation par le dialogue. Elle affirme que son expérience antérieure de l’exploitation de bases de données sur des serveurs Linux l’a aidée à considérer ces procédures comme un pipeline programmable, même si elle reconnaît que ses compétences en programmation ne sont plus ce qu’elles étaient.
La planification commence par une conversation qui décrit l’idée, par exemple l’organisation en novembre d’un webinaire sur le développement assisté par l’intelligence artificielle. Copilot lit ensuite le fichier AGENTS.md situé à la racine du dépôt, un guide rédigé au format Markdown qui définit les règles de dénomination des campagnes, l’association des trimestres fiscaux aux dates, les fuseaux horaires et les critères applicables au message d’invitation. En s’appuyant sur ces règles et sur un événement antérieur similaire, Copilot propose un nom de campagne, prépare deux versions du message d’invitation et pose les questions requises par le guide opérationnel.
Qu’est-ce qui change concrètement ?
Cette approche permet de réduire les tâches manuelles répétitives sans supprimer la décision humaine lors de la phase de planification. La conversation laisse une marge pour personnaliser un événement donné, tandis que l’automatisation prend en charge l’exécution des étapes fixes après leur approbation. Selon l’article, la préparation manuelle d’un événement prenait environ deux jours, alors que le processus commence désormais par une seule Issue, puis exécute la préparation, la vérification quotidienne des listes d’inscrits et le nettoyage après la fin de l’événement.
L’élément déterminant n’est pas GitHub Actions seul, mais la programmabilité des autres outils. La plateforme de gestion des événements utilise une API, tandis que le système de gestion de la relation client repose sur une interface CLI officielle couvrant les tâches requises et permettant de se connecter via le navigateur ; Tanaka n’a donc pas eu besoin de configurer une clé API pour celui-ci. La règle qui se dégage de l’article est que l’existence d’une API ou d’une interface CLI suffit à ouvrir la voie à une intégration programmatique, qu’il s’agisse d’une plateforme événementielle, d’un système CRM, d’un générateur de formulaires ou d’un service d’analyse.
L’expérience montre également pourquoi il peut être préférable de créer un flux personnalisé dans un environnement couvrant plusieurs marchés. L’équipe APAC ne travaille pas comme un marché unique : le même webinaire peut être organisé en japonais à Tokyo et en coréen à Séoul, avec des segments, des champs CRM et des critères de définition d’un prospect qualifié différents. Tanaka explique que l’adaptation d’une plateforme prête à l’emploi à ces différences peut nécessiter des budgets de personnalisation et de conseil, ainsi qu’une attente liée à la feuille de route du fournisseur, tandis qu’une construction interne permet de modifier le flux de travail par l’intermédiaire d’une pull request et d’une revue.
Il ne s’agit pas d’une recette visant à supprimer les plateformes marketing prêtes à l’emploi, ni d’une preuve que l’automatisation convient à toutes les équipes. La valeur pratique du cas présenté réside d’abord dans la documentation du travail, puis dans la séparation des décisions qui nécessitent une flexibilité humaine et des étapes répétitives pouvant être exécutées automatiquement. La réussite du modèle dépend également de l’existence d’outils externes pouvant être intégrés et de la précision des guides opérationnels ; si les règles sont incomplètes ou changent sans être mises à jour, les erreurs peuvent être transférées au flux de travail automatisé au lieu de disparaître.